Tatort Internet: Eine Reise ins RAM
Seite 2: Die Analyse
Die Analyse
Nach diesem Vorspiel wird es langsam spannend. Für die weitere Analyse des Memory Dumps setze ich das mächtige Open-Source-Tool Volatility ein. Dieses komplett in Python geschriebene Framework extrahiert nützliche Informationen aus den für Menschen unleserlichen Memory Dumps.
Dazu analysiert Volatility zunächst die Kernel Processor Control Region (KPCR), die bei Windows XP immer an der festen Adresse 0xffdff000 abgelegt ist und praktischerweise Zeiger auf weitere Datenstrukturen des Windows-Kerns enthält. Über die hangelt es sich dann zu den eigentlich interessanten Strukturen wie der Liste der aktiven Prozesse weiter, die Windows ja ebenfalls permanent im Arbeitsspeicher vorhalten muss.
Der Vorteil gegenüber der klassischen Forensik ist, dass man ein richtiges Live-System analysiert und dabei auch flüchtige Informationen wie die aktuellen Netzwerkverbindungen untersuchen kann. Und anders als bei den Untersuchungen direkt „am lebenden Objekt“ ist man nicht auf ein möglicherweise kompromittiertes System angewiesen, das einem nur zeigt, was man sehen soll. Mit dieser Speicheranalyse via Volatility hab ich schon so manches Rootkit zur Strecke gebracht. Mal sehen, was wir bei Wolfgang finden.
Um mir zunächst einen Überblick zu verschaffen, lasse ich mir mit dem Volatility-Kommando pslist die Liste aller Prozesse anzeigen, die zum Zeitpunkt des Snapshots aktiv waren.
Doch das sieht alles recht normal aus; auf den ersten Blick sind keine auffälligen Prozessnamen zu entdecken. Das wäre dann wohl auch zu einfach gewesen.Also weiter im Programm. Die Liste der offenen Netzwerkverbindungen via connscan2 sieht schon vielversprechender aus.
Da sind gleich zwei aktive Verbindungen verzeichnet: eine zur IP-Adresse 67.228.216.3 auf Port 80 und eine zu 204.12.250.218 auf Port 8853. Und die Prozess-IDs 1372 und 616 gehören laut Prozessliste nicht etwa zu einem Browser-Prozess wie Iexplore.exe oder Firefox.exe, sondern zu Explorer.exe und Winlogon.exe. Was haben diese Systemprozesse im Internet zu suchen?
Treffer
Das sieht ganz so aus, als hätte ich meinen ersten Treffer gelandet. Es wäre nicht das erste Mal, dass sich Unrat in diese Prozesse einhängt, um von deren Rechten zu profitieren und unbemerkt von einer Firewall ein Schwätzchen mit dem Command & Control Server (C&C) im Internet zu halten.
Mal sehen, was die Registry sagt. Einfache Userland-Trojaner verewigen sich normalerweise dort über die bekannten Autostart-Keys. Windows hält immer eine aktuelle Kopie der Registry im Speicher und Volatility wird mir dabei helfen, diese genauer zu untersuchen. Leider geht das noch nicht ganz so komfortabel wie mit den grafischen Windows-Tools wie Autoruns, sondern erfordert etwas Handarbeit.
Die Registry ist über mehrere Dateien, die sogenannten Hives verteilt. Der Registry-Zweig des aktuellen Benutzers HKEY Current User (HKCU) befindet sich in der versteckten Datei NTUSER.dat im Home-Verzeichnis unter \Dokumente und Einstellungen\. Ein weiterer wichtiger Ast ist HKEY Local Machine (HKLM) und dort der Unterzweig Software aus \Windows\system32\config. Zunächst muss ich mir mit hivelist anzeigen lassen, wo Windows die Dateien in den Speicher eingeblendet hat.
HKCU verortet Volatility an der virtuellen Adresse 0xe1c0fb60 und HKLM/Software bei 0xe1479b60. Mit diesen Informationen gewappnet, kann ich mir via printkey einzelne Schlüssel anzeigen lassen und arbeite die übliche Autostart-Liste ab. Nach einigen Fehlschlägen werde ich bei HKLM\Software\Microsoft\Windows\CurrentVersion\Run fündig.
ctfmon.exe aus system32\ sieht noch so aus, als ob es da hingehört. Aber cleansweep.exe hat da definitiv nichts zu suchen. Zwar erinnere ich mich dunkel an ein legitimes Programm dieses Namens, aber erstens würde sich das bestimmt nicht ins Verzeichnis C:\cleansweep.exe\ kopieren und zweitens bestätigt mir Wolfgang, dass er nichts derartiges installiert hat.
Die Tarnkappe
Da hat sich der gute Wolfgang doch einen Online-Banking-Trojaner eingehandelt und mit der erhofften Entlastung durch den befreundeten Forensik-Experten kann ich wohl nicht dienen. Mal sehen, was ich sonst noch alles herausfinden kann. In der Regel kontrollieren derartige Schadprogramme andere Anwendungen, indem sie bestimmte Aufrufe von Windows-Funktionen auf eigenen Code umleiten. Durch dieses Hooking können sie sich dann unter anderem verstecken, indem sie etwa den eigenen Dateinamen aus einem Verzeichnis-Listing herausfiltern.
Jetzt schlägt die Stunde des Volatility-Plug-ins malware.py, das ursprünglich für das Malware Analyst’s Cookbook entwickelt wurde – ein wirklich empfehlenswertes Standardwerk der modernen Computer-Forensik. Wie vermutet, zeigt dessen Funktion apihooks beim Explorer-Prozess mit der PID 1372 eine ganze Reihe von Inline Hooks, bei denen der Funktionsanfang durch einen Sprungbefehl in einen Bereich bei 0xEAxxxxx überschrieben wurde.
Wie mir das „Unknown“ in der letzten Spalte signalisiert, gehört dieser Adressbereich nicht einmal zu einer DLL, sondern zeigt irgendwo ins Blaue. Der Winlogon-Prozess mit der PID 616 weist exakt dieselben Hooks auf.
Da ich das nicht zum ersten Mal mache, ist mir klar, was da passiert sein muss. Das Schadprogramm hat sich über eine Funktion wie VirtualAllocEx() Speicher im Kontext des Explorer-Prozesses reserviert und dann via WriteProcessMemory den eigenen Code dort reingeschrieben. Das ist spätestens seit dem wegweisenden Phrack-Artikel NTIllusion: A portable Win32 userland rootkit eine der Standard-Methoden, wie Trojaner andere Prozesse kapern, um sie für ihre eigenen Zwecke zu missbrauchen; also etwa an der Firewall vorbei nach Hause zu telefonieren.
Dass ich es hier tatsächlich mit Schadcode zu tun habe, der Rootkit-Funktionen einsetzt, belegt die Liste der entführten Funktionsaufrufe. Mit NtQueryDirectoryFile und NtVdmControl lässt man sich Dateien anzeigen. Wer diese Funktionen kontrolliert, kann entscheiden, welche Dateien der Anwender und auch der Viren-Scanner zu sehen bekommt. Dass sich auch das Registry-Pendant NtEnumerateValueKey darunter findet, zeigt mir, dass mein Ansatz der Speicheranalyse keineswegs mit Kanonen auf Spatzen geschossen hat. Jede Wette, dass ich mit herkömmlichen Analyse-Tools wie Autoruns & Co den verräterischen Registry-Key im laufenden Windows-System nicht zu sehen bekommen hätte; genauso wenig wie die Netzwerkverbindungen.
Ein Hook an der Funktion TranslateMessage wird oft eingesetzt, um Benutzereingaben abzufangen beziehungsweise aufzuzeichnen. Über Hooks an Socket-Funktionen wie HttpSendRequestA oder InternetWriteFile kontrolliert der Trojaner den Internet-Verkehr und kann etwa gesendete Daten abfangen oder manipulieren. Damit hat ein Online-Banking-Trojaner schon eine recht gute Basis für seine betrügerischen Aktivitäten.
