Plaso-Workshop : Forensische Analyse von Zeitartefakten und Zeitlinien am Beispiel des Lone-Wolf-2018-Szenarios

Von Jochen Schlichting, Karlsruhe

In jedem vermuteten oder tatsächlichen Vorfall stellen sich die zentralen kriminalistischen Fragen: Wer? Was? Wo? Wann? Womit? Wie? (und evtl.: Weshalb? – vgl. Subprozess „Entdeckung“ in [1]). Vor allem das „Wann?“ ist dabei meistens von zentraler Bedeutung, da entsprechende Antworten den Betroffenen helfen, einen Vorfall und seine Tragweite besser einzuschätzen oder erst als solchen zu erkennen.

Bei den aktuell noch andauernden Untersuchungen zum im Dezember 2020 detektierten APT-Case Sunburst (vgl. https://malpedia.caad.fkie.fraunhofer.de/details/win.sunburst) vermutet man schon jetzt, dass solche Angriffe bereits mindestens bis ins 1. Quartal 2020 zurückreichen. Man hat es sozusagen parallel zur Covid-19-Pandemie mit einer Incident-Pandemie in der globalen, virtuellen IT-Welt zu tun. Bei der Einordnung haben auch Funde von Zeitinformationen auf infiltrierten Systemen betroffener Unternehmen geholfen.

Solche Informationen – zumeist in Form von Zeitstempeln in/aus unterschiedlichsten Artefakten – sind in der digitalen forensischen Analyse und der zugehörigen Incident-Response (DFIR) so etwas wie der Zaubertrank des Druiden Miraculix für den unbeugsamen, forensischen Analysten: Essenziell ist dabei das Wissen, dass man nicht den ganzen Kessel Zaubertrank (alle Daten) konsumieren muss, um reagieren zu können, sondern ein Schluck zur richtigen Zeit (Triage definierter Artefakte und Zeitfenster) genügt, um einen Angriff gegen das eigene Dorf (Unternehmen) abwehren zu können – manchmal braucht man zugegebenermaßen ein paar Schlucke mehr, wenn der Angriff länger andauert. Wer die richtigen Zutaten (Zeitstempel) zusammentragen und daraus einen Zaubertrank (Zeitlinie) brauen kann, ist (sehr häufig) „unbesiegbar“ und evidenzbasiert unbeugsam. Um Handlungsoptionen in der digitalen Incident-Response zu entwickeln, braucht man den richtigen Mix aus Sorgfältigkeit und Triage.

Plaso to the Rescue

Mit dem Open-Source-Werkzeugkasten Plaso (https://github.com/log2timeline/plaso), der bereits in der <kes>-Übersicht forensischer Tools kurz vorgestellt wurde [1], lassen sich solche Zeitinformationen aus diversen Datenquellen in Form von Artefakten extrahieren und als SQlite3-Datenbank im Format .plaso speichern. Plaso unterstützt mit seinen Parsern Artefakte aus den Betriebssystemen Windows, Linux, OS X und Android.

Die .plaso-Datenbank kann einerseits bereits das Endergebnis einer Extraktion von Zeitstempeln sein. Andererseits kann sie auch als Ausgangspunkt (in Form einer Masterdatenbasis) für detaillierte, triagierte Abfragen dienen, um Analysen weiter einzugrenzen.

Plaso selbst besteht aus fünf verschiedenen Teilwerkzeugen (image_export.py, log2timeline.py, pinfo.py, psort.py und psteal.py), von denen einige in den nachfolgenden Schritten genutzt werden. Besonders image_export eignet sich gut für die Extraktion spezifischer Datenobjekte in ursprünglicher Form (z. B. hiberfil.sys, pagefile.sys), wodurch eine nachvollziehbare Erzeugung aus einer definierten Quelle möglich wird.

Beispiel-Szenario

Grundlage für diesen Workshop ist das bereits im <kes>-Workshop zu Autopsy [2] benutzte Forensik-Szenario „Lone Wolf 2018“ aus dem Repository von DigitalCorpora (https://digitalcorpora.org/corpora/scenarios/2018-lonewolf-scenario). Diese Test-Daten sind frei verfügbar, sodass sich jeder selbst an ihrer Analyse versuchen kann. Im Folgenden wird das komprimierte Datenträgerabbild „LoneWolf.E01 bis .E09“ mit dem SHA1-Hashwert „694e26624d1ea029eb50d793b198edf85be4b4fc“ verwendet, das den sichergestellten Inhalt des Desktoprechners des Verdächtigen jcloudy darstellt.

Hard- und Sofwarebasis

Für diese Datenbasis sollte man mindestens eine Intel-CPU, Typ i7 Gen7 mit 4 Cores und 8 Threads, 16 GB Hauptspeicher sowie eine SATA-Festplatte nutzen, um komfortabel analysieren zu können. Parallel durchgeführte Tests auf einem Ryzen Threadripper 1950X mit 16 Cores und 64 Threads, 128 GB RAM (in der sich für bessere I/O-Performance eine Memory-only-Ramdisk mit dem LoneWolf.E0x befindet und in die auch die .plaso-Dateien geschrieben werden), ermöglichten eine sehr signifikante Beschleunigung der Analyseabläufe. Vor allem viel RAM und viele Threads helfen bei der Parallelisierung möglichst vieler Worker-Prozesse.

Der Beitrag beruht auf der Nutzung des Plaso-Release 20201228, das zwischenzeitlich wieder deutlich stabiler und zügiger arbeitet als die Releases, die zuvor seit dem Frühjahr 2020 verfügbar waren. Man sollte sich im Klaren darüber sein, dass Plaso von engagierten Softwareingenieuren entwickelt wird und seine Qualität und seinen Funktionsumfang in erster Linie dem Peer-Review durch fortwährendes Testen und Rückmeldungen seiner Nutzer verdankt. Kommerzielle Alternativen gibt es faktisch nicht – Plaso stellt somit den derzeitigen Standard für die Erstellung von Zeitlinien dar.

Selbstverständlich gibt es Systembefehle im Betriebssystemumfeld zur Anzeige von Zeitinformationen, aber diese geben beispielsweise bei Windows nicht alle existierenden Datei-Zeitstempel wieder.

Um Plaso schnell zum Laufen zu bringen, empfiehlt sich die Installation der Docker-Engine (www.docker.com/get-started), mit der eine containerbasierte, definierte Umgebung für Plaso unter Linux, MacOS und Windows zur Verfügung steht. Die Installation benötigt in Docker circa 500 MB und dauert je nach Internet-Anbindung wenige Minuten nach dem Aufruf durch docker pull log2timeline/plaso.

Ist die Installation erfolgreich, lässt sich die Einsatzbereitschaft mit folgender Eingabe testen, die einen Output mit der Plaso-Version generiert:

docker run log2timeline/plaso
log2timeline.py –version
plaso – log2timeline version
20201228

Es ist auch möglich, eine Offline-Version des Docker-Containers zu erzeugen, wenn die Datenaufbereitung ausschließlich im nicht-vernetzten Zustand betrieben werden muss. Dazu exportiert man zunächst den Docker-Container:

docker save log2timeline/plaso |
gzip -c > saved_docker_image
plaso-20201228.tgz

Anschließend kopiert man saved_docker_image-plaso-20201228.tgz auf einen externen, mobilen Datenträger und bindet diesen per .tgz-Archiv auf dem Offline-System ein, um ihn in Docker einzuspielen:

zcat saved_docker_image-plaso
20201228.tgz | docker load

Ausführung in Docker

Der Entry-Point des Docker-Containers ist die Skriptdatei plasoswitch.sh – sie versteht die Befehle log2timeline (oder log2timeline.py), pinfo (oder pinfo.py), psort (oder psort.py) sowie psteal (oder psteal.py) und führt die entsprechenden Programme von Plaso aus.

Startpunkt – log2timeline

Zunächst wird die Extraktion mit log2timeline.py gestartet. Sollten Evidenzdateien oder das Datenträgerabbild nur auf dem Host vorhanden sein, nicht aber im Docker-Container selbst (was meist das Standardszenario darstellt), muss man eine sogenannte Brücke (Bridge) zwischen Host und Container einrichten. Besonders bei großen Datenträgerabbildern im GB- oder gar TB-Bereich ist dieses Vorgehen sehr sinnvoll. Liegt das zu analysierende Datenträgerabbild LoneWolf-E0x beispielsweise im Pfad /data, kann man log2timeline.py auf diese Weise anweisen, die zu erzeugende Plaso-Datenbank als /data/LoneWolf.E0x.plaso zu erzeugen und ebenfalls dort zu speichern. Vergisst man die Pfadangabe, sucht man sonst die .plaso-Datei womöglich vergeblich im Host-System – denn sie liegt dann im Docker-Container.

Die einfachste und vielleicht auch gebräuchlichste Art, log2timeline.py auszuführen, kommt ohne zusätzliche Parameter aus – es werden nur Ein- und Ausgabe definiert. Für die Ausgabe sind Pfad und Dateiname der .plaso-Speicherdatei anzugeben, während die Eingabe der Ort der Quelle ist, egal ob es sich um eine einzelne Datei, ein Speichermedium, ein Gerät oder einen Einhängepunkt (Mountpoint) handelt. Das Werkzeug durchläuft die gesamte Datenquelle und erzeugt eine vollumfängliche Zeitlinie, die Informationen aus allen gefundenen Dateien umfasst (inkl. gelöschter Dateiobjekte).

Diese einfachste Form eines Durchlaufs, bei der lediglich das erste Archiv LoneWolf.E01 aufgerufen werden muss, lautet somit:

docker run -v /mnt/c/lw2018:/data log2timeline/
plaso log2timeline.py /data/LoneWolf.E0x.plaso /
data/LoneWolf.E01

Auf diese Weise wird die Plaso-Datenbank auf dem Host-Dateisystem gespeichert und es geht kaum I/O-Leistung dadurch verloren, Daten innerhalb des Dateisystems des Docker-Containers schreiben zu müssen.

Erste Analyse – psort.py

Der nächste Schritt ist die Ausführung der Analyse mit psort.py zur Sortierung der Zeitstempel (Ergebnis siehe Abb. 1):

docker run -v /mnt/c/lw2018:/data log2timeline/
plaso psort.py -w /data/LoneWolf.E0x.plaso.
timeline /data/LoneWolf.E0x.plaso

Direktes Arbeiten im Docker-Container

Wer auf lange Befehlszeilen verzichten möchte, kann selbstverständlich auch durch die Änderung des entry_point direkt auf die Eingabeaufforderung (CommandPrompt) innerhalb des Docker-Containers zugreifen. Danach muss man lediglich in das Verzeichnis /bin wechseln und die Plaso-Befehle stehen wie gewohnt zur Verfügung:

docker run -t -i –entrypoint=/bin/bash -v /mnt/c/
lw2018/:/data log2timeline/plaso

Erstellung einer Zeitlinie

Wenn man vorher weiß, welche Dateien für eine Analyse relevant sind und welche nicht, kann man Collection-Filter verwenden, um Plaso anzuweisen, nur Ereignisse aus explizit aufgeführten Dateien zu sammeln – das wird auch als gezieltes (targeted) Sammeln bezeichnet. Collection-Filter wirken wie ein Rezept für eine Triage, um sich auf wesentliche Informationsquellen in einen Fall (bzw. Vorfall) zu fokussieren.

Plaso unterstützt zum gezielten Einsammeln von Ereignissen in Form von Zeitinformationen sowohl Forensic-Artifacts-Definitionen als auch die Nutzung spezifischer Filter-Dateien. Es ist dabei zu beachten, dass man die verschiedenen Sammlungsfilter derzeit nicht gleichzeitig verwenden kann!

Das Digital Forensics Artifact Repository (https://github.com/ForensicArtifacts/artifacts/releases) stammt aus dem Projekt des Google Rapid
Response Frameworks (https://github.com/google/grr) für Incidents und stellt eine frei verfügbare, maschinenlesbare Wissensbasis digitaler forensischer Artefakten in Form von YAML-Dateien bereit. Die aktuelle Version 20201106 enthält über 500 verschiedene Artefakt-Definitionen, darunter mehr als 1000 Verzeichnispfade und über 600 RegistryKeys – alles sozusagen potenzielle „Indicators of Compromise“ (IoC). Diese Kollektion ist etwa dann sehr hilfreich, wenn man noch nicht genau weiß, was man sucht und damit gegebenenfalls einen Zufallstreffer landet.

Collection-Filter

Hat man hingegen ein konkretes Ermittlungsziel in Form eines auffälligen Vorgangs oder Zeitfensters vor Augen (z. B. im LoneWolf2018-Szenario bei jcloudy den 2018-04-06), dann bietet es sich an, einen
Windows-spezifischen CollectionFilter als Datei zu nutzen (z. B. den windows_filter – https://github.com/log2timeline/plaso/blob/master/data/filter_windows.txt). Sofern man die .yaml-Variante nutzt, kann man auch mit exclude spezifische Unterpfade (z. B. %SystemRoot%\WinSxS) aus Hauptpfaden (z. B. %SystemRoot%) ausschließen, was nutzlose Daten in der Analyse weiter minimiert.

Für Plaso sind auf dem .E0xDatenträgerabbild insgesamt vier Partionen (p1, p2, p3, p4) durch Programmteile von The Sleuth Kit (TSK) detektierbar (Abb. 2). Vermutet man anhand der Größe die Windowspartition auf p4 korrekt, so findet log2timeline.py dort zwei zusätzliche Volumenschattenkopien (vss1, vss2), die eine Reise zurück in der Zeit zum 27. März (2018-03-27) und 4. April (2018-04-04) ermöglichen. Forensische Analysten können also auf zeitlich fixierte Zustände zurückgreifen, die nicht einfach durch den Benutzer jcloudy im Benutzerkontext manipulierbar waren.

Mithilfe der Collection-Filter-Datei windows_filter durchsucht Plaso im LoneWolf-2018-Szenario nicht mehr alle verfügbaren Dateien innerhalb der Partition p4 nach Zeitstempeln. Dadurch schrumpft die erzeugte .plaso-Datenbank von 2,4 GB (8 Std. Laufzeit) auf 0,95 GB (Ergebnis nach 15 Min.). Spezifiziert man zusätzlich noch die Option –no_vss, um auf die Auswertung der Volumenschattenkopien des SystemDrive C: zu verzichten, sinkt der Zeitbedarf weiter.

Es ist ebenfalls möglich, ausschließlich spezifische VSS-Daten auszuwerten. Um im Beispiel etwa nur den 4. April zu betrachten, dauert ein Durchlauf mit dem folgenden Befehl gerade einmal 9 Minuten (auf einer SATA-HDD – Sortierergebnis siehe Abb. 3):

log2timeline.py -f /data/filter_
windows.txt -data/lw2018.filter.
windows.vss-only.vss2.plaso /
data/LoneWolf.E01 –partitions
p4 –vss_only –vss_stores vss2

So lassen sich übrigens auch spezifische .plaso-Datenbanken für bestimmte Zeiträume und mit eingeschränkten Artefakten erstellen.

Event-Filter

Der zweite wichtige Mitspieler in der Triage ist die Nutzung von ereignisbezogenen Filtern, die sich in Plaso in folgende Klassen unterteilen:

• Hashers: Kalkulation von MD5-/SHA1-/SHA256-Hashes über die Datenquelle(n) (z. B. Datenträgerabbilder und darin enthaltene Datenobjekte oder Verzeichnisse mit Artefakten)
• 73 verschiedene Parser: (z. B. mft, sqlite, winevtx oder pe)
• 94 verschiedene Parser-Plug-ins (z. B. winreguserassist, winregwindows_usbstor_devices oder mrulist_shell_item_list)
• 9 verschiedene Parser-Presets (z. B. android, linux, macos, webhist, win7 und win_gen), die Parser und Plug-ins als Vorauswahl kombinieren

Der Unterschied zwischen Plug-ins und Parsern liegt vor allem darin, dass ein Parser Dateiformate (FileFormats) versteht und segmentiert, während ein Plug-in Daten innerhalb von Dateiformaten versteht. Am Beispiel der Windows-Registrierung versteht der Parser also das Dateiformat der Registry selbst und analysiert es. Der Zweck eines Plug-ins ist jedoch, den tatsächlichen Schlüsselinhalt auszulesen und sinnvolle Daten daraus zu erzeugen.

Das Gleiche gilt etwa für SQLite-Datenbanken – Beispiele für SQLite-Plug-ins sind etwa das Chrome-History- oder das Firefox-Verlaufs-Plug-in. Beide Browserverläufe sind SQLite-Datenbanken, also verwenden sie denselben Parser – aber die Daten, die in ihnen gespeichert sind, sind unterschiedlich, daher braucht man spezifische Plug-ins dafür. Das funktioniert übrigens auch für .plaso-SQLite-Datenbanken selbst.

Unterstützt werden Event-Filter in Plaso von

• log2timeline.py über den Parameter –parsers für eine zielgerichtete Erzeugung von Zeitobjekten mit Parsern und Parser-Presets, bei
• psort.py über den Parameter –analysis sowie
• über die direkte Eingabe für die Auswertung.

So liefert zum Beispiel die nachfolgende Abfrage eine Übersicht aller Zeitstempelobjekte auf dem gesamten Datenträgerabbild (in chronologischer Abfolge sortiert), die über das Datenfeld user in der .plaso-Datenbank auf den Benutzer jcloudy hinweisen:

psort.py /data/lw2018-filter-windows-p4-vss-all.plaso
username contains ’jcloudy‘ -w /data/lw2018-filter
windows-p4-vss-all.plaso.jcloudy.txt

Damit werden 39 761 Events mit Bezug zu jcloudy aus insgesamt 1 469 135 herausgefiltert (Abb. 4)

Um Zeitstempelobjekte für jcloudy aus einem definierten Zeitfenster – hier die letzten 6 Stunden unmittelbar vor dem Zugriff durch die Ermittlungsbehörden – aus allen Zeitstempelobjekten herauszufiltern und zu sortieren, dient die folgende Abfrage:
psort.py /data/lw2018-filter-windows-p4-vss-all.plaso
”date > ’2018-04-06 03:00:00‘ and date < ’2018-04- 06 09:00:00‘“ -w /data/lw2018-filter-windows-p4-vss all.plaso. pc.jcloudy.1804060300.1804060900.txt Diese Analyse liefert 46 359 Events für den Zeitraum von 3:00 Uhr bis 9:00 Uhr am 06. April 2018 (Auszug siehe Abb. 5). Dabei wird unter anderem die bereits in [2] identifizierte, gelöschte Datei rootkey.csv von jcloudy quasi automatisch aufgespürt, die den Zugang zu einem Cloud-Account für den Bruder umfasst (jcloudy@file:///C:/Users/jcloudy/Downloads/rootkey.csv).

Fazit

Es ist kein Druidengeheimnis von Miraculix, dass man mit Plaso sehr viel „Zaubertrank“ in seinem forensischen Labor zur Verfügung hat. Findet man die richtige Dosierung und kreiert individuelle Rezepte, ergeben sich zumeist wundersame Erkenntnisse aus Datenquellen, die zuerst wie Datenwüsten voller Zeitstempel aussahen.

Sicherlich eignet sich Plaso auch für die Erstellung von Zeitlinien auf Datenbeständen in größeren Wirtschaftsstrafsachen, denn auch Metadaten in Dateien enthalten häufig Zeitinformationen. Plaso unterstützt zudem ein stabiles Multi-Threading, wodurch sich auch große Datenträgerabbilder und Datenverzeichnisse auswerten lassen.

Eine weitere sehr zielführende Funktion von Plaso ist die Fähigkeit, Mikrosekunden für eine Hauptsekunde eines Zeitstempelobjekts erzeugen zu können. Damit kann man die Auftrennung von Vorgängen und Abläufen sehr hoch auflösen, was beispielsweise bei Analysen von Schadsoftwareinfektionen hilft, die auf den ersten Blick nicht transparent sind.

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 in Karlsruhe (jochen.schlichting@secorvo.de – auch auf XING und LinkedIn).

Literatur

[1] Jochen Schlichting, Für alle (Vor-)Fälle, Prozesse und Open-Source-Tools für Incident-Response und Forensik, <kes> 2019#2, S. 27
[2] Jochen Schlichting, Forensische Analysen mit Autopsy (2), Überblick über Tool und Module, <kes> 2020#3, S. 23