In short: Before you rebuild a compromised server, preserve the evidence in order of volatility: first processes, connections and logged-in users, then logs and configuration, then a complete image of the system and the data of upstream services. Every copy gets a checksum and is stored away from the server. For this, the server is disconnected from the network but not switched off.
The reflex to rebuild immediately
Anyone who discovers a break-in wants to end it as quickly as possible. A fresh system, cleanly installed, with new passwords: that feels like control. Technically, a rebuild is often the right path too, especially if an attacker had root rights.
The problem is the timing. With the old system, all the answers to the questions that come in the following days disappear. Through which vulnerability did the attacker get in? Since when were they in the system? Did they have access to customer data? Is the database server next door affected as well? Without traces only guesses remain, and they help neither with data protection nor with insurance.
After PHP2Shell, one more point applies: there are no published, confirmed indicators of compromise. Whether and how a server was affected can only be read from its behavior, that is, from exactly the traces a hasty rebuild deletes. The trade press advises keeping server logs from 20 October 2026 onward.
Server evidence preservation: the order matters
Traces differ in how volatile they are. What is in memory is gone with the next restart. Logs survive longer but are rotated. Data on upstream services disappears after their own retention periods. This gives the order:
| Trace | Volatility | How to secure |
|---|---|---|
| Processes, network connections, logged-in users | disappears on restart | write the output of system commands to files |
| Memory | disappears on restart | only with special tools, a job for forensic specialists |
Temporary files in /tmp or /dev/shm |
often deleted on restart | copy without executing |
| Logs of web server, PHP, system | are rotated | copy completely, pause rotation |
| File system and database | stable until reinstallation | snapshot or disk image, database export |
| CDN, WAF, firewall, hoster | retention per the provider's periods | request an export, have it confirmed in writing |
Capture memory only if someone with suitable tools and experience is available. For systems with sensitive data or a foreseeable legal dispute, IT forensics should take this over.
Capturing volatile data in a few minutes
The following commands change nothing on the system. They write the current state to files, which are then secured away from the server. If possible, create the target directory on a connected, separate disk:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
How to secure and analyze the logs completely afterwards is described in the guide Analyzing web server logs after an attack. For virtual servers, a snapshot through the provider's management console is the easiest way to a complete image. It captures the system without you having to start further tools on the compromised server.
So that the copy is worth something later
A copy is only as good as its proof. Three rules make it reliable:
- Checksums: Every secured file gets a SHA-256 checksum. This lets you show later that the copy is unchanged.
- Log: Who secured what, when, with which command, to where? Every handover to third parties is recorded. Specialists call this the chain of custody.
- Separate storage: Copies belong on a system the attacker had no access to, and are used further only in read-only mode.
From then on, work only with copies. Any analysis on the original changes timestamps and can overwrite traces. Never run suspicious files and do not open them in the browser.
Request the logs from CDN, WAF and hoster early. This data lies outside your server and is hard for an attacker to manipulate, but it is often kept only briefly.
What destroys the evidence
Many traces are lost not through the attacker but through well-meant first aid. These steps should be avoided before securing evidence:
- Restarting or switching off: Processes, connections and memory are gone afterwards.
- Antivirus with automatic deletion: It removes files before anyone has secured them and changes timestamps.
- Cleaning up logs or temp folders: Even if space is tight, copy first, then delete.
- Installing new tools from the internet on the server: Every installation writes to the file system and can cover traces.
- Logging in with privileged credentials without need: If malicious code is still running on the server, entered passwords can be read along.
Insurers in particular later ask what was secured and when. Notes on typical obligations can be found under Cyber insurance: what counts in a claim.
Weighing up: how much time is there for securing?
Not every incident allows a long preservation. If data is being exfiltrated right now or visitors are being attacked, containment takes priority. Disconnecting from the network while the system keeps running combines both: the attacker loses access, the traces are preserved. For most web servers, a manageable amount of time is then enough for the volatile data and the snapshot.
Make the decision consciously and record it: who decided when to rebuild, and what was secured beforehand? This note later becomes part of the timeline of the incident. Whether a rebuild or a cleanup is the right path is examined in the article Rebuild or clean up the server?.
How does PHP SOS help?
- We secure volatile data, logs and system images in the right order, with checksums and a log.
- We request the data of upstream services before their retention periods expire.
- If needed, we carry out the forensic acquisition and analysis with specialized partners.
- Only then do we rebuild the server, close the entry point and document the incident until it is closed.
Frequently asked questions
Why should I preserve evidence before rebuilding?
Because only the traces show how the attacker got in, how long they were in the system and which data they could reach. You need these answers for data protection, insurance and the question of whether other systems are affected. After the rebuild they are gone.
What is most urgent when securing evidence?
Volatile data such as running processes, network connections and logged-in users disappears on shutdown. It is captured first. Logs, an image of the system and data from upstream services follow.
Is a normal backup enough as evidence preservation?
Usually not. Many backups contain no logs, no system files and no metadata such as timestamps and owners. For evidence preservation you need a complete, unaltered copy with a checksum, ideally a snapshot or a disk image.
May I take the server off the network before securing it?
Yes, as long as it keeps running. Disconnecting from the network stops data leakage and remote control without destroying volatile traces. A restart or shutdown, by contrast, wipes memory and running processes.