Site WordPress hackeado: como reagir e consertar

Seu site WordPress redireciona para um cassino, exibe uma página de reivindicação do invasor ou o Google o marca como perigoso? O mais urgente não é apagar arquivos a esmo. É conter o ataque, guardar uma cópia do estado hackeado e retomar os acessos antes de consertar. Este guia organiza as decisões das primeiras horas aos trinta dias seguintes, com os comandos úteis e as obrigações que você não pode perder (incluindo o prazo de 3 dias úteis da LGPD para comunicar a ANPD).

Ainda não tem certeza de que foi hackeado? Comece pelas verificações para saber se seu site WordPress está hackeado. Procura o detalhe técnico da limpeza, arquivo por arquivo? Ele está no nosso procedimento passo a passo para limpar um site WordPress hackeado. Este artigo é o seu plano de resposta: quem faz o quê, em que ordem e como evitar a reinfecção.

Os dez primeiros minutos: conter sem apagar

Enquanto o código malicioso estiver rodando, ele pode roubar dados, enviar spam ou infectar seus visitantes. Mas apagar tudo na hora destrói os rastros que vão permitir encontrar a porta de entrada. O meio-termo certo:

1. Tire o site do ar para os visitantes: página de manutenção no nível do servidor (uma regra no .htaccess que devolve uma página estática com código 503, ou a opção da hospedagem), não com um plugin do WordPress que depende do código comprometido.
2. Avise a hospedagem por chamado: às vezes ela já detectou a infecção, pode bloquear o envio de e-mails e tem logs que você não vê.
3. Abra um registro do incidente fora do servidor: hora, constatação, ação, responsável. Ele vai servir para o seguro, para um prestador de serviço, para um boletim de ocorrência ou para a ANPD.
4. Não restaure ainda um backup: você não sabe desde quando o site está comprometido, nem se o backup está limpo.

Avaliar a gravidade para escolher o ritmo certo

Nem toda invasão exige a mesma urgência. A tabela a seguir ajuda a decidir quem acionar e o que vem primeiro.

O que você observa	Risco principal	Prioridade	Quem acionar
Redirecionamentos para sites duvidosos, alerta do Google	Visitantes infectados, desindexação	Fora do ar imediatamente	Hospedagem, você ou um prestador
Páginas de spam indexadas (farmácia, cassino)	Posicionamento, reputação	No mesmo dia	Você, depois o Search Console
Página inicial desfigurada	Imagem da marca	Fora do ar imediatamente	Hospedagem, prestador
Contas de clientes, formulários ou pedidos expostos	Vazamento de dados pessoais	Imediata, prazo da LGPD correndo	Encarregado de dados (DPO), ANPD, prestador
Formulário de pagamento alterado (loja)	Roubo de cartões	Imediata	Intermediador de pagamento, banco, prestador
Resgate ou arquivos criptografados	Perda de dados	Imediata, não pague	Hospedagem, CERT.br, boletim de ocorrência

Guardar uma cópia do estado hackeado

Antes de qualquer conserto, baixe uma cópia completa: arquivos (por SFTP ou um arquivo compactado gerado pela hospedagem), banco de dados (exportação SQL) e, se possível, os logs de acesso do servidor dos últimos 30 dias. Guarde essa cópia fora do servidor, separada dos seus backups limpos, e identifique-a claramente como “infectada” para nunca restaurá-la por engano. É ela que vai permitir datar a invasão e, assim, escolher um backup anterior.

Para datar a invasão, procure nessa cópia os arquivos PHP modificados recentemente e a data de criação das contas desconhecidas. A regra dos backups 3-2-1 faz toda a diferença aqui: sem uma cópia externa antiga, só resta a limpeza.

Retomar os acessos, do mais amplo ao mais restrito

Troque as senhas a partir de um computador limpo, começando pelo que dá mais poder: um invasor que mantém acesso ao seu e-mail ou à área do cliente da hospedagem pode recomeçar tudo.

