Your SlideShare is downloading. ×
Rootkit case
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rootkit case


Published on

Rootkit case dropper analyse

Rootkit case dropper analyse

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. AnalyzingUnknown Malware Tools used: • Oracle VM VirtualBox 4.1.16 • Windows XP SP3 fully patched • IDA Pro 5.0 free • OllyDbg 1.10 • Resource Hacker • HxD Hexeditor • MiTeC EXE Explorer 1.0
  • 2. R136a1 | Whitepaper #1 IntroductionWhile searching for some interesting, unknown malware samples I came across a report that took myattention ( 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 severalreports of earlier (and also widely detected) versions of this family. By looking at the dates, the irst uploadedsample 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 if hecould 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 MD5: 9c0744b8119df63371b83724bafe2095 1. Information gatheringAt very irst I always look at the ile properties to cross check the strings in Google. But this sample hadn‘t anyversion strings or was signed with a (valid) certi icate. Figure 1: File Properties of the DropperHEX EDITORAt 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 #1However the following block of data looked like it was encrypted in some way. A later more detailed view intothe code disassembly was needed.After this encrypted data block came a bunch of interesting strings:driversusbhc.syskernel32WaitForSingleObjectsc start usbhcsc create %s binPath= %s type= kernel start= auto DisplayName= %susbhcsc delete stop usbhc Figure 4: Strings inside DropperTo 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 driverTo 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 upthe commands the malware uses:Description: „SC is a command line program used for communicating with the NT Service Controller andservices.“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 numberare small thus indicate the ile could be a dropper/loader:msvcrt.dllmemcpymallocfreestrcatmemsetsprintf_except_handler3_c_exit_exit_XcptFilter_cexitexit__initenv Analyzing Unknown Malware | 3
  • 4. R136a1 | Whitepaper #1__getmainargs_initterm__setusermatherr_adjust_fdiv__p__commode__p__fmode__set_app_typeKERNEL32.dll_controlfpCloseHandleWriteFileCreateFileAGetSystemDirectoryAGetProcAddressGetModuleHandleACreateProcessA Figure 5: Import TableAs you can see there are functions from msvcrt.dll (Microsoft Visual C++ Run-Time) and kernel32.dll, thustelling 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 APIfunctions also let some assumptions to be made...To continue there follows another data block and inally the Version string info (which obviously was notcorrectly 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 belaunched with the full access token of an administrator.“ Analyzing Unknown Malware | 4
  • 5. R136a1 | Whitepaper #1RESOURCE EDITORA 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 SectionPE EDITOR/VIEWERThis time I choose „Mitec EXE Explorer“ instead of famous „PEiD“, because it is quite a complete PE Editor witha clear GUI and not widely known.A look into the PE Header shows the Entrypoint (000069B6) is in the resource section (.rsrc). This is notcommon 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 AnalysisNow that I have a brief overview of the ile and a few of its intentions I look into it in more detail. I use asDisassembler 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 thecode 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 alreadyknow from the Information Gathering part. Figure 8: IDA Pro Strings WindowSo I switch to the graphical disassembly view to start code analysis. IDA Pro automatically jumps to theEntrypoint 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 normalcontrol low (loc_406AF7, loc_406B0B). Figure 9: Start of the Dropper‘s CodeSuch blocks normally indicate that some sort of exception handling is used in the code. And a quick look atthe 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 theexception handlers if an error occurs.The exception handlers itself are used for normal exceptions and not for any antidebugging purposes, so let‘scontinue the analysis.The following disassembly code are internal C++ Runtime functions and other internal stuff. Nothing thatinterests us till we reach the function call at offset 00406AD6 (call sub_40696E). Analyzing Unknown Malware | 6
  • 7. R136a1 | Whitepaper #1 Figure 10: AntiDebug tricksFirst it seems like a relative small function which does setup a SEH and calls Windows API functionCreate ile(). We also see a Debugger Interrupt (INT3 - 0xCC) which is normally used by Debuggers to set aBreakpoint. 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 thedisassembly and get a better understanding of the code. The irst AntiDebug trick is a call to CreateFile() withits own path as „lpFileName“ paramter. It took me a while to igure this out, but I inally found an explanationin 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 exclusivelythe 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). Ialso refer to Peter Ferries excellent Paper (page 36):„Interrupt 3: ...When an EXCEPTION_BREAKPOINT (0x80000003) exception occurs, Windows assumes that itwas caused by the one-byte „CC“ opcode („INT 3“ instruction). Windows decrements the exception address topoint 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 endlesslysingle stepping the same loop. Now that I know how to follow execution low I jump to the call at offset004069A5 (call sub_406911). Bingo! Analyzing Unknown Malware | 7
  • 8. R136a1 | Whitepaper #1 Figure 11: Dropper‘s main partThis is the interesting part of the executable. I see the function „sub_4068AC“ is called four times, everytimewith a pointer to a string as its only parameter. I also see the strings I found in the Information gathering partwhich 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 thefunction 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 thedebugger. To solve this problem we don‘t need to search one of those AntiDebug Plugins, instead we just makeOllyDbg to ignore INT3 break exceptions (Options -> Debugging options -> Ignore (pass to program) followingexceptions: check „INT3 breaks“). Now the exception handler of the program is called if the INT3 instructiongets executed and not OllyDbg. Figure 12: OllyDbg Exception Options Analyzing Unknown Malware | 8
  • 9. R136a1 | Whitepaper #1So 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 wholefunction I know what it is doing. Figure 13: Process creation of Windows sc.exe toolThe function memset() is used for creating the STARTUPINFO structure which is needed for functionCreateProcess(). By calling CreateProcess() with „sc stop usbhc“ as lpCommandLine parameter the Windowstool „sc.exe“ gets executed with „stop usbhc“ as the passed arguments. This stops the service „usbhc“, soobviously any previously installed versions of this malware get stopped (and later deleted) before the newversion is installed. The dynamically resolved kernel32.dll function WaitForSingleObject() (GetModuleHandle()+GetProcAddress()) ensures that sc.exe tool inished execution before continuing. Now we know that thepurpose 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 clearoverview of the graphical code view. Figure 14: Rename function for better overview Analyzing Unknown Malware | 9
  • 10. R136a1 | Whitepaper #1The following call to our newly renamed function „sc_Execute“ takes the parameter „sc delete usbhc“ thus weknow 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 withthe string „driversusbhc.sys“ by using the strcat() function. So here we see the creation of the installationpath for the driver (C:WINDOWSsystem32driversusbhc.sys). Figure 15: Get installation pathThere 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 workto explain. All we need to know is the program allocates some memory where the driver gets unpacked. Thepointer to that memory location later gets used, but let‘s see. After the unpacking routine follows anotherfunction 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 InstallationBy single stepping the arguments for function WriteFile() we can see the pointer to the buffer where thedriver was unpacked (in my case offset 003433E8). So after the unpacking and ile creation we leave the 2subroutines 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 functionNext I see with the help of function sprintf() the string „sc create usbhc binPath= C:WINDOWSsystem32driversusbhc.sys type= kernel start= auto DisplayName= usbhc“ is to be created. There follows a function callto „sc_Execute“ where the service usbhc is created and added to the registry with help of sc.exe tool. The lastfunction call is also „sc_Execute“ with parameter „sc start usbhc“ so the newly created and installed driver getsstarted 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