Forensische Analysen mit Autopsy (2) : Partielle Untersuchung des „Lone Wolf 2018“-Szenarios

Von Jochen Schlichting, Karlsruhe

Das Forensik-Szenario „Lone Wolf 2018“ auf der Website von DigitalCorpora (https://digitalcorpora.org/corpora/scenarios/2018-lonewolf-scenario) ist ziemlich faszinierend, weil es das Üben der Verwendung einer Reihe von Werkzeugen wie Autopsy, Volatility, bulk_extractor, Plaso und so weiter ermöglicht.

Das Szenario umfasst das Datenträgerabbild eines Windows-10-Laptops mit einem Benutzerprofil, das den Verlauf der Browser (Chrome, IE), eine Hibernation-Datei (hiberfil.sys), einen Hauptspeicherabzug, eine Auslagerungsdatei (pagefile.sys) und anderes enthält. Dieses Szenario und die zugehörigen Daten wurden von Thomas Moore als sein Abschlussprojekt für einen von Simson Garfinkels Kursen an der George Mason University erstellt (https://cfrs.gmu.edu).

Das Szenario verfolgt den Zweck, angehenden Incident-Respondern und forensischen Ermittlern die Möglichkeit zu geben, mit einem Datensatz eines modernen Windows-10-Clients zu arbeiten, der eine realistische Größe aufweist und dabei (mit der Zeit gehend) auch Cloud-Artefakte enthält. Die Herausforderung des Trainings besteht darin, aus der gegebenen Situation auf Basis der vorhandenen Datenspuren zu lernen.

Szenario-Hintergrund

Inhaltlich beschreibt dieser erdachte Fall die fiktive Beschlagnahme des Laptops einer fiktiven Person, die eine Massenschießerei plante. In dem Szenario alarmiert Paul Cloudy die Polizei über das zunehmend beunruhigende Verhalten seines Bruders Jim Cloudy. In der Folge beschlagnahmt die Polizei dessen Laptop und sichert mit dem Programm FTK-Imager (https://accessdata.com) Datenträger und Hauptspeicher für eine tiefergehende Analyse.

Bei der forensischen Datenerhebung wurden die folgenden Elemente erzeugt:

• Protokolldatei: FTK Imager Log.txt
• Datenträgerabbild: LoneWolf.E01 bis .E09 (50 GB), das unter anderem die Auslagerungsdatei pagefile.sys (2,9 GB) und die Hibernation-Datei hiberfil.sys (6,4 GB) enthält
• Hauptspeicherabbild: memdump.mem (17 GB)

Da die Polizei vermutet, dass der Verdächtige eine Massenschießerei plant, besteht die Aufgabe der forensischen Analyse darin, Spuren zu finden, die diese Behauptung entweder unterstützen oder widerlegen. Zusätzlich soll geprüft werden, ob es sich um einen Einzeltäter oder eine Gruppe von Tätern handelt und ob es Mitwisser gab. Die Prüfpunkte (PP) sind also PP 01 „Einzeltäter“, PP 02 „Tätergruppe“ und PP 03 „Mitwisser“.

Das Vorgehen zur Suche nach Informationen, Artefakten und Spuren, die ein Angreifer auf der eigenen IT hinterlassen hat, läuft bei forensischen Untersuchungen im Unternehmensumfeld ganz analog zum behandelten Szenario. Gemeinsam mit Kollegen ein wenig „CSI“ zu spielen, ist also eine gute Vorbereitung für eigene Analysen.

Analysevorbereitung

Um die Analyse in Autopsy durchzuführen, legt man in der Software einen neuen Fall (Case) an (s. a. [4]) und fügt ihm das Datenträgerabbild „LoneWolf.E01“ als Datenquelle (Data-Source) hinzu. Danach wählt man die „Run Ingest Modules“-Option, um einzelne Module aufrufen zu können. Dabei ist es wichtig, für alle Ingest-Module den übergreifenden Scope „All Files, Directories, and Unallocated Space“ auszuwählen (vgl. Abb. 1).

Nur so wird sichergestellt, dass Schlüsselwörter und Zielbegriffe (Keywords) für eine spätere Suche indexiert werden. Selektiert beziehungsweise verifiziert man diese Einstellung nicht, kann man später in nicht erfassten Bereichen des Datenträgers oder innerhalb von Dateien gegebenenfalls keine Hinweise finden, die für den Fall wichtig sein könnten. Oder es kommt mangels Suchtreffern zu falschen Schlussfolgerungen (False Negatives), die dazu führen, dass weitere Ermittlungen nicht zielführend ablaufen oder Bedrohungslagen unvollständig erkannt und bewertet werden.

Ebenso wichtig ist die Entscheidung, welche Ingest-Module in einer ersten Triage eingesetzt werden sollen. Hier ist es empfehlenswert, für die initiale Datenaufbereitung die Ingest-Module „Recent Activity“, „Keyword Search“ und „Data Source Integrity“ auf den Fall anzuwenden.

Gemäß dem bereits im ersten Teil dieses Workshopbeitrags [4] beschriebenen Vorgehen von Autopsy arbeiten seine Ingest-Module parallel: Das bedeutet, dass nach der Programmlogik zuerst spezifische Analysen für Benutzerkonten durchgeführt werden und im Hintergrund zum Beispiel die Indexierung für eine spätere Stichwortsuche (Keyword-Search) weiterläuft. Sucht man also zu einem frühen Zeitpunkt der Datenaufbereitung nach bestimmten Zielbegriffen, sind diese eventuell noch nicht aufbereitet und somit nicht auffindbar. Man hüte sich an dieser Stelle vor falschen Schlussfolgerungen hinsichtlich der (Nicht-)Existenz von Informationen in einem Fall.

Bei vielen Vorfällen kommt der Analyse des Kontexts von Benutzerkonten, in denen wichtige Transaktionen zum Geschehen vermutet werden, eine zeitkritische Bedeutung zu. So auch in diesem fiktiven Szenario, bei dem man zum Zeitpunkt der Beschlagnahme nicht weiß, ob es sich um einen Einzeltäter oder eine Gruppe handelt.

Akquisition und Beweiskette

Der bei der Durchsuchung und Beschlagnahme anwesende polizeiliche Ermittler fand den Laptop im angeschalteten und nicht gesperrten Zustand sowie in einem angemeldeten administrativen Berechtigungskontext des Benutzerkontos „jcloudy“, was ihm ermöglichte, neben dem Datenträger (Festplatte) auch den Hauptspeicherinhalt zu sichern – Abbildung 2 zeigt das Ausgabeprotokoll des dabei eingesetzten forensischen Werkzeugs FTK-Imager.

Nachdem die forensische Datenerhebung im Labor angekommen und das Übergabeformular für die Beweismittelkette unterschrieben ist, erfolgen erste Analysetätigkeiten mithilfe von Autopsy (https://github.com/sleuthkit/autopsy/releases/). Der erste Schritt ist die Verifikation des Hashwerts des Datenträgerabbilds, um die Integrität zu überprüfen und belegen zu können. Autopsy hasht dazu automatisch jede Datei, während die Analyseaufbereitung durchlaufen wird, einschließlich der Hauptquelle (Data-Source).

Abbildung 3 zeigt die entsprechenden Werte, die Autopsy nach Auswahl von „Data Sources Summary / Details“ ausgibt. Diese Informationen gilt es, mit den von der Akquisition bekannten Daten zu vergleichen und ihre Übereinstimmung festzuhalten. So ist gewährleistet, dass die Analyse auf einer definierten Ausgangsbasis beruht, die dem forensisch gesicherten Zustand entspricht. Die Vernachlässigung dieses einfachen Arbeitsschrittes hat bereits häufig dazu geführt, dass eine Beweiskette erfolgreich angezweifelt werden konnte.

Desktop-Dateien

Nachdem man die Integrität des Datenträgerabbilds überprüft hat, beginnt die Untersuchung im gegebenen Szenario sinnvollerweise mit der Ausgabe des Ingest-Moduls „Recent Activity“, das chronologisch absteigend sortiert wird (neueste Dateien zuerst – Abb. 4).

Da diese Auflistung viele Zugriffe auf Dateien vom Windows-Desktopbereich des Benutzerkontos „jcloudy“ enthält, liegt es nahe, sich diesen Ordner im nächsten Analyseschritt näher anzusehen. Auch sonst kann man an dieser Stelle häufig gute Informationen über die Aktivitäten eines Benutzers erlangen.

Eine rekursive Suche mit dem Dateibrowser von Autopsy nach den zuletzt im Windows-NTFS-Dateisystem geänderten Dateien (Modified) auf dem Desktop liefert im untersuchten Szenario die folgenden fünf Office-Dateien, die selbsterklärende Namen aufweisen: „Cloudy thoughts (4apr).docx“, „Planning.docx“, „Operation 2nd Hand Smoke.pptx“, „AIRPORT INFORMATION.docx“ und „The Cloudy Manifesto.docx“.

Diese Dateien liegen zeitlich alle sehr nah vor dem Datum des polizeilichen Zugriffs am 6. April 2018 (vgl. Abb. 2) und beginnen zeitlich mit der Datei „Planning.docx“, die am 29. März erzeugt worden ist. Die inhaltliche Auswertung dieser fünf Dokumente, die ebenfalls innerhalb von Autopsy möglich ist, liefert im Szenario wichtige Hinweise auf die Ansichten des Verdächtigen über Waffenkontrolle und waffenfreie Zonen („The Cloudy Manifesto.docx“) sowie seine Planung („Planning.docx“) mit Bestimmung des Angriffsziels, einer Auflistung benötigter Gegenstände, Planung der Flucht sowie anschließender Veröffentlichung einer Pressemitteilung.

Interessant ist Autopsys Darstellung der Folien des Powerpoint-Dokuments „Operation 2nd Hand Smoke.pptx“, bei dem es sich um den konkreten Angriffsplan zu handeln scheint (Abb. 5): Aus gespeicherten Bildschirmfotos kann man schließen, dass Jim Cloudy seinen Angriff für die Veranstaltung „Town Hall For Our Lives“ am 7. April 2018 am Whitfield Place 21030 geplant hatte, über welchen Zugang (Bibliothek) er das Gebäude betreten, wie er zum Flughafen fahren und über Südkorea nach Indonesien (Bali) fliehen wollte.

Cloud-Artefakte

Wie die Auswertung von Notizen helfen kann, zeigt „Cloudy Thoughts (4apr).docx“: Dieses Dokument enthält neben Erklärungen zum Verhalten des Verdächtigen auch Hinweise auf gesicherte Datenspeicher in der Cloud, zu denen sein Bruder Paul einen (Zweit-)Schlüssel besitzen soll: „The only record will remain in the cloud and Paul will have the only other keys.“ Dabei ist zunächst nicht klar, um was für einen Cloud-Service es sich handelt.

In der Auflistung der „Recent Documents“ gibt es eine unlängst genutzte Verknüpfung „rootkey.LNK“, die auf die Datei „C:\Users\jcloudy\Downloads\rootkey.csv“ verweist, die aber im Dateisystem nicht mehr existiert. In der letzten Windows-Schattenkopie des Volume-Shadows-Service (VSS) ist sie allerdings noch auffindbar, nachdem man das Ingest-Modul „Process/Extract Shadow Copies“ auf die Datenquelle angewendet hat. Der Quellpfad hierfür lautet: /vss1 – d4a32c4c-37d0-11e8-9b15-28e347017777 – 2018-04-04 06:32:10/vss1/Users/jcloudy/Downloads/rootkey.csv

Bei der weiteren Untersuchung zeigt sich, dass auf dem Laptop Cloud-Dienste von Box, Dropbox, OneDrive, Google Drive und Amazon S3 genutzt wurden – auch um die genannten Dokumente zu replizieren. Betrachtet man die zu Google Drive gehörenden Artefakte, fällt zusätzlich die Google-Doc-Datei „Brother Chat.gdoc“ auf, die auf eine Chat-Aktivität mit dem Bruder hindeutet – ihre Inhalte weisen darauf hin, dass sie unter einer URL in der Google-Cloud gespeichert ist (Abb. 6). Die letzte Aktualisierung erfolgte in der Nacht des 6. April 2018 um 3:21 Uhr, also nur wenige Stunden vor der forensischen Beweissicherung um 8:50 Uhr. Auffällig ist, dass diese Datei schon am 31. März angelegt wurde – der Chat mit dem Bruder lief also womöglich schon eine ganze Weile.

Shellbags und Prefetch

Um weitere Informationen zu den letzten Aktivitäten auf dem Rechner des Verdächtigen zu erhalten, werden von Autopsy die Ingest-Module Shellbags sowie Prefetch angestoßen. Dabei ist zu beachten, dass dies für die unterschiedlichen „Data-Sources“ erneut und separat erfolgen muss, da beispielsweise ein Shadow-Copy-Volume erst nach dem Durcharbeiten des eigentlichen Hauptdatenträgers verfügbar wird.

ShellBags dient dem Auffinden von zuletzt durch ein Benutzerkonto angesehenen Verzeichnissen. Im betrachteten Szenario zeigt sich etwa, dass basierend auf den Zeitstempeln aus der UsrClass.dat-Registrydatei des Benutzerkontos jcloudy am 27. März auf das Verzeichnis Explorer\AKMonitor\logs\ zugegriffen wurde – dessen übergeordnetes Hauptverzeichnis \AKMonitor selbst wurde bereits eine Woche zuvor erstellt (Abb. 7). Zusätzlich ist erkennbar, dass am 27. März das Unterverzeichnis \pic erstellt wurde.

Die Anwendung des Ingest-Moduls Prefetch, das für die Suche nach den zuletzt ausgeführten Programmen zuständig ist, ergibt, dass in Verbindung mit dem Namen des via Shellbags gefundenen Verzeichnisses ein Programm mit dem korrespondierenden Namen AKMONITOR.EXE ausgeführt wurde. Eine Verifikation auf dem Datenträger zeigt jedoch, dass dieses Programm dort nicht zu finden ist – es lässt sich weder auf dem Datenträger noch in den extrahierten Shadow-Copy-Volumes vss0, vss1 und vss2 lokalisieren.

Hauptspeicheranalyse

Da der Hauptspeicher (memdump.dmp) ebenfalls gesichert wurde und für die Analyse zur Verfügung steht, liegt es nahe, mit Volatility (vgl. [2,3]) auch dort nach dem ominösen Programm zu suchen. Mit der ersten Befehlszeile (pslist) in Abbildung 9 konnte ein laufender Prozess lokalisiert werden. Anschließend liefert eine pstree-Suche genaue Umgebungsparameter, mit der der Prozess AKMonitor.exe gestartet wurde: Das Programm wurde offenbar von einem anderen Datenträger (Volume) als C:\ gestartet (nämlich D:), der als HarddiskVolume5 referenziert ist.

Der anschließende filescan-Befehl liefert ein besseres Verständnis darüber, ob noch weitere Datei-Artefakte im Hauptspeicher mit dem Programm AKMonitor.exe in Verbindung stehen beziehungsweise auf denselben Aufrufpfad hinweisen. Aus der Antwort ist ersichtlich, dass der Prozess AKMonitor.exe, der schon seit dem 27. März läuft, Hinweise auf ein Log-Unterverzeichnis (\logs) liefert, das Dateien mit funktionellem Bezug wie URLs (url.dat), das Clipboard (clipboard.dat), Bilddaten (\pic) und mindestens einige Screenshots (screenshot.dat) umfasst. Darüber hinaus gibt es mit libeay32.dll und ssleay32.dll Dateien, die auf eine verschlüsselte Kommunikation hindeuten.

Mit der letzten Befehlszeile in Abbildung 9 prüft man die einzelnen logischen Windows-Handles für den laufenden Prozess AKMonitor.exe. So zeigt sich, dass dieses Programm offenbar ein Keylogger mit dem Namen „Actual Keylogger“ ist. Eine Recherche dazu führt zur Website www.actualkeylogger.com, auf der ein kommerzielles Produkt verkauft wird, das über einen Registration-Key zu aktivieren ist.

Suche nach Schlüssel-Dateien

Eine Suche nach einer Schlüsseldatei ist mit Autopsy im Ingest-Module „Interesting Files Identifier“ beispielsweise durch das Stichwort „key“ über alle Dateisysteme innerhalb des Falls möglich. Abbildung 10 illustriert die Erstellung eines fallbezogenen Regelsatzes (Rule-Set) mit mindestens einer Detailregel für ein bestimmtes Stichwort (hier: „key“). Die Anwendung dieses Regelsatzes zeigt dann in allen dem Fall zugehörigen Datenträgern, wo dieses Stichwort zu finden ist.

Im aktuellen Szenario findet man eine Datei D:\key.txt, die zu dem Kontext des Keyloggers passt, sowie zusätzlich eine Datei rootkey.csv für einen unbekannten Amazon-S3-Bucket. Ein Vergleich mit dem aus /img_LoneWolf.E01/vol_vol7/Users/jcloudy/AppData/Roaming/S3Browser/accounts.xml extrahierten Schlüsselmaterial für Amazon-S3-Buckets zeigt, dass es sich um Verweise auf zwei verschiedene Buckets handelt.

Der neue Rootkey für einen der AWS-S3-Buckets existierte gemäß dem Zeitstempel der Volume-Shadow-Copy vss1 dabei mindestens schon seit dem 4. April 2018 – und er stimmt nicht mit dem Secretkey des von jcloudy genutzten S3-Buckets überein, in dem die bereits genannten fünf Planungs-Dokumente repliziert wurden. Es könnte sich dabei also um den vom Verdächtigen erwähnten „other key“ für seinen Bruder Paul handeln (vgl. Abschnitt „Cloud-Artefakte“).

Erkenntnisse zum Chat mit dem Bruder

Der „Brother-Chat“ ist eine direkte Kommunikation zwischen Jim Cloudy und seinem Bruder Paul, zu dem bereits eine Google-DocsDatei gefunden wurde – die Unterhaltung begann den Dateidaten zufolge am 31. März und wurde letztmalig am 6. April aktualisiert (vgl. Datumsangaben in Abb. 6). Eine Stichwortsuche nach „Brother Chat“ in Autopsy liefert über einen Treffer in der Registry (Abb. 11) einen Hinweis auf einen offenen Browser-Tab in Google Chrome.

Über die Process-ID des Chrome-Browsers (Pid 13120) lassen sich mit dem Yarascan-Volatility-Plugin Inhalte aus dem Hauptspeicher finden (Abb. 12), in denen der Analyst den Chat im offenen Browser-Tab nachlesen kann, woraus sich weitere Erkenntnisse über die Motivation von Jim und die (Nicht-)Kollaboration seines Bruders ergeben (zu PP 03 „Mitwisser“).

Zunächst gibt es einen Hinweis darauf, dass Paul offenbar seinem Bruder Jim einen Computer geschickt hat und dieser sich über Neuigkeiten zum 2. Zusatzartikel der U.S.-amerikanischen Verfassung empört (Recht auf Waffenbesitz). Sein Bruder Paul fragt dann nach, was Jim in Bezug auf Waffen recherchiert, dass es die Bundesbehörden zu ihm führen könnte: „What are you researching that would bring the feds to your door?“ Der Auszug in Abbildung 12 zeigt überdies eine überraschte Rückfrage von Paul, wie gerade Jim eine Lösung für die von ihm geschilderten Probleme umsetzen wolle, es sei denn, er würde selbst in ein politisches Amt gewählt.

Fazit

Für den PP 01 „Einzeltäter“ deuten die Datenartefakte darauf hin, dass Jim Cloudy vermutlich tatsächlich alleine mit der Tatvorbereitung beschäftigt war, da beispielsweise sein Manifest und seine Fluchtplanung nur ihn betreffen und keine direkten Hinweise auf Kollaboration mit Dritten zu finden waren. Auch für den PP 02 „Tätergruppe“ finden sich in den Datenartefakten keine Hinweise auf Dritte. Für den PP 03 „Mitwisser“ liefern die Hauptspeicherinhalte in Bezug auf den „Brother-Chat“ Informationen, die aber nicht den Rückschluss zulassen, dass Paul Cloudy konkret wusste, was sein Bruder Jim vorhatte.

Offen bleibt zunächst die Frage, warum ein Keylogger auf dem Rechner von Jim Cloudy installiert worden war – und zwar zeitlich bereits vor den Zeitstempeln der Planungsdokumente auf dem Desktop von jcloudy. Eventuell könnten weitere Analysen des Hauptspeichers in Bezug auf die dort referenzierten Dateien (z. B. screenshots.dat) noch Einblicke und Hintergründe liefern – das soll aber nicht Aufgabe dieses Beitrags sein und kann interessierten Lesern als weitere Übung dienen.

Das Lone-Wolf-2018-Szenario zeigt recht gut, wie man mit Autopsy in eine komplexe Analyse einsteigen kann und recht schnell ziemlich weitreichende Ergebnisse erzielt (bzw. belegen kann). Beschränkt man sich allerdings auf Autopsy, dann fehlen Teile des Puzzles, die offenbar nur im Hauptspeicher vorliegen. Es gibt zwar bereits eine Betaversion des Ingest-Moduls Volatility, allerdings sind dessen Outputs noch nicht vollständig in die Suchfunktionen von Autopsy integriert – deshalb wurde im Beispiel weiterhin mit dem eigentlichen Volatility-Programm gearbeitet.

Jochen Schlichting (CISA, CISM, Auditteamleiter auf Basis von IT-Grundschutz) 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-SourceTools für Incident-Response und Forensik, <kes> 2019#2, S. 27
[2] Jochen Schlichting, VolatilityWorkshop (1), Der Weg in den Hauptspeicher und zu den Prozessen, <kes> 2019#4, S. 18
[3] Jochen Schlichting, VolatilityWorkshop (2), Der Weg von Prozessen zu Spuren und Artefakten von Malware, <kes> 2019#5, S. 22
[4] Jochen Schlichting, AutopsyWorkshop (1), Überblick über Tool und Module, <kes> 2019#6, S. 20