Skip to content
All posts
Threat Detection

Brute-Force Followed by Successful Login: The Attack Everyone Misses

8 min read

An attacker sends 100 password guesses to your SSH server. 99 fail. One succeeds. They are now logged in with a valid account. Most security tools will alert you about the 99 failures. Almost none will alert you about the one success that followed them. That success is the most dangerous event on your server.

Inner Warden's suspicious_login detector watches for exactly this pattern: a successful authentication from an IP that previously had multiple failed attempts. This is not just an alert. It is a compromise indicator.

Why this is the most dangerous pattern

Failed login alerts tell you someone is trying. A successful login after failures tells you someone succeeded. The difference is critical:

  • Failed logins - the attacker is outside. They are probing. Your defenses are holding. This is noise.
  • Success after failures - the attacker is inside. They guessed or cracked a password. Your defenses failed. This is a breach.

In the MITRE ATT&CK framework, this maps to T1110 (Brute Force) achieving its objective: T1078 (Valid Accounts). The attacker now has legitimate credentials and can operate as a normal user. Every action they take looks authorized.

Why most tools miss it

Standard security tools handle failures and successes as separate events:

  • fail2ban - blocks an IP after N failures. It does not track what happens after the ban expires or if a success occurs from the same IP before the ban triggers.
  • OSSEC/Wazuh - can alert on successful logins, but treats them the same regardless of whether failures preceded them.
  • auditd - logs everything but does not correlate. You would need to write custom scripts to cross-reference failures and successes per IP.
  • CloudWatch / Datadog - can create rules, but require manual correlation logic that most teams never build.

The gap is correlation. Detecting this pattern requires tracking per-IP failure history and triggering when a success arrives from an IP with recent failures. This is stateful detection, and most tools are stateless per event.

How the suspicious_login detector works

Inner Warden's sensor maintains a per-IP failure counter in a sliding time window. When a successful login event arrives, the detector checks if the source IP has recent failures:

Trigger conditionSuccessful login from IP with 3+ recent failures
Failure window10 minutes (configurable)
Sourcesauth_log + journald
OutputIncident with failure count, username, source IP

The detector does not just fire a binary alert. It includes the full context: how many failures preceded the success, which usernames were tried, and the time gap between the last failure and the success.

Severity scales with failure count

Not all suspicious logins are equal. An IP with 3 failures before success might be a user who mistyped their password. An IP with 50 failures before success is almost certainly a brute-force that found valid credentials. The severity scoring reflects this:

Failures before successSeverityInterpretation
3-4MediumPossible mistyped password, investigate
5-9HighLikely credential guessing, probable compromise
10+CriticalBrute-force succeeded, active compromise

The agent uses this severity to decide the response. A Medium might trigger monitoring. A Critical triggers immediate action: block the IP, alert the operator, and optionally suspend the compromised user's sudo access.

What the alert looks like

When the detector fires, the agent sends a Telegram notification with full context. Here is a real example:

criticalSuspicious login detected
sourceIP 185.220.101.34 | GeoIP: DE | AbuseIPDB: 100%
pattern47 failed attempts for users root, admin, ubuntu, deploy | then successful login as "deploy"
timelineFailures over 8 minutes | Success at 14:23:17 UTC
responseIP blocked (ufw deny) | TTL 24h | User "deploy" sudo suspended | TTL 1h

The operator sees exactly what happened, how severe it is, and what was done about it. No guessing, no log diving.

What to do when this alert fires

A suspicious login is a compromise indicator. Even if Inner Warden blocks the IP and suspends sudo, you should investigate:

  1. Check the compromised account - review recent commands run by the user. Look for downloads, new SSH keys, cron jobs, or new user accounts.
  2. Rotate the password - the credential is compromised. Change it immediately and enable key-based authentication if not already in place.
  3. Check for persistence - attackers often add SSH keys to ~/.ssh/authorized_keys, create cron jobs, or install backdoor services within seconds of gaining access.
  4. Review Inner Warden's audit trail - the decisions JSONL file contains the full chain: detection, enrichment, AI recommendation, and execution details.

Set it up

The suspicious_login detector is enabled by default. Install Inner Warden and it starts watching immediately:

Install
curl -fsSL https://innerwarden.com/install | sudo bash

For the best protection, combine this with IP blocking and Telegram notifications:

Enable full response chain
innerwarden enable block-ip
innerwarden configure telegram

What to do next