WordPress hackeado: guia de recuperação para agências

Uma das situações mais stressantes para qualquer agência é receber a mensagem: "o site do meu cliente foi hackeado". A pressão é imediata, o cliente está em pânico, e cada minuto conta. Este guia apresenta o processo de recuperação passo a passo — desde a identificação do comprometimento até ao hardening final — para que a sua equipa saiba exatamente o que fazer quando o pior acontece.

Como identificar que um site WordPress foi hackeado

Nem todos os comprometimentos são óbvios. Os atacantes modernos preferem permanecer invisíveis — um site hackeado silenciosamente durante semanas ou meses é muito mais valioso para fins de spam, phishing ou distribuição de malware do que um site desfigurado. Conhecer os sinais permite detetar o problema mais cedo.

Sinais visíveis imediatos

Redirecionamentos para spam: o site redireciona visitantes (especialmente os vindos do Google) para farmácias online, casinos ou páginas de phishing. A redireção é muitas vezes condicional — só acontece para utilizadores anónimos ou para tráfego de motores de busca, tornando-a difícil de detetar por quem faz login regularmente.

Conteúdo injetado: links ocultos de spam aparecem no rodapé, em posts ou em páginas — frequentemente com display:none ou cor igual ao fundo. Só são visíveis no código fonte.

Páginas novas e desconhecidas: o Google Indexação mostra URLs que nunca foram criadas — páginas de produtos falsos, conteúdo em línguas estrangeiras, ou subdiretórios inexistentes.

Sinais de bloqueio e alerta

Google Safe Browsing / Chrome: o browser apresenta aviso vermelho "O site contém software nocivo" ou "Site enganoso". Este é um dos sinais mais graves — significa que o Google detetou malware ativo e o site está a afetar utilizadores em tempo real.

Blacklist do hosting: o servidor suspende o site ou bloqueia envio de emails devido a atividade de spam detetada. O hosting recebe muitas vezes alertas antes da agência.

Google Search Console: alerta de "Problemas de segurança" — o GSC reporta malware, conteúdo hackeado ou phishing detetado durante o crawl.

Sinais de acesso comprometido

Impossibilidade de acesso ao wp-admin: a password deixou de funcionar ou a conta de administrador foi eliminada. O atacante pode ter criado uma nova conta admin e removido as existentes.

Utilizadores admin desconhecidos: na listagem de utilizadores aparecem contas com nomes aleatórios ou emails suspeitos com role de Administrador.

Emails de recuperação de password não chegam: o servidor de email foi reconfigurado pelo atacante para intercetar comunicações.

Passo 1 — Contenção imediata

Antes de qualquer limpeza, é preciso conter o incidente. Agir sem contenção prévia pode piorar a situação — limpar malware enquanto o atacante mantém acesso é trabalho perdido.

Colocar o site em manutenção

Ativar uma página de manutenção imediatamente. Se o acesso ao wp-admin ainda for possível, utilizar um plugin de maintenance mode. Se não, criar um ficheiro maintenance.php no root e adicionar ao .htaccess:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^SEU_IP$
RewriteCond %{REQUEST_URI} !/maintenance.php$
RewriteRule ^(.*)$ /maintenance.php [R=302,L]

Isto protege os visitantes de serem expostos a malware enquanto o trabalho de limpeza decorre, e evita que o Google continue a indexar conteúdo comprometido.

Revogar todos os acessos

Alterar imediatamente: password do wp-admin de todos os utilizadores, password do painel de hosting/cPanel, password FTP/SFTP, password de base de dados, chaves de API do site (payment gateways, email marketing, etc.). Se houver acesso SSH, revogar chaves e regenerar.

Não comunicar as novas credenciais por email — um email comprometido pode expor as novas passwords. Usar um gestor de passwords partilhado com a equipa.

Preservar evidências

Antes de qualquer alteração de ficheiros, guardar cópias dos logs do servidor: access.log e error.log. Estes logs podem revelar como a entrada ocorreu — qual a vulnerabilidade explorada, quando, e a partir de que IP. São essenciais para o relatório ao cliente e para evitar a mesma vulnerabilidade no futuro.

Passo 2 — Diagnóstico e limpeza

A limpeza de um site WordPress comprometido requer abordagem sistemática. Fazer uma limpeza superficial — remover apenas o malware visível — é um dos erros mais comuns. Os atacantes instalam múltiplos backdoors precisamente para sobreviver a limpezas parciais.

Scan de malware com Wordfence

Instalar e ativar o Wordfence Security (versão gratuita é suficiente para o scan inicial). Executar scan completo via Wordfence › Scan › Start New Scan. O scanner vai comparar todos os ficheiros WordPress com as versões oficiais e sinalizar alterações, ficheiros suspeitos e malware conhecido.

