Volatility-Workshop (3) : Update zu Grundlagen von Volatility in Version 3 mit punktueller Analyse des „Lone Wolf 2018“-Szenarios

Von Jochen Schlichting, Karlsruhe

Fast drei Jahre nach dem Release der „Stable Version“ Volatility 2.6 kam im Oktober 2019 eine erste Public-Beta der Major-Version 3 als kompletter Re-Write des Frameworks in Python auf GitHub. Letztlich hatte die usprüngliche Code-Basis, die noch auf das Jahr 2007 zurückgeht, zunehmend für technische und PerformanceProbleme gesorgt. Im Februar 2020 wurde dann Volatility 3 in Version 1.0.0 veröffentlicht.

Änderungen zu Volatility 2

Volatility 3 wurde von Grund auf als Bibliothek konzipiert: Seine Komponenten sind unabhängig und der gesamte Zustand, der für die Ausführung eines bestimmten Plug-ins zu einem bestimmten Zeitpunkt erforderlich ist, ist in einem Objekt enthalten, das von einem ContextInterface abgeleitet ist. Der Kontext enthält die beiden Kernkomponenten, aus denen Volatility besteht: Datenebenen und die verfügbaren Symbole.

Volatility 3 verwendet keine Profile mehr, sondern wird mit einer umfangreichen Bibliothek von Symboltabellen geliefert und kann für die meisten Windows-Speicherabbilder neue Symboltabellen generieren, die auf dem Speicherabbild selbst basieren. Dadurch können Symboltabellen spezifische Offsets für Speicherstellen (Symbolorte) enthalten, die speziell auf diesem Betriebssystem basieren. Somit ist es einfacher und schneller, Strukturen innerhalb eines Betriebssystems zu identifizieren, da die Offsets für diese Strukturen aus den offiziellen Debugging-Informationen bekannt sind.

Änderungen am Objektmodell

Das Objektmodell hat sich ebenfalls geändert: Objekte erben nun direkt von ihren Python-Gegenstücken, das heißt ein Integer-Objekt ist eigentlich ein PythonInteger (und hat alle zugehörigen Methoden) und kann überall dort verwendet werden, wo man ein normales int verwenden kann. In Volatility 2 wurde hingegen ein komplexes Proxy-Objekt konstruiert, das versuchte, alle Methoden des Host-Objekts zu emulieren – aber letztlich war es ein anderer Typ und konnte nicht an denselben Stellen verwendet werden. Heikel war dabei, dass hierdurch die Reihenfolge der Operationen wichtig werden konnte, da „a + b“ vielleicht nicht funktionierte, aber „b + a“ womöglich gut.

Volatility 3 hat zudem erhebliche Geschwindigkeitsverbesserungen erfahren. Während Volatility 2 für den Zugriff auf Live-Speicherabbilder und Situationen ausgelegt war, in denen sich die zugrunde liegenden Daten während der Ausführung des Plug-ins ohne Weiteres ändern durften, werden die Daten in Volatility 3 nun einmalig zum Zeitpunkt der Objekterstellung gelesen und bleiben statisch, auch wenn sich die darunter liegende Ebene ändert. Volatility 2 hätte die Daten erneut eingelesen, was für die Live-Speicherforensik nützlich war, aber für die üblicherweise durchgeführte statische Speicheranalyse ziemlich ineffizient war, weil gegebenenfalls unveränderte Werte viele Male unnötigerweise neu eingelesen werden mussten. Volatility 3 erfordert dagegen, Objekte manuell neu zu erzeugen, wenn sich die zugrunde liegenden Daten möglicherweise geändert haben.

Um spezifische Informationen von Volatility bereitzustellen, ohne die Flexibilität einzuschränken, dass Strukturen Mitglieder mit unterschiedlichen Namen haben können, wurden sämtliche Metadaten über das Objekt (wie seine Ebene oder sein Offset) in ein schreibgeschütztes vol()-Wörterbuch verschoben.

