tdl3 analysis paper, papers, security, rootkits
[ Pobierz całość w formacie PDF ]
TDL3: Part I
“Why so serious? Let’s put a smile …”
A detailed analysis of TDL rootkit 3
rd
generation
By
Nguyễn Phố Sơn
– npson at cmcinfosec.com
I.
Introduction
TDL or TDSS family is a famous trojan variant for its effectiveness and active technical
development. It contains couple compoments: a kernel-mode rootkit and user-mode
DLLs which performs the trojan operation such as downloaders, blocking Avs, etc,. Since
the rootkit acts as an “injector” and protector for the usermode bot binaries, almost all
technical evolutions of this threat family focus on rootkit technology so as to evade AV
scanners.
As in its name, TDL3 is the 3
rd
generation of TDL rootkit which still takes its aims at
convering stealthy existences of its malicious codes. Beside known features, this threat is
exposed with a couple of impressive tricks which help it bypassing personal firewall and
staying totally undetected by all AVs and ARKs at the moment. These aspects and
techniques will be discussed in more detail in the sections that follow.
II.
The Dropper
II.1 The packer
The dropper (
0a374623f102930d3f1b6615cd3ef0f3
) comes in packed and
obfuscated as usual by a similar packer to which was used by other TDL/TDSS variants
in the past. Despite of the author’s attempt to bypass PE-file heuristics scanning by
inserting several random API imports and exports, the sample still get detected by various
heuristics based scanner.
II.2 The installation mechanism
There’s nothing interesting with the dropper except its unique approach for installation
into systems. Instead of using known or documented method, this sample actually
implements an “0day” to execute itself thus it can bypass some lame HIPS/personal
firewalls easily.
Figure 1 illustrates pseudo-code snippet of one part of the dropper
Figure 1. Pseudo code of TDL3’s bypassing personal firewall method
First, the dropper copies itself into the Print Processor directory with a random name
determined by the system, then it modifies the characteristics of the newly created file to
convert it into a PE Dynamic Linked Library (DLL).
And here comes the interesting part of the dropper. After changing the characteristics, the
dropper registers the malicious DLL file as an Print Processor which is named “tdl” by
calling winspool API
AddPrintProcessorA()
. Internally, this API will issue an RPC
call to the Printing Subsystem hosted by
spoolsv.exe
process and force
spoolsv.exe
to load the Print Processor DLL remotely. In this case,
spoolsv.exe
will execute the
DLL version of the dropper copied inside the Print Processor directory inside the context
of
spoolsv.exe
process. In fact,
spoolsv.exe
is usually a system-trusted process to
almost personal firewalls hence the malicious DLL has the permission to do anything to
the system without neither any notification nor alarm to the users.
Although this is a pretty cool method to remotely load and execute a malicious DLL into
another trusted process, it has some limitations too. First, the caller must have
SeLoadDriverPrivilege
and second, it has to be able to write file to Print Processor
directory. Moreover, when an application tries to acquire the
SeLoadDriverPrivilege
, some personal firewall will notify the user about that
suspectious behaviour. Anyway, due to the fact that most of users aren’t technical aware
and always log in with Administrator privilege, I guess the successful installation rate
isn’t affected seriously by these aforementioned obstacles.
Figure 2. TDL3 user-mode dropper: Bypassing personal firewall mechanism
Back to the dropper, after being loaded into
spoolsv.exe
, the malicious DLL drops a
driver and begins its second stage infection in kernel space by calling
NtLoadDriver()
directly.
II.3 The first kernel mode dropper stage: Unpacking
Now the battlefield takes place in kernel mode. The dropped driver loaded by
spoolsv.exe
is actually a loader for another embedded kernel codes. From the its
DriverEntry(), the driver allocates kernel pool heap to copy the compressed data to and
employs aPlib to unpack the real rootkit driver inside itself.
One thing worth to mention: the author employed a small trick in an attempt for anti-
static analysis during this unpacking process. He first hooks an imported API in the IAT
of current driver with the unpacking routine, then call that API, and because that API
address in the IAT has been modified already, the execution is transferred to the real
decompressing procedure. When an analyst uses static analysis (e.g IDA disassembly) he
could miss the unpacking routine.
In the sample I analyze, the hooked API is
RtlAppendAsciizToString
.
Before
After
Figure 3. TDL3 kernel mode dropper anti-static analysis: IAT self hooking
At the end of this stage, the loader performs the PE mapping against the unpacked driver
over an
NonpagedPool
and finally jumps to that new zone, begins its second stage of
kernel mode infection.
II.4 The second kernel mode dropper stage: Infecting & storing rootkit’s code
The real deal actually lies in the “freshly baked” codes. It does various things to survive
the rootkit reboot, but the most important and interesting parts are:
o
Infecting miniport driver
o
Survive-reboot strategy
o
Direct read/write to hard disk using SCSI class request
Infecting driver
The infector first queries the device object responsible with
partition0
on the
hard disk device which the “
\systemroot
” is linked/installed on. It’s convinient
for the rootkit to retrieve the last miniport driver object and the name of the
driver’s binary file via that device object. For example, in my analysis, name of
the driver is “
atapi
” while
“\systemroot\system32\drivers\atapi.sys
”
is going to be infected.
The infecting algorithm isn’t complicated, it overwrites the data of “.rsrc” section
of victim driver with 824 bytes instead of kidnapping the whole driver like others
did (e.g Rustock.C), so that size of the infected file isn’t changed before and after
the infection occurs. The original overwritten data is then stored to certain sectors
on disk for later file content counterfeiting. The infector also modifies the entry
point of infected file to address of the 824 bytes codes.
Rootkit’s survive-reboot strategy
The previous variants of TDL/TDSS survive reboot by creating themselves
startup services and keep their malicious codes in files normally. So what’s new
in this TDL3? The author(s) made their decision to go lower & deeper. The
rootkit no longer uses file system to store its files, it reads and writes directly onto
disk’s sectors. The main rootkit’s code is stored at the last sectors of the disk with
the sector number is calculated by formula
total_number_of_disk –
(number_of_rootkit_sector + number_of_overwritten_data_sector)
.
The next time system reboots, when the 824 bytes in infected driver gets
executed, it waits for file system’s setup finishing (by registering itself a
filesystem notification routine), then loads and runs the rootkit stored at last
sectors of the disk.
Figure 5 demonstates how TDL3 performs the installation: the real rootkit’s codes
and overwritten atapi.sys’s data are placed into a buffer at
0x817e1000
. Total
size of data to be written down is
0x5e00
bytes. Next, it writes this buffer into
continous sectors start at sector number 0x3fffc0. Notice that 4 bytes of written
buffer is the signature of the rootkit - ‘
TDL3
’ (without quotes). The 824 bytes
loader also checks for this signature when it reads back these sectors.
Figure 4. 824 bytes loader check for TDL3 signature
Rootkit’s direct read/write feature
Another interesting feature of the infector/dropper is its approach to issue
read/write/query requests directly to hard disk via the infected miniport driver
dispatch routine.
[ Pobierz całość w formacie PDF ]