Memory Forensics mit Volatility 3: Dumps im Reproduzierbaren Lab Analysieren

Speicherforensik ist die Disziplin, aus einem RAM-Abbild die fluechtige Wahrheit eines kompromittierten Systems zu rekonstruieren: laufende Prozesse, offene Sockets, entschluesselte Payloads und injizierten Code, der auf der Platte nie erscheint. Volatility 3 ist das quelloffene Standardwerkzeug dafuer, komplett in Python 3 neu geschrieben, mit Symboltabellen statt starrer Profile. Bei Basilisk analysieren wir jeden Dump in einem reproduzierbaren Labor, damit ein Ergebnis vor Gericht und im Peer-Review Bestand hat. Dieser Leitfaden fuehrt vom Erwerb des Abbilds ueber die Kern-Plugins bis zur Erkennung von Prozessinjektion, mit Befehlen, die du direkt nachvollziehen kannst.

Warum fluechtiger Speicher zaehlt

Fast jede moderne Malware existiert irgendwann nur im RAM: dateilose Loader, in explorer.exe injizierte Beacons, mit LUKS oder BitLocker verschluesselte Volumes, deren Schluessel im Speicher liegen. Wer nur die Platte forensisch untersucht, verliert Prozessbaum, Netzwerkverbindungen zum C2, Zwischenablage, entschluesselte Strings und Reste geloeschter Prozesse. Die Reihenfolge der Fluechtigkeit nach RFC 3227 ist eindeutig: CPU-Register und Cache zuerst, dann RAM, dann Swap, erst danach die Platte. Deshalb ist die erste Handlung bei einem Live-Vorfall haeufig das saubere Abbilden des Speichers, bevor irgendjemand das System herunterfaehrt oder aufraeumt.

Das Speicherabbild erwerben

Der Erwerb muss die Integritaet wahren: minimaler Fussabdruck, sofortiges Hashing, dokumentierte Chain of Custody. Unter Windows nutzen wir WinPmem oder Magnet RAM Capture, unter Linux AVML oder LiME als Kernelmodul, in virtualisierten Umgebungen den nativen Snapshot des Hypervisors, der oft der sauberste Weg ist. Direkt nach dem Dump berechnen wir sha256sum abbild.raw und notieren den Wert im Fallprotokoll. Ein Abbild ohne Hash und ohne Zeitstempel ist forensisch wertlos. Fuer Windows-Analysen ist zusaetzlich die passende pagefile.sys wertvoll, weil ausgelagerte Seiten sonst als Luecken erscheinen.

Ein reproduzierbares Labor aufbauen

Reproduzierbarkeit ist der Kern serioser Forensik. Wir arbeiten in einem Docker-Container oder einer Python-venv mit gepinnter Volatility-3-Version, gehashten Symbol-Packs und dem Abbild als read-only gemountetem Volume. Jede Analyse startet mit derselben requirements.txt, damit ein Kollege exakt dasselbe Ergebnis erzeugt. Das Original-Abbild bleibt unberuehrt; alle Arbeit laeuft auf einer verifizierten Kopie, deren Hash mit dem Original uebereinstimmt. Wir protokollieren jeden ausgefuehrten Befehl mit Zeitstempel in einem Fall-Runbook, damit die gesamte Analysekette spaeter Schritt fuer Schritt nachvollziehbar ist.

Volatility 3 und Symboltabellen

Volatility 3 verabschiedet sich von den starren Profilen der Version 2 und nutzt stattdessen Intermediate Symbol Files (ISF), die aus Debug-Symbolen des Kernels erzeugt werden. Fuer Windows laedt das Framework Symbole automatisch aus dem Microsoft-Symbolserver anhand des GUID des Kernels; fuer Linux und macOS erzeugst du das ISF aus dem passenden System.map und den Kernel-Headern mit dwarf2json. Der erste Lauf ist immer vol -f abbild.raw windows.info, um Betriebssystemversion, Kernel-Basis und Zeitzone zu bestaetigen. Stimmt das Symbolpaket nicht, liefern alle folgenden Plugins Muell, weshalb dieser Schritt nicht uebersprungen wird.

Prozesse analysieren: pslist, psscan, pstree

Das Herz der Analyse ist der Prozesskontext. windows.pslist laeuft die doppelt verkettete Liste der aktiven Prozesse ab, wie sie der Kernel fuehrt. windows.psscan dagegen durchsucht den Speicher nach _EPROCESS-Signaturen und findet dadurch auch abgemeldete oder per DKOM versteckte Prozesse, die aus der verketteten Liste entfernt wurden. Die Differenz zwischen beiden Ausgaben ist ein klassisches Rootkit-Indiz. windows.pstree zeigt die Eltern-Kind-Hierarchie, in der Anomalien sofort auffallen: eine cmd.exe unter winword.exe, ein powershell.exe unter outlook.exe oder ein lsass.exe mit falschem Elternprozess sind Alarmzeichen.

