Implement incident response techniques
Containment, eradication and recovery in practice — isolation, segmentation, reimaging, patching, and validating the fix held.
- Reading time
- 26 min read
- Flashcards
- 18 cards
- Practice questions
- 8 questions · 2 PBQs
3.2 was the shape of the process. This is the hands-on half: how you actually contain, what eradication involves in practice, and how evidence is handled so it survives scrutiny.
Containment in practice
Three techniques, and the exam distinguishes them:
Isolation
Removing a system from the network entirely, usually via EDR or a switch port change. Total containment, and the attacker immediately knows.
Segmentation
Moving the system to a restricted network segment where it can be observed but cannot reach anything valuable. Slower to arrange, and it lets you keep watching the attacker.
Removal
Taking the system out of service completely. The most drastic option, and it costs you both the evidence in memory and any chance of observing further.
The trade-off is always stop the attacker now versus learn more first. Isolation is right when damage is ongoing or data is leaving. Segmentation is right when the intrusion is stable, the scope is unclear, and you gain more from watching than from stopping — a judgement made by the incident commander, not unilaterally by an analyst.
Eradication and recovery in practice
Eradication — remove what the attacker put there and close what let them in:
- Remove malware and every persistence mechanism found (scheduled tasks, Run keys, services, WMI subscriptions)
- Reimage where the compromise is deep — rebuilding from a known-good image is the only way to be confident about a host that had kernel-level or unknown-scope compromise
- Patch the vulnerability that was exploited
- Reset credentials that were, or may have been, exposed
- Sanitisation and secure disposal for media that cannot be trusted or is being retired
Recovery — bring services back safely:
- Restore from known-good backups, verified clean, not merely recent
- Reconstruct systems where no trusted backup exists
- Restore permissions to their intended state — attackers change them, and a rushed recovery preserves the attacker's changes
- Reconstitute resources and return capability in stages
- Verify logging and monitoring are working on restored systems
Check yourself
A host was compromised with a rootkit of unknown scope. Antivirus reports the malware as removed. What is the appropriate action?
Evidence handling
Forensic discipline matters even when nobody expects litigation, because the decision about whether an incident becomes a legal matter is usually made after the evidence was, or was not, handled properly.
Order of volatility
Collect evidence from most volatile to least, because the fragile sources disappear while you work on the durable ones.
The order, most volatile first:
- CPU registers and cache
- Memory (RAM) — running processes, injected code, network state, keys
- Network state and running processes
- Temporary file systems
- Disk
- Remote logging and monitoring data
- Physical configuration and network topology
- Archival media — backups and tapes
Chain of custody
An unbroken record of who had the evidence, when, and what they did with it. A gap in the record is enough to have evidence excluded, regardless of what it shows.
Write blocker
Hardware or software that permits reading from a drive while preventing any write to it. Without one, merely connecting a drive can alter timestamps and metadata, which compromises the integrity of the whole image.
Forensic imaging and hashing
A bit-for-bit copy of the original, hashed before and after. Matching hashes prove the image is identical to the source and unchanged since acquisition — and all analysis is performed on the copy, never the original.
Legal hold
A directive to preserve all data potentially relevant to anticipated litigation, which suspends normal retention and deletion. It overrides routine destruction schedules, and ignoring one has consequences of its own.
Two analysis techniques appear by name: file carving recovers deleted files by their content signatures when the file system metadata is gone, and timeline reconstruction orders events across sources into a single sequence — which only works if clocks were synchronised, tying straight back to Objective 1.1.
Check yourself
Which sequence correctly reflects the order of volatility?
Root cause analysis
Establishing what genuinely allowed the incident, not the last thing that happened before it. "Five whys" is the usual technique: keep asking why until you reach something you can actually change.
A user clicked a link → the macro executed → macro execution was unrestricted → there was no policy restricting macros from internet-sourced documents, and no detection for Office spawning shells. The last statement is a root cause because it names something fixable. The first is a description of an ordinary Tuesday.