Como recuperar site WordPress invadido

Quando um site WordPress é comprometido, o que está em jogo é mais do que a presença digital: a reputação da empresa, o ranqueamento orgânico construído ao longo de meses e a confiança de clientes e parceiros ficam em risco junto. Recuperar site WordPress invadido exige processo técnico estruturado, auditoria completa do ambiente e, ao final, um plano de prevenção para que o problema não se repita.

Este guia detalha as etapas reais de uma recuperação bem-feita, baseado na experiência da Digital Pixel com projetos como o do Banco Semear, onde um hardening de segurança com mais de 100 pontos auditados foi a base para a evolução digital do site.

O que acontece quando um site WordPress é invadido

Antes de partir para a recuperação, vale entender o que de fato ocorre quando um site é comprometido. Uma invasão raramente é visível de imediato. Na maioria dos casos, o atacante entra, instala backdoors e permanece oculto por dias ou semanas antes de qualquer ação perceptível.

Os sintomas mais comuns incluem:

• Redirecionamentos automáticos para sites externos suspeitos
• Páginas de spam indexadas no Google (verificável via Search Console)
• Avisos de segurança do navegador Chrome ou Firefox
• Suspensão do domínio pela hospedagem por envio de spam
• Lentidão extrema por uso indevido dos recursos do servidor
• Desfiguração visual do site (defacement)
• E-mails em massa enviados pelo servidor do domínio
• Contas de administrador criadas sem autorização

Em ambientes corporativos, o impacto ultrapassa a visibilidade. Clientes que tentam acessar o site e encontram avisos de segurança perdem a confiança. O Google pode desindexar páginas ou reduzir o ranqueamento. O tempo de inatividade tem custo direto em leads e vendas.

Por onde começa o processo técnico de recuperação

A recuperação de um site WordPress invadido não começa pela remoção do malware. Começa pelo isolamento e diagnóstico. Pular essa etapa é o erro mais comum: limpar arquivos sem entender a origem da invasão garante que o atacante voltará pelo mesmo caminho.

Isolamento do ambiente

O primeiro passo técnico é colocar o site em modo de manutenção ou substituir temporariamente o index.php por uma página neutra. Isso protege visitantes do malware enquanto o trabalho de limpeza acontece, e evita que o Google continue rastreando e indexando páginas comprometidas.

Em paralelo, notifique a hospedagem. Muitos provedores bloqueiam o envio de e-mail ou limitam recursos quando detectam atividade suspeita. Trabalhar junto ao suporte da hospedagem agiliza a liberação dos logs de acesso ao servidor, que são indispensáveis na etapa de diagnóstico.

Coleta de logs e identificação do vetor de entrada

Sem identificar como o atacante entrou, qualquer limpeza é temporária. Os vetores mais comuns em WordPress são:

• Credenciais comprometidas: senha do painel administrativo ou do FTP vazada, reutilizada de outro serviço ou descoberta por força bruta
• Plugin ou tema vulnerável: versão desatualizada com vulnerabilidade conhecida e publicada no banco CVE (Common Vulnerabilities and Exposures)
• Tema ou plugin nulo (pirata): software premium obtido ilegalmente que já vem com backdoor embutido
• Arquivo PHP com upload sem validação: formulários ou plugins que permitem envio de arquivos sem verificar o tipo
• Permissões incorretas no servidor: pastas com permissão 777 que permitem escrita por qualquer usuário
• Hospedagem compartilhada comprometida: outro site no mesmo servidor infectado e o ataque se propagou lateralmente

A análise de logs do servidor (access.log e error.log do Apache ou Nginx) mostra os IPs que acessaram o site, os arquivos requisitados e os horários das requisições. Um técnico experiente identifica o padrão de ataque e o arquivo de entrada a partir dessas informações.

Auditoria completa dos arquivos e banco de dados

Com o vetor identificado, começa a auditoria dos arquivos. O objetivo é mapear tudo que foi alterado, adicionado ou removido em relação a uma instalação limpa do WordPress.

Verificação de integridade dos arquivos do core

Os arquivos do núcleo do WordPress (wp-admin/, wp-includes/ e os arquivos da raiz como wp-login.php, wp-config.php, index.php) não devem ser modificados manualmente em uma instalação saudável. Comparar os arquivos presentes com os arquivos originais da versão correspondente do WordPress revela inserções de código malicioso.

Uma auditoria técnica verifica também:

• Arquivos PHP criados fora dos diretórios esperados (por exemplo, dentro de /uploads/)
• Funções PHP ofuscadas com base64_decode, eval, str_rot13 ou gzinflate
• Iframes ocultos e scripts externos injetados em templates
• Modificações na data de edição de arquivos que não deveriam ter sido tocados
• Arquivos com nomes que imitam arquivos legítimos (wp-logln.php, wp-admins.php)

