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. Para os fundamentos básicos de segurança WordPress e proteção de sites antes de chegar às técnicas avançadas descritas aqui, vê o guia introdutório.
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. O credential stuffing é o vetor mais comum — e a defesa começa por passwords únicas, 2FA e passkeys. Para a configuração específica de autenticação de dois fatores (2FA) no WordPress, vê o guia dedicado.
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 WordPress (razão pela qual alterar a URL de login é uma camada de segurança eficaz)inurl:"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 (as variáveis de ambiente WordPress são uma alternativa mais segura para armazenar credenciais fora do webroot). 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. Para saber o que um atacante vê ao auditar o vosso site — e como usar estas ferramentas defensivamente — vê o guia de scanners de segurança WordPress.
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. O guia de segurança da API REST WordPress cobre todos os endpoints expostos e as configurações para os proteger — a mesma REST API serve também arquiteturas de WordPress headless, onde frontends em React ou Next.js consomem conteúdo via JSON ou, com o WPGraphQL, via queries GraphQL mais eficientes.
/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 — ou encapsular num plugin WordPress personalizado para portabilidade entre projetos:
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;
});Este filtro usa a API de hooks WordPress (actions e filters) para modificar o comportamento do core sem editar os seus ficheiros; o guia de autenticação REST API WordPress cobre JWT e Application Passwords para quem precisa de proteger estes endpoints com credenciais.
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. O xmlrpc.php é também a principal porta de entrada para spam de comentários e trackbacks automatizados.
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. O Cloudflare é também a defesa mais eficaz contra ataques DDoS ao WordPress, absorvendo o tráfego malicioso antes de chegar ao servidor; o Cloudflare APO para WordPress vai mais longe e serve páginas completas em cache a partir do edge, reduzindo o TTFB a nível global.
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, desactivação do editor de ficheiros no painel de administração, HTTP Security Headers (CSP, HSTS, X-Frame-Options), e uma gestão rigorosa de utilizadores e permissões para limitar o acesso ao mínimo necessário.
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. Se o vosso site foi um deles, o guia de recuperação de sites WordPress hackeados detalha os passos imediatos a tomar nas primeiras horas após o incidente.
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. O guia de hardening WordPress e permissões de ficheiros cobre as configurações concretas que mais reduzem esta superfície de ataque.
Uma vez identificados como alvo, os ataques mais devastadores são os ataques supply chain — onde um plugin legítimo é comprometido e afeta centenas de milhares de sites de uma só vez. 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. Se o site já foi comprometido, o guia de WordPress hackeado — primeiras 24 horas cobre a resposta de emergência imediata; para casos mais graves, o serviço de recuperação de sites WordPress inclui limpeza completa e remoção de backdoors. Fale connosco para uma análise sem compromisso.
Deixe um comentário