Ataques Magecart explicados: como funciona o web skimming no navegador

TL;DR: como funcionam os ataques Magecart

• Vítimas reais, grupos reais: Pelo menos sete grupos de atacantes a injetar JavaScript em páginas de pagamento. British Airways (380 mil registos), Ticketmaster, Newegg, Warner Music.
• Corre depois do WAF: O ataque ocorre depois de o seu WAF aprovar a página, no mesmo contexto JavaScript do seu formulário de checkout.
• As regras que fecham: Os requisitos 6.4.3 e 11.6.1 fecham essa lacuna. Obrigatórios desde 31 de março de 2025 para qualquer entidade que toque numa página de pagamento.

Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.

O ataque em três movimentos

Toda a campanha de skimming, independentemente do grupo que a executa, resume-se ao mesmo ciclo de vida. Tire a marca e ficam três movimentos.

O resto deste artigo percorre cada movimento pela ordem, porque é essa ordem que torna o ataque invisível.

Movimento 1: como o código chega à página

O atacante precisa que o seu JavaScript seja executado no navegador do visitante. Existem três vias comuns para chegar à página, nenhuma das quais exige tocar na lógica do seu servidor de origem.

1. Um ficheiro alojado no próprio site. Os atacantes obtêm acesso de escrita através de um plugin vulnerável, um CMS desatualizado, ou um login de administrador roubado, e depois acrescentam algumas linhas a um ficheiro JavaScript que já é servido pelo site. A alteração é pequena e muitas vezes escondida dentro de código legítimo, pelo que um diff parece inofensivo.
2. Um script de terceiros. Os atacantes comprometem um fornecedor cujo script é carregado diretamente com <script src>, como um widget de analytics, de chat, ou de testes A/B. O skimmer passa então a ser servido a partir do domínio do fornecedor a todos os clientes que carregam a sua página, e nunca está no seu repositório para ser encontrado, razão pela qual proteger scripts de terceiros é uma disciplina própria.
3. Um gestor de tags. Os atacantes assumem o controlo de um contentor do Google Tag Manager ou equivalente e adicionam uma tag que contém o skimmer. Todos os sites e páginas que usam esse contentor passam a executar o código, incluindo páginas de checkout onde essa tag não deveria carregar.

As vias de terceiros e de gestor de tags escalam, o que as torna as mais perigosas. Um único fornecedor comprometido semeia skimmers em todos os sites que confiam nele, e um script que aprovou pode trazer consigo outro script que nunca revisou, o problema de quarta parte. É esta forma de ataque à cadeia de abastecimento que os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 visam, ao exigir um inventário e autorização de cada script numa página de pagamento. A violação da Ticketmaster em 2018 seguiu exatamente este percurso: o skimmer chegou ao checkout através do script de chatbot de um fornecedor comprometido, e não através do código próprio da Ticketmaster (resumo da Wikipédia sobre o incidente de 2018).

Movimento 2: como o skimmer lê o seu formulário

Assim que o script é executado, ler o formulário é desenvolvimento web comum, mas usado contra si. Ler e modificar o DOM é como funciona qualquer framework moderna, pelo que as ações do skimmer parecem comportamento normal da página. Um skimmer normalmente faz uma ou mais das seguintes coisas:

• Lê valores de input diretamente. Seleciona os campos de número de cartão, validade, CVV e nome pelos respetivos atributos id, name, ou autocomplete, e lê .value diretamente do DOM.
• Associa listeners de eventos. Associa input, keyup, change, ou blur aos campos de pagamento, capturando assim cada tecla premida mesmo que o utilizador nunca chegue a submeter o formulário.
• Sequestra o caminho de submissão. Envolve o handler de submissão do formulário ou intercepta o botão "pagar", montando o payload completo no momento em que o utilizador confirma.
• Aplica patches a primitivas de rede. Skimmers avançados sobrepõem fetch, XMLHttpRequest.prototype.send, ou navigator.sendBeacon para ler o pedido de pagamento real à medida que o seu próprio código o envia.
• Sobrepõe um campo falso. Alguns injetam um iframe de pagamento contrafeito por cima do real, fazendo com que o comprador introduza os dados do cartão diretamente no input do atacante. A própria análise da cside a uma campanha Magecart encontrou uma frame de pagamento falsa inserida no checkout através de uma única linha de JavaScript ofuscado, o tipo de substituição que uma verificação do lado do servidor nunca deteta.