Verificação do banco de dados

O banco de dados também é um alvo. Ataques comuns inserem código JavaScript malicioso em posts e páginas, criam contas de administrador ocultas ou alteram as opções do site para redirecionar visitantes.

A auditoria do banco inclui:

• Verificação de usuários administradores não autorizados na tabela wp_users
• Busca por scripts JavaScript suspeitos em wp_posts, wp_postmeta e wp_options
• Verificação das opções siteurl e home para redirecionamentos
• Identificação de dados de spam ou phishing inseridos em conteúdo

Limpeza técnica: o que remover e como

Com o mapeamento completo, a limpeza pode ser executada com precisão: remover exatamente o que foi comprometido, sem apagar conteúdo legítimo ou quebrar funcionalidades.

Substituição dos arquivos do core

Os arquivos do núcleo do WordPress precisam ser substituídos por cópias limpas da versão oficial. Isso elimina qualquer modificação injetada no core sem risco de perder conteúdo, que está no banco de dados e nos uploads.

Limpeza ou substituição de plugins e temas

Plugins e temas comprometidos precisam ser substituídos pelas versões originais atualizadas. Se um plugin ou tema não tem atualização disponível ou foi descontinuado, remova-o. Manter um plugin sem suporte ativo é risco permanente.

Remoção de backdoors

Esta é a etapa mais delicada. Backdoors são arquivos ou trechos de código que permitem ao atacante voltar ao ambiente mesmo depois da limpeza. O atacante os instala em múltiplos locais para garantir persistência. Uma varredura única não basta: a auditoria precisa cobrir todos os diretórios, incluindo pastas de cache e uploads.

Limpeza do banco de dados

Conteúdo malicioso inserido no banco de dados precisa ser removido com cuidado. Scripts automáticos de limpeza podem ajudar, mas precisam de revisão manual para evitar remoção de conteúdo legítimo.

Recuperação de SEO após invasão

Uma das consequências mais duradouras de uma invasão é o impacto no SEO. O Google pode penalizar o domínio, desindexar páginas ou exibir alertas de segurança nos resultados de busca. Recuperar o ranqueamento orgânico requer ações específicas no Google Search Console.

Verificação no Search Console

Após a limpeza, o Search Console mostra se o Google identificou malware ou conteúdo enganoso no site. Há relatórios específicos para isso em “Problemas de segurança”. O passo seguinte é solicitar uma revisão manual ao Google, que pode levar alguns dias para ser processada.

Verificação de páginas de spam indexadas

Muitos ataques criam centenas ou milhares de páginas de spam indexadas no Google (farmácias falsas, apostas, conteúdo adulto). Essas páginas precisam ser identificadas via Search Console ou por buscas diretas (site:seudominio.com.br), e então removidas do servidor e do índice do Google via ferramenta de remoção de URLs.

Verificação de backlinks suspeitos

Alguns ataques inserem links para outros sites em posts e páginas. Esses links precisam ser removidos para evitar penalização por links artificiais. A auditoria de backlinks via Google Search Console ou ferramentas como Ahrefs identifica links externos que saem do site sem autorização.

Como o caso Banco Semear ilustra a importância de um processo estruturado

No projeto do Banco Semear, a Digital Pixel conduziu um hardening de segurança com mais de 100 pontos auditados antes de qualquer evolução visual ou de SEO. O mesmo princípio vale para uma recuperação: segurança não é uma camada que se adiciona por cima. É a fundação sobre a qual tudo o mais é construído.

O projeto identificou vulnerabilidades específicas como URLs de administração no padrão, IDs sequenciais expostos e plugins desatualizados. Corrigir esses pontos antes de investir em SEO e CRO foi o que garantiu resultados duráveis nas fases seguintes, sem que uma nova invasão os comprometesse.

Para um banco, um site comprometido é mais do que um problema de imagem: é um risco regulatório. A mesma lógica vale para qualquer empresa que opera em setores sensíveis ou que depende do site para geração de leads e relacionamento com clientes.

Hardening pós-recuperação: o que precisa mudar

Recuperar o site sem endurecer o ambiente é adiar o problema. Após a limpeza completa, implemente as seguintes medidas:

Credenciais e acessos

• Trocar todas as senhas: painel WordPress, FTP/SFTP, banco de dados, hospedagem, e-mail
• Revogar chaves de API e tokens de integrações que possam ter sido expostos
• Remover todos os usuários não reconhecidos no painel
• Implementar autenticação de dois fatores para administradores
• Alterar o prefixo das tabelas do banco de dados (padrão wp_ é bem conhecido)

