Todo site WordPress público recebe tentativas automatizadas de login, muitas vezes desde o primeiro dia no ar. A maioria fracassa, mas elas consomem recursos, e basta uma senha fraca ou reutilizada para que uma única dê certo. Este artigo explica as três grandes variantes do ataque, como reconhecê-las nos seus logs e quais proteções realmente mudam o resultado.
Definição rápida: Ataque de força bruta. Solução pronta para usar: Proteção contra força bruta no WordPress com o WP Masquerade.
Do que estamos falando exatamente
A documentação oficial do WordPress define o ataque de força bruta como a tentativa automatizada e repetida de pares usuário/senha até que um deles funcione. Ela destaca dois pontos que costumam ser esquecidos: esses ataques geralmente partem de redes de máquinas invadidas (botnets), ou seja, de um número enorme de endereços, e, mesmo quando fracassam, podem sobrecarregar o servidor.
A escala está documentada. Em seu relatório anual de 2024, a Wordfence afirma ter bloqueado mais de 55 bilhões de tentativas de ataque a senhas (força bruta, credential stuffing e variantes), vindas de quase 136 milhões de endereços IP distintos. O mesmo relatório aponta uma queda constante desses ataques ao longo do ano, que atribui em parte às proteções das empresas de hospedagem e a melhores práticas de senha. Menos frequentes não quer dizer inofensivos: eles continuam sendo o ruído de fundo de qualquer site WordPress.
As três variantes que você precisa conhecer
O ataque de dicionário
O robô testa listas de senhas comuns em um nome de usuário que ele acredita ser válido: admin, o nome do site ou o nome de um autor encontrado no próprio site. É a forma mais antiga e a menos eficaz contra uma senha longa e aleatória. Ela ainda funciona contra senhas curtas, variações do nome do site ou palavras do dicionário seguidas de um ano.
O credential stuffing
Aqui, nenhuma senha é adivinhada. A OWASP descreve o credential stuffing como a injeção automatizada de pares usuário/senha roubados em vazamentos de outros serviços. Se um administrador usa a mesma senha na conta do WordPress e em um serviço que vazou, o atacante entra na primeira tentativa. Nenhuma regra de complexidade protege contra esse caso: só uma senha nunca reutilizada e a autenticação de dois fatores o neutralizam.
A força bruta distribuída
As botnets dividem a lista entre milhares de endereços. Cada endereço faz apenas algumas tentativas, às vezes com vários minutos de intervalo. Um bloqueio simples do tipo “5 falhas e o endereço é bloqueado” detém uma parte, mas não tudo. Por isso, as proteções eficazes combinam várias camadas, do servidor até a conta.
| Variante | O que o atacante tem | Sinal nos logs | O que a detém |
|---|---|---|---|
| Dicionário | Um nome de usuário provável, uma lista de senhas | Muitas falhas a partir de poucos endereços | Senha longa e única, limitação de tentativas |
| Credential stuffing | Pares roubados em outros lugares | Poucas tentativas por conta, muitas vezes endereços de e-mail | Senha não reutilizada, autenticação de dois fatores |
| Distribuída | Uma botnet | Falhas espalhadas por milhares de endereços | Filtragem na borda (firewall, CDN), autenticação de dois fatores |
Por que wp-login.php e xmlrpc.php
Dois arquivos aceitam um nome de usuário e uma senha sem passar por uma página HTML intermediária.
/wp-login.php: a página de login padrão. O endereço é o mesmo em todos os sites WordPress, então o robô não precisa procurar nada./xmlrpc.php: a interface XML-RPC, usada historicamente por aplicativos de publicação remota. A documentação do WordPress a descreve como alvo frequente de força bruta e recomenda desativá-la se você não a usa. Detalhamos esse assunto em um artigo dedicado ao XML-RPC.
Um terceiro fator ajuda o atacante: conhecer o nome de usuário. Por padrão, a mensagem de erro do WordPress distingue um nome de usuário desconhecido (“não está registrado neste site”) de uma senha incorreta para um usuário existente. Esse comportamento aparece no código de wp-includes/user.php. Somado aos outros meios de enumeração de contas, ele permite que o robô concentre as tentativas em nomes de usuário reais.
O que você vê nos seus logs
O log de acesso do servidor (Apache, Nginx ou LiteSpeed, muitas vezes disponível no painel da hospedagem) é a melhor testemunha. Um ataque se parece com isto (endereços de documentação, reservados para exemplos):
203.0.113.24 - - [12/Oct/2026:03:14:07 +0200] "POST /wp-login.php HTTP/1.1" 200 4512 "-" "Mozilla/5.0 ..."
198.51.100.9 - - [12/Oct/2026:03:14:09 +0200] "POST /xmlrpc.php HTTP/1.1" 200 412 "-" "Mozilla/5.0 ..."
203.0.113.77 - - [12/Oct/2026:03:14:12 +0200] "POST /wp-login.php HTTP/1.1" 200 4512 "-" "Mozilla/5.0 ..."O ponto-chave é o código de resposta. Uma falha em wp-login.php retorna status 200: a página exibe de novo o formulário com a mensagem de erro. Um login bem-sucedido retorna um redirecionamento 302 para a administração (função wp_safe_redirect(), cujo status padrão é 302). Em xmlrpc.php, a falha também é um status 200: o erro fica no corpo da resposta XML.
Para ler um log rapidamente, procure:
- um grande número de
POSTpara/wp-login.phpou/xmlrpc.phpem pouco tempo; - user agents idênticos em endereços muito diferentes;
- um
302depois de uma série de200, sobretudo se vier de um endereço que você não conhece; - picos de uso de processador ou de memória do PHP sempre nos mesmos horários.
Um 302 suspeito justifica verificar imediatamente a lista de usuários administradores, os últimos logins e os plugins instalados recentemente.
As defesas, por ordem de eficácia
Nenhuma medida isolada basta, mas nem todas têm o mesmo peso.
- Senhas longas, únicas e guardadas em um gerenciador de senhas. As recomendações do NIST (SP 800-63B-4, agosto de 2025) exigem pelo menos 15 caracteres para uma senha usada sozinha, a comparação com uma lista de senhas comprometidas e o fim das trocas periódicas obrigatórias.
- A autenticação de dois fatores, no mínimo para os administradores. A documentação do WordPress lembra que o núcleo não a oferece: é preciso um plugin ou um provedor de identidade. Com ela, uma senha descoberta ou roubada já não basta.
- A limitação de tentativas por endereço IP, para frear os ataques de dicionário. Ela tem limites diante de botnets e proxies, que detalhamos no nosso artigo sobre a limitação de tentativas de login.
- A filtragem na borda: firewall da hospedagem, CDN ou regras de servidor que limitam a taxa de requisições em
wp-login.phpexmlrpc.php. A documentação do WordPress explica que o bloqueio no nível da aplicação ainda consome PHP a cada requisição, enquanto uma filtragem na borda também protege a carga do servidor. - Fechar o que não é usado: o XML-RPC, se nenhum aplicativo depende dele, e nada de conta chamada
admin. - Mudar o endereço de login: isso não protege uma senha fraca, mas elimina muito ruído dos logs e reduz a carga.
Um ponto tranquilizador: desde o WordPress 6.8, as senhas dos usuários são armazenadas com hash bcrypt em vez de phpass. Isso não muda nada nas tentativas on-line pelo formulário, mas torna muito mais cara a quebra dos hashes caso o banco de dados seja roubado.
| Medida | Contra o dicionário | Contra o credential stuffing | Contra a carga do servidor |
|---|---|---|---|
| Senha longa e única | Sim | Sim (se nunca for reutilizada) | Não |
| Autenticação de dois fatores | Sim | Sim | Não |
| Limitação de tentativas por IP | Em grande parte | Parcialmente | Pouco |
| Filtragem na borda (firewall, CDN) | Parcialmente | Parcialmente | Sim |
| Endereço de login personalizado | Reduz o ruído | Reduz o ruído | Sim, para wp-login.php |
Com o WP Masquerade
A versão gratuita do WP Masquerade permite definir um endereço de login personalizado e fechar o wp-login.php para visitantes anônimos depois de testar o novo endereço, além de bloquear o XML-RPC e os pingbacks. As armadilhas para robôs contam as requisições a esses endereços fechados, o que dá uma medida concreta do ruído evitado. O WP Masquerade Pro acrescenta a limitação de tentativas de login por endereço IP e a autenticação de dois fatores obrigatória por função. Nenhuma dessas funções substitui uma senha única: elas reduzem a exposição e o custo de um ataque.
Para lembrar
- Os ataques de força bruta miram sobretudo
wp-login.phpexmlrpc.php, a partir de milhares de endereços. - O credential stuffing dá certo na primeira tentativa se uma senha for reutilizada: a complexidade não basta.
- Nos logs, uma falha retorna 200 e um login bem-sucedido retorna 302.
- Prioridades: senha única e longa, autenticação de dois fatores para os administradores e, depois, limitação e filtragem na borda.
Fontes
- WordPress Developer Resources: Brute Force Attacks (abre em uma nova aba)
- OWASP: Credential stuffing (abre em uma nova aba)
- NIST SP 800-63B-4: Authentication and Authenticator Management (agosto de 2025) (abre em uma nova aba)
- Make WordPress Core: WordPress 6.8 will use bcrypt for password hashing (abre em uma nova aba)
Outras fontes consultadas: páginas oficiais dos fornecedores e banco de dados Wordfence.
