How to Preserve Evidence After a Cyber Incident (Without Destroying What You Need)

Evidence preservation is the first discipline of forensic investigation, and it is the one most frequently violated in the hours before a DFIR team arrives. Not through negligence, but through good intentions. Someone powers off the compromised server to stop the damage. An IT team member reimages the affected laptop so the employee can get back to work. The log files from the firewall are deleted to make room for new entries. Each of these actions makes sense from a certain perspective. Each of them destroys evidence that cannot be recovered.

The problem is that evidence destruction in the first hours of an incident is largely invisible. There is no error message, no failed action. The system is reimaged and looks clean. The logs are gone. The memory is wiped. It is only later, when the forensic investigation is underway and the investigator asks for the disk image from the affected endpoint, that the gap becomes apparent. At that point, the question of how the attacker got in, what they accessed, and where else they went may be unanswerable. That unanswered question sits in every subsequent report you file with regulators and insurers.

What Evidence Exists and Why It Is Fragile

Digital evidence in an incident falls into two categories: volatile and non-volatile. Volatile evidence exists only while a system is running: the contents of memory, active network connections, running processes, and the decrypted state of any encrypted data the attacker is using. This evidence is destroyed the moment the system is powered off. It cannot be recovered from disk after the fact. If volatile evidence is relevant to your investigation, which it frequently is, the system must be forensically imaged while it is running, before power is removed.

Non-volatile evidence persists after power is removed: the contents of the disk, file system metadata including creation and modification timestamps, registry entries, event logs stored on disk, and application logs. This evidence is more durable but not indestructible. Reimaging a disk overwrites it completely. Running antivirus or remediation tools on a live system modifies file access timestamps. Logging infrastructure that is running concurrently continues writing, potentially rolling over the entries that captured the attacker's activity. Non-volatile evidence degrades more slowly but does degrade, and some actions destroy it instantly.

What Not to Do in the First Hours

The actions most likely to destroy evidence in the first hours of an incident are:

• Powering off systems instead of isolating them from the network. Isolation preserves volatile evidence; shutdown destroys it.
• Reimaging or restoring affected endpoints before forensic images are taken.
• Running antivirus or endpoint detection scans on affected systems. These modify file access timestamps and may delete files before they are examined.
• Deleting or rotating logs that are believed to contain evidence of the attack.
• Copying files from an affected system to a USB drive using the affected system itself, which modifies metadata.
• Opening suspicious files on a standard workstation to "check what they are".

These actions are almost universally well-intentioned. Brief your IT team on this list before an incident occurs. The briefing takes 20 minutes and can save an investigation.

The Right Actions for Evidence Preservation

The correct approach to an affected system before a DFIR team arrives depends on the system type and the nature of the incident. In most cases, the right action is to isolate the system from the network without powering it off: disconnect the network cable or disable the network interface, but leave the system running. This preserves volatile evidence while preventing the attacker from continuing to use the system.

Concurrently, preserve logs before they can roll over. Export logs from network devices, firewalls, identity platforms, and cloud environments to a separate, unaffected storage location. These logs are critical for the forensic timeline and for understanding the attacker's movement through the environment. The priority should be logs from systems closest to the initial access point and from authentication infrastructure, as these tend to contain the most significant evidence. Your DFIR team can advise on collection priorities once engaged, but getting logs off systems that are continuing to run is time-sensitive.

Engaging a DFIR Team Before Acting on Affected Systems

The most effective evidence preservation strategy is simple: do not take actions on affected systems until a qualified DFIR team is engaged and advising on the response. This is easier to follow when you have a retainer relationship and can activate a team quickly. It is harder when you are in a break-glass situation and the team will not arrive for several hours. In that gap, the guidance is: isolate rather than destroy. Disconnect rather than reimage. Export logs rather than delete them. Document everything rather than assume it will be remembered.

When the DFIR team arrives, provide them with a complete account of every action taken on every affected system since the incident was detected. If a system was powered off, say so, and note the time. If logs were exported, provide the export. If antivirus was run, provide the scan report and note when it ran. This information allows the investigator to calibrate their findings against what evidence was available and what was altered. Honest documentation of what happened is significantly more useful than an incomplete account that hides actions taken out of embarrassment.

We work with organisations to establish evidence preservation procedures before incidents occur and to conduct forensic evidence collection that maintains integrity from the first action through to the final report. Contact us at info@cyberlinx.com.au to discuss your evidence handling procedures.