TL;DR: Ataques Magecart
- O que é um ataque Magecart: Um ataque Magecart é um ataque de web skimming baseado no navegador, no qual JavaScript malicioso é injetado em um site com o objetivo de roubar dados de cartão de pagamento ou entradas sensíveis de formulários diretamente do navegador do usuário durante o checkout ou login.
- Por que ataques Magecart são difíceis de detectar: O Magecart opera inteiramente no navegador, então defesas tradicionais como WAFs, SIEMs e monitoramento de transações não identificam nada fora do comum enquanto os pagamentos legítimos continuam sendo processados normalmente.
- Como prevenir ataques Magecart: Uma prevenção eficaz exige minimizar scripts nas páginas de checkout, governar e monitorar JavaScript de terceiros, aplicar controles de navegador como CSP e SRI, e implantar uma ferramenta de monitoramento client-side contínuo como o cside.
"Fui notificado recentemente sobre uma violação de dados na sua loja e meu cartão de crédito foi usado de forma indevida."
Isso é um pesadelo para o suporte ao cliente. E não é só isso: suas equipes de fraude e financeiro também estão recebendo alertas de emissores de cartão e questionamentos de provedores de pagamento.
O Magecart não se trata de falsificar páginas de login ou pagamento. Trata-se do abuso das suas páginas reais de login e checkout — aquelas em que seus clientes confiam.
É isso que é o Magecart: o que acontece quando o seu login e checkout se tornam o elo mais fraco nos seus controles de segurança. Mesmo que seus servidores, WAF e controles de PCI estejam sólidos, algumas linhas de JavaScript malicioso no navegador podem capturar dados de cartão e PII por semanas antes que alguém perceba.
Este guia explica o que é o Magecart, como ele funciona, por que é difícil de detectar e quais são as ferramentas para prevenção de Magecart.
O que é um ataque Magecart?
Um ataque Magecart é um ataque de web skimming baseado no navegador. JavaScript malicioso é injetado em um site de e-commerce com um único objetivo: roubar dados de cartão de pagamento.
Não é algo que você deseja para si mesmo nem para seus clientes. É um pesadelo para lojas online porque abusa da confiança dos seus clientes. Causa grandes prejuízos ao negócio online: perdas financeiras, chargebacks, multas regulatórias e sérios danos à reputação.
Seu WAF e sua stack de segurança server-side não vão detectar nada disso. O ataque acontece inteiramente no navegador do usuário, em um ambiente de código que o monitoramento do seu backend nunca alcança. Mesmo outros controles relacionados ao PCI DSS, como criptografia ou tokenização, não têm valor se o atacante rouba os dados do cartão antes que essas defesas entrem em ação. As transações do seu lado continuam sendo processadas normalmente, como se nada estivesse errado. Da sua perspectiva, parece business as usual. Mas enquanto isso, os dados são silenciosamente exfiltrados do navegador do seu cliente para os servidores do atacante.
Magecart é um tipo de Web Skimming
Magecart é uma forma de web skimming (ou e-skimming). O web skimming é a versão online da clonagem de cartão de crédito em caixas eletrônicos: teclas digitadas ou entradas são copiadas por dispositivos ocultos e usadas posteriormente para gastar dinheiro em outro lugar. Quando os atacantes adicionam seu JavaScript malicioso a uma loja online, isso abre muitas oportunidades para eles. Eles conseguem ver o que um usuário digita em formulários de pagamento ou login e exfiltram esses dados secretamente para seus próprios sistemas.
Como o termo "Magecart" evoluiu
Por volta de 2015-2016, pesquisadores de segurança começaram a reportar que lojas online baseadas em Magento estavam sendo alvo de ataques de clonagem de cartão online. Tipicamente, JavaScript era injetado nas páginas de checkout para roubar e exfiltrar dados de pagamento e PII. Daí surgiu o nome: 'Magecart' — 'Mage' de Magento e 'cart' — abreviação de carrinho de compras (shopping cart).
Com o tempo, os ataques Magecart se espalharam para outras plataformas e configurações de e-commerce personalizadas. Qualquer plataforma com JavaScript client-side e scripts de terceiros era vulnerável, não apenas o Magento.
Do card skimming no Magento aos ataques estilo Magecart em todo lugar
O Magecart evoluiu para um estilo de ataque: um rótulo para digital skimming, formjacking, e-skimming, clonagem de cartão online, e se tornou uma ameaça importante para plataformas de varejo online.
Magecart é menos um apelido para um grupo específico e mais um rótulo abrangente para um ecossistema de grupos e técnicas de digital skimming. De forma geral, eles usam o mesmo vetor de ataque, mas dependem de infraestrutura e ferramentas diferentes.
Como funcionam os ataques Magecart
A ideia parece simples: copiar dados de formulário e exfiltrá-los para um endpoint comprometido. Parece fácil, não é? Na prática, esses ataques são mais sutis e sofisticados. A todo momento, a loja online precisa se comportar como esperado: sem erros, sem timeouts.
Para que o digital skimming seja bem-sucedido, nem seus sistemas de monitoramento nem seus clientes podem perceber nada fora do comum.
Veja como um ataque Magecart típico se desenrola no navegador.
1. Injeção de JavaScript malicioso no site
Primeiro, o atacante precisa de uma forma de executar seu próprio JavaScript no navegador do usuário, pois é lá que o ataque acontece. Ele busca vulnerabilidades como plugins ou componentes de CMS desatualizados ou mal configurados, ou scripts de terceiros negligenciados, como um plugin, arquivos de CDN, tag manager, entre outros.
Esse ponto fraco se torna o vetor de ataque: o atacante adiciona algumas linhas do seu JavaScript malicioso a um arquivo de produção existente ou a um script de terceiros. A alteração é mínima, muitas vezes misturada com código legítimo, então nada chama atenção durante uma revisão de segurança.
2. Leitura dos dados de pagamento e formulários
Feito isso, o JavaScript malicioso acessa o DOM e lê os dados que o usuário inseriu no formulário. JavaScript acessando e modificando o DOM é um comportamento normal no desenvolvimento web moderno. É assim que o JavaScript torna as páginas dinâmicas sem recarregar o documento HTML completo. Muitos frameworks como React ou Svelte dependem do fato de que o JavaScript pode manipular o DOM.
O digital skimmer agora foca em campos específicos do formulário de pagamento ou login: número do cartão, data de validade, CVV, nome, endereço e assim por diante. Ele copia esses valores sem alterar o formulário ou o fluxo do usuário de nenhuma forma visível.
3. Exfiltração dos dados para o servidor do atacante
Após capturar os dados, o próximo passo é transferi-los sem ser detectado para um servidor controlado pelo atacante. Na maioria das vezes, o gatilho para a exfiltração é o usuário clicar no botão 'pagar'/'enviar'. Nesse momento, o script monta o payload (bruto ou codificado) com os detalhes do cartão, PII e, frequentemente, informações de contexto como timestamps ou URLs.
As técnicas de exfiltração mais comuns incluem fetch, XMLHttpRequest para código mais antigo, requisições de imagem ocultas e navigator.sendBeacon(). TLS/HTTPS não impede a exfiltração porque ela parece uma requisição https legítima, com um payload muito pequeno. Os atacantes frequentemente usam domínios muito parecidos com os hostnames legítimos usados por lojas online, CDNs ou ferramentas de analytics para não levantar suspeitas. Se a requisição de exfiltração falhar, o código simplesmente captura o erro e não executa. Mas a transação legítima é processada normalmente.
4. Mantendo a loja funcionando e os pedidos sendo processados
Para que o ataque Magecart seja eficaz, as transações precisam continuar fluindo. O skimmer exfiltra uma cópia dos dados, mas o formulário de pagamento também é enviado para o seu backend e gateway de pagamento. Pedidos são criados, pagamentos são autorizados e seus sistemas de fulfillment entram em ação.
Como os Atacantes Obtêm Acesso aos Scripts Web para Ataques Magecart
Os atacantes varrem sua stack web em busca de pontos fracos: lugares onde scripts podem ser editados e código de skimming pode se infiltrar. Para defender seu site e construir um modelo de ameaça eficaz, você precisa conhecer os vetores de entrada mais comuns para ataques Magecart.
1. Magecart via Plugins, CMS ou código da plataforma de e-commerce
Seu próprio CMS ou plataforma de e-commerce é uma superfície de ataque direta. Plataformas como Magento, WooCommerce, apps do Shopify e código de checkout personalizado precisam de escrutínio regular. Os pontos fracos típicos são plugins e extensões desatualizados, ou edições inseguras em templates ou arquivos JavaScript. Contas de administrador precisam de proteção extra: se um atacante conseguir fazer login como administrador, alterar scripts se torna fácil.
Se sua loja online está rodando um plugin de pagamento ou rastreamento desatualizado no Magento ou WooCommerce, o digital skimming está a um passo de distância. Se os atacantes conseguirem modificar os arquivos do plugin ou abusar de uma conta de administrador, basta editar um único arquivo JavaScript na página de checkout para adicionar o skimmer.
2. Magecart via cadeia de fornecimento de código de terceiros
Isso inclui qualquer entrada via <script src> ou um tag manager: bibliotecas de CDN, ferramentas de A/B testing ou analytics para o time de marketing, widget de chat/suporte para o atendimento ao cliente e assim por diante. Esses scripts são gerenciados e hospedados por fornecedores externos ou injetados via tag managers que podem executar código na maioria das páginas. Basta um único script de terceiros comprometido ou uma conta de tag manager abusada para espalhar código de skimmer para todos os sites e páginas onde esse código é utilizado.
Às vezes, uma conta do Google Tag Manager (GTM) ou um widget de chat externo tem código que carrega em todo o site (incluindo páginas de checkout), mesmo que não tenha nenhuma funcionalidade nessas páginas. Se o GTM for comprometido e uma tag extra com código JavaScript de skimmer for adicionada, todo formulário de checkout em todo site que usa o container estará executando código Magecart.
Por que ataques Magecart são difíceis de detectar
Agora que vimos como um ataque Magecart funciona no navegador, é justo perguntar: por que as defesas tradicionais não detectam isso? Temos regras de WAF, dashboards de SIEM e controles de PCI. Mesmo assim, essas camadas de segurança ainda têm um ponto cego para ataques client-side baseados no navegador, como o Magecart.
1. WAF, SIEM e dados de transação não detectam ataques Magecart
A maioria das ferramentas de segurança web foi projetada para proteger atividades server-side ou monitorar a infraestrutura da empresa, não o navegador dos usuários. Um WAF inspeciona o tráfego para suas aplicações, mas não vê o que o navegador envia diretamente para outros domínios. Um SIEM exibe logs de servidor e infraestrutura, mas não registra chamadas de saída extras do navegador para endpoints maliciosos.
Analisar dados de transação em busca de fraude não vai revelar evidências de um ataque Magecart porque o fluxo de compra legítimo ainda é concluído normalmente. O skimmer copia os detalhes do cartão no navegador enquanto o backend registra uma transação limpa e autorizada, sem nenhuma anomalia.
Atacantes experientes conseguem interceptar valores sensíveis no nível do DOM antes que eles sejam enviados para seus servidores, efetivamente silenciando seus sistemas de alerta.
2. Falta de visibilidade sobre scripts de terceiros aumenta o risco de Magecart
Ter visibilidade total sobre scripts de terceiros é um grande desafio. Quais scripts estão rodando? Eles têm permissão para rodar em um formulário de checkout ou página de login? Quem está acompanhando o comportamento e as alterações deles ao longo do tempo? Perguntas muito básicas com as quais muitas organizações têm dificuldade quando ninguém é realmente responsável pela cadeia de fornecimento client-side.
Desenvolvedores web têm controle limitado sobre esses scripts, pois eles são gerenciados e hospedados por fornecedores externos. Quando a propriedade muda ou funcionários são demitidos, scripts de terceiros ou bibliotecas JavaScript podem deixar de ser atualizados, e uma vulnerabilidade em qualquer um desses scripts pode se tornar um risco de segurança.
Esse é exatamente o vetor de entrada que os ataques Magecart exploram. Comprometer um script ou biblioteca de terceiros amplamente utilizado pode transformá-lo em um ataque de supply chain em larga escala, afetando todos os sites que o utilizam.
3. Um problema client-side exige uma defesa client-side
Esse é o problema central do Magecart: a maioria das empresas não tem visibilidade real do que acontece no navegador. Dashboards de segurança server-side não mostram para quais domínios o navegador está enviando requisições durante o checkout, mesmo quando se trata de chamadas cross-origin (CORS).
Eles não alertam quando um novo domínio de saída aparece em um formulário de pagamento. E não enviam um aviso sobre uma violação de Content Security Policy (connect-src) quando um script está tentando exfiltrar dados para um endpoint inesperado.
4. A fraude só é descoberta depois, muito depois
Um dos aspectos mais prejudiciais de um ataque Magecart é que raramente é detectado pela própria organização que foi violada. Na maioria dos casos, os primeiros sinais de problema vêm de bancos, emissores de cartão ou clientes. Quando esses relatórios externos chegam, o skimmer já coletou um volume significativo de dados de titulares de cartão.
Como prevenir ataques Magecart
Os princípios fundamentais da prevenção de Magecart são diretos: mantenha seu fluxo de checkout o mais limpo e enxuto possível, mantenha o controle dos scripts que rodam nele e adicione controles no navegador com monitoramento contínuo 24/7. Os passos lógicos a seguir vão ajudá-lo a implementar medidas de prevenção para reduzir sua exposição ao Magecart.
1. Execute apenas os scripts necessários no login e checkout
No login e no checkout, cada script extra adiciona risco. Essas páginas devem carregar apenas o básico de UX e o estritamente necessário para autenticação e pagamento. Sem hesitação, remova marketing, analytics, widgets de chat e similares do login e do checkout.
De preferência, isole o checkout e use um template minimalista ou até mesmo um subdomínio separado com apenas os inputs de terceiros necessários. Ao fazer isso, você limita sua superfície de ataque e as oportunidades para o código Magecart se camuflar. Além disso, será muito mais fácil fazer a limpeza se algo der errado.
2. Use o cside para governança de scripts de terceiros
Crie um inventário de scripts para ter uma visão clara de quais scripts rodam onde e o que eles realmente fazem. Páginas sensíveis, incluindo login e checkout, devem servir apenas scripts de terceiros que foram aprovados com uma justificativa.
Por fim, defina um processo de gestão de mudanças para especificar quem tem permissão para modificar scripts e containers de tag manager. Você também pode exigir previews e aprovação antes que as alterações entrem em produção. Em paralelo, aplique uma governança rigorosa de fornecedores e inclua segurança de scripts e tratamento de incidentes nos contratos e no onboarding de provedores externos.
Uma ferramenta de governança de scripts de terceiros pode automatizar esses elementos instantaneamente com um dashboard que associa cada script a um fornecedor e gera automaticamente descrições do que cada script está fazendo.
3. Use controles de navegador: CSP e SRI
Uma Content Security Policy (CSP) ajuda você a definir de onde os scripts têm permissão para carregar (script-src) e para onde o navegador tem permissão para enviar dados (connect-src).
script-src deve ser restrito a domínios confiáveis e connect-src deve permitir apenas os endpoints necessários para o checkout, em vez de liberar qualquer destino.
Habilitar uma CSP também ajuda no reporte de violações de política, especialmente no login e checkout. Tentativas inesperadas de injeção de script e exfiltração serão reveladas. Para bibliotecas de terceiros estáticas, use Subresource Integrity (SRI) para reforçar a integridade, mas trate isso como uma camada da sua defesa, não como a solução definitiva.
4. Use o cside para monitoramento de Magecart
Com o Magecart, você precisa de visibilidade dentro do navegador. O monitoramento client-side automatizado e contínuo, 24/7, vai revelar quais scripts estão rodando e comportamentos suspeitos que sinalizam atividade de Magecart. Uma ferramenta de prevenção de Magecart mapeia todos os scripts do seu site e usa um motor assistido por IA para detectar sinais de alerta a partir de uma variedade de pontos de dados.
O cside ajuda merchants a identificar e bloquear:
- Ataques de supply chain via JavaScript de terceiros
- Scripts de terceiros maliciosos ou adulterados
- Scripts mal configurados que vazam dados sensíveis
- Magecart, e-skimming, formjacking e skimmers relacionados
O cside é validado para os requisitos client-side do PCI DSS 4.0.1 e é usado por equipes de compliance para prevenir violações de GDPR, CCPA e outras regulamentações de privacidade causadas por scripts de terceiros arriscados.
Autoavaliação rápida de prontidão contra Magecart
Você está preparado para se defender de ataques estilo Magecart? Sim/Não
- Nossas páginas de checkout e login carregam apenas scripts cujo propósito e comportamento esperado conhecemos
- Temos uma lista atualizada de todos os scripts, próprios e de terceiros, que rodam na nossa página de checkout
- Marketing, analytics, A/B testing e widgets de chat são monitorados para garantir que não estejam coletando mais dados do que o necessário
- Alterações em scripts 'confiáveis', como containers de tag manager, são controladas…
- Estamos verificando a integridade dos scripts por meio de uma ferramenta de segurança client-side ou outro mecanismo (como Sub Resource Integrity)
- Temos monitoramento client-side que mostra para onde os dados coletados por scripts de terceiros estão sendo enviados
- Temos um mecanismo para bloquear scripts que foram publicamente identificados como comprometidos
Os maiores ataques Magecart da história recente
Nosso relatório de ameaças client-side de 2025 identificou mais de 72.000 sites impactados por ataques client-side. Esses ataques seguem o mesmo padrão dos maiores ataques Magecart da história recente: algumas linhas de JavaScript malicioso comprometem milhões de usuários antes que alguém perceba. Abaixo está um resumo rápido dos casos mais notáveis.
- Ticketmaster (2018) – Script de Chatbot Comprometido Atacantes injetaram código de skimming em um chatbot de terceiros hospedado pela Inbenta Technologies. Cada carregamento de página executava o script malicioso, expondo dados de pagamento e pessoais de aproximadamente 9,4 milhões de clientes ao longo de quatro meses. O incidente resultou em multas regulatórias e acordos em ações coletivas.
- British Airways (2018) – 22 Linhas de JavaScript Malicioso Atacantes obtiveram acesso usando credenciais de terceiros comprometidas e inseriram apenas 22 linhas de código de skimmer em uma biblioteca usada na página de pagamento da BA. Os dados foram exfiltrados para um domínio semelhante ao legítimo ("baways.com"), afetando cerca de 400.000 clientes. A BA enfrentou dezenas de milhões em multas de GDPR e anos de litígio.
- Newegg (2019) – Script Injetado na Página de Checkout Atacantes obtiveram acesso de escrita ao servidor de pagamento da Newegg e adicionaram um pequeno skimmer ao botão de checkout. Quando os clientes enviavam o pagamento, os dados do cartão eram enviados para um domínio falso de analytics ("neweggstats.com"), comprometendo números de cartão, CVVs e PII por mais de um mês antes da detecção.
FAQ
Como saber se meu site está infectado por Magecart ou e-skimming?
Ataques Magecart são difíceis de detectar porque o checkout continua funcionando normalmente e as ferramentas server-side não identificam nada fora do comum. O único método confiável é o monitoramento client-side com uma ferramenta como o cside, que inspeciona os scripts em execução no navegador e sinaliza alterações suspeitas no código ou transferências de dados para fora.
Ataques Magecart podem ocorrer mesmo usando um processador de pagamento como Stripe ou PayPal?
Sim. Se os campos do seu checkout estão hospedados no seu próprio site (mesmo usando um processador de pagamento terceirizado), scripts de terceiros na sua página ainda podem acessar o que os usuários digitam nesses campos. Se o seu site redireciona completamente os clientes para o domínio do provedor de pagamento (por exemplo, checkout.stripe.com), o Magecart não consegue capturar dados de cartão nesse ponto. No entanto, outras informações sensíveis do seu site, como credenciais de login, dados de KYC ou detalhes de conta, ainda podem ser coletadas se scripts maliciosos estiverem presentes.
Um ataque Magecart pode ocorrer mesmo se eu tokenizar ou criptografar os dados do cartão de crédito?
Sim. A tokenização e a criptografia só acontecem depois que o cliente envia o pagamento, mas o Magecart rouba os dados enquanto o usuário ainda está digitando. Mesmo fluxos totalmente tokenizados ou criptografados continuam vulneráveis ao skimming se scripts maliciosos estiverem rodando na página.