Zusätzlich wurde die Trennung zwischen einer Schablone (die ein Objekt erstellt) und dem eigentlichen Objekt selbst klarer definiert: In Volatility 2 konnten einige Informationen (z. B. die Größe) nur aus einem erstellten Objekt abgeleitet werden. Dies führte dazu, dass eine Schablone auf einem leeren Puffer instanziiert wurde, allein um die Größe zu ermitteln. In Volatility 3 hingegen enthalten Schablonen Informationen (wie ihre Größe), die direkt abgefragt werden können, ohne das Objekt tatsächlich zu erstellen.

Layer und Layer-Abhängigkeiten

Die Adressräume von Volatility 3 werden nun genauer als Übersetzungsschichten bezeichnet, da sie typischerweise übereinander liegen und Adressen zwischen der höheren logischen Schicht und der niedrigeren physischen Schicht übersetzen können. Die Adressräume in Volatility 2 waren strikt auf einen Stapel beschränkt, der linear übereinander lag. In Volatility 3 können Schichten mehrere „Abhängigkeiten“ (niedrigere Schichten) haben, was die Integration von Funktionen wie Swap-Space ermöglicht.

Automagic

In Volatility 2 wurde versucht, sowohl für Anwender als auch für Entwickler Abläufe einfach zu gestalten. Dies führte zu dem, was als „Automagic“ bezeichnet wurde, da es sich um automatische Prozesse handelte. Diese automatischen Prozesse wurden in Volatility 3 stärker kodifiziert. Die „automagischen“ Prozesse sind nun klar definiert und können je nach Bedarf für einen bestimmten Lauf (Run) aktiviert oder deaktiviert werden. Im Gegensatz dazu war Automagic in Volatility 2 kein besonders modularer Mechanismus. Automagic wurde ausschließlich für das Stapeln von Adressräumen (und nicht für die Identifizierung von Profilen) verwendet und konnte nicht einfach deaktiviert oder konfiguriert werden. Automagics in Volatility 3 sind nun eine Kernkomponente, die von den Verbrauchern der Bibliothek nach eigenem Ermessen aufgerufen werden kann oder auch nicht. Es wurde auch eine Stacker-Automagie integriert, um die häufigste Funktion von Volatility 2 zu emulieren, nämlich das automatische Stapeln von Adressräumen (jetzt Translation Layers) übereinander.

Ausgabe-Rendering

Die Output-Rendering-Funktion ähnelt der von Volatility 2 sehr, da sie ursprünglich bereits für Volatility 3 entwickelt wurde. Zusätzlich wird nun jedoch verlangt, dass alle Plug-ins die Ausgabe in einem TreeGrid-Objekt erzeugen, um sicherzustellen, dass die Bibliothek unabhängig von der jeweiligen Schnittstelle verwendet werden kann. Außerdem gibt es mit Volumetric ein Web-GUI, über das alle Plug-ins, die über die Kommandozeile (CLI) aufrufbar sind, auch von einer Webseite aus gestartet werden können. Dieses bietet Funktionen wie automatische Formatierung und Sortierung der Daten, die zuvor nicht einfach über die CLI bereitgestellt werden konnten.

Zudem existiert nun die Möglichkeit für eine Dateiausgabe, sodass die Benutzeroberfläche ein Mittel zum Rendern oder Speichern dieser Dateien bereitstellen kann. Eine weitere wichtige Ausgabeformatoption steht mit der Option -r RENDERER zur Verfügung. Als Renderer sind derzeit verfügbar (RENDERER-Argument jeweils in Klammern): CLIRenderer, QuickTextRenderer (quick), CSVRenderer (csv), PrettyTextRenderer (pretty), JsonRenderer (json) sowie JsonLinesRenderer (jsonl). Mit -r pretty verbessert sich die bisher übliche CLI-Ausgabe stark in Richtung schnellere Lesbarkeit, und über -r csv lassen sich recht angenehme Gridviews mit PowerShell erstellen.

