PrestaShop pirateada: detetar e remover um skimmer bancário

O pior ataque é aquele que não parte nada

Quando uma loja PrestaShop pirateada cai em erro 500, o comerciante dá por isso na primeira hora. Quando tem um skimmer instalado, a loja continua a funcionar na perfeição: as encomendas passam, os clientes pagam e um script injetado na página de pagamento copia discretamente os números de cartão para um servidor terceiro.

A vaga observada no PrestaShop no início de 2026 segue este padrão. O ponto de entrada quase nunca é o core: é um módulo de terceiros desatualizado, por vezes instalado anos antes e depois esquecido.

Duas consequências imediatas para o comerciante: a perda de conformidade PCI DSS junto do prestador de pagamentos e a obrigação de notificar a autoridade de proteção de dados competente no prazo de 72 horas, ao abrigo do artigo 33.º do RGPD.

Os sinais que devem alertar

Nenhum destes sinais é uma prova por si só, mas cada um merece verificação:

• clientes que comunicam débitos fraudulentos pouco depois de uma encomenda na sua loja;
• o prestador de pagamentos contacta-o por causa de uma taxa de fraude anormal;
• um ficheiro JavaScript do tema tem uma data de alteração recente sem que tenha publicado o que quer que seja;
• uma etiqueta <script> que aponta para um domínio desconhecido aparece no código-fonte da página de encomenda;
• o Google Search Console assinala conteúdo enganador ou páginas de spam indexadas.

Os domínios de exfiltração imitam de propósito serviços legítimos: nomes com cdn, analytics, jquery, tag-manager, em extensões pouco comuns. Um domínio parecido com o da Google sem ser google.com é o sinal mais fiável.

O diagnóstico por SSH, em cinco comandos

Ficheiros alterados nos últimos sete dias:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Código ofuscado nos temas e nos módulos:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Backdoors clássicas:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

Do lado da base de dados, uma injeção histórica bem documentada consiste em inserir JavaScript no nome da loja, que é depois reproduzido em todas as páginas:

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Uma conta de funcionário que não reconheça, ou um valor de configuração com HTML lá dentro, valem como confirmação.

O procedimento de limpeza

Limpar um site pirateado sem método garante uma reinfeção. A ordem conta.

1. Congelar a cena. Faça uma cópia completa dos ficheiros e da base de dados antes de mexer no que quer que seja. É a sua única prova e a única forma de perceber o vetor de entrada.

2. Estancar a hemorragia. Coloque a loja em modo de manutenção. Enquanto a página de pagamento estiver online, os números continuam a sair.

3. Repor o código a partir de uma fonte limpa. Volte a transferir o core do PrestaShop na versão exata que tem instalada e sobreponha os ficheiros, preservando img/, upload/, download/, os seus módulos próprios e config/settings.inc.php. Reinstale cada módulo de terceiros a partir do site do respetivo editor, nunca a partir de um arquivo encontrado no servidor.

4. Limpar a base de dados. Corrija os valores alterados em ps_configuration, elimine as contas de funcionário desconhecidas e inspecione os blocos CMS e as descrições de produto que contenham <script>.

5. Renovar tudo. Palavras-passe dos funcionários, palavra-passe da base de dados, acessos FTP/SSH, chaves de API dos módulos de pagamento e as chaves criptográficas de config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Regenerar estas chaves encerra todas as sessões, incluindo a do atacante.

6. Fechar a porta de entrada. Sem este passo, a reinfeção chega em poucos dias. Atualize todos os módulos, consulte os comunicados de segurança publicados pela Friends-of-Presta para cada um deles e aplique as correções de segurança do core.

Reforçar a loja para o futuro

• Mudar o nome da pasta de administração e protegê-la com uma autenticação HTTP adicional.
• Proibir a execução de PHP em img/, upload/ e download/ através da configuração do servidor.
• Ativar a autenticação de dois fatores em todas as contas de funcionário.
• Instalar uma firewall aplicacional e uma monitorização da integridade dos ficheiros: um ficheiro PHP criado em modules/ tem de gerar um alerta.
• Fazer cópias de segurança diárias, com uma retenção mínima de 30 dias. Uma cópia de 7 dias não serve de nada perante uma intrusão descoberta ao fim de três semanas.

Se a sua loja foi comprometida através de um módulo de pesquisa por facetas por corrigir, leia também a nossa análise da vulnerabilidade ps_facetedsearch.

Intervenção de emergência

Um skimmer custa mais caro a cada dia que fica no lugar. Auditamos, limpamos e protegemos a loja, com um relatório escrito do vetor de entrada. Diagnóstico gratuito, resposta em 1 h — fale connosco.