Netzwerk und Handles

Nach den Prozessen folgen die Verbindungen. windows.netscan rekonstruiert TCP- und UDP-Endpunkte samt Ziel-IP, Port, Zustand und besitzendem Prozess und deckt so aktive C2-Kanaele auf, selbst wenn die Verbindung nur kurz bestand. windows.handles listet die offenen Handles eines Prozesses auf Dateien, Registry-Schluessel, Mutexe und Named Pipes; ein verdaechtiger Mutex ist oft die Signatur einer bekannten Malware-Familie. windows.dlllist und windows.ldrmodules vergleichen die geladenen Module: eine DLL, die in der Speicherabbildung liegt, aber in keiner der drei Ladelisten steht, deutet stark auf reflektives DLL-Laden hin.

Injektion und Hollowing erkennen

Das wichtigste Plugin fuer aktive Bedrohungen ist windows.malfind. Es sucht Speicherregionen mit der Kombination aus PAGE_EXECUTE_READWRITE-Schutz, fehlendem Datei-Mapping und ausfuehrbaren Bytes am Anfang, was das klassische Muster von Shellcode-Injektion und Process Hollowing ist. Die Ausgabe zeigt einen Hex-Dump; ein MZ-Header oder die typische 4D 5A-Signatur in einer RWX-Region bestaetigt eine injizierte PE. Ergaenzend faengt windows.hollowprocesses den Fall, in dem ein legitimer Prozess gestartet und sein Speicher durch fremden Code ersetzt wurde. Jeder Fund wird mit windows.vadinfo gegengeprueft, um die betroffene VAD-Region exakt zu benennen.

Artefakte extrahieren

Sobald ein verdaechtiger Prozess feststeht, extrahieren wir Beweise. windows.memmap --pid N --dump speichert den kompletten adressierbaren Speicher des Prozesses; windows.dumpfiles --pid N rekonstruiert gecachte Dateien aus dem Speicher. Die injizierte Region aus malfind laesst sich isolieren und in eine Sandbox oder zu einem Disassembler wie Ghidra weiterreichen. Registry-Hives holen wir mit windows.registry.hivelist und windows.registry.printkey, um Persistenzschluessel unter Run und Services zu pruefen. Jede extrahierte Datei wird sofort gehasht und im Fall-Runbook mit dem Ursprungs-PID verknuepft.

Haeufige Fallstricke

Der erste Fallstrick ist das falsche Symbolpaket, das plausibel aussehende, aber voellig falsche Ergebnisse liefert. Der zweite ist das Ignorieren der Differenz zwischen pslist und psscan, wodurch versteckte Prozesse unentdeckt bleiben. Der dritte ist das Arbeiten am Original statt an einer gehashten Kopie, was die Beweiskette zerstoert. Der vierte ist das Vertrauen auf einen einzelnen Indikator: ein RWX-Segment allein ist nicht zwingend boesartig, weil auch JIT-Compiler solche Regionen anlegen. Der fuenfte ist das Vergessen der pagefile.sys, wodurch ausgelagerte Beweise fehlen und die Analyse luecken zeigt.

Checkliste

Abbild mit minimalem Fussabdruck erwerben und sofort per SHA-256 hashen. In reproduzierbarem Labor an einer read-only Kopie arbeiten. Mit windows.info die OS-Version und das richtige Symbolpaket bestaetigen. Prozesse mit pslist, psscan und pstree triagieren und die Differenzen notieren. Netzwerk mit netscan, Module mit dlllist und ldrmodules pruefen. Injektion mit malfind und hollowprocesses suchen. Verdaechtige Regionen mit memmap und dumpfiles extrahieren, hashen und im Runbook dokumentieren. Jeden Befund mit mindestens zwei unabhaengigen Indikatoren belegen.

Zeitleiste und Korrelation

Ein einzelnes Plugin liefert eine Momentaufnahme; die Geschichte des Vorfalls entsteht erst aus der Korrelation mehrerer Quellen entlang einer Zeitachse. windows.pstree mit Erstellungszeitstempeln, kombiniert mit netscan-Verbindungszeiten und den Zeitstempeln aus windows.registry.userassist, ergibt eine belastbare Abfolge: wann der Loader startete, wann der C2-Kanal aufging, wann Persistenz gesetzt wurde. Wir exportieren diese Artefakte und fuehren sie in einem Super-Timeline-Werkzeug wie Plaso zusammen, damit Disk- und Speicher-Ereignisse in einer einzigen chronologischen Sicht liegen. Erst dann laesst sich Ursache von Wirkung trennen und der Patient Zero benennen. Wichtig ist der Abgleich der Zeitzone: windows.info liefert den Bias, und jeder Zeitstempel wird konsequent in UTC normalisiert, sonst entsteht eine scheinbare Kausalitaet, die es nie gab. Eine saubere Timeline ist das Rueckgrat des Abschlussberichts und das, was ein Gutachter zuerst prueft.