Für die Analyse von Windows-Hauptspeicherabbildern stehen etliche Plug-ins zur Verfügung, die sich komfortabel per PowerShell anzeigen lassen (Abb. 2). Mit Volatility 3 besteht zudem mit der Option –parallelism threads endlich die Möglichkeit, die gesamten Analysetätigkeiten, die in den Bereich des reinen Scannings des Hauptspeicherabbilds fallen über die maximale Anzahl von verfügbaren Threads errechnen zu lassen. Daraus resultiert ein erheblicher Performancegewinn bei zeitkritische Analysen. Bei der Analyse einer möglichen, bestehenden Systemkompromittierung kann man etwa mit dem Plug-in windows.vadyarascan.VadYaraScan sehr zügig nach „Indicators of Compromise“ (IoC) suchen.

Installation

Die Installation von Volatility 3 erfordert mindestens Python 3.8 und das Paketverwaltungswerkzeug „pip“. Sie kann sowohl unter Linux als auch unter Windows durchgeführt werden. Unter Windows kann die Powershell als leistungsstarke Umgebung zusätzlich genutzt werden.

Es ist ratsam, die forensische Analyseumgebung durch Verwendung des Pakets virtualenv in einer abgesonderten Umgebung einzurichten. Dies verhindert potenzielle Auswirkungen auf das übrige System. Dies ermöglicht sowohl die Segregation als auch die Möglichkeit, beispielsweise eine offizielle Veröffentlichung in einer isolierten Installationsinstanz aufzubewahren und die aktuelle Entwicklerversion in einem separaten Verzeichnis zu haben. Auf diese Weise kann auch eine Volatility-2-Instanz aufrechterhalten werden. Für diese gibt es derzeit aufgrund des Volatility-Plug-in-Wettbewerbs die meisten Plug-ins für verschiedene Anwendungsszenarien, von denen einige (noch) nicht für Volatility 3 verfügbar sind.

Um eine funktionierende Volatility-3-Umgebung unter Windows einzurichten, öffnet man die Kommandozeileneingabe (cmd.exe), navigiert zum Skript-Pfad von Python (z. B. C:\Python38\Scripts), der kompilierte Binärdateien enthält, und erstellt dort mithilfe von virtualenv eine entsprechende Umgebung. Nach Aktivierung dieser Umgebung (.\Scripts\activate.bat) können in der Windows Powershell benötigte Pakete mit den Befehlen pip install pefile yara-python capstone jsonschema installiert werden. Anschließend wird Volatility per git clone https://github.com/volatilityfoundation/volatility3.git installiert.

Architektur und Begriffe

Volatility 3 teilt die Speicheranalyse in mehrere Komponenten auf, dies sind: Speicherschichten (Memory Layers), Schablonen und Objekte (Templates and Objects) sowie Symboltabellen. Das Framework speichert all dies in einem sogenannten Context, der als Container für all die verschiedenen Schichten und Tabellen fungiert, die zur Speicheranalyse notwendig sind.

Speicherschichten (Memory Layers)

Eine Speicherebene ist eine Datenansammlung, auf die durch Anfragen an eine bestimmte Adresse zugegriffen werden kann. Ein Speicher wird als sequenziell angesehen, wenn Daten über sequenzielle Adressen abgerufen werden. Es ist jedoch nicht notwendig, die Daten sequenziell zu speichern. Moderne Prozessoren neigen dazu, den Speicher in ausgelagerten Formaten (paged out) zu verwalten.

