Schaduw-GTM-containers op gokplatforms met meerdere merken: wat ze zijn en hoe u ze detecteert

Als uw platform 70 of meer casinomerken beheert, draait Google Tag Manager vrijwel zeker op elk domein. En over al die domeinen is het aantal actieve container-ID's dat uw beveiligingsteam formeel heeft beoordeeld waarschijnlijk veel kleiner dan het aantal dat daadwerkelijk wordt uitgevoerd in de browsers van spelers. Die kloof is het schaduw-GTM-probleem. In Q1 2025 detecteerde cside meer dan 300.000 aanvalssignalen op bewaakte sites, waarbij ongeautoriseerde scriptuitvoering via tagmanagers een van de meest consistente aanvalsvectoren in het iGaming-segment vormde. In mijn werk met gokexploitanten met meerdere merken heb ik gezien dat deze kloof tussen de containers die beveiligingsteams kennen en de containers die daadwerkelijk in de browsers van spelers worden uitgevoerd groter wordt met elk merk dat aan een portfolio wordt toegevoegd.

Wat een GTM-container eigenlijk is en waarom dit belangrijk is voor beveiliging

Snel antwoord: Een Google Tag Manager-container is een JavaScript-uitvoeringsomgeving die op uw domein wordt geladen met volledige toegang tot de DOM, cookies, browseropslag en netwerkverzoeken. Elke tag die in die container wordt gepubliceerd, wordt uitgevoerd met dezelfde rechten als uw eigen first-party code. Een ongeautoriseerde container-ID op uw domein staat gelijk aan het verlenen van schrijftoegang aan een onbekende partij tot uw naar spelers gerichte interface.**

Google Tag Manager is ontworpen om niet-ontwikkelaars JavaScript te laten implementeren op live websites zonder betrokkenheid van engineering. Dat is de kernwaarde van het product voor marketing- en analyseteams. Vanuit beveiligingsperspectief betekent diezelfde functie dat een enkele container-ID in een sitesjabloon een open uitvoeringscontext vormt voor iedereen met publicatierechten voor die container. Om de omvang van het probleem te illustreren: een enkele GTM-container kan 48 of meer onderliggende scripts activeren, en elk van die scripts kan verdere afhankelijkheden laden. De laadketen van leveranciers is een boom, geen lijst, en de meeste beveiligingsteams zijn zich alleen bewust van de wortel.

Wanneer beveiligingsteams hun aanvalsoppervlak controleren, richten ze zich doorgaans op:

• Server-side infrastructuur en API's
• Authenticatie en sessiebeheer
• Bekende scripts van derden in de codebase

Wat zelden wordt gecontroleerd, is de GTM-containerinventaris zelf: welke container-ID's actief zijn op welke domeinen, wie publicatietoegang heeft, en welke tags momenteel zijn geconfigureerd om af te vuren. Voor een platform met meerdere merken en 70 tot 200 domeinen wordt deze inventaris vrijwel nooit met beveiligingsstrengheid bijgehouden.

Het ENISA-dreigingslandschap voor supply chain-aanvallen identificeert compromittering van scripts en afhankelijkheden van derden als een van de belangrijkste escalerende aanvalscategorieën. GTM-containers vormen de kern van dit risico omdat ze tegelijkertijd worden vertrouwd door de browser, worden beheerd door personeel zonder beveiligingsachtergrond, en in staat zijn willekeurige code uit te voeren. Voor een breder beeld van hoe afhankelijkheden van derden aanvalsvectoren worden voordat ze uw tagmanager bereiken, is het patroon van supply chain-aanvallen op zichzelf de moeite waard om te begrijpen.

Hoe schaduw-GTM-containers ontstaan op gokplatforms

Snel antwoord: Schaduwcontainers bereiken iGaming-domeinen via vier hoofdroutes: affiliateteams die hun eigen container-ID's insluiten tijdens het opzetten van campagnes, bureaupersoneel dat containers toevoegt aan nieuwe merklanceringen zonder technische beoordeling, gecompromitteerde inloggegevens die aanvallers toegang geven tot het GTM-account, en snelkoppelingen van ontwikkelaars waarbij een testcontainer-ID naar productie wordt gepromoveerd en nooit wordt verwijderd.**

