You've confirmed a data breach. Systems are compromised. The instinct is to shut everything down, wipe and rebuild, get back to normal as fast as possible.
That instinct will cost you.
In our experience across hundreds of incidents, the evidence destroyed in the first hour of response causes more long-term damage than the breach itself. It undermines insurance claims, weakens legal positions, and makes it impossible to determine what was actually stolen.
This guide covers how to contain a breach effectively while keeping your forensic evidence intact.
Why Evidence Matters More Than You Think
Evidence isn't just for catching the attacker (though it helps). It's critical for:
- Insurance claims: Insurers increasingly require forensic evidence to validate claims. No evidence, reduced payout — or denial.
- Regulatory compliance: GDPR Article 33 requires you to document the nature of the breach, categories of data affected, and likely consequences. You can't document what you've destroyed.
- Notification scope: Forensic evidence determines how many people you need to notify. Without it, you may have to assume worst-case scope — notifying everyone instead of just affected individuals.
- Legal proceedings: Whether you pursue the attacker, defend against litigation from affected parties, or negotiate with regulators — evidence is your foundation.
- Root cause analysis: How did they get in? If you don't know, you can't prevent it happening again.
The Order of Volatility
Digital evidence has a shelf life. Some evidence disappears in seconds, some persists for months. Collect in order of volatility:
- CPU registers and cache — Gone the instant power is lost. Rarely collected outside specialist forensics.
- Memory (RAM) — Contains running processes, encryption keys, network connections, malware in execution. This is the single most valuable evidence source. Lost when system is powered off or rebooted.
- Network state — Active connections, routing tables, ARP cache. Changes constantly. Capture immediately.
- Running processes — What's executing right now? Process lists, open files, loaded DLLs. Changes with every second.
- Disk contents — File system, logs, registry, deleted files. More persistent but can be overwritten by continued system use.
- Network logs — Firewall logs, proxy logs, DNS logs, SIEM data. Usually retained for days to months depending on configuration.
- Backups and archives — Historical data. Most persistent but may also be compromised.
Containment Without Destruction
Strategy 1: Network Isolation (Preferred)
Disconnect the system from the network while keeping it powered on. This stops the attacker's access and prevents lateral movement while preserving all volatile evidence.
How to isolate correctly:
- Disconnect the network cable (don't disable the adapter in software — that can trigger malware kill switches)
- For wireless: disable the access point or block the MAC address at the router, not on the endpoint
- Move the system to an isolated VLAN if physical disconnection isn't feasible
- Do NOT shut down, reboot, or log off
Strategy 2: Firewall Segmentation
When you can't physically disconnect systems (production servers, cloud infrastructure), use firewall rules to isolate them:
- Block all outbound traffic from compromised systems
- Allow only forensic tool traffic inbound
- Log all blocked connection attempts (valuable intelligence)
- Keep the systems running and accessible to forensic teams
Strategy 3: Credential Isolation
Sometimes the fastest containment is revoking the attacker's access without touching the systems:
- Reset all compromised account passwords (including service accounts)
- Revoke active sessions and tokens
- Disable compromised VPN profiles
- Rotate API keys and certificates
Evidence Collection: What to Capture and How
Immediate Captures (First 30 Minutes)
| Evidence Type | Tool / Method | Why It Matters |
|---|---|---|
| Memory dump | WinPMEM, FTK Imager, LiME (Linux) | Captures running malware, encryption keys, attacker tools in memory |
| Process list | tasklist /v, ps aux, Volatility | Shows what was running at time of detection |
| Network connections | netstat -anob, ss -tulpn | Reveals C2 servers, lateral movement, data exfiltration endpoints |
| Event logs | wevtutil, journalctl | Authentication events, process creation, privilege escalation |
| Screenshots | Phone camera, screenshot tool | Ransom notes, error messages, unusual displays — simple but often forgotten |
Secondary Captures (Hours 1-24)
| Evidence Type | Tool / Method | Why It Matters |
|---|---|---|
| Full disk image | FTK Imager, dd, KAPE | Complete forensic copy for detailed analysis |
| Firewall/proxy logs | SIEM export, syslog | Data exfiltration timeline, C2 communication patterns |
| Email headers | Exchange/M365 message trace | Phishing email analysis, lateral phishing detection |
| Cloud audit logs | Azure AD, AWS CloudTrail, GCP | Unauthorised access, configuration changes, data access |
| Endpoint detection logs | EDR console export | Malware detections, process trees, timeline reconstruction |
The 5 Evidence-Destroying Mistakes We See Every Week
Mistake 1: Powering Off Systems
Why it happens: Panic. "Turn it off" feels like containment.
What you lose: All volatile memory — running processes, encryption keys, active network connections, malware in execution.
Instead: Network isolate. Keep systems running.
Mistake 2: Running Antivirus Scans
Why it happens: "We need to clean the infection."
What you lose: The malware itself (quarantined or deleted), file timestamps, disk state.
Instead: Capture evidence first, remediate second. The malware IS the evidence.
Mistake 3: Rebuilding from Backup Immediately
Why it happens: "We need to get back to business."
What you lose: The compromised system's evidence. Also risk restoring infected backups.
Instead: Image the compromised system first. Test backups in isolation. Then restore.
Mistake 4: Resetting All Passwords at Once
Why it happens: "Lock everything down."
What you lose: The attacker's active sessions (evidence of what they were doing). May also trigger attacker's dead man's switch.
Instead: Targeted credential rotation. Monitor, then contain.
Mistake 5: Communicating on Compromised Channels
Why it happens: Using the company's normal email and Slack to coordinate response.
What you lose: Operational security. The attacker reads your response plans.
Instead: Switch to out-of-band communications immediately. Personal phones, encrypted messaging, separate email accounts.
Chain of Custody
Evidence is only useful if it's admissible. Maintain chain of custody from the start:
- Document who collected what, when, and how
- Hash all evidence (MD5 + SHA-256) immediately upon collection
- Store originals separately — work only with forensic copies
- Use write-blockers for disk imaging where possible
- Maintain a written log of all evidence handling
When to Call for Help
If any of these apply, engage professional DFIR support before proceeding:
- Active attacker still in your environment
- Data exfiltration confirmed or suspected
- Regulatory notification may be required
- Insurance claim likely
- Legal proceedings possible
- You're not sure what you're looking at
Professional incident responders have done this hundreds of times. They know what evidence matters, how to collect it without contamination, and how to present it to insurers, regulators, and courts.
Evidence-Preserving Incident Response
Our DFIR team specialises in forensically sound containment and investigation. Every engagement produces court-admissible evidence and comprehensive reporting.