Sie sind auf Seite 1von 20

Studienbrief 7 RAM Sicherung und Analyse

Seite 113

Studienbrief 7 RAM Sicherung und Analyse

7.1 Lernergebnisse

Nach Durcharbeitung dieses Studienbriefes besitzen Sie theoretische und prakti- sche Kenntnisse, um eine Sicherung und Analyse des Arbeitsspeichers durchzufüh- ren. Sie sind vertraut mit den technischen Grundlagen flüchtiger Speichermedien. Ebenfalls können Sie die Notwendigkeit dieses Vorgangs beurteilen und können Vor- und Nachteile, Einschränkungen sowie die Anforderungen an die hierfür speziellen forensischen Werkzeuge einschätzen.

7.2 Advance Organizer

Die forensische Analyse von Datenträgern ist heute meistens nicht mehr ausrei- chend, um weiterentwickelte Angriffe oder kriminelles Verhalten eines Anwenders nachzuweisen. Im Speziellen zieht eine ausschließlich durchgeführte Post-Mortem Analyse der Datenträger einen großen Verlust von Informationen – und somit auch von möglichen Indizien oder Beweisen – nach sich. Neben persistent verschlüssel- ten und damit im Rahmen einer Post-Mortem Analyse unzugänglichen Spuren sind dies beispielsweise Passwörter, aktuell laufende Prozesse, Schadsoftware oder Netzwerkverbindungen. Aus diesem Grund ist von einem zu untersuchen- den IT-System die Sicherung des Arbeitsspeichers von enormer Bedeutung. Die grundlegende Literatur für dieses Kapitel bildet das Buch von Ligh et al. [16].

7.3 Einleitung

In einer kurzen Einführung soll zunächst auf die technischen Unterschiede zu den persistenten Speichermedien eingegangen werden. Auch der Unterschied zwi- schen Post-Mortem- und Live-Analyse wird noch einmal hervorgehoben. Vor allem werden wir uns die Frage stellen, welchen Vorteil die Analyse des Arbeitsspeichers mit sich bringt.

Der Arbeitsspeicher oder auch Hauptspeicher wird meist mit dem Akronym RAM für seine englische Bezeichnung Random Access Memory bezeichnet. Im Gegensatz zu einem persistenten Speichermedium (also einem Datenträger, der die Daten dauerhaft speichert) wie einer herkömmlichen Festplatte, einem USB-Stick oder einer Speicherkarte für das Smartphone bzw. die Digitalkamera handelt es sich beim RAM um einen sogenannten flüchtigen sowie volatilen Speicher. Das bedeutet folgendes:

Random Access Memory

1. Flüchtigkeit: die Informationen können nicht dauerhaft persistent gespei- chert werden, sondern bleiben lediglich bei vorhandener Betriebsspannung erhalten. Eine Unterbrechung der Spannungsversorgung führt innerhalb einer kurzen Zeitspanne zu einem Verlust aller gespeicherter Daten.

Flüchtiger Speicher

2. Volatilität: der Hauptspeicher unterliegt einer sehr starken Fluktuation, da ständig Daten geschrieben, gelesen, verschoben oder überschrieben werden.

Volatilität

Soll

ma der Unverändertheit von Spuren mit großer Sorgfalt vorgenommen werden, da hier die Sicherung ohne Änderung des RAM meist nicht möglich ist. Dies ist ein

zentraler Unterschied zur Datensicherung bei herkömmlichen Datenträgern im Rahmen einer Post-Mortem Datenakquise. Als IT-Forensiker müssen Sie daher bei der Sicherung besonders auf die Wahl der forensischen Werkzeuge sowie auf geeignete Dokumentation achten, um die Veränderungen im RAM nachvollziehen

das RAM gesichert werden, so muss dies gemäß dem forensischen Paradig-

Sicherung vs. Verände- rung

Seite 114

Studienbrief 7 RAM Sicherung und Analyse

zu können, da Spuren auf Grund der RAM-Sicherung Ihnen als IT-Forensiker zuzuordnen sind.

Informationen im RAM

Der Arbeitsspeicher bietet dem IT-Forensiker eine Fülle von Informationen, die wichtige Spuren, Indizien und Beweise für die anstehende Ermittlung liefern kön- nen. Wie Sie in den kommenden Abschnitten sehen, finden sich beispielsweise Hinweise auf ausgeführte beziehungsweise aktuell laufende Prozesse und Dienste sowie geöffnete Netzwerkverbindungen. Des Weiteren lassen sich dort möglicher- weise entschlüsselte Chiffretexte oder zugehörige Entschlüsselungs-Passwörter auffinden (z.B. von einer Festplattenverschlüsselung mittels Truecrypt). Der Ar- beitsspeicher kann ebenso Auskunft über mögliche Schadsoftware geben oder solche Daten beinhalten, die der Anwender niemals abspeichern wollte, wie zum Beispiel E-Mails im Entwurf, Chatnachrichten oder kinderpornographische Schrif- ten, die nur im Browser angesehen wurden. Auch im Bezug auf Malware ist eine Analyse des Arbeitsspeicher unabdingbar, so lässt sich beispielsweise erkennen, in welchen Prozess sich das Schadprogramm eingehängt hat. Weitere Beispiele finden Sie in [1]. Zusammenfassend können im RAM folgende Informationen vorliegen:

• Laufende Prozesse und Dienste

• Geöffnete Netzwerkverbindungen

• Entschlüsselte Chiffretexte

• Entschlüsselungspasswörter

• Informationen zu angemeldeten Benutzern

• Ausgeführte Schadsoftware samt Aussage über deren Aktivitäten

• Flüchtige Dokumente wie Entwurfsdokumente oder online betrachtete Do- kumente.

Einschränkungen

Die Informationen im Arbeitsspeicher sind somit essentiell, um wertvolle Spuren auswerten zu können. Allerdings existieren die oben genannten Einschränkungen der Flüchtigkeit sowie Volatilität, die auf der Seite des IT-Forensikers zu beachten sind. Da es sich um flüchtige Daten handelt und diese somit einer hohen Fluktua- tion unterliegen, können wichtige Informationen lediglich fragmentiert vorliegen (weil diese nicht mehr im RAM alloziert sind) oder im ungünstigsten Fall bereits gänzlich überschrieben sein. Aus diesem Grund sind die Informationen im Ar- beitsspeicher lediglich für eine Analyse der jüngeren Vergangenheit nützlich [1]. Zusammenfassend unterliegt das RAM folgenden Einschränkungen:

• Flüchtige Daten (gehen ohne Spannungsversorgung verloren)

• Informationen können bereits überschrieben sein (Volatilität)

• Bietet daher lediglich Informationen aus jüngerer Vergangenheit

In den folgenden Abschnitten wird Ihnen die Sicherung und die Analyse des Speicherabbildes schrittweise an einem durchgängigen Beispiel veranschaulicht.

Kontrollaufgabe 7.1 K Erläutern Sie den Begriff der Volatilität und die damit verbundenen Nach- teile
Kontrollaufgabe 7.1
K
Erläutern Sie den Begriff der Volatilität und die damit verbundenen Nach-
teile bei der forensischen Untersuchung.

7.4

Sicherung des Arbeitsspeichers

Seite 115

Kontrollaufgabe 7.2 K Welche Informationen erhält der IT-Forensiker durch die Analyse des Ar- beitsspeichers?
Kontrollaufgabe 7.2
K
Welche Informationen erhält der IT-Forensiker durch die Analyse des Ar-
beitsspeichers?

7.4 Sicherung des Arbeitsspeichers

