Site WordPress hackeado: diagnosticar e limpar em vários sites

Você abre o site do cliente e ele redireciona para uma farmácia. Ou o Google Search Console acusa conteúdo injetado. Ou o host manda um aviso dizendo que o site WordPress hackeado está consumindo recursos demais. A primeira reação é entrar no painel e começar a apagar coisas. Não faça isso. Sem diagnóstico, você apaga evidência e pode deixar a porta dos fundos aberta.

Este artigo entrega uma ordem de diagnóstico que separa comprometimento real de falso positivo, mostra quando limpar no lugar e quando restaurar backup, e trata do recorte de quem administra vários sites: como checar em lote se o mesmo vetor entrou em outros sites do mesmo servidor antes de responder ao cliente.

Antes de tudo: confirme que é invasão, não falso positivo

Nem todo alerta é ataque. Cache envenenado, plugin desatualizado sinalizado pelo host e redirect só em mobile são falsos positivos comuns. A ordem abaixo evita que você comece a limpar um site que não foi invadido.

1. Verifique o HTML servido, não o que você vê logado. Use curl -I https://seusite.com.br e depois curl -s https://seusite.com.br | head -100. Se aparecer script ofuscado, iframe ou link estranho no código-fonte, é comprometimento. Se o código estiver limpo mas o navegador redireciona, pode ser cache ou DNS.
2. Teste em janela anônima e em outro dispositivo. Redirect só em mobile costuma vir de regra no .htaccess ou de user-agent. Se só acontece no seu navegador, é cache local ou extensão.
3. Confira o .htaccess e o wp-config.php. Linhas como RewriteRule .* http://site-estranho.com ou auto_prepend_file apontando para arquivo externo são injeção. Compare com um backup limpo ou com o padrão do WordPress.
4. Olhe os usuários administradores. Um usuário administrador desconhecido no WordPress quase sempre indica entrada. Se você não criou, audite a lista completa e os últimos logins. Há um passo a passo em como auditar admins em vários sites.
5. Cheque os posts e páginas. Links injetados aparecem no conteúdo ou em widgets. Se o volume for grande, o caminho é achar e limpar link injetado em vários sites.

Se os cinco passos deram negativo, o problema provavelmente é cache, CDN ou configuração do host. Não limpe nada ainda.

Sinais de site WordPress hackeado que não deixam dúvida

Alguns sintomas são conclusivos. Quando aparecem, trate como comprometimento confirmado:

Na prática, dois ou mais sinais juntos significam invasão. Um sinal isolado pede investigação antes de qualquer ação destrutiva.

Como o ataque entrou: vetores mais comuns

Identificar o vetor é o que impede a reinfecção. Limpar sem saber por onde entrou é convite para o ataque voltar em dias.

• Plugin ou tema desatualizado com vulnerabilidade conhecida. É o vetor mais frequente. Se o host sinalizou plugin desatualizado, comece por aí. A triagem está em vulnerabilidade em plugin WordPress: triagem em vários sites.
• Credenciais fracas ou reutilizadas. Senha igual à de outro serviço vazado derruba o site sem exploit nenhum.
• Plugin pirata ou nulled. Traz backdoor embutido. Se você não instalou, verifique quem tem acesso ao painel.
• Permissões de arquivo erradas. Pastas 777 permitem escrita por qualquer processo.
• Site vizinho no mesmo servidor. Em hospedagem compartilhada, uma conta comprometida pode alcançar outras. Este é o ponto crítico para quem gerencia vários sites.

Limpar no lugar ou restaurar backup?

Esta é a decisão que separa um trabalho de duas horas de um de dois dias. O critério é simples:

Restaurar backup só resolve se ele for anterior à entrada do atacante. Se o backup já contém o backdoor, você restaura o problema. Antes de restaurar, confirme a data do comprometimento pelos logs do host ou pela data de modificação dos arquivos suspeitos.

Limpeza passo a passo quando a decisão é limpar no lugar

