Se a sua plataforma gere 70 ou mais marcas de casino, o Google Tag Manager está quase certamente a ser executado em todos os domínios. E, nesses domínios, o número de IDs de contentor ativos que a sua equipa de segurança reviu formalmente é provavelmente muito inferior ao número que está de facto a ser executado nos navegadores dos jogadores. Essa lacuna é o problema dos contentores sombra do GTM. No Q1 de 2025, a cside detetou mais de 300.000 sinais de ataque em sites monitorizados, sendo a execução não autorizada de scripts através de gestores de tags um dos vetores de ataque mais consistentes no segmento iGaming. Ao trabalhar com operadores de jogo multimarca, tenho visto esta lacuna entre os contentores que as equipas de segurança conhecem e os contentores que estão efetivamente a ser executados nos navegadores dos jogadores aumentar a cada marca acrescentada a um portefólio.
O que é, na realidade, um contentor GTM e porque é que importa para a segurança
Resposta rápida: Um contentor do Google Tag Manager é um ambiente de execução de JavaScript carregado no seu domínio com acesso total ao DOM, aos cookies, ao armazenamento do navegador e aos pedidos de rede. Qualquer tag publicada dentro desse contentor é executada com as mesmas permissões que o seu próprio código first-party. Um ID de contentor não autorizado no seu domínio equivale a conceder a uma parte desconhecida acesso de escrita à sua interface voltada para o jogador.**
O Google Tag Manager foi concebido para permitir que não-programadores implementem JavaScript em sites em produção sem envolvimento da engenharia. Essa é a sua principal proposta de valor para as equipas de marketing e de análise. Do ponto de vista da segurança, essa mesma funcionalidade significa que um único ID de contentor num modelo de site é um contexto de execução aberto para qualquer pessoa com direitos de publicação nesse contentor. Para ilustrar a escala do problema: um único contentor GTM pode disparar 48 ou mais scripts-filho, e cada um desses scripts pode carregar mais dependências. A cadeia de carregamento de fornecedores é uma árvore, não uma lista, e a maioria das equipas de segurança só conhece a raiz.
Quando as equipas de segurança auditam a sua superfície de ataque, tendem a concentrar-se em:
- Infraestrutura e APIs do lado do servidor
- Autenticação e gestão de sessões
- Scripts de terceiros conhecidos na base de código
O que raramente é auditado é o próprio inventário de contentores GTM: que IDs de contentor estão ativos em que domínios, quem tem acesso de publicação e que tags estão atualmente configuradas para disparar. Numa plataforma multimarca com 70 a 200 domínios, este inventário quase nunca é mantido com rigor de segurança.
O ENISA Threat Landscape for Supply Chain Attacks identifica o comprometimento de scripts e dependências de terceiros como uma das principais categorias de ataque em crescimento. Os contentores GTM estão no centro deste risco porque são, em simultâneo, confiados pelo navegador, controlados por pessoal alheio à segurança e capazes de executar código arbitrário. Para uma visão mais alargada de como as dependências de terceiros se tornam vetores de ataque antes de chegarem ao seu gestor de tags, vale a pena compreender por si só o padrão de ataque à cadeia de abastecimento.
Como surgem os contentores sombra do GTM nas plataformas de jogo
Resposta rápida: Os contentores sombra chegam aos domínios de iGaming através de quatro vias principais: equipas de afiliação a incorporar os seus próprios IDs de contentor durante a configuração de campanhas, pessoal de agências a adicionar contentores em lançamentos de novas marcas sem revisão de engenharia, credenciais comprometidas que dão aos atacantes acesso à conta GTM, e atalhos de programadores em que um ID de contentor de teste é promovido para produção e nunca removido.**
O termo "sombra" não implica necessariamente intenção maliciosa no momento da inserção. Muitos contentores sombra começam como decisões operacionais legítimas que nunca chegaram a ser limpas ou revistas. Mas criam contextos de execução persistentes e não monitorizados que podem ser explorados muito depois de o seu propósito original ter terminado.
Eis as quatro origens mais comuns observadas em plataformas de iGaming multimarca:
-
Adições de contentores por equipas de afiliação: uma equipa de marketing de performance fecha um acordo com uma rede de afiliação que exige o disparo de um pixel através do GTM. O afiliado fornece o seu próprio ID de contentor. O marketing adiciona-o diretamente ao modelo de domínio sem abrir um ticket de segurança. A partir desse momento, o contentor dispara em todas as páginas voltadas para o jogador.
-
Lançamentos de novas marcas: durante o lançamento acelerado de uma marca, uma agência ou um programador adiciona um contentor GTM temporário para prototipar análises e rastreio. Após o lançamento, o contentor continua ativo porque ninguém assume a tarefa de o desativar.
-
Credenciais GTM comprometidas: um agente de ameaça obtém acesso a um contentor GTM autorizado existente através de um prestador de marketing vítima de phishing ou de um ataque de credential stuffing a uma conta Google associada ao contentor. O agente publica uma nova tag maliciosa dentro de um contentor já considerado de confiança.
-
Atalhos de programadores: um ID de contentor de QA ou de staging fica codificado de forma fixa (hard-coded) num modelo partilhado durante a construção de um site. Quando o modelo entra em produção em vários domínios, o contentor de staging vai junto, e os contentores de staging têm tipicamente um acesso de publicação menos controlado.
Em todos estes casos, os registos de rede da plataforma mostram a mesma entrada: um pedido GET bem-sucedido a www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX. O ID do contentor é visível no URL, mas não é cruzado com um inventário aprovado de forma automatizada.
O que pode ser executado dentro de um contentor não autorizado
Resposta rápida: Dentro de um contentor GTM não autorizado, um atacante pode implementar scripts de pixel que exfiltram dados pessoais (PII) dos jogadores para redes de anúncios de terceiros, injetar código de redirecionamento que desvia os jogadores para sites concorrentes, instalar skimmers de campos de formulário em páginas de depósito, executar rastreio de afiliação sombra que sequestra a atribuição de conversões, ou carregar payloads maliciosos adicionais a partir de domínios externos, tudo sem qualquer vestígio do lado do servidor.**
O leque de payloads que um contentor GTM pode entregar só é limitado pelo que o JavaScript consegue fazer no navegador. Na prática, há quatro categorias de payload mais relevantes para as plataformas de iGaming.
Primeiro, os pixels de rastreio sombra. Um contentor pode disparar eventos de pixel do Facebook, do TikTok ou do LinkedIn com IDs de pixel que não são first-party. Para um operador de jogo que não pode legalmente anunciar nestas plataformas, isto constitui simultaneamente uma violação do RGPD e uma violação da política de publicidade, e o operador pode estar completamente alheio ao que está a acontecer.
Segundo, os scripts de redirecionamento de jogadores. Conforme descrito no contexto do sequestro do percurso do jogador, uma tag HTML personalizada dentro de um contentor GTM pode intercetar eventos de clique em botões de depósito, formulários de início de sessão ou CTAs de bónus, e redirecionar os jogadores para um destino concorrente. O sistema de gatilhos (triggers) integrado no contentor torna simples limitar isto a páginas, dispositivos ou segmentos de utilizadores específicos.
Terceiro, os skimmers de campos de formulário. Em páginas de depósito ou de KYC onde os jogadores introduzem dados de cartão ou documentos de identidade, uma tag GTM pode associar event listeners a campos de introdução e exfiltrar os valores inseridos para um endpoint remoto. Trata-se de um equivalente, ao nível do navegador, dos ataques de estilo Magecart, executado sem tocar em código do lado do servidor.
Quarto, os scripts de carregamento (loaders). Uma tag do contentor pode carregar ficheiros JavaScript externos adicionais, transformando efetivamente o contentor GTM num dropper de payload de primeira fase. O domínio que serve o payload adicional pode não constar de nenhuma lista de bloqueio no momento do carregamento, o que torna a deteção ao nível da rede pouco fiável.
O diagrama acima divide o mesmo carregamento de gtm.js nas duas camadas que o observam. A camada de rede termina numa resposta limpa; a camada de execução (runtime) é onde o contentor sombra realmente faz o seu trabalho.
| Camada | O que observa | Veredito |
|---|---|---|
| Rede, o que a CSP, a WAF e os registos de rede veem | O navegador do jogador emite GET www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX; resolve para a infraestrutura da Google (de confiança, na lista de permissões da CSP) | 200 OK, carregamento limpo |
| Lacuna de deteção | Transação de rede concluída, a execução começa | A transição é invisível para as ferramentas de rede |
| Runtime JS do navegador, invisível para as ferramentas de rede | O contentor sombra do GTM não revisto (ID de contentor não revisto, carregado em tempo de execução) ramifica-se em quatro comportamentos, cada um disparado do lado do cliente | Sem veredito de rede adicional; o comportamento é o único sinal |
Os quatro ramos em tempo de execução em que o contentor se divide, pixels de rastreio sombra que exfiltram PII para redes de anúncios, um redirecionamento do jogador para um concorrente, um skimmer de campos de formulário nas páginas de depósito e KYC, e um script de carregamento que obtém um payload externo, são exatamente os quatro mecanismos descritos acima. Todos eles são executados depois do 200 OK, razão pela qual um registo de rede limpo não é prova de que o contentor é seguro.
Porque é que as ferramentas existentes não detetam a atividade dos contentores sombra
Resposta rápida: As ferramentas de monitorização de rede e as soluções ao nível de CDN veem que o GTM.js foi carregado com sucesso a partir da infraestrutura da Google. Não veem que IDs de contentor estavam ativos, que tags dispararam dentro desses contentores, ou que JavaScript essas tags executaram depois do carregamento. A superfície de ataque reside inteiramente dentro do runtime JavaScript do navegador, depois de a transação de rede estar concluída.**
Esta é a lacuna arquitetónica que torna os contentores sombra do GTM um risco persistente e pouco endereçado. A tabela abaixo mapeia cada ferramenta comum com aquilo que consegue e não consegue observar num cenário de GTM sombra.
| Categoria de ferramenta | O que CONSEGUE ver | O que NÃO CONSEGUE ver |
|---|---|---|
| Content Security Policy (CSP) | Se os scripts carregam a partir de domínios permitidos | Que ID de contentor está a ser executado; que código é executado dentro de um domínio permitido |
| Web Application Firewall (WAF) | Cabeçalhos e corpos dos pedidos/respostas HTTP | JavaScript em execução dentro de um separador do navegador após o carregamento da página |
| Análise de tráfego de rede | Que o gtm.js foi carregado; o ID do contentor no URL do pedido | Que tags dispararam dentro do contentor; o que essas tags executaram; recursos externos carregados após a inicialização |
| Ferramentas de desenvolvedor do navegador (manual) | Comportamento completo em tempo de execução num único domínio, num determinado momento | Comportamento em tempo de execução em 70 a 200 domínios de forma contínua; alterações de tags publicadas dinamicamente |
Na nossa monitorização de plataformas de jogo multimarca, a lacuna de IDs de contentor é consistentemente maior do que os operadores esperam. As equipas de segurança têm frequentemente registos formais para menos de metade dos IDs de contentor que observamos em execução nos seus portefólios de domínios. A discrepância aumenta com a escala da plataforma, e aumenta mais depressa do que a maioria dos processos de governação consegue acompanhar.
A divulgação da Sansec sobre o polyfill.js, em junho de 2024, que afetou mais de 490.000 sites, é um paralelo instrutivo. Todos esses sites tinham carregado aquilo que parecia ser uma biblioteca legítima e amplamente utilizada, a partir de uma CDN de confiança. Os registos de rede mostravam uma resposta limpa e bem-sucedida. O payload malicioso só se tornou visível quando alguém observou o que o JavaScript estava efetivamente a fazer dentro do navegador. Os contentores sombra do GTM seguem o mesmo padrão: a camada de rede reporta um carregamento limpo a partir da infraestrutura da Google, e tudo o que se segue é invisível sem instrumentação ao nível do navegador.
Como a cside identifica todos os contentores e todos os scripts em todos os domínios
Resposta rápida: A cside instrumenta 100% das sessões reais de utilizadores ao nível do navegador, o que significa que vê todos os IDs de contentor GTM carregados em todos os domínios do seu portefólio, todas as tags que disparam dentro de cada contentor e todos os scripts que essas tags executam ou carregam. Quando surge um novo ID de contentor, ou quando um contentor conhecido executa um novo tipo de payload, a cside emite um alerta em tempo real com o contexto de execução completo.**
Para plataformas multimarca, a cside fornece um inventário unificado de scripts em todo o portefólio de domínios. Em vez de exigir uma auditoria manual de cada conta GTM, a plataforma revela a realidade em tempo de execução: o que está efetivamente a ser executado nos navegadores dos jogadores, neste preciso momento, em cada domínio.
Capacidades específicas relevantes para a deteção de contentores sombra do GTM:
- Enumeração de IDs de contentor: a cside identifica todos os IDs de contentor GTM distintos observados a carregar em todos os domínios monitorizados, sinalizando qualquer um que não estivesse presente no instantâneo de inventário anterior
- Mapeamento da execução de tags: para cada contentor, a cside mapeia que tags HTML personalizadas e tags de carregamento de scripts disparam, e que domínios externos contactam
- Alerta de novo payload: quando um contentor previamente observado começa a executar um novo padrão de script ou a contactar um novo domínio externo, é emitido imediatamente um alerta
- Correlação entre domínios: se um ID de contentor sombra aparecer em vários domínios em simultâneo, a cside identifica o padrão, o que é útil para detetar ataques coordenados durante lançamentos de novas marcas ou lançamentos de campanhas de afiliação
- Cobertura de 100% das sessões: como a cside instrumenta todas as sessões, e não uma amostra, consegue captar condições de ataque que só se manifestam para segmentos de utilizadores, dispositivos ou geografias específicos
- Perfis de permissão por fornecedor: assim que um contentor sombra é identificado e trazido para dentro da governação, os operadores podem atribuir a cada fornecedor carregado via GTM o seu próprio perfil de permissões, com capacidades controláveis específicas. Isto significa que uma tag de análise carregada através do GTM pode ficar impedida de aceder a campos de pagamento, à Payment Request API ou ao localStorage, mesmo que o código do fornecedor venha a ser comprometido mais tarde
A cside não depende de monitorização baseada em proxy nem de amostragem passiva do tráfego de rede. A instrumentação é executada dentro do navegador, o que lhe confere o mesmo ponto de vista dos scripts que monitoriza.
O que a primeira sessão de monitorização revelou
Quando realizámos a primeira sessão de monitorização da cside numa importante plataforma europeia de jogo online multimarca, no início deste ano, uma das primeiras coisas que o painel revelou foi um conjunto de IDs de contentor GTM que ninguém na equipa de segurança conseguia explicar. A plataforma operava mais de 70 marcas de casino e apostas desportivas, e a equipa de segurança acreditava ter um controlo razoável sobre o seu parque de gestores de tags. O que o inventário ao nível do navegador mostrou foi diferente. No primeiro dia de monitorização do domínio da marca inicial, a cside identificou vários IDs de contentor ativos que tinham sido adicionados pela equipa de marketing sem passar por qualquer processo de revisão de segurança. Os contentores estavam a carregar em páginas em produção, voltadas para os jogadores, há meses.
A equipa de segurança não tinha sido notificada porque a equipa de marketing não sabia que a notificação era necessária. Não existia qualquer processo estabelecido que ligasse as alterações no gestor de tags à supervisão de segurança. Cada contentor tinha sido adicionado no contexto de uma campanha legítima ou de um acordo de afiliação, e simplesmente nunca tinha sido revisto nem removido. Nas primeiras 24 horas após o início da sessão de monitorização, a plataforma teve pela primeira vez um inventário completo, em tempo de execução, de todos os contentores em execução no domínio de teste, e já estava em curso um plano de remediação para os contentores não revistos. O comentário da plataforma após a sessão: foi a primeira vez que viram, num só lugar, todo o seu parque de scripts ao nível do navegador.
Resumo
Os contentores sombra do GTM são uma falha de governação que cria uma exposição de segurança. Os contentores chegam através de canais operacionais normais, carregam a partir de infraestrutura de confiança da Google, e são invisíveis para qualquer ferramenta de monitorização que não seja executada dentro do navegador. Para plataformas multimarca, a única abordagem fiável é a instrumentação contínua ao nível do navegador, que mantém um inventário em tempo real de todos os IDs de contentor, todas as tags e todos os scripts em execução em todo o portefólio de domínios. Uma auditoria pontual estará sempre desatualizada no momento em que o contentor seguinte for adicionado. A capacidade de segurança do lado do cliente da cside fornece este inventário contínuo e, para mais detalhes sobre como os payloads de redirecionamento são entregues através destes contentores, consulte o nosso guia sobre ataques de redirecionamento por scripts maliciosos em plataformas de casino.
