wp_brute_force_login
Severity: Critical
Signal: auth.attempt — repeated failed logins in a short window
What this signal means
Logystera detected a sustained burst of failed login attempts. This is consistent with a brute-force or credential stuffing attack against your WordPress login page.
What surprise this prevents
An attacker gaining admin access silently — installing a backdoor, injecting malware, or taking over the site — before you notice anything is wrong.
Why it matters
An attacker is actively trying to gain admin access. If they succeed, they can install backdoors, inject malware, exfiltrate data, or use the site for spam and phishing. Even failed attempts can cause resource exhaustion on shared hosting.
Investigate
View entity alerts in Logystera →
Check:
- How many attempts, from how many IPs?
- Are attempts targeting specific usernames (common ones:
admin,administrator, site domain)? - Is the traffic from a single IP or distributed (botnet)?
In Logystera, filter auth.attempt signals for this entity. Look at labels.actor.ip and payload.username_hash patterns.
Recommended actions
Immediate:
- Block the attacking IP(s) at your firewall, Cloudflare, or
.htaccess:apache Deny from 203.0.113.42 - Verify no admin accounts were created — go to Users → All Users and sort by date registered.
- Check for active sessions from unknown IPs — go to your security plugin or run:
sql SELECT * FROM wp_usermeta WHERE meta_key = 'session_tokens';
Harden:
- Limit login attempts using a plugin like Limit Login Attempts Reloaded if not already active.
- Enable two-factor authentication for all admin accounts.
- Rename or protect the login URL — move from
/wp-login.phpto a custom path using a security plugin. - Disable XML-RPC if not needed — it is a common brute-force vector:
php add_filter( 'xmlrpc_enabled', '__return_false' );
When to safely ignore
This signal may be safely ignored if you are running a deliberate penetration test against your own site and have configured your test tool to generate login attempts.
A small number of isolated failed logins (1–2 attempts from a single IP) is normal background noise and does not trigger this alert — the rule requires a sustained burst over a short window.
Signal reference
{
"event_type": "auth.attempt",
"payload": {
"success": false,
"username_hash": "a1b2c3...",
"username_len": 5
},
"labels": {
"actor": { "user_id": 0, "ip": "203.0.113.42" }
}
}