Triage: deciding what this actually is

Why this matters

Between an alert firing and an incident being declared sits the work of this lesson: deciding what the thing is, how bad it is, and how far it reaches.

It is the highest-leverage hour of any response. Get the scope wrong and you contain three hosts out of forty, watch the attacker continue, and learn a week later that the eradication was theatre. Get the severity wrong and you either wake an executive over an adware detection or leave a domain compromise in the queue behind a phishing report.

The lesson

Severity, urgency and impact

Three words used interchangeably in conversation and distinguished on the exam.

• Impact — how bad the consequence is. Data exposed, systems unavailable, money lost, safety affected, regulatory consequence.
• Urgency — how fast it must be dealt with. Driven by whether it is ongoing, spreading, or on a deadline.
• Severity (or priority) — the combination, which is what actually determines the response.

The distinction earns its keep because the two axes come apart, and the pairs that come apart are where judgement is needed:

• High impact, low urgency. A serious data exposure that ended months ago. Grave, and nothing is on fire; rushing adds nothing.
• Low impact, high urgency. Commodity malware spreading rapidly across workstations. Each host is minor; the trajectory is not.
• High impact, high urgency. Ransomware mid-encryption, an active hands-on intrusion, exfiltration in progress.

Factors that should drive the rating:

• Is it ongoing? An active attacker outranks almost everything.
• What is the asset and what data does it hold? Lesson 23's criticality, reappearing here.
• How many systems or accounts are involved, and is that number growing?
• What level of access does the attacker have? A standard user is a different incident from a domain administrator.
• Is there a regulatory or contractual clock? Personal data changes the shape of the response, per lesson 26.
• Is the business function affected?

Two cautions. Rate on what you know and revise openly — initial severity is provisional, and a triage rating that never changes across an incident is usually one nobody revisited. And beware the anchoring effect of the alert's own severity: a "medium" SIEM rule that fired on a domain controller is not a medium incident, and the tool has no idea what the host is.

Scoping: how many hosts, how many accounts

The question that most often has the wrong answer early.

The default assumption should be that the scope is larger than the alert suggests, because you found the intrusion at the point where it was noisy enough to detect, not at the point where it started.

Scoping systematically:

• Hosts. Which systems show the indicator? Search the estate for it rather than examining the one that alerted. If you can only search the host that alerted, that is a preparation finding.
• Accounts. Which accounts were used on the compromised host, including service accounts and any credential that was cached or in memory there? Treat every credential that touched a compromised host as compromised — this is the rule people shortcut and regret, because credential theft from memory does not leave the tidy evidence a login does.
• Time. When does the earliest evidence sit? Then look earlier still: the first observed activity is rarely the first activity.
• Data. What was accessible from the access obtained, and what was actually touched? Those are different questions and both get asked.
• Network. What could the compromised host reach — the lateral movement question from lesson 3.
• Externally. Does infrastructure seen here appear elsewhere in your logs, at a different time, against a different host? The Diamond Model pivot from lesson 27.

Two things that make scoping possible, and both are preparation: centralised logs with real retention, and the ability to query the whole estate at once. Without them, scoping degrades to examining hosts one at a time, which does not finish.

And record scope as a statement with a boundary: "confirmed on four hosts, searched the whole estate for the indicator, retention limits the search to 30 days". Not "four hosts affected", which is a claim about the world that your evidence does not support.

Pivoting from one artefact to the next

The core analytical technique of response: every artefact you hold gives you a search that can produce the next one.

The standard pivots:

• A host → its processes, connections, files and logins. Then: what talked to it, what it talked to.
• A file hash → every host with that file, and the reputation and sandbox history of the sample.
• An IP or domain → every host that contacted it, plus its resolution history, its certificate, and what else shares them.
• An account → every authentication it made, where from, to what, and whether the pattern changed.
• A time window → everything unusual in it, which is how you find the activity you had no indicator for.
• A technique → the other techniques that accompany it (lesson 27), which is how you look for what you have not yet found.

How to pivot without getting lost:

• Record every pivot and its result, including the ones that found nothing. A negative result is evidence, and you will otherwise repeat it at hour five.
• Watch for the pivot that widens too far. A shared hosting IP or a Microsoft domain will match half the estate. An indicator's value depends on its specificity — the pyramid of pain from lesson 13.
• Prefer pivots that could disprove your theory, not only ones that confirm it. Confirmation bias in an investigation produces a confident, wrong narrative faster than anything else.
• Keep a list of open threads. Investigations branch, and the unexamined branch is where the second foothold lives.

Timeline construction

The single most valuable artefact a responder produces, and the one that turns a pile of observations into an account of what happened.

A workable timeline is a table with: timestamp (in UTC), source, host, account, event, and how confident you are. Building it as you go rather than afterwards is not a style preference — reconstructing a timeline at the end means re-deriving everything, and lesson 38 covers why contemporaneous notes carry weight that recollection does not.

The mechanical traps, all of which have wrecked real timelines:

• Time zones. Normalise everything to UTC and say so. Mixed local times produce events that appear to precede their own causes.
• Clock skew. Hosts disagree. Note the offset where you know it.
• Log timestamp semantics differ — written time, received time, event time, indexed time. A SIEM's ingestion time is not the event's time, and under load they can diverge by a lot.
• Timestamps are attacker-modifiable on disk. Filesystem times can be altered; log timestamps from a centralised collector are harder to touch, which is one of several reasons to ship logs off the host.

What a good timeline gives you, and why the effort pays:

• The earliest evidence, which sets the real scope of your search.
• Gaps, which are as informative as entries — a quiet week in the middle usually means missing telemetry rather than a dormant attacker.
• The story, in a form you can hand to somebody else without narrating it.
• The root cause, which usually sits at the top of a complete timeline and nowhere else.

Knowing when to stop analysing and start containing

The judgement call that defines this phase, and one the exam tests as a scenario.

Analysing longer gives better scope, more evidence, and a more complete eradication. Containing sooner stops the damage. They are in direct tension and the trade is real.

Contain now, analysis unfinished, when:

• The attacker is actively working, hands on keyboard.
• Encryption or destruction has started, or is imminent.
• Exfiltration is in progress.
• The path leads toward a crown-jewel system you can still get in front of.
• The spread rate means waiting an hour materially changes the outcome.
• Safety or life-critical systems are involved, where the calculus is not close.

Analyse further before containing, when:

• The activity is dormant or historic, with no current action.
• You have partial scope and containing what you see would tell the attacker you are there while leaving their other access intact. This is the important one: partial containment against a live, capable intruder is worse than none, because it burns surprise and buys little.
• The containment action is highly disruptive and the evidence is still ambiguous.
• Evidence would be destroyed by the containment action and cannot be captured first.

Practical ways to hold both:

• Capture volatile evidence first where you can — memory, connections, process list — then contain. Often minutes, and lesson 31 covers how.
• Prepare containment for the full scope, then execute it together, rather than host by host as you find them.
• Contain in ways that do not announce themselves, where the situation allows: network segmentation rather than an obvious block page, monitoring at a chokepoint rather than an EDR quarantine popup on the attacker's session.
• Set a decision point in advance. "We will contain at 14:00 regardless of what we know by then" is a much better instrument than an open-ended investigation, because the default failure of this phase is not containing too early — it is analysing indefinitely while nobody decides.

Topics this lesson owns

• [x] Severity, urgency and impact
• [x] Scoping: how many hosts, how many accounts
• [x] Pivoting from one artefact to the next
• [x] Timeline construction
• [x] Knowing when to stop analysing and start containing