WordPress pirateado: 12 sinais e como verificar cada um

Os sinais mais claros de que um site WordPress foi pirateado são contas de administrador que ninguém criou, ficheiros PHP onde só deviam existir imagens e páginas de spam ou redirecionamentos que nunca aparecem no ecrã do próprio dono. A maior parte destes sinais é discreta de propósito: os atacantes querem que o site continue a funcionar, por isso escondem-se dos administradores com sessão iniciada e só mostram o conteúdo malicioso aos motores de pesquisa ou a determinados visitantes.

Seguem-se 12 sinais, agrupados pelo local onde costumam ser detetados, cada um com uma forma concreta de verificação. Várias verificações usam o WP-CLI, a linha de comandos do WordPress. O gestor de ficheiros e a ferramenta de base de dados do alojamento também servem, só que são mais lentos.

WordPress pirateado? Sinais que os visitantes notam

1. Redirecionamentos só no telemóvel ou a partir do Google

Muitas infeções redirecionam apenas parte dos visitantes: quem navega no telemóvel ou quem chega através de uma pesquisa no Google. As políticas de spam do Google descrevem os dois truques: o cloaking (conteúdo diferente para motores de pesquisa e para pessoas) e o redirecionamento de utilizadores móveis para um domínio de spam. Quem escreve o endereço no computador vê um site normal e não dá por nada.

Como verificar: no telemóvel, com dados móveis e sem sessão iniciada, pesquise o site no Google e toque no resultado. Num terminal, compare um pedido simples com o de um "visitante móvel vindo do Google":

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' \
  -e 'https://www.google.com/' https://example.com/

Um 301 ou 302 para um domínio estranho, apenas no segundo resultado, é um sinal de alerta forte. Os redirecionamentos feitos em JavaScript não aparecem desta forma, por isso procure também scripts desconhecidos no código-fonte da página.

2. Avisos do navegador ou do antivírus

Um aviso do navegador em ecrã inteiro a alertar para um site enganador, ou clientes a dizer que o antivírus bloqueou o site, significa normalmente que uma lista de bloqueio já detetou malware ou phishing no domínio. Como verificar: consulte o domínio na página de estado dos sites do Safe Browsing da Google e peça uma captura de ecrã do aviso exato.

Sinais nos resultados de pesquisa do Google

3. Páginas de spam nos resultados de site:

Páginas injetadas de casinos, farmácias ou imitações de marcas aparecem muitas vezes no Google antes de darem nas vistas noutro lado. Como verificar: pesquise site:example.com e procure títulos noutras línguas ou temas que nunca publicou. Acrescentar palavras como casino, viagra ou loan ajuda a afunilar a pesquisa.

4. Problemas de segurança na Search Console

Se o site estiver verificado na Google Search Console, abra Segurança e ações manuais → Problemas de segurança. É aí que o Google lista os problemas que detetou, como conteúdo pirateado ou malware. Como verificar: confirme que a propriedade está verificada e que as mensagens chegam a alguém que as lê. Um relatório vazio é uma boa notícia, mas não é uma prova.

Sinais no servidor e na conta de alojamento

5. Conta suspensa ou consumo elevado de CPU

Os fornecedores de alojamento suspendem contas que enviam spam, servem páginas de phishing ou sobrecarregam o servidor. Um pico de CPU sem aumento de visitas pode indicar que há um minerador de criptomoedas ou um script de spam a correr na conta. Como verificar: leia a mensagem do fornecedor até ao fim (muitas vezes indica os ficheiros em causa) e veja os gráficos de recursos no painel de controlo. Com acesso SSH, ps aux --sort=-%cpu | head mostra os processos mais ativos.

6. Envio de spam e IP em listas negras

Se os seus e-mails começarem a ser devolvidos, ou se receber devoluções de mensagens que nunca enviou, pode haver um script a enviar spam através do servidor. Como verificar: pergunte ao fornecedor de alojamento se o volume de correio enviado mudou e consulte o endereço IP do servidor num verificador público de listas de bloqueio.

7. Ficheiros PHP em wp-content/uploads

A pasta de uploads deve conter imagens e documentos, não código. Um ficheiro PHP ali é muitas vezes uma web shell, uma backdoor que permite ao atacante executar comandos. Como verificar:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

Alguns plugins colocam um index.php vazio nas suas pastas para impedir a listagem do diretório. Abra cada resultado e veja o que contém de facto.

8. Ficheiros do núcleo alterados

Os atacantes gostam de esconder código nos ficheiros do núcleo do WordPress, porque ninguém os lê. Como verificar: wp core verify-checksums compara os ficheiros do núcleo com as somas de verificação oficiais do WordPress.org e avisa de cada ficheiro que não corresponda (referência do comando). wp plugin verify-checksums --all faz o mesmo para os plugins, mas apenas para os que estão alojados no WordPress.org.

9. Alterações inesperadas no .htaccess ou no wp-config.php

Bastam algumas linhas a mais no .htaccess para redirecionar os visitantes consoante a página de origem ou o navegador. Uma linha no wp-config.php, ou uma diretiva auto_prepend_file no .user.ini, pode carregar malware antes de o WordPress sequer arrancar. Como verificar: compare os dois ficheiros com a última cópia de segurança fiável e procure truques típicos de ofuscação e de prepend:

