Incident Response and Threat Hunting
The Incident Response and Threat Hunting domain tests whether you can run a structured investigation: scope an intrusion, preserve evidence in the right order, and hunt for adversary behavior that no alert has caught yet. Expect scenario questions where you must choose the next action, justify an evidence-collection order, or turn an intelligence report into a hunt plan.
Core rules
- Follow a recognized lifecycle: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned (PICERL). NIST SP 800-61r2 frames the same phases and stresses documentation at every step.
- Collect in order of volatility (RFC 3227): CPU registers and cache, memory, network state and connections, running processes, disk, remote logs, archival media.
- Maintain chain of custody: label, hash with SHA-256, and log who handled evidence and when. A broken chain can invalidate findings.
- Hunt with hypotheses, not IOC lists. Pick a technique from MITRE ATT&CK, state what telemetry would prove it, then query.
Worked example
A SIEM alert shows a suspicious scheduled task created on a workstation. Before deleting it, capture the task XML, the creating process tree, the user context, and the task action binary hash. Then search other endpoints for the same task name and binary hash to scope. Reasoning: the task is persistence; deleting first destroys the evidence that identifies the loader and any lateral spread.
Traps
- Containing or remediating before capturing volatile data.
- Hunting only known IOCs, which misses renamed tooling.
- Treating one log source as ground truth.
- Forgetting timezone normalization, which breaks timelines.
- Writing conclusions before the evidence is scoped.