WordPress invadido: como descobrir, limpar e evitar que aconteça de novo

Seu WordPress foi invadido? Veja os sinais, como achar arquivos alterados e backdoors com WP-CLI, limpar o site com segurança e impedir nova invasão.

Para que serve

Redirecionamento para sites de apostas, páginas de spam indexadas no Google, alerta do navegador ou do Search Console, servidor enviando spam: são os sinais típicos de um WordPress invadido. A causa quase sempre é um plugin ou tema desatualizado, ou uma senha de administrador vazada. Este artigo mostra como confirmar a invasão, encontrar o que foi alterado, limpar com segurança e fechar a porta de entrada. Para a instalação e o endurecimento inicial do WordPress, veja também o artigo «Como otimizar o WordPress no seu servidor: velocidade, cache e segurança».

Pré-requisitos

• Acesso SSH à VM onde o site roda e o wp-cli instalado.
• Espaço em disco para uma cópia completa do site e do banco antes de mexer.
• Um backup antigo, de antes da invasão, se existir.

Sinais de WordPress invadido

• Usuários administradores que ninguém criou.
• Arquivos .php dentro de wp-content/uploads.
• Pesquisa site:seudominio.com.br no Google mostra páginas em outros idiomas ou de produtos que você não vende.
• Picos de CPU, processos php ou sh desconhecidos, ou fila de e-mails enorme.
• Redirecionamento só para visitantes vindos do Google ou de celular (o invasor esconde o efeito do administrador).

Passo 1: preserve evidências e contenha

1. Tire um snapshot da VM no Proxmox (VM → Snapshots → Take Snapshot) ou faça cópia dos arquivos e do banco:

   cd /var/www/site
   sudo tar czf /root/site-invadido-$(date +%F).tar.gz .
   sudo -u www-data wp db export /root/site-invadido-$(date +%F).sql

   Mova as cópias para fora da pasta pública.
2. Coloque o site em manutenção ou bloqueie o acesso público no servidor web enquanto investiga, principalmente se ele está distribuindo malware.
3. Troque as senhas de todos os administradores, do banco de dados, do SFTP/SSH e do painel de hospedagem, a partir de um computador limpo.

Passo 2: encontre o que foi alterado no WordPress

1. Compare o núcleo com os arquivos oficiais:

   cd /var/www/site
   sudo -u www-data wp core verify-checksums
   sudo -u www-data wp plugin verify-checksums --all

   Qualquer arquivo listado como alterado ou que "não deveria existir" é suspeito. Plugins comprados fora do repositório oficial não têm checksum para comparar.
2. Procure PHP onde não deveria haver:

   sudo find wp-content/uploads -type f -name "*.php"
   sudo find . -name "*.php" -newer wp-config.php -mtime -30 -ls

3. Procure trechos ofuscados comuns em backdoors:

   sudo grep -rlE "eval\(base64_decode|gzinflate\(base64|str_rot13\(|assert\(\\\$_(POST|GET|REQUEST)" wp-content

   Alguns plugins legítimos usam essas funções; avalie cada resultado.
4. Confira pastas que carregam código automaticamente: wp-content/mu-plugins, wp-content/drop-ins e o arquivo .htaccess (redirecionamentos condicionais).
5. Revise usuários, tarefas e opções no banco:

   sudo -u www-data wp user list --role=administrator
   sudo -u www-data wp cron event list
   sudo -u www-data wp option get siteurl
   sudo -u www-data wp option get home
   sudo -u www-data wp db search "<script" --all-tables --stats

6. Olhe fora do site: crontab -l do usuário do PHP, processos (ps aux --sort=-%cpu | head) e conexões (ss -tunap). Se encontrar binários desconhecidos rodando, o comprometimento pode ter passado do WordPress para o sistema.
7. Descubra a porta de entrada nos logs de acesso, procurando POSTs em arquivos de plugins próximos da data dos primeiros arquivos alterados:

   sudo grep "POST" /var/log/nginx/access.log* | grep -v wp-cron | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Passo 3: limpe o site

1. Reinstale o núcleo sem tocar em wp-content e wp-config.php:

   sudo -u www-data wp core download --force --skip-content

2. Reinstale plugins e temas a partir da fonte oficial, em vez de limpar arquivo por arquivo. Remova os que não usa e os abandonados (sem atualização há muito tempo):

   sudo -u www-data wp plugin install NOME-DO-PLUGIN --force

3. Apague os arquivos PHP em uploads, os administradores desconhecidos e as tarefas cron estranhas.
4. Invalide sessões e cookies trocando as chaves do wp-config.php:

   sudo -u www-data wp config shuffle-salts

5. Atualize tudo: wp core update, wp plugin update --all, wp theme update --all.
6. Considere restaurar um backup limpo se a invasão for extensa. Um backup anterior à primeira alteração, seguido das atualizações, costuma ser mais confiável que limpeza manual.

Passo 4: evite nova invasão do WordPress

• Ative atualização automática de plugins críticos e acompanhe avisos de segurança dos plugins que usa.
• Exija autenticação em dois fatores para todos os administradores.
• Cada site com usuário de sistema e pool PHP-FPM próprios, para que a invasão de um não atinja os outros.
• Bloqueie execução de PHP em uploads e limite tentativas no wp-login.php.
• Considere um WAF na frente do site (veja o artigo sobre ModSecurity e Cloudflare).
• Backup diário fora do servidor, com retenção suficiente para voltar a antes de uma invasão silenciosa (30 dias ou mais).

Como saber se funcionou

• wp core verify-checksums e wp plugin verify-checksums --all não apontam diferenças.
• Nenhum PHP em uploads e nenhum administrador desconhecido.
• O site abre normalmente acessando pelo celular e por um link do Google.
• No Google Search Console, em Problemas de segurança, não há alertas (ou você já pediu a revisão).

Problemas comuns

• A infecção volta depois de limpar: sobrou um backdoor (geralmente em mu-plugins, em um tema não usado ou no banco) ou a falha original não foi corrigida.
• Outro site do mesmo servidor também infectado: os sites compartilham o mesmo usuário de sistema. Separe usuários e pools PHP.
• Google ainda mostra aviso: após a limpeza, solicite a revisão no Search Console; pode levar alguns dias.

Perguntas frequentes

Plugin de segurança resolve?

Ajuda a detectar, mas roda dentro do próprio WordPress, que pode estar comprometido. Use a verificação por WP-CLI e os logs do servidor como referência.

Preciso comunicar a ANPD?

Se o site guardava dados pessoais (cadastros, pedidos) e eles podem ter sido acessados, avalie com o responsável jurídico. Veja o artigo sobre LGPD nesta categoria.

Restaurar o backup basta?

Só se você também corrigir a falha que permitiu a invasão; caso contrário, o site é reinfectado em pouco tempo.

Leitura complementar

• WordPress: Hardening WordPress
• WP-CLI: wp core verify-checksums
• WordPress: autenticação em dois fatores

Precisa de ajuda?

Se o servidor está enviando spam ou atacando terceiros e você precisa de acesso ao console IPMI/iLO para isolar a VM, abra um ticket ou chame o suporte 24/7.