Warum Arbeitsspeicher wichtig ist und wie er gesichert wird

Ein Datenträgerabbild zeigt, was ein System gespeichert hat; ein Speicherabbild zeigt, was es gerade tat: welche Programme mit welchen Argumenten liefen, wer angemeldet war, mit welchen Zielen der Rechner verbunden war und welche Geheimnisse entschlüsselt vorlagen. Das meiste davon verschwindet beim Ausschalten. Diese Lektion behandelt, was ausschließlich im RAM vorliegt, was Sie zuerst erfassen sollten und wie Sie den Arbeitsspeicher von Windows, Linux und virtuellen Maschinen sichern, damit die Sicherung analysiert werden kann und ihre Beweiskraft begründbar ist. Das Problem der Linux-Symboltabellen erhält besondere Aufmerksamkeit, weil es der häufigste Grund für das Scheitern einer Linux-Analyse ist.

Was ausschließlich im RAM vorliegt

Der Arbeitsspeicher (Random Access Memory, RAM) enthält den Arbeitszustand des Betriebssystems und jedes laufenden Programms. Ein Teil davon wird später auf den Datenträger geschrieben, etwa in die Auslagerungsdatei, die Ruhezustandsdatei oder ein Absturzabbild (Lektion 5.4), vieles jedoch nie:

• Prozesse und ihre Befehlszeilen. Die vollständige Befehlszeile, beispielsweise powershell.exe -enc <Base64>, liegt häufig nur im Speicher des Prozesses vor.
• Netzwerkverbindungen. Offene Sockets, lauschende Ports und entfernte Adressen sowie der ARP-Cache und die Routingtabelle.
• Angemeldete Sitzungen. Interaktive Sitzungen, Remotedesktop- und Dienstsitzungen mit ihren Zugriffstoken. Unter Windows enthält der Prozess der lokalen Sicherheitsautorität (lsass.exe) Anmeldeinformationsmaterial für angemeldete Benutzer.
• Entschlüsselte Daten und Verschlüsselungsschlüssel. Solange ein BitLocker-Volume entsperrt oder ein VeraCrypt-Container eingebunden ist, befindet sich der zu seiner Entschlüsselung verwendete Hauptschlüssel im RAM. Seine Wiederherstellung kann die einzige Möglichkeit sein, den verschlüsselten Datenträger später zu lesen (Modul 7 behandelt verschlüsselte Volumes).
• Inhalte der Zwischenablage, einschließlich kopierter, aber nie gespeicherter Texte.
• Injizierter oder dateiloser Code. Schadsoftware, die direkt in einen anderen Prozess geladen wird oder als Skript im Arbeitsspeicher läuft, hinterlässt möglicherweise keine ausführbare Datei auf dem Datenträger (Lektion 5.3).
• Nicht gespeicherte Dokumente und Editorpuffer.
• Überreste des privaten Surfens. Private Modi vermeiden das Schreiben des Verlaufs auf den Datenträger, doch URLs, Seitentexte und Formulardaten verbleiben im Prozessspeicher des Browsers.

Der Arbeitsspeicher kann außerdem Datenträgerbeweise bestätigen: Prefetch belegt, dass ein Programm zu irgendeinem Zeitpunkt ausgeführt wurde, während ein Prozess in einem Speicherabbild belegt, dass es zum Zeitpunkt der Sicherung lief, einschließlich Startzeit, übergeordnetem Prozess und Benutzer.

Die Reihenfolge nach Flüchtigkeit

RFC 3227, Richtlinien für die Sammlung und Archivierung von Beweismitteln (2002), weist die erfassende Person an, von den flüchtigsten zu den am wenigsten flüchtigen Beweismitteln vorzugehen. Die dortige Liste lautet:

1. Register und Cache
2. Routingtabelle, ARP-Cache, Prozesstabelle, Kernelstatistiken, Arbeitsspeicher
3. Temporäre Dateisysteme
4. Datenträger
5. Für das System relevante entfernte Protokollierungs- und Überwachungsdaten
6. Physische Konfiguration und Netzwerktopologie
7. Archivmedien

Register und Cache ändern sich innerhalb von Nanosekunden und werden fast nie erfasst, daher kommt in der Praxis das Speicherabbild zuerst. Routingtabelle, ARP-Cache und Prozesstabelle liegen alle im RAM: Ein vollständiges Speicherabbild bewahrt sie, während die vorherige Ausführung von Live-Befehlen wie netstat oder ps den Arbeitsspeicher verändert. Temporäre Dateisysteme wie Linux tmpfs (/dev/shm und bei einigen Distributionen /tmp) liegen im RAM und verschwinden beim Ausschalten. Entfernte Protokolle überdauern den Vorfall, werden aber gemäß den Aufbewahrungsrichtlinien rotiert. Fordern Sie sie daher frühzeitig an.