Daten müssen nicht zwingend in einem leicht zugänglichen Format gespeichert sein. Sie können kodiert, verschlüsselt oder eine Kombination aus verschiedenen Datenquellen sein. Diese Datenquellen werden typischerweise von Programmen gehandhabt, die Dateiformate verarbeiten, oder vom Speichermanager des Prozessors. Sie stellen quasi „Übersetzungen“ der ursprünglichen Daten dar – entweder geometrisch oder sprachlich. Volatility 3 stellt dies durch einen gerichteten Graphen dar. Endknoten dieses Graphen sind „DataLayers“, und die internen Knoten werden als „TranslationLayer“ bezeichnet. Auf diese Weise können beispielsweise ein Rohspeicherabbild im LiME-Dateiformat und eine Auslagerungsdatei zu einer einzigen virtuellen Intel-Speicherschicht zusammengeführt werden. Wenn Adressen vom Intel-Layer abgefragt werden, erfolgt die Übersetzung der Adresse in eine physische Adresse mithilfe des Intel-Speicherzuordnungsalgorithmus und der entsprechenden Verzeichnistabellenbasis oder Seitentabellenabbildung. Diese Adresse wird dann entweder an den Swap-Layer oder den LiME-Layer weitergeleitet. Wenn sie an den LiME-Layer weitergeleitet wird, bestimmt der LiME-Dateiformat-Algorithmus, wo die Daten innerhalb der Datei gespeichert sind, und liefert die Daten zurück.

Schablonen und Objekte (Templates and Objects)

Sobald es möglich ist, auf zusammenhängende Speicherbereiche über eine virtuelle Adresse (wie sie von Programmen gesehen wird) zuzugreifen, können Objekte extrahiert werden. Dazu wird eine Schablone (Template) auf einer Speicherebene (Memory Layer) an einem bestimmten Offset verwendet. Eine Schablone enthält alle Informationen über die Struktur eines Objekts, ohne tatsächlich mit Daten befüllt zu sein. Eine Schablone gibt die Größe einer Struktur und ihrer Elemente wieder und zeigt, wie weit ein bestimmtes Element in der Struktur liegt und was verschiedene Werte in diesem Feld bedeuten können. Sie enthält jedoch nicht den Inhalt eines bestimmten Elements.

Objekte können unter Verwendung einer Schablone auf einer Speicherebene an einem bestimmten Offset erstellt werden. Ein Objekt ermöglicht die Abfrage seiner Elemente und insbesondere die Verfolgung von Zeigern, was einen einfachen Zugriff auf die im Objekt enthaltenen Daten ermöglicht.

Symboltabellen

Die meisten kompilierten Programme haben ihre eigenen Schablonen (Templates) und definieren die Struktur sowie den Ort dieser Schablonen als Symbole. Ein Symbol ist oft eine Adresse. Eine Schablone kann verwendet werden, um auf Symbole unabhängig voneinander zu verweisen. Symbole und ihre Nachschlagetabellen werden oft als Debugging-Informationen neben der Programmkompilierung erstellt. Volatility 3 bietet über eine Symboltabelle Zugriff auf diese Informationen. Man kann mehrere dieser Symboltabellen innerhalb eines Kontexts als SymbolSpace sammeln. Ein Kontext kann jeweils nur einen SymbolSpace speichern, der jedoch so viele SymbolTable-Elemente wie nötig enthalten kann.

Volatility 3 verwendet die De-facto-Namenskonvention für Symbole im Format „module!symbol“, um auf sie zu verweisen. Diese Informationen werden aus einer JSON-formatierten Datei gelesen, die als Vermittler zwischen Windows-PDB-Dateien, Linux-DWARF-Dateien, anderen Symbolformaten und dem internen Python-Format fungiert, das Volatility 3 zur Darstellung von Schablonen oder Symbolen verwendet.

Zur Erinnerung: Das Gegenstück eines SymbolSpace in Volatility 2 war ein Profil, aber die Vorversion des Frameworks konnte nicht zwischen Symbolen aus verschiedenen Modulen unterscheiden und erforderte eine spezielle Handhabung für 32-Bit-Programme, die Wow64 unter Windows verwendeten. Alle Symbole befanden sich in einem einzigen Namensraum – mit der Möglichkeit von Kollisionen von Symbolnamen.

Plug-ins, Ausgabe und Automagic

