Correlating Brute-Force Authentication Failures with Successful Lateral Pivot Events

Why This Matters

The brute-force-then-pivot attack pattern is one of the most common sequences seen in SMB exposure incidents and RDP honeypot data. An attacker automates password guessing against an exposed service, achieves one successful authentication among hundreds of failures, then immediately uses that credential to move laterally to internal hosts. The forensic signature spans two phases — a noisy failure burst followed by quiet but dangerous success — and correlation across both is required to reconstruct the full attack timeline and identify the compromised account.

Core Concept

Brute-force in Windows event logs manifests as a high volume of Event 4625 (Logon Failure) records from a single source IP against one or more target accounts, in rapid succession. The attack typically stops abruptly once a success occurs.

Event 4624 (Logon Success) immediately following a 4625 cluster from the same source IP is the pivot trigger. The successful logon provides the attacker with a valid session from which to issue further authentication attempts to internal hosts.

Pivot is the subsequent lateral movement: the attacker uses the newly compromised account to authenticate to additional internal hosts (further 4624 events from an internal source IP, now using the breached account). The source IP changes from external to internal at this point — a key differentiator between initial compromise and lateral movement phases.

Key fields to correlate: IpAddress (source of authentication), TargetUserName (account targeted), LogonType, and TimeCreated. The attack chain: external_ip → 4625 cluster → 4624 success → internal_ip → 4624 multi-host.

Technical Deep-Dive

-- Splunk: find IPs with brute-force failures followed by success
index=wineventlog EventCode IN (4624, 4625)
| eval outcome = if(EventCode=4624, "success", "failure")
| stats count(eval(outcome="failure")) AS failures
        count(eval(outcome="success")) AS successes
        values(Account_Name) AS accounts
        earliest(_time) AS first_attempt
        latest(_time) AS last_seen
  BY Source_Network_Address
| where failures > 20 AND successes > 0
| eval success_ratio = round(successes / (failures + successes) * 100, 1)
| sort -failures

-- Splunk: identify compromised account and subsequent pivot hosts
| inputlookup brute_success_accounts.csv
| map search="search index=wineventlog EventCode=4624
    Account_Name=$account$ earliest=$first_success$ latest=$window_end$
    | stats dc(ComputerName) AS host_count values(ComputerName) AS hosts BY Account_Name"

# Linux: grep auth.log for SSH brute force then success
grep "Failed password" /var/log/auth.log 
  | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Find the successful login from the top brute-force source
ATTACKER_IP="192.168.1.200"
grep "Accepted" /var/log/auth.log | grep "$ATTACKER_IP"

# Then look for subsequent pivots FROM that compromised host
PIVOT_HOST="victim01"
grep "Accepted" /var/log/auth.log | grep "from $PIVOT_HOST"

# Python: parse Windows evtx JSON export, correlate brute then pivot
import json
from collections import defaultdict

events = json.load(open("security_events.json"))
failures = defaultdict(list)
successes = defaultdict(list)

for e in events:
    src = e.get("IpAddress", "")
    user = e.get("TargetUserName", "")
    ts = e.get("TimeCreated", "")
    if e["EventID"] == 4625:
        failures[src].append((ts, user))
    elif e["EventID"] == 4624 and e.get("LogonType") in ("3","10"):
        successes[src].append((ts, user))

for src, fails in failures.items():
    if len(fails) > 20 and src in successes:
        print(f"BRUTE+PIVOT: {src}")
        print(f"  Failures : {len(fails)}")
        print(f"  Successes: {successes[src]}")

Analytical Methodology

1. In your SIEM, aggregate Event 4625 by source IP and target account over the investigation window. Any source generating more than 20 failures in under 5 minutes against the same host is a brute-force candidate.
2. For each flagged source IP, check whether any Event 4624 (success) occurred from that same IP, targeting any account, within 60 minutes of the failure cluster. This is your confirmed credential compromise event.
3. Record the TargetUserName from the 4624 success event — this is the compromised account.
4. Pivot: search all Event 4624 records for the compromised account name across all hosts in the time window following the initial compromise (use a 72-hour window to be conservative). Map each destination host and the source IP of that subsequent logon.
5. Note the source IP change: the initial brute-force came from an external IP. Subsequent pivot events should originate from an internal IP (the compromised machine). This transition confirms lateral movement has begun.
6. Identify additional accounts used during the pivot phase. Attackers commonly dump credentials from the first compromised host and begin authenticating with harvested accounts — expanding the scope of the incident.
7. Build a timeline table: timestamp, source IP, destination host, account, EventID, logon type. This becomes the backbone of the incident report and containment plan.
8. Identify the last hop: the destination host that the attacker was on at investigation time. This is the host requiring immediate isolation.

Common Analytical Errors

• Treating all 4625 clusters as incidents: Misconfigured applications, expired password prompts, and roaming profile sync all generate 4625 bursts. Confirm that a 4624 success follows from the same source before escalating.
• Missing the internal-source pivot: After initial compromise, subsequent lateral movement events originate from an internal IP, not the external attacker IP. Analysts focused only on external sources miss the pivot phase entirely.
• Not accounting for account lockout: If the organisation has account lockout policies, the brute-force may have triggered a lockout. Search for Event 4740 (account locked out) to confirm and identify the exact moment the attacker succeeded before lockout.
• Assuming a single compromised account: Attackers frequently compromise multiple accounts in a single brute-force session targeting a password-spraying wordlist. Examine all 4624 successes from the attacker IP, not just the first.

NICE Framework Alignment

Further Reading

• CrackMapExec documentation — understand the tool's log footprint from the attacker's perspective
• SANS: "Detecting Brute Force Attacks in Windows Event Logs" (whitepaper)
• Microsoft: Account Lockout and Management Tools — Event 4740 reference
• Elastic SIEM detection rules: "Potential Password Spraying of Microsoft 365 Accounts"
• ATT&CK T1110: Brute Force — sub-technique matrix and detection data sources