Tatort Internet: Operation am offenen Herzen

Inhaltsverzeichnis

Es ist Freitagmittag und ich freue mich auf ein frühes Wochenende, als mein Handy klingelt. Am anderen Ende der Leitung vernehme ich die aufgeregte Stimme von Wolfgang, der soeben einen Anruf seiner Bank bekommen hat, dass sein Bankkonto vorübergehend gesperrt ist. Seine Bankdaten seien auf einem russischen Server aufgetaucht und von seinem Konto wurden bereits 2000 Euro abgebucht.

Es ist einer der wenigen Samstagnachmittage, an denen die Sonne scheint. Ich überlege gerade, wie viel Fleisch ich wohl für den geplanten Grill-Abend einkaufen soll, als mein Handy klingelt. Mit nervöser Stimme eröffnet mir Hans, dass er sich anscheinend ’nen Virus eingefangen habe.

Als ich zurückfrage, wie er denn darauf komme, gerät der sonst so selbstsichere Maschinenbaustudent ins Stottern: „Äh, naja, ich hab mir doch gestern einen neuen Rechner gekauft, inklusive Microsoft Office. Allerdings nur als 30-Tage-Testversion und ich hatte kein Geld mehr für die Vollversion. Und da dachte ich …“, „… da lad ich mir mal eben einen Crack runter und spar mir das Geld“, vervollständige ich den Satz. „Und jetzt passieren auf einmal seltsame Dinge auf deinem System, stimmt’s?“

„Genau, aber woher weißt Du…?“, wundert sich Hans. Ich denk insgeheim: „Weil jeden Tag ein Dummer aufsteht“, während ich ihm ruhig erkläre, dass er keineswegs der Erste ist, der sich mit solchen Problemen an mich wendet.

Dann zieh ich ihm die Fakten Stück für Stück aus der Nase: Nach dem Start des angeblichen Cracks verschwand die ausführbare Datei wie von Zauberhand vom Desktop. Sonst passierte nichts – jedenfalls nichts Sichtbares. Doch seitdem signalisierte der Router quasi permanenten Internet-Verkehr, obwohl keine Anwendungen gestartet waren, die Traffic hätten produzieren können. Nach einem Neustart war kurz Ruhe und dann ging das Geblinke der Router-LED erneut los. Da Hans noch etwas bei mir gut hat, schwing  ich mich auf mein Fahrrad und mach mich auf den Weg zu ihm.

Ein erster Blick auf das System und mein siebter Sinn sagen mir, dass ich hier an der Oberfläche nicht fündig werde, sondern deutlich tiefer bohren muss. Zu dumm, dass ich mein Memory-Dump-Analyse-System gestern im Büro gelassen habe. Also werd ich wohl den Rechner direkt analysieren müssen: lokales Kernel-Debugging – quasi eine Operation am offenen Herzen.

„No risk, no fun!“, schießt mir durch den Kopf, während ich in Gedanken die Ärmel hochkremple. Ganz real installiere ich von meinem schreibgeschützten USB-Stick Microsofts Debugging-Tools for Windows  – vor allem wegen des darin enthaltenen großartigen Debuggers WinDbg. Das benötigte .NET-Framework hat Hans offenbar bereits eingespielt.

Normalerweise läuft der Debugger auf einem separaten Analysesystem und kontrolliert von dort aus über ein serielles Kabel oder via FireWire den Rechner mit dem zu untersuchenden Code. Mangels eines separaten Computers muss ich jedoch lokal debuggen. Aber wozu gibt es Tools wie LiveKD von Mark Russinovich? Ich werf es gleich mit ins WinDbg-Installationsverzeichnis und kopiere zusätzlich noch das nützliche WinDbg-Script callbacks.wdbg von Moonsols ins Unterverzeichnis scripts\.

Los geht’s! Ich starte LiveKd mit dem Parameter –w, was den Debugger WinDbg aufruft. Zuvor fragt mich LiveKd noch, ob ich vom Microsoft Symbol Server http://msdl.microsoft.com/download/symbols die aktuellen Dateisymbole runterladen möchte. Klar will ich! Denn erst der bringt dem Debugger bei, an welchen Adressen die ganzen Windows-Funktionen und Datenstrukturen liegen. Da das von Windows-Version zu -Version verschieden ist und mit Sprache, Service Packs und sogar einzelnen Updates anders ausfallen kann, benötige ich stets die zum System passenden.