O fornecimento condicional é o que garante o silêncio

O skimmer não dispara para toda a gente. Filtra-se para que as pessoas com maior probabilidade de o apanhar (nomeadamente equipas de segurança, scanners e bots) nunca vejam o comportamento malicioso:

• Filtragem por caminho. Muitos skimmers só se ativam em URLs que correspondem a um padrão de checkout ou de login, ficando o código latente em todo o resto.
• Deteção de automação. A leitura de navigator.webdriver devolve true em navegadores headless e automatizados, permitindo ao skimmer servir código limpo a um scanner e o payload real a um comprador. Variantes mais avançadas procuram variáveis globais do Selenium ou fugas do Runtime do Chrome DevTools Protocol (CDP) para identificar navegadores instrumentados.
• Disparo único por sessão. Exfiltrar apenas uma vez evita ruído de rede duplicado que poderia destacar-se num log.

Essa corrida ao armamento também está a escalar do lado do atacante: o relatório de investigação Future of Web Security 2026 da cside registou um crescimento de cerca de dez vezes no playwright-stealth ao longo de 2025, automação construída para derrotar navigator.webdriver e verificações semelhantes. A mesma evasão que esconde as ferramentas de um atacante dos defensores é o que esconde um skimmer das suas. O código costuma, ainda por cima, estar ofuscado, o que enterra a intenção durante uma revisão manual.

Movimento 3: como os dados saem

A captura não serve de nada ao atacante até que os dados o alcancem. A exfiltração é um único pedido de saída a partir do navegador, e o atacante tem várias formas discretas de o enviar.

Três propriedades tornam esta fuga quase impossível de detetar do exterior. O pedido é HTTPS, pelo que é encriptado como todo o resto do seu tráfego. O destino é normalmente um domínio typosquatted ou registado recentemente que parece um fornecedor real. O skimmer da British Airways exfiltrou para baways.com, pelo que não salta à vista num log. E o payload é minúsculo e frequentemente codificado em base64, pelo que parece um ping de telemetria de rotina. De forma crítica, este pedido vai diretamente do navegador para o atacante; nunca passa pela sua origem, pelo seu WAF, ou pelo seu gateway de pagamento. É essa a razão pela qual o roubo é invisível para o servidor.

Por que motivo o seu servidor, WAF e processador nunca o veem

Junte os três movimentos e o ponto cego torna-se óbvio. O código carregou no navegador, leu o campo no navegador, e enviou a cópia do navegador para um terceiro domínio. O seu backend só viu a transação legítima e autorizada.

• Uma web application firewall inspeciona pedidos que chegam à sua origem. O pedido de exfiltração nunca chega lá, pelo que o WAF não tem nada para inspecionar.
• Um SIEM agrega logs de servidor e de infraestrutura, e o skimmer não gera qualquer evento de servidor. A monitorização de fraude sinaliza anomalias de compra, mas a compra real concluiu-se exatamente como esperado.
• Um processador de pagamentos como o Stripe ou a Adyen protege a transação que recebe. Se os campos de cartão estiverem na sua própria página, um skimmer lê-os antes de o processador sequer ser envolvido, e a sua página continua a dever a sua própria evidência de PCI DSS 4.0.1 6.4.3 e 11.6.1, independentemente do processador.

O ataque vive num runtime que a sua stack do lado do servidor não consegue alcançar. Um problema client-side precisa de uma defesa client-side.

Como a monitorização ao nível do navegador apanha cada movimento

A deteção tem de estar onde o skimmer é executado. A cside monitoriza scripts e comportamento no navegador, pelo que cada movimento deixa um sinal sobre o qual pode agir.

