How to Preserve Evidence Before Patching a Server

To preserve evidence before patching an exploited server, collect the vendor's own diagnostic data, capture a disk or VM snapshot, copy logs off the host and record what you collected, all before you run the update. Patches often overwrite the very files that show how an attacker got in. The vendor of SiteGuard Server Edition said this explicitly when it disclosed the exploited SiteGuard CVE-2026-106931 in October 2026.

Why does patching destroy evidence?

Patching replaces program files, rotates or truncates logs and restarts services, which wipes the in-memory state and file timestamps an investigator needs. If the flaw lives in a component that processes attacker input, the files that held that input may be the ones the patch replaces.

EG Secure Solutions told SiteGuard customers to download the product's diagnostic information before updating because the update could erase attack traces. JPCERT/CC repeated that advice in its alert.

When should you preserve evidence first?

Preserve evidence first whenever a vulnerability is confirmed exploited in the wild and your server was exposed during the exploitation window. In that situation you are no longer only patching; you are also responding to a possible incident.

A good trigger list:

• The vendor or a CERT says the flaw is exploited.
• CISA lists it in KEV, especially with a forensic triage flag under BOD 26-04.
• The vulnerable component was reachable while exploitation was happening.
• You notice anything odd on the host: new accounts, unknown processes, unfamiliar files.

If none of these apply, patch normally. Evidence collection takes time, and time matters when a fix is available.

How to preserve evidence before patching

Work in this order. It moves from the most volatile data to the least, and from the cheapest step to the most expensive.

1. Write down the start time and who is doing the work. Every later step refers back to this.
2. Collect the vendor's diagnostic package. Many products have a built-in export for support cases. For SiteGuard Server Edition it is in the web management screen under Diagnostic information, Download diagnostic information. Vendors design these exports to include their own logs and state, which generic tools may miss.
3. Capture memory if you have the tooling and skills. Running processes, network connections and injected code exist only in memory. If you do not have a tested memory acquisition tool, skip this rather than improvising on a production server.
4. Snapshot the VM or image the disk. On a virtual server, a hypervisor snapshot is fast and does not touch the guest. Keep the snapshot until the investigation is closed.
5. Copy logs to another system. Web server access and error logs, the security product's own logs, system authentication logs and any scheduler logs. Copy them to storage the compromised host cannot write to.
6. Record hashes and a short inventory. For each file or image you saved, note its location, size, hash and the time you collected it. That record is your chain of custody.
7. Then patch. Apply the update or vendor patch and confirm the version afterwards.

What should you look for afterwards?

Review the saved data for activity during the exposure window: new local accounts, changed scheduled tasks, unfamiliar files in web roots or temp directories, and outbound connections from the server. Compare file listings in the snapshot with a clean build of the same version if you have one.

If you find signs of compromise, the patch is not the fix. Plan a rebuild and rotate every credential the host held. Our explainer on why to rebuild before you rotate credentials after a breach covers the sequencing, and what a web shell is and how it gets on a server describes one of the most common leftovers.

How long can evidence collection delay the patch?

Keep it short. For a single server, the vendor export, a snapshot and a log copy take minutes, not hours. Decide in advance which steps are mandatory and which are optional so the on-call engineer is not making that judgment under pressure.

If the server cannot be snapshotted and collection will take hours, reduce exposure while you work: block the vulnerable feature, restrict access or take the host out of the load balancer. For SiteGuard, JPCERT/CC lists disabling the statistics feature as a workaround.

Make it a standing procedure

Write the steps above into your patch runbook as a branch for exploited vulnerabilities. Note, per product, where the vendor's diagnostic export lives; you do not want to look for it during an incident. Products that run inside the web server, such as a host-based WAF, deserve a line of their own because they process every request and often run with root or SYSTEM privileges.