2.2 Classification and Escalation Scoring

Key Takeaways

  • Each SOC Simulator scenario is 400 marks: Classification 150, Escalation 150, and Case Reports 100 (TryHackMe scoring article, 29 March 2025).
  • Not every alert requires escalation; the SOC Simulator advice article says to focus on alerts with clear indicators of compromise and to follow a structured classification then escalation process.
  • TryHackMe's SAL1 technical-issues article (19 May 2025) warns that if you misclassify at least 1 true positive or the time runs out, the whole section is marked 0.
  • Distinguish true positive, false positive, and benign true positive before you decide to escalate or close.
  • When uncertain, spend minutes confirming a possible true positive rather than casually marking it false—one missed TP zeros the section under that published warning.
Last updated: September 2026

Classification and escalation are not leftover paperwork after you "find the hacker." They are most of a SOC Sim's points. TryHackMe's scoring article (29 March 2025) breaks each simulator scenario into 400 marks: Classification 150, Escalation 150, and Case Reports 100. Two scenarios therefore contribute 800 marks toward the 750 / 1,000 pass mark. You can theoretically have a decent case narrative and still fail the exam if classification and escalation collapse. Work them as a structured pipeline, in that order.

The 400-mark split, in analyst language

Classification is the verdict you attach to each alert: what kind of event is this, and is it malicious, noisy, or authorized? Escalation is the decision to push a confirmed problem to the next owner with enough evidence to act. Case reports (next section) are the written investigation that ties alerts together. Marks are listed separately so you cannot hide a wrong verdict inside a long write-up, or escalate everything "to be safe" without classifying.

ComponentMarks per scenarioWhat it rewardsTypical failure
Classification150Correct verdicts on the alert set, especially true positivesLabelling a real intrusion as a false positive
Escalation150Raising the alerts that need a responder, with usable IoCsEscalating the scanner; sitting on a confirmed C2 beacon
Case reports100Structured notes that another analyst can act onA story with no times, hosts, or recommendations

The SOC Simulator advice article (11 March 2025) tells you to follow a structured classification and escalation process, and it says not all alerts require escalation—focus on those with clear IoCs. Those two sentences are the scoring strategy: earn classification by being right; earn escalation by being selective and complete on the true positives.

The published zero-mark warning (do not soften this)

TryHackMe's SAL1 technical-issues article (19 May 2025), in the subsection on timer or exam progress not updating, states that if you misclassify at least 1 TP or the time runs out the whole section will be marked as 0. Teach that as TryHackMe's published language, not as a rumor.

Two independent ways to zero a section:

  1. Misclassify at least one true positive. A real phishing payload, beacon, or credential dump labelled false positive (or otherwise not recognised as a TP) is enough, according to that article.
  2. Time runs out. The format article gives 2 hours per scenario. If the scenario timer expires, the same technical-issues article says the whole section is marked 0.

"Section" here is the SOC Sim section you are in—not a promise that the multiple-choice paper is untouched, and not a promise of partial credit inside that sim. The published warning is absolute: one missed TP or a timeout → 0 for the section. Do not tell yourself you will "pick up some classification points anyway."

That pairing is what makes the simulator harsh. You must finish, and you must not miss TPs. Spending 50 minutes proving an interesting false positive while an unclassified malware alert sits in the queue is how both failure modes sneak up together: you either timeout, or you rush the remaining TPs and mislabel one.

Practical posture under that rule:

  • First pass: identify every alert that could be a TP. Confirm or refute with Splunk quickly.
  • Do not casually click false positive on a host that pulled an unknown script from a lookalike domain.
  • If time is low, correctly classify remaining likely TPs and write short escalations; do not start a new deep-dive that risks the clock.
  • Closing obvious scanner noise is good—so long as you did not "close" a TP to tidy the queue.

True positive vs false positive vs benign true positive

Use three verdicts the way a SOC uses them. Mixing them up is how TPs get marked FP.

True positive (TP)

The detection fired on activity that is genuinely malicious (or a real policy violation of the sort the detection is meant to catch). Example, continuing Northwind Logistics from section 2.1:

  • Mail gateway: lookalike domain northwind-logiistics.example (extra i) sends the CFO a "wire invoice" with a link.
  • Proxy: WS-FIN-14 / j.patel GETs http://updates-cdn-mail.example/invoice.js.
  • Windows: wscript.exe launches that script; a new outbound HTTPS session to 198.51.100.44 repeats every 60 seconds.

Classify true positive. The rule is not confused; an attacker delivered, executed, and called home. Collect IoCs (domains, URL, hash if present, IP, user, host) for escalation.

False positive (FP)