De term "schaduw" impliceert niet noodzakelijk kwade bedoelingen op het moment van invoeging. Veel schaduwcontainers beginnen als legitieme operationele beslissingen die nooit zijn opgeschoond of herzien. Maar ze creëren persistente, ongemonitorde uitvoeringscontexten die lang na hun oorspronkelijke doel nog kunnen worden misbruikt.

Dit zijn de vier meest voorkomende oorsprongen die worden waargenomen op iGaming-platforms met meerdere merken:

• Toevoegingen door affiliateteams: een performance-marketingteam sluit een deal met een affiliatenetwerk waarvoor een pixel via GTM moet worden afgevuurd. De affiliate levert zijn eigen container-ID aan. Marketing voegt die rechtstreeks toe aan de domeinsjabloon zonder een beveiligingsticket aan te maken. De container vuurt vanaf dat moment af op alle naar spelers gerichte pagina's.

• Nieuwe merklanceringen: tijdens een snelle merklancering voegt een bureau of ontwikkelaar een tijdelijke GTM-container toe om analytics en tracking te prototypen. Na de lancering blijft de container actief omdat niemand de taak van ontmanteling op zich neemt.

• Gecompromitteerde GTM-inloggegevens: een dreigingsactor krijgt toegang tot een bestaande, geautoriseerde GTM-container via een gephishte marketingcontractant of een credential-stuffing-aanval op een Google-account dat aan de container is gekoppeld. Ze publiceren een nieuwe kwaadaardige tag binnen een reeds vertrouwde container.

• Snelkoppelingen van ontwikkelaars: een QA- of stagingcontainer-ID wordt tijdens de bouw van een site hardcoded in een gedeelde sjabloon. Wanneer de sjabloon op meerdere domeinen live gaat, gaat de stagingcontainer mee, en stagingcontainers hebben doorgaans minder gecontroleerde publicatietoegang.

In al deze gevallen tonen de netwerklogs van het platform dezelfde vermelding: een succesvol GET-verzoek naar www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX. De container-ID is zichtbaar in de URL, maar wordt op geen enkele geautomatiseerde manier vergeleken met een goedgekeurde inventaris.

Wat er kan worden uitgevoerd binnen een ongeautoriseerde container

Snel antwoord: Binnen een ongeautoriseerde GTM-container kan een aanvaller pixelscripts inzetten die PII van spelers exfiltreren naar advertentienetwerken van derden, omleidingscode injecteren die spelers naar sites van concurrenten leidt, formulierveld-skimmers installeren op stortingspagina's, schaduw-affiliatetracking uitvoeren die conversieattributie kaapt, of extra kwaadaardige payloads laden vanaf externe domeinen, allemaal zonder enige serverside voetafdruk.**

Het bereik van payloads dat een GTM-container kan afleveren, wordt alleen beperkt door wat JavaScript in de browser kan doen. In de praktijk zijn vier payloadcategorieën het meest relevant voor iGaming-platforms.

Ten eerste, schaduw-trackingpixels. Een container kan Facebook-, TikTok- of LinkedIn-pixelevents afvuren met pixel-ID's die niet van het bedrijf zelf zijn. Voor een gokexploitant die op deze platforms wettelijk niet mag adverteren, is dit zowel een AVG-overtreding als een schending van het advertentiebeleid, en de exploitant kan zich hiervan volledig onbewust zijn.

Ten tweede, redirectscripts voor spelers. Zoals beschreven in de context van het kapen van de speler-journey, kan een aangepaste HTML-tag binnen een GTM-container klikgebeurtenissen op stortingsknoppen, inlogformulieren of bonus-CTA's onderscheppen en spelers omleiden naar een bestemming van een concurrent. Dankzij het ingebouwde triggersysteem van de container is het eenvoudig om dit te beperken tot specifieke pagina's, apparaten of gebruikerssegmenten.

Ten derde, formulierveld-skimmers. Op stortings- of KYC-pagina's waar spelers kaartgegevens of identiteitsdocumenten invoeren, kan een GTM-tag event listeners koppelen aan invoervelden en ingevoerde waarden exfiltreren naar een extern eindpunt. Dit is een equivalent op browserniveau van aanvallen in Magecart-stijl, uitgevoerd zonder serverside code aan te raken.

