Case study: the TDSS rootkit

This article is a case study of the TDSS malware, also known as Tidserv, TDSServ and Alureon. Some of its components are detected as Trojan.Win32.DNSChanger and Trojan.FakeAlert.

There are several reasons for conducting a detailed study of this malware:

Thus, TDSS is a borderline type of threat: sufficiently advanced to cause problems for AV, or even to defeat it completely, but not sufficiently critical to trigger a detailed study; widespread enough to cause numerous user issues, but not serious enough to trigger a full epidemic alert.

TDSS is known for its ability to bypass active protection/HIPS, for its outstanding persistence and its rootkit functions. Users with all kinds of anti-malware solutions have reported problems disinfecting their systems. Observable activity typically includes website redirects, ad popups and the blocking of AV updating/loading activities. Its functionality can vary widely though, since TDSS is designed as a modular unit and additional components can be downloaded and installed to provide extra features.

The first TDSS infection reports date back to the middle of 2008. Even at that time the malware showed extraordinary persistence, causing problems for users and demonstrating the ability to bypass anti-malware protection. Given that the malware’s creators have managed to keep this advanced functionality up to date for almost a year now, and given the malware’s code architecture and skilful implementation, we can assume that TDSS is being developed with a clear vision by a team of proficient engineers.

TDSS itself is a very advanced modular downloader. Its main goal is to persist in a system and to provide a means for remote control (via a downloaded configuration file) and a framework for downloading/installing modules for additional functionality.

TDSS is delivered to a PC through a wide and elaborate distribution network. Known attack vectors include website iframe attacks [3], [4] and bundling the malware with pseudo-legitimate video codecs [5], as well as legitimate software [6] and cracks [7] distributed via p2p networks.

Back in 2008, the presence of TDSS was marked by a driver named TDSSserv.sys (after which the malware was named). Since then, malware-related file names have changed several times, and have included clbdriver.sys, seneka*.sys, UACd*.sys, gaopdx*.sys, tdlserv.sys and others.

Another change is that recent samples patch msi.dll for their installation, while the early samples used to patch advapi32.dll. This is probably a reaction to the behavioural heuristics that have recently been added to security solutions.

In the most recent samples the code protection is designed to make the trojan look like a regular system file or a device-supporting utility. The unpacker stub is a big piece of regular code, which means there is no extra entropy throughout the file’s byte array (which is an easy-to-spot sign of a packed file). Furthermore, the code is enriched by random pseudo-legitimate ASCII strings and random API calls designed to fool a hasty analyst into thinking it is a legitimate piece of code.

The code protection itself is trivial: an easily removed envelope with normal code inside.

Most recent samples of TDSS contain worm functionality. The malware tries to distribute itself to removable drives by copying its own body into all available drives as a hidden *.com file in the hidden RECYCLER directory, and by creating the file autorun.inf, with the file reference on the same drive.

Most recent TDSS samples change systems’ DNS addresses, thus causing all the hostname requests to filter through a malicious service. This is a brilliant solution, probably inspired by the much-talked-about DNS root server vulnerability and the Evilgrade proof of concept [9]. Distributing a spoofed DNS provider throughout the network by means of a DHCP service gives an attacker control of the entire network’s web traffic, even as far as delivering malware to clean machines under the guise of a legitimate software update.

For analysis, I took a fairly recent sample, dated March/April 2009 (MD5: 1DE66FC07C7B5893F5F83B397AC38 F3D). It is a specimen of the TDSS variety quoted by Symantec Russia as being one of the most notable at the end of March [10], [11].

The general execution flow of an average TDSS specimen has already been described [9], [12] as have its basic mechanisms in userland [4]. A summary of the high-level functions of this particular sample is available from any public sandbox [13]. I will be focusing on the trojan’s most important features and driver functionality.

Trojan installation and protection bypassing

The trojan’s initial installation routine is notable, since it allows behavioural protection/firewalls to be bypassed. The idea is to force a legitimate service to load a legitimate, but maliciously patched DLL. This is achieved via the modification of the msi.dll file in the \knowndlls directory, followed by a regular launch of the Microsoft Installer service:

NtCreateSection(..”\knowndlls\dll.dll”..) // new section for a malicious dll
CopyFile(..”msi.dll”, <temporary_file>..) // preparing the dll to patch
WriteFile(..<temporary_file>, <malicious_code_injection>..) // patching

The injected code will call LoadLibrary, which will invoke the malicious dll mapped into the \knowndlls\dll.dll section. The shellcode is quite elegant:

push 7c906cbc ; pointer to ‘dll.dll’ – really this is a calculated pointer to the last part of the 
‘ntdll.dll’ name in the regularly mapped ntdll.dll

call $+5 ; call next instruction so that its address is on the stack

sub dword ptr [esp], 0a ; now the first dword on the stack points to the first shellcode instruction, meaning that LoadLibrary will return there. Shellcode will be replaced by original code by then.

mov eax, LoadLibrary

jmp eax ; call LoadLibrary (‘dll.dll’)

Once the infected dll has been prepared, the \knowndlls\msi.dll section is recreated to point to an infected dll, and the msiexec.exe service is started to force the now infected library to be loaded:

NtOpenSection(..”\knowndlls\msi.dll”..)

NtMakeTemporaryObject(..) // clear the OBJ_PERMANENT flag from section

CloseHandle(..)

NtCreateSection(..”\knowndlls\msi.dll”, .. <temporary_file>..) //recreate the msi.dll section, now pointing to the infected msi.dll library in 
<temp filename>

..

StartService (..”Windows Installer”..)

The main idea of this technique is that, since it is executed in the context of the Windows Installer, the malicious code will have all the necessary privileges to download and install anything. It downloads and installs a fresh build of the TDSS kernel component.

Another advantage of the technique is that no obviously malicious behaviour is exhibited, so a HIPS will fail here until it ‘learns’ this particular trick.

The dll.dll functionality itself is quite simple, as can be seen in the flowchart shown in Figure 1.

Figure 1. IDA-generated flowchart of the dll.dll.

The trojan hooks the following functions in the kernel:

The latter three hooks are implemented via SDT modification. The NtEnumerateKey hook is used to hide all the TDSS registry keys listed in the trojan’s configuration key (‘gaopdx*’ in this case), except for trusted processes. The NtQueryValueKey hook is used to spoof DNS addresses without modifying the registry (and therefore without triggering a HIPS registry alert), via a substitution of ‘DhcpNameServer’ and ‘NameServer’ [14] registry values.

Hooks to IofCallDriver and IofCompleteRequest are implemented by splicing the kernel code in ntkrnlpa.exe in memory. They are used to hide the trojan’s files and probably its network TCP activity.

A hook to IofCallDriver is used to infiltrate all the IRPs system wide, which allows the trojan to hide its own files (beginning with the string ‘gaopdx*’ in this case) when it catches an IRP to a file system driver:

If ( FsRtlIsNameInExpression (..”*\\gaopdx*” or “*\\TEMP\\gaopdx*”..) )

Then return (STATUS_TOO_MANY_SECRETS) 

IofCompleteRequest has a similar functionality.

push 0    ; argument to the command

push ‘VERG’  ; 4-byte command, allowing to prove the hook is in place

push ‘TDL2’ ; a magic value which leads execution to the command processor and not to the 
original API

call ds:ZwFlushInstructionCache ; this is a piece of code from the dll.dll component, checking 
for the presence of the core driver.

Manual disinfection of TDSS is trivial. The following instructions are for a generic method that will completely remove any specimen of the TDSS family. This removal method is suitable for any end-user, since it is very simple and requires neither special skills nor specific tools:

Note that steps 1–4 must be carried out manually, without any anti-malware, because if an anti-malware product lacks a single signature for a trojan’s core file, the file will not be removed and the malware will return after reboot.

Behavioural protection/HIPS developers should consider keeping an eye on the behaviours/actions that allow TDSS to succeed:

Although most of these actions are not malicious by themselves, they clearly pose a minor threat and thus should be considered in combination, supplied with reasonable threat weights, and within a particular process execution context.