The detection fired, but the event is not what the rule claims. The pattern matched junk: a bad field extraction, a signed admin script that only looks encoded, or a user-agent substring that collides with malware lore. Example:

  • Alert: "Encoded PowerShell – possible fileless malware" on WS-IT-02.
  • Docs: IT uses a signed Deploy-Helpdesk.ps1 from \\tools.northwind-log.example\it every Monday.
  • Splunk: the parent is msiexec.exe from that share; the command line matches the documented installer; no new network callback; hash is the known internal package.

Classify false positive. The activity is not malware. Close with the documentation pointer. Escalating it as an incident trains responders to ignore you and spends escalation effort on a non-event.

Benign true positive (BTP)

The detection is technically correct—the activity matches the pattern—but it is authorized or expected. Example:

  • Alert: "Many outbound connections to newly registered domains" from SCAN-01 (10.20.9.15) at 02:10 UTC Saturday.
  • Docs: SCAN-01 is the vulnerability scanner; Saturday 02:00–04:00 is the approved external-scan window.
  • Splunk: the destinations are customer-facing web roots listed in the scan scope, User-Agent is the scanner string, and WS-FIN-14 is not talking to those same new domains.

Classify benign true positive. The detector told the truth about "lots of new domains"; the company wanted that traffic. Usually you close with that justification. You escalate a BTP only if local policy says scanner findings still need a tracking ticket—not because the connections looked "scary" in isolation.

VerdictDetector correct?Malicious / incident?Default next step
True positiveYesYesEscalate with IoCs and affected assets
False positiveNoNoClose; cite why the rule misfired
Benign true positiveYesNo (authorized)Close; cite the authorizing control or window

The dangerous exam error is stuffing TPs into the FP or BTP buckets so the queue looks "done." Under the 19 May 2025 warning, that is not a style issue; it is a section zero.

Worked example: escalate vs close

Use the same three Northwind alerts.

Escalate — phishing delivery (alert 1) and payload/C2 on WS-FIN-14 (alert 2, plus any later process/C2 alerts that share IoCs). Why: clear IoCs, a user execution path, and a repeating callback. The SOC Simulator advice says to escalate when necessary and to focus on clear IoCs; this is that pile. Your escalation package should name:

  • Times: 13:02:11 UTC mail, 13:04:44 UTC download, beacon interval if seen.
  • Assets: cfo@..., j.patel, WS-FIN-14 (10.20.40.88), possibly FILE-FIN-01 if you saw access.
  • IoCs: sender domain, URL, hash, C2 IP/domain.
  • Ask: isolate WS-FIN-14, block the domain/IP at proxy and firewall, reset j.patel (and CFO if they opened the mail), preserve the mailbox copy.

Close — scanner outbound (alert 3) after a short confirm. Why: asset is SCAN-01, documented window, destinations in scope, no overlap with the finance IoCs. This is BTP. Closing it is not laziness; it is the "not all alerts require escalation" rule. If you escalated alert 3 with the same urgency as the C2, you would bury the incident in noise and show you did not read the docs.

Do not escalate yet — a lone failed logon with no other IoCs. Example: one 4625 on a jump host from a user who, per HR notes in the docs, is travelling. Classify according to evidence (often FP or low-confidence until correlated). Park it, hunt whether the C2 IP ever authenticated, and only escalate if it joins the TP chain. Structured means: verdict first, promotion second.

Operating order that protects both 150s and the clock

  1. Snapshot the queue (section 2.1).
  2. For each alert: timestamp, asset, docs check, bounded Splunk.
  3. Assign TP / FP / BTP. If it might be a TP and you are short on proof, keep investigating—do not guess FP to clear it.
  4. For TPs with clear IoCs: escalate immediately with the evidence you have; you can append later dynamic alerts to the same incident.
  5. For FP / BTP: close with one factual sentence.
  6. Re-check the queue. New dynamic TPs must be classified before the timer dies.

Escalation without classification is noise. Classification without escalation on a confirmed beacon is an incomplete SOC action. Missing a TP or missing the clock, per TryHackMe's May 2025 technical-issues article, is a zero.

Marks in one SAL1 SOC Simulator scenario (400 total)
Test Your Knowledge

According to TryHackMe's scoring article (29 March 2025), how are the 400 marks in one SOC Simulator scenario divided?

A
B
C
D
Test Your Knowledge

TryHackMe's SAL1 technical-issues article (19 May 2025) warns that which of the following marks the whole section 0?

A
B
C
D
Test Your Knowledge

A firewall alert shows many outbound connections from SCAN-01, which company documentation names as the approved vulnerability scanner in a Saturday maintenance window. Proxy logs show no user workstation talking to those destinations. What is the best pair of actions?

A
B
C
D
Test Your Knowledge

WS-FIN-14 downloaded invoice.js from a lookalike domain after a CFO-targeted message, then beaconed to 198.51.100.44 every 60 seconds. How should you classify and handle that chain?

A
B
C
D