O vosso site não foi atacado porque alguém o escolheu. Foi atacado porque um bot o encontrou. Os ataques a WordPress são 97% automatizados — scanners que percorrem a internet continuamente, identificam instalações WordPress, verificam versões e plugins contra bases de dados de vulnerabilidades conhecidas, e passam à exploração em minutos. Compreender como estes sistemas de reconhecimento funcionam é o primeiro passo para retirar o vosso site do radar.
A Escala do Problema: 90.000 Ataques por Minuto
O WordPress alimenta 43,5% de todos os sites na internet (W3Techs, 2026) e 61,4% de todos os sites com CMS. O segundo maior CMS tem apenas 4,8% de quota de mercado. Esta concentração transforma o WordPress no alvo mais rentável que existe: desenvolver um scanner ou exploit para WordPress significa ter acesso imediato a dezenas de milhões de alvos potenciais com o mesmo esforço.
Os números resultantes são difíceis de assimilar: o Wordfence bloqueou 55 mil milhões de ataques por password em 2024 e mais de 100 mil milhões de tentativas de credential stuffing em 2023, provenientes de 74 milhões de IPs únicos. Estimativas independentes apontam para 13.000 sites WordPress hackeados por dia e 90.000 ataques por minuto contra a plataforma globalmente.
Um novo site WordPress é encontrado por scanners automáticos em horas. Segundo dados da Sophos, um site recebe mais de 2.000 tentativas de ataque automatizado nas primeiras 24 horas após entrar online — antes de qualquer campanha de marketing, antes de ter tráfego real, antes que o proprietário saiba que é um alvo.
Google Dorking: O Motor de Pesquisa Como Ferramenta de Reconhecimento
O Google indexa muito mais do que conteúdo para consumo humano. Indexa caminhos de ficheiros, versões de software, erros de configuração e dados técnicos que proprietários de sites nem sabem que estão expostos. Google Dorking é o uso de operadores de pesquisa avançados para encontrar exactamente esta informação — e não requer nenhuma ferramenta especial além do próprio Google.
A Google Hacking Database (GHDB), mantida pelo Exploit-DB, cataloga centenas de dorks verificados especificamente para WordPress. Alguns exemplos do que é possível encontrar:
inurl:wp-login.php— lista todas as páginas de login WordPress indexadas pelo Google, confirmando imediatamente que são instalações WordPressinurl:"wordpress readme.html"— encontra o ficheiro readme.html que revela a versão exacta do WordPress em texto claro"index of" inurl:wp-content/— identifica sites com listagem de directórios activa; a Patchstack documentou 12 milhões de resultados para esta pesquisa, todos com os ficheiros internos expostos publicamenteinurl:"/wp-content/plugins/[nome-plugin]/"— identifica sites com plugins específicos instalados; cruzando com vulnerabilidades conhecidas, torna-se uma lista de alvos pré-qualificadosfiletype:sql intext:wp_users— encontra dumps de bases de dados SQL com tabelas de utilizadores WordPress, incluindo hashes de passwords
A Patchstack conduziu um teste documentado em que utilizou Google Dorking para descarregar arquivos de backup WordPress de múltiplos servidores e extrair credenciais de base de dados diretamente dos ficheiros wp-config.php encontrados. Nenhum exploit foi necessário — os ficheiros estavam simplesmente acessíveis porque o servidor tinha listagem de directórios activa.
Shodan: O Motor de Pesquisa da Internet das Coisas
Enquanto o Google indexa páginas web para humanos, o Shodan indexa o que os servidores dizem sobre si próprios: cabeçalhos HTTP, versões de software, certificados SSL, banners de serviço. Escaneia activamente o espaço de endereços IPv4 e armazena respostas técnicas completas de cada servidor encontrado.
Uma pesquisa simples por “wordpress” no Shodan devolve 499.108 instalações identificáveis. Com filtros específicos, os resultados tornam-se listas de alvos muito precisas:
http.title:"WordPress › Installation"— instalações WordPress inacabadas, directamente exploráveis: um investigador que documentou esta query conseguiu completar a instalação e obter acesso de administradorhttp.component:"WordPress" country:PT— todos os sites WordPress em Portugal identificados pelo Shodanhttp.title:"Hacked by"— sites já comprometidos (cerca de 2.000 resultados documentados)
O Shodan não está sozinho. Plataformas como ZoomEye (1,2 mil milhões de dispositivos indexados), Censys e FOFA oferecem capacidades similares. O FOFA, em particular, pode devolver dezenas de milhares de instalações WordPress agrupadas por país e versão em segundos — com filtro por CVE para encontrar directamente sistemas afectados por vulnerabilidades específicas.
Quando investigadores analisaram comunicações internas do grupo de ransomware Black Basta, encontraram consultas sistemáticas a estas plataformas antes de cada campanha de ataque. O reconhecimento através de ferramentas públicas é parte do processo operacional de grupos criminosos organizados.
WPScan: A Ferramenta Construída Especificamente Para o WordPress
O WPScan é um scanner de vulnerabilidades open-source para WordPress, escrito em Ruby, pré-instalado no Kali Linux (o sistema operativo padrão de pentesters e atacantes). A sua base de dados tem 64.782+ vulnerabilidades catalogadas, actualizada diariamente. Em 2024 foram adicionadas 7.966 novas entradas; em 2025, 11.334.
O WPScan detecta automaticamente:
- Versão do WordPress — via meta generator tag, parâmetros de versão em CSS/JS, readme.html e feed RSS
- Plugins instalados e versões — testando URLs como
/wp-content/plugins/[plugin]/readme.txtcom uma wordlist de todos os plugins conhecidos; o campo “Stable tag” no readme.txt revela a versão exacta instalada - Temas instalados — método similar via style.css e readme.txt do tema
- Usernames dos utilizadores — usando múltiplos métodos em paralelo (ver secção seguinte)
- Ficheiros sensíveis expostos — backups de wp-config.php, dumps de bases de dados, ficheiros de debug
Com todos estes dados, o WPScan cruza automaticamente contra a sua base de dados de vulnerabilidades e apresenta uma lista de falhas exploráveis com classificação de severidade e links para exploits publicados. O processo completo demora minutos.
O Que o Vosso Site Revela Sem Que Saibam
A maioria dos sites WordPress expõe informação técnica sensível por defeito, sem qualquer configuração incorrecta da parte do proprietário — é simplesmente o comportamento standard da plataforma. Aqui estão os endpoints mais explorados:
/readme.html — Versão Exacta em Texto Claro
Criado automaticamente em cada instalação WordPress. Contém a versão exacta da plataforma em texto claro, sem qualquer autenticação. Um browser aponta para https://vossosite.pt/readme.html e a versão está imediatamente disponível. Cruzada com a base de dados WPScan, confirma em segundos se existe alguma vulnerabilidade conhecida para essa versão.
Meta Generator Tag — Versão no Código HTML
A tag <meta name="generator" content="WordPress 6.x.x"> aparece no <head> de todas as páginas de um site WordPress por defeito. Visível em “Ver código fonte” em qualquer browser. É esta tag que os Shodan, Censys e outros scanners usam para identificar e catalogar instalações WordPress à escala de toda a internet — incluindo a versão exacta.
/wp-json/wp/v2/users — Lista de Utilizadores Sem Autenticação
Endpoint da REST API activo por defeito desde WordPress 4.7. Basta abrir https://vossosite.pt/wp-json/wp/v2/users num browser para obter um JSON com todos os utilizadores do site: username, display name, slug e ID. O WordPress não considera usernames como informação privada — daí a ausência de restrição por defeito. Na prática, conhecer o username é metade do trabalho de um ataque de brute force.
/xmlrpc.php — A Porta de Amplificação de Ataques
Interface de acesso remoto activa por defeito em todas as instalações WordPress. O método system.multicall permite encapsular centenas de tentativas de login numa única chamada HTTP — uma amplificação de 100x ou mais face a ataques directos ao wp-login.php. Mais crítico: contorna completamente plugins de limitação de tentativas de login que monitorizam apenas o formulário standard. Um atacante que ignore o wp-login.php e use exclusivamente xmlrpc.php pode fazer brute force sem que a maioria das protecções activadas o detecte.
/wp-content/plugins/[plugin]/readme.txt — Versão de Cada Plugin
O ficheiro readme.txt standard de cada plugin contém o campo “Stable tag” com a versão exacta instalada. Acessível via URL directa sem autenticação. O WPScan testa sistematicamente estes URLs para todos os plugins conhecidos. Resultado: lista completa de plugins instalados e versões, cruzada com vulnerabilidades conhecidas.
/wp-content/debug.log — Logs de Erro Expostos
Quando o modo debug está activo em produção (configuração comum em sites que tiveram problemas e nunca foram limpos), o WordPress escreve um ficheiro de log em /wp-content/debug.log — publicamente acessível por defeito. O conteúdo típico inclui caminhos completos de ficheiros no servidor, erros de queries SQL com nomes de tabelas, e stack traces com estrutura interna da aplicação.
Em 2024, a vulnerabilidade CVE-2024-44000 do LiteSpeed Cache demonstrou o pior cenário possível: o plugin escrevia cookies de sessão no debug.log, permitindo account takeover sem qualquer autenticação — bastava descarregar o ficheiro de log e usar o cookie. Scanners automáticos testam sistematicamente /wp-content/debug.log em todas as instalações WordPress que encontram.
Como Remover as Pistas
Nenhuma destas exposições é inevitável. Todas têm correção — e a maioria é simples.
Remover a versão WordPress exposta
Eliminar o readme.html via gestor de ficheiros do hosting (atenção: pode ser recriado em actualizações — verificar após cada update). Para a meta generator tag e a versão no RSS, adicionar ao functions.php do tema:
remove_action('wp_head', 'wp_generator');Para remover parâmetros de versão em CSS/JS (os ?ver=6.x.x nos URLs de estilos e scripts), é necessário código adicional no functions.php ou um plugin específico como Remove WordPress Version.
Bloquear a enumeração de utilizadores
Para desactivar o endpoint REST API de utilizadores para visitantes não autenticados, adicionar ao functions.php:
add_filter('rest_endpoints', function($endpoints) {
if (!is_user_logged_in()) {
unset($endpoints['/wp/v2/users']);
unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
}
return $endpoints;
});Bloquear também a enumeração via ?author=1 (que faz redirect para o URL do autor, revelando o username).
Desactivar ou restringir xmlrpc.php
Para a grande maioria dos sites que não usam Jetpack nem clientes de publicação remota, o xmlrpc.php pode ser completamente bloqueado via .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Se usam Cloudflare, uma regra WAF simples — URI igual a /xmlrpc.php → Block — resolve o problema antes de o tráfego chegar ao servidor.
Cloudflare como primeira linha de defesa
O plano gratuito do Cloudflare oferece 5 regras WAF personalizadas — suficientes para cobrir os principais vectores. A vantagem crítica é que o Cloudflare bloqueia o tráfego antes de chegar ao servidor WordPress: scanners como o WPScan e botnets ficam impedidos de sequer contactar os endpoints sensíveis. Com regras simples é possível bloquear xmlrpc.php, colocar em desafio o acesso ao wp-login.php para IPs suspeitos, e bloquear pedidos ao endpoint de utilizadores REST API.
Plugins de hardening
Plugins como Wordfence, Solid Security ou Sucuri aplicam muitas destas configurações de forma automatizada e com interface acessível. Uma configuração correcta deve incluir: remoção da meta generator tag, bloqueio da listagem de utilizadores, restrição do xmlrpc.php, limitação de tentativas de login, e desactivação do editor de ficheiros no painel de administração.
Uma nota importante sobre o Wordfence: 58.848 sites com o Wordfence instalado foram comprometidos em 2024. O plugin é uma camada de defesa valiosa, mas não substitui uma configuração correcta. O WAF gratuito do Wordfence tem regras com 30 dias de atraso face à versão premium — vulnerabilidades recentes ficam cobertas apenas para subscritores pagos.
O Conceito Fundamental: Reduzir a Superfície de Reconhecimento
Nenhuma medida de segurança torna um site completamente indetectável ou invulnerável. O objectivo é diferente: aumentar o custo do ataque ao ponto em que o bot passa para o próximo alvo na lista. Quando o seu site não expõe a versão WordPress, não lista utilizadores, bloqueia o xmlrpc.php e tem limitação de tentativas de login activa, a maioria dos scanners automáticos não encontra pontos de entrada fáceis e segue em frente.
Os ataques são indiscriminados e automatizados. A selecção do alvo é feita por critérios de facilidade, não de valor. Remover as pistas que os scanners procuram é remover o vosso site da lista de alvos óbvios.
Quer saber o que o vosso site está a revelar aos scanners automáticos? Na OnePixel fazemos auditorias de segurança WordPress que incluem análise de exposição de informação técnica, configuração de hardening e implementação das protecções correctas. Fale connosco para uma análise sem compromisso.
Deixe um comentário