Meu site foi hackeado: o que fazer agora (guia técnico passo a passo)

Site hackeado não se resolve por tentativa e erro. O princípio técnico é direto: primeiro contém-se o dano, depois identifica-se o vetor de entrada, e só então a limpeza e a atualização acontecem, nessa ordem, porque pular uma etapa costuma reabrir a mesma porta.

O tempo joga contra quem demora a agir. Segundo o relatório State of WordPress Security da Patchstack, 91% das vulnerabilidades identificadas em 2025 estavam em plugins, não no núcleo do WordPress, e metade das falhas de alto impacto é explorada em menos de 24 horas após ser divulgada publicamente. O CrowdStrike 2026 Threat Hunting Report chega a um número parecido: 88% dos CVEs com exploit de prova de conceito publicado já foram usados em ataques reais dentro de 48 horas. Isso raramente tem a ver com sorte do atacante. Tem a ver com a velocidade da resposta. É esse fluxo de resposta que este guia detalha.

Por que a ordem importa mais que a pressa

Um site comprometido raramente tem um único ponto de falha. Arquivos alterados, banco de dados com scripts injetados e credenciais expostas costumam aparecer juntos, e cada peça tem uma dependência de ordem: o isolamento precisa vir antes do diagnóstico, o diagnóstico precisa vir antes da limpeza, e a limpeza precisa vir antes da rotação de credenciais.

Quando essa ordem é quebrada, o efeito de costume é o mesmo: o site volta ao ar limpo, mas reinfecta dias depois, porque a senha usada pelo invasor continuava válida ou o plugin vulnerável nunca foi atualizado. Antes de seguir para o passo a passo, vale ter à mão acesso SSH ou ao terminal do painel de hospedagem, já que a maior parte dos comandos abaixo depende disso.

Como recuperar um site hackeado em 6 passos

1. Isole o site via SSH

Coloque o site em modo de manutenção e troque a senha do painel de hospedagem e do acesso SSH antes de investigar qualquer coisa. Revogue também tokens de API de integrações como gateway de pagamento e webhooks.

touch /var/www/html/.maintenance
passwd seu_usuario

Verificação: confirme que o site exibe a página de manutenção para visitantes externos e que a senha antiga não funciona mais em uma nova tentativa de login.

2. Identifique o vetor de entrada

Restaurar sem saber por onde o invasor entrou tende a reabrir a mesma porta. Rode os comandos abaixo, nessa sequência, para mapear o que mudou:

find /var/www/html -name "*.php" -mtime -7 -type f
grep -rl "eval(\|base64_decode(\|gzinflate(" /var/www/html --include="*.php"
mysql -u usuario -p -e "SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10;" nome_do_banco

Na maioria dos casos, o resultado aponta para um plugin desatualizado, um tema baixado fora do repositório oficial, ou uma senha reaproveitada de outro serviço já vazado.

Verificação: liste os arquivos modificados e as contas de administrador criadas recentemente antes de seguir. Se nada aparecer de estranho, amplie a janela do find para 30 dias.

3. Faça um snapshot forense

Antes de deletar qualquer coisa, salve uma cópia completa do estado atual, arquivos e banco de dados juntos.

tar -czf /backup/snapshot-comprometido-$(date +%Y%m%d).tar.gz /var/www/html
mysqldump -u usuario -p nome_do_banco > /backup/db-comprometido-$(date +%Y%m%d).sql

Verificação: confirme que o .tar.gz e o .sql foram gerados com tamanho maior que zero antes de seguir para a limpeza.

4. Restaure ou limpe arquivo por arquivo

Com backup limpo disponível, restaurar é o caminho mais rápido: volte arquivos e banco ao ponto anterior à infecção e aplique todas as atualizações pendentes antes de reativar o site.

Sem backup limpo, a limpeza manual reinstala o essencial a partir de fontes oficiais:

wp core update --force --allow-root
wp plugin install $(wp plugin list --field=name --allow-root) --force --allow-root
find /var/www/html/wp-content/uploads -name "*.php" -delete

Verificação: rode de novo o grep de funções suspeitas do Passo 2 e confirme que o resultado voltou vazio.

5. Rotacione todas as credenciais

A limpeza técnica sem troca de credenciais deixa a porta fechada, mas a chave ainda na mão de quem invadiu.

curl -s https://api.wordpress.org/secret-key/1.1/salt/
wp user session destroy --all --allow-root

Troque também a senha do usuário do banco de dados, as chaves SSH e as credenciais de FTP pelo painel de hospedagem.

Verificação: tente logar com a senha antiga em qualquer serviço trocado. Se funcionar, a rotação não foi completa.

6. Atualize tudo e ative uma camada de proteção

Com o vetor de entrada corrigido, atualize o restante do ambiente e adicione uma camada extra de defesa antes de considerar o caso encerrado.

wp plugin update --all --allow-root
wp theme update --all --allow-root

Um firewall de aplicação web (WAF) ajuda, mas tem limite: a Patchstack aponta que firewalls tradicionais bloqueiam apenas 12% dos ataques específicos a WordPress. O caminho mais sólido combina WAF, autenticação em duas etapas e atualizações automáticas para os plugins mais críticos.

Verificação: confira se todos os plugins aparecem como “atualizado” no painel e se o login administrativo agora exige segundo fator.

Checklist fazer / não fazer

E, por último, a reputação no Google

Se o Google marcou o site como comprometido, a limpeza técnica não remove o aviso automaticamente. É preciso acessar o Search Console, na seção de Segurança e ações manuais, confirmar que o problema foi resolvido e solicitar a revisão descrevendo objetivamente o que foi feito. O prazo de resposta costuma variar de alguns dias a duas semanas, e pedir uma segunda revisão antes disso não acelera o processo.

Próximo passo

Esse é o passo a passo técnico completo. Se preferir contar com suporte especializado para investigar o vetor de ataque e conduzir a limpeza, a hospedagem WordPress da KingHost já vem com backup diário automático, SSD e acesso root via SSH configurados desde o início. Fale com o suporte técnico da KingHost e comece a recuperação sem sair do lugar.

Perguntas frequentes