als PDF | 1,3 MB

PTFinder und PoolFinder – Identifikation von Prozessen und
anderen Objekten des Microsoft Windows-Betriebssystemkerns
in Arbeitsspeicherabbildern
Andreas Schuster
Helenenstraße 5c
53225 Bonn
E-Mail: [email protected]
30.06.2008
Zusammenfassung
Die Werkzeuge PTFinder und PoolFinder ermöglichen eine Betrachtung der von einem Microsoft Windows-Betriebssystemkern instantiierten Objekte unabhängig von den Enumerationsmechanismen des Betriebssystems. Im Rahmen einer forensischen Untersuchung machen diese Werkzeuge
sowohl bereits zerstörte, als auch aktive und in maliziöser Absicht verborgene Objekte des Betriebssystems sichtbar.
1
1
Stand der Forschung/Technik
Der Hauptspeicher eines Computers enthält umfassende Informationen über den Zustand der ausgeführten Programme. Die Folgen netzwerkbasierter Angriffe sind möglicherweise sogar nur im Hauptspeicher,
nicht aber auf einem Massenspeicher nachweisbar. Um so mehr überrascht, dass der Hauptspeicher in
der digitalen Forensik derzeit nur selten als Informationsquelle herangezogen wird.
S CHWEITZER [1] sowie J ONES, B EJTLICH und ROSE [2] beschreiben zwar Verfahren zur Sicherung des
Hauptspeichers, gehen dann aber nicht auf die Auswertung der Speicherabbilder ein.
So verwundert es nicht, dass sich bislang einzig die Suche nach Folgen druckbarer Zeichen als Standardverfahren zur Untersuchung von Speicherabbildern etablieren konnte. Typischerweise kommen hierzu
Programme wie das unter UNIX bekannte strings zum Einsatz. Diese sehr einfache Art der Auswertung
birgt jedoch drei entscheidende Schwächen:
1. Die meisten der interessanten Zeichenfolgen finden sich im Userland, dem einem Prozess zur exklusiven Nutzung zugewiesenen Arbeitsspeicher. Wie S OLOMON ET AL . [3] gezeigt haben, werden diese Daten binnen weniger Minuten nach Beendigung eines Prozesses durch das Betriebssystem erneut verwendet oder aber mit Nullbytes überschrieben .
2. Als schwerwiegendes Problem erweist sich der Verlust des Kontextes. Hierzu muss vorausgeschickt werden, dass der Arbeitsspeicher in gleichmäßig große Seiten unterteilt ist. Zuteilungen
an Prozesse erfolgen dabei jedoch nicht zusammenhängend. In benachbarten Seiten identifizierte
Zeichenfolgen werden deswegen häufig unterschiedlichen Prozessen zuzuschreiben sein. Unterbleibt die mühevolle Rekonstruktion der Zuordnung von Speicherseiten zu Prozessen, so besteht
die Gefahr der Fehlinterpretation.
3. Viele der für die IT-Forensik wichtigen Informationen liegen nicht als als Text vor. IP-Adressen,
Zeitstempel und zahlreiche weitere Meta-Daten über Objekte des Betriebssystemkerns sind gewöhnlich nur in binärer Form abgelegt. Mit dem dargestellten Verfahren lassen sich diese Informationen
daher in einem Speicherabbild nicht identifizieren.
Teilweise lassen sich diese Schwächen überwinden, indem man ein Speicherabbild mit einem Debugger analysiert. Programme dieser Art verstehen sich jedoch primär als Testhilfe zur Diagnose von Fehlern während der Entwicklungsphase einer Software. Typischerweise enumerieren Debugger Objekte
des Betriebssystems, zum Beispiel Prozesse und Threads, über die zu diesem Zweck vom Betriebssystem bereitgestellten Funktionen. Debugger sind deshalb allgemein nicht geeignet, in maliziöser Absicht
verborgene Objekte zu entdecken. Auch bereits wieder zerstörte Objekte wird ein Debugger nicht darstellen, da sie aus der Sicht des Betriebssystems nicht mehr existieren. Für forensische Zwecke wertvolle
Informationen bleiben daher ungenutzt.
Um die Entwicklung forensisch einwandfreier Werkzeuge zu stimulieren, veranstaltete der Digital Forensics Research Workshop im Jahr 2005 einen Wettbewerb [4]. Ausgehend von einem simulierten Angriff
auf einen Computer mit dem Betriebssystem Microsoft Windows 2000 wurden Abbilder des Arbeitsspeichers und einige ergänzende Dateien veröffentlicht. Die Aufgabe bestand darin, den Hergang und
die Auswirkungen des Vorfalls zu analysieren.
2
Zwei Programme, MemParser [5] von C HRIS B ETZ und KnTList [6] von G EORGE G ARNER und ROBERTJAN M ORA, gingen siegreich aus dem Wettbewerb hervor. Beide Werkzeuge enumerieren Objekte, indem sie die entsprechenden Funktionen des Betriebssystemkerns nachbilden. Damit unterliegen sie jedoch denselben funktionalen Beschränkungen, wie das Betriebssystem selbst: Maliziöse Software kann
einer Entdeckung entgehen und bereits beendete Prozesse und Threads sind nicht mehr nachweisbar.
3
2
Idee
Der Betriebssystemkern von Microsoft Windows ist objektorientiert. Die Daten eines Objekts werden in
Speicherbereichen des Kernels abgelegt, die Microsoft als Pools [7] bezeichnet. Für die Untersuchung
von Computern sind zwei dieser Pools von besonderer Bedeutung. Daten im paged pool können bei
Bedarf in eine Auslagerungsdatei verschoben werden, um freien Arbeitsspeicher für andere Zwecke zu
gewinnen. Besonders häufig benötigte Daten, und hierzu zählen die für die digitale Forensik bedeutsamen
Informationen über Gerätetreiber, Prozesse und Threads, werden hingegen in einem non-paged pool
permanent im Arbeitsspeicher gehalten. Allen Allokationen in den Pools stellt das Betriebssystem einen
kurzen Block von Verwaltungsinformationen, den POOL HEADER voran.
Abbildung 1 zeigt einen Auszug aus einem Arbeitsspeicherabbild in einem Hex-Editor. Der POOL HEADER
ist hier in rot markiert. In der rechten Spalte ist deutlich die Zeichenfolge ”Pro” zu erkennen. Hierbei
handelt es sich um das so genannte Pool Tag1 . Es weist darauf hin, dass dieser Speicherbereich für die
Verwaltung eines Prozesses alloziert wurde. In gleicher Weise sind Tags für die anderen Objekte des
Kernels und hunderte weiterer Datenstrukturen in Verwendung. Microsoft empfiehlt Programmierern
von Kerneltreibern, Pool Tags eindeutig einem Ausführungspfad zuzuordnen [8].
Abbildung 1: Prozess-Objekt des Betriebssystemkerns in einem Hauptspeicherabbild
Allen Objekten der Ausführungsschicht ist in ähnlicher Weise eine identische Datenstruktur vorangestellt. In Abbildung 1 ist sie blau hinterlegt. Diese OBJECT HEADER genannte Struktur ermöglicht
dem Betriebssystem eine einheitliche Verwaltung der durch Objekte repräsentierten Ressourcen.
Der OBJECT HEADER nennt unter anderem den Namen der betreffenden Instanz und wie viele andere Instanzen darauf verweisen. Wichtig ist ebenfalls ein Zeiger auf eine weitere Datenstruktur, die die
Klasse genauer beschreibt.
Klassen definieren üblicherweise individuelle Datenstrukturen. Im hier abgebildeten Beispiel eines Pro1 Tatsächlich
umfasst das Pool Tag vier Zeichen, hier sind es ”Proc”. Allerdings ist im vorligenden Fall das höchstwertige
Bit des vierten Zeichens gesetzt, um anzuzeigen, dass der Speicherbereich für Zwecke des Betriebssystemkerns selbst belegt
wurde.
4
zesses finden sich die spezifischen Daten des Objektes in einer Struktur namens EPROCESS. Ihr hier
grün unterlegter Datenbereich enthält unter anderem den Namen der Programmdatei. In der rechten
Spalte der Abbildung 1 ist er als Zeichenfolge dfrws2005.exe zu erkennen.
Es lassen sich also Datenstrukturen auf drei Ebenen unterscheiden:
1. Speicherverwaltung des Kernels
2. allgemeine Objektstruktur
3. spezifische Objektstruktur
Die zentrale Idee dieses Beitrags besteht darin, dass sich diese Datenstrukturen mit Hilfe eines Regelwerks in einem Abbild des Hauptspeichers identifizieren lassen. Anstatt also wie bisher Listen und
Baumstrukturen zu rekonstruieren, die dann auf die einzelnen Objektinstanzen verweisen, ist es so
möglich, das Speicherabbild nach den Objektinstanzen selbst zu durchsuchen.
2.1
Signaturen für Kernel-Objekte
Das Regelwerk basiert auf zwei unterschiedlichen Arten von Signaturen. Statische Signaturen erfordern
die exakte Übereinstimmung zwischen einem Bitmuster und dem Speicherabbild. Signaturen dieser Art
lassen sich induktiv durch Reverse-Engineering des Betriebssystemkerns gewinnen. Alternativ kann deduktiv eine statische Signatur als übereinstimmendes Bitmuster einer Menge bekannter Objektinstanzen
gebildet werden.
Als statische Signatur zur Erkennung von EPROCESS-Strukturn ist so zum Beispiel die Bytefolge 0x03
0x00 0x1b 0x00 geeignet. Die Bedeutung der einzelnen Zahlen ergibt sich aus der Definition der Datenstruktur: 0x03 bezeichnet Prozesse, während beispielsweise 0x05 eine Semaphore und 0x06 einen
Thread bezeichnen. Die Zuordnung von Nummern zu Objekttypen ist konstant von Windows 2000 bis
hin zum Windows Server 2008. Die zweite Zahl, 0x1b nennt die Länge der Datenstruktur in Einheiten
von 8 Bytes. Die Länge variiert zwischen den einzelnen Betriebssystem-Versionen. Für alle Instanzen
derselben Version ist sie konstant.
Dynamische Signaturen gehen zunächst von der Hypothese aus, eine gewünschte Datenstruktur gefunden zu haben. Sie interpretieren dann den Abschnitt im Speicherabbild gemäß der Strukturdefinition.
Schließlich überprüfen sie einzelne Elemente innerhalb der Struktur. Typischerweise wird hierbei getestet, ob sich der Wert innerhalb eines bestimmten Intervalls befindet oder komplexeren Bedingungen
genügt.
Ein Beispiel soll dies verdeutlichen: Prozess-Objekte enthalten Zeiger auf ihre Vorgänger und Nachfolger. Die Adressen dieser Objekte sind zunächst nicht bekannt. Aufgrund der Speicheraufteilung des Betriebssystems kann aber gefordert werden, dass diese Zeiger in einen bestimmten Bereich des Adressraums
verweisen müssen. Ein weiteres Kriterium lässt sich daraus ableiten, dass der Arbeitsspeicher mit einer
Granularität von 8 Bytes zugewiesen wird. Also müssen auch die mutmaßlichen Adressen ganzzahlig
durch 8 teilbar sein.
5
2.2
Implementierung
Diese einfache Idee wurde in zwei unterschiedlichen Werkzeugen umgesetzt. PTFinder identifiziert mit
Hilfe von insgesamt 20 Signaturen die spezifischen Strukturen von Prozessen [9]. Das Programm führte
die identifizierten Objekte mit ihrer Adresse und den wichtigsten Daten zunächst nur in einer tabellarischen Form auf. Um einem Betrachter die Interpretation der mitunter sehr umfangreichen Daten zu
erleichtern, wurde es um eine grafische Ausgabe erweitert. PTFinder erzeugt jetzt einen Graphen der
Eltern-Kind-Relation von Prozessen und Threads in der Beschreibungssprache DOT. Mit Hilfe der frei
erhältlichen Software GraphViz [10] lässt sich der Graph dann in einem gebräuchlichen Grafik-Format
darstellen.
Die Entwicklung des umfangreichen Regelwerks für PTFinder erforderte viel Zeit. Um das Funktionsprinzip bei geringem Aufwand auf eine große Anzahl unterschiedlicher Objektklassen anwenden zu
können, wurde ein zweites Werkzeug entwickelt. PoolFinder stützt sich allein auf den lediglich 8 Bytes
großen POOL HEADER. Die Schwierigkeit bestand hier darin, trotz dieser sehr kleinen Struktur Regeln
mit ausreichend hoher Selektivität zu entwickeln und dadurch falsch-positive Funde zu vermeiden.
Derzeit bildet PoolFinder aus 9 Regeln [11] ein gewichtetes Gesamtergebnis. Der Anwender kann über
einen Schwellwert bestimmen, ob er nur die zweifelsfrei identifizierten Allokationen, oder aber bei einem
entsprechend niedrigeren Schwellwert auch Überreste früherer Allokationen betrachten möchte.
Mit PoolFinder lassen sich sämtliche Objekte der Ausführungsschicht sowie mehrere hundert weitere Klassen von Allokationen in einem Speicherabbild nachweisen. PoolFinder beschränkt sich darauf,
die Position der Allokationen mit ihren wichtigsten Eigenschaften in einer Datenbank zu vermerken.
Um die Beispiel-Implementierung einfach und portabel zu halten, wurde als SQLite [12] als DBMS
gewählt. Das aktuelle Datenbank-Schema erlaubt es, die Resultate mehrerer Speicherabbilder in derselben Datenbank zu speichern. Änderungen zwischen Abbildern lassen sich deshalb leicht mit den SQLMengenoperatoren EXCEPT und INTERCEPT leicht bestimmen.
2.3
Ergänzungen
Einige Dienstprogramme ergänzen PoolFinder und unterstützen den Anwender bei der Detailanalyse
der gefundenen Speicherallokationen. PoolGrep durchsucht Allokationen nach einem regulären Ausdruck und meldet die jeweiligen Pool Tags. Geht man von bekannten Informationen, zum Beispiel einer
IP-Adresse in kanonischer Darstellung aus, so führt PoolGrep unter anderem auf Allokationen für TCPSockets und deren Pool Tags. Der Anwender identifiziert mit deren Hilfe zuerst den entsprechenden
Gerätetreiber, hier also tcpip.sys. In einem zweiten Schritt lässt sich die den Speicherblock anfordernde Funktion bestimmen. Die weitere Nutzung des Speicherbereichs, und damit das Datenformat, ist dann
mit den Techniken des Reverse-Engineerings bestimmbar.
PoolDump gibt alle Allokationen einer Klasse als Hexdump mit ergänzenden Informationen aus. Auch
dieses Werkzeug soll primär das Reverse-Engineering unterstützen. Abbildung 2 zeigt einen durch das
Rootkit Unreal.a [13] manipulierten Treiber-Eintrag. Nur sehr erfahrene Anwender werden die Manipulation in dieser Darstellung bemerken.
Für einen breiten Anwenderkreis müssen die Informationen jedoch einfacher zu erfassen sein. Hierzu
dient das Programm PoolView. Es interpretiert die Datenstrukturen, prüft einzelne Werte und warnt den
6
’Driv’ (P/-) at offset
0000: 06 00 1f 0a 44
0010: 68 31 a0 e1 01
0020: 00 00 00 00 00
0030: 04 00 a8 00 08
0040: 00 17 00 00 70
0050: 98 33 a0 e1 10
0060: 00 00 00 00 14
0070: 7e 93 a4 fc 7e
|
00d0: 7e 93 a4 fc 7e
00e0: 00 00 00 00 00
00f0: 00 00 00 00 00
0x01022d70
72 69 f6 78
00 00 00 00
00 00 00 00
22 0c 81 12
22 1b 81 48
d8 68 80 00
9d a4 fc 7e
93 a4 fc 7e
1c
00
00
00
2e
a1
93
93
34
00
00
00
0c
a4
a4
a4
e1
00
00
00
81
fc
fc
fc
0c
00
00
00
1c
33
7e
7e
00
00
00
90
00
9d
93
93
0c
00
00
a4
1c
a4
a4
a4
00
00
00
fc
00
fc
fc
fc
....Dri.x.4.....
h1..............
................
....."..........
....p"..H.......
.3....h.....3...
........˜...˜...
˜...˜...˜...˜...
93 a4 fc 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00
˜...˜...........
................
Abbildung 2: Darstellung eines manipulierten Treiber-Eintrags durch PoolDump.
Anwender bei unzulässigen und inkonsistenzen Daten. Abbildung 3 zeigt den gleichen Treiber-Eintrag
in der Darstellung durch PoolView.
Derzeit verarbeitet PoolView Daten von 20 Klassen. Das Programm befindet sich noch in einer frühen
Phase der Entwicklung und steht derzeit nur Ermittlungsbehörden und anderen besonderen Benutzergruppen auf Anfrage zur Verfügung.
Offset: 0x01022d70
Free: Object: 0x00000000 (SUSPECT object address detected!)
Extension: 0x810c2e48 (SUSPECT mismatching object and extension detected!)
Obj type: 0x00000000 (SUSPECT object type pointer detected!
Obj name: 0xe1a03168
Drv name: 0xe1a03398
Image base: 0xfca49000
Size: 0x00001700
Init: 0xfca49d33
Start info: 0x00000000
Unload: 0xfca49d14
Funct. 0: 0xfca4937e
...
Funct. 27: 0xfca4937e
Abbildung 3: PoolView übersetzt die Datenstruktur in eine leichter zu erfassende Form und weist auf
verdächtige Daten hin.
7
3
Nutzen
Der Hauptnutzen dieser Idee ergibt sich aus ihrer Unabhängigkeit von den üblichen Mechanismen zur
Verwaltung von Objekten.
1. Schadsoftware tarnt Kernelobjekte, die Hinweise auf maliziöse Aktivitäten geben könnten, indem
sie sie aus den zur Verwaltung genutzten Datenstrukturen entfernt. Da die Suche nach Kernelobjekten von diesen Verwaltungsdaten unabhängig ist, erweist sie sich als robust gegenüber den
Täuschungsversuchen.
2. Objekte, die ihre Aufgabe erfüllt haben, werden durch das Betriebssystem zerstört und aus den
entsprechenden Verzeichnissen entfernt. Für die digitale Forensik ist jedoch auch der Blick in die
Vergangenheit von großer Bedeutung. Zeigt die Gegenwart die Folgen eines Angriffs, so können
sich aus dem Vergangenen wertvolle Hinweise auf das Angriffswerkzeug und die ausgenutzte
Schwachstelle ergeben. Die Suche nach Kernelobjekten findet Spuren längst vergangener Objekte,
solange sie im Speicher noch nicht überschrieben wurden. Die Methode ist damit das Analogon
zur Wiederherstellung gelöschter Dateien, die schon lange ein unverzichtbarer Schritt in der forensischen Untersuchung von Massenspeichern ist.
Ein extremes Beispiel für Spuren bereits bereits gelöschter Objekte ist die Persistenz von Daten über
einen Neustart des Betriebssystems hinaus. Mit PTFinder konnte sie auf dem Digital Forensics Research
Workshop 2006 erfolgreich nachgewiesen werden [9]. Auch wenn dies unter realistischen Bedingungen
kaum wiederholbar sein dürfte, so demonstriert es eindrucksvoll die Leistungsfähigkeit der Methode.
3.1
Incident Response
Bei der Incident Response unterstützt die Visualisierung der Hierarchie von Prozessen und Threads mit
Hilfe von GraphViz die schnelle Analyse eines Systemzustands; ein starker Anfangsverdacht auf eine
Kompromittierung lässt sich einschließlich Datensicherung und Auswertung mit PTFinder in etwa einer
30 Minuten durchführen. Der untersuchte Host kann hierbei sogar im Produktivbetrieb verbleiben. Als
Beispiel für diesen Anwendungsfall soll hier ein Speicherabbild des Digital Forensic Research Workshops [4] dienen.
Mit PTFinder werden zunächst in dem Speicherabbild die Spuren aktiver und bereits beendeter Prozesse
identifiziert. Jedes Prozess-Objekt nennt neben der eigenen ID auch die des erzeugenden Prozesses.
Auf der Basis dieser Eltern-Kind-Relation erstellt PTFinder einen Graphen (siehe Abbildung 4). Seine
Knoten sind die Prozess-Objekte, seine Kanten entsprechen der festgestellten Abstammung.
Für jeden Prozess ist, jeweils von links nach rechts, seine numerische Prozess-ID, der gegebenenfalls auf
16 Zeichen gekürzte Name der Programmdatei und die Startzeit angegeben. Diese Daten werden direkt
aus der jeweiligen EPROCESS-Struktur gewonnen.
Grau hinterlegte Knoten markieren bereits beendete Prozesse. Zusätzlich zu den bereits genannten Informationen werden auch der Zeitpunkt der Beendigung und der vom Programm zurückgegebene Status
angegeben. Die grau hinterlegten Knoten symbolisieren zugleich diejenigen Objekte, die einzig durch
8
Abbildung 4: Hierarchie der Prozesse eines kompromittierten Hosts
die Suche nach Prozessobjekten, nicht aber durch die anderen zuvor genannten Methoden identifiziert
werden können.
Die Prozess-Hierarchie entwickelt sich von links nach rechts. Am linken Bildrand ist der Idle-Prozess
dargestellt, der den System-Prozess startet. Weitere stets gestartete Prozesse sind der Session Manager
(SMSS), das Client/Server Runtime Subsystem (CSRSS), Winlogon und das Local Security Authority
Subsystem (LSASS). Letzteres ist für die Authentisierung von Sitzungen und die Autorisierung von
Aktionen verantwortlich.
Abbildung 5: Erfolgreicher Angriff mit Metasploit gegen das LSASS
In der Vergrößerung (Abbildung 5) ist deutlich zu erkennen, dass aus dem Local Security Authority
Subsystem zwei Kindsprozesse hervorgingen – was sehr ungewöhnlich ist. Hinzu kommt, dass diese
beiden Prozesse mit metasploit.exe den Namen eines bekannten Angriffswerkzeugs [14] tragen.
9
In einem Fall hat der mutmaßliche Schadcode einen weiteren Prozess UMGR32.EXE gestartet. Der Name deutet zunächst auf den Windows User Manager, ein harmloses Dienstprogramm zur Verwaltung
von Benutzerkonten und -gruppen hin. Mit weiteren Informationen aus der EPROCESS-Struktur dieses
Prozesses ließ sich schließlich dessen Adressraum mit dem Programmcode rekonstruieren. Die weitere
Analyse zeigte, dass es sich jedoch um die bekannte Backdoor Back Orifice [15] handelt. In der Gesamtansicht wird deutlich, dass aus dieser Backdoor heraus das Programm dfrws2005.exe ausgeführt
wurde, was aber binnen einer Sekunde terminierte. Es gab dabei den Fehlercode 0 an das Betriebssystem
zurück, was gewöhnlich ”Erfolg” signalisiert.
Worin dieser Erfolg besteht, wird deutlich, wenn man (siehe Abbildung 4, rote Markierungen im oberen
Teil) nach weiteren Ereignissen in zeitlicher Nähe sowie nach Prozessen des selben Namens sucht. Beide
Ansätze führen auf eine weitere Instanz von dfrws2005.exe, die als Kindsprozess von services.exe
läuft.
Dies lässt vermuten, dass die erste gestartete Instanz von dfrws2005.exe sich als Systemdienst installierte. Der Service Control Manager services.exe startete dann die zweite Instanz. Die genaue Analyse
ergab dann, dass es sich bei dfrws2005.exe um das Rootkit ”Hacker Defender” [16] handelt. Wie die
Abbildung bereits andeutet, startete das Rootkit dann noch einen Netcat-Listener. Mit seiner Hilfe war
über einen TCP-Socket eine privilegierte Kommandozeile zu erreichen.
3.2
Datierung der Ausführung bestimmter Adressen
Aus den Meta-Informationen über einzelne Threads lässt sich ableiten, dass zu einem bestimmten Zeitpunkt Code an einer bestimmten Adresse ausgeführt wurde. Analog zu Prozessen sind hier ebenfalls der
Zeitpunkt der Beendigung des Threads und ein Statuscode verfügbar.
Im Falle einer forensischen Untersuchung gelang so der Nachweis, dass eine Schadsoftware bereits einen
Thread zur Zerstörung des Dateisystems gestartet hatte.
3.3
Auswirkungen forensischer Software auf das Untersuchungsgut
Forensische Software soll die ursprünglichen Spuren nur im absolut notwendigen Umfang verändern.
Mit Hilfe von PoolFinder lassen sich Veränderungen in den Speicherbereichen des Betriebssystemkerns
genauer beobachten, als dies mit konventionellen Methoden wie einem Kernel-Debugger möglich wäre.
Der Autor wird im August 2008 erste Ergebnisse auf dem Digital Forensics Research Workshop vorstellen [17]. Demnach sollte gerade Software zum Zwecke der forensisch einwandfreien Sicherung des
Arbeitsspeichers und der Incident Response äußerste Zurückhaltung bei der Instantiierung neuer KernelObjekte üben. Um möglichst viele Spuren zu erhalten, sollte ein derartiges Programm lediglich einen
einzigen Thread erzeugen und auch keine weiteren Kindsprozesse starten.
10
Abbildung 6: Meta-Informationen über Threads ermöglichen die Datierung der Ausführung bestimmter
Code-Abschnitte.
4
Marktchancen
Der Markt für Software zur forensisch einwandfreien Auswertung von Arbeitsspeicherabbildern ist noch
kaum entwickelt.
Im kommerziellen Sektor herrscht derzeit das nur ausgewählten Nutzern zugängliche KnTList vor. Dieses Programm verfolgt den konventionellen Ansatz und lokalisiert Kernelobjekte über die Verwaltungsmechanismen des Betriebssystemkerns. In enger Zusammenarbeit mit dem Autor, George Garner, stellt
PTFinder inzwischen über eine XML-Schnittstelle Informationen über aufgefundene Prozesse und Threads
zur Verfügung, um so die Analysequalität von KnTList zu verbessern.
Obwohl sich PTFinder ausdrücklich als Machbarkeitsstudie versteht, wurde das Programm in die zwei
Werkzeug-Sammlungen grml [18] und Helix [19] für Administratoren und Computer-Forensiker aufgenommen.
PTFinder ist bei Strafverfolgungsbehörden in aller Welt im Einsatz. R ICHARD M C Q UOWN von der
Milwaukee Police ergänzte PTFinder um das grafische Frontend PTFinderFE [20] und portierte [21] das
Suchverfahren in die Scriptsprache des gebräuchlichen kommerziellen Forensik-Programms EnCase von
Guidance Software.
Die Idee der Suche nach Objekten, das Regelwerk zur Identifizierung von Prozessen und Threads und die
Implementierung in der Open Source Software PTFinder wurden mit dem Best Paper Award des Digital
Forensic Research Workshop 2006 ausgezeichnet.
Im Rahmen seiner zeitlichen Möglichkeiten strebt der Verfasser die Anwendung des Prinzips der kontextunabhängigen Suche über Prozesse, Gerätetreiber und Threads hinaus auf die verbleibenden Objektklassen des Microsoft Windows Betriebssystemkerns an. Entsprechend den mit PTFinder und PoolView
gewonnenen Erfahrungen sollen die aufgefundenen Daten benutzerfreundlich aufbereitet und in Hierar-
11
chien und Zeitleisten visualisiert werden. Als ersten Schritt hierzu hat der Verfasser Funktionalität aus
PTFinder, PoolFinder und PoolView in Volatility[22], ein quelloffenes Framework für Anwendungen zur
forensischen Analyse von Arbeitsspeicherabbildern, eingebracht.
12
5
Literatur
[1] S CHWEITZER , D OUGLAS: Incident Response. Wiley Publishing, Indianapolis, 1. Auflage, 2003.
[2] J ONES , K EITH J., R ICHARD B EJTLICH und C URTIS W. ROSE: Real Digital Forensics : Computer
Security and Incident Response. Addison-Wesley Professional, 2005.
[3] S OLOMON , JASON, E WA H UEBNER, D EREK B EM und M AGDALENA S ZE ŻYNSKA:
User data persistence in physical memory.
Digital Investigation, 4(2):68–72, 2007.
doi:10.1016/j.diin.2007.03.002.
[4] D IGITAL F ORENSICS R ESEARCH W ORKSHOP: Memory Analysis Challenge, August 2005. Online. http://www.dfrws.org/2005/challenge/ (2008-06-01).
[5] B ETZ , C HRIS: MemParser, August 2005. Online. http://www.dfrws.org/2005/challenge/
memparser.html (2008-06-01).
[6] G ARNER , G EORGE M. und ROBERT-JAN M ORA: kntlist, August 2005. Online. http://www.
dfrws.org/2005/challenge/kntlist.html (2008-06-01).
[7] M ICROSOFT C ORPORATION, Redmond: POOL TYPE, Mai 2005.
microsoft.com/en-us/library/aa492492.aspx (2008-06-01).
Online. http://msdn2.
[8] M ICROSOFT C ORPORATION, Redmond: ExAllocatePoolWithTag, 2008. Online. http://msdn2.
microsoft.com/en-us/library/ms796989.aspx (2008-06-01).
[9] S CHUSTER , A NDREAS: Searching for Processes and Threads in Microsoft Windows Memory
Dumps. Digital Investigation, 3(Supplement 1):10–16, September 2006. doi:10.1016/j.diin.
2006.06.010.
[10] AT&T: Graphviz - Graph Visualization Software, Januar 2005. Online. http://www.graphviz.
org/ (2008-06-01).
[11] S CHUSTER , A NDREAS: Pool Allocations as an Information Source in Windows Memory Forensics.
In: G ÖBEL , O LIVER, D IRK S CHADT, S ANDRA F RINGS, H ARDO H ASE, D ETLEF G ÜNTHER und
J ENS N EDON (Herausgeber): IT-Incident Management & IT-Forensics – IMF 2006, Band P-97 der
Reihe Lecture Notes in Informatics, Seiten 104–115, 18 Oktober 2006.
[12] SQLite Home Page. Online. http://www.sqlite.org/ (2008-06-01).
[13] EP X0FF: Unreal.A, bypassing modern Antirootkits. Rootkit.com, 1 Februar 2007. Online.http:
//www.rootkit.com/newsread.php?newsid=647 (2008-06-01).
[14] The Metasploit Project. Online. http://www.metasploit.org/index.html (2008-06-01).
[15] C ULT OF THE D EAD C OW: Back Orifice 2000, 27 November 2004. Online. http://www.bo2k.
com/ (2008-06-01).
[16] HF: Hacker Defender, 18 September 2005. Online. http://www.rootkit.com/project.php?
id=5 (2008-06-01).
13
[17] S CHUSTER , A NDREAS: The impact of Microsoft Windows pool allocation strategies on memory
forensics. Digital Investigation (in print). doi:10.1016/j.diin.2008.05.007.
[18] P ROKOP, M ICHAEL: grml - Linux Live-CD for Sysadmins. Online. http://grml.org/ (2008-0601).
[19] E - FENSE , I NC ., Alexandria, VA, USA: Helix - Incident Response & Computer Forensics Live CD.
Online. http://www.e-fense.com/helix/ (2008-06-01).
[20] M C Q UOWN , R ICHARD: PTFinderFE Facts, 26 Oktober 2007. Online. http://forensiczone.
blogspot.com/2007/10/ptfinderfe-facts.html (2008-06-01).
[21] M C Q UOWN , R ICHARD: RAM Enscript, 22 November 2007. Online. http://forensiczone.
blogspot.com/2008/01/ram-enscript.html (2008-06-01).
[22] WALTERS , A ARON und N ICK L. P ETRONI: The Volatility Framework: Volatile memory artifact extraction utility framework. Online. https://www.volatilesystems.com/VolatileWeb/
volatility.gsp (2008-06-01).
14