Für alle (Vor-)Fälle : Prozesse und Open-Source-Tools für Incident-Response und Forensik

Der sprichwörtliche „Fall der Fälle“ ist angesichts von Komplexität, Angriffsfläche und Bedeutung heutiger IT schon fast als Regelfall anzusehen („Assume the Breach!“). Eine angemessene Reaktion auf mögliche Vorfälle mit Sicherheitsbezug benötigt eine sorgsame Vorbereitung von Organisation und Technik – umso mehr, wenn personenbezogene Daten im Spiel sind und eine Meldepflicht an die Aufsichtsbehörden binnen 72 Stunden besteht oder Verzögerungen zu begründen sind (Art. 33 DSGVO).

Obwohl sich in den Geschäftsführungen mittlerweile die Erkenntnis durchgesetzt hat, dass zur ordentlichen Sorgfaltspflicht neben der Reaktion auf Probleme auch die Vorbereitung gehört, wissen doch längst nicht alle Organisationen, was in ihren IT-Netzen und -Systemen gerade passiert und wie sie mit den mehr oder minder stetigen, mehr oder minder schweren Sicherheitsvorfällen umgehen sollen. Dieser unbefriedigenden Situtation wird mittlerweile – spätestens nach dem nächsten nennenswerten Vorfall – gern mit dem Aufbau interner SecurityIncident-Response-Teams (SIRTs) begegnet. Doch personelle Ressourcen zu schaffen (wenn man sie denn findet), genügt alleine natürlich nicht. Incident-Response und Forensik benötigen gut geplante Prozesse und griffbereite Werkzeuge, um tatsächlich schnell und effektiv handeln zu können, wenn es darauf ankommt.

Organisatorische Grundlagen

Es gibt derzeitig mindestens zwei wesentliche Standards für Vorfallteams:

• Der Bereich „DER: Detektion und Reaktion“ [1] des seit Ende 2017 verfügbaren BSI-Grundschutzkompendiums führt recht viele sinnvolle Anforderungen in deutscher Sprache auf, die im Vorfeld und während eines Vorfalls eine Rolle spielen. Nicht alles davon ist für den eigenen operativen Betrieb zwingend notwendig. Vielmehr zeigt sich häufig, dass Unternehmen sich das heraussuchen, was am besten funktioniert und für sie durchhaltbar ist. Der Vorteil solcher Bausteine liegt darin, dass diese als ein Messinstrument fungieren und Vergleichbarkeit erzeugen.
• Schon deutlich länger gibt es die vom US-amerikanischen NIST 2008 veröffentlichte und 2012 überarbeitete Special Publication 800-61 „Computer Security Incident Handling Guide“ [2], der im weiteren Verlauf des Artikels gefolgt wird. Dem dortigen Kapitel 3 „Handling an Incident“ entstammt die in Abbildung 1 dargestellte praktisch bewährte Struktur, die mit ihren sieben Subprozessen in der erfolgreichen Vorfallsbekämpfung vielfach erprobt ist.

Vorfallszenarien und -identifizierung

Unternehmen gelingt es meist, sich mit dem Subprozess „1. Vorbereitung“ in eine günstige organisatorische Ausgangsposition für die Reaktion auf einen Sicherheitsvorfall zu bringen. Bemerkt man dann im Kontext von Subprozess „2. Entdeckung“ tatsächlich einen Anfangsverdacht, werden unweigerlich die folgenden kriminalistischen Fragestellungen an den Vorfall gestellt: Wer? Was? Wo? Wann? Womit? Wie? (und evtl.) Weshalb?

Diese „W-Fragen“ leiten zusammen mit den übergeordneten Anforderungen aus der Compliance den Subprozess „3. Analyse“ ein, in dem ein spezifisches Szenario identifiziert wird. Dabei besitzt das Locard’sche Prinzip „Jeder und alles am Tatort nimmt etwas mit und lässt etwas zurück“ für die forensischen Untersuchung digitaler Tatorte eine große Bedeutung. Daten beziehungsweise Datenspuren (Artefakte) können auch in der digitalen Forensik ein genaueres Bild eines Vorfalls und so eine Beurteilung des Geschehens ermöglichen.