Die klassische Unterteilung in Sicherungsmechanismen des Hauptspeichers unter- Anforderungen scheidet Hardware- sowie Software-basierte Verfahren. Heute wird diese strenge Unterscheidung nicht mehr getroffen, stattdessen versucht man die Verfahren nach wesentlichen Anforderungen an den Sicherungsprozess einzustufen. Vömel und Freiling [31] nennen Verfügbarkeit (engl. availability) sowie Atomarität (engl. atomicity). Unter Verfügbarkeit verstehen Vömel und Freiling die Eigenschaft, dass keine besonderen Vorkehrungen am System vorab getroffen werden müssen (z.B. im Rahmen der strategischen Vorbereitung gemäß BSI-Modell) und dass eine Si- cherung auch ohne dezidierte Kenntnis über das zu sicherende Gerät gelingt – eine Sicherung also ’einfach’ technisch möglich ist. Mit Atomarität beschreiben Vömel und Freiling das Kriterium, dass während der Sicherung das System nicht ’gestört’ wird, also die Sicherung in einer atomaren Leseoperation ohne Unterbrechung durchgeführt wird. In 2013 haben Vömel und Stüttgen [32] dann die folgenden drei Anforderungen für eine forensisch einwandfreie (engl. criteria for sound memory acquisition) genannt:

1. Korrektheit: das forensische Abbild stimmt mit dem physikalischen Haupt- speicher soweit wie möglich überein. Mit diesem Kriterium haben die Au- toren vor allem die Manipulation durch Malware im Auge. Der Grad der Korrektheit ergibt sich aus dem prozentualen Anteil der Größe der korrekt gesicherten Speicherseiten in Relation zur gesamten Speichergröße.

Korrektheit

2. Atomarität: die Sicherung geschieht in einer atomaren Leseoperation ohne Unterbrechung (s.o.).

Atomarität

3. Integrität: dieses Kriterium vergleicht den Zustand des RAM (bzw. seines Snapshots) mit dem Zustand zu einem festen Zeitpunkt τ (der in der Pra- xis typischerweise ein Zeitpunkt ist, wenn der IT-Forensiker das System übergeben bekommt und noch keine eigenen Spuren hinterlassen hat). Der Grad der Integrität ist dann der prozentuale Anteil der seit dem Zeitpunkt τ unveränderten Speicherseiten in Relation zu allen Speicherseiten.

Integrität

Vömel und Freiling nennen in [31] eine Reihe von Sicherungsmöglichkeiten des Arbeitsspeichers und setzen diese in Relation zu ihren beiden Anforderungen ’Ver- fügbarkeit’ und ’Atomarität’ (siehe Abbildung 7.1). Das ideale Sicherungsverfahren besitzt eine hohe Verfügbarkeit und eine hohe Atomarität, befindet sich also rechts oben in Abbildung 7.1. Bei den tatsächlichen Verfahren müssen wir allerdings Ab- striche hinnehmen. Wir werden im Folgenden einige Sicherungsstrategien nennen und später für eine Auswahl davon weitere Details nennen:

Sicherungsmöglichkeiten

1. Die erste Sicherungsstrategie verwendet das Betriebssystem des Hosts im Kernel Modus (Kernel Level Applications). Wir werden darauf in Ab- schnitt 7.4.1 genauer eingehen. Nach Abbildung 7.1 ist die Verfügbarkeit sehr hoch, allerdings ist die Atomarität eher durchschnittlich, weil wir mit dem laufenden System arbeiten und daher mit anderen Prozessen konkurrieren. Außerdem verändern wir bei der Sicherung das RAM.

Kernel Level Applications

2. Die

zweite Sicherungsstrategie nutzt nicht das Betriebssystem des Hosts,

sondern greift direkt auf den Hauptspeicher zu (Hardware Bus-Based Tech-

nique). Dazu steht zum Beispiel ein Direct Memory Access (DMA) über die

Hardware Bus-Based Technique

Seite 116

Studienbrief 7 RAM Sicherung und Analyse

Abb. 7.1: Sicherungs- techniken in Relation zu den Anforderungen ’Verfügbarkeit’ und ’Ato- marität’, Quelle [31]

’Verfügbarkeit’ und ’Ato- marität’, Quelle [31] FireWire-Schnittstelle zur Verfügung, was wir in Abschnitt

FireWire-Schnittstelle zur Verfügung, was wir in Abschnitt 7.4.2 vorstellen. Da der FireWire-Zugriff sich als teilweise unzuverlässig erwiesen hat (im Hinblick auf Abstürze während der Sicherung und im Hinblick auf die Korrektheit, siehe [31]) und da zur Sicherung eine IEEE 1394-Schnittstelle verfügbar sein muss, wird dieses Verfahren im ’Koordinatenursprung’ von Abbildung 7.1 dargestellt.

Cold Booting

3. Bei der dritten Sicherungsstrategie greifen wir ohne das Host-Betriebssytem auf den Hauptspeicher zu, nachdem wir ein eigenes Betriebssystem gestartet haben, wie es zum Beispiel durch einen Cold Boot Zugriff möglich ist (Cold Booting in Abbildung 7.1). Wir werden das Cold Booting in Abschnitt 7.4.3 darstellen. Insgesamt schneidet es sehr gut im Hinblick auf Verfügbarkeit und Atomarität ab.

Hibernation Datei

4. Gängige Betriebssysteme speichern den Hauptspeicherinhalt in einer Hi- bernation Datei, bevor das System in den Ruhezustand (Suspend to Disc) wechselt. Unter Windows schreibt das Betriebssystem Teile des Hauptspei- chers in die Datei hiberfil.sys. Weiterhin legt Windows die RAM-Inhalte komprimiert ab und nutzt ein proprietäres Dateiformat. Daher kann die Aus- sagekraft der Hibernation Datei eingeschränkt sein. Weil viele Betriebssyste- me einen vergleichbaren Ansatz wie Windows nutzen, wird die Hibernation Sicherungsstrategie als ’eher’ verfügbar in Abbildung 7.1 dargestellt. Da das Betriebssystem vor dem Ruhezustand ausschließlich den RAM-Speicher sichern will, ist die Atomarität sehr hoch.

Virtualisierung

5. Eine weitere Sicherungsstrategie ist Virtualisierung, wie sie zum Beispiel im Umfeld von Hostern oder Cloud-Anbietern vorkommt. Gängige Virtualisie- rungslösungen bieten entweder einen Snapshot des gesamten Gastsystems an oder einen Export des Gast-RAM (z.B. VMware als .vmem-Datei auf dem Host). Die Atomarität dieses Ansatzes ist sehr hoch, weil das Gastsystem vom Host aus eingefroren werden kann, die Verfügbarkeit ist allerdings eher gering, weil eben Virtualisierung für das zu sicherende System vorausgesetzt wird.

Akzeptanz, Inte-

Gehen

wir noch kurz darauf ein, welche Konsequenzen der Einsatz eines Werk-

grität der Spuren

zeugs zur Sicherung des Arbeitsspeichers nach sich ziehen kann. Wie Sie aus den vorherigen Kapiteln bereits wissen, gelten die gleichen Anforderungen wie

7.4

Sicherung des Arbeitsspeichers

Seite 117

bei allen anderen forensischen Werkzeugen, also zum einen die Akzeptanz des Werkzeugs im forensischen und juristischen Umfeld, zum anderen sollen keine Daten des Systems verändert werden bzw. die Änderungen zwingend notwendig und deren Ursache ausführlich dokumentiert sein.

Da

insbesondere bei Nutzung des Host-Betriebssystems – ist eine Veränderung der zu sicherenden Daten die Regel und nicht die Ausnahme. Denn die ausführbare Sicherungsapplikation wird auf dem zu sicherenden System ausgeführt und daher in den Hauptspeicher geladen. In der Konsequenz müssen diese Änderungen am Zielsystem so gering wie nur möglich gehalten werden. Auch die Dokumentation der durchgeführten Schritte und Methoden sollte besonders genau erfolgen.

wir bei der Sicherung des Arbeitsspeichers in das laufende System eingreifen –

Als IT-Forensiker müssen Sie im Rahmen der Ermittlungen die Vor- und Nachteile einer Sicherung des Arbeitsspeichers gegeneinander abwägen, wenn möglich in Rücksprache mit dem Auftraggeber oder beteiligten Juristen. Dazu sollten Sie sich genaustens überlegen, welche Spuren/Indizien die spätere RAM-Analyse für das Ziel der IT-forensischen Untersuchung liefern kann. Sie müssen dann die Frage beantworten, ob der Eingriff in das laufende System aus forensischer Sichtweise überhaupt lohnenswert ist.

RAM wird typischerweise verändert

Abwägung

7.4.1 Sicherung mit Kernel Level Applications

