Rootkit case dropper analyse

1. Analyzing
Unknown Malware
Tools used:
• Oracle VM VirtualBox 4.1.16
• Windows XP SP3 fully patched
• IDA Pro 5.0 free
• OllyDbg 1.10
• Resource Hacker 3.6.0.92
• HxD Hexeditor 1.7.7.0
• MiTeC EXE Explorer 1.0

2. R136a1 | Whitepaper #1
Introduction
While searching for some interesting, unknown malware samples I came across a report that took my
attention (http://www.threatexpert.com/report.aspx?md5=9c0744b8119df63371b83724bafe2095).
The malware contains a usermode and a kernelmode part and looks like a legit program at irst (.sys + .inf
iles). By typing one of the created registry entries (NdisrdMP.ndi) into the search mask I discovered several
reports of earlier (and also widely detected) versions of this family. By looking at the dates, the irst uploaded
sample is from year 2009, so this malware family is at least used since then.
Unfortunately I hadn‘t access to the Threatexpert database, so I contacted rkhunter from kernelmode.info if he
could provide me a copy. So thanks goes to him!
This paper is about the Static Analysis of the Dropper of this malware. You can ind the rest of the analysis
(Kernelmode Payload + Additional Components) on rkhunters‘ Blog at http://artemonsecurity.blogspot.com.
Sample MD5: 9c0744b8119df63371b83724bafe2095
1. Information gathering
At very irst I always look at the ile properties to cross check the strings in Google. But this sample hadn‘t any
version strings or was signed with a (valid) certi icate.
Figure 1: File Properties of the Dropper
HEX EDITOR
At next I open the sample in a Hex Editor to get a brief overview (PE Header information, strings, used APIs,
...). So I saw the „Rich Header“, which only gets created when a Microsoft compiler was used.
Next I saw the section names (.text, .data, .rsrc, .reloc) which tell me this executable probably isn‘t packed/
crypted.
Figure 2: Rich Header
Figure 3: Section Names
Analyzing Unknown Malware | 2

3. R136a1 | Whitepaper #1
However the following block of data looked like it was encrypted in some way. A later more detailed view into
the code disassembly was needed.
After this encrypted data block came a bunch of interesting strings:
driversusbhc.sys
kernel32
WaitForSingleObject
sc start usbhc
sc create %s binPath= %s type= kernel start= auto DisplayName= %s
usbhc
sc delete usbhc.sc stop usbhc
Figure 4: Strings inside Dropper
To make a few assumptions:
• A driver named usbhc.sys is to be created
• The kernel32.dll function WaitForSingleObject() is used
• The Windows sc.exe tool (Description: „A tool to aid in developing services for WindowsNT“) is used to
install, start, stop and delete the driver
To get a better understanding what the sc.exe tool is and what it can do, we type „sc“ into Start -> Run...
Now a command line window pops up with the description and the arguments one can use. I will only pick up
the commands the malware uses:
Description: „SC is a command line program used for communicating with the NT Service Controller and
services.“
start: „Starts a service.“
stop: „Sends a STOP request to a service.“
delete: „Deletes a service <from the registry>.“
create: „Creates a service. <adds it to the registry>.“
After another block of data there follows the Import Table and the used API functions. The functions in number
are small thus indicate the ile could be a dropper/loader:
msvcrt.dll
memcpy
malloc
free
strcat
memset
sprintf
_except_handler3
_c_exit
_exit
_XcptFilter
_cexit
exit
__initenv
Analyzing Unknown Malware | 3

4. R136a1 | Whitepaper #1
__getmainargs
_initterm
__setusermatherr
_adjust_fdiv
__p__commode
__p__fmode
__set_app_type
KERNEL32.dll
_controlfp
CloseHandle
WriteFile
CreateFileA
GetSystemDirectoryA
GetProcAddress
GetModuleHandleA
CreateProcessA
Figure 5: Import Table
As you can see there are functions from msvcrt.dll (Microsoft Visual C++ Run-Time) and kernel32.dll, thus
telling us the malware was probably written in Visual C++.
The API functions CreateFile() and WriteFile() are probably used to create the usbhc.sys driver. The other API
functions also let some assumptions to be made...
To continue there follows another data block and inally the Version string info (which obviously was not
correctly implemented, because it doesn‘t appear in the ile properties) and the manifest.
The manifest tells us an interesting detail:
...<requestedExecutionLevel level=“requireAdministrator“ uiAccess=“false“></requestedExecutionLevel>...
As described by Microsoft: „The application runs only for administrators and requires that the application be
launched with the full access token of an administrator.“
Analyzing Unknown Malware | 4

5. R136a1 | Whitepaper #1
RESOURCE EDITOR
A quick look at the resource section with Resource Hacker doesn‘t reveal any special resources, e.g.
(encrypted) PE iles or any other interesting data.
Figure 6: Resource Section
PE EDITOR/VIEWER
This time I choose „Mitec EXE Explorer“ instead of famous „PEiD“, because it is quite a complete PE Editor with
a clear GUI and not widely known.
A look into the PE Header shows the Entrypoint (000069B6) is in the resource section (.rsrc). This is not
common for a normal PE ile.
The Timestamp of the ile is „18.06.2012 12:34:00“, so we have a fresh malware sample.
The rest of the information is quite common and nothing that interests us.
Figure 7: PE Editor View
Analyzing Unknown Malware | 5

6. R136a1 | Whitepaper #1
2. Static Analysis
Now that I have a brief overview of the ile and a few of its intentions I look into it in more detail. I use as
Disassembler IDA Pro 5.0 free and as Debugger OllyDbg 1.10 in parallel.
With IDA Pro we have the great feature of a graphical overview of the code and with OllyDbg we single step the
code to get a better understanding of the disassembly.
At irst in IDA Pro I look at the Strings window which in this case doesn‘t reveal any more than we already
know from the Information Gathering part.
Figure 8: IDA Pro Strings Window
So I switch to the graphical disassembly view to start code analysis. IDA Pro automatically jumps to the
Entrypoint of the executable, in this case the Entrypoint from PE header.
What immediately takes my attention are the two „unconnected“ code blocks which stand out of the normal
control low (loc_406AF7, loc_406B0B).
Figure 9: Start of the Dropper‘s Code
Such blocks normally indicate that some sort of exception handling is used in the code. And a quick look at
the irst few assembly lines con irms our assumption, because the parameter for the SEH prolog function
(call __SEH_prolog) points to a structure which holds the offsets (loc_406AF7, loc_406B0B - see above) to the
exception handlers if an error occurs.
The exception handlers itself are used for normal exceptions and not for any antidebugging purposes, so let‘s
continue the analysis.
The following disassembly code are internal C++ Runtime functions and other internal stuff. Nothing that
interests us till we reach the function call at offset 00406AD6 (call sub_40696E).
Analyzing Unknown Malware | 6

7. R136a1 | Whitepaper #1
Figure 10: AntiDebug tricks
First it seems like a relative small function which does setup a SEH and calls Windows API function
Create ile(). We also see a Debugger Interrupt (INT3 - 0xCC) which is normally used by Debuggers to set a
Breakpoint. So where is the functionality of this executable you may ask?
What we see here are two (old) AntiDebugging techniques. Now we use OllyDbg in parallel to single step the
disassembly and get a better understanding of the code. The irst AntiDebug trick is a call to CreateFile() with
its own path as „lpFileName“ paramter. It took me a while to igure this out, but I inally found an explanation
in Peter Ferries „The ‚Ultimate‘ Anti-Debugging Reference“ (page 49):
„CreateFile(): A slightly unreliable way to detect the presence of a debugger is to attempt to open exclusively
the ile of current process. When some debuggers are present, this action will always fail...“
The second AntiDebug trick a a simple int3 Interrupt together with a Structured Exception Handler (SEH). I
also refer to Peter Ferries excellent Paper (page 36):
„Interrupt 3: ...When an EXCEPTION_BREAKPOINT (0x80000003) exception occurs, Windows assumes that it
was caused by the one-byte „CC“ opcode („INT 3“ instruction). Windows decrements the exception address to
point to the assumed „CC“ opcode, and then passes the exception to the exception handler.“
So when I analyze the ile in OllyDbg the Exception Handler (loc_4069A2) never gets called and I am endlessly
single stepping the same loop. Now that I know how to follow execution low I jump to the call at offset
004069A5 (call sub_406911). Bingo!
Analyzing Unknown Malware | 7

8. R136a1 | Whitepaper #1
Figure 11: Dropper‘s main part
This is the interesting part of the executable. I see the function „sub_4068AC“ is called four times, everytime
with a pointer to a string as its only parameter. I also see the strings I found in the Information gathering part
which are used as parameters with this function. But let‘s start one by one.
After the stack frame is set up the function „sub_4068AC“ is called with a pointer to string „sc stop usbhc“
as parameter. Now in IDA Pro I jump into this function and in parallel set a Breakpoint in OllyDbg on the
function at offset 004069A5 (call sub_406911 - see above). But wait there was the INT3 AntiDebug trick,
so when I run the program (F9) my breakpoint is never reached, instead the INT3 breakpoint just halts the
debugger. To solve this problem we don‘t need to search one of those AntiDebug Plugins, instead we just make
OllyDbg to ignore INT3 break exceptions (Options -> Debugging options -> Ignore (pass to program) following
exceptions: check „INT3 breaks“). Now the exception handler of the program is called if the INT3 instruction
gets executed and not OllyDbg.
Figure 12: OllyDbg Exception Options
Analyzing Unknown Malware | 8

9. R136a1 | Whitepaper #1
So I single step into the irst function call (004068AC) and see there are four Windows API functions used
(memset(), CreatProcess(), GetProcAddress()+GetModuleHandle()). After single stepping through the whole
function I know what it is doing.
Figure 13: Process creation of Windows sc.exe tool
The function memset() is used for creating the STARTUPINFO structure which is needed for function
CreateProcess(). By calling CreateProcess() with „sc stop usbhc“ as lpCommandLine parameter the Windows
tool „sc.exe“ gets executed with „stop usbhc“ as the passed arguments. This stops the service „usbhc“, so
obviously any previously installed versions of this malware get stopped (and later deleted) before the new
version is installed. The dynamically resolved kernel32.dll function WaitForSingleObject() (GetModuleHandl
e()+GetProcAddress()) ensures that sc.exe tool inished execution before continuing. Now we know that the
purpose of this function is to „execute“ the passed string parameter by creating a new Process for sc.exe tool.
In IDA Pro we can rename the function „sub_4068AC“ into something like „sc_Execute“ to get a more clear
overview of the graphical code view.
Figure 14: Rename function for better overview
Analyzing Unknown Malware | 9

10. R136a1 | Whitepaper #1
The following call to our newly renamed function „sc_Execute“ takes the parameter „sc delete usbhc“ thus we
know the service will be deleted (removed from registry). By following the next code line (call sub_40685F)
we land in a function where the system directory is retrieved (GetSystemDirectory()) and concatenated with
the string „driversusbhc.sys“ by using the strcat() function. So here we see the creation of the installation
path for the driver (C:WINDOWSsystem32driversusbhc.sys).
Figure 15: Get installation path
There follows a function call to the unpacking/decryption routines where the usbhc.sys driver gets decrypted/
unpacked (call sub_4067A4). I am not going into detail about the unpacking routine, since it is a tedious work
to explain. All we need to know is the program allocates some memory where the driver gets unpacked. The
pointer to that memory location later gets used, but let‘s see. After the unpacking routine follows another
function call (call sub_40681C) where the unpacked driver inally gets written to disk (CreateFile()+WriteFile(
)+CloseHandle()).
Analyzing Unknown Malware | 10

11. R136a1 | Whitepaper #1
Figure 16: Driver Installation
By single stepping the arguments for function WriteFile() we can see the pointer to the buffer where the
driver was unpacked (in my case offset 003433E8). So after the unpacking and ile creation we leave the 2
subroutines and rename the function „sub_40685F“ into soemthing like „usbhc_DriverInstall“.
Analyzing Unknown Malware | 11

12. R136a1 | Whitepaper #1
Figure 17: Overview of Dropper‘s function
Next I see with the help of function sprintf() the string „sc create usbhc binPath= C:WINDOWSsystem32
driversusbhc.sys type= kernel start= auto DisplayName= usbhc“ is to be created. There follows a function call
to „sc_Execute“ where the service usbhc is created and added to the registry with help of sc.exe tool. The last
function call is also „sc_Execute“ with parameter „sc start usbhc“ so the newly created and installed driver gets
started as a service.
That‘s all! Now the SEH epiloge function gets called (call __SEH_epilog) and the program exits.
To sum the features of the Dropper up a bit:
• Dropper for kernelmode Payload
• Driver is packed/crypted inside Dropper
• Two (known) AntiDebug tricks are used
• Makes use of Windows sc.exe tool
• Payload gets installed as a service
Analyzing Unknown Malware | 12