1. O e-mail que recebe as redefinições de senha, depois a área do cliente da hospedagem e o registrador do domínio (ative a autenticação em dois fatores).
2. Contas SFTP e SSH, painel de controle (cPanel, Plesk) e usuário do banco de dados, depois atualize o wp-config.php.
3. Chaves e salts do WordPress, o que encerra todas as sessões abertas, inclusive a do invasor.
4. Todas as contas de administrador, depois as senhas de aplicativo e as chaves de API dos plugins (pagamento, envio de e-mails, backup remoto).

Com o WP-CLI, as verificações básicas cabem em poucos comandos:

# Novas chaves e salts: todas as sessões são encerradas
wp config shuffle-salts

# Contas de administrador: identifique as que você não conhece
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Tarefas agendadas: uma tarefa desconhecida pode reinfectar o site
wp cron event list --fields=hook,next_run_relative,recurrence

# Endereços do site: um redirecionamento pode se esconder aqui
wp option get siteurl
wp option get home

Consertar: o que substituir, o que inspecionar

O princípio: tudo o que pode ser reinstalado a partir de uma fonte oficial é substituído, não limpo linha por linha. Só o que é seu (conteúdos, mídias, configurações, tema sob medida) é inspecionado manualmente.

Item	Ação	Comando ou método
Núcleo do WordPress	Reinstalar idêntico	wp core verify-checksums e depois wp core download --force --skip-content
Plugins e temas	Excluir e reinstalar a partir do wordpress.org ou do desenvolvedor	wp plugin verify-checksums --all, nunca versões “nulled”
Pasta uploads	Nenhum arquivo PHP deve estar lá	find wp-content/uploads -name "*.php"
mu-plugins e drop-ins	Verificar cada arquivo	wp-content/mu-plugins, object-cache.php, advanced-cache.php
.htaccess e wp-config.php	Comparar com uma versão limpa	Redirecionamentos, auto_prepend_file, inclusões desconhecidas
Banco de dados	Procurar scripts injetados	Tabelas wp_options e wp_posts: tags <script>, eval, base64
Usuários	Excluir as contas desconhecidas	Reatribuir seus conteúdos, verificar funções alteradas

Os esconderijos clássicos de um backdoor ficam justamente onde ninguém olha: um arquivo de nome inofensivo em uploads, um mu-plugin que não aparece na lista de plugins, uma tarefa cron que recria o arquivo excluído. Se você não descobrir como o invasor entrou (plugin vulnerável, senha reutilizada, acesso FTP roubado), o site será invadido de novo em poucos dias: é a hora de chamar um profissional.

O plano de resposta, passo a passo

Sair das listas negras e do alerta do Google

Quando o site estiver limpo, e só então, coloque-o de volta no ar e peça a retirada dos alertas:

• Google Search Console: o relatório “Problemas de segurança” lista o que o Google encontrou. Corrija tudo, em todas as páginas, e depois clique em “Solicitar análise” descrevendo o problema, o que você fez e o resultado. O Google informa que uma análise de malware ou conteúdo hackeado leva de alguns dias a algumas semanas: não envie outra solicitação enquanto a primeira estiver em andamento. Detalhes no nosso guia sobre o alerta de “site perigoso”.
• Páginas de spam indexadas: deixe-as responder 404 ou 410 e use a ferramenta de remoção temporária para as mais visíveis. O método completo está no nosso artigo sobre spam de SEO e desindexação.
• Outras listas: verifique o domínio em serviços de análise como VirusTotal ou Sucuri SiteCheck, e o IP de envio dos seus e-mails nas listas antispam se suas mensagens estiverem caindo no spam. Cada lista tem seu próprio procedimento de remoção.

WordPress Hacked? Step-By-Step Fix, Cleanup, and 99% Attack Prevention TutorialAo clicar, o vídeo é carregado de youtube-nocookie.com (YouTube, Google). Nada é carregado antes do seu clique.

Comunicar: ANPD, titulares, boletim de ocorrência

Se o invasor pôde acessar dados pessoais (contas de clientes, formulários de contato, pedidos, lista de assinantes), trata-se de um incidente de segurança com dados pessoais nos termos da LGPD. O artigo 48 da LGPD e a Resolução CD/ANPD nº 15/2024 exigem comunicar a ANPD e os titulares afetados em até 3 dias úteis, contados do conhecimento do incidente, quando ele puder acarretar risco ou dano relevante aos titulares. O risco é considerado relevante sobretudo quando envolve senhas, dados financeiros ou dados pessoais sensíveis. Em todos os casos, registre o incidente no seu registro interno. Nosso artigo sobre proteção de dados, logs e segurança do WordPress detalha o que convém guardar.