Eine verbreitete Sicherungsstrategie ist die Nutzung spezieller Applikationen, Kernel Mode die das Host-Betriebssystem im Kernel-Modus verwenden. Daher verwenden Vömel und Freiling in Abbildung 7.1 die Bezeichnung Kernel Level Applications für diese Sicherungsstrategie. Im Unterschied zu User-Land-Anwendungen (User Level Applications in Abbildung 7.1) ist der Zugriff auf Hardware und Speicher- bereiche nicht eingeschränkt. Das Sicherungswerkzeug kann im Kernel-Mode alle verfügbaren Speicherbereiche referenzieren. Ein weiterer Vorteil ist, dass Mal- ware Verschleierungsmechanismen einsetzt, die das Auslesen der verwendeten Speicherbereiche unterbindet bzw. erschwert. Bei Sicherung im Kernel-Mode ist diese Verschleierung aus Sicht der Malware schwieriger und damit ihr Auftreten aus Sicht des IT-Forensikers unwahrscheinlicher.

Für die Sicherung des Arbeitsspeichers existiert eine große Auswahl an forensi- schen Werkzeugen 1 . Die konkrete Auswahl hängt davon ab, welches Betriebssys- tem zu sichern ist sowie welche Präferenzen im Hinblick auf kommerzielle Tools der IT-Forensiker hat. In der Liste auf dem Forensics Wiki finden sich die Klassiker von Moonsols, ManTech, Mandiant, EnCase sowie FTK.

Tools

Da Windows das am meisten verbreitete Betriebssystem ist, stellen wir in Bei- DumpIt spiel 7.1 eine Sicherungssoftware vor, die als Kernel Level Application das RAM sichert. Ein häufig verwendetes und kostenfreies Tool ist DumpIt, das von dem bekannten IT-Sicherheitsexperten Matthieu Suiche entwickelt wurde und über dessen Firma MoonSols bezogen werden kann 2 .

Beispiel 7.1: Sicherung des RAM mittels DumpIt unter Windows B Die Nutzung von DumpIt ist
Beispiel 7.1: Sicherung des RAM mittels DumpIt unter Windows
B
Die Nutzung von DumpIt ist sehr einfach. Nach dem Herunterladen des
ca. 100 KiB großen zip-Archivs von der o.a. Downloadseite von MoonSols
entpacken Sie das Archiv. Es enthält neben der ca. 200 KiB großen exe-Datei

1 http://forensicswiki.org/wiki/Tools:Memory _ Imaging

2 http://www.moonsols.com/wp-content/plugins/download-monitor/download.php?id=7

Seite 118

Studienbrief 7 RAM Sicherung und Analyse

auch eine Datei README.txt, die noch einmal explizit auf Folgendes hinweist: Reverse engineering is prohibited.
auch eine Datei README.txt, die noch einmal explizit auf Folgendes hinweist:
Reverse engineering is prohibited.
Die Datei DumpIt.exe kopieren Sie auf einen externen Datenträger (z.B.
einen USB-Stick), den Sie mit dem zu sichernden System verbinden. Das
Speicherabbild wird per Default in das gleiche Verzeichnis kopiert. Die
Readme-Datei sagt dazu: The raw memory dump is generated in the current
directory, only a confirmation question is prompted before starting.
Im obigen Screenshot sehen wir, dass die Datei DumpIt.exe vom Wechsel-
datenträger gestartet wurde, der als Laufwerk G: in das Dateisystem des
Hosts eingehängt ist. DumpIt zeigt dann an, dass der Hauptspeicher die
Größe 1511 MiB hat und auf dem USB-Stick noch über 4000 MiB Speicher-
platz zur Verfügung stehen. Wichtig bei großen Speicherabbildern von mehr
als 4 GiB ist die Formatierung des USB-Sticks, die für solche Dateien kein
FAT-Dateisystem sein darf. DumpIt schlägt als Speicherort für das Speicher-
abbild den USB-Stick vor, die zugehörige Datei enthält neben dem String
HACKERSPACE auch den aktuellen Zeitstempel im Dateinamen. Eine Bestäti-
gung mit ’yes’ initiiert die Sicherung des RAM auf dem USB-Stick.

Linux Auch für Linux gibt es Kernel Level Applications, die den Arbeitsspeicher unter Nutzung des Host-Betriebssytems sichern. Sie können z.B. den Linux Memory Extractor LiME 3 verwenden. LiME kann auch für die RAM-Sicherung von Android- Geräten genutzt werden. Bitte beachten Sie, dass aktuelle Linux-Kernel den Zugriff auf das RAM mittels des Geräts /dev/mem nicht ermöglichen, so dass der Befehl

#

dd

if=/dev/mem

of=ram.dd

keine RAM-Sicherung durchführt. Weitere Tools finden Sie z.B. im Forensicswiki.

3 https://github.com/504ensicslabs/lime

7.4

Sicherung des Arbeitsspeichers

Seite 119

Die Sicherung des Arbeitsspeichers unter Mac OS erfolgt zum Beispiel unter Zuhil- fenahme des Werkzeugs Mac Memory Reader 4 im Mach-O Format 5 . Mit folgendem Befehl lässt sich hier der Arbeitsspeicher sichern:

sudo

./MacMemoryReader

/Volumes/STORAGE/ram _ dump.mach-o

Mac OS

7.4.2 Hardware Bus-basierte Techniken

In diesem Abschnitt betrachten wir an Hand des Beispiels IEEE 1394 eine Möglich- FireWire keit zur Sicherung des Arbeitsspeichers, ohne eine Anwendung auf dem System auszuführen. Somit werden Änderungen am System gering gehalten. Der Zugriff wird allgemein über einen Hardwarebus durchgeführt, in unserem konkreten Beispiel über die FireWire Schnittstelle des Rechners – vorausgesetzt der Rechner besitzt eine solche Schnittstelle [1].

Diese Methode funktioniert selbst dann, wenn beispielsweise der Bildschirm des Rechners gesperrt und mit einem Passwort geschützt ist. Ist der Besitzer des Rech- ners nicht in der Lage, das Passwort zu nennen (z.B. weil er abwesend ist) oder verweigert er die Herausgabe, so lässt sich die Sicherung des Arbeitsspeichers mit Hilfe dieses speziellen Zugriffs über den IEEE 1394 Bus dennoch realisieren.

Über FireWire ist ein direkter Zugriff auf den Arbeitsspeicher des Rechners mög- lich, indem der ’Direct Memory Access (DMA)’ des FireWire Bussystems aus- genutzt wird. Der Direct Memory Access dient dazu, die Geschwindigkeit bei einer Datenübertragung zu erhöhen. Dies wird erreicht, in dem die Daten über den DMA-Controller direkt in den Arbeitsspeicher geladen werden. Das Betriebssystem mit einer vorhanden Passwortsicherung des Bildschirms kann somit umgangen werden [15].

Direct Memory Access

Verfügt das zu untersuchende System über keine FireWire Schnittstelle, so kann dieses optional z.B. über eine PCMCIA Karte nachgerüstet werden. Die Installation der benötigten Treiber erfolgt im Hintergrund auch bei einem gesperrten Rechner

PCMCIA-Karte

[15].

Da der FireWire-Zugriff sich als teilweise unzuverlässig erwiesen hat (im Hinblick auf Abstürze während der Sicherung und im Hinblick auf die Korrektheit, siehe [31]) und da zur Sicherung eine IEEE 1394-Schnittstelle verfügbar sein muss, wird dieses Verfahren im ’Koordinatenursprung’ von Abbildung 7.1 dargestellt.

Korrektheit

7.4.3

Cold Booting

Bei den bisherigen Sicherungsstrategien des RAM setzen wir voraus, dass sich das System des Verdächtigen im laufenden Zustand befindet. Der Verdächtige könnte jedoch beim Eintreffen der Ermittler versehentlich oder beabsichtigt das System ausschalten bzw. die Stromzufuhr des Rechners unterbrechen. In diesem Szenario bleibt dem IT-Forensiker jedoch eine kurze Zeitspanne, um mittels Cold Booting die Informationen im Arbeitsspeicher zu erhalten und anschließend zu sichern.

Cold Booting

