Learn · Triage
Triaging an Alert
Decide what an alert is worth before anyone spends an afternoon on it: did the rule fire correctly, did the activity succeed, and does it matter here?
About 10 min
- In this unit
- How to decide what an alert is worth: did the rule fire correctly, did the activity succeed, and does it matter.
- Before you start
- Searching with KQL
Why it matters
Triage decides what gets investigated at all. Every alert either earns an analyst's time or is closed, and a wrong call costs in both directions: an intrusion closed as noise, or a day spent chasing a scheduled job.
The alert is where the work starts, not where it ends. The rule tells you what it saw; it cannot tell you what happened next, or whether that is normal on this host.
What analysts see
In Elastic Security, an alert arrives with a few fields that frame the decision:
- The rule that fired, and what it is written to catch.
- A severity the rule's author chose before ever seeing your environment.
- The event or events that triggered it: a process, a sign-in, a web request.
- The host, account and addresses involved, each of which you can search for.
None of those fields is the verdict. The verdict comes from what you check next.
Core concept
Ask three separate questions, in order. Did the rule fire on what it is meant to catch? That makes the alert a true positive or a false positive. Did the activity succeed? And does it matter here, or is it expected on this host?
Keep the answers apart. A failed attempt is still a true positive: the rule caught exactly what it was built for, and the attempt is worth recording. An expected admin task that matches a rule is a benign true positive: real activity, harmless in context.
Severity is not a verdict. A high-severity alert can be benign, and a medium one can be the start of an intrusion.
Annotated examples
An attack that succeeded
A rule flags repeated failed sign-ins from one outside address:
- kibana.alert.rule.name:
- "Many failed sign-ins from one source" (note 1)
- kibana.alert.severity:
- "medium"
- source.ip:
- "203.0.113.61"
- KQL:
- source.ip: "203.0.113.61" and event.code: "4624" (note 2)
- results:
- 1 event
- user.name:
- "m.haddad" (note 3)
- winlog.event_data.LogonType:
- "3"
- Note 1: The rule saw 38 failed sign-ins (event 4625) from one address. That is what it is built to catch: a true positive.
- Note 2: The question the alert cannot answer: did any attempt succeed? Event 4624 is a successful sign-in.
- Note 3: One did, as a network sign-in (logon type 3). The activity succeeded, and this account is now part of an incident.
True positive, succeeded. Escalate: the account needs containing, and everything it did after that sign-in needs reading.
The same alert, a failed attempt
The same rule on a later day, for that outside source again:
- kibana.alert.rule.name:
- "Many failed sign-ins from one source"
- KQL:
- source.ip: "203.0.113.61" and event.code: "4624" (note 1)
- results:
- 0 events (note 2)
- Note 1: The same follow-up query as before.
- Note 2: No sign-in succeeded. The rule still fired correctly, so this is a true positive whose activity failed, not a false positive.
True positive, failed. Record it with the reason, and check whether any account locked out along the way.
Real, but benign
A rule flags an encoded PowerShell command on an admin workstation:
- kibana.alert.rule.name:
- "Script launched with an obfuscated argument" (note 1)
- kibana.alert.severity:
- "high"
- host.name:
- "it-admin-03.corp.example"
- process.command_line:
- "powershell.exe -enc <base64>"
- process.parent.name:
- "CcmExec.exe" (note 2)
- process.parent.code_signature.subject_name:
- "Microsoft Corporation" (note 3)
- Note 1: The command really is encoded, so the rule fired on what it is meant to catch.
- Note 2: The parent is the Configuration Manager client, which runs deployment scripts this way by design.
- Note 3: Signed by the vendor. Confirm it against the deployment schedule or the admin team before you close it.
Benign true positive. Close it with the reason, and tune the rule for this parent and signer rather than switching it off.
A false positive
A watchlist rule flags a web request:
- kibana.alert.rule.name:
- "Web request matched a watchlist entry" (note 1)
- kibana.alert.severity:
- "medium"
- url.full:
- "https://updates.vendor.example/client/check" (note 2)
- url.domain:
- "updates.vendor.example"
- Note 1: Start with what the rule looks for. Here, a watchlist entry matched as a substring anywhere in the URL.
- Note 2: A software vendor's update check. The rule matched something it was never meant to: a false positive.
False positive. Close it, and fix the rule so the entry has to match the domain, not any part of the URL.
How to investigate
- 1.
Read the rule before the event.
Know what it is written to catch, so you can tell whether this event is that.
- 2.
Decide whether it fired correctly.
Does the triggering event match what the rule is meant to catch? That is the true or false positive question.
- 3.
Check whether the activity succeeded.
Search for what would follow if it had: a successful sign-in, a process that ran, a connection that completed.
source.ip: "203.0.113.61" and event.code: "4624" - 4.
Check the context.
What the host does, what started the process and who signed it, whether it matches a schedule or a known admin task.
- 5.
Record the verdict and the reason.
True or false positive, succeeded or failed, benign or harmful, and what you checked to decide. The next analyst needs the reason, not just the label.
- 6.
Write it up for the next analyst.
Use the same headings as your notebook's Conclusion: what happened, the supporting evidence and a note on it, the affected users, hosts and systems, your confidence, and an initial containment recommendation. Keep what you confirmed apart from what you suspect, and name the evidence behind each confirmed line. A write-up someone else can check is worth more than a longer one.
Common mistakes
Mistake: Treating severity as the verdict.
InsteadSeverity is the rule author's estimate before seeing your environment. Decide from what you check.
Mistake: Closing a failed attempt as a false positive.
InsteadIf the rule caught what it is built for, it is a true positive, even when the attempt failed.
Mistake: Stopping at the alert text.
InsteadThe alert says what the rule saw. Search for whether the activity succeeded and what happened next.
Mistake: Switching off a noisy rule.
InsteadTune it for the specific benign case (a parent, a signer, a domain), so it still catches everything else.
Mistake: Recording a verdict without a reason.
InsteadWrite down what you checked. A label alone cannot be reviewed or reused.
Mistake: Writing a suspicion as a fact.
InsteadMark it as suspected, and say what evidence would confirm it.
Field references
| Field | What it tells you | Seen in |
|---|---|---|
| kibana.alert.rule.name | The rule that fired. | Elastic Security alerts |
| kibana.alert.severity | The severity set by the rule's author. | Elastic Security alerts |
| event.code | 4625 is a failed sign-in, 4624 a successful one. | Windows Security |
| winlog.event_data.LogonType | How a sign-in happened; 3 is over the network. | Windows Security (4624, 4625) |
| process.parent.name | What started the process. | Sysmon |
| process.parent.code_signature.subject_name | Who signed the parent program. | Endpoint and Sysmon data, where collected |
| url.full, url.domain | The whole requested URL, and its domain. | Proxy, Web logs |
Apply it in a Case
Pick a case that opens with an alert. Before you investigate anything else, answer the three questions for it, and write down what you checked for each.
- CuckooSkills: Log analysisTelemetry: Windows · Sysmon
- GhostwriterSkills: Log analysisTelemetry: Windows · Sysmon
- TrailheadSkills: Log analysisTelemetry: Suricata
References
- Manage detection alerts · Elastic Security
- Event 4625 · Microsoft
- Event 4624 · Microsoft
- Incident Response Recommendations and Considerations for Cybersecurity Risk Management (SP 800-61 Rev. 3) · NIST
Related in Learn
- Searching with KQLSearch the SIEM every range runs on the way an investigation does: set the time range, ask one precise question in KQL, pin what matters and pivot on what you find.
- Thinking in MITRE ATT&CKThe shared language of detection work: what an attacker was trying to achieve and how. How to read ATT&CK, map evidence to it, and avoid the common mapping mistakes.