Als Erstes möchte ich klären, ob und vor allem wie tief sich der Schadcode im System verankert hat. Dabei hilft mir das Script callbacks.wdbg. Der Windows-Kern kennt verschiedene Events, bei deren Auftreten er Callback-Handler aktivieren kann. So löst etwa das Erzeugen eines neuen Prozesses ein Event aus, für das man sich beim Kernel als PspCreateProcessNotifyRoutine registrieren kann.

Fast jedes etwas anspruchsvollere Kernelmode-Rootkit, das mir in den letzten Jahren untergekommen ist, nutzt eine dieser Möglichkeiten, sich in den Start von Prozessen einzuklinken. So kann es Sicherheitssoftware schon beim Laden deaktivieren oder Usermode-Komponenten in vertrauenswürdige Windows-Prozesse wie svchost, winlogon oder services.exe einschleusen.

Also starte ich auf dem Kernel-Debugger-Prompt das Callback-Skript, das die Events der Reihe nach abklappert und alle dafür  registrierten Handler auflistet:

kd> $$><scripts\callback.wdbg 

Zugegeben – die KD-Syntax ist gewöhnungsbedürftig, aber wenn man sie drauf hat, ist es das mächtigste Werkzeug der Windows-Welt. Ich ignoriere die Fehlermeldungen über ein paar Symbole, die KD nicht auflösen kann, und konzentriere mich auf die gefundenen Callbacks: Keine für Create Process, Create Thread und die BugCheckCalls zeigen auf bekannte Windows-Funktionen im HAL und den NDIS- oder SMB-Treibern. Alles harmlos. Was mich allerdings stutzig macht, ist ein Eintrag unter Load Image Notify Callback, dessen Adresse 0x820d78eb offenbar in völlig unbekanntes Terrain zeigt.

Das lohnt einen zweiten Blick mit dem KD-Befehl !address 0x820d78eb. Der Debugger bestätigt prompt meine Befürchtung:

813ed000 - 01213000 
   Usage  KernelSpaceUsageNonPagedPool 

Der Nonpaged Pool des Kernels enthält in der Regel Daten, die immer direkt mit physikalischem Speicher verbunden sind – also nie auf die Festplatte ausgelagert werden. Dort legt der Kernel Datenstrukturen ab, die auch dann verfügbar sein müssen, wenn ein Page Fault zum Einlesen der Daten von der Festplatte tödlich wäre. Während der Behandlung eines Hardware-Interrupts des Festplatten-Controllers sollte man besser keine weitere Leseoperation starten.

Die dort abgelegten Daten sind Informationen zu Prozessen, Semaphoren, Mutexe und so weiter. So gut wie nie wird Speicher aus dem Nonpaged Pool für Code verwendet. Bisher habe ich in diesem Bereich nur dann Code beobachtet, wenn ein Rootkit im Spiel war – zuletzt bei einer Malware namens TDL. Sollte ich hier einen weiteren Abkömmling der TDL-Familie vor mir haben? Dann hat sich Hans auf seinem nigelnagelneuen System gleich ein recht fortschrittliches Kernel-Rootkit eingefangen.

Immer mehr Rootkits, darunter auch einige TDL-Varianten, nutzen eine spezielle Methode, um eigenen Code ausführen zu lassen. Windows unterhält einen Pool von sogenannten System Worker Threads, die beim Boot-Vorgang vom System-Prozess gestartet werden. Sie sind dazu gedacht, anderen Threads, wie denen zur Behandlung von Interrupts, Arbeit abzunehmen. Das passiert etwa, um möglichst schnell einen Code-Bereich zu verlassen, während deren Ausführung der Zugriff auf wichtige Systemressourcen gesperrt ist, oder schlicht, um die Stabilität wichtiger Kernel-Teile zu erhöhen.