Don’t Destroy Evidence – Handle Data and Systems Carefully During Incident Response

Questions to Antonia

Based on your thousands of hours in incident response work, what would be a Red Flag for you? 

There’s one red flag that stands out to me: When breached organizations see forensic investigations as optional rather than essential. All too often, our Incident Response engagements begin with the Customer (proudly) describing the massive effort they have invested into rebuilding their environment. However, when asked whether forensic investigations have been initiated, or digital evidence has been preserved, the room suddenly goes silent. If Forensic investigations are an afterthought – or worse, not even considered – in your Incident Response, there’s a high chance the threat actor is still lurking in your environment or will visit again. If you don’t know how many doors your house has, how should you know which ones to lock? Forensic investigations are not a luxury – they’re a necessity.   

Why is “restarting and rebooting” a bad idea during an incident? 

I understand that the instinct to press the restart button when your devices start acting funnily is high. However, restarting devices during incidents can have serious consequences for the analysis and recovery process. Rebooting can permanently destroy critical volatile data stored in memory or even log files with limited retention span. Forensic artifacts from memory can include for example, currently active processes, their network connections and loaded DLLs, and traces of fileless malware executions. 

This data can contain invaluable clues that help us understand how and when the breach occurred, what methods were used, and what steps are necessary to fully evict the threat actor. Once a device is restarted, this information – and thereby highly valuable evidence – is lost forever and cannot be recovered. 

Another consideration is that a restart can even act as a trigger for additional malicious execution. For example, certain persistence mechanisms – such as run keys or scheduled tasks – might only execute after a restart, potentially initiating ransomware encryption or (re-)establishing a communication channel to the attacker’s C2 server. 

So, in short: by restarting devices, you cut off vital visibility and control. Unless specifically instructed by your Incident Response team, avoid rebooting at all costs. Always consult them first and ensure that all crucial evidence has been collected and preserved as well as that no persistence or execution is triggered through a reboot to prevent additional impact. If you want to contain the attack, isolate the device from the network and leave it otherwise untouched. 

Why is “Delete all encrypted VMs” a bad idea during an incident? 

Yet again, that approach strongly interferes with the Fundamental principle of forensic investigations: Don’t meddle with the evidence but preserve it. Deleting encrypted VMs means wiping out crucial forensic evidence, such as event logs, registry changes, and network connection records, that could help us forensic investigators understand how the threat actor gained access and moved through your environment. Even if the encrypted data itself can’t be fully recovered, fragments may remain unencrypted or partially decryptable, offering valuable insights into the attack chain and the threat actor’s activities. Any small piece of evidence can help solving the big puzzle how and when the threat actor came in and how to keep them out successfully.  

It is also important to remember that deleting those virtual machines is neither assisting the forensic investigation nor the recovery work. Once deleted, you lose the ability to restore the machine from a previous secure snapshot or backup, erasing all traceability and hindering your ability to learn from the incident. The best course of action is to isolate affected machines from the network and preserve their data for forensic analysis—never delete them in the initial stages.  

Are there any exceptions to this Red Flag? 

While destroying forensic evidence is never recommended, every incident is unique regarding its attack path and business impact and requires a tailored response. Therefore, to every rule can be an exception – but don’t assume that you’re it. In the case that your Incident Response team has collected and preserved all evidence, finalized the investigation and your organization is running critically low on storage, it may be appropriate to discuss deleting encrypted Virtual Machines during the recovery process. However, deleting Virtual Machines is NEVER a good idea during initial containment or analysis but only an option once the forensic analysis is concluded.