Configuração do WordPress

• Mover ou proteger o wp-config.php
• Desabilitar a edição de arquivos diretamente pelo painel (DISALLOW_FILE_EDIT)
• Restringir o acesso ao wp-login.php e /wp-admin/ por IP ou senha adicional
• Alterar a URL de acesso ao painel administrativo
• Configurar headers de segurança HTTP (CSP, X-Content-Type-Options, X-Frame-Options)

Plugins e temas

• Remover todos os plugins inativos (mesmo desativados, os arquivos ficam no servidor)
• Remover temas não utilizados
• Manter WordPress, plugins e temas sempre atualizados
• Usar apenas plugins e temas de fontes confiáveis com histórico de atualizações

Servidor e hospedagem

• Revisar e corrigir permissões de arquivos e pastas
• Configurar WAF (Web Application Firewall)
• Ativar monitoramento de integridade de arquivos
• Verificar se outros sites no mesmo servidor foram afetados
• Considerar migração para hospedagem com isolamento adequado de ambientes

Backup verificado: a proteção que a maioria ignora

Uma recuperação bem-feita também avalia o backup disponível. Se o ambiente tem backups regulares, é possível restaurar para uma versão anterior à invasão como ponto de partida, e então verificar se a versão restaurada já estava comprometida (o que é comum quando o ataque permanece silencioso por semanas).

Backup verificado significa ter o arquivo de backup e ter testado a restauração. Muitas empresas descobrem que os backups existem mas não funcionam no momento em que mais precisam. Uma rotina de backup adequada inclui:

• Backups diários automáticos em local externo ao servidor, fora da própria hospedagem
• Retenção de múltiplas versões (7, 14, 30 dias) para poder voltar a um ponto anterior à invasão
• Teste periódico de restauração em ambiente separado
• Backup separado do banco de dados e dos arquivos

Quando contratar um especialista para recuperar site WordPress invadido

A pergunta não é se vale contratar um especialista. É quanto tempo e reputação a empresa pode perder tentando resolver internamente antes de acionar suporte qualificado.

Ferramentas gratuitas como Wordfence ou Sucuri podem identificar sintomas e remover malware conhecido, mas têm limitações claras: não identificam backdoors sofisticados, não auditam o banco de dados com profundidade, não recuperam o SEO e não entendem o contexto do ambiente específico da empresa.

Um especialista em recuperação WordPress entrega:

• Diagnóstico da origem real da invasão, além dos sintomas imediatos
• Limpeza completa incluindo backdoors e persistências ocultas
• Relatório técnico com evidências do que foi encontrado e removido
• Plano de hardening específico para o ambiente
• Acompanhamento pós-recuperação para confirmar que o ambiente está limpo

Perguntas frequentes sobre recuperação de site WordPress invadido

Quanto tempo leva para recuperar um site WordPress invadido?

Depende da complexidade do ataque e do estado do ambiente. Casos simples, com malware identificável e backup disponível, podem ser resolvidos em algumas horas. Ataques mais sofisticados, com múltiplos backdoors, banco de dados comprometido e ausência de backup limpo, podem levar de 1 a 3 dias de trabalho técnico.

É possível recuperar o ranqueamento no Google após uma invasão?

Sim, mas o processo exige ação ativa no Google Search Console: solicitação de revisão após a limpeza, remoção de URLs de spam indexadas e monitoramento por algumas semanas. O tempo de recuperação depende da extensão do dano e da velocidade de reindexação do Google, que geralmente leva entre 1 e 4 semanas após a revisão ser aprovada.

O que fazer imediatamente ao descobrir que o site foi invadido?

Primeiro: não apague nada sem diagnóstico. Segundo: coloque o site em manutenção para proteger visitantes. Terceiro: entre em contato com o suporte da hospedagem para solicitar os logs de acesso. Quarto: acione um especialista para conduzir o diagnóstico e a limpeza. Agir por conta própria sem entender o vetor de entrada pode piorar a situação ou eliminar evidências que facilitariam a recuperação.

Como saber se o meu site WordPress foi invadido mesmo sem sintomas visíveis?

O Google Search Console é o primeiro lugar a verificar: há um relatório de problemas de segurança que mostra se o Google identificou malware, redirecionamentos ou conteúdo enganoso no site. Ferramentas como Sucuri SiteCheck fazem uma varredura externa. Uma auditoria técnica completa dos arquivos do servidor é a forma mais confiável de identificar comprometimentos silenciosos.