Rootkit case
4 likes•793 views
The document summarizes the static analysis of an unknown malware sample. The analysis involved using various tools to gather information and disassemble the malware. Key findings include that the malware installs a driver named usbhc.sys, uses anti-debugging techniques, unpacks and installs its kernelmode payload by using the sc.exe tool to start, stop and delete services, and installs its payload as a Windows service named usbhc.
Rootkit case
- 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