Home / Blog / Alert Triage

Beginner 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.22 in 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 statusMeaningWhy it matters
0xC000006AWrong passwordThe account exists
0xC0000064Unknown usernameLikely enumeration
0xC0000234Account locked outPossible 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

  1. Benign: a known scanner, a service account with an expired password, or a user who mistyped. Close with the evidence.
  2. Suspicious: unknown source, many accounts, no success yet. Block or isolate, then keep watching.
  3. 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.