Embed Size (px)
Citation preview
Hochschule Wismar
University of Technology, Business and Design
Fakultät für Ingenieurwissenschaften
IT-Forensik-Projekt II
Malware-Spurensuche im Arbeitsspeicher
unter Verwendung des Analyse-Instruments Rekall
Eingereicht am: 29.07.2019
von: Anja Kutzner
Robert Utzig
Tobias Koehler
Studiengang: IT-Forensik
Betreuerin: Prof. Dr.-Ing. Antje Raab-Düsterhöft
Aufgabenstellung
In dieser Projektarbeit werden die volatilen Daten eines mit der Malware
WannaCry infizierten Arbeitsspeichers untersucht. Dabei wird das
Analyse-Instrument Rekall und eine Erweiterung des Opensource Projekts
Memory Analyzer eingesetzt.
Methodisch soll diese Suche nach digitalen Spuren als formeller
memory-forensischer Untersuchungsprozess durchgeführt werden. Die
Spurensicherung wird dabei nach den Vorgaben des Bundesamt für Sicherheit
in der Informationstechnik in Verlaufs- und Ergebnisprotokollen dokumentiert.
Dabei steht die Frage im Mittelpunkt, ob Spuren der Malware WannaCry in
einer definierten Laborumgebung durch die Instrumente Rekall und Memory
Analyzer nachgewiesen werden können.
2
Kurzreferat / Abstract
Die fortschreitende Digitalisierung wirtschaftlicher und privater Prozesse
unserer Gesellschaft bringt zunehmende Risiken von kriminellen Angriffen auf
informationstechnische Systeme mit sich. Ein großer Teil dieser Gefahren geht
von Malware-Angriffen aus für deren strafrechtlich relevantem Nachweis
konkrete Vorgehensweisen eingehalten werden müssen. Diese Arbeit
beschreibt sowohl kriminalistisch als auch technisch zu berücksichtigende
Aspekte einer it-forensischen Untersuchung, die als Gegenstand einen
Malware-Angriff auf den volatilen Arbeitsspeicher eines Computersystems hat.
Durch den Einsatz des Analysetools Rekall wird an einem mit der Malware
Wannacry infizierten RAM Modul ein exemplarischer Untersuchungsprozess
von der Datensicherung bis zur Dokumentation der Analyse durchgeführt.
The continuing development of the digitization process on economic and private
sectors of our society implies an increasing risk of criminal attacks against
information systems. A significant portion of such risks arise from malware
attacks, what leads to certain requirements regarding their criminal persecution.
This paper describes criminal and technical aspects of a computer forensic
investigation in case a malware attack against a volatile main memory has
happened. An exemplary evaluation of a Wannacry malware attack in use of
the memory forensic framework Rekall is described from the data protection to
the investigation report.
3
Aufgabenstellung 2
Kurzreferat / Abstract 3
1. Einleitung 6
2. Definition und Eigenschaften von Malware 9 2.1 Definition und Klassifikation von Malware 9 2.2 Verhalten von Malware 11 2.3 Methoden zur Malware Analyse 14
3. Forensische Sicherung digitaler Spuren 16 3.1 Merkmale der digitalen Spurensicherung 16 3.2 Anforderungen an die Sicherung digitaler Spuren 18 3.3 Der memory-forensische Untersuchungsprozess 19 3.4 Die Dokumentation 23
4. Sicherungstechniken volatiler Daten 25 4.1 Hardwarebasierte Techniken 25 4.2 Softwarebasierte Techniken 26 4.3 Cold Booting Techniken 28
5. Malware Analyse in der Memory-Forensik 30 5.1 Aufbau der Windows-Prozess-Struktur 30 5.2 Prozesse und Threads 34 5.3 Packing und Compression-Analyse 37 5.4 Code Injection 38 5.5 Netzwerkanalyse 40
6. Durchführung der praktischen Memory-Analyse 42 6.1 Das Labor Szenario 42 6.2 Die Malware Wannacry 47 6.3 Das Analyseinstrument Rekall 49 6.4 Das Analyseinstrument Memory Analyser 52 6.5 Das Verlaufsprotokoll 55 6.6 Das Ergebnisprotokoll 67
7. Fazit 71
4
Literaturverzeichnis 73
Abbildungsverzeichnis 77
Tabellenverzeichnis 78
Anlagenverzeichnis 79
Selbstständigkeitserklärung 96
5
1. Einleitung
“IT-Forensik ist die streng methodisch vorgenommene Datenanalyse auf
Datenträgern und in Computernetzen zur Aufklärung von Vorfällen unter
Einbeziehung der Möglichkeiten der strategischen Vorbereitung insbesondere
aus der Sicht des Anlagenbetreibers eines IT-Systems.” 1
Dabei umfasst die Wissenschaft der IT-Forensik (engl.: Computer Forensic)
viele verschiedene IT-Bereiche: “Computer Forensic is a large area and is
classified in many ways.” und wird u.a. in die folgenden Disziplinen unterteilt: 2
● Festplatten-Forensik
● Memory-Forensik
● Smartphone-Forensik
● Registry-Forensik
● Netzwerk-Forensik
● Datenbank-Forensik
Gegenstand aller IT-forensischen Auswertungen sind digitale Daten, die zur
weiteren Aufarbeitung in ein prozessual verwendbares Beweismaterial
umgewandelt werden müssen. Im Falle eines Cyber-Angriffs wird generell das 3
gesamte Computersystem auf digitale Spuren untersucht. In dieser Arbeit
befassen wir uns mit Malware Angriffen, die im Jahre 2018 insgesamt 57% der
gemeldeten Cyber-Angriffe in deutschen IT-Unternehmen ausmachten:
1 BSI, Bundesamt für Sicherheit in der Informationstechnik: Leitfaden „IT-Forensik“, 2011. 2 Chhetri, Amrit, 2015. Kapitel 6 3 Wernert, 2017. S.108
6
Abbildung 1: Übersicht der Cyberangriffe im Jahr 2018 in Deutschland 4
Malware kann ein Computersystem auf verschiedene Arten befallen, wobei
Malware Attacken auf den Arbeitsspeicher (RAM) zu den unauffälligsten und
zugleich gefährlichsten Cyber-Angriffen zählen.
“Malware can be completely memory resident. Rather than debate the
differences between viruses, worms, trojans, etc., it is sufficient to say that
malware can exist completely in RAM.” 5
Die Analyse von nicht-persistenten Daten eines Arbeitsspeichers wird den
Methoden der forensischen Disziplin Memory Forensik (auch: Arbeitsspeicher
Forensik, engl.: Memory Forensics, Memory Analysis) zugeordnet: “Memory
forensics is forensic analysis of a computer’s memory dump. Its primary
application is investigation of advanced computer attacks which are stealthy
4 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2018.pdf 5 Vidas, 2010. S. 7
7
enough to avoid leaving data on the computer's hard drive. Consequently, the
memory (RAM) must be analyzed for forensic information.” 6
Zu Beginn dieser Arbeit wird zunächst die Begrifflichkeit und Klassifikation von
Malware erläutert. In Kapitel 3 erfolgt eine formelle Beschreibung digitaler
Spuren als auch ermittlungstechnischer Anforderungen an deren Sicherung.
Zudem wird die Notwendigkeit einer lückenlosen Dokumentation während des
memory-forensischen Untersuchungsprozess verdeutlicht. Die konkreten
Möglichkeiten von Sicherungstechniken volatiler Arbeitsspeicher werden in
Kapitel 4 aufgezeigt. Im Anschluss dazu werden verschiedene
Analysemethoden für die Untersuchung eines Arbeitsspeichers im Rahmen
einer Malware-Analyse vorgestellt.
Abschließend wird in Kapitel 6 eine exemplarische Analyse eines mit der
Malware Wannacry infizierten Arbeitsspeichers durchgeführt und in Verlauf und
Untersuchungsergebnis dokumentiert.
6 https://en.wikipedia.org/wiki/Memory_forensics
8
2. Definition und Eigenschaften von Malware
2.1 Definition und Klassifikation von Malware
Der Begriff Malware stammt aus dem Englischen: “malware” heisst zu deutsch
bösartig und der Begriff “Software” bezeichnet ein Computerprogramm. “Der
Begriff subsumiert jegliche schädliche Software, die mit und ohne Wissen des
Nutzers auf dessen System übertragen und/oder ausgeführt wird” . 7
Das bedeutet Malware ist keine fehlerhafte Software, sondern ist gezielt erstellt
worden, um konkrete Sicherheitslücken und mangelhafte
Informationsarchitekturen zum gezielten Angriff auf Computersysteme
auszunutzen. Malware kann als Executable, Skripte, Code oder anderen 8
Softwareformen gestaltet sein und gelangt in aller Regel ohne die Zustimmung
über die Kommunikationskanäle wie Email, Web oder USB Sticks in das
Zielsystem. Maliziöse Aktionen auf dem infizierten Zielsystem reichen von der 9
Beeinträchtigung von Regelprozessen, des Diebstahls von sensiblen
Informationen, des Ausspionierens des Opfers bis hin zu Distributed Denial of
Service Attacken (DDOS) auf andere Systeme. 10
Grundsätzlich werden unter dem Begriff Malware verschiedene Arten von
Schadprogrammen wie Trojanern, Viren, Würmern und Rootkits summiert. In
der praktischen Durchführung der Malware Analyse ist es hilfreich diese
Programme zu klassifizieren: 11
● Viren und Würmer
● Trojaner
● Backdoor und Remote Access Trojaner (RAT)
7 Wernert, 2017. S.207 8 https://de.wikipedia.org/wiki/Schadprogramm 9 Monnappa, 2018. S. 7 10 https://en.wikipedia.org/wiki/Denial-of-service_attack 11 Monnappa, 2018. S. 7
9
● Adware
● Botnet
● Information Stealer
● Ransomware
● Rootkit
● Downloader oder Dropper
Für die Wahl und die Programmierung einer Malware für eine Malware-Klasse
steht das Ziel des Programmierers und des Angreifers im Mittelpunkt. Verfolgt
der Autor das Ziel “Infizieren”, soll die Malware auf dem Zielsystem ausgeführt
werden oder eine Sicherheitslücke ausnutzen. Das Ziel “Nutzen durch
Schaden” wird ebenfalls durch die Ausführung bestimmter Funktion auf dem
gewünschten System ausgeführt. Hier stehen monetäre, persönliche oder
politische Motive für den Angreifer im Vordergrund. Damit dieser Nutzen
möglichst lange erhalten bleibt und auch keine Rückschlüsse auf den Angreifer
oder den Malware Autor möglich sind, muss die Malware “Unerkannt bleiben”.
Hierbei sollen die infizierten Systeme und Analysen möglichst wenig
Informationen über die Malware enthalten. Sobald eine größere Anzahl an
Zielsystemen oder Benutzergruppen mit der Malware erreicht werden soll, muss
der Autor die Malware mit Replikationsmöglichkeiten zum “Vervielfältigen” der
Malware ausstatten.
Es muss angemerkt werden, dass ein singulärer Schadcode nicht immer
eindeutig klassifiziert werden kann. Es kann mehrere Funktionalitäten und
Malware-Verhalten erfüllen. Beispielsweise kann eine Malware eine
Wurmkomponente beinhalten, die ein Netzwerk nach Verwundbarkeiten scannt
und eine weitere Komponente wie Backdoor oder Ransomware im Zielsystem
absetzt. Dieses Malware-Verhalten ist für die anschließende Analyse von
enormer Bedeutung.
10
2.2 Verhalten von Malware
Die Einordnung von Malware erfolgt nach deren Funktion und Angriffsvektoren -
dem Malware-Verhalten. Für einen guten Überblick seien den definierten
Klassen aus Punkt 2.1 in einem kurzen Satz das spezifische Verhalten
zugeordnet:
Klassifikation Malwareverhalten
Viren oder Würmer ... kopieren sich selbst und verteilen sich somit auf andere Computer. Virus verteilt sich nur mit User Eingriffen; Würmer ohne User Eingriffe... 12
Trojaner … verkleiden sich als reguläre Programme. Installiert führen sie maliziöse Aktivitäten wie Informationsspionage, Übertragung von Dateien oder Überwachung über Webcams durch.
Backdoor / Remote Access Trojaner (RAT)
… ist ein trojanisches Pferd, dass Zugang zum System gewährt, um Kommandos auf dem kompromittierten System auszuführen
Adware … präsentiert nicht-gewollte Werbung, um den User zum Download / Installation einer Software zu verleiten. 13
Botnet … ist eine Gruppe von Computern mit gleicher Schadsoftware, die darauf warten von einem Kontrollserver Anweisungen für die Durchführung maliziöser Aktivitäten wie Spammails oder DDOS Attacken durchzuführen.
Information Stealer … ist designed, um sensible Informationen wie Bankdaten oder Tastatureingaben abzugreifen. Dies umfasst Keyloggers, Spyware, Sniffer und Form Grabber
Ransomware … hält System als Geisel und sperrt beispielweise User aus eigenem System oder verschlüsselt ihre Dateien gegen Lösegeldforderung.
Rootkit … erlaubt dem Angreifer privilegierte Rechte und verbirgt die Präsenz von Malware.
12https://digitaler-mittelstand.de/technologie/ratgeber/viren-trojaner-und-co-5-malware-arten-49985 13 https://www.kaspersky.de/resource-center/threats/malware-classifications
11
Downloader oder Dropper … sind dafür gebaut zusätzliche Malwarekomponenten zu downloaden oder zu installieren.
Tabelle 1: Übersicht der Klassifikation Malware
Natürlich verändern sich diese Programme sehr schnell. Daher sei der Leser für
einen umfassenden aktuellen Überblick über diese Funktionen an dieser Stelle
auf https://blog.malwarebytes.com/glossary/ verwiesen.
Mit diesen unterschiedlichen Verhaltensweisen und -mustern sind natürlich
bestimmte Bedrohungspotentiale verbunden. Dies reicht von kleinem Diebstahl
bis hin zur Zerstörung ganzer Anlagen und umfasst außerdem die Beständigkeit
einer Malware auf einem System und die Fähigkeiten zum Spurenverwischen
des Schadcodes.
Kaspersky Lab klassifiziert auf Basis dieses Bedrohungsverhalten sämtliche
von der Kaspersky-Antiviren-Engine erkannte Malware. Es weist jedem Objekt
eine Verhaltensbeschreibung und eine damit verbundene Position im
Klassifikationsbaum zu: 14
14 https://www.kaspersky.de/resource-center/threats/malware-classifications
12
Abbildung 2: Kaspersky’s Klassifikationsbaum von Malware
Die Verhaltensweisen mit einem geringeren Bedrohungspotential werden dabei
im unteren Bereich (blau) dargestellt. Mit zunehmenden Rot-Anteil im oberen
Teil des Klassifikationsbaumes nimmt das Bedrohungspotential durch das
Malwareverhalten zu. Dieser Kaspersky Klassifikationsbaum stellt im Rahmen
der Malware-Analyse insbesondere bei der Identifikation einer unbekannten
Malware auf einem infizierten System eine wertvolle Basis dar und wird daher
auch von einer Reihe anderer Antiviren-Anbieter als Grundlage genutzt.
13
2.3 Methoden zur Malware Analyse
Grundsätzlich befasst sich die Malware Analyse mit der Untersuchung des
Verhaltens von Schadcode. Dabei bestimmen die Ziele der Verständnis
Gewinnung über die Fähigkeiten der Funktionalitäten, der Entdeckung im
Zielsystem und schlussendlich der Eliminierung von Schadcode auf dem
System die Durchführung und die Methodik der Untersuchung. Es unterstützt 15
die Zweckbestimmung und das Verstehen der Auswirkungen auf ein
kompromittiertes System. Weiterhin werden Netzwerkindikatoren in Verbindung
mit dem Schadcode identifiziert, um vergleichbare Angriffe aufzudecken. Zum 16
Beispiel, wenn eine bestimmte IP Adresse während der Analyse entdeckt wird,
kann man diese IP Adresse für eine Netzwerksignatur nutzen, um den Traffic
aufzuzeichnen. Dies ermöglicht die Identifikation aller Hosts, die diese IP
Adresse kontaktieren. Ein weiteres Beispiel ist die Auswertung von
Host-basierten Signaturen, wie Dateinamen oder Registry Keys, die von
bestimmten Schadprogrammen genutzt werden. Dies ermöglicht es
vergleichbare Systeminfektionen festzustellen. 17
Grundsätzlich für das Verständnis der Motive und Charakteristiken von Malware
stehen verschiedene Analysetechniken zur Verfügung:
● In der statischen Analyse wird eine Anwendung analysiert ohne das sie
ausgeführt wird. Insbesondere die Metadaten können damit gut
extrahiert werden. Für die Bestimmung der Vorgehensweise der
anschließenden tiefergehende Analyse wird die einfache statische
Analyse genutzt. 18
● Bei der dynamischen Analyse wird der verdächtige Schadcode in einer
isolierten Debugger Umgebung (zum Beispiel IDA Pro) ausgeführt und
und auf Laufzeitverhalten untersucht. Diese Analyse ist einfach
15 Monnappe, 2018. S. 8 16 Sikorski, Honig, 2012. S. 2 17 Monnappe, 2018. S. 9 18 Monnappe, 2018. S. 25 ff.
14
durchzuführen und gibt wertvolle Hinweise auf das Verhalten der
Malware, deckt allerdings nicht alle maliziösen Funktionalitäten
vollständig auf. 19
● Die aufwändigere Code Analyse richtet den Fokus auf die Untersuchung
des Source Code des Schadprogramms, um das Innenleben und die
Funktionalität zu untersuchen. Diese Analyse ist sowohl statisch als auch
dynamisch durchführbar und liefert einen tiefen Einblick in die
Funktionalität des Schadcodes. Über das so genannte Reversing, also
die Ausführung eines Dissassembler wie IDA Pro , Radare oder 20 21
Ghidra , wird der Code systematisch kontrolliert analysiert, um 22
Anomalien und typische Strukturen zu verstehen. Code Analyse verlangt
ein gutes Verständnis der eingesetzten Programmiersprache und des
Betriebssystems. 23
● Die Technik der Memory Analyse (oder Memory Forensik) wird
grundsätzlich eingesetzt, um den Arbeitsspeicher (RAM) eines
Computers auf forensische Artefakte zu untersuchen. Diese Techniken
lassen sich in die Malware Analyse integrieren und ermöglichen ein
tiefgreifendes Verständnis des Verhaltens der Malware nach der
Infizierung. Weiterhin ist die Memory Forensik geeignet die
Verschleierung und die Ausweichressourcen einer Malware zu
bestimmen. 24
Grundsätzlich wird in einer Malware-Analyse eine integrierte Vorgehensweise
aus verschiedenen Analysetechniken in Abhängigkeit nach Untersuchungsziel
und der Malware-Eigenschaften aufgesetzt. Für die weiteren Ausführungen in
der vorliegenden Arbeit wird die Malware-Analyse auf die Techniken der
Memory-Forensik konzentriert.
19 Monnappe, 2018. S. 68 ff. 20 https://www.hex-rays.com/products/ida/ 21 https://rada.re/r/ 22 https://ghidra-sre.org/ 23 Monnappe, 2018. S. 96 ff. 24 Monnappe, 2018. S. 373 ff.
15
3. Forensische Sicherung digitaler Spuren
3.1 Merkmale der digitalen Spurensicherung
Die Sicherung kriminalistisch relevanter Spuren dient juristisch dem
Sachbeweis für eine Tat, einer Täterschaft oder den Tat-Umständen. Somit ist
sie ein wichtiger Bestandteil innerhalb des forensischen Ermittlungsprozess. 25
Dazu gehören die Spurensuche, die Spuren-Erfassung und die
Spurenauswertung. Im Mittelpunkt der Spurensicherung steht dabei das
Bewahren der verfügbaren Spuren und ihr Schutz vor äußeren Einflüssen. Dies
gilt für alle Arten von Spuren (physikalisch wie digital) insbesondere dann,
wenn das zu untersuchende Material unwiederbringlich ist.
Zur Begrifflichkeit von digitalen Spuren (digital evidence) verwenden wir die
Definition von Casey: digitale Spuren sind Spuren, die auf Daten basieren,
welche in Computersystemen gespeichert oder übertragen wurden. Hieraus 26
ergibt sich ein wesentlicher Unterschied von digitalen zu physischen Spuren:
sie sind mit dem bloßem Auge nicht sichtbar für den Betrachter. Demzufolge ist
eine besondere Aufbereitung der digitalen Spuren notwendig, um sie einer
Analyse unterziehen zu können. Zur Klassifizierung von digitalen Spuren ist es
hilfreich ihre Eigenschaften genauer zu betrachten: 27
● Flüchtigkeit von Spuren (Volatilität von Spuren): Eine Einschätzung der
Persistenz von digitalen Spuren ist zwingend notwendig, da dies die
Dringlichkeit der Untersuchung sowie die Wahl der it-forensischen
Werkzeuge erheblich beeinflusst. Man unterscheidet zwischen drei Arten
von Persistenz: persistente digitale Spuren bleiben auch ohne
Stromzufuhr erhalten, wogegen semi-persistente Spuren eine
durchgängige Stromzufuhr benötigen um langfristig erhalten zu bleiben.
25 https://de.wikipedia.org/wiki/Spurensicherung 26 Casey, 2004. S.12 27 Dewald, Freiling, 2016. S. 32
16
Ein Beispiel hierfür ist der Inhalt des Arbeitsspeichers (RAM) eines
Computers. Flüchtige Spuren bleiben auch bei Stromzufuhr nur zeitlich
begrenzt erhalten ( z.B. Netzwerkdaten oder Inhalte von
Prozessorregistern). Insgesamt gilt der Grundsatz: Je “flüchtiger” die
Spuren sind, desto schneller sollte man sie sichern. 28
● Vermeidbarkeit von Spuren: Hier wird die Entstehung von digitalen
Spuren in zwei Gruppen unterteilt: zum einen gibt es die “technisch
vermeidbaren Spuren, die um ihrer selbst Willen erzeugt werden” . Dem 29
gegenüber stehen die technisch unvermeidbaren Spuren, “die
unweigerlich anfallen und daher nicht durch einfache Änderungen an der
Konfiguration eines Systems vermieden werden können”. Für die 30
it-forensische Analyse ist vor allem die zweite Kategorie interessant, da
sie nicht vorsätzlich manipuliert sein können, also eine hohe
Glaubwürdigkeit mitbringen.
● Manipulierbarkeit von Spuren: Es findet eine Einschätzung statt mit
welcher Wahrscheinlichkeit die gefunden Spuren vorsätzlich mit
anti-forensischen Techniken manipuliert sein könnten zu dem Zweck 31
forensische Maßnahmen präventiv zu verhindern.
● Kopierbarkeit von Spuren: Das wichtigste Merkmal dieser Eigenschaft ist
die Gewährung von Integrität , d.h. es dürfen durch den Kopiervorgang 32
keine Veränderungen an den zu analysierenden Daten erfolgen.
● Semantik von Spuren: Es wird eine formelle Einordnung der
vorliegenden digitalen Spuren vollzogen, die richtungsweisend für die
spätere Untersuchung ist. Dewald,Freiling unterscheiden zwischen den
Datentypen bezüglich ihrer Semantik: Primärdaten (Daten, zu deren
Anwendung Applikationen bereitstehen), Sekundärdaten (Daten, mit
denen Primärdaten einfach verarbeitet werden können), Programmdaten
28 Brezinski, Killalea, 2002. S. 6 29 Dewald, Freiling, 2016. S. 34 30 Dewald, Freiling, 2016. S. 34 31 Wernert, 2017. S.203 32 Wernert, 2017. S.108
17
(die ausführbaren Anwendungen), Konfigurationsdaten (Steuerdaten für
die Anwendung von Primärdaten) und Logdateien (Protokolle über das 33
Verhalten von Anwendungen). 34
3.2 Anforderungen an die Sicherung digitaler Spuren
Im Sinne der IT-Forensik muss - analog zu forensischen Prozessen in der
physischen Welt - prinzipiell nach Spuren gesucht werden, die eine aufgestellte
Versionen zu Tat, Täterschaft oder Tatumstände untermauern oder diese auch
widerlegen. An die forensische Untersuchung eines Arbeitsspeichers und die 35
damit verbundenen Instrumente, werden besondere Anforderungen gestellt, um
eine spätere Gerichtsverwertbarkeit sicherzustellen: 36
● Akzeptanz: insbesondere die schnellen Veränderungen im digital
analytischen Umfeld gestalten den Markt für forensische
Auswertungsinstrumente volatil. Prinzipiell ist der Einsatz neuer
Instrumente nicht ausgeschlossen, allerdings sollte die angewandte
Methode von der Fachwelt akzeptiert sein.
● Glaubwürdigkeit: ein Nachweis für die Robustheit und Funktionalität der
eingesetzten Methode muss erbracht werden.
● Wiederholbarkeit: bei gleicher Ausgangssituation und eingesetzten
Methoden und Hilfsmittel müssen bei wiederholter Anwendung die
gleichen Ergebnisse reproduzierbar sein.
● Integrität: während der Untersuchung dürfen die Spuren weder bemerkt
noch unbemerkt verändert worden sein. Die Sicherung der Integrität
digitaler Beweise muss jederzeit belegbar sein.
● Ursache und Auswirkungen: es muss möglich sein durch die
ausgewählte Methode logisch nachvollziehbare Verbindungen zwischen
Spuren, Ereignissen und gegebenenfalls Personen herzustellen.
33 Wernert, 2017. S.207 34 Dewald, Freiling, 2015. S. 41 35 BSI, 2011. S. 22 36 Geschonnek, 2014. S. 143
18
● Dokumentation: jeder Schritt des Ermittlungsprozesses muss
angemessen dokumentiert sein. Die Authentizität der Daten und das
Vorgehen des Forensikers muss gewährleistet sein. Weiterhin umfasst
die Dokumentation die Ergebnisse der unternommenen Einzelschritte
innerhalb des gesamten forensischen Untersuchungsprozess im Sinne
eines lückenlosen Nachweis in Form einer Chain of Custody (siehe
Kapitel 3.4).
3.3 Der memory-forensische Untersuchungsprozess
Ein Prozess Modell (engl. Process Model) beschreibt wie über
Untersuchungsmethoden gedacht, diskutiert und einzelne Prozeduren im
Rahmen eines digitalen Untersuchungsprozess implementiert und dokumentiert
werden. Zudem werden die einzelnen Erkenntnisse des 37
Untersuchungsprozesses stetig reflektiert um die angewandten Techniken
gegebenenfalls aufeinander abzustimmen. Für it-forensische Untersuchungen
bieten sich folgende Prozessmodelle an:
● Das “Investigative Process Model” wurde als Casey Modell von Eoghan
Casey beschrieben und besteht aus zwölf einzelnen, chronologischen
Prozesschritten, die sehr dediziert von der Feststellung eines
Verbrechens bis zur Interpretation die gesamte it-forensische
Untersuchung von unten nach oben strukturieren. 38
37 Walters, Petroni, 2012. S. 2 38 Casey, 2004. S. 123
19
Abbildung 3: Das Investigative Process Model nach Casey 39
● Das “S-A-P Modell” bestehend aus den Phasen Secure, Analyze and 40
Present ist insbesondere für die Incident Response Beweissicherung
entwickelt worden und fasst einige der Phasen vergleichbarer
Prozessmodelle einfacher und kompakter zusammen.
● Der Integrated Digital Investigation Process (IDIP) wurde von Brian
Carrier und Eugene Spafford im Jahre 2003 im Ursprung entwickelt und
bettet die it-forensischen Untersuchung in den gesamthaften
Untersuchungsprozess ein. Vergleichbar einer physischen 41
Spurensicherung liefert demnach ein digitaler Tatort unterschiedliche
Arten von Beweisen aus denen ein digitales Tatumfeld rekonstruiert
werden kann:
39 Casey, 2004. S. 125 40 https://de.wikibooks.org/wiki/Disk-Forensik/_Richtlinien/_Das_SAP-Modell 41 Carrier, Spafford, 2002. S. 17
20
Abbildung 4: IDIP Modell nach Carrier und Spafford 42
Der Block Digital Crime Scene wird dabei in die Prozessphasen Preservation -
Survey - Search - Reconstruction - Presentation unterteilt. Für eine Vertiefung
dieser einzelnen Phasen wird an dieser Stelle verzichtet und der Leser auf den
Beitrag von Florence Tushabe für die Digital Forensic Conference im Jahr 2004
verwiesen. Für die weiterführenden Ausführungen wird auf die wesentlichen 43
Aspekte dieses Prozesses an der entsprechenden Stelle punktuell
eingegangen.
Die erste Maßnahme ist die Sicherung der digitalen Spuren in der Preservation
Phase. Die angewandten Verfahren dazu lassen sich grob in zwei Gruppen
einteilen : 44
1. Die Post-Mortem-Sicherung: Die Computersysteme werden in einem
statischen Zustand gesichert, d.h. nach Abschalten der Stromzufuhr.
2. Die Live-Sicherung: Die Computersysteme werden in einem laufenden
Zustand gesichert, die Stromzufuhr bleibt dabei durchgängig.
Der volatile Arbeitsspeicher eines Computersystems ist ein schwieriger
Untersuchungsaspekt des digitalen Tatortumfelds. Insbesondere die Sicherung
von flüchtigen Memory Daten vervollständigt den digitalen Tatortbefund und
42 Tushabe, 2004. S. 3 43 Tushabe, 2004. S. 4 44 Heinson, 2015. S.26
21
ermöglicht eine schnelle Identifikation von Untersuchungsobjekten in der
Survey Phase auf Basis gesicherter Beweise. Dies umfasst beispielsweise
Login Daten einzelner Nutzer, Prozesse, Threads , Netzwerkverbindungen 45 46
und Open Files . Die Sicherung dieser flüchtigen Daten und die anschließende 47
Analyse ermöglichen in beiden Fällen - der kriminalistischen
Tatortuntersuchung und der Incident Response - einen Einblick in den 48
Zustand des zu untersuchenden Systems und schafft mögliche Synergien zur
Untersuchung persistenter Daten Untersuchungen. Eine Ausnahme hierbei ist 49
die Live-Sicherung, da hier der digitale Tatort nicht “abgesichert” werden kann,
potentielles Beweismaterial aber trotzdem weiter gesammelt wird. In diesem 50
Fall beginnt die Untersuchung (Survey) also bereits während des Vorfalls, um
flüchtige Spuren zu finden, zu speichern und anschließend zu untersuchen.
Gegenstand von Live-Sicherungen sind häufig Inhalte von Arbeitsspeichern,
sowie Informationen zu bestehenden Netzwerkverbindungen oder über
gestartete Prozesse. 51
Oft werden Post-Mortem-Sicherung und Live-Sicherung auch miteinander
kombiniert. Dies ist beispielsweise in der Memory-Forensik der Fall, wenn ein
semi-flüchtiger Arbeitsspeicher untersucht werden soll. Der Vorgang des
Auslesens des Speichers ist eine Live-Sicherung, wogegen das durch den
Auslesevorgang gewonnene Abbild anschließend einer Post-Mortem-Analyse
unterzogen wird.
Anschließend werden die sichergestellten digitalen Spuren einer
Charakterisierung unterzogen. Im Rahmen einer Identifizierung werden die
Spuren zunächst auf ihre Tauglichkeit als Beweismittel überprüft. Zudem
45 https://de.wikipedia.org/wiki/Prozess_(Informatik) 46 https://de.wikipedia.org/wiki/Thread_(Informatik) 47 https://www.com-magazin.de/tipps-tricks/windows-7/openfiles-befehl-verwenden-14185.html 48 https://www.computerweekly.com/de/definition/Vorfallreaktionsplan-Incident-Response-Plan-IRP 49 Osborne, 2013. S. 8 50 Walters, Petroni, 2012. S. 4 51 BSI, 2011. S. 13
22
werden die erwähnten Klassifikationen der Spuren hinsichtlich möglicher
Parallelen betrachtet. Ebenfalls hilfreich ist die Überprüfung auf
Individualisierungen. Damit sind individuelle Merkmale gemeint (z.b. Namen
oder Laufzeit von Prozessen), welche auf einen Zusammenhang der Beweise
zueinander hinweisen. Auf Basis dieser Untersuchungen wird die Möglichkeit
einer Assoziation zwischen Spur X und Spur Y ermittelt. Überprüft man alle
vorhanden digitalen Spuren auf diese Art, lässt sich die Anzahl der
verdächtigen Spuren eingrenzen. Es handelt sich also um eine selektiven
Prozess, der die forensische Analyse zeitlich und technisch vereinfachen kann.
Die Informationsselektion in dem Umwandlungsprozess von digitalen Spuren zu
Beweismitteln birgt allerdings zugleich allerdings das Risiko der Reduktion,
bzw. des Informationsverlustes. Dies ist insbesondere der Fall wenn die
Umwandlung durch automatische Prozesse erfolgt. 52
3.4 Die Dokumentation
Der lückenlosen Dokumentation der Datensicherung in einem
kriminaltechnischen Verfahren im Rahmen eines Ersten Angriffs (Sicherungs-
und Auswertungsangriffs) kommt besondere Bedeutung zu. Eine solche 53
Dokumentation umfasst die Person (Wer) die die Spur gesichert hat, mit
welchem Verfahren (Womit) die Spur gesichert wurde und welcher
Spurenträger vorlag. Zudem sollte die Dokumentation eine lückenlose 54
Beweismittelkette (engl. Chain of Custody) wiederspiegeln, in der der Fluss von
Spuren bis zur Erbringung eines Beweismittels festgehalten ist. Dadurch wird
die Nachvollziehbarkeit, die Prüfung der Authentizität und die Integrität
zukünftiger Beweismittel gewährleistet. 55
52 Wernert, 2017. S.108 53 Ackermann, Clages, Roll, 2019. S. 133 54 Ackermann, Clages, Roll, 2019. S. 130 55 https://de.wikipedia.org/wiki/Beweismittelkette
23
Unabhängig davon, welches Prozessmodell für die Durchführung der Ermittlung
zugrunde gelegt wird, nimmt die Dokumentation zwei Aufgaben wahr: 56
1. Erstellung eines Verlaufsprotokolls, in dem alle Abläufe und Ergebnisse
während der laufenden Untersuchung dokumentiert werden. Die Form
dieses Protokolls ist immer gleich und gibt einen umfassenden Überblick
über die durchgeführten Maßnahmen. In vielen modernen forensischen
Analysewerkzeugen wie beispielsweise EnCase wird dieses 57
Verlaufsprotokoll automatisch generiert.
2. Von dem erstellten Verlaufsprotokoll wird ein Ergebnisprotokoll
abgeleitet, welches die gewonnenen Daten interpretiert, anschaulich
aufbereitet und zugänglich gemacht werden.
Das Bundesamt für Sicherheit in der Informationstechnik hat im Leitfaden 58
IT-Forensik aus dem März 2011 detaillierte Vorgehensmodelle für einige
ausgewählte Cyber-Vorfall Szenarien beschrieben. Dabei werden ein 59
fall-spezifisches Verlaufs- und Ergebnisprotokoll exemplarisch im
Ermittlungsprozess zugeordnet. Für weiterführende Information sei an dieser
Stelle auf diesen Leitfaden verwiesen. 60
56 BSI, 2011. S. 91 57 https://www.guidancesoftware.com/encase-forensic 58 https://www.bsi.bund.de/DE/Home/home_node.html 59 BSI, 2011, S. 234 ff. 60 vgl. BSI, 2011. S. 244, 253, 256, 261, 268, 275, 283, 297
24
4. Sicherungstechniken volatiler Daten
Die Sicherung von volatilem Speicher erfolgt über die Kopie flüchtiger Daten
aus dem Arbeitsspeicher in eine persistente Speicherungsform. Hierfür 61
werden hardware- und software-basierte Instrumente genutzt an deren
Korrektheit hohe Anforderungen bezüglich Verfügbarkeit, Glaubwürdigkeit und
Genauigkeit gestellt werden. Vor allem die Gewährleistung der Integrität der 62
gesicherten Daten durch die eingesetzte Technik ist von hoher Bedeutung.
Schatz hebt in seinem Aufsatz hervor, dass überhaupt keine
Arbeitsspeicher-Erfassung durchgeführt werden sollte, falls Glaubwürdigkeit
und Genauigkeit durch Verfahrensfehler oder Verfälschung nicht sichergestellt
werden können. Es würde die investigative Ermittlung negativ beeinflussen,
wenn Falschinformation aus dem flüchtigen Arbeitsspeicher in den
Ermittlungsprozess einfliessen. Vömel und Freiling fassen die Schatz’schen 63
Kriterien Glaubwürdigkeit und Genauigkeit unter dem Begriff “atomicity”
zusammen. Atomicity einer angewandten Technik reflektiert die Forderung an
ein akurates und vollständiges Image eines volatilen Speichers. 64
4.1 Hardwarebasierte Techniken
Die Installation eines physischen Devices unterstützt Ermittler bei der Erstellung
eines Speicherabbildes eines Zielsystems. Peripheral Component Interconnect
Karten (PCI) ermöglichen Zugriff auf den physischen Speicher. Direct Memory 65
Access (DMA) erlaubt physisch angeschlossenen Peripheriegeräten direkt mit 66
dem Arbeitsspeicher ohne Umweg über die CPU zu kommunizieren. Bereits im
Jahr 2004 stellten Carrier und Grands ihre PCI Karte vor, die eine präzise Kopie
des Arbeitsspeichers ohne Interaktion mit dem laufenden Betriebssystem des
61 Ligh, Case, 2014. S. 69 62 Schatz, 2007. S. 127 63 Schatz, 2007. S. 128 64 Voemel, Freiling, 2011. S. 14 65 https://de.wikipedia.org/wiki/Peripheral_Component_Interconnect 66 https://de.wikipedia.org/wiki/Speicherdirektzugriff
25
Zielsystems ermöglicht. Neben PCI wird die serielle Datenübertragung wie 67 68
beispielsweise FireWire immer bedeutender in der Erstellung von Memory 69
Images. Dies liegt daran, dass Firewire Direct Memory Access in seiner
architektonischen Grundkonzeption von Beginn an mitbringt. Über den FireWire
Controller IEE 1394 kann der Hauptspeicher eines Rechners ausgelesen 70
werden. In dieser konfigurierten Betriebsart werden alle Lese- und
Schreibanfragen autonom durch andere am FireWire Bus angeschlossenen
Teilnehmer ausgeführt ohne weitere Software auf dem Hostsystem zu 71
involvieren. Der grosse Vorteil dieser Techniken besteht darin, dass die 72
Inhalte des Arbeitsspeichers unabhängig vom zugrunde liegenden
Betriebssystem direkt über die Hardware ausgelesen werden und somit keine
Verfälschung der Systemdaten erfolgen kann. Somit erfüllen hardwarebasierte
Techniken in der Regel die Forderung nach atomicity. Nachteilig bei PCI ist die
niedrigere Verfügbarkeit, da die Devices vorab installiert sein müssen. Dies ist
bei Hardware Bus basierten Techniken gelöst, da Hardware Bus Ports in
Desktop Systemen und portablen Systemen in der Regel verfügbar sind.
4.2 Softwarebasierte Techniken
Der Einsatz einer virtuellen Maschine (VM) ermöglicht das Ausführen einer
sichergestellten Systemumgebung eines angegriffenen Computersystems. Jede
VM ist ausgestattet mit einem virtuellen Prozessor, grafischen Adaptern,
Netzwerkzugriff und diversen I/O-Schnittstellen. Eine sehr wichtige Eigenschaft
von virtuellen Maschinen ist, dass diese fähig sind die Ausführungsphase der
zu untersuchenden Systemumgebung anzuhalten. In diesem Halte-Zustand ist
der Systemzustand, inklusive des virtuellen Arbeitsspeichers, verfügbar und
kann so auf der Festplatte des zugrundeliegenden Hostsystems gespeichert
werden. Somit kann der gesamte Speicherinhalt durch mehrfaches Anhalten
67 Carrier, Grand, 2004. S. 50 68 https://de.wikipedia.org/wiki/Serielle_Datenübertragung 69 https://de.wikipedia.org/wiki/FireWire 70 https://www.elektronik-kompendium.de/sites/com/0808111.htm 71 Osborne, 2013. S. 10 72 Ligh, Case, 2014. S. 6
26
des Systems in Form von einzelnen Speicherabbildern erfasst und analysiert
werden und somit die Anforderungen von Atomicity erfüllen. 73
Eine zweite Möglichkeit zur Analyse von Zuständen eines Arbeitsspeichers ist
die Auswertung sogenannte Crash Dumps. Dabei handelt es sich um binäre
Dateien, die im Falle von Systemabstürzen bei bestimmten
Systemkonfigurationen automatisch auf der Festplatte des Computersystems
geschrieben werden. Solche Dumps können mit Debugging Tools (Debuggers)
gleichartiger Betriebssystem untersucht werden. Für forensische Zwecke 74
können diese Crash Dumps durch Veränderung der Windows Registry
“künstlich” erzeugt werden. Ein Nachteil dieses Verfahrens ist, dass die
Verfügbarkeit der so gewonnen Speicherabbilder von dem Vorhandensein
entsprechender Debugging Tools abhängt. 75
Weiterhin besteht die anspruchsvolle Option physischen Speicher atomar durch
Einsatz einer User-Mode Applikation durch Direct Access Memory zu lesen. 76
Beispielsweise extrahiert das Instrument PMDump den Adressraum eines 77
einzigen Prozesses aus dem flüchtigen Arbeitsspeicher. Es ist somit schnell in 78
der Ausführung und bietet eine Konzentration auf ausgewählte relevante
Prozesse unter Nutzung der entsprechenden einsehbaren Prozess-ID’s
(Ausnahme: versteckte Prozesse durch Einsatz von Rootkits). Dadurch wird
eine hohe Verfügbarkeit sichergestellt, da diese Tools auch als USB Flash
Drive eingesetzt werden können. Allerdings verändert es auch den Zustand des
Arbeitsspeichers, da es als weiterer Prozess in den Arbeitsspeicher geladen
wird. Dies wird verschärft, wenn auf dem zu untersuchenden System Malware
ausgeführt wird, die Funktionen des Betriebssystem beeinträchtigen. Somit
erfüllen diese Instrumente die Forderung nach atomicity nicht. 79 80
73 Ligh, Case, 2014. S. 101 74 Osborne, 2013. S. 10 75 Osborne, 2013. S. 11 76 https://www.tutorialspoint.com/User-Mode-vs-Kernel-Mode 77 http://www.ntsecurity.nu/toolbox/pmdump/ 78 Vidstrom, 2002, http://ntsecurity.nu/toolbox/pmdump/ 79 Russinovich, Solomon, Ionescu, 2017. S. 45. 80 Voemel, Freiling, 2011. S. 18
27
Um die Nachteile der User-Mode Applikationen zu mildern konzentriert sich das
Software Engineering auf die Entwicklung von Kernel-Mode Applications zur 81
Erstellung von forensischen Kopien des volatilen Speichers. Diese Technik wird
in teils freien und kommerziell verfügbaren Tools, wie Memory DD , Windows 82
Memory Toolkit , Memoryze , WinEN , KnTDD und Fast Dump Pro 83 84 85 86 87
genutzt. Trotz des Betriebs im Kernel Mode verändern diese Instrumente den
Zustand im Arbeitsspeicher, da Windows einen neuen Prozess und Thread
Strukturen bei der Ausführung erzeugt. Weiterhin ist die Verfügbarkeit
gemindert, da Administratorenrechte für die Installation einer solchen
Arbeitsumgebung benötigt werden und die Ausführung des Prozesses ebenfalls
besondere Nutzerrechte voraussetzt. 88
4.3 Cold Booting Techniken
Halderman et al. präsentierten im Jahr 2009 einen neuen Ansatz für die 89
Erfassung von Daten aus einem flüchtigen Speicher. Ihr Ansatz basiert auf der
Entdeckung, dass Informationen aus dem Arbeitsspeicher nicht sofort nach
dem Ausschalten des Systems gelöscht werden und möglicherweise innerhalb
einer bestimmten Zeit zurück gewonnen werden können. Es werden drei 90
Methoden zum Erhalt volatiler Speicherinhalte dargestellt, die alle auf dem
Phänomen der Memory Remanence basieren. Der erste und zugleich 91
einfachste Ansatz ist ein Reboot des Systems und der Neustart im Kernelmode
mit einem kleinen Memory Footprint, der Zugang zum Restspeicher gewährt.
81 https://www.tutorialspoint.com/User-Mode-vs-Kernel-Mode 82 http://sourceforge.net/projects/mdd 83 http://www.moonsols.com/windows-memory-toolkit 84 http://www.mandiant.com/products/free_software/memoryze 85 http://www.guidancesoftware.com 86 http://www.gmgsysteminc.com/knttools 87 http://www.hbgary.com/fastdump-pro 88 Osborne, 2013. S. 12 89 Halderman, Schoen, Henninger, 2009. S. 91 90 Chow, Pfaff, Garfinkel, 2005. S. 22 91 https://en.wikipedia.org/wiki/Data_remanence
28
Eine weitere Alternative ist das zu untersuchende Computersystem von der
Stromversorgung zu trennen und die Arbeitsspeichermodule zu einem zweiten
Computer zu überführen, der so konfiguriert ist diesen Zustand zu extrahieren. 92
Aus diesen Forschungsansätzen wurden Methoden zur Reduktion der
Verfälschung remanenter Daten entwickelt. Die Speichermodule werden vor der
Entfernung gekühlt, um die Rückgewinnungszeit zu verlängern. In von
Halderman durchgeführten Tests mit vier Systemen, weist er eine höhere
Verfallszeit zwischen 41% und 50% von nicht-gekühlten Systemen nach einigen
Minuten nach. In den Fällen, in den die RAM Module vor dem Neustart gekühlt
waren betrug der Verfall der Daten lediglich zwischen 0.000036% und 0.18%. 93
Diese wissenschaftliche Forschung zeigt, dass mit dieser Methode ein
atomares Abbild des RAM Speichers möglich ist. 94
92 Halderman, Schoen, Henninger, 2009. S. 92 93 Halderman, Schoen, Henninger, 2009. S. 97 94 siehe weiteres Beispiel Machbarkeit Cold Boot siehe PoC AfterLife, durchgeführt von Timothy Vidas (Carnegie Mellon University), https://users.ece.cmu.edu/~tvidas/papers/HICSS10.pdf
29
5. Malware Analyse in der Memory-Forensik
Nach der Erfassung und Speicherung der flüchtigen Daten aus dem
Arbeitsspeicher werden diese Speicherinhalte im Rahmen der forensischen
Spurenauswertung analysiert. Dabei nutzt die Memory-Forensik die Analyse
von Informationen aus dem Memory-Image, um den Zustand eines zu
untersuchenden Systems zu ermitteln. Für die Analyse einer Malware umfasst
dies insbesondere die Analyse von Metadaten, die für die Ausführung von
Prozessen im Betriebssystem notwendig sind und die im volatilen
Arbeitsspeicher für einige Wochen verfügbar sein können.
Grundsätzlich muss an dieser Stelle bei den folgenden Analysemethoden
beachtet werden, daß die Ergebnisse nicht zwingend zu korrekten Annahmen
führen. Auch bei der Memory-Forensik im Malware-Kontext sind
Anti-Debugging/Anti-Analysis-Tools wie ADD anzufinden, die nachfolgende 95
Strukturen in einem größeren Rahmen manipulieren, um verfälschte Ergebnisse
zu hinterlassen bzw. Analysen sehr aufwändig machen.
5.1 Aufbau der Windows-Prozess-Struktur
Zur Analyse versteckter Malware ist es notwendig zu verstehen, wie Prozesse
des Windows-Betriebssystems im Speicher strukturiert werden und welche
Strukturen ein Malware-Autor nutzen bzw. manipulieren kann. Die Grundlagen
gelten für die verschiedenen Arten der Analyse. Daher wird an dieser Stelle ein
Überblick über diese Strukturen gegeben:
Portable Executable (PE)
Das Portable-Executable-Format ist ein binäres Dateiformat, das von Windows
eingesetzt wird, um ausführbare Dateien, wie beispielsweise eine .exe-Datei zu
beschreiben. Das PE-Format beinhaltet Strukturen für den File-Header und 96
95 https://code.google.com/archive/p/attention-deficit-disorder/ 96 https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
30
weitere Section-Header. Neben den verpflichtenden File-Header kann eine
Datei bis zu weiteren 96 Sektionen beinhalten. 97
Struktur Beschreibung
File-Header Dos Header + PE Header + Optional Header
Section-Header Optionale Header
.text - Segment Im Textsegment ist der Maschinen-Code und damit die Logik des Programms enthalten.
.data - Segment Im Data-Segment sind vom Programm bereits initialisierte Variablen enthalten
.rdata - Segment Im Rdata-Segment können Imports für Programm - bibliotheken (siehe DLL) enthalten sein. Es können auch vom Programm genutzte String-Literale hinterlegt werden
Tabelle 2: Aufbau des PE-Formats 98
Dynamic Link Library (DLL)
Eine DLL-Datei ist eine windows-spezifische dynamische Programmbibliothek,
diese auch im PE-Format abgespeichert wird. Sie stellt Funktionen zur
Verfügung, die von anderen Programmen genutzt werden können. 99
EPROCESS-Struktur
Jeder Windows-Prozess wird im Arbeitsspeicher durch eine
EPROCESS-Struktur repräsentiert. Innerhalb dieser Strukturen liegen unter 100
anderem Informationen wie den zugehörigen Threads (ETHREAD), den
geladenen Modulen (LDPR) und Speicherinformationen (VAD) vor. Diese 101
liegt im Windows-System-Mode und kann daher nicht durch den Nutzer
verändert werden.
97 http://www.keithholman.net/pe-format.html 98 http://www.keithholman.net/pe-format.html 99 https://de.wikipedia.org/wiki/Dynamic_Link_Library 100 https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess 101 https://umuttosun.com/eprocess-structure/
31
Abbildung 5: High-Level-Darstellung der Prozess-Ressourcen 102
Die Handle-Tables oder Process-Handles sind Zugriffe eines Programms auf 103
externe Ressourcen wie Dateien, Registry-Einträgen und anderen Prozessen.
Beispielsweise kann eine Malware selbst auch Informationen auf verschlüsselte
DLL-Funktionen hinterlegen, die sie dann nutzen kann ohne diese direkt im
System zu hinterlegen. Die Prozesse selbst enthalten ein bis mehrere 104
Threads. Ein Thread ist ein Unterprozess. Je nach Multitasking-Fähigkeit 105
eines Betriebssystems und der eingesetzten Hardware ist die gleichzeitige
Ausführung von Threads erlaubt. Threads eines Prozesses können miteinander
kommunizieren. Die genutzten DLL Dateien, die von einem Prozess geladen
102 Ligh, Case, Levy, 2014. S. 150 103 https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.process.handle?view=netframework-4.8 104 Ligh, Case, Levy, 2014. S. 176 105 https://de.wikipedia.org/wiki/Thread_(Informatik)
32
werden, werden als Loaded Modules bezeichnet. Die 106
Virtual-Adress-Deskriptors Struktur (VAD) ist eine Baumstruktur, die
Informationen über den genutzten virtuellen Speicher eines Programms gibt.
Elemente eines VAD-Baum beinhalten auch Berechtigungsinformationen wie
auf die Speicherbereiche zugegriffen werden darf. Werte für einen 107
Speicherschutz können PAGE_EXECUTE_READWRITE oder
PAGE_EXECUTE_WRITECOPY sein. 108
Process-Memory
Jeder von Windows gestartete Prozess beinhaltet seinen eigenen
Speicherbereich. Dieser Speicherbereich strukturiert sich folgendermaßen:
Bereich Beschreibung
Dynamic DLL Es beinhaltet die geladenen DLL-Dateien eines Prozess
Environment variables Die Umgebungsvariablen wie Pfade zu Ausführungs- dateien, temporären Verzeichnissen und anderen Verzeichnisangaben
PEB Der Process-Environment-Block beinhaltet Metadaten über den gestarteten Prozess
Process Heap Im Process-Heap werden hauptsächlich die vom Prozess verwendeten Variablen und deren Werte gespeichert
Thread [n]-Stack Jeder Thread hat seinen eigenen Speicherbereich. In dem Bereich findet man Angaben wie Funktions- argumente, Rückgabewerte und lokale Variablen
Mapped files, Application Data
In diesem Bereich können verknüpfte Dateien aus dem Dateisystem enthalten sein. Ebenso auch zusätzliche Werte, die zur Ausführung des Prozess notwendig sind.
106https://docs.microsoft.com/en-us/windows/win32/psapi/enumerating-all-modules-for-a-process 107https://resources.infosecinstitute.com/finding-enumerating-processes-within-memory-part-2/#gref) 108 https://docs.microsoft.com/en-us/windows/win32/memory/memory-protection-constants
33
Executable Es beinhaltet den Programmcode, der von der Festplatte geladen wurde
Tabelle 3: Aufbau des Process-Memory 109
Die Struktur Process Environment Block (PEB)
Der Process Environment Block ist eine Struktur des Windows-System-Kernels
und wird aus der EProcess-Struktur verlinkt. Der PEB beinhaltet Informationen
über den aktuell ausgeführten Prozess. Diese ist nicht Teil des 110
Kernel-Modes, sondern läuft im User-Mode des Betriebssystem. Dies ist
wichtig, da die PEB-Struktur selbst auch durch eine mögliche Schadsoftware
manipuliert werden kann. 111
Information Beschreibung
ProcessParameter Zeiger auf eine Struktur die Informationen über die Startparameter des Prozess wie Arbeitsverzeichnis, Umgebungsvariablen, Pfad zum Programm
LdR Ein Zeiger auf eine Struktur die Informationen über geladenen Module beinhaltet
Tabelle 4: Aufbau PEB Struktur 112
5.2 Prozesse und Threads
Die EPROCESS- und ETHREAD-Listen können sehr aufwendig numeriert,
einzeln erfasst und analysiert werden, um so eine Momentaufnahme des RAM
Zustands zu erhalten. Um dies zielgerichteter durchführen zu können werden
“Signature-based” Scanning Prozeduren entwickelt, die anhand von
Standardregeln die Strukturen der Systemprozesse und Datenstrukturen
beschreiben. Mit Hilfe dieser Signaturen können Prozesse und Threads aus
dem Speicher extrahiert werden, unabhängig davon ob die Prozesse
zusammenhängen. Insbesondere für die Entdeckung von Malware, die sich als
109 Ligh, Case, Levy, 2014. S. 190 110 Ligh, Case, Levy, 2014. S. 219 111 Ligh, Case, Levy, 2014. S. 220 112 Ligh, Case, Levy, 2014. S. 219 - 234
34
Prozess innerhalb des Speichers versteckt hat, ist dieses Vorgehen als
Anomalieerkennung sehr vielversprechend. Mit der Entwicklung des 113 114
Vorgehen “Windows Operating System Agnostic” im Jahr 2010, haben Okolicia
und Petersen ein Instrument geschaffen, dass es ohne Aufwand im harten
Coding möglich macht, ein beliebiges Memory Image unabhängig von der
Windowsversion einzulesen, um eine Analyse der Prozesse und Threads im
Speicher zu ermöglichen. Die Basisadressen der Kernel-Executables werden 115
extrahiert und mit Hilfe der Analyse der “Debug section” können die
Globally-Unique-Identifier (GUID) und das Alter der Prozesse bestimmt werden.
Dies wird mit der Program Database (PDB) von Microsoft-Symbol-Server
verglichen. Somit ist es möglich Memory-Images ohne aufwändige
Code-Offsets zu parsen. Wenn die Datenstrukturen einmal identifiziert und 116
modelliert wurden, können sie mit dem Parsen des Memory-Image dazu
benutzt werden, Prozesse zu extrahieren oder System-Zustandsinformation zu
erhalten. Durch verschiedene Methoden kann die Schadsoftware nun die
gegeben Datenstrukturen nutzen, um Einfluss auf Prozess-Darstellung und
-Struktur zu nehmen. Das Ziel eines Malware-Authors ist es dabei sich vor dem
Benutzer, Administrator oder Forensiker zu verstecken; dabei nutzt er folgende
Strategien:
● Image-Name-Tricks: Die EPROCESS-Struktur hält nur 16 Zeichen für
den Image-Name bereit und nutzt nicht den vollen Pfad. Daher
verwendet der Malware-Autor einen Dateinamen eines Programms, der
schon auf dem System existiert wie beispielsweise explorer.exe. Diese
Datei liegt nicht im originären Pfad und ist auf den ersten Blick nicht
erkennbar und bedarf weiterer Analysen um entdeckt zu werden. Zur
113 Schuster, 2006. S. 12 114 Walter, Petroni, 2012. S. 6 115 Okolicia, Petersen, 2010. S. 49 116 Okolicia, Petersen, 2010. S. 50 - 56
35
Auswertung muss die vollständige Pfad-Angabe des PEB herangezogen
werden. 117
● Parent-Process-Tricks: Hier wird die Malware durch ein gültiges valides
Programm gestartet und verschleiert diese invalide Ausführung. Hierzu
kann eine Ausführung über die Windows-Services genutzt werden, die
dann als Parent der Service wie svchost.exe genutzt wird. Denkbar sind
auch Aufrufe über die Windows-API, da dort ein eigener Parent-Prozess
angegeben werden kann. Die Prozesse sehen dann wie normale
Kind-Prozesse des Windows-Service aus und erschweren das direkte
Entdecken der Malware. Auch hierfür muss die vollständige Pfad-Angabe
des PEB zur Analyse herangezogen werden. 118
● PEB-Manipulation: Die Methoden Image-Name-Trick und
Parent-Process Trick können durch eine korrekte Pfad-Auswertung des
PEB identifiziert werden. Da der PEB allerdings im Usermode liegt, kann
dieser durch die Malware manipuliert und durch einen anderen gültigen
Pfad ersetzt werden. Um diese Manipulation zu entdecken ist die
Analyse des Virtual Address Descriptor (VAD) notwendig, da das
Betriebssystem (Memory-Manager) Informationen über die
Speicherbereiche eines Prozess beinhaltet. 119
● Direct-Kernel-Object-Manipulation: Die EPROCESS-Struktur verknüpft
die laufenden Prozesse über eine doppelt verlinkte Linkliste. Ziel der
Attacke ist es nun den laufenden Prozess aus dieser Linkliste zu
entfernen. Dies geschieht dadurch, dass der FLink und PLink-Pointer
überschrieben werden. Da die Manipulation der EPROCESS-Struktur
erfolgt, sind für diese Art der Manipulation Root-Rechte/
Administrationsrechte notwendig. Statt der Auswertung der verknüpften
Linklisten wird ein Scannen des Speichers nach EPROCESS-Elementen
ausgeführt. Daher kann eine Analyse der Linklisten und eine Analyse
117 Ligh, Adair, Hartstein, 2011. S. 593 118 Ligh, Adair, Hartstein, 2011. S. 594 119 Ligh, Adair, Hartstein, 2011. S. 595
36
des Scans zu unterschiedlichen Ergebnisse kommen. Die
unterschiedlichen Ergebnismengen sind ein Anhaltspunkt für mögliche
Schadsoftware. 120
Abschließend kann die Vorgehensweise von Prozessignaturen genutzt werden,
um Systemkonfigurationen aus den Windows Registries zu extrahieren.
Insbesondere sollen mit der Memory Forensik zwei Hives identifiziert werden,
die nur im RAM gespeichert werden: Hardware und Registry (_CMHIVE mit der
Signatur 0xbee0bee0). Diese beiden Hives beinhalten Zustandsinformationen 121
und können nur mit der Memory Forensik untersucht werden. Aljaedi et al. 122
heben diese Möglichkeiten für Ermittler in Memory Analyse hinsichtlich System
Zustandsanalyse und der Rekonstruktion des Nutzerverhaltens besonders
hervor.
5.3 Packing und Compression-Analyse
Ziel des Packing bzw. der Compression ist es den eigentlichen Malware-Code
einer Anwendung noch weiter vor dem Nutzer oder Forensiker zu verstecken.
Grundsätzlich können bei einem normalen Programm der Ausführungs-Code
sowie mögliche Ressourcen mit entsprechenden Tools wie PE-Viewer,
identifiziert werden. Sobald aber der Malware-Code gepackt und komprimiert
sowie möglicherweise verschlüsselt in einem anderen Segment des
PE-Formats versteckt wird, kann dies bei einer statischen Codeanalyse bzw.
beim Reversing nicht identifiziert werden. 123
120 Ligh, Adair, Hartstein, 2011. S. 588 121 Osborne, 2013. S. 19 122 Aljaedi, Lindskog, Zavarski, 2011. S. 1253 - 1258 123 Ligh, Case, Levy, 2014. S. 245
37
Abbildung 6: Schematische Darstellung eines Packing/Unpacking-Vorgang anhand einer .exe
im PE-Format 124
Um den Schadcode ausführen zu können, muss das Programm ein Unpacking
vornehmen. Damit wird der Schadcode in die entsprechenden PE-Segmente
der .exe übertragen und liegt offen im Arbeitsspeicher des System. Nun kann 125
über entsprechende Analyse Instrumente, wie Rekall oder Volatility , die 126 127
.exe aus dem Speicher extrahiert werden, um dann eine Analyse mit einem
Reversing-Tool oder im PE-Viewer durchzuführen. 128
5.4 Code Injection
Malware nutzt das Konzept der Code-Injection, um Malware-Prozesse und
Aktionen in der Ausführung regulärer Systemprozesse zu verschleiern. Dabei
bringt die Malware einen legitimen Prozess dazu Aktionen wie den Download
von Trojanern oder Informationen des System auszulesen. Die Malware kann 129
dazu unterschiedliche Arten der Injektion nutzen:
124 Ligh, Case, Levy, 2014. S. 245 125 Ligh, Case, Levy, 2014. S. 245 126 http://www.rekall-forensic.com/ 127 https://www.volatilityfoundation.org/ 128 https://en.wikipedia.org/wiki/Reverse_engineering 129 Ligh, Case, Levy, 2014. S. 251
38
● Remote-DLL-Injection: Der Malware-Prozess bringt einen anderen
Ziel-Prozess dazu eine DLL zu laden. Dazu werden die API-Funktionen
LoadLibrary oder LdRLoadDLL genutzt. Die DLL wird zum Laden 130 131
auf dem System benötigt. Sofern die nachgeladene DLL Packing nutzt,
kann durch Analyse der Speicherregionen auf Malware geschlossen
werden. Für komplexere Analysen durch Auswertung der Kontextpfade,
der Durchführung von Yara Scans und DLL-Load-Timestamps kann 132 133
dies weiter detailliert untersucht werden. 134
● Remote-Code-Injection: Bei der Remote-Code-Injection startet der
Malware-Prozess auch einen Ziel-Prozess, aber statt eine DLL zuladen,
wird in den Speicher des Ziel-Prozess geschrieben. Die Auswertung
einer Remote-Code-Injection geschieht über eine Auswertung der
VAD-Struktur. 135
● Reflective-DLL-Injection: Der Malware-Prozess schreibt eine DLL in
den Memory-Space eines Ziel-Prozesses. Das Laden der DLL geschieht
dabei nicht über die API-Funktionen. Die DLL muss dabei nicht auf dem
System hinterlegt sein. Für die Analyse einer Reflective-DLL-Injection ist
auch die Auswertung der VAD-Struktur notwendig, da dort die
entsprechenden Importe der DLL-Funktionen hinterlegt sind . 136
● Hollow-Process-Injection: Hier startet die Malware ein valides
Programm, tauscht aber vor dem Start des ersten Thread den Code aus
und kopiert dabei die PE-Sektionen einer Malware in die PE-Sektionen
des validen Programm und lässt die sonstige Strukturen wie den PEB
unangetastet. Zur Analyse muss die Eltern/Kind-Prozess-Struktur
ausgewertet werden, indem geprüft wird, ob das valide Programm von
130 https://docs.microsoft.com/de-de/cpp/build/loadlibrary-and-afxloadlibrary?view=vs-2019 131 https://stackoverflow.com/questions/51120625/ldrloaddll-crash 132 http://virustotal.github.io/yara/ 133 https://docs.microsoft.com/en-us/windows/win32/debug/pe-format 134 Ligh, Case, Levy, 2014. S. 253 135 Ligh, Case, Levy, 2014. S. 253 136 Ligh, Case, Levy, 2014. S. 257
39
einem anderen validen Programm gestartet wurde. Dabei wird die 137
PEB- und die VAD-Struktur verglichen. Wenn der PEB im
Process-Memory sich von den Informationen im VAD unterscheidet kann
dies ein Indiz für eine Malware sein. 138
5.5 Netzwerkanalyse
Memory-Images ermöglichen Einblicke in die Netzwerkverbindungen des zu
untersuchenden Systems. Neben der Erfassung von Prozessinformationen aus
dem Arbeitsspeicher ist es möglich die lokalen und Remote Socket Adressen
der aktiven Netzwerkverbindungen zu extrahieren. Die PDB-Dateien werden 139
genutzt um die Datenstrukturen und Symbole zu identifizieren, um die tcpip.sys
im Speicher zu untersuchen. Sobald die relevanten Symbole einmal 140
identifiziert wurden, werden die PDB-Dateien genutzt, um diese Verbindungen
im physischen Speicher zu lokalisieren und diese Informationen zu extrahieren.
Dadurch ist es möglich aktive TCP-Verbindungen im volatilen Arbeitsspeicher
zu identifizieren. Zur Verwendung von Netzwerkkommunikation muss der
Prozess nun je nach gewünschter Funktion entweder eine Verbindung zu einem
entfernten System herstellen oder selbst einen Dienst bereitstellen, der von
anderen Systemen in Anspruch genommen werden kann. Hierzu wird in
TCP/IP-basierten Netzwerken eine Quell- und Zieladresse sowie ein Quell- und
Zielport benötigt. Mögliche Verbindungen und damit ein Informationsaustausch
können dabei auch über andere Services wie DNS-Anfragen nach draußen
gelangen.
137https://www.blackhat.com/docs/asia-17/materials/asia-17-KA-What-Malware-Authors-Don't-Want-You-To-Know-Evasive-Hollow-Process-Injection-wp.pdf 138https://www.blackhat.com/docs/asia-17/materials/asia-17-KA-What-Malware-Authors-Don't-Want-You-To-Know-Evasive-Hollow-Process-Injection-wp.pdf 139 Okolicia, Petersen, 2010. S. 50 140 Hinweis: die tcpip.exe kann hierzu nicht genutzt werden, da der Windows Kernel direkt keine TCP/IP Kommunikation abarbeitet.
40
Die Netzwerkanalyse gibt einen Einblick in viele Malware-Anwendungen,
die aktuell im System ausgeführt werden. Diese Anwendungen nutzen in der 141
Regel vordefinierte Ports um Schadcode in einem Zielsystem auszuführen.
Live-Forensik Instrumente, wie beispielsweise TCPView , decken diese 142
Gefahren auf. Memory-Forensik-Analyse-Techniken unterstützen dabei Daten
aus diesen Instrumenten zu korrelieren und ermöglichen damit ein tieferes
Verständnis des Vorfalls. 143
141 Vömel, Freiling, 2011. S. 21 142 Download: https://www.heise.de/download/product/tcpview-22994 143 Russinovich, Solomon, Ionescu, 2009. S. 89
41
6. Durchführung der praktischen Memory-Analyse
6.1 Das Labor Szenario
Der schwierigste Teil in der Memory-Forensik ist die Erfassung eines
Memory-Images in atomarer und verfügbarer Form. Software-basierte
Vorgehensmodelle sind zwar hoch-verfügbar, nachteilig ist allerdings, dass sie
auf dem Zielsystem allokiert werden müssen und somit Veränderungen am
Zustand des Systems vornehmen. Hingegen hardware-basierte Techniken
reproduzieren akurate Abbilder, da sie vom Betriebssystem ohne eigene
Speicherallokation unabhängig sind. Es bedarf mehr Wissen über das
Zielsystem und es müssen Vorbereitungsmaßnahmen getroffen werden, bevor
die Ermittlung gestartet werden kann.
Abbildung 7: Übersicht Bewertung der Sicherungstechniken 144
Aufgrund der hohen Verfügbarkeit bei vergleichbar hoher Datenqualität und
unter Berücksichtigung der verfügbarer Ressourcen der Autoren soll für die
folgende praktische Memory-Analyse das Abbild eines Images mit einer
virtuellen Maschine genutzt werden. Hierfür wird ein Windows-7-32-Bit-System
144 Osborne, 2013. S. 14
42
mit Virtual-Box 6.0.8 im Debug-Modus virtualisiert, um den Memory-Dump zu
erzeugen. Als Hostsystem dient ein 64-bit Windows-System der Version 10.
Abbildung 8: Virtualisierung Windows 7 Zielsystem
Für die Aktivierung des Debug-Modus müssen die Umgebungsvariablen
VBOX_GUI_DBG_AUTO_SHOW und VBOX_GUI_DBG_ENABLED vorhanden
sein und den boolschen Wert true haben.
43
Abbildung 9: Übersicht Setzen der Variablen für Start debug Modus
Nach der beschriebenen Einrichtung der Systemvariablen kann der
Debug-Modus aktiviert werden.
44
Abbildung 10: Bestätigung erfolgreicher Start im debug Modus
Die Malware WannaCry ist unter folgenden HTTP-Link verfügbar und wird mit
einem Download-Prozess auf das Hostsystem transferiert:
https://github.com/ytisf/theZoo/tree/master/malwares/Binaries/Ransomware.Wa
nnaCry
Das übermittelte Datenpaket wird auf dem Hostsystem entpackt und per Maus
“Drag/Drop”-Event in die virtuelle Maschine überführt. Innerhalb der Virtual-Box
wird die ausführbare Datei per Maus Doppel-Klick ausgeführt und impliziert die
gewünschte Infizierung des virtuellen Systems.
45
Abbildung 11: Übersicht entpackte Malware WannaCry in der VM
Abschließend wird mit dem Befehl .pgmphystofile der Memory Dump des
infizierten Systems erzeugt.
Abbildung 12: Bestätigung der erfolgreichen Erstellung des Memory Dumps
46
6.2 Die Malware Wannacry
Die Malware WannaCry, auch bekannt als Wcrypt, WCRY, WannaCrypt oder
Wana Decrypt0r 2.0, ist ein Schadprogramm, das nach der Kompromittierung
eines Zielsystems bestimmte Benutzerdateien des Rechners mit einem
2048-Bit-RSA-Schlüssel verschlüsselt. Anschließend wird vom Nutzer ein
bestimmter Betrag in der Kryptowährung Bitcoin gefordert, um die Dateien
wieder zu entschlüsseln beziehungsweise nach Ablauf einer bestimmten Frist
ein Datenverlust durch das Programm anzudrohen. Demnach kann WannaCry
als Ransomware klassifiziert werden wobei die Programmierer von WannaCry
auf einen monetären Vorteil durch Erpressung abzielen. Darüber hinaus 145
wurde WannaCry als Computerwurm spezifiziert, um eine größtmögliche
selbstständige Verbreitung sicherzustellen und installiert auf dem Zielsystem
die Backdoor DoublePulsar , um einen späteren Zugriff auf die Systeme zu 146
ermöglichen.
Im Kaspersky’s Klassifikationsbaum wird WannaCry im oberen roten Teil des
Baumes angesiedelt mit enormen Gefahrenpotential. Im Rahmen des
Cyberangriffs im Mai 2017 wurden weltweit in über 150 Ländern tausende von
Computern innerhalb weniger Stunden infiziert und es hat auch Krankenhäuser,
Transportinfrastrukturen und private Firmen betroffen. 147
145 https://de.wikipedia.org/wiki/WannaCry 146 https://de.wikipedia.org/wiki/DoublePulsar 147 https://techcrunch.com/2019/05/12/wannacry-two-years-on/?guccounter=1&guce_referrer_us=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_cs=wUktlT21zC2HYZ5ROC5CrA
47
Abbildung 13: Beispielhafte Meldung der Malware WannaCry
WannaCry nutzt EternalBlue, einem Exploit der Sicherheitslücke MS17-010 im
SMB-Protokoll von Microsoft. Ursprünglich wurde dieser Exploit durch die NSA
bereits vor dem Angriff im Jahr 2017 über fünf Jahre lang von der NSA genutzt
ohne diesen Sicherheitslücke an Microsoft zu melden. Erst als diese
Information durch die Hackergruppe The-Shadow-Brokers gestohlen und
schrittweise veröffentlicht wurde, wurde Microsoft darüber informiert. Einem
Monat nach Veröffentlichung der Sicherheitslücke erfolgte der Angriff mit der
Ransomware. 148 149
148 https://de.wikipedia.org/wiki/EternalBlue 149 https://www.securityfocus.com/bid/96704
48
Abbildung 14: Sicherheitslücke Exploit CVE-2017-0144
6.3 Das Analyseinstrument Rekall
Wichtige Kriterien bei der Wahl eines geeigneten Softwaretools zur
it-forensischen Spurensicherung sind die Verfügbarkeit, eine hohe Flexibilität,
Kompatibilität mit möglichst vielen Computersystemen und nicht zuletzt eine
Frage des Kostenaufwands.
49
Das Open-Source-Projekt Rekall ist ein in der Programmiersprache Python 150
implementiertes Framework und ist unter der GNU (General Public License)
Lizenz frei verfügbar. Es bietet ein breites Spektrum an Funktionalitäten und
zudem ein Plugin-Interface, durch das Möglichkeiten für funktionale
Skalierungen geschaffen werden . Der in Python geschriebene Quelltext ist für 151
jedermann zugänglich und wird permanent erweitert . Rekall ging 2013 als 152 153
Fork des Open-Source-Projekts Volatility hervor und steht für die 154
Betriebssysteme Windows, Linux und OSX zur Verfügung.
Für die Sicherung der Inhalte eines Arbeitsspeichers bringt Rekall für alle
Plattformen das jeweilige Werkzeug mit: WinPmem (Windows), pmem (Linux)
und MacPmem (OSX) . Anstatt das Speicherabbild in einem Dump zu sichern, 155
kann mit dem Kommandozeilenbefehl --live auch eine Analyse im laufenden
Zustand durchgeführt werden. Zudem ist Rekall in dem Rapid Resonse-Tool
GRR integriert, welches als Open-Source-Tool von der Firma Google unter 156
einer Apache 2.0 Lizenz bereitgestellt wird. Somit gibt es mit Rekall mehrere
Möglichkeiten den Inhalt eines Arbeitsspeichers zu analysieren:
1. Die Erstellung eines Dump-Files auf dem zu untersuchenden
Computersystem unter Verwendung der Befehle WinPmem, pmem oder
MacPmam, der mit der Kommandozeile rekal.exe -f <dump file> zur
weiteren Analyse geladen werden kann.
2. Die Durchführung einer Live-Analyse des Arbeitsspeichers auf dem zu
untersuchenden Computersystem mit der Kommandozeile rekal.exe
--live.
3. Die Übermittlung eines Dumps per Fernzugriff auf das zu untersuchende
Computersystem unter Verwendung des Tools GRR
150 http://www.rekall-forensic.com 151 https://digital-forensics.sans.org/media/rekall-memory-forensics-cheatsheet.pdf 152 https://github.com/google/rekall 153 https://github.com/google/rekall/graphs/contributors 154 https://www.volatilityfoundation.org 155 http://rekall-forensic.blogspot.de/2016/05/the-pmem-suite-of-memory-acquisition.html 156 https://github.com/google/grr
50
Die gegenwärtig verfügbaren Rekall Releases sind 1.7.1 Hurrican Ridge sowie
ein Release Candidate für die Version 1.7.2. Es werden 32- und
64-Bit-Prozessoren für folgende Betriebssysteme unterstützt:
● Microsoft Windows XP Service Pack 2 and 3
● Microsoft Windows 7 Service Pack 0 and 1
● Microsoft Windows 8 and 8.1
● Microsoft Windows 10
● Linux Kernels 2.6.24 to 4.4.
● OSX 10.7-10.12.x.
Voraussetzung für eine erfolgreiche Installation und Benutzung des
Frameworks ist eine Python Distribution der Version 3.0. Ausgeführt werden
kann Rekall in einem Shell-Kommando-Interpreter mit dem zu untersuchenden
Dump-File als Parameter: rekal.exe -f <dump_file>. Daraufhin wird der
interaktive Rekall-Command-Line Interpreter gestartet, in dem weitere Rekall
Befehle ausgeführt werden können.
Abbildung 15: Start von Rekall in einer Windows Powershell und Ausführung von imageinfo
51
In der vorangegangenen Abbildung lieferte der Befehl imageinfo eine erste
Übersicht über das System des Arbeitsspeichers. Die Nutzung der Rekall Shell
ist nicht zwingend notwendig, es kann auch in den Standard-Shells eines
Betriebssystems (z.B. Windows Powershell) gearbeitet werden.
6.4 Das Analyseinstrument Memory Analyser
Rekall bietet Möglichkeiten zur Speicherung der Resultate in Dateien
verschiedener Formate (Ascii, JSON, HTML), allerdings ist es für den Benutzer
nicht einfach einen Überblick über die vielfältigen Untersuchungen zu behalten.
Eine Hilfe bietet hier das Open Source Projekt Memory Analyser . 157
Es wird unter der GNU General Public License v3.0 von der Systems Austria
GmbH angeboten und verspricht ein grafisches User Interface zur vereinfachten
Bedienung der Kommandozeilentools Volatility und Rekall in Form eines
C#-Projekts. Die Untersuchungen verschiedener Memory-Dumps können in
Projekten verwaltet und mit Suchanfragen nach spezifischen Begriffen gefiltert
werden.
Um die praktische Memory-Analyse dieser Arbeit anschaulicher zu gestalten
wurde ein lokaler Clone des Memory-Analyser-Projekt erstellt und mit Microsoft
Visual Studio 2019 geladen. Es stellte sich heraus dass manche der
dokumentierten Features des Projekts nicht funktionsfähig, beziehungsweise
nicht vorhanden waren. Folgende Schritte waren nötig um den
Memory-Analyser für Rekall lauffähig zu machen:
1. Einige der verlinkten DLLs stellten sich als veraltet heraus und
mussten ersetzt werden um das Projekt kompilieren zu können.
2. Entgegen der angepriesenen Konnektivität mit einem Rekall
Prozess zeigte sich, dass lediglich eine Interface Klasse
157 https://github.com/TSA-CERT/memoryanalyzer
52
VolatilityExecutioner.cs existierte. Es musste eine zusätzliche
Klasse RekallExecutioner.cs programmiert werden.
3. Trotz erfolgreichem Aufruf eines Rekall-Prozesses aus dem
Memory-Analyser konnten keine Resultate der Kommandos
angezeigt werden. Nach Verifikation des Programmcodes stellte
sich heraus, dass das User Interface des Memory Analysers auf
Grundlage von SQLite Dateien arbeitet, in welche die 158
Analyseergebnisse abgelegt sein sollten. Ein Export für das
Fileformat .sqlite wird von Rekall allerdings nicht unterstützt. Aus
diesem Grund war eine Erweiterung der Programmierung
notwendig, um bei der Verwendung von Rekall auf Basis von
Ascii-Dateien arbeiten zu können. Damit ist der
Rekall-Anwendungsfall des erweiterten Memory-Analysers
unabhängig von Datenbanken, bietet aber andererseits keine
Möglichkeit für gefilterte Abfragen der Ergebnisse.
4. Die grafische Anzeige der Resultate war lediglich für das
Datenbank-Format des VolatilityExecutioner implementiert und
somit für die textbasierten Ergebnisse des RekallExecutioners
nicht geeignet. Aus diesem Grund wurde eine alternative
Darstellung für ASCII-Files unter Verwendung des Widgets
System.Windows.Forms.RichTextBox programmiert.
Nach diesen Modifikationen ist es möglich den erweiterten Memory-Analyser
als Analysetool für mit Rekall durchgeführte Untersuchungen zu verwenden.
Das User-Interface besteht aus einem Frame zur Verwaltung von Projekten,
welche in einer Baumstruktur dargestellt werden. In dem Feld Command ist es
möglich für das jeweils aktive Projekt Rekall-Kommandos abzusetzen, deren
Ergebnisse in einem Text-Frame dargestellt werden und als Eintrag in dem
Projekt-Baum gespeichert werden. Durch die Schaltflächen Restart und Delete
158 https://www.sqlite.org/fileformat.html
53
besteht die Möglichkeit Kommandos zu wiederholen oder aus der Baumstruktur
zu entfernen.
Abbildung 16: Memory Analyser mit Rekall Extension
Alle Rekall-Ergebnisse werden als einzelne Textfiles in .txt Dateien gespeichert.
Für eine persistente Verwaltung der Projekte legt der Memory-Analyser
Meta-Informationen in .command Dateien ab.
54
Abbildung 17: Memory Analyse Resultate und Projektinformationen des Projekts cridex
6.5 Das Verlaufsprotokoll
Durch die in Kapitel 5 beschriebenen Strukturen ergibt sich folgende Reihe von
Auswertungs-Aufgaben, die in dieser Untersuchung als Basis für das
Verlaufsprotokoll zur Malware-Analysen mit Rekall dient.
Auswertungskategorie Rekall-Befehl Untersuchungsziel
System imageinfo Systeminformation
Prozesse (Prozessliste, Prozessbaum, Prozessinformation, Threads)
pslist psscan pstree psxview threads procinfo <pid>
Auswertung der Prozesse auf der EPROCESS-Struktur (pslist und pstree), auf die Speicherzugriffe (psscan), auf die Threads (threads) und auf den PEB (procinfo)
Services svcscan Auswertung Windows-Services
55
Hives hives Auswertung der Registry-Hives
Packing/Compression procdump Extraktion der PE-Dateien
DLL-Zugriffe dlllist Ausgabe eingebundener dynamic linked Libraries
Handles handles Ausgabe aktiver Datei-Zugriffe
Code-Injection malfind, ldrmodules
Auswertung von PEB und VAD
Netzwerkanalyse netscan, netstat, dns_cache
Suche nach Netzwerkverbindungen (netscan), Ausgabe der Netzwerk Statistik (netstat) und Extrahieren des Windows-DNS-Cache
Disk Artifacts filescan dumpfiles
Scannen nach _FILE_OBJECT-Zugriffen (filescan) und deren Extraktion (dumpfiles)
Tabelle 5: Übersicht des geplanten Verlaufs und Rekall Befehle für die Analyse
Im folgenden werden die aufgelisteten Kategorien auf das mit WannaCry
infizierte System angewendet. Je nach Auftreten von Auffälligkeiten werden die
einzelnen Untersuchungsschritte an verdächtigen Prozessen und
Datenstrukturen iterativ wiederholt.
Auswertungskategorie Prozesse:
1. Rekall-Befehl pslist
Aufruf rekal -f .\wannacry --output pslist.txt pslist
Artefakt Der Prozess @WanaDecryptor (PID=2632) ist aufgrund seines Namens
auffällig
Anlage 1: pslist (S.79)
56
2. Rekall-Befehl psscan
Aufruf rekal -f .\wannacry --output psscan.txt --scan_kernel psscan
Artefakt vdsldr.exe (PID=1848) scheint ein “versteckter” Prozess zu sein, da er im
Untersuchungsschritt 1. nicht aufgelistet wurde
Anlage 2: psscan (S.80)
3. Rekall-Befehl pstree
Aufruf rekal -f .\wannacry --output pstree.txt pstree
Artefakt Eltern und Kind-Prozess von Prozess 2632 auffällig.
ed01ebfbc9eb5b(PID=2260) und taskhsvc.exe(PID=1804)
Anlage 3: pstree (S.81)
4. Rekall-Befehl psxview
Aufruf rekal -f .\wannacry --output psxview.txt psxview
Artefakt Rekall warf bei der Ausführung eine Fehlermeldung. Offensichtlich ist die
Implementierung von psxview in der Rekall Version 1.7.2. fehlerhaft.
Anlage 4: psxview (S.82)
5. Rekall-Befehl procinfo
Verfolgen von Spur aus 3. mit der Prozess-Id 2260
Aufruf rekal -f .\wannacry --output procinfo_2260.txt procinfo 2260
Artefakt Keine Auffälligkeiten
Anlage 5: procinfo für Prozess 2260 (S.83)
57
6. Rekall-Befehl procinfo
Verfolgen von Spur aus 1. mit der Prozess-Id 2632
Aufruf rekal -f .\wannacry --output procinfo_2632.txt procinfo 2632
Artefakt Keine Auffälligkeiten
Anlage 6: procinfo für Prozess 2632 (S.84)
7. Rekall-Befehl procinfo
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry --output procinfo_1804.txt procinfo 1804
Artefakt Keine Auffälligkeiten
Anlage 7: procinfo für Prozess 1804 (S.85)
8. Rekall-Befehl procinfo
Verfolgen von Spur aus 1. mit der Prozess-Id 2262
Aufruf rekal -f .\wannacry --output procinfo_1848.txt procinfo 1848
Artefakt Keine Auffälligkeiten
9. Rekall-Befehl threads
Verfolgen von Spur aus 1. mit der Prozess-Id 2260
Aufruf rekal -f .\wannacry --output threads_2260.txt threads 2260
Artefakt Verwendung von VAD-Threads, folglich Verdacht auf
Speicheranpassungen
Anlage 8: threads für Prozess 2260 (S.85)
58
10. Rekall-Befehl threads
Verfolgen von Spur aus 3. mit der Prozess-Id 2632
Aufruf rekal -f .\wannacry --output threads_2632.txt threads 2632
Artefakt Verwendung von mswsock-Threads, folglich Verdacht auf
Socket-Verbindungen
Anlage 9: threads für Prozess 2632 (S.85)
11. Rekall-Befehl threads
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry --output threads_1804.txt threads 1804
Artefakt Verwendung von mswsock-Threads, folglich Verdacht auf
Socket-Verbindungen
Anlage 10: threads für Prozess 1804 (S.86)
12. Rekall-Befehl threads
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry --output threads_1848.txt threads 1848
Artefakt Keine Prozess-Information möglich
13. Rekall-Shell-Session zur Pfad-Auswertung
Aufruf rekal -f .\wannacry
> describe(pstree)
> select cmd , path,_EPROCESS.pid from pstree() where
_EPROCESS.pid=1804 or _EPROCESS.pid=2632 or
_EPROCESS.pid=2260 or _EPROCESS.pid=1848
59
Artefakt Pfad-Abfragen auf das Verzeichnis c:\tmp\Ransomware.WannaCry,
folglich Assoziation der Prozesse mit der Malware WannaCry
Anlage 11: Pfad-Auswertung (S.86)
Auswertungskategorie Services:
14. Rekall-Befehl svcscan
Aufruf rekal -f .\wannacry --output svcscan.txt svcscan
Artefakt Keine Services über Programmnamen auffindbar
Anlage 12: svcscan (Ausschnitt) (S.86)
Auswertungskategorie Hives:
15. Rekall-Befehl hives
Aufruf rekal -f .\wannacry --output hives.txt hives
Artefakt Keine Auffälligkeiten
Anlage 13: hives (S.87)
Auswertungskategorie DLL-Zugriffe:
16. Rekall-Befehl dlllist
Verfolgen von Spur aus 2. mit der Prozess-Id 2632
Aufruf rekal -f .\wannacry --output dllist_2632.txt dlllist 2632
Artefakt Die DLL mswsock.dll wurde geladen, folglich Verdacht auf offene
Socket-Connections innerhalb des Prozesses
Anlage 14: dlllist für Prozess 2632 (S.87)
60
17. Rekall-Befehl dlllist
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry --output dllist_1804.txt dlllist 1804
Artefakt Folgende DLLs wurden geladen:
C:\tmp\Ransomware.WannaCry\TaskData\Tor\libevent-2-0-5.dll
C:\tmp\Ransomware.WannaCry\TaskData\Tor\libssp-0.dll
C:\tmp\Ransomware.WannaCry\TaskData\Tor\libgcc_s_sjlj-1.dll
C:\tmp\Ransomware.WannaCry\TaskData\Tor\LIBEAY32.dll
C:\tmp\Ransomware.WannaCry\TaskData\Tor\SSLEAY32.dll
C:\tmp\Ransomware.WannaCry\TaskData\Tor\zlib1.dll
sowie weitere windowsspezifische DLL-Dateien, z.B. mswsock.dll und
cryptbase.dll,
folglich Verdacht auf offene Socket-Connections und Netzwerk-Aktivitäten
innerhalb des Prozesses
Anlage 15: dlllist für Prozess 1804 (S.88)
18. Rekall-Befehl dllist
Verfolgen von Spur aus 3. mit der Prozess-Id 2260
Aufruf rekal -f .\wannacry --output dllist_2260.txt dlllist 2260
Artefakt Die DLL cryptbase.dll wurde geladen, folglich Verdacht auf
Trojaner-Angriff
Anlage 16: dlllist für Prozess 2260 (S.88)
Auswertungskategorie Handles:
19. Rekall-Befehl handles
Verfolgen von Spur aus 2. mit der Prozess-Id 2632
61
Aufruf rekal -f .\wannacry --output handles_2632.txt handles 2632
Artefakt Keine Auffälligkeiten
Anlage 17: handles für Prozess 2632 (S.89)
20. Rekall-Befehl handles
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry --output handles_1804.txt handles 1804
Artefakt Zugriff auf die Datei
\Device\HarddiskVolume1\Users\IEUser\AppData\Roaming\tor\lock
Anlage 18: handles für Prozess 1804 (S.89)
21. Rekall-Befehl handles
Verfolgen von Spur aus 3. mit der Prozess-Id 2260
Aufruf rekal -f .\wannacry --output handles_2260.txt handles 2260
Artefakt Zugriff auf die Dateien
\Device\HarddiskVolume1\Users\IEUser\AppData\Local\Temp\hibsys.WN
CRYT
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\00000000.eky
Anlage 19: handles für Prozess 2260 (S.90)
22. Rekall-Befehl handles
Verfolgen von Spur aus 3. mit der Prozess-Id 1848
Aufruf rekal -f .\wannacry --output handles_1848.txt handles 1848
Artefakt Keine Informationen verfügbar
62
Auswertungskategorie Packing/Compression:
23. Rekall-Befehl procdump
Verfolgen von Spur aus 3. mit der Prozess-Id 2632
Aufruf rekal -f .\wannacry procdump 2632
Artefakt Dump-Erstellung für spätere Packing/Compression-Analysen
Anlage 20: prodump für Prozess 2632 (S.90)
24. Rekall-Befehl procdump
Verfolgen von Spur aus 3. mit der Prozess-Id 1804
Aufruf rekal -f .\wannacry procdump 1804
Artefakt Dump-Erstellung für spätere Packing/Compression-Analysen
Anlage 21: prodump für Prozess 1804 (S.90)
25. Rekall-Befehl procdump
Verfolgen von Spur aus 3. mit der Prozess-Id 2260
Aufruf rekal -f .\wannacry procdump 2260
Artefakt Dump-Erstellung für spätere Packing/Compression-Analysen
Anlage 22: prodump für Prozess 2260 (S.90)
26. Rekall-Befehl procdump
Verfolgen von Spur aus 3. mit der Prozess-Id 1848
Aufruf rekal -f .\wannacry procdump 1848
Artefakt Prozess nicht auffindbar
63
Auswertungskategorie Code-Injection:
27. Rekall-Befehl malfind
Aufruf rekal -f .\wannacry --output malfind.txt malfind
Artefakt Mögliche VAD-Manipulationen an svchost.exe, searchfilterhost.exe,
explorer.exe
Anlage 23: malfind (Ausschnitt) (S.91)
28. Rekall-Befehl ldrmodules
Aufruf rekal -f .\wannacry --output ldrmodules.txt ldrmodules
Artefakt Keine Auffälligkeiten
Anlage 24: ldrmodules (Ausschnitt) (S.92)
Auswertungskategorie Netzwerkanalyse:
29. Rekall-Befehl dns_cache
Aufruf rekal -f .\wannacry --output dns_cache.txt dns_cache
Artefakt Nicht für 32-Bit-System verfügbar 159
30. Rekall-Befehl netstat
Aufruf rekal -f .\wannacry --output netstat.txt netstat
Artefakt Keine Ergebnisse
Anlage 25: netstat (S.93)
159 https://github.com/google/rekall/blob/master//rekall-core/rekall/plugins/windows/dns.py#L128
64
31. Rekall-Befehl netscan
Aufruf rekal -f .\wannacry --output netstat.txt --scan_kernel netscan
Artefakt Offener Port 9050 des Prozess 1804,
Verbindungen zu den IP-Adressen:
2.21.38.54,
13.107.4.50
86.59.21.38
93.184.221.240
94.75.194.221
95.101.0.136
158.69.92.127
188.68.37.135
213.61.66.117
Anlage 26: netscan (S.93)
Auswertungskategorie Disk-Artifacts:
32. Rekall-Befehl filescan
Aufruf rekal -f .\wannacry --output filescan.txt --scan_kernel filescan
(Das Schreiben des Output-Files wurde mit einem Fehler abgebrochen)
rekal -f .\wannacry --scan_kernel filescan
(Copy&Paste-Übernahme in filescan.txt)
Artefakt Auffällige Dateien:
\Device\HarddiskVolume1\Users\Default\Desktop\@[email protected]
e (abgelegt in verschiedenen User-Desktops)
\Device\HarddiskVolume1\Users\Default\Desktop\@[email protected]
mp (abgelegt in verschiedenen User-Desktops)
\Device\HarddiskVolume1\Users\IEUser\AppData\Local\Temp\hibsys.WN
CRYT (Beispielhaft, tritt auch bei verschiedene andere Dateien auf)
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\00000000.eky
65
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\00000000.pky
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\00000000.res
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\taskse.exe
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\taskdl.exe
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\lib
event-2-0-5.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\lib
gcc_s_sjlj-1.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\lib
ssp-0.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\zli
b1.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\lib
eay32.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\ssl
eay32.dll
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\f.wnry
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\ta
skhsvc.exe
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\ta
skhsvc.exe
\Device\HarddiskVolume1\tmp\Ransomware.WannaCry\TaskData\Tor\zli
b1.dll
\Device\HarddiskVolume1\tmp\@[email protected] (abgelegt in
verschiedenen Ordnern)
Anlage 27: filescan (Ausschnitt) (S.94)
33. Rekall-Befehl dumpfiles
Aufruf mkdir windows
rekal -f .\wannacry dumpfiles --dump_dir=windows
Artefakt Die vollständige Dump-Datei kann aus Platzgründen nicht in dem Bericht
gezeigt werden. Der Befehl wurde mit einem Fehler abgebrochen.
66
Es wurde ein Teil der in 31. gefundenen Dateien mit zusätzlichen
Analyse-Informationen extrahiert.
Anlage 28: dumpfiles (Ausschnitt) (S.95)
6.6 Das Ergebnisprotokoll
1. Prozess-Assoziation (Eltern-Kind)
Durch die Verlaufsschritte 1. und 3. ergaben sich drei verdächtige
Prozesse, die in einer parent-child Prozess-Abhängigkeit stehen. Diese
drei Prozesse sind dadurch Kandidaten für eine weitere
Detailuntersuchung.
2. Versteckte Prozesse
Durch den Untersuchungsschritt 2. konnte ein möglicherweise
versteckter Prozess identifiziert werden, zu dem aber in späteren
Analysen keine weiteren Informationen gefunden werden konnte. Der
Verdacht liegt nahe, dass es sich um einen legitimen Prozess handelt,
der bereits während der Dump-Erstellung beendet war, aber noch Reste
im RAM vorhanden waren.
3. Threads
Die Thread-Auswertung konnte Prozesse ermitteln, aus denen heraus
Windows-Socket-Funktionen ausgeführt wurden.
4. Pfadauswertungen
Es konnte keine Auffälligkeiten an den Prozesspfaden identifiziert
werden.
67
5. Services
Es konnten keine Auffälligkeiten identifiziert werden
6. Hives
Es konnten keine Auffälligkeiten identifiziert werden.
7. Handles
Es konnten Dateizugriffe von den Prozesse aus 1. und 3. identifiziert
werden. Allein daraus sind aber keine Schlussfolgerungen möglich.
8. Code-Injection
Durch die Code-Injection-Untersuchung in Verlaufsschritt 27. wurden
durch Malfind mögliche Prozesse identifiziert, bei denen eine
Code-Injection denkbar wäre. Allerdings hat sich dies als “false positive”
erweisen, da malfind diese Prozesse auch bei einer entsprechenden
neu-installierten Windows ohne Malware-Befehl auch aufgezeigt hat.
Diese spielen daher für eine weitere Untersuchung keine Rolle.
Die Ausführung von ldrmodules in Untersuchungsschritt 28. konnte keine
versteckten DLL-Einbindungen identifizieren.
9. DLL-Dateien
Die Auswertung der eingebunden DLL-Dateien der Prozesse aus 1. und
3. deuten auf eine Verwendung von Netzwerkfunktionen,
TOR-Funktionen und Verschlüsselungsfunktionen der Prozesse auf den
Schritten aus 1. bis 3. hin.
10.Netzwerkdienste
Der Prozess 1804 aus 1. und 3. stellt einen Socket 9050 und damit eine
mögliche Netzwerkkommunikation bereit. Allerdings ist der Port nur über
das lokale Netzwerkinterface erreichbar und damit nicht für
68
Internetzugriffe offen. Der Port 9050, der Default-Port für einen eigenen
Tor-Server, erlaubt eine Verbindung zum Tor-Netzwerk 160
11.Netzwerk-Zugriffe
Einige der IP-Adressen können als Exit-Nodes des Tor-Netzwerks
identifiziert werden und bestätigen die aktive Verwendung der
Tor-DLL-Dateien. - https://otx.alienvault.com/indicator/ip/86.59.21.38
- https://otx.alienvault.com/indicator/ip/94.75.194.221
- https://otx.alienvault.com/indicator/ip/158.69.92.127
- https://otx.alienvault.com/indicator/ip/188.68.37.135
12.Extraktion
Es konnte eine erfolgreiche Extraktion der Prozesse aus 1. und 3.
durchgeführt werden. Die .exe-Dateien dieser Prozesse können nun zu
einer weiteren Analyse in Ghidra oder Radare oder zur Übergabe an
Virustotal genutzt werden. Von Virustotal wurden diese als WannaCry 161
bestätigt.
160 https://wiki.ubuntuusers.de/Tor/Konfiguration/ 161 https://www.virustotal.com
69
Abbildung 18: Beispielhafte Übermittlung an Virustotal
13.Disk-Artifacts
Durch Extraktion der Dateien in Schritt 32. werden neben den
ausführbaren .exe- und DLL-Dateien noch andere Dateiformate
entdeckt. Dazu zählen verschlüsselte Dateien sowie Hintergrundbilder
für den Nutzer, die darüber informieren sollen, dass das System infiziert
wurde. Allerdings konnten nicht alle Dateien aufgrund eines
Rekall-Fehlers erfolgreich extrahiert werden.
Die Auswertung der vorliegenden Spuren erfolgte auf Basis der Checkliste und
offensichtlicher Artefakte. Einige der gefundenen Spuren hatten einen klaren
Bezug auf die Malware WannaCry, andere erwiesen sich als Fehlspuren. Der
Fokus dieser Untersuchung liegt auf der Malware WannaCry, es wurde
demnach keine vollständige Analyse aller vorhandenen Prozesse, Dateien und
Speicherbereiche durchgeführt. Es fand folglich ein Selektionsprozess statt,
aufgrund dessen es nicht auszuschließen ist, dass weitere digitale Spuren
vorhanden sind, die auf andere Angriffe von Malware hindeuten.
70
7. Fazit
Abschliessend kann festgehalten werden, dass es möglich ist mit Hilfe des
Analyse-Instruments Rekall den Verdacht eines Cyber-Angriffs durch die
Malware WannaCry hinreichend zu belegen. Wie aus dem Ergebnisprotokoll in
Kapitel 6.6 hervorgeht, lassen sich wesentliche Funktionsweisen wie die
Verwendung des Tor-Netzwerks sowie das Verlinken von DLLs zur
Verschlüsselung erkennen. Auch Indikatoren wie der Zugriff auf IP-Adressen
des Tor-Netzwerks sind zu finden. Eine Extraktion der Malware für spätere
weitere Analyseformen kann erfolgreich durchgeführt werden. Weiterhin ist es
mit Rekall möglich bestimmte maliziöse Aktionen von WannaCry
auszuschliessen bzw. als unwahrscheinlich einzustufen, da keine
entsprechenden Artefakte in den Windows-Services gefunden wurden.
Letztendlich liefert das Analyseinstrument Rekall lediglich die digitalen Spuren.
Für korrekte Schlussfolgerungen ist eine zusätzliche Interpretation der
Resultate notwendig. Ansonsten besteht die Gefahr von falschen Annahmen,
wie beispielsweise die Code-Injection-Untersuchung gezeigt hat.
Zu der Usability von Rekall kann gesagt werden, dass es sich um ein mächtiges
Analyse-Werkzeug handelt und einige wichtige Funktionen für die
Memory-Forensik bereitstellt. Allerdings muss während der Arbeit mit Rekall
immer wieder eine Internet-Recherche oder Verifikation des Source Codes
vorgenommen werden, um zu erkennen warum manche Befehle zu
Fehlermeldungen führen. So hat beispielsweise die Analyse der Memory
Dumps Version Windows 10 bei der Evaluierung des Labor-Szenarios einige
Schwierigkeiten bereitet.
Das Analyse-Instrument Memory Analyser, das als Alternative zu der
Rekall Shell getestet wurde, stellt sich entgegen der Projektbeschreibung als
“nicht-Rekall-fähig” heraus, so dass vor der Benutzung ein erheblicher
programmiertechnischer Aufwand notwendig war. Im Vergleich mit dem Rekall
71
Interpreter zeigten sich Vorteile bei der Verwaltung und der Visualisierung von
Untersuchungsergebnissen.
Es muss berücksichtigt werden, dass die exemplarische Untersuchung dieser
Arbeit durch die Bedingungen des Labor Szenarios (siehe Kapitel 6.1) und dem
Fokus auf der Malware WannaCry nicht als allgemeingültig angesehen werden
kann. Es existieren u.a. wesentlich komplexere Arten von Malware wie
beispielsweise Root-Kits. Zudem wurde die Analyse von Memory-Dumps
anderer Betriebssysteme in dieser Arbeit nicht betrachtet. Auch die
Herausforderungen, die durch den Einsatz von Anti-Forensik-Tools entstehen
können, wurden hier nicht berücksichtigt.
Abschließend darf nicht unerwähnt bleiben, dass die formellen Anforderungen
an die Sicherung digitaler Spuren (siehe Kapitel 3.2) durch den Einsatz von
Rekall grösstenteils erfüllt werden. Durch die parallele Entwicklung mit dem
Analyse-Werkzeug Volatility und der Integration in das Google Produkt GRR ist
das Kriterium der Akzeptanz gegeben. Die Frage nach der Robustheit kann
nicht nur positiv beantwortet werden, da sich vereinzelt Probleme mit speziellen
Versionen von Betriebssystemen und Python Installationen zeigen. Da die
praktische Memory-Analyse auf einem Abbild eines Images mit einer virtuellen
Maschine durchgeführt wurde, konnten keine Mängel bezüglich
Wiederholbarkeit und Integrität festgestellt werden. Um mit Rekall Ursache und
Wirkung einzelner Spuren miteinander sicherzustellen bedarf es spezieller
Sachkenntnis der großen Bandbreite von Rekall-Funktionalitäten. Eine
lückenlose Dokumentation in Form einer Chain of Custody ist durch manuelles
Kopieren der Einzelresultate möglich. Hier wäre allerdings eine automatisierte
Lösung wünschenswert.
72
Literaturverzeichnis
Ackermann R., Clages H., Roll H. 2019
Handbuch der Kriminalistik: Kriminaltaktik für Praxis und Ausbildung - 5. Auflage
Stuttgart Boorberg
Aljaedi A., Lindskog D., Zavarsky P. 2011
Comparative analysis of volatile memory forensics: Live response vs. memory imaging, in Privacy, Security, Risk and Trust
IEEE Third International Conference on Social Computing
Beebe N.L., Clark J.G. 2007
Digital Forensic text string searching: Improving information retrieval effectiveness by thematically clustering search result - http://www.sciencedirect.com/science/article/pii/S1742287607000412
San Antonio Digital Investigation
Brezinski D., Killalea T. 2002
Guidelines for Evidence Collection and Archiving, RFC 3227/BCP 55, www.ietf.org/rfc/rfc3227.txt
The Internet Society
BSI - Bundesamt für Sicherheit 2011
Bundesamt für Sicherheit in der Informationstechnik: Leitfaden „IT-Forensik“, Version 1.0.1
Bonn
Carrier B., Grand J. 2004
A hardware-based memory acquisition procedure for digital investigations, http://www.sciencedirect.com/science/article/pii/S1742287603000021
San Diego Digital Investigation
Carrier B., Spafford E.H., 2003
Getting Physical with the Digital Investigation Process
U.S.A. International Journal of Digital Evidence
Casey E. 2004
Digital Evidence and Computer Crime: Forensic Science, Computers, and the Internet, 2. Auflage
Baltimore Academic Press
73
Chhetri, Amrit, 2015
Computer Forensics Practical Guide: Investigating Computer Attacks
Bloomtington, Booktango
Chow J., Pfaff B., Garfinkel B. 2005
Shredding your garbage: reducing data lifetime through secure deallocation - http://dl.acm.org/citation.cfm?id=1251398.1251420
Berkeley USENIX Security Symposium
Dewald, Andreas; Freiling, C. 2016
Forensische Prinzipien: von digital zu cyber, 2. Auflage
Norderstedt Books on Demand
Geschonnek A. 2014
Computer Forensik: Systemeinbrüche erkennen, ermitteln, aufklären - 6. Auflage
Heidelberg dpunkt
Halderman J.A., Schoen S.D., Heninger N. 2009
Last we remember: cold-boot attacks in encryption keys - http://doi.acm.org/10.1145/1506409.1506429
Comm. ACM
Heinson. D. 2015
IT-Forensik Tübingen Mohr Siebeck
Johansen G. 2017
Digital Forensics and Incident Response: An intelligent way to respond to attacks
Birmingham Packt Publishing
Ligh M.H., Case A., Levy J. 2014
The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and MAC Memory
Indianapolis John Wiley & Sons, Inc.
Ligh M.H., Adair S., Hartstein B. 2011
Malware Analyst’s Cookbook and DVD - Tools and Techniques for Fighting Malicious Code
Indianapolis John Wiley & Sons, Inc.
Monnappa K.A., 2018
Malware Analysis: Explore the concepts, tools, and techniques to analyse and investigate Windows malware
Packt Publishing
Osborne G. 2013
Memory Forensics: Review of Acquisition and Analysis Techniques, DSTO Defence Science and Technology Organisation
Edinburgh (Australia)
74
Okolicia J., Petersen G.L. 2010
Windows operating system agnostic memory analysis - The Proceedings of the 10th Annual DFRWS Conference
West Haven Digital Investigation
Russinovich M.E., Solomon D.A., Ionescu A. 2017
Windows Internals - Band 1: Systemarchitektur, Prozesse, Threads, Speicherverwaltung, Sicherheit und mehr - 7. Auflage
Heidelberg dpunkt.verlag
Schatz B. 2007
Bodysnatcher: Towards reliable volatile memory acquisition by software, http://www.sciencedirect.com/science/article/pii/S1742287607000497
Fairfield Gardens Digital Investigation
Schuster A. 2006
Searching for processes and threads in microsoft windows memory dumps - The Proceedings of the 6th Annual Digital Forensic Research Workshop
Lafayette Digital Investigation
Sikorski M., Honig A. 2012
Practical Malware Analysis - The Hands-On Guide to Dissecting Malicious Software
San Francisco William Pollock
Tushabe F. 2004
The Enhanced Digital Investigation Process Model
Baltimore The Digital Forensic Research Conference
Vidas T. 2007
The Acquisition and Analysis of Random Access Memory, Journal of Digital Forensic Practice, https://doi.org/10.1080/15567280701418171
Journal of Digital Forensic Practise
Vidas T. 2010
Volatile memory acquisition via warm boot memory survivability
43rd Hawai International Conference on System Science
Vidstrom A. 2002
PMDump - http://ntsecurity.nu/toolbox/pmdump/
75
Vömel S., Freiling F.C. 2011
A survey of main memory acquisition and analysis techniques for the windows operating system
Elsevier Digital Investigation
Walthers, A., Petroni, N. 2012
Integrating Volatile Memory Forensics into the Digital Investigation Process
Mainland, Komoku
Wernert, M. 2017
Internetkriminalität - Grundlagenwissen, erste Maßnahmen und polizeiliche Ermittlungen - 3. Auflage
Stuttgart Boorberg
76
Abbildungsverzeichnis
Abbildung 1 Übersicht der Cyberangriffe im Jahr 2018 in Deutschland
7
Abbildung 2 Kaspersky’s Klassifikationsbaum von Malware 13
Abbildung 3 Das Investigative Process Model nach Casey 20
Abbildung 4 IDIP Modell nach Carrier und Spafford 21
Abbildung 5 High-Level-Darstellung der Prozess-Ressourcen 32
Abbildung 6 Schematische Darstellung eines Packing /Unpacking Vorgang anhand einer .exe im PE-FormatS
38
Abbildung 7 Übersicht Bewertung der Sicherungstechniken 42
Abbildung 8 Virtualisierung Windows 7 Zielsystem 43
Abbildung 9 Übersicht Setzen der Variablen für Start debug Modus 44
Abbildung 10 Bestätigung erfolgreicher Start debug Modus 45
Abbildung 11 Übersicht entpackte Malware WannaCry in der VM 46
Abbildung 12 Bestätigung der erfolgreichen Erstellung des Memory Dumps
46
Abbildung 13 Beispielhafte Meldung der Malware WannaCry 48
Abbildung 14 Sicherheitslücke Exploit CVE-2017-0144 49
Abbildung 15 Start von Rekall in einer Windows Powershell und Ausführung von imageinfo
51
Abbildung 16 Memory Analyser mit Rekall Extension 54
Abbildung 17 Memory Analyse Resultate und Projektinformationen des Projekts cridex
55
Abbildung 18 Beispielhafte Übermittlung an Virustotal 70
77
Tabellenverzeichnis
Tabelle 1 Übersicht der Klassifikation Malware 11
Tabelle 2 Aufbau des PE-Formats 31
Tabelle 3 Aufbau des Process-Memory 33
Tabelle 4 Aufbau PEB Struktur 34
Tabelle 5 Übersicht geplante Verkauf Rekall Befehle für die Analyse
56
78
Anlagenverzeichnis
Anlage 1) pslist
79
Anlage 2) psscan
80
Anlage 3) pstree
81
Anlage 4) psxview
82
Anlage 5) procinfo für Prozess 2260
83
Anlage 6) procinfo für Prozess 2632
84
Anlage 7) procinfo für Prozess 1804
Anlage 8) threads für Prozess 2260
Anlage 9) threads für Prozess 2632
85
Anlage 10) threads für Prozess 1804
Anlage 11) Pfad-Auswertung
Anlage 12) svcscan (Ausschnitt)
86
Anlage 13) Hives
Anlage 14) dlllist für Prozess 2632
87
Anlage 15) dlllist für Prozess 1804
Anlage 16) dlllist für Prozess 2260
88
Anlage 17) handles für Prozess 2632
Anlage 18) handles für Prozess 1804
89
Anlage 19) handles für Prozess 2260
Anlage 20) procdump für Prozess 2632
Anlage 21) procdump für Prozess 1804
Anlage 22) procdump für Prozess 2260
90
Anlage 23) Malfind (Ausschnitt)
91
Anlage 24) ldrmodules (Ausschnitt)
92
Anlage 25) Netstat
Anlage 26) Netscan
93
Anlage 27) Filescan (Ausschnitt)
94
Anlage 28) Dumpfiles (Ausschnitt)
95
Selbstständigkeitserklärung
Hiermit erklären wir, dass wir die vorliegende Arbeit mit dem Titel
Malware-Spurensuche im Arbeitsspeicher
unter Verwendung des Analyse-Instruments Rekall
selbstständig und ohne unerlaubte fremde Hilfe angefertigt, keine anderen als
die angegebenen Quellen und Hilfsmittel verwendet und die den verwendeten
Quellen und Hilfsmitteln wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht haben.
Berlin, 29. Juli 2019
Anja Kutzner
Robert Utzig
Tobias Koehler
96
![Index [] · ISO 27005 74, 107, 414 ISO 27006 74, 450 ISO 31010 87, 299 ISO 9000 Malware siehe Schadsoftware431 ISO 9001 75, 403, 409 IT Business Continuity Management 118, 150 IT-Forensik](https://img.pdfslide.org/doc/110x75/5ac7d04b7f8b9a51678bbc70/index-27005-74-107-414-iso-27006-74-450-iso-31010-87-299-iso-9000-malware.jpg)