Entscheidung zur Sicherung und Dokumentation der Spuren

Wenn ein System im laufenden Zustand vorgefunden wird, wird standardmäßig der Arbeitsspeicher gesichert, bevor es heruntergefahren oder die Stromversorgung unterbrochen wird. Ein vorheriges Herunterfahren zerstört die RAM-Beweise und kann ein eingebundenes verschlüsseltes Volume dauerhaft sperren. Gründe für ein anderes Vorgehen, etwa Schadsoftware, die aktiv Daten löscht, müssen abgewogen und schriftlich festgehalten werden.

Jede Live-Sicherung verändert das System. Das Werkzeug läuft als Prozess, lädt einen Treiber oder ein Modul oder öffnet Gerätedateien und überschreibt Speicherseiten, die möglicherweise freigegebene, aber noch wiederherstellbare Daten enthielten. Diese Spuren lassen sich nicht vermeiden, deshalb minimieren und dokumentieren Sie sie. ISO/IEC 27037 behandelt die Live-Sicherung und verlangt, dass jede Maßnahme begründet und dokumentiert wird. NIST SP 800-86 empfiehlt, flüchtige Daten in der Reihenfolge ihrer Flüchtigkeit mit vertrauenswürdigen Werkzeugen und unter Berücksichtigung ihrer Auswirkungen zu erfassen. Dokumentieren Sie Werkzeugname, Version und Hashwert, den genauen Befehl, das verwendete Konto, Start- und Endzeit in UTC mit ihrer Zeitquelle sowie jede Konsolenaktion.

Sicherung unter Windows

Werkzeuge zur Arbeitsspeichersicherung unter Windows benötigen Administratorrechte, weil sie einen Kerneltreiber laden, um den physischen Speicher zu lesen. Führen Sie das Werkzeug von externen Medien aus und schreiben Sie die Ausgabe auf ein vorbereitetes externes Laufwerk oder eine Netzwerkfreigabe. Schreiben Sie eine Sicherung niemals auf den eigenen Datenträger des Beweissystems: Dadurch würden nicht zugeordnete Cluster überschrieben, die gelöschte Dateien enthalten könnten. Berechnen Sie den Hashwert der Ausgabe, sobald sie vollständig ist.

Gängige Ausgabeformate sind Raw (eine flache Kopie des physischen Speichers mit der Endung .raw, .mem oder .img), das Microsoft-Absturzabbildformat (.dmp, ein Header, auf den Speicherseiten folgen) und AFF4 (Advanced Forensic Format 4, ein Container mit Komprimierung und Metadaten). Volatility 3 liest Raw- und Absturzabbilddateien direkt, jedoch kein AFF4. Exportieren Sie eine AFF4-Sicherung daher zuerst in das Raw-Format.

Zwei Windows-Funktionen erschweren die Analyse. Ausgelagerte Daten: Nach pagefile.sys verschobene Seiten befinden sich nicht im RAM-Abbild, wodurch Lücken entstehen. Sichern Sie nach Möglichkeit auch die Auslagerungsdatei (Lektion 5.4). Speicherkomprimierung: Seit Windows 10 komprimiert die Speicherverwaltung selten verwendete Seiten im RAM, statt sie auszulagern. In aktuellen Versionen von Windows 10 und 11 gehört der Komprimierungsspeicher zu einem Prozess namens Memory Compression. Diese Daten befinden sich im Abbild, sind aber komprimiert und können nur von Werkzeugen gelesen werden, die den Komprimierungsspeicher unterstützen.

Virtuelle Maschinen

Ein Hypervisor kann den Gastspeicher speichern, ohne etwas innerhalb des Gasts auszuführen. Dadurch hinterlässt kein Werkzeug Spuren, und eine angehaltene VM steht still, sodass ihr gespeicherter Arbeitsspeicher konsistent ist.

