TrueNAS Snapshots as a Forensic Tool After Ransomware

When ransomware hits a Windows domain, two clocks start ticking at once during the first few hours: management’s business continuity countdown and the attacker’s quiet exfiltration window. In this phase many NAS systems suffer from the same critical mistake: the most recent clean snapshot is rolled back, the filesystem is saved — and the entire forensic context is erased. Anyone running TrueNAS on ZFS instead has a tool that serves as both restore target and forensic archive at the same time. This article shows how to use ZFS snapshots in the incident response process so that recovery and evidence preservation stop working against each other.

The core idea is simple: A ZFS snapshot is read-only, and crypto malware cannot modify it without root access on the NAS itself. Multiple snapshots taken before and after the incident together form a timeline. zfs diff turns that timeline into a chronologically ordered list of every single file operation — including renames, which most ransomware families leave behind like a signature.

Why the Classic Restore Destroys the Forensics

In many SMB environments the emergency plan looks like this: isolate the domain controller, unplug the affected file shares, find the last working snapshot, zfs rollback — accounting can work again. From an IT perspective that is efficient, but from a legal and insurance perspective it is negligent. A cyber insurer regularly requires a forensic report that answers: When did the attacker enter the network, which accounts were taken over, which data was exfiltrated, were persistence mechanisms deployed. Once the file shares are rolled back, the timestamps of first encryption, the original ransom notes and the sequence of affected directories are gone.

The more elegant path: before any rollback, take a fresh snapshot of the compromised state (zfs snapshot pool/dataset@forensic-2026-08-04), protect it as an evidence marker, and only then clone the clean pre-incident snapshot into a new dataset. That keeps the incident state accessible for weeks without blocking production.

ZFS Snapshot Architecture for the Emergency

For snapshots to carry any forensic value in an emergency, the snapshot policy has to be right beforehand. In our customer projects we typically see the following as a minimum tiering:

Tier	Interval	Retention	Purpose
Short-term	every 15 min	24 h	Rollback on user error
Working day	hourly	7 days	Fine-grained incident timeline
Week	daily	4 weeks	Detection of latent attacks
Long-term	weekly	12 months	Compliance and data recovery
Air-gapped replica	daily	90 days	Immutable second site

The last point is decisive: replication to a second TrueNAS SCALE 25.10 system, ideally with zfs send | ssh remote zfs recv -x readonly=off followed by zfs set readonly=on on the target, prevents an attacker with administrative rights on the source NAS from also destroying the history. We cover the hardening of that setup individually in our TrueNAS consulting projects.

Reconstructing the Attacker Timeline with zfs diff

The actual forensic tool is zfs diff. It compares two snapshots and lists every changed, added, deleted or renamed file with a marker. In practice, the first call after an incident looks like this:

# Narrow down the suspicious time window
zfs list -t snapshot -o name,creation -r tank/fileserver

# Before/after diff on a dataset
zfs diff tank/fileserver@auto-2026-08-03_18-00 \
         tank/fileserver@auto-2026-08-04_07-15 \
   | tee /mnt/evidence/diff_fileserver_first_hour.log

# Extract only renames -- typical ransomware pattern
grep '^R' /mnt/evidence/diff_fileserver_first_hour.log \
   | awk '{print $2" -> "$3}' | head -50

Output lines start with M (modified), + (created), - (removed) or R (renamed). Ransomware families of 2025 and 2026 almost all follow the pattern “read original, encrypt, write to new file, rename or delete original”. The R lines therefore consistently show the exact moment and sequence of first encryption — often starting in an obscure share path that hints at the compromised user account.

Identifying Patient Zero and Tracing Lateral Movement

Once you have the first 50 to 100 renamed files, sort them by modification time on the original snapshot. Access works directly through the hidden .zfs path:

ls -laR /mnt/tank/fileserver/.zfs/snapshot/auto-2026-08-03_18-00/ \
   | grep -f <(grep '^R' diff_fileserver_first_hour.log \
                  | awk '{print $2}' | xargs -n1 basename)

The earliest timestamps lead you to patient zero — the file that was touched first. The file path gives you the share, the share gives you the authorized user group, and combined with the SMB audit log of the respective TrueNAS dataset (smbstatus or the TrueNAS auditing feature introduced in 24.10 “Electric Eel”) you can reconstruct the client hostname and often the domain user whose session the attacker hijacked.

For lateral movement, repeat zfs diff across further datasets and write the timestamps of first encryption into a table. The pattern is usually clear: SMB share A at 07:12, share B at 07:18, share C at 07:24 — from that you derive the sequence of hijacked accounts and often a service account acting as a jump host.

Chain of Custody — Preserving Evidentiary Value

For the collected artifacts to hold up in front of an insurer or in court, you need a traceable chain of custody. Four points that TrueNAS can cover with on-board tools:

1. Freeze the snapshot: zfs hold forensic pool/dataset@forensic-2026-08-04 prevents accidental deletion by auto snapshot retention.
2. Create a hash baseline: find /mnt/pool/dataset/.zfs/snapshot/forensic-2026-08-04 -type f -exec sha256sum {} \; > /mnt/evidence/hashes.sha256 — the hash tree is signed and stored off the NAS.
3. Read-only clone for analysts: zfs clone pool/dataset@forensic-2026-08-04 pool/forensic-work followed by zfs set readonly=on. Analysts work on the clone, not on the snapshot.
4. Documentation: Every action (who, when, which command, which result) into a log that is also signed and stored off the NAS.

If those four steps are completed within the first hour after detection, you have preserved a forensic state that can still be re-analyzed three months later — without delaying the production restart any longer than necessary.

Finding a Clean Restart Point — Do Not Guess

The final block is the actual restore. Instead of blindly betting on “the last working snapshot”, determine the restart point in a data-driven way. Principle: the youngest snapshot whose zfs diff against the forensic snapshot shows no ransomware-typical renames is your candidate. Combine that with a look at the ratio of R lines / M lines — a sudden jump often marks the start of encryption down to the minute.

For the recovery itself we recommend mounting the clean dataset as a clone (zfs clone) in parallel to the compromised dataset, moving the critical shares over and keeping the compromised state accessible for a few weeks for follow-up analysis. A well orchestrated backup concept with replication to a second system makes that switch possible within minutes.

DATAZONE Supports You in an Emergency

A ransomware incident is not the moment to use TrueNAS snapshots productively for the first time. We help you build the snapshot policy, the replication to a second site and the incident response playbooks beforehand — and in an emergency we support you by phone or on site with evidence preservation and a clean restart. Reach out via our contact form or call us directly in Neuburg; we take care of customers throughout southern Germany.