Campanha de skimming em Magento infeta 953 lojas com código que escapa aos scanners
Uma operação criminosa que desde meados de 2025 planta discretamente JavaScript malicioso em lojas Magento chegou já a 953 lojas online e continua ativa. O que distingue esta campanha não é tanto a escala como a técnica: o código injetado decide, em cada carregamento de página, se o visitante é um comprador humano ou um scanner automatizado, e só entrega a carga maliciosa a humanos.
O que aconteceu
Os atacantes guardam um pequeno loader dentro da base de dados do Magento, e não num ficheiro de tema ou de módulo. Fica na tabela cms_block, onde o Magento armazena os blocos de conteúdo estático apresentados nas páginas da loja. Como o loader faz parte do conteúdo normal da página, sobrevive às verificações de integridade de ficheiros e aos redeploys que só analisam o código.
Antes de fazer o que quer que seja, o loader contacta um servidor de distribuição de tráfego e pergunta se o visitante atual deve receber o script verdadeiro. Os compradores legítimos recebem a carga de skimming; tudo o que se pareça com um crawler, um browser headless ou um scanner de segurança recebe, em vez disso, uma instrução inofensiva que não faz nada. Um lojista que execute uma análise externa rápida verá muitas vezes um resultado limpo numa loja já comprometida.
O grupo roda a sua infraestrutura de poucos em poucos meses. O domínio em uso desde outubro de 2026 foi encontrado nos blocos de conteúdo de 83 lojas. Destas, 60 já tinham executado um loader mais antigo dos mesmos operadores e 34 estavam infetadas de forma intermitente desde outubro de 2025. Por outras palavras, muitos comerciantes já tinham sido atingidos, "limparam" o script visível e voltaram a ser infetados porque o acesso subjacente nunca foi removido.
O próprio loader evoluiu. A versão inicial lia um valor guardado chamado fpCode no armazenamento do browser do visitante e voltava a executá-lo em páginas seguintes, o que mantinha o skimmer vivo mesmo quando o domínio do atacante estava offline. No final de outubro, os operadores reescreveram-no para enviar uma impressão digital completa do browser ao servidor: verifica marcadores de automação como navigator.webdriver, variáveis globais do Selenium e propriedades do ChromeDriver, e recolhe o nome da GPU, o tamanho do ecrã e o fuso horário para distinguir browsers reais de ambientes de teste.
Como as lojas foram comprometidas
Trata-se de uma injeção ao estilo Magecart, e o acesso inicial veio sobretudo de falhas de upload de ficheiros no Magento. Em março de 2026, o grupo injetou o loader em 471 lojas numa única hora depois de colocar web shells através do PolyShell, a vulnerabilidade de upload de ficheiros sem restrições identificada como CVE-2026-48356.
O loader foi também encontrado em 169 instalações de Magento 2 às quais faltava pelo menos um patch de segurança do núcleo. 102 delas apresentavam ainda ficheiros enviados através do PolyShell ou do SessionReaper (CVE-2025-54236), uma falha crítica que permite sequestrar sessões de clientes. As lojas totalmente atualizadas também não ficaram imunes: uma loja numa versão atual recebeu o loader uma hora depois de uma análise ter saído limpa, o que aponta para credenciais roubadas ou backdoors residuais e não para um exploit novo.
Porque é que importa
Os skimmers de checkout roubam os números de cartão diretamente do browser do cliente, pelo que o comerciante costuma saber do problema pelas redes de cartões ou por clientes irritados, e não pela sua própria monitorização. Esta campanha agrava a situação porque derrota ativamente a única verificação em que a maioria dos lojistas confia: uma análise externa da loja. Um resultado limpo de uma ferramenta automatizada já não prova que uma loja Magento está segura.
Os números de reinfeção são o outro sinal de alarme. Remover um script injetado sem fechar a brecha por onde entrou, e sem rodar as credenciais que o atacante já tem, compra no máximo algumas semanas.
O que fazer
Se gere uma loja Magento, trate a lista seguinte como uma checklist obrigatória e não como uma sugestão:
- Procure na base de dados, não só nos ficheiros. Consulte as tabelas
cms_blockecms_pageà procura de padrões comofpCode,se_referrerelocalStorage.getItem. Analise em particularcms_block.content. - Verifique a persistência. Reveja a tabela
admin_userà procura de contas que não reconheça, procure processos desconhecidos no servidor e inspecione diretórios de upload comopub/media/custom_options/à procura de web shells. - Rode tudo. Depois da limpeza, altere as credenciais da base de dados, do administrador e das APIs. Apagar o script não revoga o acesso do atacante.
- Aplique os patches. O boletim APSB26-73 da Adobe corrige o PolyShell e o APSB25-88 cobre o SessionReaper. Se não puder atualizar de imediato, coloque uma firewall de aplicações web à frente da loja para bloquear as tentativas de exploração conhecidas entretanto.
- Teste como um humano. Ao verificar uma loja, use uma sessão de browser normal com o armazenamento ativado, e não apenas um scanner headless, e compare os scripts que um visitante real recebe com o que as suas ferramentas veem.
Indicadores a vigiar (defanged)
- Domínio do loader:
deepveindrilling[.]com(caminhos/?s=d35c5031e/?s=49b7ca5f&fp=) - Domínios de distribuição de tráfego:
additionalver[.]com,lanhd6549tdhse[.]top,neswnsssn[.]click,manulfie[.]click,hdfdsi84j3h[.]top,c85grt98sd[.]com - Hosts de carga maliciosa vistos em dezembro de 2025:
leqdger[.]click,crypto-insider[.]top - Resposta-isco servida aos scanners:
QWE=123; - Chaves do armazenamento do browser:
fpCode,136c1e07507f4a97,136c1e07507f4a98
Campanhas como esta entram por falhas conhecidas e corrigíveis e depois contam com que ninguém olhe com atenção. O nosso serviço de análise de vulnerabilidades verifica as plataformas de comércio eletrónico precisamente para esta classe de exposição, desde boletins de segurança do Magento por aplicar até caminhos de upload com permissões de escrita, para que a brecha seja fechada antes que outra pessoa a encontre.