Cold Booting nutzt aus, dass die in den Speicherbausteinen des Arbeitsspeichers gespeicherten Daten zwischen mehreren Sekunden bis Minuten lang verbleiben, bis sie nach Ablauf dieser Zeitspanne 6 unwiederbringlich verloren sind. Dies wird

Datenremanenz

4 http://www.cybermarshal.com/index.php/cyber-marshal-utilities/mac-memory-reader 5 https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/ MachORuntime/Reference/reference.html

6 Die Zeitspanne unterliegt Fertigungstoleranzen.

Seite 120

Studienbrief 7 RAM Sicherung und Analyse

als Datenremanenz bezeichnet. Durch eine zusätzliche Kühlung der Speicherbaustei- ne mittels Kältespray kann die Remanenzzeit erheblich verlängert werden. Cold Booting macht sich dies zu Nutze. Natürlich kann Cold Booting auch vom IT- Forensiker selber eingesetzt werden, z.B. weil andere Sicherungsstrategien versagt haben. Dann wird er vor dem Hard-Reset die Speicherbausteine kühlen.

Minimalen Kernel booten

Fallstricke

Beim Cold Booting wird nach Kühlung der Speicherriegel ein minimaler spezieller Kernel gebootet, der nur die Aufgabe hat, das RAM zu sichern oder nach Ver- schlüsselungsschlüsseln zu suchen. Der bootende Kernel befindet sich auf einem bootfähigen Datenträger, oft wird das ein USB-Stick sein, auf den auch direkt das Speicherabbild gesichert werden kann. Konzeptionell könnten die Speicherriegel auch in dezidierte Lesegeräte gesteckt werden, allerdings wird dieser Ansatz nicht genutzt.

Cold Booting erscheint noch eher eine akademische denn eine operative Technik zu sein. Mögliche Fallstricke von Cold Booting sind eine untypische Bootreihenfolge (z.B. die interne Festplatte steht an höchster Stelle), so dass der externe bootfähige Kernel nicht gestartet wird. Sicherheitsaffine Nutzer könnten auch das BIOS im POST (power-on self-test) dazu veranlassen, den Arbeitsspeicher zu überschreiben, falls ein unsauberes Beenden des Betriebssystems erkannt wurde.

Kontrollaufgabe 7.3 Nennen Sie die Anforderungen an Sicherungsstrategien des RAM.
Kontrollaufgabe 7.3
Nennen Sie die Anforderungen an Sicherungsstrategien des RAM.
Kontrollaufgabe 7.4 Begründen Sie für die Kernel Level Applications sowie die Virtualsierungs- Sicherungsstrategie die
Kontrollaufgabe 7.4
Begründen Sie für die Kernel Level Applications sowie die Virtualsierungs-
Sicherungsstrategie die jeweilige Lage im Koordinatensystem in Abbil-
dung 7.1.
Kontrollaufgabe 7.5 Welchen Vorteil bietet der FireWire Zugriff gegenüber einer herkömmlichen Sicherung des
Kontrollaufgabe 7.5
Welchen Vorteil bietet der FireWire Zugriff gegenüber einer herkömmlichen
Sicherung des Arbeitsspeichers?

7.5 Analyse des Arbeitsspeichers

In diesem Abschnitt wird Ihnen die Analyse des Arbeitsspeichers anhand eines Fallbeispiels detailliert veranschaulicht. Hierzu werden wir Ihnen die technischen Grundlagen und den Umgang mit dem verbreiteten Analysewerkzeug Volatility ausführlich darstellen, um Ihnen die Bearbeitung der Übungen zu erleichtern. Weiterführende Literatur und Informationen finden Sie im Buch The Art of Memory Forensics : Detecting Malware and Threats in Windows, Linux, and Mac Memory [16] sowie im Wiki des Analysewerkzeugs Volatility [11].

Vorwurf Drogenhandel

7.5.1 Fallbeispiel: Szenario

Als IT-forensischer Ermittler sollen Sie im Rahmen einer Hausdurchsuchung die Polizei begleiten, um eine Beschlagnahmung und Sicherung der IT-Geräte des Ver- dächtigen durchzuführen. Die Person wird verdächtigt, sich an Drogengeschäften

7.5 Analyse des Arbeitsspeichers

Seite 121

zu beteiligen und lebt alleinstehend, so dass (in diesem Beispiel) davon ausge- gangen werden kann, dass alle IT-Geräte nicht von einer dritten Person benutzt werden. Die Zuordnung digitaler Spuren zu einer natürlichen Person (nämlich des Verdächtigen) wird daher vorausgesetzt.

Als IT-Forensiker sollen Sie im Rahmen der Hausdurchsuchung Spuren sichern, um den Verdacht zu widerlegen oder bestätigen. Bei Ihrem Eintreffen befindet sich der Windows7-Rechner im laufenden Betrieb und ist nicht durch ein Administra- torkennwort geschützt. Sie können daher wie in Abschnitt 7.4.1 eine Sicherung des Arbeitsspeichers mittels des Host-Betriebssystems sowie des auf einem USB-Stick mitgebrachten Tools DumpIt durchführen. Nach Beschlagnahmung des Rechners und weiteren Geräten beginnen Sie in Ihrem forensischen Labor mit der Untersu- chung des Arbeitsspeichers. Hierzu verwenden Sie das Open Source Werkzeug Volatility 7 (siehe Abschnitt 7.5.2).

Volatility

7.5.2 Eine kurze Einführung in Volatility

Volatility ist ein Framework der Volatility Foundation, mit dessen Hilfe die Analyse des Arbeitsspeichers performant und mit sehr guten Ergebnissen durchgeführt werden kann. Die aktuelle Version 2.4 ist unter der GNU General Public License für Linux, Windows und MAC erhältlich. Volatility ist in Python implementiert.

Funktionalität von Volatility wird in Form von Plugins zur Verfügung gestellt. Plugins Volatility wird mit einer Reihe von Standardplugins ausgeliefert, die ein breites Gebiet abdecken. Weitere Plugins können je nach Bedarf manuell nachinstalliert werden. Da Volatility auf Python basiert, müssen die entsprechenden Bibliotheken in das System eingebunden sein.

Die Installationsanleitung des Frameworks sowie eine ausführliche Dokumenta- tion der integrierten Plugins finden Sie in der Readme-Datei 8 und im Wiki 9 . Je nach Installation wird Volatility mittels des Befehls python vol.py (bei manueller Installation) oder volatility (z.B. bei Installation in Kali) aufgerufen. Wir nutzen im Folgenden Letztere. Die Syntax ist wie folgt:

Syntax

$

volatility

[plugin]

-f

[image]

--profile=[profile]

Hierin ist plugin das verwendete Plugin (also der gewünschte Befehl von Volati- lity, vgl. z.B. mmls im Sleuthkit), image das verwendete RAM-Image (in unserem Fall also die Arbeitskopie dump _ copy.raw, siehe unten) und profile der Name des in Volatility verwendeten Profils des gesicherten RAM-Betriebssystems (in unserem Beispiel unten Win7SP1x86 für Windows 7 mit Service Pack 1 auf einer

 

x86-Architektur).

 

Hilfe zu Volatility erhalten Sie auf der Kommandozeile mit dem Flag -h, mit dem Flag --info gibt Volatility zahlreiche Informationen zu hinterlegten Profilen, verfügbaren Plugins usw. aus. Auszüge aus der Ausgabe zu --info finden Sie in Quelltext 7.1.

Hilfefunktion

7 http://www.volatilityfoundation.org/

8 https://github.com/volatilityfoundation/volatility/blob/master/README.txt

9 https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

Seite 122

Studienbrief 7 RAM Sicherung und Analyse

Q
Q

Quelltext 7.1: Plugin Hilfefunktion

#

volatility

--info

Profiles

--------

VistaSP0x64

-

A

Profile

for

Windows

Vista

SP0

x64

[REMOVED]

Win7SP1x86

-

A

Profile

for

Windows

7

SP1

x86

WinXPSP1x64

-

A

Profile

for

Windows

XP

SP1

x64

[REMOVED]

Scanner

Checks

--------------

 

[REMOVED]

Plugins

-------

apihooks

-

Detect

API

hooks

in

process

and

kernel

memory

[REMOVED]