• VMware: Der Gastspeicher wird in eine .vmem-Datei geschrieben, wenn die VM angehalten wird (zusammen mit einer .vmss-Zustandsdatei) oder wenn ein Snapshot den Arbeitsspeicher einschließt (zusammen mit einer .vmsn-Snapshot-Datei). Sichern Sie die .vmem zusammen mit der zugehörigen .vmss oder .vmsn: Die Zustandsdatei beschreibt, wie der Gastspeicher in der .vmem angeordnet ist, und wird von Volatility 3 verwendet.
• Hyper-V: Seit Windows Server 2016 und Windows 10 werden gespeicherte Zustände und Prüfpunkte in .vmrs-Laufzeitzustandsdateien gespeichert. Ältere Versionen verwendeten .bin-Dateien (Arbeitsspeicher) und .vsv-Dateien (gespeicherter Zustand). Keines dieser Formate ist ein Raw-Abbild: Konvertieren Sie es mit einem Werkzeug, das das Format versteht, etwa Microsofts Werkzeugen für Speicherabbilder gespeicherter Zustände, und prüfen Sie das Ergebnis.

Sicherung unter Linux

LiME (Linux Memory Extractor) ist ein ladbares Kernelmodul. Ein Kernel akzeptiert ein Modul nur, wenn es für genau diese Kernelversion und -konfiguration erstellt wurde. Daher muss LiME mit den Headern des laufenden Kernels kompiliert werden, und zwar auf einem separaten, sauberen System mit derselben Distribution und demselben Kernel, nicht auf dem Beweissystem. Der Build erzeugt lime-<release>.ko, das beispielsweise mit insmod lime-6.1.0-18-amd64.ko "path=/mnt/usb/mem.lime format=lime" geladen wird. Der Parameter format akzeptiert raw, padded oder lime. Das Format lime schreibt vor jedem physischen Speicherbereich einen 32-Byte-Header, der mit dem magischen Wert 0x4C694D45 beginnt. Dieser erscheint in der Datei als ASCII-Bytes EMiL. LiME kann die Sicherung mit path=tcp:<port> auch über das Netzwerk bereitstellen und so jeden lokalen Schreibvorgang vermeiden. Bei Secure Boot und erzwungener Modulsignierung wird ein unsigniertes LiME-Modul abgewiesen.

AVML (Acquire Volatile Memory for Linux) ist Microsofts Alternative: ein statisches Userland-Programm, das keinen kernelspezifischen Build benötigt. Es liest über /dev/crash, /proc/kcore oder /dev/mem, je nachdem, was verfügbar ist, und schreibt im LiME-Format, optional komprimiert (Volatility 3 liest die komprimierte Datei, wenn die snappy-Bibliothek installiert ist; andernfalls konvertieren Sie sie mit avml-convert).

/proc/kcore stellt den virtuellen Kernelspeicher als ELF-Core-Datei dar. Es handelt sich nicht um ein fertiges physisches Speicherabbild: Die scheinbare Größe spiegelt den Adressraum des Kernels wider (etwa 128 TiB auf typischen x86-64-Systemen), Kernel-Lockdown kann den Zugriff einschränken, und das Kopieren mit dd erzeugt keine Datei, wie sie Analysewerkzeuge erwarten. Auch /dev/mem ist keine praktikable Quelle: Mit der auf den meisten Distributionen aktivierten Kerneloption STRICT_DEVMEM kann gewöhnlicher RAM nicht gelesen werden (aktuelle x86-Kernel geben selbst für RAM innerhalb des ersten 1 MiB Nullen zurück).

Die Tabelle fasst die Sicherungsoptionen dieser Lektion zusammen.

Das Symboltabellenproblem

Zur Analyse eines Linux-Abbilds benötigt Volatility 3 eine Symboltabelle für exakt den betreffenden Kernel-Build: eine ISF-JSON-Datei (Intermediate Symbol Format), die die Strukturen und Symboladressen des Kernels beschreibt. Sie wird mit dwarf2json aus einer vmlinux-Datei mit DWARF-Debuginformationen und der passenden System.map erstellt, beispielsweise mit dwarf2json linux --elf vmlinux-6.1.0-18-amd64 --system-map System.map-6.1.0-18-amd64 > debian12-6.1.0-18.json. Unter Debian stammt die Debug-vmlinux aus dem Paket linux-image-<release>-dbg. Volatility 3 ordnet die Symboldatei anhand der Kernel-Banner-Zeichenfolge dem Abbild zu. Das Plugin banners zeigt an, welches Banner ein Abbild enthält. Eine Sicherung ohne passende Symbole kann unbrauchbar sein. Dokumentieren Sie deshalb bei der Sicherung uname -a: Die Ausgabe sagt dem Analysten genau, für welchen Kernel Symbole beschafft werden müssen.

Integrität, Smear und Zeitablauf