Die Identifizierung von Szenarien lässt sich erfahrungsgemäß am besten durch die folgenden Fragestellungen vornehmen:

• Sind Daten abgeflossen, zugetragen oder manipuliert worden?
• Sind personenbezogene Daten betroffen?
• Handelt es sich um Schadsoftware oder aktive Angreifer?
• Kann ein Zeitfenster identifiziert oder eingeschränkt werden?
• Wie ist der Angriff abgelaufen?
• Läuft der Vorfall noch?
• War es ein zielgerichteter Angriff oder ist man zufälliges Opfer?

Sind das Szenario und betroffene Infrastrukturkomponenten hinreichend klar, stellt sich die Frage, an welchen Orten sich Daten oder Artefakte finden lassen. Erst dann steht die Entscheidung an, welche Werkzeuge gegebenenfalls sinnvoll einsetzbar sind.

Vorgehen bei der Analyse

Übliche Primärquellen, an denen die digitale Forensik zuerst auf fallbezogene Daten oder Datenspuren hin prüft und die als Grundlage für eine Analyse dienen, sind mindestens Hauptspeicher- oder/ und Datenträgerabbilder. Ergänzend kommen je nach Verfügbarkeit Unterquellen hinzu, die zum Teil aus den Primärquellen extrahiert beziehungsweise diagnostisch generiert werden. Dies sind unter anderem Zeitlinien, Berechtigungsstrukturen und Netzwerkkommunikation.

Der Analyse von Hauptspeicherabbildern (sog. RAM-Dumps/- Images) oder Auslagerungsdateien (Swap Files) kommt immer häufiger die Schlüsselrolle zu, um einen Verdacht zu erhärten oder zu entkräften. Dies gilt vor allem, wenn sich auf klassischen Datenträgern keine Hinweise finden lassen, die ein Analyseszenario sinnvoll beantworten. Diese Situation ist eng mit dem Typ des Angreifers verbunden: Durchgeführte Transaktionen können entweder automatisiert (durch programmgesteuerte Abläufe) oder interaktiv (durch menschliche Akteure) erfolgen – eine automatisierte Vorbereitung mit interaktiver Nacharbeit ist für Angriffe ebenfalls nicht unüblich.

Werkzeugauswahl

Es gibt in der digitalen Forensik zwar recht viele kommerzielle Werkzeuge. Da diese aber dem Prinzip „Closed Source“ unterliegen, ist es fast unmöglich, fehlerhafte Abläufe bei der Datenaufbereitung und Artefaktextraktion zeitnah festzustellen und Fehler nachzuvollziehen. Zusätzlich ist zu bedenken, dass besonders Projekte, die dem Prinzip „Open Source“ folgen, in der digitalen Forensik die Innovationstreiber für eine zeitnahe, funktionelle Unterstützung von ständig aktualisierten Betriebssystemen, Anwendungen und Datenformaten sind. Diese Innovationen fließen erst mit zum Teil sehr langer zeitlicher Verzögerung in kommerzielle Werkzeuge zurück – oder auch gar nicht.

Hinzu kommt häufig die Unplanbarkeit der Natur eines Vorfalls und seines Ablaufs mit der gleichzeitigen Notwendigkeit, das richtige Werkzeug kurzfristig verfügbar zu haben und unter hohem Zeitdruck korrekte Ergebnisse liefern zu können. Das Werkzeug gehört also auch zum Subprozess „1. Vorbereitung“, um sozusagen die richtigen Pfeile im Köcher zu haben. Und selbstverständlich haben verfügbare Budgets für Analysewerkzeuge einen großen Einfluss auf die Ausstattung und die Möglichkeiten von Security-Incident-Response-Teams (SIRTs). Die führenden Prämissen für SIRT-Werkzeuge, die im Tagesgeschäft entscheidend sind, lauten Robustheit, Verfügbarkeit, Budget und Zeit.