grep -rnE --include='*.php' 'eval\(|base64_decode\(|gzinflate\(|str_rot13\(' . | head -50
grep -rn 'auto_prepend_file' --include='.htaccess' --include='.user.ini' --include='php.ini' .

Há plugins legítimos que também usam algumas destas funções, por isso cada resultado é uma pista e não um veredicto.

Sinais no painel do WordPress

10. Administradores desconhecidos

Criar uma nova conta de administrador é a forma clássica de manter o acesso, e há malware que esconde essa conta do ecrã Utilizadores. Como verificar:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

As duas opções --skip impedem que o código normal dos plugins e do tema, incluindo malware que lá se esconda, filtre a lista. Os plugins must-use e o wp-config.php continuam a ser carregados, por isso verifique-os também (sinais 9 e 11). Se o WP-CLI mostrar mais administradores do que o ecrã Utilizadores, há alguma coisa a esconder uma conta. Veja ainda, no perfil de cada administrador, se existem Application Passwords (palavras-passe de aplicação) que ninguém da equipa criou.

11. Plugins que ninguém instalou

Procure plugins com nomes genéricos, sem autor ou sem descrição, que ninguém na equipa se lembra de ter instalado. Os plugins must-use, em wp-content/mu-plugins, são carregados automaticamente e passam facilmente despercebidos. Como verificar: wp plugin list mostra os plugins normais juntamente com os must-use e os drop-ins, como o object-cache.php; wp plugin list --status=must-use,dropin mostra apenas estes dois últimos grupos.

12. Tarefas cron estranhas

O malware agenda-se muitas vezes a si próprio para poder voltar depois de ser apagado. Como verificar:

wp cron event list --fields=hook,next_run_relative,recurrence

Investigue cada hook que não consiga associar a um plugin que utiliza. As tarefas cron do servidor também contam: crontab -l ou a secção de cron do painel de alojamento mostram-nas.

O que fazer na primeira hora

Se um ou mais destes sinais apontarem para um ataque, a hora seguinte decide quanto ainda será possível apurar. Trabalhe com calma e por esta ordem:

1. Não apague nada em pânico. Apagar o ficheiro suspeito ou o administrador desconhecido destrói provas e raramente elimina a infeção por completo, porque os atacantes deixam muitas vezes mais do que uma porta de regresso.
2. Preserve as provas. Faça um snapshot ou uma cópia de segurança completa dos ficheiros e da base de dados no estado comprometido e descarregue os registos de acesso e de erros do servidor web, que muitos fornecedores guardam apenas durante um período limitado. Guarde a cópia offline e identifique-a como infetada.
3. Mude as palavras-passe a partir de um dispositivo limpo. Comece pela conta de alojamento e siga para o SFTP/SSH, a base de dados e todos os administradores do WordPress. Se o seu próprio computador puder estar comprometido, use outro, e ative a autenticação de dois fatores para todos os administradores.
4. Contacte o fornecedor de alojamento. Tem acesso aos registos do servidor, aos outros sites da mesma conta e ao correio enviado, e consegue muitas vezes isolar o site rapidamente.
5. Anote a hora. Registe quando teve conhecimento do ataque pela primeira vez e o que observou até agora.

O último ponto é importante para o RGPD. Se o atacante pôde aceder a dados de clientes, mensagens de formulários de contacto, contas de utilizador ou encomendas, o ataque constitui normalmente uma violação de dados pessoais. O artigo 33.º do RGPD obriga a notificar a autoridade de controlo (em Portugal, a CNPD) sem demora injustificada e, sempre que possível, no prazo de 72 horas após ter tido conhecimento da violação, a menos que esta não seja suscetível de resultar num risco. O nosso guia sobre a notificação de violações de dados em 72 horas explica como fazer esta avaliação.

Com as provas a salvo, continue com o nosso plano passo a passo para remover malware do WordPress: conter o site, encontrar o ponto de entrada, limpar a partir de fontes fidedignas e renovar todas as credenciais.

O Security Audit & Compliance, o plugin WordPress da secaudit.eu, verifica por si vários destes sinais, incluindo contas de administrador ocultas, eventos cron suspeitos, somas de verificação do núcleo, alterações de ficheiros face a uma linha de base e spam SEO oculto. Deteta e reporta; remover o malware continua a ser trabalho seu ou de um profissional.

Perguntas frequentes

Um site pode estar pirateado sem qualquer sinal visível?

Sim. Muitas infeções são feitas para passarem despercebidas ao dono: ignoram utilizadores com sessão iniciada, visam apenas os motores de pesquisa ou correm só no servidor. É por isso que as verificações acima vão além de olhar para a página inicial.

Qualquer ataque é uma violação de dados nos termos do RGPD?

Nem todos, mas muitos são. Se houve acesso a dados pessoais, ou se estes foram alterados, perdidos ou ficaram indisponíveis, trata-se de uma violação de dados pessoais. Documente a avaliação em qualquer caso: o artigo 33.º, n.º 5, exige um registo de todas as violações, incluindo as que não são notificadas.

Devo repor já a cópia de segurança de ontem?

Só depois de guardar o estado infetado e de saber, pelo menos aproximadamente, quando começou o ataque. Uma cópia feita depois da intrusão também contém a backdoor, e repor sem fechar o ponto de entrada deixa o atacante voltar a entrar de imediato.

Este artigo contém informação geral e não constitui aconselhamento jurídico.