TrueNAS-Snapshots als Forensik-Werkzeug nach Ransomware

Wenn ein Ransomware-Angriff eine Windows-Domäne trifft, laufen in den ersten Stunden zwei Uhren gleichzeitig: Der Business Continuity Countdown der Geschäftsführung und die stille Verwertungsfrist der Angreifer. In dieser Phase wird auf vielen NAS-Systemen ein folgenschwerer Fehler gemacht: Der jüngste saubere Snapshot wird zurückgerollt, das Dateisystem ist gerettet — und der komplette forensische Kontext ist gelöscht. Wer stattdessen mit einem TrueNAS-System und ZFS arbeitet, hat ein Werkzeug in der Hand, das gleichzeitig Restore-Ziel und Forensik-Archiv ist. Dieser Artikel zeigt, wie Sie ZFS-Snapshots im Incident-Response-Prozess so nutzen, dass Recovery und Beweissicherung nicht mehr in Konflikt stehen.

Der Kern der Idee ist einfach: Ein ZFS-Snapshot ist read-only, ein Kryptotrojaner kann ihn ohne Root-Rechte auf dem NAS nicht verändern. Mehrere Snapshots vor und nach dem Vorfall bilden gemeinsam eine Timeline. zfs diff macht aus dieser Timeline eine chronologisch geordnete Liste jeder einzelnen Dateioperation — inklusive Umbenennungen, die Ransomware-Familien wie eine Signatur hinterlassen.

Warum der klassische Restore die Forensik zerstört

In vielen SMB-Umgebungen läuft der Notfallplan wie folgt ab: Domain-Controller isolieren, betroffene Fileshares vom Netz nehmen, letzten funktionierenden Snapshot suchen, zfs rollback — Rechnungswesen kann arbeiten. Aus IT-Sicht ist das effizient, aus juristischer und versicherungstechnischer Sicht ist es fahrlässig. Ein Cyber-Versicherer verlangt regelmäßig einen forensischen Bericht, der zeigt: Wann kam der Angreifer ins Netz, welche Konten wurden übernommen, welche Daten wurden exfiltriert, gab es Persistenzmechanismen. Sind die Fileshares zurückgerollt, fehlen die Zeitstempel der Erstverschlüsselung, die Ransom-Notes im Original und die Reihenfolge der befallenen Verzeichnisse.

Der elegantere Weg: Vor dem Rollback einen frischen Snapshot des kompromittierten Zustands erzeugen (zfs snapshot pool/dataset@forensik-2026-08-04), diesen als evidence marker sichern, und erst dann den sauberen Vor-Snapshot in ein neues Dataset klonen. So bleibt der Vorfallszustand für Wochen zugriffsbereit, ohne die Produktion zu blockieren.

ZFS-Snapshot-Architektur für den Ernstfall

Damit Snapshots im Ernstfall überhaupt einen forensischen Wert haben, muss die Snapshot-Policy vorher stimmen. In unseren Kundenprojekten sehen wir typischerweise folgende Staffelung als Minimum:

Ebene	Intervall	Retention	Zweck
Kurzzeit	alle 15 min	24 h	Rollback bei Anwenderfehler
Arbeitstag	stündlich	7 Tage	Feingranulare Timeline im Incident
Woche	täglich	4 Wochen	Erkennung latent laufender Angriffe
Langzeit	wöchentlich	12 Monate	Compliance und Datenwiederherstellung
Air-gapped Replika	täglich	90 Tage	Immutable Zweitstandort

Entscheidend ist der letzte Punkt: Die Replika auf ein zweites TrueNAS SCALE 25.10 System, idealerweise mit zfs send | ssh remote zfs recv -x readonly=off und anschließendem zfs set readonly=on auf dem Ziel, verhindert, dass ein Angreifer mit administrativen Rechten auf dem Quell-NAS auch die Historie zerstört. Details zur Härtung dieses Setups besprechen wir in unseren TrueNAS-Beratungsprojekten individuell.

Mit zfs diff die Angreifer-Timeline rekonstruieren

Das eigentliche Forensik-Werkzeug ist zfs diff. Es vergleicht zwei Snapshots und listet jede geänderte, hinzugefügte, gelöschte oder umbenannte Datei mit einem Marker. In der Praxis sieht der erste Aufruf nach einem Vorfall so aus:

# Verdächtiges Zeitfenster eingrenzen
zfs list -t snapshot -o name,creation -r tank/fileserver

# Vorher/Nachher-Diff auf ein 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

# Nur Umbenennungen extrahieren -- typisches Ransomware-Muster
grep '^R' /mnt/evidence/diff_fileserver_first_hour.log \
   | awk '{print $2" -> "$3}' | head -50

