Memory Forensics enthüllt, was Festplatten-Forensik nicht sehen kann — den flüchtigen Zustand eines Systems zum Zeitpunkt der Erfassung.
Memory Acquisition & Kernel-Strukturen — den Speicher korrekt sichern
Die Speicherakquisition ist der kritischste Schritt in der Memory-Forensik: Ein fehlerhafter Dump ist wertlos, und der Akquisitionsprozess selbst verändert den Speicher (Heisenberg-Prinzip der Forensik). Die Wahl des richtigen Tools hängt vom Betriebssystem, der Kernel-Version und den aktiven Schutzmechanismen (Secure Boot, VBS, Kernel Patch Protection) ab. Für die Analyse ist ein tiefes Verständnis der Windows-Kernel-Speicherstrukturen unerlässlich — EPROCESS, KTHREAD, PEB und der VAD Tree bilden das Fundament jeder Memory-Analyse.
- WinPmem, DumpIt & Kernel-Mode Acquisition: WinPmem (Teil des Rekall-Projekts) ist ein Kernel-Mode-Treiber, der physischen Speicher über das
\\.\pmem-Device liest. Der Treiber wird als Minifilter geladen und erzeugt ein Raw- oder AFF4-Format-Dump. Limitation: Unter Windows mit VBS (Virtualization-Based Security) ist der Hypervisor-geschützte Speicher (Credential Guard Enclave, HVCI-geschützte Bereiche) nicht im Dump enthalten — der Kernel hat keinen Zugriff auf VBS-isolierten Speicher. DumpIt (Comae Technologies) bietet eine Ein-Klick-Lösung mit minimalem Speicher-Footprint und unterstützt Remote Acquisition über das Netzwerk. Best Practice: Immer zwei Dumps erstellen — einen unmittelbar nach Entdeckung des Incidents, einen nach der initialen Triage — die Differenz zeigt Veränderungen durch den Angreifer in Echtzeit. Hash-Validierung des Dumps mit SHA256 direkt nach der Erstellung. - Linux-Speicherakquisition — AVML & LiME: Auf Linux-Systemen ist die Memory-Akquisition komplizierter, da der Zugriff auf
/dev/memseit Kernel 2.6 eingeschränkt ist (CONFIG_STRICT_DEVMEM). LiME (Linux Memory Extractor) ist ein Kernel-Modul, das als Loadable Kernel Module (LKM) kompiliert und geladen wird — es muss exakt für die laufende Kernel-Version kompiliert werden. Problem: Auf Produktionssystemen sind häufig keine Kernel-Header installiert. AVML (Acquire Volatile Memory for Linux), entwickelt von Microsoft für Azure-Umgebungen, löst dieses Problem: Es ist ein statisch kompiliertes User-Mode-Tool, das über/proc/kcoreoder den Sysfs-Interface den Speicher liest — kein Kernel-Modul erforderlich. AVML unterstützt direkte Kompression (LZ4) und Upload in Azure Blob Storage. Forensische Besonderheit: Linux-Speicher-Dumps erfordern ein DWARF-Symbolprofil (ISF-Datei) für die Analyse mit Volatility 3 — dieses muss für die exakte Kernel-Version erstellt werden (dwarf2json). - EPROCESS & KTHREAD — Kernel-Objektstrukturen verstehen: Jeder Windows-Prozess wird im Kernel durch eine
EPROCESS-Struktur repräsentiert (ca. 1400 Bytes in Windows 11). Kritische Felder:ActiveProcessLinks(doppelt verkettete Liste aller Prozesse — Ziel für DKOM-Rootkits),UniqueProcessId(PID),Token(Security Token mit Berechtigungen),InheritedFromUniqueProcessId(Parent PID),Peb(Pointer auf den Process Environment Block im User-Mode).KTHREADbeschreibt Threads:StartAddress(wo der Thread startet — bei Injection oft in nicht-zugeordneten Speicherbereichen),TrapFrame(gespeicherter CPU-Zustand).PEB(Process Environment Block) enthält: geladene DLLs (Ldr-Listen), Kommandozeile, Umgebungsvariablen. Volatility nutzt diese Strukturen, um Prozesse zu enumerieren, und kann Diskrepanzen zwischen verschiedenen Enumerationsmethoden erkennen — ein Schlüsselindikator für Rootkits. - VAD Tree — Virtual Address Descriptor für Injection-Erkennung: Der VAD (Virtual Address Descriptor) Tree ist eine balancierte Baumstruktur (AVL-Baum) im Kernel, die alle virtuellen Speicherbereiche eines Prozesses beschreibt. Jeder VAD-Knoten enthält:
StartingVpn/EndingVpn(Virtual Page Numbers — Adressbereich),Protection(Speicherschutz: Read/Write/Execute),PrivateMemory/Mapped(privater oder dateigestützter Speicher),FileObject(zugeordnete Datei, falls Memory-Mapped). Für die Forensik entscheidend: Speicherbereiche mitPAGE_EXECUTE_READWRITE-Schutz ohne zugeordnete Datei sind höchst verdächtig — sie deuten auf injizierten Shellcode hin. Legitime Speicherbereiche mit Execute-Berechtigung sind fast immer dateigestützt (DLLs, EXEs). Der Volatility-Pluginvadinfolistet alle VAD-Knoten mit ihren Schutzattributen —malfindfiltert gezielt nach verdächtigen Bereichen und extrahiert den Inhalt für weitere Analyse (z. B. mit YARA-Rules oder Disassembly).
Volatility 3 Deep Dive — vom Plugin zur Erkennung
Volatility 3 ist eine vollständige Neuentwicklung gegenüber Volatility 2 — geschrieben in Python 3 mit einer modularen Plugin-Architektur. Der größte Unterschied: Volatility 3 nutzt Intermediate Symbol Format (ISF) statt vorkompilierter Profile — ISF-Dateien können dynamisch für jede Windows-Build-Version aus den Microsoft Symbol Servern generiert werden. Die Analyse beginnt mit der Identifikation des Betriebssystems (windows.info), gefolgt von der Prozess-Enumeration (windows.pslist, windows.psscan), und endet mit der Analyse spezifischer Artefakte (Netzwerk, Registry, injizierter Code).
- Prozess-Analyse — pslist vs. psscan vs. pstree:
windows.pslistfolgt derActiveProcessLinks-Liste im Kernel — der offiziellen doppelt verketteten Liste aller Prozesse. Ein DKOM-Rootkit (Direct Kernel Object Manipulation) entfernt den Prozess aus dieser Liste —pslistsieht ihn nicht.windows.psscandurchsucht den gesamten physischen Speicher nachEPROCESS-Signaturen (Pool Tags:Proc) — unabhängig von der verketteten Liste. Ein versteckter Prozess erscheint inpsscan, aber nicht inpslist— die Differenz ist ein Rootkit-Indikator.windows.pstreezeigt die Parent-Child-Beziehungen:svchost.exemuss vonservices.exegestartet sein,lsass.exevonwininit.exe— Abweichungen deuten auf Process Spoofing hin. Kommando:vol -f memory.dmp windows.psscan | diff - <(vol -f memory.dmp windows.pslist)zeigt versteckte Prozesse. - malfind — injizierter Code und Shellcode-Erkennung:
windows.malfindist das leistungsstärkste Volatility-Plugin für die Malware-Erkennung. Es durchsucht den VAD Tree jedes Prozesses nach Speicherbereichen mit verdichtigen Attributen:PAGE_EXECUTE_READWRITE-Schutz (beschreibbar und ausführbar — fast immer illegitim), nicht dateigestützt (keinFileObjectim VAD), erkennbare MZ/PE-Header in nicht-zugeordneten Speicherbereichen (injizierte DLLs). Malfind extrahiert die ersten 64 Bytes des verdächtigen Bereichs und zeigt sowohl den Hex-Dump als auch die Disassembly. Fortgeschrittene Analyse: Die extrahierten Speicherbereiche können mit YARA-Rules gescannt werden (windows.vadyarascan) — YARA erkennt bekannte Shellcode-Patterns, Cobalt Strike Beacon-Signaturen und Metasploit-Payloads. Tipp: Nicht jeder malfind-Treffer ist bösartig — JIT-Compiler (Java, .NET) allokieren ebenfalls RWX-Speicher. Die Analyse erfordert Kontext: Welcher Prozess, welche Start-Adresse, welcher Code. - netscan & Registry — Netzwerk- und Konfigurations-Artefakte:
windows.netscanextrahiert aktive und kürzlich geschlossene Netzwerkverbindungen aus Kernel-Strukturen (_TCP_ENDPOINT,_UDP_ENDPOINTimtcpip.sysPool). Jeder Eintrag enthält: lokale/remote IP und Port, Verbindungsstatus (ESTABLISHED, LISTENING, CLOSE_WAIT), PID des zugehörigen Prozesses, Erstellungszeitpunkt der Verbindung. Forensischer Wert: Netzwerkverbindungen sind im RAM auch nach dem Schliessen noch kurzzeitig sichtbar (Pool-Recycling) — der Forensiker kann C2-Verbindungen finden, die zum Zeitpunkt der Akquisition bereits beendet waren.windows.registry.hivelistzeigt alle im Speicher geladenen Registry-Hives,windows.registry.printkeyextrahiert einzelne Schlüssel. Wert: Registry-Daten im RAM enthalten den aktuellen Stand, während die Hive-Dateien auf der Festplatte nur den letzten Flush-Zustand zeigen — Autorun-Einträge und Malware-Konfigurationen sind häufig nur im RAM aktuell. - Timeline-Analyse & YARA-Integration:
timelinerkombiniert Zeitstempel aus verschiedenen Quellen (Prozess-Erstellung, Netzwerkverbindung, Registry-Modifikation, Datei-Zugriff) in eine einheitliche chronologische Zeitleiste. Dies ermöglicht die Rekonstruktion der Angriffskette: 14:32:15 —outlook.exestartetpowershell.exe(Phishing), 14:32:18 — RWX-Speicher inpowershell.exeallokiert (Shellcode), 14:32:20 — Netzwerkverbindung zu185.x.x.x:443(C2), 14:33:01 —lsass.exeZugriff (Credential Dumping). YARA-Integration:windows.vadyarascanscannt den gesamten virtuellen Speicher aller Prozesse mit benutzerdefinierten YARA-Rules. Beispiel: Eine YARA-Rule für Cobalt Strike Beacon erkennt den charakteristischen Speicher-Footprint (Malleable C2 Configuration Block, Sleep Mask). Kommando:vol -f memory.dmp windows.vadyarascan --yara-file cobalt_strike.yar. Für maximale Abdeckung: Kombinieren Sie community YARA-Rules (YARA-Rules-Repository, Elastic Security, Malpedia) mit eigenen, umgebungsspezifischen Regeln.
Anti-Forensik-Erkennung & Rootkit-Detection — die unsichtbaren Spuren finden
Fortgeschrittene Angreifer kennen Memory-Forensik-Techniken und setzen Anti-Forensik-Massnahmen ein: DKOM-Rootkits verstecken Prozesse, Timestomping fälscht Zeitstempel, Log-Clearing entfernt Spuren — aber alle diese Aktionen hinterlassen eigene Artefakte im Speicher. Die Kunst der Memory-Forensik besteht darin, diese Spuren der Spurenverwischung zu finden. Volatility bietet spezialisierte Plugins für die Erkennung von Manipulationen an Kernel-Strukturen, und die Cross-Referenzierung verschiedener Datenquellen deckt Inkonsistenzen auf.
- DKOM-Erkennung — Direct Kernel Object Manipulation aufspüren: DKOM manipuliert Kernel-Datenstrukturen direkt im Speicher, um Prozesse, Treiber oder Netzwerkverbindungen vor dem Betriebssystem zu verstecken. Die klassische Technik: Das
Flink/BlinkderActiveProcessLinksin derEPROCESS-Struktur des versteckten Prozesses wird umgebogen — der vorherige Prozess zeigt auf den nächsten, der versteckte wird übersprungen. Erkennung mit Volatility: pslist vs. psscan-Differenz (wie beschrieben). Zusätzlich:windows.callbackszeigt alle registrierten Kernel-Callbacks (PsSetCreateProcessNotifyRoutine, CmRegisterCallback) — ein Rootkit, das diese Callbacks manipuliert, verhindert, dass neue Prozess-Events an den EDR-Sensor gemeldet werden.windows.ssdtprüft die System Service Descriptor Table — gepatche SSDT-Einträge zeigen auf Code außerhalb vonntoskrnl.exe, ein klassischer Kernel-Rootkit-Indikator. - Process Hollowing & Process Doppelgänging erkennen: Process Hollowing (T1055.012): Der Angreifer startet einen legitimen Prozess (z. B.
svchost.exe) im SUSPENDED-Zustand, entleert dessen Speicher (NtUnmapViewOfSection), schreibt bösartigen Code hinein und setzt die Ausführung fort. Erkennung: Diskrepanz zwischen dem PEB-ImagePathName und dem tatsächlichen Speicherinhalt — der PEB zeigtsvchost.exe, aber der Code im.text-Abschnitt gehört nicht zusvchost.exe. Volatility:windows.malfindzeigt den PE-Header in einem nicht-dateigestützten Speicherbereich. Process Doppelgänging (T1055.013) nutzt NTFS Transactions: Eine temporäre Datei wird in einer NTFS-Transaktion erstellt, der bösartige Code hineingeschrieben, ein Section-Object erzeugt und die Transaktion zurückgerollt — die Datei existiert nie auf der Festplatte, aber das Section-Object im Speicher ist gültig. Erkennung:windows.handleszeigt Section-Objects ohne korrespondierendes File-Object. - Timestomping-Erkennung im Speicher: Timestomping (T1070.006) ändert die
$STANDARD_INFORMATION-Zeitstempel einer Datei (Created, Modified, Accessed), um forensische Zeitleisten zu verfälschen. Im Speicher hinterlässt Timestomping Spuren: Die$FILE_NAME-Attribute im MFT (Master File Table) enthalten unabhängige Zeitstempel, die nicht von Standard-Timestomping-Tools geändert werden — die Diskrepanz zwischen$STANDARD_INFORMATIONund$FILE_NAME-Zeitstempeln ist ein starker Indikator. Volatility-Analyse:windows.mftscanscannt den physischen Speicher nach MFT-Einträgen und extrahiert beide Zeitstempel-Sets. Zusätzlich: USN Journal im Speicher — das NTFS Update Sequence Number Journal protokolliert Dateiänderungen und kann im RAM-Dump gefunden werden, selbst wenn es auf der Festplatte gelöscht wurde. Die Kombination von MFT-Analyse, USN Journal und Prefetch-Daten im Speicher ermöglicht eine robuste Zeitleiste, die Timestomping-Versuche aufdeckt. - Log-Clearing-Artefakte & Credential Extraction: Wenn ein Angreifer Windows Event Logs löscht (
wevtutil cl Security), bleiben die Events im RAM erhalten, bis der Speicher überschrieben wird.windows.evtlogsextrahiert Event-Log-Einträge direkt aus dem Speicher — auch gelöschte. Besonders wertvoll: Event ID 1102 (Security Log Cleared) wird selbst gespeichert, bevor das Log gelöscht wird — im RAM ist es noch vorhanden und beweist die Manipulation. Credential Extraction:windows.hashdumpextrahiert NTLM-Hashes aus dem SAM-Registry-Hive im Speicher.windows.lsadumpextrahiert LSA Secrets (gespeicherte Dienstkonten-Passwörter, DPAPI-Master-Keys). Fürlsass.exe-Speicher: Mimikatz-kompatible Analyse mitwindows.cachedump(Domain-Cached-Credentials) und manueller LSASS-Speicheranalyse. Forensischer Tipp: Erstellen Sie den LSASS-Prozess-Dump separat (vol -f memory.dmp -o /output windows.memmap --pid [lsass_pid] --dump) und analysieren Sie ihn mit pypykatz (Python-Implementierung von Mimikatz) für maximale Credential-Extraktion.
← Vorheriger Artikel
OAuth 2.0 & JWT Exploitation
Nächster Artikel →
Hardware Hacking & Side-Channel Attacks
Sie benötigen Unterstützung?
Memory Forensics ist die entscheidende Fähigkeit für die Erkennung von Fileless Malware und fortgeschrittenen Bedrohungen. Wir führen RAM-Akquisition und Volatility-Analyse im Incident-Response-Fall durch, erstellen YARA-Rules für Ihre Umgebung und schulen Ihr Team in Memory-Forensik-Techniken.
Security & Firewall ansehen →