imageinfo

-

Identify

information

for

the

image

 

[REMOVED]

7.5.3 Analyse mittels Volatility

Wir zeigen im Folgenden mittels beispielhafter Volatility-Plugins, wie die Analyse des Arbeitsspeichers durchgeführt wird. Wir arbeiten unter Kali Linux auf der Kommandozeile. Hierbei werden wir Schritt für Schritt vorgehen, um eine Aussage treffen zu können, ob sich der Tatverdacht bestätigen oder widerlegen lässt.

Integrität der

Zur

forensischen Untersuchung liegt als Mastercopy das von DumpIt erzeugte

Arbeitskopie

Speicherabbild dump.raw sowie dessen Arbeitskopie dump _ copy.raw vor. Zur ab- schließenden Überprüfung der Beweiskette werden die Prüfsummen der Abbilder mittels SHA-256 erstellt und verglichen.

$ sha256sum dump.raw dump _ copy.raw f13c3f8fd644caff6e1d17995ad32b732322bf0aa9a30e79f72f258c87fe507c dump.raw f13c3f8fd644caff6e1d17995ad32b732322bf0aa9a30e79f72f258c87fe507c dump _ copy.raw

Profil des Speicherabbilds

Plugin imageinfo

Bevor wir innerhalb des Speicherabbilds gezielt nach Spuren suchen, bestimmen wir dessen Profil. Unter dem Profil versteht man Details zu dem Betriebssystem, das auf dem gesichterten IT-Systems gelaufen ist, sowie Informationen zur Hardware

7.5 Analyse des Arbeitsspeichers

Seite 123

Architektur. Volatility bietet hierfür das Plugin imageinfo an. Die Aufrufsyntax von Volatility haben wir in Abschnitt 7.5.2 beschrieben.

Quelltext 7.2: Plugin imageinfo

#

volatility

imageinfo

-f

dump _ copy.raw

Volatility

Foundation

Volatility

Framework

2.4

Determining

profile

based

on

KDBG

search

 

Suggested

Profile(s)

:

Win7SP0x86,

Win7SP1x86

 
 

AS

Layer1

:

IA32PagedMemory

(Kernel

AS)

AS

Layer2

:

FileAddressSpace

(/forensic/dump _ copy.raw)

PAE

type

:

No

PAE

 

DTB

:

0x185000L

 

KDBG

:

0x8294ac28

 

Number

of

Processors

:

1

Image

Type

(Service

Pack)

:

1

 

KPCR

for

CPU

0

:

0x8294bc00

 
 

KUSER _ SHARED _ DATA

:

0xffdf0000

Image

date

and

time

:

2015-01-07

09:31:17

UTC+0000

Image

local

date

and

time

:

2015-01-07

10:31:17

+0100

 
Q
Q

Volatility hat einige Profile hinterlegt und sucht nach typischen Mustern, um das KDBG konkrete Profil zu bestimmen. Dazu nutzt es den Kernel Debugger Block, KDBG, dessen Adresse imageinfo zurückgibt. Die Suche nach dem Profil dauert eine ge- wisse Zeit. In unserem Beispiel sehen wir anhand von Quelltext 7.2, dass Volatility zwei Profile vorschlägt (siehe Suggested Profile(s)).

Das ist nicht ungewöhnlich, wenn Profile sehr ähnlich zueinander sind. Allerdings entnehmen wir dem Feld Image Type, dass es sich bei unserem Speicherabbild vermutlich um ein Windows 7 Service Pack 1 Betriebssystem handelt – andernfalls wäre das Feld Image Type leer (d.h. im Falle des Service Pack 0). Im weiteren Verlauf der Untersuchung nutzen wir dieses Profil. Wie in Abschnitt 7.5.2 erläutert, rufen wir daher im Folgenden Volatility stets mit dem Flag --profile=Win7SP1x86 auf, um Probleme bzw. eine falsche Interpretation des Abbilds auszuschließen.

Dem Address Space Layer1 Feld AS Layer1 entnehmen wir, dass der RAM von einer 32 Bit Architektur stammt. Zusätzlich sehen Sie als von imageinfo ausgege- bene Informationen die Anzahl der Prozessoren (in unserem Beispiel gibt es einen Prozessor), die Systemzeit zum Zeitpunkt der Sicherung (als Weltzeit sowie lokale Zeit) und weitere Angaben, die wir nicht näher im Detail betrachten werden.

Prozessliste

Im nächsten Schritt verschaffen wir uns eine Übersicht über die zum Zeitpunkt der Sicherung laufenden Prozesse. Hierzu verwenden wir das Plugin pslist. Dieses Plugin gibt alle Prozesse mit dem aufrufenden Programmnamen, der Prozess-ID (PID), der Elternprozess-ID (Parent Process ID, PPID), der Anzahl der Threads (Thds), dem zugehörigen virtuellen Offset im Arbeitsspeicher sowie weiterer In- formationen wie Anzahl der Handles sowie Beginn- und ggfls. Endzeitpunkt des

Prozesses an. In Quelltext 7.3 sehen Sie die gekürzte Ausgabe (durch

gekenn-

Service Pack 1

Weitere Informationen

Plugin pslist

Seite 124

Studienbrief 7 RAM Sicherung und Analyse

zeichnet) des Aufrufs des Plugins pslist. Mit dem Switch -P gibt Volatility die physikalischen Adressen aus.

Q
Q

Quelltext 7.3: Plugin pslist

#

volatility

pslist

-f

dump _ copy.raw

--profile=Win7SP1x86

Volatility

Foundation

Volatility

Framework

2.4

Offset(V)

Name

PID

PPID

Thds

----------

-----------------

------

------

------

[REMOVED]

0x85e164b8

dwm.exe

1072

800

3

0x8623bd40

explorer.exe

1136

912

22

0x86282d40

SearchIndexer.

1996

448

15

0x85db23f8

SearchProtocol

536

1996

8

0x86310bd0

svchost.exe

2056

448

9

0x845aed40

TrueCrypt.exe

3120

2940

4

0x862fbb38

mscorsvw.exe

3376

448

7

0x862a66d0

sppsvc.exe

3420

448

4

0x84637d40

svchost.exe

3456

448

21

0x846e1ab8

dllhost.exe

2428

592

12

0x846e1430

iexplore.exe

2440

1136

12

0x84706550

iexplore.exe

3028

2440

20

0x848e0998

TrustedInstall

792

448

11

0x849bbd40

iexplore.exe

4052

2440

21

0x8485bb78

wuauclt.exe

2616

848

4

0x84964518

IE11-Windows6.

1700

2616

8

0x84ae0d40

DumpIt.exe

3360

1136

2

0x84c43d40

conhost.exe

3300

376

2

[REMOVED]

Standardprozesse

Die Prozessliste aus Quelltext 7.3 zeigt uns wohlbekannte Prozesse wie den Datei- manager Explorer (explorer.exe, PID 1136) oder mehrere Instanzen des Internet Explorers (ieexplore.exe, PID 2240 oder PID 3028 mit Elternprozess 2240).

’Interessante’ Prozesse

Daneben sehen wir aber auch, dass zur Zeit der Sicherung eine Instanz des Ver- schlüsselungsprogramms Truecrypt (TrueCrypt.exe, PID 3120) ausgeführt wur- de, so dass darauf geschlossen werden kann, einen oder mehrere verschlüsselte Truecrypt-Container auf einem persistenten Datenträger (z.B. der internen Fest- platte, einem beschlagnahmten USB-Stick) vorzufinden. Des Weiteren ist zu be- obachten, dass während der Sicherung das Sicherungsprogramm DumpIt lief (DumpIt.exe, PID 3360). Zumindest dieser Prozess ist eine Veränderung am RAM, die von uns im Rahmen der Sicherung des Hauptspeichers verursacht wurde. Bevor wir der Spur von verschlüsselten Truecrypt-Containern nachgehen, legen wir zunächst das Augenmerk auf Netzwerkverbindungen.

Plugin pstree

Alternativ stellt das Plugin pstree alle zum Zeitpunkt der Sicherung laufenden Prozesse in einer Baumstruktur dar, wobei Kindprozesse jeweils durch Einrücken dargestellt werden. Die sonst dargestellten Informationen sind die gleichen wie bei dem Plugin pslist.