Die Ausgabezeilen beginnen mit M (modified), + (created), - (removed) oder R (renamed). Ransomware-Familien der Jahre 2025/26 arbeiten fast alle nach dem Muster “Original lesen, verschlüsseln, in neue Datei schreiben, Original umbenennen oder löschen”. Die R-Zeilen zeigen deshalb regelmäßig genau den Moment und die Reihenfolge der Erstverschlüsselung — häufig beginnend in einem obskuren Freigabepfad, der Rückschlüsse auf das kompromittierte Benutzerkonto zulässt.

Patient Zero identifizieren und Lateral Movement nachzeichnen

Sobald Sie die ersten 50 bis 100 umbenannten Dateien haben, sortieren Sie nach Modification-Time des Original-Snapshots. Der Zugriff funktioniert direkt über den versteckten .zfs-Pfad:

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)

Die frühesten Zeitstempel führen Sie zu Patient Zero — der Datei, die als erste angefasst wurde. Aus dem Dateipfad ergibt sich die Freigabe, aus der Freigabe die berechtigte Benutzergruppe, und mit dem SMB-Audit-Log des jeweiligen TrueNAS-Datasets (smbstatus bzw. der TrueNAS Auditing-Feature seit 24.10 “Electric Eel”) lässt sich der Client-Hostname und damit oft der Domain-User rekonstruieren, dessen Session der Angreifer übernommen hat.

Für die laterale Bewegung wiederholen Sie den zfs diff über weitere Datasets und schreiben die Zeitpunkte der jeweils ersten Verschlüsselung in eine Tabelle. Das Muster ist meistens deutlich: SMB-Freigabe A um 07:12, Freigabe B um 07:18, Freigabe C um 07:24 — daraus ergibt sich die Reihenfolge der übernommenen Konten und häufig ein Servicekonto als Sprungbrett.

Chain of Custody — Beweiswert erhalten

Damit die gesammelten Artefakte vor einem Versicherer oder Gericht Bestand haben, brauchen Sie eine nachvollziehbare Chain of Custody. Vier Punkte, die sich in TrueNAS mit Bordmitteln umsetzen lassen:

1. Snapshot einfrieren: zfs hold forensik pool/dataset@forensik-2026-08-04 verhindert das versehentliche Löschen durch Auto-Snapshot-Retention.
2. Hash-Baseline erzeugen: find /mnt/pool/dataset/.zfs/snapshot/forensik-2026-08-04 -type f -exec sha256sum {} \; > /mnt/evidence/hashes.sha256 — der Hash-Baum wird selbst signiert und außerhalb des NAS abgelegt.
3. Read-only-Klon für Analysten: zfs clone pool/dataset@forensik-2026-08-04 pool/forensik-work mit anschließendem zfs set readonly=on. Analysten arbeiten am Klon, nicht am Snapshot.
4. Dokumentation: Jede Aktion (wer, wann, welcher Befehl, welches Ergebnis) in ein Protokoll, das ebenfalls signiert und außerhalb des NAS gespeichert wird.

Wer diese vier Schritte innerhalb der ersten Stunde nach Erkennung durchführt, hat einen forensischen Zustand konserviert, den man auch drei Monate später noch neu auswerten kann — ohne den Produktions-Wiederanlauf länger als nötig zu verzögern.

Sauberen Wiederanlaufpunkt finden — nicht raten

Der letzte Baustein ist der eigentliche Restore. Statt blind auf “den letzten funktionierenden Snapshot” zu setzen, bestimmen Sie den Wiederanlaufpunkt datengetrieben. Prinzip: Der jüngste Snapshot, dessen zfs diff gegen den forensischen Snapshot keine ransomware-typischen Umbenennungen zeigt, ist Ihr Kandidat. Kombinieren Sie das mit einem Blick auf den Verhältniswert Anzahl R-Zeilen / Anzahl M-Zeilen — ein plötzlicher Sprung markiert den Beginn der Verschlüsselung meist auf die Minute genau.

Für die Recovery selbst empfehlen wir, das saubere Dataset als Klon (zfs clone) parallel zum kompromittierten Dataset zu mounten, die kritischen Freigaben umzuhängen und den kompromittierten Zustand für die Nachanalyse einige Wochen erreichbar zu halten. Ein sauber orchestriertes Backup-Konzept mit Replikation auf ein Zweitsystem macht diesen Schwenk innerhalb weniger Minuten möglich.

DATAZONE unterstützt Sie im Ernstfall

Ein Ransomware-Vorfall ist kein Zeitpunkt, um TrueNAS-Snapshots zum ersten Mal produktiv zu nutzen. Wir helfen Ihnen dabei, die Snapshot-Policy, die Replikation auf einen zweiten Standort und die Incident-Response-Playbooks vorher aufzubauen — und im Ernstfall telefonisch oder vor Ort bei der Beweissicherung und dem sauberen Wiederanlauf zu unterstützen. Sprechen Sie uns an über das Kontaktformular oder rufen Sie direkt in Neuburg an; wir betreuen Kunden im gesamten süddeutschen Raum.