Ein Plug-in dient dazu, Daten über die Benutzeroberfläche von Volatility 3 anzufordern und sie dann zu verwenden, um eine bestimmte Form der Analyse auf dem Context durchzuführen (mit beliebigen Symboltabellen und Speicherschichten). Das Kommunikationsmittel zwischen der Benutzeroberfläche und der Bibliothek ist der Konfigurationsbaum, den Komponenten innerhalb des Context verwenden, um konfigurierbare Daten zu speichern.

Nachdem ein Plug-in ausgeführt wurde, gibt es die Ergebnisse in einem bestimmten Format, dem TreeGrid, zurück. Dadurch wird sichergestellt, dass die Daten von Consumern der Bibliothek verarbeitet werden können, ohne genau zu wissen, um welche Daten es sich handelt oder wie sie formatiert sind. Benutzeroberflächen können wählen, wie sie die Ausgabe der Ergebnisse am besten über OutputRenderer darstellen wollen. Die Bibliothek antwortet immer mit einem TreeGrid und die Oberfläche kann dann bestimmen, wie sie es anzeigt.

Für die Kommandozeilenschnittstelle (CLI) kann das die Textausgabe als Tabelle sein oder die Ausgabe in eine SQLite-Datenbank oder CSV-Datei. Für eine Weboberfläche ist die beste Ausgabe wahrscheinlich in der JavaScript Object Notation (JSON), sodass sie als Tabelle angezeigt oder in eine Datenbank wie Elastic Search eingefügt und mit einem vorhandenen Frontend wie Kibana durchforstet werden kann.

Der Konfigurationsbaum (Configuration Tree) fungiert als Schnittstelle zwischen dem aufrufenden Programm und der Volatility-3-Bibliothek. Elemente der Bibliothek (z. B. ein Plug-in, ein Translation Layer, eine Automagic usw.) können diesen Baum verwenden, um dem aufrufenden Programm mitzuteilen, welche Optionen sie benötigen und/oder optional unterstützen. Sie ermöglichen es dem aufrufenden Programm, diese Informationen bereitzustellen, wenn die Bibliothek dann aufgerufen wird.

Es gibt bestimmte SetupTasks, die den Kontext in einer für ein Plug-in vorteilhaften Weise aufbereiten, bevor es ausgeführt wird, und hierfür einige sich wiederholende und leicht falsch zu machende Aufgaben erledigen. Solche Tasks werden Automagic (Volatility3.framework.automagic) genannt, da sie beispielsweise auf „magische“ Weise ein Raw-Memory-Image nehmen und das Plug-in automatisch mit einer geeigneten Intel-Übersetzungsschicht und einer genauen Symboltabelle versorgen, ohne dass das Plug-in oder das aufrufende Programm alle notwendigen Details eigenständig angeben müssten.

Automagic ist in Volatility 3 eine wesentliche Komponente, welche die Arbeit mit modernen Kernelversionen von Windows sehr stark vereinfacht oder zum Teil erst ermöglicht – und damit erstmals auch automatisch über das Automagic-Submodul volatility.framework.automagic.pdbscan eine Unterstützung für „unbekannte“ Kernelversionen liefert. Gerade unter den Aspekten der Geschwindigkeit und des erforderlichen Fachwissens, um auf Daten innerhalb eines Raw-Memory-Images zugreifen zu können, werden Einsteiger mit Volatility 3 hierdurch sehr stark „unsichtbar“ unterstützt.

Teilweise kann man mit Volatility 3 sogar auch vermeintlich nicht-lesbare (smeared) Raw-Memory-Images aus älteren Fällen in eine lesbare Form überführen.

Praxis: Lone Wolf 2018

Im Folgenden dient das schon aus dem Lone-Wolf-2018-Szenario in früheren Workshop-Artikeln [5,6] bekannte Hauptspeicherabbild von jcloudy’s Windows10-Rechner [7] dazu, um exemplarisch einige Volatility-3-Funktionen vorzustellen. Zur besseren Nutzbarkeit wurde hierzu die Umgebungsvariable $mem definiert, um auf das Hauptspeicherabbild über die Ramdisk R: zugreifen und so die I/O-Belastung für das Analysesystem gering halten zu können, im Beispiel-System etwa per:

PS C:\Python38\Scripts\Volatility3
-af090bf\Volatility3\> $mem =
R:\forensic\digital.corpora\
scenarios\LW2018\jcloudy\mem\
memdump.mem

Das initiale Auslesen der informativen Daten des Hauptspeicherabbilds dauerte auf dem Analyse-PC (i7 Gen10th) für die 17 GB nur rund 30 Sekunden. Dabei wurde für die gefundene Windows-Version eine eigenständige Symbols-Datei 481F0DAABA6C4F02B456FAD74941C2A4-1.json.xz automatisch erstellt, die einen Zugriff auf weitere Daten innerhalb des Hauptspeicherabbilds erst ermöglicht.

Sofern man ältere Kernel-Builds von Windows verwendet oder beispielsweise keinen Online-Zugriff auf den Microsoft-Symbolsserver besitzt, lassen sich auch statische Sets vordedinierter Symboldateien nutzen. Diese sind unter https://downloads.volatilityfoundation.org/Volatility3/symbols/windows.zip mit einer Größe von 800 MB abrufbar. Ein solches Repository gab es in der Vergangenheit nur beim Forensik-Framework Rekall, das aber inzwischen auf Github nicht länger aktiv gepflegt wird (Status „archived“).

Optional (z. B. für die Offline-Nutzung) hält das Volatility Project auch Sammlungen kernelspezifischer Symboldateien für die Betriebssystemfamilien OSX und Linux bereit – was sehr hilfreich ist, da diese nur über mehrere manuelle Arbeitsgänge erzeugbar sind.

Sechs exemplarische Analyseschritte

Im Workshop-Beitrag [5] wurde über die Diskforensik ein gestartetes verdächtiges Programm namens AKMonitor.exe identifiziert. Hätten die Ermittler nur noch den Hauptspeicher sichern können, wäre es nunmehr trotzdem möglich gewesen, diesem Programm auf die Spur zu kommen: Zuerst würde man sich darüber informieren, welche Programme mit welchen Aufrufparametern gestartet wurden – dabei hilft das Plug-in windows.cmdline.CmdLine (Abb. 3).

Nach Unterdrückung der Treffer für das lokale Laufwerk C:\ bleiben die zwei dargestellten Zeilen, die zeigen, dass AKMonitor.exe von einem Laufwerk D:\ aufgerufen wurde – und später (erwartungsgemäß) das Sicherungsprogramm FTK Imager.exe, das die Ermittler zur Sicherung der Disk- und Hauptspeicherabbilder des Rechners von jcloudy eingesetzt hatten. In einem zweiten Schritt lässt sich aus der Prozessliste leicht ermitteln, wann die zugehörigen Prozesse zu diesen externen Programmen gestartet wurden (Abb. 4).

Der dritte Schritt untersucht anhand der Windows Registry den Kontext, unter dem AKMonitor.exe auf das System gelangt ist (Abb. 5). Das geschieht mit dem Plug-in windows.registry.userassist.UserAssist und führt zu dem Ergebnis, dass das Programm offenbar schon am 27. März 2018 vormittags um 09:33:20 auf dem Rechner von jcloudy installiert wurde. Demgegenüber wurde das Programm als aktiver Prozess erst um 23:29:45 am 27. März 2018 gestartet – es war noch aktiv (2018-04-06 12:42:31), während die Ermittler die Beweissicherung vornahmen (2018- 04-06 12:41:20). Wie schon in [5] berichtet, arbeitete der verdächtige „J. Cloudy“ eigentlich ausschließlich auf dem sichergestellten Rechner, den er von seinem Bruder erhalten hat.

Abbildung 6 zeigt das Ergebnis des nächsten Analyseschritts zur Identifizierung der Security-Privilegien (Se*Privilege), die der Prozess von AKMonitor.exe (PID8312) besitzt: Insgesamt sind das 35, darunter zum Beispiel auch SeTcbPrivilege, aufgrund dessen das Programm als Teil des Betriebssystems gilt und den meisten Systemauditfunktionen von Windows entgeht. Es ist somit leicht erkennbar, dass es sich hier nicht um ein „einfaches“ Programm handelt, sondern um etwas, das vollständigen Systemzugriff besitzt – was außerhalb bekannter Betriebssystemteile üblicherweise auf Schadsoftware schließen lässt.