Berechnen Sie sofort den Hashwert der Sicherung, üblicherweise mit SHA-256. Der Hashwert belegt, dass die Datei seit der Sicherung unverändert ist, kann aber nicht gegen die Quelle geprüft werden: Der Arbeitsspeicher ändert sich ständig, weshalb zwei Sicherungen desselben laufenden Systems niemals denselben Hashwert ergeben.

Der Arbeitsspeicher ändert sich auch während des Auslesens: Seiten, die am Ende einer Sicherung kopiert werden, spiegeln einen späteren Zustand wider als Seiten, die am Anfang kopiert werden. Dieser Smear kann inkonsistente Strukturen erzeugen, beispielsweise einen Listeneintrag, der auf einen bereits beendeten Prozess verweist. Eine Sicherung ist keine perfekte Momentaufnahme. Überprüfen Sie daher auffällige Ergebnisse anhand weiterer Belege.

Durchgerechnetes Beispiel: Sicherung eines Linux-Servers

Ein laufender Debian-12-Webserver muss gesichert werden. Ein LiME-Modul wurde im Voraus auf einem Laborsystem mit identischem Kernel erstellt. Das Sicherungsprotokoll lautet:

Größenberechnung. RAM-Größen sind binär: 8 GiB = 8 × 1.073.741.824 = 8.589.934.592 Bytes. Laufwerksgeschwindigkeiten sind dezimal: 200 MB/s = 200.000.000 Bytes pro Sekunde. Zeit = 8.589.934.592 ÷ 200.000.000 ≈ 42,9 s, also etwa 43 Sekunden. Werden 8 GiB als 8.000.000.000 Bytes behandelt, ergibt das 40 s, eine Unterschätzung um 7 %. Die dokumentierten 46 Sekunden entsprechen der Schätzung zuzüglich des Ladens des Moduls. Ein Server mit 64 GiB benötigt bei derselben Geschwindigkeit 68.719.476.736 ÷ 200.000.000 ≈ 344 s, also fast sechs Minuten Smear. Auch die lime-Datei ist nicht genau 8 GiB groß: LiME kopiert nur die Bereiche, die der Kernel in /proc/iomem als System RAM aufführt, und fügt pro Bereich 32 Bytes hinzu.

Befugnis und Datenschutz

Der Arbeitsspeicher enthält Passwörter, private Nachrichten und Daten von Personen, die nicht Gegenstand der Untersuchung sind. Vergewissern Sie sich, dass Ihre Befugnis (ein richterlicher Beschluss, die Einwilligung des Eigentümers oder ein Auftrag zur Reaktion auf Sicherheitsvorfälle) die Live-Sicherung abdeckt. Halten Sie sich an den zulässigen Umfang und schützen Sie die Sicherung als sensible Daten.

Prüfungsschwerpunkt: Rechnen Sie mit Fragen, die die Reihenfolge nach Flüchtigkeit auf ein Szenario anwenden, danach fragen, was ein Speicherabbild enthält, das ein Datenträgerabbild nicht enthält, und prüfen, warum der Hashwert einer Arbeitsspeichersicherung nicht erneut gegen das laufende System verifiziert werden kann. Sie sollten wissen, dass die Linux-Analyse mit Volatility 3 von einer ISF-Symboldatei abhängt, die exakt zum Kernel-Banner passt.

Kernpunkte

• RAM enthält laufende Prozesse, Befehlszeilen, Verbindungen, Sitzungen, Verschlüsselungsschlüssel und dateilosen Code, die nie auf den Datenträger gelangen.
• Erfassen Sie von der höchsten zur geringsten Flüchtigkeit (RFC 3227): Sichern Sie den Arbeitsspeicher vor dem Herunterfahren und dokumentieren Sie die unvermeidbaren Spuren des Werkzeugs.
• Führen Sie Windows-Werkzeuge als Administrator von externen Medien aus, schreiben Sie auf externe Medien und berechnen Sie sofort den Hashwert der Ausgabe.
• LiME muss für exakt den laufenden Kernel erstellt werden; AVML ist eine Userland-Alternative; /proc/kcore ist kein fertiges physisches Speicherabbild.
• Dokumentieren Sie uname -a: Ohne eine ISF-Symboltabelle für genau diesen Kernel kann Volatility 3 die Sicherung möglicherweise nicht analysieren.
• Smear, ausgelagerte Seiten und die Windows-Speicherkomprimierung bedeuten, dass eine Sicherung niemals eine vollständige, konsistente Momentaufnahme ist.