Analisar os resultados com atenção. Nem tudo o que o Wordfence sinaliza é malware — personalizações legítimas também aparecem. Mas qualquer ficheiro PHP em /wp-content/uploads/ é suspeito por definição, assim como ficheiros core do WordPress com conteúdo diferente do original.

Verificar ficheiros alterados via checksums

O WP-CLI permite verificar a integridade dos ficheiros core do WordPress comparando com os checksums oficiais:

wp core verify-checksums
wp plugin verify-checksums --all

Qualquer ficheiro que falhe a verificação foi modificado. Para ficheiros core, a solução é reinstalar o WordPress: wp core download --force. Para plugins comprometidos, reinstalar a partir do repositório oficial.

Limpar backdoors e rever utilizadores admin

Backdoors são o mecanismo de reentrada do atacante. As localizações mais comuns são: ficheiros PHP com funções eval(base64_decode(...)), system(), ou exec(); ficheiros .php disfarçados de imagens ou com nomes que imitam ficheiros legítimos (wp-logln.php, wp-includes/class.wp.php); ficheiros em /wp-content/uploads/ que não deveriam nunca conter PHP executável.

Verificar também a tabela wp_users diretamente na base de dados — contas admin criadas via SQL não aparecem em logs normais. Verificar igualmente a tabela wp_options para valores suspeitos nos campos siteurl e home, e procurar código injetado em active_plugins ou na opção template.

Passo 3 — Recuperação e hardening

Após a limpeza, o site precisa de ser restaurado a um estado funcional e seguro. A decisão principal é: limpar o site infetado ou restaurar um backup limpo.

Restaurar backup limpo vs. limpeza manual

Restaurar backup: é a opção mais segura quando existe um backup verificado anterior ao comprometimento. A data de comprometimento pode ser estimada pelos logs do servidor — procurar o primeiro acesso suspeito. Se o backup for anterior a essa data, o restore é limpo. A desvantagem é a perda de conteúdo criado entre o backup e o incidente.

Limpeza manual: necessária quando não existe backup limpo ou quando a perda de conteúdo é inaceitável. É mais demorada e requer mais expertise — existe sempre o risco de deixar passar um backdoor. Deve ser complementada com uma reinstalação completa dos ficheiros core.

Em qualquer caso, após o restore ou limpeza, executar novamente o scan completo para confirmar que o site está limpo antes de reativar.

Alterar todas as passwords e forçar 2FA

Após a recuperação, alterar todas as passwords novamente — as alteradas na contenção foram feitas com o servidor possivelmente ainda comprometido. Implementar autenticação de dois fatores para todas as contas de administrador. Plugins como WP 2FA ou Wordfence Login Security permitem forçar 2FA para roles específicos.

Gerar novas secret keys do WordPress — as chaves antigas podem ter sido comprometidas e estar a ser usadas para manter sessões autenticadas. Atualizar no wp-config.php usando o gerador oficial em https://api.wordpress.org/secret-key/1.1/salt/.

Atualizar tudo e rever permissões de ficheiros

Atualizar WordPress core, todos os plugins e todos os temas para as versões mais recentes. Se um plugin não tem atualização disponível e é conhecido por ter vulnerabilidades, removê-lo. Verificar permissões de ficheiros: wp-config.php deve ter permissões 400 ou 440; ficheiros PHP devem ter 644; diretórios devem ter 755. Nunca 777.

Solicitar ao hosting a remoção do site das blacklists internas e submeter pedido de revisão no Google Search Console (em "Problemas de segurança") após confirmar que o site está limpo.

Como prevenir futuros ataques

A recuperação de um site hackeado é cara — em tempo, em reputação e na relação com o cliente. A prevenção é sempre mais eficiente. As três áreas críticas são:

Monitorização proativa

Um sistema de monitorização 24/7 deteta anomalias antes de chegarem a ser incidentes declarados: mudanças inesperadas no DNS, certificados SSL com problemas, uptime, e alertas de blacklist. A deteção precoce reduz dramaticamente o impacto de um comprometimento.

Atualizações regulares e controladas

A grande maioria dos comprometimentos WordPress explora vulnerabilidades já corrigidas em versões mais recentes — o problema é que os sites não estão atualizados. Um processo de atualizações mensais controladas, com testes em staging antes da aplicação em produção, elimina a maioria das superfícies de ataque.

Suporte técnico rápido quando algo falha

Quando um site é comprometido, cada hora conta. Ter acesso a suporte técnico urgente com SLA definido faz a diferença entre um incidente resolvido em horas e uma crise que se prolonga por dias — com todo o impacto reputacional que isso implica para a agência e para o cliente.