Um zu den oben genannten W-Fragen Antworten oder zumindest erste Anhaltspunkte finden zu können, bedarf es zur Aufnahme von Analysetätigkeiten unter diesen vier Prämissen einer Grundausstattung IT-forensischer Werkzeuge. Die nachfolgende kurze Auswahl und Vorstellung solcher Werkzeuge, die sich am Open-Source-Prinzip orientieren, soll dabei helfen, dass diese Prämissen zu den Stärken des eigenen SIRT werden können. Um den Subprozess „3. Analyse“ zu meistern, gilt es, die Spezialisten mit den besten Werkzeugen auszurüsten.

Die Werkzeuge selbst stellen bei fachkundiger Nutzung eine belastbare Basis für Analysen in der digitalen Forensik bereit und überzeugen durch ihre Historie in der Weiterentwicklung und Verfügbarkeit seit teilweise bereits über einem Jahrzehnt.

Werkzeuge

Analyse von Hauptspeicherabbildern mit Volatility

Volatility ist ein einziges, zusammenhängendes Framework zur Analyse der RAM-Dumps von 32- und 64-Bit-Windows, Linux-, OSX- und Android-Systemen (https://github.com/volatilityfoundation/volatility). Das modulare Design von Volatility ermöglicht es, neue Betriebssysteme und Architekturen zeitnah nach ihrer Veröffentlichung problemlos zu unterstützen. Als Zielobjekte eignen sich alle IT-Systeme, bei denen der Zugriff auf den Hauptspeicher möglich ist – die forensischen Möglichkeiten sind daher immens. Ohne Volatility hätte man beispielsweise über die Rolle der Stuxnet-Schadsoftware zur „Zentrifugenoptimierung“ vermutlich nur sehr, sehr wenig erfahren.

Volatility wurde in Python geschrieben, einer etablierten forensischen und Reverse-Engineering-Sprache mit einer Vielzahl von Bibliotheken, die sich leicht in Volatility integrieren lassen. Es läuft auf Windows-, Linuxoder OSX-Analysesystemen und benötigt im Gegensatz zu anderen Speicheranalysewerkzeugen, die nur unter Windows laufen, keine .NET-Installationen und Administratorrechte.

Eine erweiterbare und skriptfähige Programmierschnittstelle (API) ermöglicht es, das aktuelle Release selbst zu erweitern und Innovationen anzustoßen. Beispielsweise lässt sich Volatility einsetzen, um ein benutzerdefiniertes Webinterface oder ein GUI zu erstellen, eine Malware-Sandbox zu betreiben, eine Introspektion virtueller Maschinen durchzuführen oder einfach den Kernelspeicher automatisch zu untersuchen. Analysten können unter anderem neue Adressräume, Plugins und Datenstrukturen hinzufügen, um das Volatiliy-Framework an die eigenen Erfordernisse anzupassen.

Der bisher erreichte Funktionsumfang des Werkzeugs basiert auf Reverse-Engineering und spezialisierter Forschung zu Datenstrukturen. Volatility bietet Funktionen, die der Microsoft-eigene Kernel-Debugger nicht zulässt, wie beispielsweise die Rekonstruktion von Befehlshistorien, Konsolen-Input/Output-Puffern, User-Objekten (im GUI-Speicherbereich) und netzwerkbezogene Datenstrukturen. Vieles, was nicht dokumentiert ist, kann mit Volatility sichtbar und analysierbar gemacht werden.

Das Tool unterstützt zudem verschiedenste Dateiformate: Volatility analysiert RAW-Dumps, CrashDumps, Hibernation-Dateien, VMware .vmem, VMware gespeicherte Zustands- und Suspended-Dateien (.vmss/. vmsn), VirtualBox-Core-Dumps, LiME (Linux Memory Extractor) sowie „Expert Witness Format“ (EWF) und unterstützt direkt den physischen Speicherzugriff über Firewire. Zusätzlich kann man zwischen diesen Formaten hin und her konvertierten. Das „Advanced Forensics File Format“ AFF4 (www.aff4.org) wird derzeit allerdings nur über zusätzliche Plugins unterstützt.

Schnelle und effiziente Algorithmen ermöglichen es, RAM-Dumps von großen Systemen ohne unnötigen Zeitaufwand und Speicherverbrauch zu analysieren. Beispielsweise ist Volatility in der Lage, Kernelmodule aus einem 64-GB-Hauptspeicherabbild innerhalb weniger Sekunden aufzulisten. Das Zeitverhalten unterscheidet sich je nach Analysebefehl, aber andere Speicheranalyseframeworks benötigen fast immer – meist deutlich – länger (Stunden) oder stürzen während der Analyse ab.

Volatility besitzt einen thematischen Schwerpunkt im Bereich digitale Forensik, Incident-Response und Schadsoftware, da es von Experten aus diesen Bereichen entwickelt wurde, um sich auf die Szenarien konzentrieren zu können, die Analysten typischerweise untersuchen. Infolgedessen existieren Funktionen in Volatility, die vor allem für forensische Analysten oft sehr wichtig sind (nicht-zugeordneter Speicher, indirekte Artefakte etc.). Überdies hilft das große Community-Plugin-Repository (https://github.com/volatilityfoundation/community), wenn es darum geht, noch mehr vorhandene Artefakte aufzuspüren.

Auch ohne eine ausführliche Einarbeitung in Volatility kann man beispielsweise bei Windows-Systemen sehr einfach den „Puls fühlen“ und gegebenenfalls einen Anfangsverdacht anhand existierender Unregelmäßigkeiten auf den Ergebnissen einiger Plugins begründen. Dies ist sehr hilfreich, wenn die Vermutungen noch sehr vage sind. Dazu reichen meistens die Ergebnisse der in Abbildung 2 gezeigten Befehlszeilen aus.

Analyse von Datenträgerabbildern mit The Sleuth Kit / Autopsy

Die Werkzeuge „The Sleuth Kit“ (TSK) und der „Autopsy Forensic Browser“ (kurz: Autopsy, siehe unten) sind für die forensische Analyse von Datenträgerabbildern (sog. Disk-Dumps bzw. dd-Dumps) geeignet (https:// github.com/sleuthkit/). Beide sind für Linux-, Windowsund OSX-Plattformen verfügbar. The Sleuth Kit (TSK) besteht aus einer C-Bibliothek und einer Sammlung von mehr als zwanzig Kommandozeilenwerkzeugen, die Daten und Artefakte von Festplatten und Dateisystemen aufbereiten und analysieren können.

Die TSK-Kommandozeilenwerkzeuge sind in fünf Gruppen organisiert: Dateisystemebene (File System Layer), Dateinamensschicht (File Name Layer), Metadatenschicht (Meta Data Layer), Dateneinheitsschicht (Data Unit Layer – „Dateneinheit“ ist dabei der Oberbegriff in TSK, um sich auf eine Gruppierung aufeinanderfolgender Sektoren zu beziehen) und Dateisystemjournal (File System Journal).

Jede Benennung eines Teilwerkzeugs besteht aus jeweils zwei Teilen, wobei der erste Teil seine Gruppe und der zweite Teil seine Funktion identifiziert. Die Dateisystemebene (fs) enthält die Daten, die das Layout und allgemeine Informationen über ein Dateisystem beschreiben. Zu dieser Schicht gehört das Teilwerkzeug fsstat, das den Bootsektor oder Superblock sowie andere Datenstrukturen liest, die für verschiedene Dateisystemtypen spezifisch sind.

Die Teilwerkzeuge zur Dateinamensschicht (f) verarbeiten hingegen die Strukturen der Dateinamen, die sich typischerweise im übergeordneten Verzeichnis befinden (z. B. ffind und fls). Die Tools der Metadatenschicht (i) befassen sich mit den Strukturen der Metadaten, die Details zu einer Datei speichern (z. B. icat, ifind, ils, istat). Bei den Programmen und Funktionen für die Dateneinheitsschicht (blk) geht es um diejenigen Dateneinheiten, in denen der spezifische Dateiinhalt gespeichert ist (z. B. blkcat, blkls, blkstat und blkcalc).

Die Teilwerkzeuge des Dateisystemjournals (j) verarbeiten die Journale unterschiedlicher Dateisysteme, die vorgenommene Metadaten- (und manchmal auch Inhalts-) Aktualisierungen aufzeichnen (z. B. jcat und jls). Das kann beispielsweise bei der Wiederherstellung kürzlich gelöschter Daten helfen. TSK unterstützt die Dateisystemformate Ext2/3/4 (linux-ext2, linux-ext3, linux-ext4), FAT (fat, fat12, fat16, fat32), NTFS (ntfs) und UFS1/2 (freebsd, netbsd, openbsd, solaris).

Autopsy ist eine grafische Benutzeroberfläche auf Java-Basis, die einen einfachen Zugriff auf die TSKTeilwerkzeuge ermöglicht (https://github.com/sleuthkit/ autopsy/). Das GUI ist intuitiv gestaltet und folgt einem Workflow, der den Fallablauf einer forensischen Analyse unterstützt. Als Hauptmodule jenseits der Funktionen von TSK stellt es noch Funktionen zur Hash-Filterung, Indexierung und Stichwort-Suche, für Web-Artefakte, Data-Carving, Multimedia, „Indicators of Compromise“ (IoCs) und Timeline-Analyse bereit.

Die Kombination der beiden Werkzeuge ergibt sehr umfangreiche Möglichkeiten der Datenaufbereitung. Dabei ist anzumerken, dass gerade bei sehr vielen Dateiobjekten und inkrementeller Aufarbeitung ihrer Metadaten eine leistungsfähige Hardware für die Analysestation ab 32 GB Hauptspeicher von entscheidendem Vorteil für eine möglichst zeitnahe, vollständige Datenaufbereitung ist. Andererseits kann man die Datenaufbereitung aber auch nach eigenen „Ablaufrezepten“ Zug um Zug vornehmen.

Bei Autopsy ist es ebenfalls möglich, den Funktionsumfang deutlich zu erweitern und den eigenen Analyseerfordernissen je nach Szenario anzupassen. Dies geschieht einerseits durch die zentral gepflegten „Autopsy Add-On Modules“ (https://github.com/sleuthkit/ autopsy_addon_modules), zum anderen durch nicht zentral erfasste Add-on-Modules (etwa https://github. com/markmckinnon/Autopsy-Plugins). So ist auch eine Integration von anderen Datenquellen oder -aufbereitungen möglich, die anderen forensischen Werkzeugen entstammen (z. B. Volatility oder Plaso).

Erstellung von Zeitlinien mit Log2timeline und Plaso

Die Analyse von Zeitlinien ist eine der wichtigsten Funktionen, die hilft, schädliche oder auffällige Aktivitäten in Systemen zu finden. Sie ermöglicht dem Analysten etwa, Artefakte aus der Windows-Registrierung, dem Dateisystem und dem Betriebssystem automatisch zu sammeln und in der Reihenfolge ihres Auftretens anzuordnen. Eindringlinge verwenden häufig anti-forensische Techniken, um ihre Spuren im System zu verwischen – aber es ist fast unmöglich, wirklich alle digitalen Spuren zu löschen, da es einfach zu viele davon gibt.

Daten von Zeitlinien sind äußerst nützlich, um die Aktivität von Angreifern oder Effekten zu verfolgen, die noch nicht zuzuordnen sind. Da Zeitinformationen auf der Ebene der Betriebssysteme und innerhalb von Anwendungsressourcen auftreten beziehungsweise erzeugt werden, ist die Verwendung von Verschlüsselung und verdeckten Kanälen nutzlos. Alles, was ein Angreifer durchführt, interagiert mit dem System (Programmcode starten, öffnen, ändern, Dateien löschen etc.) und hinterlässt Datenspuren.

Log2timeline ist ein Werkzeug, das die Zeitstempel aus verschiedenen Datenquellen auf einem IT-System extrahieren und zu einer übergreifenden Zeitlinie (sog. Super-Timeline) zusammenfassen kann. Plaso ist eine Python-basierte Backend-Engine, die von log2timeline zum Erstellen von übergreifenden Zeitlinien verwendet wird (https://github.com/log2timeline/plaso) – ihr Name ist ein Akronym für „Plaso Langar Að Safna Öllu“, was auf Isländisch „Plaso will alles sammeln“ bedeutet.

Das Ziel von log2timeline ist es, ein einziges Tool bereitzustellen, das verschiedenste Protokolldateien, forensische Artefakte und weitere Datenquellen von einem oder mehreren IT-Systemen analysieren kann, um eine einzige korrelierte Zeitachse zu erstellen. Plaso selbst besteht aus Teilwerkzeugen, die Zeitstempel aus einem IT-System sammeln, archivieren und diese aufbereiteten Zeitdaten durchsuchen.

Die wichtigsten Teilwerkzeuge von Plaso sind:

• log2timeline: Dies ist das Hauptprogramm, das verwendet wird, um Ereignisse aus einer Datei, einem Laufwerk/Volume oder einem Datenträgerabbild zu extrahieren und die Ereignisse dann in einer .plaso-Speicherdatei zu speichern
• pinfo: Die .plaso-Speicherdatei enthält Informationen darüber, wie und wann die Datenerhebung stattgefunden hat – pinfo zeigt diese Informationen an
• psort: Damit wird die .plaso-Speicherdatei gefiltert, sortiert und verarbeitet, um Ergebnisse in ein menschenlesbares Format zu konvertieren.

Es gibt zahlreiche Plugins beziehungsweise Parser, um verschiedene Windows-, Registry- und WebhistoryArtefakte zu sammeln – Parser für Linux, Android und OSX sind ebenfalls verfügbar.

Das Erstellen einer allumfassenden übergreifenden Zeitlinie ist eine zeitintensive Aufgabe. Es ist jedoch auch möglich, fokussierte Zeitlinien mit log2timeline zu erstellen, um Daten aus relevanten Datenquellen für einen spezifischen Zeitraum zu sammeln – basierend auf dem jeweiligen Analyseszenario. Diese Methode wird als gezielte Zeitlinienerstellung (Targeted Timeline-Collection) bezeichnet.

Das Ergebnis der Nutzung von Plaso ist ein ZIPkomprimiertes Archiv, das mehrere Dateien enthält. Psort ist das Nachbearbeitungswerkzeug, das diese .plaso-Datei liest und die Ereignisse in chronologischer Reihenfolge extrahiert: Es kann Duplikate entfernen und die Ausgabe in einem für den Menschen lesbaren Format darstellen. Das Ausgabeformat kann in Form verschiedener Datenstrukturen der Typen CSV, JSON, MySQL oder SQLite gewählt werden. Die resultierenden Daten kann man anschließend zur Analyse beispielsweise in Autopsy importieren.

Fazit

Nachdem das prozessorientierte Vorgehen gemäß NIST SP 800-61 pragmatisch den Weg für eine funktionierende Security-Incident-Response weist, ist es Aufgabe der Unternehmensleitungen dafür zu sorgen, dass auch die weiteren Schritte (4. Eindämmung / 5. Beseitigung / 6. Wiederherstellung / 7. Nachbearbeitung) mit Inhalten gefüllt und im Unternehmen erprobt werden.

Eine sinnvolle Auswahl an Basis-Werkzeugen ist zielführend, um zu starten – aber es gilt die alte Weisheit: „A fool with a tool is still a fool.“ Daher bleibt Unternehmen und sonstigen Organisationen nur der Weg in einen adaptiven und kontinuierlichen Lernprozess, um bei Vorfällen agieren zu können und nicht reagieren zu müssen.

Der Autor und die Redaktion planen für zukünftige Ausgaben der eine Reihe von „Workshop“-Beiträgen, die den Einsatz von Open-Source-Werkzeugen in der digitalen Forensik genauer behandeln, um diesen Lernprozess zu unterstützen.

Jochen Schlichting (CISA, CISM, Auditteamleiter auf Basis von IT-Grundschutz) arbeitet als Consultant bei der Secorvo Security Consulting in Karlsruhe (jochen-schlichting@sercovo.de).

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), IT-Grundschutz-Kompendium, Bausteine „DER: Detektion und Reaktion“, www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/bausteine/DER/DER_Uebersicht_node.html

[2] National Institute of Standards and Technology (NIST), Computer Security Incident Handling Guide, NIST Special Publication 800-61 Revision 2, August 2012, https://doi.org/10.6028/NIST.SP.800-61r2