| Field | Detail |
|---|---|
| Platform | TryHackMe |
| Room URL | tryhackme.com/room/socl1alerttriage |
| Category | SOC / Blue Team |
| Status | ✅ Completed |
| Points Earned | 80 |
| Tasks Completed | 6 |
| Streak | 🔥 5 |
| GitHub File | labs/tryhackme/rooms/soc-l1-alert-triage.md |
| Live Website | tryhackme.html |
Learn more about SOC alerts and build a systematic approach to efficiently triaging them. The room covers the full alert lifecycle from event generation to resolution, alert properties and fields, prioritisation logic, and the step-by-step triage workflow used by L1 analysts in real-world SOC environments.
Worked through each task sequentially using the live SOC dashboard provided by TryHackMe. Applied the alert prioritisation framework (filter → sort by severity → sort by time) to select the correct alert first, then followed the triage workflow (assign → in progress → investigate in SIEM → verdict → comment → close) for each of the three practical alerts.
From Events to Alerts:
An event occurs (login, file download, process launch) → the system logs it → logs are shipped to SIEM or EDR → a detection rule matches a pattern → an alert is generated. Alerts save analysts from reviewing millions of raw logs daily by surfacing only suspicious, anomalous events.
Alert Management Platforms:
| Solution | Examples | Description |
|---|---|---|
| SIEM | Splunk ES, Elastic | Solid alert management, preferred choice for most SOC teams |
| EDR / NDR | MS Defender, CrowdStrike | Provide own dashboards but SIEM/SOAR is preferred |
| SOAR | Splunk SOAR, Cortex SOAR | Aggregates alerts from multiple solutions for larger SOC teams |
| ITSM | Jira, TheHive | Custom ticket management for teams with dedicated tooling |
Alert Properties — all 8 fields:
| # | Property | Description | Examples |
|---|---|---|---|
| 1 | Alert Time | Creation time — usually a few minutes after the actual event | Alert: 15:35 / Event: 15:32 |
| 2 | Alert Name | Summary of what happened, based on the detection rule name | Unusual Login Location, Mimikatz Usage |
| 3 | Alert Severity | Urgency level set by detection engineers, adjustable by analysts | 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Critical |
| 4 | Alert Status | Whether someone is working on it or triage is done | 🆕 New / 🔄 In Progress / ✅ Closed |
| 5 | Alert Verdict | Classification of the alert — real threat or noise | 🔴 True Positive / 🟢 False Positive |
| 6 | Alert Assignee | The analyst who owns the alert and is responsible for it | Also called alert owner |
| 7 | Alert Description | Three sections: rule logic, why it matters, how to triage | Varies by alert type |
| 8 | Alert Fields | Key values that triggered the alert | Hostname, commandline, IP, username |
Alert Prioritisation — 3-step framework:
| Step | Action | Reasoning |
|---|---|---|
| 1 | Filter | Only take New / Unassigned alerts — never take one already being worked |
| 2 | Sort by severity | Critical first, then High, Medium, Low — higher severity = more likely real, higher impact |
| 3 | Sort by time | Oldest first within same severity — older breaches have had longer to do damage |
Alert Triage Workflow — step by step: