Um redirecionamento para um site de apostas, um aviso vermelho no Chrome, um administrador que ninguém conhece: nem todos esses sinais provam uma invasão, e um site comprometido também pode parecer perfeitamente normal. Este artigo oferece um método para chegar a uma conclusão em menos de uma hora: os sinais que devem alertar você, as verificações externas e internas a fazer em ordem, os comandos WP-CLI de verificação de integridade e a leitura dos logs.
Os sinais que devem alertar você
A documentação oficial do WordPress fala em indicadores de comprometimento. Alguns são visíveis para todos; outros, só por ferramentas ou para certos visitantes. A tabela a seguir os classifica conforme o lugar onde devem ser verificados.
| Sinal | O que você nota | Onde verificar primeiro | Nível de alerta |
|---|---|---|---|
| Aviso de navegação | Página vermelha de “site perigoso” no navegador ou aviso nos resultados | Search Console, relatório “Problemas de segurança” | Alto |
| Páginas de spam indexadas | Títulos em japonês, farmácia, falsificações nos resultados do Google | Pesquisa site:seudominio.com.br | Alto |
| Redirecionamentos | Os visitantes que chegam do Google ou de um celular vão parar em outro site | Teste com curl variando Referer e User-Agent | Alto |
| Contas desconhecidas | Administrador criado recentemente, e-mail de recuperação alterado | wp user list --role=administrator | Alto |
| Site suspenso | A hospedagem desativou o site ou aponta envio de spam | E-mail ou suporte da hospedagem | Alto |
| Arquivos modificados | Arquivos do núcleo diferentes do original, PHP em uploads | Somas de verificação do WP-CLI, scanner | Médio a alto |
| Lentidão, picos de tráfego | Carga anormal no servidor, requisições POST a arquivos desconhecidos | Logs de acesso | A confirmar |
Um sinal isolado da última linha não basta: uma lentidão pode vir de um plugin mal escrito ou de uma onda de robôs. Por outro lado, uma conta de administrador desconhecida ou um arquivo PHP na pasta de mídia justificam passar imediatamente para o modo “incidente”.
Por que você não vê nada enquanto o Google vê alguma coisa
Muitos malwares praticam a camuflagem (cloaking): só mostram o redirecionamento ou o conteúdo de spam para certos visitantes. Os critérios habituais são a ausência de cookie de login, a origem a partir de um buscador (cabeçalho Referer), o tipo de dispositivo ou o robô de indexação (cabeçalho User-Agent). Conectado ao seu Painel, você muitas vezes vê um site limpo.
O Google recomenda não abrir diretamente no navegador as páginas apontadas como infectadas, e usar em vez disso a ferramenta de inspeção de URL do Search Console ou o curl, variando o Referer e o User-Agent:
# Como um visitante vindo do Google
curl -s -e "https://www.google.com/" -A "Mozilla/5.0 (Linux; Android 14) Mobile" https://seudominio.com.br/ | head -50
# Como o robô do Google
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://seudominio.com.br/ | head -50
# Só os cabeçalhos: um redirecionamento 301/302 inesperado aparece na hora
curl -sI -e "https://www.google.com/" https://seudominio.com.br/Compare as respostas com a de uma requisição sem opções. Um bloco de links, um script desconhecido ou um cabeçalho Location para outro domínio em apenas uma das variantes é um sinal forte.
As verificações externas, em dez minutos
- Search Console, relatório “Problemas de segurança”: o Google classifica ali os alertas em conteúdo invadido (injeção de código, de conteúdo ou de URL), malware e engenharia social, com exemplos de URL.
- Search Console, proprietários e usuários: um proprietário que você não conhece é, segundo o Google, um forte sinal de comprometimento. Os invasores o adicionam para indexar as suas páginas e enviar os seus próprios sitemaps.
- Pesquisa
site:seudominio.com.br: percorra várias páginas de resultados procurando URLs ou títulos que não sejam seus. - Situação no Safe Browsing: o relatório de transparência do Google indica se o seu domínio está atualmente marcado como perigoso.
- Analisadores remotos: o Sucuri SiteCheck e o VirusTotal examinam o que é publicamente acessível. A própria Sucuri avisa que o SiteCheck não detecta nada no lado do servidor.
Essas verificações não exigem nenhum acesso ao servidor: você pode fazê-las mesmo que não gerencie a hospedagem. Elas não provam a ausência de invasão, porque uma backdoor silenciosa não deixa nenhum rastro visível de fora.
Verificar a integridade dos arquivos com o WP-CLI
O WP-CLI baixa as somas de verificação publicadas pelo WordPress.org e as compara com os seus arquivos. É a verificação mais confiável para o núcleo e para os plugins gratuitos, e ela não carrega o WordPress, o que evita executar código malicioso durante a verificação.
# Núcleo do WordPress, apontando arquivos desconhecidos na raiz
wp core verify-checksums --include-root
# Todos os plugins vindos do wordpress.org
wp plugin verify-checksums --all
# Arquivos PHP presentes na mídia (não deveria haver nenhum)
find wp-content/uploads -type f -name "*.php"
# Arquivos PHP modificados nos últimos 7 dias
find . -type f -name "*.php" -mtime -7Leia com atenção os limites desses comandos:
wp core verify-checksumsaponta os arquivos do núcleo modificados. Sem--include-root, um arquivo adicionado na raiz (por exemplo, um falsowp-user.php) passa despercebido.wp plugin verify-checksumssó compara os plugins publicados no wordpress.org. Os plugins premium precisam ser comparados com um pacote baixado do desenvolvedor.- O WP-CLI não oferece comando equivalente para temas: e o arquivo
functions.phpdo tema ativo é um esconderijo frequente. - A data de modificação de um arquivo é fácil de falsificar: um arquivo aparentemente antigo não está necessariamente limpo.
Contas, plugins ocultos e tarefas agendadas
Os invasores tentam manter o acesso mesmo depois de uma limpeza parcial. Os casos publicados pela Sucuri em 2025 mostram as técnicas comuns: em julho, uma backdoor colocada em wp-content/mu-plugins/wp-index.php criava um administrador oculto chamado “officialwp”; em setembro, um falso plugin “DebugMaster” se removia da lista de plugins e filtrava a lista de usuários, enquanto um arquivo wp-user.php na raiz recriava a conta “help” se ela fosse excluída.
Como essas contas podem ficar ocultas no Painel, consulte diretamente o banco de dados:
# Administradores, com data de cadastro
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Plugins "must-use" e drop-ins, ausentes da lista habitual
wp plugin list --status=must-use
wp plugin list --status=dropin
# Tarefas agendadas: um hook com nome desconhecido merece investigação
wp cron event list- Os plugins da pasta
mu-pluginssão carregados automaticamente, não podem ser desativados pela administração e só aparecem na aba “Obrigatórios”. - Um administrador criado em uma data em que ninguém trabalhou no site, ou com um e-mail descartável, deve ser considerado hostil.
- Verifique também os acessos fora do WordPress: contas FTP ou SFTP, chaves SSH, usuários do banco de dados, contas do painel da hospedagem.
Ler os logs do servidor
Os logs de acesso (access log) respondem a duas perguntas: desde quando, e por onde. A localização depende da hospedagem: seção específica do painel em uma hospedagem compartilhada, muitas vezes /var/log/apache2/ ou /var/log/nginx/ em um servidor que você administra. O arquivo wp-content/debug.log só existe se o registro de depuração estiver ativado, e nunca deve ficar público.
# Requisições POST a arquivos PHP que não são os pontos de entrada habituais
grep "POST " access.log | grep -v -E "wp-login.php|admin-ajax.php|wp-cron.php|xmlrpc.php" | grep "\.php"
# Qualquer acesso a um arquivo PHP da pasta de mídia
grep -E "/wp-content/uploads/.*\.php" access.log
# Endereços IP mais ativos na página de login
grep "wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | headUma requisição POST repetida para um arquivo de nome inofensivo (por exemplo, em uma pasta de tema) e que responde 200 é típica de uma backdoor. Anote o horário da primeira ocorrência: ele serve para escolher um backup anterior à invasão. Os logs costumam ser guardados por pouco tempo; copie-os antes de qualquer outra ação.
Qual ferramenta para qual verificação
| Ferramenta | Tipo | O que ela vê | O que ela não vê |
|---|---|---|---|
| Search Console | Externa, Google | Alertas de segurança, páginas indexadas, proprietários adicionados | Backdoors sem efeito visível |
| Sucuri SiteCheck, VirusTotal | Análise remota | Código malicioso nas páginas públicas, listas de bloqueio | Arquivos no servidor, banco de dados |
| WP-CLI (somas de verificação) | No servidor | Núcleo e plugins do wordpress.org modificados, arquivos sobrando na raiz | Temas, plugins premium, uploads, banco de dados |
| Wordfence (scanner) | Plugin | Assinaturas de malware, comparação com o wordpress.org | Comparação de temas e plugins desativada na varredura padrão; assinaturas gratuitas com 30 dias de atraso |
| Logs de acesso | Servidor | Cronologia, arquivos chamados, endereços IP | Conteúdo dos arquivos |
Nenhuma ferramenta cobre tudo. Combine pelo menos uma verificação externa, uma verificação de integridade no servidor e uma revisão das contas. Para escolher um scanner no servidor, veja o nosso comparativo dos plugins de segurança para WordPress. Se a invasão for confirmada, o próximo passo está no procedimento de limpeza passo a passo.
Detectar mais cedo da próxima vez
O melhor diagnóstico é aquele que você não precisa rodar manualmente. O WP Masquerade Pro inclui uma verificação de integridade do núcleo do WordPress e alertas por e-mail com relatório semanal. A versão gratuita já conta, com as armadilhas para robôs, os robôs que procuram falhas ou arquivos sensíveis. Não é um antivírus nem uma ferramenta de desinfecção: ele complementa um scanner e os seus backups, não os substitui.
Para confirmar uma suspeita infecção por infecção, com os comandos e consultas SQL correspondentes, veja como saber se um site WordPress foi invadido.
Leia também: Site WordPress hackeado: como reagir e consertar.
Para lembrar
- Um site que parece normal quando você está conectado pode estar infectado: teste em janela anônima e com
curlimitando o Google. - Comece pelo Search Console (problemas de segurança e proprietários) e depois verifique os arquivos com
wp core verify-checksums --include-rootewp plugin verify-checksums --all. - Verifique o que as somas de verificação não enxergam: tema,
mu-plugins,uploads, plugins premium, banco de dados. - Liste os administradores pela linha de comando, porque eles podem estar ocultos no Painel.
- Copie os logs imediatamente: eles datam a invasão e orientam a limpeza.
Fontes
- WordPress.org: FAQ My site was hacked (abre em uma nova aba)
- WP-CLI: wp core verify-checksums (abre em uma nova aba)
- WP-CLI: wp plugin verify-checksums (abre em uma nova aba)
- Google: relatório de problemas de segurança (Search Console) (abre em uma nova aba)
Outras fontes consultadas: documentação oficial, páginas oficiais dos fornecedores, publicações de pesquisadores de segurança e banco de dados Wordfence.