Plugin psscan

Das Plugin psscan wird genutzt, um auch kürzlich beendete Prozesse zu finden. Weiterhin findet psscan auch versteckte (’hidden’) sowie ausgehängte (’unlinked’) Prozesse, wie sie vor allem von Keyloggern, Rootkits oder anderer verschleiernder Malware genutzt werden.

7.5 Analyse des Arbeitsspeichers

Seite 125

Netzwerkverbindungen

Zur Ausgabe der Netzwerkverbindungen gibt es je nach Betriebssystem bzw. Be- triebssystemversion unterschiedliche Volatility Plugins. Für Windwos Vista, Win- dows 2008 Server sowie Windows 7 Speicherabbilder ist das Plugin netscan zu verwenden, für die etwas älteren Windows XP Versionen sowie Windows 2003 Server wird das Plugin connscan eingesetzt. Da unser Snapshot das Betriebssystem Windows 7 beinhaltet, nutzen wir in Quelltext 7.4 das Plugin netscan.

Plugin netscan

Quelltext 7.4: Plugin netscan # volatility netscan -f dump _ copy.raw --profile=Win7SP1x86 Volatility Foundation
Quelltext 7.4: Plugin netscan
#
volatility
netscan
-f
dump _ copy.raw
--profile=Win7SP1x86
Volatility
Foundation
Volatility
Framework
2.4
Offset(P) Proto Local Address
Foreign
Address
[REMOVED]
0x5e1263b8 TCPv4 10.0.2.15:49271 62.154.232.97:80
0x5e12da08 TCPv4 10.0.2.15:49270 62.154.232.83:80
0x5e147df8 TCPv4 10.0.2.15:49322 62.138.116.3:80
0x5e14bdf8 TCPv4 10.0.2.15:49332 54.231.0.153:443
0x5e152b08 TCPv4 10.0.2.15:49298 62.138.116.15:80
0x5e159bb0 TCPv4 10.0.2.15:49277 62.154.232.83:80
[REMOVED]
0x5e234830 TCPv4 10.0.2.15:49299 62.138.116.15:80
0x5e235890 TCPv4 10.0.2.15:49302 46.4.85.238:80
0x5e23b2f0 TCPv4 10.0.2.15:49296 62.138.116.15:80
0x5e283528 TCPv4 10.0.2.15:49303 46.4.85.238:80
0x5e3745f8 TCPv4 10.0.2.15:49432 224.0.0.252:80
0x5e39e5d8 TCPv4 10.0.2.15:49428 224.0.0.252:80
0x5e39f008 TCPv4 10.0.2.15:49441 65.55.252.71:443
[REMOVED]

