Site hackeado n\u00e3o se resolve por tentativa e erro. O princ\u00edpio t\u00e9cnico \u00e9 direto: primeiro cont\u00e9m-se o dano, depois identifica-se o vetor de entrada, e s\u00f3 ent\u00e3o a limpeza e a atualiza\u00e7\u00e3o acontecem, nessa ordem, porque pular uma etapa costuma reabrir a mesma porta.<\/p>\n\n\n\n
O tempo joga contra quem demora a agir. Segundo o relat\u00f3rio State of WordPress Security<\/em> da Patchstack<\/a>, 91% das vulnerabilidades identificadas em 2025 estavam em plugins, n\u00e3o no n\u00facleo do WordPress, e metade das falhas de alto impacto \u00e9 explorada em menos de 24 horas ap\u00f3s ser divulgada publicamente. O CrowdStrike 2026 Threat Hunting Report<\/a> chega a um n\u00famero parecido: 88% dos CVEs com exploit de prova de conceito publicado j\u00e1 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. \u00c9 esse fluxo de resposta que este guia detalha.<\/p>\n\n\n\n Um site comprometido raramente tem um \u00fanico ponto de falha. Arquivos alterados, banco de dados com scripts injetados e credenciais expostas costumam aparecer juntos, e cada pe\u00e7a tem uma depend\u00eancia de ordem: o isolamento precisa vir antes do diagn\u00f3stico, o diagn\u00f3stico precisa vir antes da limpeza, e a limpeza precisa vir antes da rota\u00e7\u00e3o de credenciais.<\/p>\n\n\n\n Quando essa ordem \u00e9 quebrada, o efeito de costume \u00e9 o mesmo: o site volta ao ar limpo, mas reinfecta dias depois, porque a senha usada pelo invasor continuava v\u00e1lida ou o plugin vulner\u00e1vel nunca foi atualizado. Antes de seguir para o passo a passo, vale ter \u00e0 m\u00e3o acesso SSH ou ao terminal do painel de hospedagem, j\u00e1 que a maior parte dos comandos abaixo depende disso.<\/p>\n\n\n\n Coloque o site em modo de manuten\u00e7\u00e3o e troque a senha do painel de hospedagem e do acesso SSH antes de investigar qualquer coisa. Revogue tamb\u00e9m tokens de API de integra\u00e7\u00f5es como gateway de pagamento e webhooks.<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> confirme que o site exibe a p\u00e1gina de manuten\u00e7\u00e3o para visitantes externos e que a senha antiga n\u00e3o funciona mais em uma nova tentativa de login.<\/p>\n\n\n\n Restaurar sem saber por onde o invasor entrou tende a reabrir a mesma porta. Rode os comandos abaixo, nessa sequ\u00eancia, para mapear o que mudou:<\/p>\n\n\n\n Na maioria dos casos, o resultado aponta para um plugin desatualizado, um tema baixado fora do reposit\u00f3rio oficial, ou uma senha reaproveitada de outro servi\u00e7o j\u00e1 vazado.<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> 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.<\/p>\n\n\n\n Antes de deletar qualquer coisa, salve uma c\u00f3pia completa do estado atual, arquivos e banco de dados juntos.<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> confirme que o .tar.gz e o .sql foram gerados com tamanho maior que zero antes de seguir para a limpeza.<\/p>\n\n\n\n Com backup limpo dispon\u00edvel, restaurar \u00e9 o caminho mais r\u00e1pido: volte arquivos e banco ao ponto anterior \u00e0 infec\u00e7\u00e3o e aplique todas as atualiza\u00e7\u00f5es pendentes antes de reativar o site.<\/p>\n\n\n\n Sem backup limpo, a limpeza manual reinstala o essencial a partir de fontes oficiais:<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> rode de novo o grep de fun\u00e7\u00f5es suspeitas do Passo 2 e confirme que o resultado voltou vazio.<\/p>\n\n\n\n A limpeza t\u00e9cnica sem troca de credenciais deixa a porta fechada, mas a chave ainda na m\u00e3o de quem invadiu.<\/p>\n\n\n\n Troque tamb\u00e9m a senha do usu\u00e1rio do banco de dados, as chaves SSH e as credenciais de FTP pelo painel de hospedagem.<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> tente logar com a senha antiga em qualquer servi\u00e7o trocado. Se funcionar, a rota\u00e7\u00e3o n\u00e3o foi completa.<\/p>\n\n\n\n Com o vetor de entrada corrigido, atualize o restante do ambiente e adicione uma camada extra de defesa antes de considerar o caso encerrado.<\/p>\n\n\n\n Um firewall de aplica\u00e7\u00e3o web (WAF) ajuda, mas tem limite: a Patchstack aponta que firewalls tradicionais bloqueiam apenas 12% dos ataques espec\u00edficos a WordPress. O caminho mais s\u00f3lido combina WAF, autentica\u00e7\u00e3o em duas etapas e atualiza\u00e7\u00f5es autom\u00e1ticas para os plugins mais cr\u00edticos.<\/p>\n\n\n\n Verifica\u00e7\u00e3o:<\/strong> confira se todos os plugins aparecem como \u201catualizado\u201d no painel e se o login administrativo agora exige segundo fator.<\/p>\n\n\n\n Se o Google marcou o site como comprometido, a limpeza t\u00e9cnica n\u00e3o remove o aviso automaticamente. \u00c9 preciso acessar o Search Console, na se\u00e7\u00e3o de Seguran\u00e7a e a\u00e7\u00f5es manuais, confirmar que o problema foi resolvido e solicitar a revis\u00e3o descrevendo objetivamente o que foi feito. O prazo de resposta costuma variar de alguns dias a duas semanas, e pedir uma segunda revis\u00e3o antes disso n\u00e3o acelera o processo.<\/p>\n\n\n\nPor que a ordem importa mais que a pressa<\/strong><\/h2>\n\n\n\n
Como recuperar um site hackeado em 6 passos<\/strong><\/h2>\n\n\n\n
1. Isole o site via SSH<\/strong><\/h3>\n\n\n\n
touch \/var\/www\/html\/.maintenance
passwd seu_usuario<\/code><\/pre>\n\n\n\n2. Identifique o vetor de entrada<\/strong><\/h3>\n\n\n\n
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<\/code><\/pre>\n\n\n\n3. Fa\u00e7a um snapshot forense<\/strong><\/h3>\n\n\n\n
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<\/code><\/pre>\n\n\n\n4. Restaure ou limpe arquivo por arquivo<\/strong><\/h3>\n\n\n\n
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<\/code><\/pre>\n\n\n\n5. Rotacione todas as credenciais<\/strong><\/h3>\n\n\n\n
curl -s https:\/\/api.wordpress.org\/secret-key\/1.1\/salt\/
wp user session destroy --all --allow-root<\/code><\/pre>\n\n\n\n6. Atualize tudo e ative uma camada de prote\u00e7\u00e3o<\/strong><\/h3>\n\n\n\n
wp plugin update --all --allow-root
wp theme update --all --allow-root<\/code><\/pre>\n\n\n\nChecklist fazer \/ n\u00e3o fazer<\/strong><\/h3>\n\n\n\n
\u2705 Fazer<\/strong><\/td> \u274c N\u00e3o fazer<\/strong><\/td><\/tr> Isolar o site antes de investigar<\/td> Investigar com o site ainda exposto ao p\u00fablico<\/td><\/tr> Identificar o vetor de entrada antes de limpar<\/td> Restaurar backup sem saber a causa da invas\u00e3o<\/td><\/tr> Rotacionar toda credencial ap\u00f3s a limpeza<\/td> Reativar o site com as senhas antigas<\/td><\/tr> Atualizar plugins, tema e core juntos<\/td> Atualizar s\u00f3 o componente que causou o ataque<\/td><\/tr> Guardar snapshot forense antes de deletar<\/td> Apagar arquivos comprometidos sem c\u00f3pia<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n E, por \u00faltimo, a reputa\u00e7\u00e3o no Google<\/strong><\/h2>\n\n\n\n
Pr\u00f3ximo passo<\/strong><\/h2>\n\n\n\n