A help desk technician sees an EDR alert for a malicious script on a laptop and does what feels responsible: holds the power button until the screen goes dark. The malware had been running only in memory, so its process, its network connections and any keys it held vanished in seconds. The disk survived, but the most valuable evidence did not, and nothing anyone does later can bring it back.
On the CompTIA Security+ SY0-801 exam this sits under objective 4.8, which expects you to choose and protect the evidence an investigation depends on. This lesson covers file and log integrity and the three kinds of system image the objective names: memory dumps, bit-level copies and snapshots. It shows how each is captured and how hashing proves none of them changed. Chain of custody and the incident response phases are covered in the incident response section.
Evidence only counts if you can prove it hasn't changed
An investigation's findings are only as strong as the evidence under them. If a lawyer, an auditor or your own manager can ask "how do you know this file is what was on the laptop?" and you have no answer, the finding is an opinion. Integrity is the answer, and it comes from three habits.
First, hash evidence the moment you collect it. A SHA-256 hash is a fingerprint: change one bit of a 500 GB image and the hash changes completely. Recording the hash at acquisition lets anyone recompute it later and show the evidence is identical. Forensic tools often record MD5 or SHA-1 alongside SHA-256 for compatibility with older tools, but both are broken for collision resistance, so SHA-256 is the value to rely on.
Second, never work on the original. You image the source, seal the master copy and analyze a verified working copy. If analysis goes wrong, you make another copy from the master.
Third, protect evidence that is still being created. Logs are evidence before anyone knows there is an incident, and an attacker with administrator rights can edit or erase them. Log integrity has to be designed in advance.
Log integrity depends on getting a copy off the host before an attacker can reach it
A log that lives only on the compromised machine is controlled by whoever controls that machine. The main defense is centralized forwarding: every system sends its events, as they happen, to a collector or SIEM the attacker doesn't control. Linux systems forward syslog, ideally over TLS on port 6514; Windows systems use Windows Event Forwarding or a SIEM agent. A typical rsyslog forwarding rule:
# /etc/rsyslog.d/60-forward.conf: send every message to the central collector over TLS
global(DefaultNetstreamDriverCAFile="/etc/ssl/certs/corp-ca.pem")
*.* action(type="omfwd" target="logs.corp.example.com" port="6514" protocol="tcp"
StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="logs.corp.example.com")
Once a copy has left the host, clearing the local log no longer erases the record. The clearing itself becomes an alert, such as Windows event 1102.
The central store needs protecting too. Write-once storage, often called WORM (write once, read many), accepts new data but refuses edits and deletions until a retention period ends. Cloud object storage offers this as an object lock; in compliance mode not even the account's root user can shorten the retention. Some logging systems go further and chain entries with hashes or seal them cryptographically, so removing or editing one entry breaks verification. systemd's journal can do this with Forward Secure Sealing, checked with journalctl --verify. Access separation matters as much as technology: the administrators of the servers shouldn't also be able to delete the SIEM's data. And every source needs synchronized time from NTP (port 123), or the timeline built from these logs won't line up.
When you export logs as evidence, hash the export and record the value:
$ sha256sum fw01-2026-10-14.log | tee fw01-2026-10-14.log.sha256
5d41a9c2...e07b fw01-2026-10-14.log
$ sha256sum -c fw01-2026-10-14.log.sha256
fw01-2026-10-14.log: OK
File integrity monitoring adds a related protection on hosts: it hashes critical files, including logging configuration, and alerts when they change.