Loja Magento invadida: o que fazer nas primeiras 72 horas sem apagar a evidência

Magento hackeado: os sinais que abrem o incidente

Loja Magento invadida raramente avisa com tela de erro. Os sinais costumam chegar de fora ou aparecer de lado:

• clientes relatando cartão clonado depois de comprar na loja, ou aviso do gateway de pagamento;
• script desconhecido carregando na página de pagamento;
• usuário administrador que ninguém da equipe criou;
• arquivo alterado ou criado fora de um deploy;
• alerta de site perigoso no navegador ou no Google.

Com qualquer um deles, eu trato como incidente até ter prova do contrário. E a primeira decisão não é limpar. No guia de resposta a incidentes da Adobe, auditar os acessos ao admin e preservar os logs críticos estão entre os primeiros passos, e a Adobe alerta que muitas lojas são comprometidas de novo em questão de horas.

Horas 0 a 2: conter a invasão sem apagar a evidência

Decida a contenção. Se o sinal envolve a página de pagamento, cada compra nova pode expor mais um cartão: tire a loja do ar com o modo de manutenção, que devolve uma página 503 para todos, exceto os IPs liberados. Se o sinal é só um admin desconhecido, sem indício no checkout, dá para manter a venda enquanto o acesso ao painel é bloqueado. Na dúvida, eu paro a venda.

bin/magento maintenance:enable --ip=203.0.113.10
bin/magento maintenance:status

O IP liberado é o de quem investiga (o do exemplo é um endereço reservado para documentação). Com a loja em manutenção, a documentação da Adobe manda parar também os consumidores das filas.

Preserve antes de mexer. Guarde fora do servidor, com data e hora:

• logs do servidor web e do PHP, mais as pastas var/log e var/report;
• cópia completa do banco de dados;
• cópia dos arquivos da loja mantendo as datas de modificação;
• crontab dos usuários do servidor e lista de processos rodando.

Se há cartão envolvido, fale com o gateway de pagamento já nessa etapa: as transações contestadas ajudam a datar o início do problema.

Horas 2 a 24: medir o alcance e achar o admin desconhecido

As perguntas que a Adobe manda responder são diretas: houve acesso a dados de cartão? O que foi levado? Há quanto tempo a loja está comprometida? A informação estava criptografada? Para responder, eu começo por quatro frentes:

1. Usuários do admin criados ou com login no período suspeito.
2. Integrações criadas no período: um token de integração acessa a API sem passar pela tela de login.
3. Arquivos: código diferente do repositório e arquivos .php dentro de pub/media, onde executável não deveria existir.
4. Pontos de injeção de script: cabeçalho e rodapé do HTML na configuração de design, em todos os escopos, e blocos de conteúdo.

SELECT user_id, username, email, created, logdate, is_active
  FROM admin_user
 WHERE created >= '2026-10-01' OR logdate >= '2026-10-01';

SELECT integration_id, name, email, status, created_at
  FROM integration
 WHERE created_at >= '2026-10-01';

find pub/media -type f -name '*.php'

Troque a data pelo início provável do incidente. No Adobe Commerce, o relatório de Action Logs mostra as ações no admin com usuário, IP e horário; no Magento Open Source esse recurso não existe, e os logs do servidor web viram a fonte principal.

Admin desconhecido no Magento: desative e anote, não apague ainda. E-mail usado, data de criação e último login são evidência.

Horas 24 a 72: limpar o Magento 2 e trocar credenciais na ordem certa

Limpar malware do Magento 2 não é apagar o arquivo estranho. A Adobe recomenda remover o que não é necessário e reinstalar o código a partir de uma fonte conhecida e limpa, como o repositório ou a distribuição original, e, em alguns casos, recriar o servidor, porque o código malicioso pode ficar escondido esperando para se restaurar. Antes de reabrir, aplique os patches pendentes: segundo a Adobe, a maioria dos incidentes explora vulnerabilidade sem patch, senha fraca ou permissão mal configurada. Se há boletim em aberto para a sua versão, veja como decidir o prazo do boletim de segurança.

A armadilha: trocar senha antes de fechar a porta de entrada entrega a senha nova para quem ainda está lá dentro. E quem leu o app/etc/env.php leu a senha do banco e a chave de criptografia. Por isso a ordem:

Pela documentação da Adobe, a troca da chave pede modo de manutenção e cron desligado, e desde a 2.4.8 só existe pela linha de comando. Depois da limpeza, peça a revisão ao Google se a loja foi marcada como perigosa e mantenha vigilância reforçada nos dias seguintes.

Cartão de cliente clonado: quem avisar e em quanto tempo

Pela LGPD (art. 48), quem comunica o incidente à ANPD e aos clientes é o controlador, ou seja, a loja. A Resolução CD/ANPD nº 15/2024 fixa o prazo em três dias úteis, contados de quando a loja soube que o incidente afetou dados pessoais. Segundo a ANPD, a comunicação é obrigatória quando três critérios se somam: ocorrência confirmada, dados pessoais envolvidos e possibilidade de risco ou dano relevante aos titulares.

• Três dias úteis não são 72 horas. Exemplo de contagem: incidente conhecido numa sexta-feira, sem feriado no caminho, vence na quarta seguinte.
• Faltando informação, a comunicação pode ser feita em etapas, com complemento em até 20 dias úteis.
• A loja mantém o registro do incidente por no mínimo cinco anos, mesmo quando ele não precisa ser comunicado.
• O fornecedor de suporte, como operador, avisa a loja sem demora injustificada.

Isso não é parecer jurídico: a avaliação de risco e o texto do comunicado passam pelo encarregado de dados ou por um advogado. Se a loja precisa de ajuda técnica agora, o suporte de urgência fura a fila.