• Comunicação incompleta: você pode comunicar no prazo com o que já sabe e complementar depois. Mais vale uma comunicação parcial dentro do prazo do que uma perfeita fora dele.
• Loja virtual: avise seu intermediador de pagamento se o checkout pode ter sido alterado. Ele vai dizer o que fazer com os cartões.
• Ajuda e boletim de ocorrência: o CERT.br recebe notificações de incidentes e orienta sobre a resposta; o boletim de ocorrência, de preferência numa delegacia de crimes cibernéticos, costuma ser exigido pelo seguro.

Os trinta dias seguintes: não ser hackeado de novo

Um site limpo sem correção da causa costuma ser reinfectado. Durante o mês seguinte:

• Atualize tudo o que faltar, exclua os plugins sem uso e substitua os plugins abandonados.
• Ative a autenticação em dois fatores em todas as contas que podem publicar ou administrar.
• Refaça as verificações de integridade toda semana e fique de olho no surgimento de novos administradores.
• Teste uma restauração de backup, de verdade, em um ambiente de homologação.
• Escreva um breve relatório pós-incidente: causa, duração, custo, o que faltou.

O que o WP Masquerade pode fazer, e o que ele não faz

Sejamos claros: o WP Masquerade não é uma ferramenta de limpeza. Ele não procura malware, não filtra o tráfego como um firewall e não faz backup do seu site. Para o conserto, use um scanner (Wordfence, MalCare, Sucuri) ou um profissional, e a ferramenta de backup de sua preferência.

Ele entra em ação depois, para reduzir as chances de um novo incidente e avisar você mais cedo. A versão gratuita muda o endereço da página de login, bloqueia o XML-RPC e remove os rastros que denunciam o WordPress aos robôs. O WP Masquerade Pro adiciona a autenticação em dois fatores obrigatória por função, a limitação de tentativas de login, o controle de integridade do núcleo, o registro de atividades dos administradores e os alertas de plugins vulneráveis, que muitas vezes teriam permitido corrigir a falha antes do ataque.

Perguntas frequentes

É melhor restaurar um backup ou limpar o site?

Restaure se você tiver um backup anterior à invasão e souber quando ela aconteceu. Caso contrário, limpe ou reconstrua. Nos dois casos, corrija a porta de entrada e troque todos os acessos, senão o invasor vai voltar.

Quanto tempo o Google leva para retirar o alerta?

Depois de uma solicitação de análise no Search Console, o Google fala em alguns dias a algumas semanas para malware e conteúdo hackeado. O prazo depende da qualidade da limpeza: qualquer problema restante faz a análise ser reprovada.

Preciso comunicar a ANPD por um simples spam de SEO?

Não, se nenhum dado pessoal pôde ser consultado ou copiado. Mas um invasor que conseguiu adicionar páginas muitas vezes teve acesso ao banco de dados: verifique o que ele contém (contas, pedidos, formulários) antes de concluir, e anote sua análise no registro de incidentes.

Trocar as chaves e salts do WordPress é suficiente?

Não. Isso encerra as sessões abertas, mas um invasor que conhece uma senha, tem uma conta de administrador oculta ou um backdoor volta na hora. Os salts são uma parte de um conjunto: senhas, contas, arquivos e tarefas agendadas.

Quando chamar um profissional?

Quando você não encontra a porta de entrada, quando o site se reinfecta depois da limpeza, quando dados de clientes ou de pagamento estão em jogo, ou quando o site gera o seu faturamento. Peça um relatório por escrito: causa, arquivos afetados, medidas tomadas.

Fontes

• WordPress.org: FAQ My site was hacked (link externo, abre em uma nova aba)
• Google: relatório de problemas de segurança (link externo, abre em uma nova aba)
• ANPD: comunicação de incidente de segurança (link externo, abre em uma nova aba)
• WP-CLI: wp config shuffle-salts (link externo, abre em uma nova aba)