1. Coloque o site em manutenção. Um 503 evita que o atacante veja você trabalhando e que visitantes peguem redirect.
2. Faça backup do estado atual. Sim, do estado infectado. Você vai precisar dele para comparar e para eventual perícia.
3. Troque todas as senhas. Painel, FTP, banco, e-mail do domínio. Inclua as chaves do wp-config.php (salts).
4. Reinstale core, temas e plugins a partir do repositório oficial. Não confie em arquivos existentes. Delete e reinstale.
5. Remova plugins e temas que você não usa. Cada um é superfície de ataque.
6. Procure backdoors. Compare a pasta wp-content com uma instalação limpa. Arquivos PHP em uploads são quase sempre maliciosos.
7. Limpe o banco. Procure por <script>, <iframe> e domínios estranhos em wp_posts, wp_options e wp_postmeta. Cuidado com substituições em massa: um UPDATE errado derruba o site.
8. Verifique redirecionamentos. .htaccess, wp-config.php, funções do tema e plugins de cache costumam esconder regras.
9. Atualize tudo e revise permissões. Pastas 755, arquivos 644. wp-config.php pode ficar em 600.
10. Saia do modo manutenção e monitore. Reinfecção em 48 horas indica que sobrou backdoor.

Se o site tem muitos arquivos e você não tem SSH, o caminho pelo painel da hospedagem é mais lento. Nesse caso, baixe wp-content por FTP e compare localmente com uma instalação limpa. É trabalhoso, mas é o único jeito de achar backdoor sem linha de comando.

O recorte de quem cuida de vários sites: checar em lote antes de responder ao cliente

Quando um site é comprometido, a pergunta que o cliente não faz mas importa é: os outros também foram? Em servidor compartilhado, o mesmo vetor pode ter atingido todos. Antes de responder ao cliente, faça uma varredura em lote.

1. Liste todos os sites no mesmo servidor. Inclua os de outros clientes se você tem acesso ao painel do host.
2. Compare datas de modificação. Arquivos alterados na mesma janela de tempo em sites diferentes indicam ataque comum.
3. Procure o mesmo indicador. Se o backdoor é wp-content/uploads/2024/x.php, busque esse padrão em todos os sites.
4. Verifique usuários admin em todos. Um usuário novo na mesma data em vários sites é sinal claro.
5. Cheque plugins desatualizados em lote. O vetor costuma ser o mesmo plugin em versão vulnerável.

Esse trabalho manual não escala. É exatamente onde um painel de gestão de vários sites economiza horas: você vê versões, usuários e alertas de todos de uma vez, em vez de abrir site por site. O 100% WP centraliza atualizações, backups e monitoramento, o que ajuda a detectar o mesmo vetor em vários sites antes que o segundo cliente ligue.

Quando NÃO limpar no lugar

Existem cenários em que insistir na limpeza é perda de tempo e risco. Não limpe no lugar quando:

• O banco tem conteúdo injetado em muitas tabelas e você não consegue mapear tudo.
• O atacante teve acesso ao painel por dias ou semanas. Nesse período, pode ter criado backdoors em pontos que você não vai achar.
• O site é de e-commerce com dados de clientes. Aqui a prioridade é conter o vazamento e comunicar, não economizar tempo.
• Você não tem backup limpo nem tempo para uma auditoria completa. Restaurar de uma instalação nova e reimportar conteúdo costuma ser mais seguro.

Nesses casos, a decisão correta costuma ser reconstruir o site a partir de uma instalação limpa, importando apenas conteúdo e mídia verificados.

Erros comuns que fazem o ataque voltar

• Trocar só a senha do painel. O atacante mantém acesso por FTP, banco ou backdoor.
• Não remover plugins desativados. Código parado ainda é código executável.
• Confiar no backup sem verificar a data. Backup pós-infecção restaura o problema.
• Deixar permissões 777. Facilita a reinfecção.
• Não avisar o host. Se o vetor veio de outra conta no mesmo servidor, o problema volta.
• Ignorar os outros sites. O mesmo ataque costuma atingir todos os sites do mesmo servidor.

Prevenção para quem gerencia vários sites

Depois de limpar, o trabalho é evitar a próxima. Atualizações em dia, backups automáticos fora do servidor, autenticação em dois fatores para todos os admins e revisão periódica de usuários resolvem a maior parte dos casos. Um bom ponto de partida é hardening em vários sites, que cobre permissões, cabeçalhos e configuração do servidor.

Vale também definir prioridades. Nem toda ameaça exige ação imediata, e saber o que atacar primeiro evita pânico. O artigo sobre ameaças de segurança WordPress e o que priorizar ajuda nessa ordem.

Por fim, se o site é de cliente e você não tem certeza do escopo, não improvise. Um site WordPress hackeado com dados de terceiros envolve responsabilidade legal e reputacional. Nesse caso, o caminho é acionar o host, documentar tudo e, se necessário, contratar um serviço especializado em remoção de malware.

Fonte: Documentação oficial do WordPress