Linux- und macOS-Speicher

Windows dominiert die Beispiele, aber Volatility 3 analysiert auch Linux- und macOS-Abbilder, sofern das passende ISF vorliegt. Fuer Linux erzeugst du es mit dwarf2json aus dem kernelspezifischen System.map und den Debug-Symbolen des exakt laufenden Kernels, denn schon ein Patch-Level Unterschied bricht die Struktur. Die Plugin-Namen spiegeln die Windows-Logik: linux.pslist und linux.pstree fuer Prozesse, linux.bash extrahiert die Kommandohistorie direkt aus dem Speicher der Shell, linux.check_syscall und linux.check_modules suchen nach Kernel-Rootkits, die die Syscall-Tabelle umgebogen haben. Fuer Container ist relevant, dass ein einziger Host-Dump alle Namespaces enthaelt; Prozesse verschiedener Container erscheinen nebeneinander und werden ueber ihre cgroup-Zugehoerigkeit getrennt. macOS verlangt ein aus der passenden KDK erzeugtes Symbolpaket. Das Prinzip bleibt identisch: verifizierte Symbole zuerst, dann systematische Triaged, dann belegte Extraktion.

Automatisierung mit vol -r und YARA-Regeln

Wiederholbare Analyse verlangt maschinenlesbare Ausgaben. Volatility 3 unterstuetzt mit vol -r json oder -r csv strukturierte Renderer, deren Ergebnisse sich in ein Notebook oder ein SIEM einspeisen lassen, statt Terminaltext von Hand zu lesen. Auf dieser Basis bauen wir ein Skript, das nach dem Erwerb automatisch die Kern-Plugins ausfuehrt, die Differenz zwischen pslist und psscan berechnet, jede RWX-Region aus malfind extrahiert und sofort einen YARA-Scan mit kuratierten Regeln fuer bekannte Beacon-Familien darueber laufen laesst. Ein Treffer hebt den Fall automatisch auf eine hoehere Prioritaet und benachrichtigt den zustaendigen Analysten. So wird aus der manuellen Triaged ein reproduzierbarer Pipeline-Schritt, dessen Zwischenergebnisse gehasht und archiviert werden, damit jeder spaetere Reviewer exakt denselben Weg von Rohabbild zu Befund nachvollziehen kann, ohne der urspruenglichen Analystin blind vertrauen zu muessen.

FAQ: Kann ich einen Speicherdump ohne exaktes Betriebssystem-Profil analysieren?

Bei Volatility 3 gibt es keine manuell gewaehlten Profile mehr; das Framework leitet die Struktur aus den Symboltabellen ab. Fuer Windows geschieht das automatisch ueber den Kernel-GUID und den Microsoft-Symbolserver. Fuer Linux musst du das passende ISF selbst aus System.map und Kernel-Debug-Symbolen mit dwarf2json erzeugen, sonst schlagen die Plugins fehl.

FAQ: Was, wenn malfind nichts findet, obwohl der Verdacht bleibt?

malfind ist stark, aber nicht allwissend: fortgeschrittene Malware kann RWX-Regionen vermeiden, Speicher als Bild mappen oder Code erst zur Laufzeit dekomprimieren. Ergaenze die Analyse dann mit ldrmodules fuer unverlinkte DLLs, netscan fuer C2-Spuren und einem YARA-Scan ueber das gesamte Abbild mit windows.vadyarascan, um bekannte Signaturen zu treffen.

Fazit

Praktisches Takeaway: baue heute ein reproduzierbares Labor, erwirb ein Abbild einer Test-VM mit einem bekannten Beacon und laufe die komplette Kette von windows.info bis malfind durch, bis du den injizierten Code selbst siehst. Speicherforensik ist keine Magie, sondern methodische Arbeit: sauberer Erwerb, verifizierte Symbole, systematische Prozess-Triaged, mehrfach belegte Indikatoren und eine luckenlose Beweiskette. Wer jeden Schritt hasht und protokolliert, liefert Ergebnisse, die im Incident-Response-Report wie im Gerichtssaal standhalten. Wiederhole die Uebung mit verschiedenen Injektionstechniken, bis das Muster im Hex-Dump sofort ins Auge springt.