Descoberta e escopo da campanha
Uma operação sofisticada e de longa duração do grupo Magecart foi descoberta por pesquisadores de segurança da ANY.RUN, operando silenciosamente por mais de 24 meses. A campanha infectou sites de e-commerce em pelo menos 12 países, utilizando mais de 100 domínios maliciosos para roubar dados de cartões de pagamento em tempo real. A infraestrutura da campanha abrange uma quantidade de domínios que reflete um nível de investimento e planejamento mais consistente com o cibercrime organizado do que com o skimming oportunista.
Os pesquisadores identificaram 17 sites WooCommerce confirmados infectados entre fevereiro de 2024 e abril de 2025. As vítimas foram identificadas no Reino Unido, Dinamarca, França, Espanha e Estados Unidos, com uma concentração notável na Espanha, diretamente ligada ao abuso do ecossistema de pagamento Redsys pela campanha.
Como o ataque se desenrola
A operação emprega uma cadeia de infecção em camadas e múltiplas etapas, projetada para frustrar a detecção e a remoção. Após comprometer um site WooCommerce, os atacantes injetam um carregador JavaScript ofuscado pequeno em um dos arquivos de script existentes do site. Este carregador não contém lógica de roubo de cartões por si só; ele se comunica silenciosamente com a infraestrutura externa, recupera um payload de configuração JSON (codificado como matrizes de caracteres numéricos) e busca a próxima etapa maliciosa dinamicamente.
O carregador também possui um mecanismo de fallback: se um domínio de staging estiver inacessível ou bloqueado, ele automaticamente percorre uma lista de domínios de backup até receber uma resposta válida. Este design garante que a campanha continue operando mesmo quando componentes individuais são derrubados, uma razão chave pela qual a operação permaneceu indetectada por mais de dois anos.
Vetor e exploração
O payload de segunda etapa é entregue de domínios criados para se assemelhar a serviços web legítimos, incluindo bibliotecas jQuery falsas, recursos de CDN e plataformas de análise como jquerybootstrap[.]com, newassetspro[.]com e assetsbundle[.]com. Uma vez carregado, o script malicioso aguarda o aparecimento da página de checkout e sequestra a interface de pagamento, substituindo ou sobrepondo inteiramente o formulário de pagamento legítimo com um falso convincente.
A técnica mais eficaz da campanha é a imitação de alta fidelidade de provedores de serviços de pagamento confiáveis. A variante mais documentada imita de perto o Redsys, um processador de pagamento amplamente utilizado na Espanha, incorporando o domínio legítimo do Redsys sis.redsys.es no fluxo de ataque para adicionar credibilidade. Interfaces do PayPlug SAS também foram replicadas.
Exfiltração de dados e WebSocket
Uma vez que uma vítima insere os detalhes do cartão no formulário falsificado, o payload transmite os dados, incluindo BIN, número completo do cartão, data de expiração e CVV. Diferente de uma solicitação HTTP POST padrão, os dados são transmitidos através de um canal WebSocket criptografado. O servidor de comando e controle em um caso documentado foi disfarçado como um domínio Redsys (redsysgate[.]com).
Este método de exfiltração é escolhido deliberadamente: o tráfego WebSocket é frequentemente ignorado por ferramentas de monitoramento de segurança baseadas em HTTP convencionais, reduzindo a chance de detecção em tempo real. A interface de pagamento falsificada suporta vários idiomas (inglês, espanhol, árabe e francês), indicando uma estratégia de direcionamento deliberada e globalmente orientada.
Expansão para vetores móveis
Em uma expansão notável da superfície de ataque, o mesmo payload malicioso também serviu como mecanismo de entrega para arquivos APK do Android. Quando usuários acessaram lojas infectadas em dispositivos móveis, o script exibia um prompt oferecendo descontos ou bônus em troca do download de um aplicativo, completo com instruções para habilitar a instalação de "Fontes Desconhecidas". Este vetor móvel foi localizado em pelo menos quatro idiomas, reforçando que a infraestrutura da campanha foi construída com propósito, não improvisada.
Medidas de mitigação recomendadas
Para equipes de segurança, as prioridades defensivas chave incluem monitorar conexões WebSocket de saída de páginas de checkout, aplicar políticas de segurança de conteúdo (CSP) estritas, implementar monitoramento de integridade de arquivos JavaScript e realizar auditorias regulares de scripts de terceiros. Para instituições financeiras, o compartilhamento proativo de inteligência de ameaças e a detecção aprimorada de fraude para transações sem cartão permanecem contra-medidas críticas contra esta classe de ameaça de pagamento persistente e adaptativa.
Impacto e alcance
Embora os comerciantes de e-commerce sejam os alvos iniciais de acesso, o dano financeiro primário recai sobre os bancos e os titulares de cartões. Os dados de cartão roubados alimentam perdas de fraude a jusante e erodem a confiança do consumidor nos sistemas de pagamento digital, pressões que as instituições financeiras absorvem muito tempo após o skimmer ser removido.
O que os CISOs devem fazer imediatamente
Os CISOs devem revisar imediatamente as políticas de CSP de seus sites de e-commerce e garantir que não haja scripts de terceiros não autorizados. A implementação de monitoramento de integridade de arquivos é crucial para detectar injecções de JavaScript. Além disso, a análise de tráfego de saída deve incluir a inspeção de conexões WebSocket para identificar exfiltração de dados de pagamento.