netscan liefert wie in Quelltext 7.4 dargestellt Informationen zu lokalen und ent- Informationen fernten Layer3- und Layer4-Adressen bzw. -Ports, das Layer4-Protokoll sowie das Offset im physikalischen Hauptspeicher. Weiterhin gibt netscan die PID und den Namen des zugehörigen Prozesses aus samt Zeitstempel der Erzeugung des Sockets sowie den Status der Verbindung (diese Informationen sind in Quelltext 7.4 nicht dargestellt und durch ' ersetzt).

'

Q
Q

In unserem Beispiel-Snapshot sind mehrere Verbindungen vom lokalen System zu Webservern über das Standardprotokoll HTTP (Port 80) bzw. über das Sicherheits- protokoll TLS (Port 443) geöffnet. Zur Auflösung der IP-Adressen der angefragten Server zu ihren menschenlesbaren URLs können wir Reverse DNS-Lookup-Dienste oder -Programme wie nslookup oder dnswatch 10 nutzen. Beispielsweise gehört die IP-Adresse des HTTP-Servers 62.138.116.3, der lokal mit dem Port 49322 kommu- niziert, zum Webserver der Domain www.spiegel.de. Wir werden gleich mittels der Registry sehen, welche Domains zu den anderen IP-Adressen gehören, d.h. der Reverse DNS-Lookup gelingt mit Informationen aus unserem Snapshot selber. Interessant ist noch die Abfrage nach dem Standort des unter einer IP-Adresse erreichbaren Dienstes, wie Sie es beispielsweise mit utrace 11 recherchieren kön- nen.

Reverse DNS-Lookup

10 www.dnswatch.info

11 www.utrace.de

Seite 126

Studienbrief 7 RAM Sicherung und Analyse

Windows Registry

Hintergrund zur Registry

Registry

Im Arbeitsspeicher des Rechners befindet sich ebenfalls die Windows Registrie- rungsdatenbank (Windows Registry). Bei dieser Datenbank handelt es sich um eine hierarchische Datenbank, um zentrale Konfigurationseinstellungen des Windows Betriebssystems, seiner Anwendungen und seiner Nutzer zu hinterlegen. Da die darin gespeicherten Informationen während des Betriebs abgefragt werden, wird die Windows Registry beim Start in den Arbeitsspeicher geladen und dort vorge- halten. Mittels Volatility finden wir dort also Informationen über das Benutzer- und Hardwareprofil sowie die installierten Anwendungen und weitere systemrelevante Einstellungen.

Die Windows Registry ersetzt seit Windows 3.x die meisten INI-Dateien und wird nach Microsoft [19] definiert als eine

zentrale hierarchische Datenbank, in der wichtige Informationen über System- konfiguration, Benutzer, Anwendungen und Hardwaregeräte abgelegt sind.

Die Registry besteht aus einer Gruppe von Schlüsseln (’keys’), Unterschlüsseln (’subkeys’) und jeweiligen Werten (’values’).

Hive

Tabelle 7.1: Wurzelschlüs- sel der Windows Registry

Plugin hivelist

Bei der Registry-Datenbank handelt es sich nicht nur um eine einzelne Da- tei, sondern sie setzt sich aus mehreren diskreten Dateien zusammen, den sogenannten Hives. Die Hives befinden sich mit Ausnahme des Schlüssels HKEY_CURRENT_USER im Ordner SystemRoot/System32/Config. Eben genannter Schlüssel ist je nach Benutzer im Verzeichnis SystemRoot/Profiles/<Benutzername> abgelegt [20, 21]. Informationen zu den Wurzelschlüsseln, die jeweils einen Zweig der Registry festlegen, finden Sie in Tabelle 7.1.

Schlüssel

Beschreibung

HKEY_CURRENT_USER

Informationen über den derzeit angemel- deten Benutzer und dessen profilgebun- denen Konfigurationen.

(HKCU)

HKEY_USERS (HKU)

Enthält Informationen über alle angeleg- ten Benutzerprofile auf dem Rechner.

HKEY_LOCAL_MACHINE

Enthält spezifische Konfigurationsin- formationen für den Rechner. Diese Konfigurationen gelten für alle Benutzer des Computers.

(HKLM)

HKEY_CLASSES_ROOT

Dieser Schlüssel bietet eine Sicht aller Anwendungskonfigurationen, d.h. benut- zerspezifische (HKEY_CURRENT_USER) und systemweite Einstellungen (HKEY_LOCAL_MACHINE).

(HKCR)

HKEY_CURRENT_CONFIG

Dieser Schlüssel enthält das Hardware- profil des Rechners.

(HKCC)

Zum Einstieg in die Untersuchung der Windows Registrierungsdatenbank nut- zen wir das Plugin hivelist. Dieses sucht im Snapshot die virtuellen Adressen

7.5 Analyse des Arbeitsspeichers

Seite 127

der Hive Dateien und gibt zusätzlich den Verzeichnispfad zum Speicherort der zugehörigen Datei auf der Festplatte aus (siehe Quelltext 7.5).

Quelltext 7.5: Plugin hivelist

# volatility hivelist -f dump _ copy.raw --profile=Win7SP1x86 Volatility Foundation Volatility Framework 2.4 Virtual Physical Name ---------- ---------- ---- 0x898429c8 0x0f56e9c8 \REGISTRY\MACHINE\HARDWARE 0x8b980008 0x045f4008 \Device\HarddiskVolume1\Boot\BCD 0x8b9809c8 0x045f49c8 \SystemRoot\System32\Config\SOFTWARE 0x918b69c8 0x02fe09c8 \SystemRoot\System32\Config\DEFAULT 0x919d79c8 0x04ef39c8 \??\C:\Users\eve\ntuser.dat 0x919fe448 0x02642448 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT 0x91a0f1f8 0x04da21f8 \SystemRoot\System32\Config\SECURITY 0x91a73870 0x08a8f870 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT 0x91ab2950 0x53df0950 \SystemRoot\System32\Config\SAM 0x95ea4410 0x55106410 \??\C:\System Volume Information\Syscache.hve 0x97e5e008 0x51316008 \??\C:\Users\eve\AppData\Local\Microsoft\Windows\UsrClass.dat 0x97f989c8 0x1a7699c8 \??\C:\Windows\System32\config\COMPONENTS 0x8980c5f0 0x025ec5f0 [no name] 0x8981a218 0x0f58c218 \REGISTRY\MACHINE\SYSTEM

Q
Q

Aus Quelltext 7.5 entnehmen wir, dass zum Zeitpunkt der Sicherung vermut- Beispielinformationen lich nur der Benutzer ’eve’ angemeldet war. Dessen Profil, das dem Schlüssel HKEY_CURRENT_USER (HKCU) entspricht, wird in seiner ntuser.dat Datei in seinem Benutzerverzeichnis gespeichert. Weiterhin sehen wir zum Beispiel, dass die SAM (Security Accounts Manager) in den Hauptspeicher geladen ist; in ihr fin- den wir unter Anderem die hinterlegten Passworthashes zur Nutzeranmeldung.

Unter den Netzwerkverbindungen haben wir gesehen, dass der Rechner des Ver- dächtigen mit mehreren Webservern verbunden war. Außerdem wissen wir aus der Prozessliste, dass mehrere Instanzen des Internet Explorers liefen. Wir wollen daher mit Hilfe der Registry weitere Informationen zu aufgerufenen Webseiten er- halten. Dazu müssen wir aber den richtigen Schlüssel (also Registry-Key) kennen, der diese Informationen speichert. Um alle Schlüssel innerhalb eines Registry- Zweigs zu sehen, können wir das Plugin hivedump verwenden. Es benötigt die virtuelle Adresse der zugehörigen Hive. Da wir uns für das Surfverhalten des Verdächtigen – und damit für nutzerbezogene Profilinformationen – interessieren, verwenden wir das Offset von HKEY_CURRENT_USER aus Quelltext 7.5, das in der Datei C:\Users\eve\ntuser.dat gespeichert wird. Beispielhafte Ausgaben

Plugin hivedump

Seite 128

Studienbrief 7 RAM Sicherung und Analyse

von hivedump für den Zweig von HKCU und darin für den Internet Explorer stellen wir in Quelltext 7.6 dar.

Q
Q

Quelltext 7.6: Plugin hivedump

 

#

volatility

hivedump

-f

dump _ copy.raw

--profile=Win7SP1x86

-o

0x919d79c8

Volatility

Foundation

Volatility

Framework

2.4

 

----------------------------

[REMOVED]

 

2014-12-10

12:03:49

\Software\Microsoft\Internet

Explorer\Suggested

Sites

2014-12-15

08:17:23

\Software\Microsoft\Internet

Explorer\TabbedBrowsing

2015-01-07

09:30:45

\Software\Microsoft\Internet

Explorer\TypedUrls

2014-12-10

12:02:28

\Software\Microsoft\Internet

Explorer\URLSearchHooks

2014-12-10

12:03:55

\Software\Microsoft\Internet

Explorer\User

Preferences

[REMOVED]

 

Unter den zahlreichen Ausgaben des Plugin hivedump stellen wir in Quelltext 7.6 exemplarisch 5 Registry-Keys von HKCU dar, die Informationen über die nutzer- bezogenen Informationen des Verdächtigen zum Internet Explorer vorhalten. Von besonderem Interesse für uns ist dabei der Registry-Schlüssel TypedUrls, denn dieser speichert die manuell eingegebenen URLs des Nutzers.

Plugin printkey

Wenn wir den Bezeichner sowie den Pfad eines Registry-Schlüssels kennen, so gibt uns das Plugin printkey den zugehörigen Wert des Schlüssels aus. Die Aufruf- syntax sowie die Ausgabe für den Schlüssel TypedUrls stellen wir in Quelltext 7.7 dar. Dem Switch -K übergeben wir den Pfad des Registry-Keys, für den wir uns interessieren.

Q
Q

Quelltext 7.7: Plugin printkey

 

#

volatility

printkey

-f

dump _ copy.raw

--profile=Win7SP1x86

\

 

-K

"Software\Microsoft\Internet

Explorer\TypedUrls"

 

Volatility

Foundation

Volatility

Framework

2.4

Legend:

(S)

=

Stable

 

(V)

=

Volatile

----------------------------

 

Registry:

\??\C:\Users\eve\ntuser.dat

Key

name:

TypedURLs

(S)

 

Last

updated:

2015-01-07

09:30:45

UTC+0000

Subkeys:

 

Values:

REG _ SZ REG _ SZ REG _ SZ REG _ SZ

url1

url2

url3

url4

:

(S)

http://spiegel.de/ http://shiny-flakes.com/ http://google.de/

 

:

(S)

:

(S)

:

(S)

http://go.microsoft.com/fwlink/?LinkId=69157

Key TypedUrls

Aus Quelltext 7.7 sehen wir, dass vier URLs im Registry-Schlüssel TypedUrls dauerhaft (also ’Stable’) gespeichert sind – also vermutlich vom Verdächtigen manuell eingegeben wurden. Dieser Registry-Schlüssel hat keine Subkeys, zuletzt wurde er am 07. Januar 2015 um 09:30 Uhr Weltzeit gespeichert. Unter den vier manuell eingegeben URLs sind drei vermutlich unverdächtige URLs, wir entdecken aber auch die URL http://shiny-flakes.com, die uns bei der Ermittlung interessiert. Der Screenshot der Webseite ist in Abbildung 7.2 dargestellt. Vermutlich hat diese Seite mit Drogen zu tun.

7.5 Analyse des Arbeitsspeichers

Seite 129

7.5 Analyse des Arbeitsspeichers Seite 129 Internet Explorer Nachdem wir nun Informationen mittels der Registry aus

Internet Explorer

Nachdem wir nun Informationen mittels der Registry aus dem RAM-Dump ex- trahiert haben, sehen wir uns Applikationsdaten an. Wir vermuten, dass der Ver- dächtige mittels des Internet Explorer die Drogenseite Shiny-Flakes betrachtet hat. Das Volatility Plugin iehistory gibt uns die vollständige Chronik des Inter- net Explorers aus – falls diese noch nicht gelöscht wurde. Dies hat zum einen den Vorteil, dass hierbei nicht nur die manuell eingegebenen URLs rekonstruiert werden, sondern ebenfalls die Navigation innerhalb der Webseiten inklusive der

Abb. 7.2: Überprüfung der Webseite shiny- flakes.com.

Plugin iehistory

Seite 130

Studienbrief 7 RAM Sicherung und Analyse

Zugriffszeiten. Weiterhin speichert die Chronik auch Zugriffe auf lokale Dateien. Der Aufruf sowie die Ausgabe des Plugins iehistory finden Sie in Quelltext 7.8.

Q
Q

Quelltext 7.8: Plugin iehistory

#

volatility

iehistory

-f

dump _ copy.raw

--profile=Win7SP1x86

Volatility

Foundation

Volatility

Framework

2.4

[REMOVED]

**************************************************

Process:

1136

explorer.exe

Cache

type

"URL

"

at

0x2ff5400

Record

length:

0x100

Location:

:2015010720150108:

eve@file:///H:/a1-250x250.jpg

Last

modified:

2015-01-07

10:29:40

UTC+0000

 

Last

accessed:

2015-01-07

09:29:40

UTC+0000

File

Offset:

0x100,

Data

Offset:

0x0,

Data

Length:

0x0

**************************************************

[REMOVED]

**************************************************

Process:

1136

explorer.exe

Cache

type

"URL

"

at

0x2ff5800

Record

length:

0x100

Location:

:2015010720150108:

eve@https://www.shiny-flakes.com

Last

modified:

2015-01-07

10:30:02

UTC+0000

 

Last

accessed:

2015-01-07

09:30:02

UTC+0000

File

Offset:

0x100,

Data

Offset:

0x0,

Data

Length:

0x0

**************************************************

[REMOVED]

**************************************************

Process:

1136

explorer.exe

Cache

type

"URL

"

at

0x2ff5a00

Record

length:

0x100

Location:

:2015010720150108:

eve@https://www.shiny-flakes.com/?post _ type=product

Last

modified:

2015-01-07

10:30:12

UTC+0000

 

Last

accessed:

2015-01-07

09:30:12

UTC+0000

File

Offset:

0x100,

Data

Offset:

0x0,

Data

Length:

0x0

**************************************************

[REMOVED]

In Quelltext 7.8 stellen wir von den zahlreichen Ausgaben von iehistory drei Einträge (Records) dar, die jeweils 256 Byte (also 0x100 Byte) belegen. Alle Einträge gehören zur Internet Explorer Instanz, die als PID 1136 läuft. Wir sehen, dass der Verdächtige vor dem Aufruf der Webseite shiny-flakes.com die lokale Datei a1-250x250.jpg betrachtet hat – vermutlich eine Bilddatei. Danach betrachtete der Verdächtige die wohlbekannte Hauptseite der Domain shiny-flakes.com und navigierte zehn Sekunden später zur Produktsuche.

Truecrypt

Passphrase im Cache? Im letzten Schritt unserer Untersuchung gehen wir dem Hinweis aus Quelltext 7.3 nach, dass auf dem System ein Truecrypt-Container lief. Wenn möglich, wollen wir die Passphrase des Containers aus dem Snapshot extrahieren. Dies ist davon abhängig, ob der Verdächtige beim Einhängen des verschlüsselten Containers die Passphrase gecached hat. Eine gecachede Passphrase erlaubt zum Beispiel

7.5 Analyse des Arbeitsspeichers

Seite 131

das automatische Einhängen eines Truecrypt-Containers beim Booten des Rech- ners oder das mehrmalige Mounten während einer Sitzung ohne erneute Eingabe der Passphrase. Aus Sicherheitsgründen ist eine gecachede Passphrase nicht zu empfehlen, wir hoffen aber, dass der Verdächtige Usability höher priorisiert als Si- cherheit. Andernfalls gewinnen wir zunächst nur die Information, dass vermutlich ein Truecrypt-Container genutzt wurde.

Volatility

Version 2.4 stehen die Plugins truecryptsummary, truecryptmaster sowie truecryptpassphrase standardmäßig zur Verfügung.

bietet für die Analyse von Truecrypt entsprechende Plugins. Ab

Quelltext 7.9: Plugin truecryptpassphrase # volatility truecryptpassphrase -f dump _ copy.raw --profile=Win7SP1x86
Quelltext 7.9: Plugin truecryptpassphrase
#
volatility
truecryptpassphrase
-f
dump _ copy.raw
--profile=Win7SP1x86
Volatility
Foundation
Volatility
Framework
2.4
Found
at
0x94ae2064
length
12:
antiforensik

Plugin truecryptpassphra- se

Q
Q

Wie anhand Quelltext 7.9 zu sehen ist, enthält das Speicherabbild die Passphra- se antiforensik zum Entschlüsseln des Truecrypt Containers, den wir z.B. im Rahmen der Post-Mortem-Analyse vom Datenträger sichern. Um weitere Infor- mationen aus dem Speicherabbild über den Container zu erhalten (beispielswei- se den Einhängepunkt, die Größe des Datenträgers, das im Container genutzte Dateisystem oder den verwendeten Verschlüsselungsalgorithmus samt Modus) können wir die bereits angesprochenen Volatility Plugins truecryptmaster oder

truecryptsummary verwenden.

Abschluss des Fallbeispiels

Abschließend wird erneut die Prüfsumme der analysierten Arbeitskopie des Spei- cherabbilds berechnet, um die Integrität der Arbeitskopie sicherzustellen. Quell- text 7.10 entnehmen wir, dass die Arbeitskopie unverändert ist.

Quelltext 7.10: Abschließende SHA-256 Hashwertberechnung

#

f13c3f8fd644caff6e1d17995ad32b732322bf0aa9a30e79f72f258c87fe507c

dump _ copy.raw

sha256sum

dump _ copy.raw

Integritätsprüfung

Q
Q

Während der RAM-Analyse kamen mehrere Spuren ans Tageslicht, die den vor- Ergebnisprotokoll geworfenen Verdacht des Drogenhandels bestätigen können. Im Snapshot des Hauptspeichers konnten wir Indizien finden, dass sich der Verdächtige auf einer einschlägigen Drogen-Webseite aufhielt, deren URL er manuell – also vermutlich bewusst – eingegeben hat. Wir haben ebenfalls einen verschlüsselten Truecrypt Container entdeckt, dessen Entschlüsselungspassphrase im RAM vorgehalten wur- de. Mit Hilfe dieser Passphrase können wir den Truecrypt Container im Rahmen einer Post-Mortem Analyse untersuchen.

Insgesamt haben wir nur wesentliche Schritte vorgeführt, so dass weitere Fra- gen ungeklärt bleiben. Diese sollen Sie in den Übungen dieses Kapitels selbst beantworten.

Übungen

Seite 132

Studienbrief 7 RAM Sicherung und Analyse

7.6 Zusammenfassung

In diesem Studienbrief haben Sie sich das Wissen eines wesentlichen Aspekts der Live Forensik angeeignet – der Sicherung und Analyse des Arbeitsspeichers. Sie sind sich der Vorteile sowie der Einschränkungen der RAM-Analyse bewusst. Es ist spezifisch von Fall zu Fall eine Abwägung über die Sinnhaftigkeit einer Sicherung und Analyse des Arbeitsspeichers durchzuführen.

Vorteile

Der Arbeitsspeicher bietet uns als IT-Forensiker zusätzliche Informationen, die nicht während der Post-Mortem Analyse des Datenträgers rekonstruiert werden können, beispielsweise detaillierte Informationen über laufende Prozesse, Dienste oder Netzwerkverbindungen, über den angemeldeten Benutzer sowie Passwörter bzw. Passphrases im Klartext. Solche Informationen sind typischerweise bei IT- forensischen Ermittlungen sehr hilfreich.

Nachteile

Allerdings unterliegt der RAM einer ständigen Fluktuation. Die Informationen sind also zeitlich kurz verfügbar. Des Weiteren ist bei dem Eingreifen in das System eine Veränderung unvermeidbar. Daher muss zum einen sichergestellt werden, dass diese Änderungen so gering wie möglich ausfallen, zum anderen sollten die Dokumentationsschritte besonders detailliert durchgeführt werden. Das eingesetz- te Sicherungswerkzeug sollte daher also nur geringst mögliche Änderungen am System durchführen.

Übung 7.1 Innerhalb der ersten Übung sollen detaillierter Aussagen über den angemel- deten Benutzer des
Übung 7.1
Innerhalb der ersten Übung sollen detaillierter Aussagen über den angemel-
deten Benutzer des Systems gemacht werden. In der Windows Registrie-
rungsdatenbank existieren Werte eines Schlüssel, welche einen Überblick
über die profilbezogenen Benutzerinformationen bieten. Finden und extra-
hieren Sie sowohl diesen Registrierungsschlüssel als auch die dazugehörigen
Werte mittels Volatility.
Hinweis: Verwenden Sie das Plugin printkey.
Übung 7.2 Die Windows Registrierungsdatenbank besitzt einen Schlüssel, der die Be- nutzernamen und dazugehörigen
Übung 7.2
Die Windows Registrierungsdatenbank besitzt einen Schlüssel, der die Be-
nutzernamen und dazugehörigen Passworthashes enthält. Recherchieren
Sie den Namen des Schlüssels und extrahieren Sie deren Inhalt. Mit wel-
cher kryptographischen Hashfunktion wurden die Passwörter der Nutzer
abgebildet, können die Klartextpasswörter wiederhergestellt werden?
Hinweis: Verwenden sie dazu die Volatility Plugins hivelist und hivedump