TR0.11 Interactive Lab: Your First Triage

Figure TR0.11 — The first triage lab. Six alerts from the NE environment with mixed classifications.

Lab instructions

For each alert below, apply the 8-question triage scorecard from TR0.6. Score each question, calculate the total, determine the classification (FP, probable TP, or confirmed TP), and decide the immediate action. Write your reasoning before checking the reference answer. The reasoning is more important than the classification — two analysts can reach the same classification through different reasoning, and the reasoning reveals gaps in the triage process.

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 the Edinburgh office. No VPN documented. No travel request in the system. The sign-in from Singapore used a Windows 10 device with 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 the Deleted Items folder. 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 the last 30 days. d.wright works in the accounts payable department.

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 the parent process is cmd.exe, parent of cmd.exe is svchost.exe (PID 876, service: Schedule). No remote logon events to this server in the last 60 minutes. The 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 for t.chen.

Alert 5: Penetration test — 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. A change ticket (CHG-2026-0415) authorises penetration testing by a.patel from 10:00-12:00 today on DESKTOP-NGE-IT03.

Alert 6: Outbound connection — DESKTOP-NGE042

Alert: Custom Sentinel rule — Beaconing pattern detected. DESKTOP-NGE042 (j.morrison’s workstation) is making HTTP connections to 45.155.205.99 every 60 seconds (±3 seconds). Connection 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 making the connections is rundll32.exe loading msedge_update.dll from C:\Users\j.morrison\AppData\Local\Temp.

Why practice speed matters

Attacker dwell times are decreasing. Mandiant’s reporting shows median dwell time at approximately 10 days — but that is a median across all incidents including those discovered months after compromise. For targeted attacks against organisations with detection capability, the window from initial access to objective completion is measured in hours. CrowdStrike’s breakout time metric (initial access to lateral movement) shows the fastest adversaries operating in under 2 minutes. Palo Alto’s Unit 42 reports that median time to exfiltration compressed from 9 days to 2 days between 2023 and 2024. The triage scorecard takes 10-15 minutes. The attacker’s kill chain takes hours. Practising the scorecard until it is reflexive — until you can classify an alert without consulting the reference card — is what makes the 15-minute triage window achievable under production pressure.

Scoring the lab: performance metrics for self-assessment

After completing all 6 alerts, calculate your performance across four dimensions:

Dimension 1: Classification accuracy. How many of your classifications matched the reference answers? Target: 5/6 correct. Score: assign 1 point per correct classification. If you scored 4/6 or below, identify which alert type you misclassified and review the relevant subsection (TR0.2 for classification definitions, TR0.6 for scorecard application).

Dimension 2: Scorecard consistency. For each alert, compare your scorecard score against the reference. A discrepancy of 1-2 points per question is acceptable (different analysts weigh ambiguous evidence differently). A discrepancy of 3+ points on any question indicates you may be over- or under-weighing that evidence category. Focus on Q1 (evidence of compromise) and Q3 (active vs historical) — these two questions have the highest impact on the final classification.

Dimension 3: Speed. Time yourself on the 6 alerts. Target: 30-45 minutes total. FP alerts should take 3-5 minutes each (read context, confirm no indicators, close). Probable TP alerts should take 8-10 minutes (full scorecard, containment planning). If any individual alert took longer than 12 minutes, identify the bottleneck: was it reading the alert context (improve by pre-studying alert types in TR2-TR3), running the scorecard (improve by memorising the 8 questions), or deciding on containment (improve by studying the containment playbooks in TR2.5 and TR3.6)?

Dimension 4: Documentation quality. Review your triage notes for each alert. Could another analyst read your notes and understand: what you checked, what you found, why you classified the alert the way you did, and what actions you took? If your notes are sparse (“Checked — looks fine — closed”), they fail the documentation standard. The triage report format from TR0.5 provides the template: classification summary, findings per query, containment actions, evidence preserved, outstanding questions.

Common lab mistakes to watch for:

Alert 3 (MFA fatigue): classifying a FAILED attack as a TP requiring full IR mobilisation. The attack was real but it FAILED — no compromise occurred. The correct response is password reset (invalidate the stolen credential) and monitoring, not full incident response. The distinction between “the attacker tried and failed” versus “the attacker tried and succeeded” is one of the most important triage skills.

Alert 5 (service account): dismissing a service account alert as noise without verifying the scheduled activity. 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 often have broad access and their activity is not monitored as closely as interactive user accounts.

Alert 6 (atypical travel): classifying atypical travel to a known NE site as a TP. The atypical travel alert fires because the user does not USUALLY sign in from Manchester — but NE has a Manchester office, and the user’s calendar shows a meeting there. Context resolves the alert. The analyst who classifies based solely on the alert title without checking environmental context will over-classify atypical travel alerts.

Self-assessment

Review your 6 classifications against the reference answers. For each alert where your classification matched: what reasoning did you use? Did you follow the scorecard, or did you classify by pattern recognition? For each alert where your classification differed: which scorecard question did you answer differently? Was your answer defensible with the available data, or did you miss a data point?

The goal 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 process ensures you check the right data before deciding.

The queue management discipline

Processing the 6-alert queue correctly requires queue management discipline that many junior analysts lack initially. Three rules that Rachel enforces at NE:

Rule 1: Process in priority order. The alerts are presented in severity order (HIGH first, then MEDIUM, then LOW). Process them in this order. Do not skip to Alert 5 (service account) because it looks easy and closeable. The HIGH-severity alerts demand attention first because the potential damage from a delayed HIGH is greater than the delay cost of keeping a LOW alert waiting.

Rule 2: Complete each alert before starting the next. Do not open Alert 2 while Alert 1 is still in progress. Each alert requires focused attention — context reading, query interpretation, scorecard scoring, and containment planning (if TP). Splitting attention between two alerts increases the risk of misclassification on both. The exception: if a CRITICAL alert arrives while triaging a MEDIUM, pause the MEDIUM (document where you stopped), triage the CRITICAL, then return to the MEDIUM.

Rule 3: Document as you go, not after. The triage report is not a post-triage documentation task — it is an DURING-triage recording. When you run Query 1 and see an anomalous IP, document it immediately in the incident comment: “Query 1: anomalous IP 185.220.101.42 (Tor exit, Romania) at 08:14. Device fingerprint mismatch.” When you score Q1 on the scorecard, document the score and reasoning immediately. At the end of the triage, the report is already complete — you do not need to remember what you found 10 minutes ago. This habit is what separates professional triage documentation from ad-hoc notes that the investigation team cannot interpret.

The shift handoff scenario. At NE, the SOC operates across shifts. If Analyst A triages Alert 1 but does not complete it before shift end, Analyst B must continue from where Analyst A stopped. The incident comments are the handoff mechanism — if Analyst A documented as they went, Analyst B reads the comments and continues from the last documented step. If Analyst A did not document, Analyst B starts the triage from scratch — duplicating 10-15 minutes of work. The document-as-you-go discipline is not just good practice for the investigation team handoff; it is essential for the shift handoff within the SOC.