Home / Blog / Alert Triage
Triage a Brute Force Alert in 5 Steps (Event ID 4625)
A repeatable beginner workflow for the most common SOC alert: lots of failed Windows logons. Read the alert, enrich, scope, decide and document.
Failed logon alerts are one of the first things a new analyst sees on shift. Most are noise, a few are the start of something serious. This walkthrough gives you a simple five step routine so every 4625 alert gets the same careful treatment.
Scenario: your SIEM fires "Multiple failed logons from a single source". 37 events for event ID 4625 from
10.0.4.22in 10 minutes.
Read the alert properly
Before you open any tool, pull the key facts out of the alert itself:
- Source: which IP or host generated the failures?
- Target: one account (guessing) or many accounts (spraying)?
- Logon type: 3 is network, 10 is RDP, 2 is interactive.
- Status code: the reason each attempt failed.
| Sub status | Meaning | Why it matters |
|---|---|---|
0xC000006A | Wrong password | The account exists |
0xC0000064 | Unknown username | Likely enumeration |
0xC0000234 | Account locked out | Possible user impact |
Enrich the source
Work out what 10.0.4.22 actually is. Check your CMDB or DHCP logs, then look at its recent activity in the SIEM.
Splunk (SPL)
index=wineventlog EventCode=4625 src_ip="10.0.4.22"
| stats count values(TargetUserName) as users values(Sub_Status) as status by src_ip, LogonType
| sort - count
Microsoft Sentinel (KQL)
SecurityEvent
| where EventID == 4625 and IpAddress == "10.0.4.22"
| summarize attempts = count(), users = make_set(TargetUserName) by IpAddress, LogonType
| order by attempts desc
Check for a success
This is the step that matters most. A pile of failures followed by a 4624 success from the same source is a very different alert.
SecurityEvent
| where EventID in (4624, 4625) and IpAddress == "10.0.4.22"
| project TimeGenerated, EventID, TargetUserName, LogonType
| order by TimeGenerated asc
Rule of thumb: failures then success from an unknown source means escalate now, do not wait to finish the write up.
Decide on a verdict
- Benign: a known scanner, a service account with an expired password, or a user who mistyped. Close with the evidence.
- Suspicious: unknown source, many accounts, no success yet. Block or isolate, then keep watching.
- Malicious: a success after failures, or a source with known bad reputation. Escalate to incident response.
Document it
Write the ticket so the next analyst can follow your reasoning without asking you:
Alert: Multiple failed logons (4625) x37 from 10.0.4.22
Source: WS-114, finance VLAN, owner J. Doe
Targets: 12 accounts, sub status 0xC0000064 (unknown user)
Success after failures: none
Verdict: Suspicious, password spraying from internal host
Action: Host isolated via EDR, escalated to IR, ticket INC-0000
That is the whole loop. Run it the same way every time and triage gets faster and more consistent. Follow along for the next post in this track.