4.2.1. Detection, Evidence Acquisition, and Chain of Custody
💡 First Principle: Evidence collected improperly is evidence that cannot be used — in court, in regulatory proceedings, or in disciplinary action. Chain of custody isn't paperwork; it's the mechanism that makes evidence legally defensible.
Detection and Analysis
IR begins when an indicator triggers investigation — either from a SIEM alert, user report, threat hunting finding, or external notification (law enforcement, ISAC, vendor). The first analysis phase answers: Is this a true incident? What systems are involved? What is the attacker's current activity?
Indicators of Compromise (IoCs) during detection:
- File hashes of known malicious executables
- IP addresses / domains used for C2
- Registry keys created for persistence
- User accounts created by the attacker
- Unusual processes or network connections
Evidence Acquisition
When an incident is confirmed, evidence must be collected before remediation — re-imaging or patching destroys forensic evidence. Evidence types and collection order (most volatile first):
| Evidence Type | Volatility | Collection Method |
|---|---|---|
| CPU registers / cache | Highest | Only if live forensics tooling in place |
| Running processes / network connections | Very high | EDR snapshot; netstat, ps, tasklist output |
| RAM (memory) | High | Memory acquisition tool (WinPmem, LiME for Linux), writing the image to external media or across the network, never to the suspect system's own disk |
| Disk (running system) | Medium | Live/logical acquisition (e.g., FTK Imager live capture); full bit-for-bit imaging waits for power-off |
| Disk (powered off) | Low | Physical removal and imaging with write blocker |
| Logs (SIEM/centralized) | Low | Already centralized; query and export |
| External/backup media | Lowest | Preserve as-is |
Chain of Custody
Every piece of evidence collected during an incident must be tracked through a chain of custody:
- Collection: Who collected it, when, from what system, using what method
- Handling: Every person who had access, when, and why
- Storage: How evidence is stored (encrypted, write-protected, physically secured)
- Transfer: Documentation of every handoff
- Disposition: Final fate of evidence (returned, destroyed, archived)
Why it matters: if evidence is challenged in court or regulatory proceedings, gaps in chain of custody allow opposing parties to argue the evidence was tampered with, rendering it inadmissible.
Validating Data Integrity — Hash the evidence immediately upon collection (SHA-256 of disk image, memory dump, log export). Any subsequent analysis is performed on a copy; the original is preserved. If the hash of the original changes, the evidence was modified.
Legal Hold — When litigation or regulatory investigation is anticipated, a legal hold instructs relevant parties to preserve all potentially relevant data and halts normal data deletion schedules (like log rotation or email purging). IT and legal must coordinate to identify what data is in scope.
Preservation — Forensic copies must be stored in a way that prevents modification: write blockers for physical media, read-only mounts for disk images, access-controlled repositories with audit logs.
⚠️ Exam Trap: Chain of custody is not only relevant to criminal investigations. It applies to any incident where the evidence might support disciplinary action, civil litigation, insurance claims, or regulatory compliance reporting. Organizations that don't maintain chain of custody "because it's not a criminal matter" lose the ability to take formal action against insiders or seek insurance coverage.
The CS0-004 Incident Response Process
CS0-004 lists seven phases: Preparation, Detection, Analysis, Containment, Eradication, Recovery, and Post-incident. It separates Detection from Analysis:
- Detection notices that something may be an incident: a SIEM correlation rule fires, an EDR sensor flags a process, a user calls the service desk, or a partner sends a notice.
- Analysis confirms it and scopes it: is this real, which systems and accounts are involved, and how is it happening?
The other CS0-004 phases fit around those two. Preparation is the work done before any incident: playbooks, training, the jump kit and out-of-band contact lists (detailed in 4.3.1). Containment, Eradication and Recovery are covered in 4.2.2. Post-incident is the review of what happened, with owners assigned to improvement actions (4.3.2).
NIST SP 800-61 adds a distinction between signs. A precursor suggests an incident may occur, such as a vendor bulletin about a new exploit for your web server. An indicator suggests one may have occurred or is occurring.
Log Collection, Correlation, and Enrichment
- Collection: get logs off the host and into central storage. A host the attacker controls as root cannot be trusted to keep its own logs. Preserve and hash what is there, then forward to a remote collector.
- Correlation: link events from different sources through shared values such as IP address, username, host, and time. NIST's example: the firewall has the source IP, the application log has the username, and only together do they show what happened.
- Augmentation and enrichment: add context to each event, such as GeoIP location, asset owner, business criticality, and threat-intelligence reputation, usually at ingestion. Enrichment speeds triage but does not tie events together by itself.
Alerts and Notifications. Critical alerts must reach an accountable person on a channel that interrupts them, such as an on-call page, with acknowledgment tracked and automatic escalation when nobody responds. A shared mailbox checked hourly is not an alerting process.
Triage. Triage is fast sorting: decide whether an alert is a true positive, give it an initial severity based on the behavior and the asset involved, and route it. Deep forensics belongs to analysis, not triage.
A confirmed false positive (for example, a legitimate IT automation script that triggers a PowerShell alert) is documented, the detection rule is tuned so it does not recur, and the case is closed. It does not move on to containment or eradication.
Establishing a Timeline. Convert every source to UTC, correct any measured clock drift, order events by when they happened (not when the SIEM ingested them), and document every adjustment. Record the time zone with each evidence entry.
Determining Severity and Impact, and Prioritizing
NIST says incidents should not be handled first-come, first-served. Prioritize on three factors, including the likely future impact if the incident is not contained:
| Factor | Categories |
|---|---|
| Functional impact | None; Low (all critical services still available, some efficiency lost); Medium (a critical service lost to a subset of users); High (some critical services unavailable to any users) |
| Information impact | None; Privacy breach (PII accessed or exfiltrated); Proprietary breach; Integrity loss (sensitive data changed or deleted) |
| Recoverability | Regular (predictable, existing resources); Supplemented (predictable, more resources); Extended (unpredictable, outside help needed); Not recoverable (e.g., data published) |
⚠️ Exam Trap: "Nothing left the network" does not mean information impact is None. Altered records are an integrity loss.
Evidence Gathering: Legal Hold in Practice
The duty to preserve starts when litigation is reasonably anticipated, not when a lawsuit is filed. Federal Rule of Civil Procedure 37(e) addresses electronically stored information that "should have been preserved in the anticipation or conduct of litigation", and intentional destruction can lead to an adverse inference or dismissal. When counsel expects a suit, issue the hold at once: suspend log rotation and mailbox purges for the data in scope and record what was preserved.
Preservation when powering down. After memory has been captured, NIST SP 800-86 notes that a graceful OS shutdown runs cleanup routines and can let malware remove itself, while removing power preserves swap and temporary files at some risk of file system corruption. Choose deliberately and record the choice.
Reflection Question: During an IR engagement, a junior analyst copies suspicious files from a compromised server to a USB drive, then analyzes them on a personal laptop. They find clear evidence of data theft. Why might this evidence be challenged, and what should the analyst have done instead?