In this section
TR0.10 Your First Triage
Sections 0.1–0.9 built the complete triage methodology: the 60-minute window, the four-outcome classification, the Triage Trinity, the scorecard, and the report template. This section puts all of it together. Six alerts from the NE environment, each with the context a triage analyst would have available. You classify each alert, document your reasoning, and compare against the reference answer.
Scenario
It's 09:00 on a Monday at Northgate Engineering. Six alerts are in the SOC queue, ranging from HIGH to LOW severity. Rachel assigned you the queue. You have the scorecard from Section 0.8 and the report template from Section 0.9. For each alert, you'll receive the alert details and the result of the first triage query — the same information an L1 analyst sees when they open the alert. Classify each alert, document your scorecard reasoning, then check the reference answer.
Figure TR0.10 — Six NE alerts spanning cloud identity, endpoint, email, Linux, and cross-environment scenarios. Apply the scorecard, classify each, and compare against the reference answers.
How to work this lab
For each alert, apply the 8-question scorecard. Score each question, calculate the total, determine the classification (FP, probable TP, confirmed TP, or BTP), and decide the immediate action. Write your reasoning before expanding the reference answer. The reasoning matters more than the classification — two analysts can reach the same classification through different reasoning, and the reasoning reveals gaps in the triage process.
Time yourself. FP alerts should take 3–5 minutes each. Probable and confirmed TP alerts should take 8–10 minutes. Target: all 6 alerts in 30–45 minutes.
Alert 1: Impossible travel — s.patel
Alert: Entra ID Protection — Impossible travel. s.patel@northgateeng.com authenticated from London (09:02) and from Singapore (09:08). s.patel is a software developer based in Edinburgh. No VPN documented. No travel request. The Singapore sign-in used a different device fingerprint than s.patel's known laptop.
Triage query result: SigninLogs shows 0 previous sign-ins from this Singapore IP for any NE user. The IP resolves to a residential ISP in Singapore.
Alert 2: Inbox rule creation — d.wright
Alert: Custom Sentinel rule — Suspicious inbox rule. d.wright@northgateeng.com created an inbox rule redirecting emails containing "bank details" and "payment confirmation" to Deleted Items. Rule created at 11:45 from 198.51.100.10 (Bristol office egress IP).
Triage query result: SigninLogs shows d.wright authenticated from Bristol office IP at 08:30. Normal browser user-agent. MFA completed via Authenticator push. No anomalous sign-ins in last 30 days. d.wright works in accounts payable.
Alert 3: Credential access — SRV-NGE-BRS005
Alert: Defender for Endpoint — Suspicious credential access. Process rundll32.exe loaded comsvcs.dll on SRV-NGE-BRS005 (Bristol file server) at 02:22. Command line includes MiniDump. Running as SYSTEM.
Triage query result: DeviceProcessEvents shows parent process is cmd.exe, parent of cmd.exe is svchost.exe (PID 876, service: Schedule). No remote logon events in last 60 minutes. Scheduled task "SystemHealthCheck" was created 3 days ago.
Alert 4: Failed sign-ins — t.chen
Alert: Custom Sentinel rule — Brute force detected. 12 failed sign-in attempts for t.chen@northgateeng.com from IP 203.0.113.99 between 14:00 and 14:05. All failures: incorrect password.
Triage query result: SigninLogs shows 0 successful authentications from 203.0.113.99. The IP resolves to a hosting provider (OVH). t.chen has not authenticated since 13:30 (legitimate session from Manchester office). No MFA registration changes.
Alert 5: Kerberoasting — a.patel
Alert: Defender for Identity — Suspected Kerberoasting. a.patel@northgateeng.com requested Kerberos TGS tickets for 15 service accounts in 2 minutes at 10:30 from DESKTOP-NGE-IT03.
Triage query result: IdentityLogonEvents confirms the Kerberoasting pattern. a.patel is a senior IT administrator. Change ticket CHG-2026-0415 authorizes penetration testing by a.patel from 10:00–12:00 today on DESKTOP-NGE-IT03.
Alert 6: C2 beaconing — DESKTOP-NGE042
Alert: Custom Sentinel rule — Beaconing pattern detected. DESKTOP-NGE042 (j.morrison's workstation) makes HTTP connections to 45.155.205.99 every 60 seconds (±3 seconds). Started at 14:30. Consistent packet size (312 bytes).
Triage query result: DeviceNetworkEvents confirms 45 connections in 45 minutes. The destination IP has no DNS record. The process is rundll32.exe loading msedge_update.dll from C:\Users\j.morrison\AppData\Local\Temp\.
Scoring your performance
After completing all 6 alerts, assess across four dimensions.
Classification accuracy. How many matched the reference? Target: 5/6 correct. If you scored 4/6 or below, identify which alert type you misclassified — review Section 0.2 for classification definitions or Section 0.8 for scorecard application.
Scorecard consistency. Compare your scores against the reference. Discrepancies of 1–2 points per question are normal. Discrepancies of 3+ on any question indicate a gap in how that evidence category is interpreted. Focus on Q1 (evidence of compromise) and Q3 (active vs historical) — these two questions have the highest impact on the final classification.
Speed. Target: 30–45 minutes total. If any individual alert took longer than 12 minutes, identify the bottleneck. Was it reading the alert context, running the scorecard, or deciding on containment? Each bottleneck maps to a specific section in the course for further practice.
Documentation quality. Review your triage notes. Could another analyst read them and understand what you checked, what you found, why you classified the way you did, and what actions you took? If your notes are sparse — "Checked, looks fine, closed" — they fail the documentation standard from Section 0.9.
The self-assessment isn't a pass/fail exercise. It's a diagnostic. If you consistently over-classify (calling FPs probable TPs), you'll generate unnecessary escalations that exhaust the investigation team. If you consistently under-classify (calling probable TPs as FPs), you'll miss real incidents. Neither pattern is visible from a single alert — it emerges across the queue. After this lab, you should know which direction your triage instinct leans and how the scorecard corrects for it.
Run this lab again in a week without looking at the reference answers beforehand. Your second run will be faster and your classifications will be more consistent. The improvement between run one and run two is where the scorecard methodology transitions from something you follow consciously to something that shapes how you read alerts automatically.
Common mistakes on this lab
Alert 4 — classifying a failed attack as a TP. The brute force was real but it failed. No compromise occurred. The correct response is documentation, threat intelligence (watchlist the IP), and monitoring. Full IR mobilization for a failed attack wastes resources and trains the team to over-escalate. The distinction between "the attacker tried and failed" versus "the attacker tried and succeeded" is one of the most important triage skills.
Alert 5 — dismissing a service account alert without verifying the schedule. Service accounts operating on schedule are BTPs — but only if you verify the schedule. An unverified dismissal risks closing a genuine compromise of a service account, which is among the most dangerous compromise types because service accounts have broad access and lower monitoring visibility than interactive users.
Alert 6 — not recognizing the C2 indicators. The combination of regular interval (60 seconds), consistent jitter (±3 seconds), consistent packet size (312 bytes), and a DLL loaded from Temp by rundll32.exe is a classic C2 pattern. Analysts who focus on the process name (rundll32 is legitimate) without examining the loaded DLL name and network behavior will miss the beacon.
Getting the right answer by gut feeling works in a lab where you have time, no distractions, and no consequences. In production at 3 AM with three alerts firing simultaneously and the CISO asking for an update, gut feeling produces inconsistent results. The scorecard takes 2–3 minutes extra per alert. That investment produces documented reasoning that survives audit, enables team calibration, and catches the one alert where your gut feeling is wrong because the attacker deliberately mimicked a pattern you've seen a hundred times before. The 5/6 accuracy from gut feeling drops to 3/6 under production pressure. The scorecard maintains 5/6 regardless of conditions because the questions force you to check specific evidence instead of relying on recognition.
Investigation Principle
The goal of this lab is not 6/6 correct on the first attempt. The goal is a consistent triage methodology that produces defensible classifications — even when you are unsure, the scorecard ensures you check the right data before deciding. Consistency under uncertainty is the professional standard.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.