Ten vierde, loaderscripts. Een containertag kan extra externe JavaScript-bestanden laden, waardoor de GTM-container feitelijk verandert in een eerste-fase-payloaddropper. Het domein dat de extra payload aanlevert, staat op het moment van laden mogelijk op geen enkele blokkeerlijst, waardoor detectie op netwerkniveau onbetrouwbaar wordt.

Het diagram hierboven splitst dezelfde gtm.js-load op in de twee lagen die deze waarnemen. De netwerklaag stopt bij een schone respons; de runtimelaag is waar de schaduwcontainer zijn werk daadwerkelijk doet.

De vier runtime-vertakkingen waarin de container uitwaaiert, schaduw-trackingpixels die PII lekken naar advertentienetwerken, een omleiding van de speler naar een concurrent, een formulierveld-skimmer op stortings- en KYC-pagina's, en een loaderscript dat een externe payload binnenhaalt, zijn precies de vier mechanismen die hierboven zijn beschreven. Elk wordt uitgevoerd na de 200 OK, en dat is precies waarom een schone netwerklog geen bewijs is dat de container schoon is.

Waarom bestaande tools schaduwcontaineractiviteit missen

Snel antwoord: Netwerkmonitoringtools en oplossingen op CDN-niveau zien dat gtm.js succesvol is geladen vanuit de infrastructuur van Google. Ze zien niet welke container-ID's actief waren, welke tags binnen die containers werden afgevuurd, of welke JavaScript die tags na het laden uitvoerden. Het aanvalsoppervlak bevindt zich volledig binnen de JavaScript-runtime van de browser, na afronding van de netwerktransactie.**

Dit is de architecturale kloof die schaduw-GTM-containers tot een aanhoudend, onvoldoende aangepakt risico maakt. In de onderstaande tabel wordt per veelgebruikte tool aangegeven wat deze wel en niet kan waarnemen in een schaduw-GTM-scenario.

Bij onze monitoring van gokplatforms met meerdere merken is de kloof in container-ID's consistent groter dan exploitanten verwachten. Beveiligingsteams hebben vaak formele registraties voor minder dan de helft van de container-ID's die wij zien uitvoeren op hun domeinportfolio's. De discrepantie groeit met de schaal van het platform, en groeit sneller dan de meeste governance-processen kunnen bijhouden.

De onthulling van Sansec over polyfill.js in juni 2024, die meer dan 490.000 sites trof, is een verhelderende parallel. Elk van die sites had wat leek op een legitieme, veelgebruikte bibliotheek geladen vanaf een vertrouwde CDN. Netwerklogs toonden een succesvolle, schone respons. De kwaadaardige payload werd alleen zichtbaar toen iemand keek naar wat de JavaScript feitelijk in de browser deed. Schaduw-GTM-containers volgen hetzelfde patroon: de netwerklaag rapporteert een schone load vanuit de infrastructuur van Google, en alles wat daarna volgt is onzichtbaar zonder instrumentatie op browserniveau.

Hoe cside elke container en elk script op alle domeinen identificeert

Snel antwoord: cside instrumenteert 100% van de echte gebruikerssessies op browserniveau, wat betekent dat het elke GTM-container-ID ziet laden op elk domein in uw portfolio, elke tag die binnen elke container afvuurt, en elk script dat die tags uitvoeren of laden. Wanneer een nieuwe container-ID verschijnt of een bekende container een nieuw type payload uitvoert, geeft cside in realtime een waarschuwing met volledige uitvoeringscontext.**

Voor platforms met meerdere merken biedt cside een uniforme scriptinventaris voor het volledige domeinportfolio. In plaats van een handmatige audit van elk GTM-account te vereisen, brengt het platform de runtime-realiteit naar boven: wat er op dit moment daadwerkelijk wordt uitgevoerd in de browsers van spelers, op elk domein.

Specifieke functionaliteiten die relevant zijn voor detectie van schaduw-GTM:

• Opsomming van container-ID's: cside identificeert elke afzonderlijke GTM-container-ID die wordt waargenomen op alle bewaakte domeinen, en markeert elke container die niet aanwezig was in de vorige inventarissnapshot
• In kaart brengen van taguitvoering: voor elke container brengt cside in kaart welke aangepaste HTML-tags en scriptladende tags afvuren, en met welke externe domeinen ze contact maken
• Waarschuwing bij nieuwe payload: wanneer een eerder waargenomen container een nieuw scriptpatroon begint uit te voeren of contact maakt met een nieuw extern domein, wordt onmiddellijk een waarschuwing gegeven
• Cross-domein correlatie: als een schaduwcontainer-ID gelijktijdig op meerdere domeinen verschijnt, identificeert cside het patroon, wat nuttig is voor het detecteren van gecoördineerde aanvallen tijdens nieuwe merklanceringen of de uitrol van affiliatecampagnes
• 100% sessiedekking: omdat cside elke sessie instrumenteert, en niet een steekproef, legt het aanvalsomstandigheden vast die alleen optreden bij specifieke gebruikerssegmenten, apparaten of geografische locaties
• Permissieprofielen per leverancier: zodra een schaduwcontainer is geïdentificeerd en onder governance is gebracht, kunnen exploitanten elke via GTM geladen leverancier een eigen permissieprofiel toewijzen met specifieke, beheersbare mogelijkheden. Dit betekent dat een via GTM geladen analytics-tag kan worden beperkt in toegang tot betaalvelden, de Payment Request API, of localStorage, zelfs als de code van de leverancier later wordt gecompromitteerd

cside vertrouwt niet op monitoring via proxy's of passieve steekproeven van netwerkverkeer. De instrumentatie draait binnen de browser, waardoor het hetzelfde uitzichtpunt heeft als de scripts die het monitort.

Wat de eerste monitoringsessie aan het licht bracht

Toen we eerder dit jaar de eerste cside-monitoringsessie uitvoerden op een groot Europees online gokplatform met meerdere merken, was een van de eerste dingen die het dashboard naar boven bracht een set GTM-container-ID's waar niemand in het beveiligingsteam verklaring voor had. Het platform exploiteerde meer dan 70 casino- en sportweddenschapsmerken, en het beveiligingsteam ging ervan uit dat het een redelijk overzicht had van zijn tagmanager-domein. Wat de inventaris op browserniveau liet zien, was anders. Binnen de eerste dag van het monitoren van het eerste merkdomein identificeerde cside meerdere actieve container-ID's die door het marketingteam waren toegevoegd zonder enig beveiligingsbeoordelingsproces te doorlopen. De containers waren al maanden actief op live, naar spelers gerichte pagina's.

Het beveiligingsteam was niet op de hoogte gesteld, omdat het marketingteam niet wist dat melding vereist was. Er bestond geen vaststaand proces dat wijzigingen aan de tagmanager koppelde aan beveiligingstoezicht. Elke container was toegevoegd in de context van een legitieme campagne of affiliatedeal, en was simpelweg nooit beoordeeld of verwijderd. Binnen 24 uur na de start van de monitoringsessie had het platform zijn eerste volledige runtime-inventaris van elke container die op het testdomein werd uitgevoerd, en was er een herstelplan in gang gezet voor de niet-beoordeelde containers. De reactie van het platform na de sessie: dit was de eerste keer dat ze hun volledige script-inventaris op browserniveau in één overzicht hadden gezien.

Samenvatting

Schaduw-GTM-containers zijn een governancefout die een beveiligingsrisico creëert. De containers komen binnen via normale operationele kanalen, laden vanuit vertrouwde Google-infrastructuur, en zijn onzichtbaar voor elke monitoringtool die niet binnen de browser draait. Voor platforms met meerdere merken is continue instrumentatie op browserniveau, die een live inventaris bijhoudt van elke container-ID, elke tag en elk script dat wordt uitgevoerd op het gehele domeinportfolio, de enige betrouwbare aanpak. Een audit op een specifiek moment is altijd verouderd tegen de tijd dat de volgende container wordt toegevoegd. De client-side security-functionaliteit van cside biedt deze continue inventarisatie, en voor meer details over hoe redirectpayloads via deze containers worden afgeleverd, zie onze gids over kwaadaardige script-redirectaanvallen op casinoplatforms.