Magecart é web skimming que roda dentro do navegador. JavaScript malicioso pousa em uma página de checkout ou login, lê o que o visitante digita no formulário, e envia uma cópia para um servidor controlado pelo atacante. O pagamento legítimo ainda passa, então dos seus servidores parece um dia normal de transações limpas. Tudo parece bem enquanto dados de cartão estão saindo, e essa lacuna é o problema todo.
Este post explica a mecânica para alguém que encontra a ameaça pela primeira vez. Não é uma política de prevenção nem a taxonomia formjacking-versus-Magecart. Ele percorre a sequência real: como o código entra, como ele captura os dados, e como sai. Entenda esses três movimentos e você entende por que um web application firewall, um SIEM, e um processador de pagamentos podem estar todos no verde enquanto um skimmer roda. cside monitora essa camada do navegador diretamente, observando cada script conforme ele executa e sinalizando o momento em que um começa a ler campos ou chamar um domínio que nunca tocou antes, o que é a base para detectar o Magecart em tempo real em vez de após a violação.
O ataque em três movimentos
Toda campanha de skimming, independentemente de qual grupo a execute, se resume ao mesmo ciclo. Tire a marca e você tem três movimentos.
| Movimento | O que acontece | Onde vive |
|---|---|---|
| Injetar | O atacante faz seu JavaScript carregar na sua página | Um arquivo first-party comprometido, uma tag de terceiros, ou um tag manager |
| Capturar | O script lê dados de cartão ou credenciais do formulário | O DOM e os event listeners de formulário no navegador |
| Exfiltrar | Uma cópia dos dados é enviada ao servidor do atacante | Uma requisição de saída do navegador para um domínio do atacante |
O restante deste post percorre cada movimento em ordem, porque a ordem é o que torna o ataque invisível.
Movimento 1: como o código chega à página
O atacante precisa que seu JavaScript execute no navegador do visitante. Ele tem três rotas comuns para a página, nenhuma das quais exige tocar na lógica do seu servidor de origem.
- Um arquivo self-hosted. Eles obtêm acesso de escrita através de um plugin vulnerável, um CMS desatualizado, ou um login de admin roubado, e então adicionam algumas linhas a um arquivo JavaScript que você já serve. A mudança é pequena e frequentemente escondida dentro de código legítimo, então um diff parece insignificante.
- Um script de terceiros. Eles comprometem um vendor cujo script você carrega diretamente com
<script src>, como um widget de analytics, chat, ou testes A/B. Agora o skimmer é entregue do domínio do vendor para todo cliente que carrega sua página, e nunca está no seu repositório para ser encontrado, e é por isso que proteger scripts de terceiros é uma disciplina por si só. - Um tag manager. Eles assumem o controle de um contêiner do Google Tag Manager ou similar e adicionam uma tag contendo o skimmer. Todo site e página que usa aquele contêiner agora roda o código, incluindo páginas de checkout onde a tag não tem negócio de carregar.
As rotas de terceiros e tag manager escalam, o que as torna as perigosas. Um vendor comprometido semeia skimmers em todo site que confia nele, e um script que você aprovou pode puxar outro script que você nunca revisou, o problema de quarta parte. É esse formato de cadeia de suprimentos que os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 miram ao exigir um inventário e autorização de cada script em uma página de pagamento. O vazamento da Ticketmaster em 2018 seguiu exatamente esse caminho: o skimmer chegou ao checkout através do script de chatbot de um fornecedor comprometido, não do código próprio da Ticketmaster (resumo na Wikipédia do incidente de 2018).
Movimento 2: como o skimmer lê seu formulário
Uma vez que o script roda, ler o formulário é desenvolvimento web comum voltado contra você. Ler e modificar o DOM é como todo framework moderno funciona, então as ações do skimmer parecem comportamento normal de página. Um skimmer tipicamente faz um ou mais dos seguintes:
- Lê valores de input diretamente. Ele seleciona os campos de número do cartão, validade, CVV e nome pelos seus atributos
id,name, ouautocompletee lê.valuedireto do DOM. - Anexa event listeners. Ele engancha
input,keyup,change, oublurnos campos de pagamento, então captura cada tecla mesmo que o usuário nunca envie o formulário. - Sequestra o caminho de submit. Ele envolve o handler de submit do formulário ou engancha o botão "pagar", montando o payload completo no momento em que o usuário confirma.
- Patches primitivas de rede. Skimmers avançados sobrescrevem
fetch,XMLHttpRequest.prototype.send, ounavigator.sendBeaconpara ler a requisição de pagamento real conforme seu próprio código a envia. - Sobreponhe um campo falso. Alguns injetam um iframe de pagamento falsificado sobre o real, então o comprador digita os dados do cartão direto no input do atacante. A própria análise da cside de uma campanha Magecart encontrou um frame de pagamento falso inserido no checkout por uma única linha ofuscada de JavaScript, o tipo de troca que um scan do lado do servidor nunca vê.
Serving condicional é o que o mantém silencioso
O skimmer não dispara para todo mundo. Ele se filtra para que as pessoas com maior probabilidade de pegá-lo, ou seja, equipes de segurança, scanners e bots, nunca vejam o comportamento malicioso:
- Filtragem por caminho. Muitos skimmers só se armam em URLs que correspondem a um padrão de checkout ou login, então o código permanece dormente em todo o resto.
- Detecção de automação. Ler
navigator.webdriverretornatrueem navegadores headless e automatizados, então o skimmer pode servir código limpo a um scanner e o payload real a um comprador. Variantes mais avançadas sondam por globais do Selenium ou vazamentosRuntimedo Chrome DevTools Protocol (CDP) para identificar navegadores instrumentados. - Disparo uma vez por sessão. Exfiltrar uma única vez evita ruído de rede duplicado que poderia se destacar em um log.
Essa corrida armamentista também está escalando do lado do atacante: o relatório de pesquisa Future of Web Security 2026 da cside rastreou o playwright-stealth crescendo cerca de dez vezes ao longo de 2025, automação construída para derrotar navigator.webdriver e checagens similares. A mesma evasão que esconde o tooling de um atacante dos defensores é o que esconde um skimmer do seu. O código geralmente é ofuscado além de tudo isso, o que enterra a intenção durante uma revisão manual.
Movimento 3: como os dados saem
A captura é inútil para o atacante até que os dados o alcancem. Exfiltração é uma única requisição de saída do navegador, e o atacante tem várias formas silenciosas de enviá-la.
| Método | Como aparece no tráfego |
|---|---|
navigator.sendBeacon() | Um pequeno POST que dispara de forma confiável no unload, projetado para analytics, então se mistura |
fetch() / XMLHttpRequest | Uma requisição assíncrona padrão, frequentemente para um domínio parecido que imita um CDN ou host de analytics |
| Requisição de imagem | O payload é anexado ao src de um <img> como query string; o navegador "carrega" uma imagem que na verdade é um drop de dados |
| WebSocket | Um canal persistente para transmitir teclas capturadas quase em tempo real |
Três propriedades tornam esse vazamento quase impossível de perceber de fora. A requisição é HTTPS, então é criptografada como todo o resto do seu tráfego. O destino é geralmente um domínio typosquatted ou recém-registrado que parece um vendor real. O skimmer da British Airways exfiltrou para baways.com, então não salta de um log. E o payload é minúsculo e frequentemente codificado em base64, então parece um ping rotineiro de telemetria. Criticamente, essa requisição vai do navegador direto para o atacante; ela nunca passa pela sua origem, seu WAF, ou seu gateway de pagamento. É essa a razão pela qual o roubo é invisível para o servidor.
Por que seu servidor, WAF e processador nunca o veem
Junte os três movimentos e o ponto cego é óbvio. O código carregou no navegador, leu o campo no navegador, e enviou a cópia do navegador para um terceiro domínio. Seu backend só viu a transação legítima e autorizada.
- Um web application firewall inspeciona requisições que chegam à sua origem. A requisição de exfiltração nunca chega lá, então o WAF não tem nada para inspecionar.
- Um SIEM agrega logs de servidor e infraestrutura, e o skimmer não gera evento de servidor. Monitoramento de fraude sinaliza anomalias de compra, mas a compra real foi concluída exatamente como esperado.
- Um processador de pagamentos como Stripe ou Adyen protege a transação que recebe. Se seus campos de cartão estão na sua própria página, um skimmer os lê antes que o processador sequer seja envolvido, e sua página ainda deve sua própria evidência de PCI DSS 4.0.1 6.4.3 e 11.6.1 independentemente do processador.
O ataque vive em um runtime que sua stack do lado do servidor não consegue alcançar. Um problema client-side precisa de uma defesa client-side.
Como o monitoramento da camada do navegador captura cada movimento
A detecção precisa estar onde o skimmer roda. cside monitora scripts e comportamento no navegador, então cada movimento deixa um sinal sobre o qual ele pode agir.
- Injetar aparece como um script novo ou modificado. cside mantém um inventário de scripts e sinaliza adições, mudanças, e tags de terceiros adulteradas quando elas aparecem, não semanas depois em um relatório de fraude.
- Capturar aparece como comportamento. Listeners inesperados em campos de pagamento, código lendo inputs que não deveria, e overrides de
fetchousendBeaconsão anomalias de runtime contra uma baseline conhecida como boa. - Exfiltrar aparece como um destino. cside expõe requisições de saída para domínios que não estão na sua allowlist, o movimento característico de um skimmer tentando sair.
Como cside roda em navegadores reais em vez de um scanner de sala limpa, serving condicional não esconde o skimmer da forma que o esconde de um crawler headless. Essa mesma visibilidade produz a evidência que o PCI DSS 4.0.1 espera: um inventário autorizado de scripts da página de pagamento para o 6.4.3, e alertas sobre mudanças não autorizadas no conteúdo e cabeçalhos de scripts para o 11.6.1, ambos obrigatórios desde 2025-03-31.