• Injetar aparece como um script novo ou modificado. A cside mantém um inventário de scripts e sinaliza adições, alterações, e tags de terceiros adulteradas assim que surgem, não semanas depois, num relatório de fraude.
• Capturar aparece como comportamento. Listeners inesperados em campos de pagamento, código a ler inputs que não deveria, e substituições de fetch ou sendBeacon são anomalias de runtime face a uma baseline conhecida como boa.
• Exfiltrar aparece como um destino. A cside expõe pedidos de saída para domínios que não estão na sua allowlist, o movimento característico de um skimmer a tentar sair.

Como a cside corre em navegadores reais, e não num scanner de sala limpa, o fornecimento condicional não esconde o skimmer da forma como esconde de um crawler headless. Essa mesma visibilidade produz a evidência que o PCI DSS 4.0.1 exige: um inventário autorizado dos scripts da página de pagamento para o 6.4.3, e alertas sobre alterações não autorizadas ao conteúdo e aos cabeçalhos de scripts para o 11.6.1, ambos obrigatórios desde 2025-03-31.

Leitura adicional na cside

• O que é o skimming de cartão online?
• O que é o Magecart: guia completo e estratégia de prevenção
• Formjacking vs Magecart vs digital skimming
• O que são skimmers digitais?
• Os maiores ataques Magecart da história (até agora)
• Segurança client-side da cside

Incidentes Magecart identificados (2018 a 2024)

O ecossistema Magecart é uma federação pouco coesa de, pelo menos, sete grupos distintos (numerados de Group 1 a Group 12 pela RiskIQ) que partilham TTPs. As divulgações públicas abaixo são os casos de referência que clientes e QSAs citam ao definir o âmbito dos controlos PCI DSS 4.0.1 §6.4.3 e §11.6.1.

• British Airways (2018). Cerca de 380.000 registos de cartões de pagamento exfiltrados ao longo de 15 dias a partir de um script comprometido, servido nas páginas de checkout e na aplicação móvel. A multa do ICO do Reino Unido foi reduzida de £183M para £20M.
• Ticketmaster UK (2018). Dados de cartão de ~40.000 clientes expostos depois de o script de apoio ao cliente da Inbenta, servido a partir de um CDN de terceiros, ter sido modificado para fazer skimming da página de pagamento. Multa do ICO de £1,25M.
• Newegg (2018). 15 linhas de JavaScript injetado capturaram todos os dados de cartão submetidos a checkout/payment.aspx durante 35 dias. Atribuição ao Magecart Group 4 pela RiskIQ.
• Warner Music Group (2020). Vários sites de comércio eletrónico operados pela WMG nos EUA e no Reino Unido comprometidos durante três meses, visando dados de checkout na plataforma Volusion.
• Segway (2022). Os atacantes usaram uma extensão maliciosa do Magento para fazer skimming de formulários de pagamento, divulgado pela Malwarebytes.
• Kaiser Permanente (2024). 13,4 milhões de membros notificados depois de scripts de análise e de rastreio de terceiros em páginas voltadas para membros terem exposto informação sensível, próximo da mesma classe de TTP Magecart.
• Cadeia de abastecimento Polyfill.io (2024). Após uma mudança de propriedade, cdn.polyfill.io começou a servir código malicioso a mais de 100.000 sites que incorporavam a biblioteca, divulgado pela Sansec. A Fastly, a Cloudflare e a Google intervieram ao nível da rede.
• Adobe Commerce / Magento Cosmicsting (CVE-2024-34102). Falha de desserialização de XML no servidor, usada para instalar skimmers do lado do cliente em centenas de comerciantes Magento ao longo de 2024 e até 2025.

Todos os casos acima contornaram as defesas do lado do servidor do comerciante e manipularam código executado pelo navegador. É exatamente essa a lacuna que o PCI DSS 6.4.3 (autorização e integridade de scripts) e o 11.6.1 (deteção de alterações na página de pagamento) foram escritos para fechar.

Leituras relacionadas

• Como o Polyfill.io atingiu 490 mil sites (ataque à cadeia de abastecimento do navegador)
• O que é formjacking?
• Skimming de cartão de crédito online
• Plataformas de monitorização de scripts de terceiros: as 5 melhores opções comparadas