In the chaos of a ransomware or major breach incident, the instinct is to act — power off affected machines, rebuild systems, restore from backup, get operations running again. That instinct is understandable. It is also, from a forensic perspective, often catastrophic.
The majority of organisations we respond to have already destroyed significant forensic evidence before calling us. Not through negligence — through reasonable, well-intentioned IT responses that happen to obliterate the data we need to understand what happened, how the attacker moved, and what they accessed.
This post explains what evidence exists, why it matters, and what not to do in the critical first hours.
Why Evidence Preservation Matters
Forensic evidence serves multiple purposes beyond satisfying investigator curiosity:
- Determining scope: What systems were accessed, what data was exfiltrated — essential for breach notification obligations under GDPR
- Root cause analysis: How did the attacker get in? Without this, you cannot close the initial access vector and risk re-compromise
- Threat actor attribution: Which group is responsible? This affects negotiation strategy, decryptor viability, and sanctions screening
- Legal proceedings: If you pursue law enforcement referral or civil litigation, evidence collected and preserved to forensic standards is required
- Insurance claims: Insurers require evidence that the incident was investigated properly; inadequate forensics can affect claim validity
- Regulatory enquiries: The ICO and sector regulators may ask detailed questions about what you knew and when — you need evidence to answer them
The Most Valuable Evidence You Destroy First
Volatile Memory (RAM)
RAM contains running processes, network connections, encryption keys, attacker tools loaded in memory, and credentials. It is the richest source of real-time forensic data — and it is destroyed the moment a machine is powered off or rebooted.
Rebooting an affected server to "see if it clears the problem" is one of the most common errors we encounter. By the time we arrive, the RAM has been written over dozens of times. The attacker's malware, the credentials they were using, the encryption keys that might have allowed decryption — gone.
If a system is running and you have not yet called in forensic support, do not power it off unless there is an immediate safety requirement to do so. Isolate it from the network — disconnect the cable or disable the network interface — but leave it powered on.
Windows Event Logs
Windows event logs record authentication events, process creation, service installation, account changes, and network connections. They are invaluable for reconstructing attacker activity — but they have size limits and roll over. Logs from the initial access phase, which may have occurred weeks before the ransomware deployment, may already have rolled over naturally. Do not accelerate that by clearing logs or resizing log storage during an incident.
In environments where logs are not forwarded to a SIEM or centralised log store, the only copy of authentication and activity logs may be on the affected endpoint. If that endpoint is wiped and rebuilt, those logs are gone permanently.
Network Flow Data and Firewall Logs
Network logs show lateral movement — how the attacker moved from system to system — and exfiltration — large data transfers to external infrastructure in the days before ransomware deployment. Firewall and proxy logs often capture the exfiltration event even when endpoint logs do not. These are frequently stored short-term and may roll over within days. Preservation is time-critical.
Disk Images
Before rebuilding or wiping any system, it should be forensically imaged — a sector-by-sector copy of the disk that preserves all data including deleted files and file system metadata. Rebuilding without imaging destroys evidence permanently. In some cases, deleted malware, attacker staging directories, and credential harvest output can only be recovered from disk images taken before rebuild.
Common Mistakes That Destroy Evidence
Rebooting Affected Systems
As above — destroys RAM. Avoid unless there is no alternative.
Running Antivirus or EDR Remediation Immediately
AV and EDR tools, when they quarantine or delete malware, destroy the malware samples themselves — which are valuable for analysis. If you have endpoint security tooling that has detected activity, document what it found before allowing it to remediate. Quarantine is preferable to deletion where your tooling supports it.
Wiping and Rebuilding Before Imaging
The urgency to restore operations is real. But rebuilding a system without imaging it first is a permanent, irreversible loss of forensic data. Even a few hours spent imaging key systems before rebuild can dramatically improve investigative outcomes.
Letting Staff Continue to Use Compromised Systems
Normal use of a compromised system overwrites evidence. File system timestamps change, logs update, RAM contents change. Where a system is suspected of compromise, restrict or suspend use until it has been forensically examined.
Communicating Over Potentially Compromised Channels
If your email or Teams environment was accessible to the attacker, do not use it to communicate about the incident. The attacker may still be watching. Use out-of-band communication — personal phones, Signal, a clean device on a separate network — for incident coordination.
What to Do Instead
When you discover or suspect an incident:
- Isolate, don't power off. Disconnect affected systems from the network while keeping them powered on where possible
- Call IR immediately. Every hour without forensic guidance is potential evidence loss
- Preserve logs urgently. Export Windows event logs, firewall logs, and VPN access logs before they roll over
- Document everything. Screenshots, photographs of screens showing ransom notes or error messages, notes of what was observed and when
- Do not communicate the incident over potentially compromised infrastructure
- Do not allow IT staff to "clean" systems without forensic guidance — this is the single most common evidence destruction event we see
Chain of Custody
If you anticipate legal proceedings — whether law enforcement referral, civil litigation, or regulatory investigation — evidence must be collected in a manner that supports chain of custody. This means documented collection procedures, cryptographic hashing of evidence items, secure storage, and a complete record of who accessed evidence and when.
Evidence collected informally by internal IT staff, while not worthless, is significantly weaker in legal proceedings than evidence collected to forensic standards by accredited practitioners. If legal action is a realistic possibility, engage forensic professionals early.
Binary Response provides immediate digital forensics response and evidence preservation support. If you are in an active incident, contact us at enquiries@binary-response.com. Do not reboot, do not wipe — call first.