Daher wurde anschließend mit dem Plug-in windows.malfind.Malfind geprüft, ob auf dem System typische Schadsoftware-Mechanismen (wie Injections) anzutreffen sind. Das Ergebnis (Abb. 7) zeigt, dass dies der Fall ist – und neben dem fragwürdigen externen Programm selbst mit insgesamt 128 Treffern auch alle wesentlichen Programme betroffen sind, die der Nutzer jcloudy für seine Anschlagsplanung verwendet hat. Es liegt also der Verdacht nahe, dass das von Laufwerk D:\ ins System eingebrachte AKMonitor.exe sich zur Überwachung in andere Programme eingeklinkt hat.

Daher wurde in einem sechsten Analyseschritt das Programm aus dem Hauptspeicher extrahiert, um eine kurze Sichtung auf auffällige Strings vorzunehmen: Dabei scheinen auffällige Begriffe wie screenshots.dat, Actual Keylogger report, spy_only_char und weitere den Malware-Verdacht zu bestätigen (Abb. 8).

Fazit

Das Beispiel zeigt, wie man mit Volatility 3 und unterstützenden Programmen in sechs Schritten und in hoher Arbeitsgeschwindigkeit recht gut aus einem einfachen Windows-10-Hauptspeicher-Abbild viele Erkenntnisse gewinnen kann, die zu konkreten „Indicators of Compromise“ führen. Ein solches Vorgehen ist natürlich nicht auf das Lone-Wolf-2018-Szenario oder Windows 10 beschränkt, sondern funktioniert in vielen Fällen, in denen Windows-, Linux- oder OSX-Hauptspeicher untersucht werden müssen.

Die Crux ist aktuell, dass das alte Volatility 2.6.1 nur eine zeitlich stark versetzte Unterstützung für moderne Windows-Kernel erfährt, derzeit aber noch deutlich mehr stabile Plug-ins besitzt als Volatility 3. Hat man ein Hauptspeicherimage, das davon nicht unterstützt wird, sitzt man als Incident-Responder zwischen den Stühlen – sprich zwischen den beiden Werkzeugen.

Das neue Volatility 3 ist primär als Library programmiert und es wird wohl auch zukünftig nicht alle Outputs in der gewohnten einfachen Darstellung geben. Dies dürfte zukünftig sogenannten Rich-Client-User-Interfaces überlassen bleiben, die mit den von Volatility aufbereiteten Daten weiterarbeiten.

Man muss bei Volatility 3 auch ganz klar sagen, dass es sich hierbei um ein forschendes Forensikprojekt handelt – nicht-funktionierende beziehungsweise abbrechende Plug-ins gehören derzeit zum Laufzeitverhalten dazu.

Man kann in Teilen schon feststellen, dass das alternative Framework Rekall (www.rekall-forensic.com), obwohl es nicht mehr weiterentwickelt wird, für Windows schon vieles kann, wo Volatility 3 in Sachen Stabilität erst noch hinkommen muss. Allerdings funktioniert bei Volatility 3 inzwischen das automatische Profile-Building deutlich zuverlässiger als bei Rekall. Konsequenz: Der versierte Digital-Forensic-Incident-Responder muss derzeit noch viele Pfeile (sprich: virtualenv’s) im Köcher behalten.

Jochen Schlichting (CISA, CISM, BSI-Auditteamleiter auf Basis von IT-Grundschutz, TI-Sicherheitsgutachter der gematik) arbeitet als Consultant, Head of Forensic Labs sowie Lead und Incident-Responder bei der Secorvo Security Consulting GmbH (jochen.schlichting@secorvo.de – auch auf XING und LinkedIn).