Archive for the Rootkits Category

DKOM Opens Door to Malware Rootkits

Posted in Rootkits with tags , , on 27 December, 2009 by __fastcall

I love this one found it in McAfee’s blog posted by Romain Levy

Much malware comes with a kernel rootkit component. Subverting the Windows kernel is indeed the best way to conceal malicious activities on infected systems. To achieve this, many types of malware load malicious device drivers that enjoy full access to all kernel objects. However, this technique is somewhat noisy, and loading a new driver is not really stealthy.

At McAfee Labs we recently ran across a W32/IRCBot.gen.ac sample that uses Direct Kernel Object Manipulation (DKOM) to hide itself without loading a new driver. This technique seems impossible at first sight because modifying kernel memory pages from userland is not allowed. However, W32/IRCBot.gen.ac takes advantage of an undocumented function exported by ntdll.dll that provides debugging functionalities at the kernel level.

NtSystemDebugControl(), despite being undocumented, has been known for many years. It provides simple functions such as reading from and writing to any location within the kernel memory. And this is exactly what a piece of malware needs to manipulate kernel objects.

W32/IRCBot.gen.ac starts by checking what version of Windows it’s running on. This technique won’t work under Windows Vista or Windows 7. If the infected machine is not running Windows XP, W32/IRCBot.gen.ac gives up and doesn’t try to hide itself.

If it does find Windows XP, W32/IRCBot.gen.ac opens the current process’ token to ensure it has the SeDebugPrivilege, which is required to call NtSystemDebugControl().

To find the process list in the kernel memory, W32/IRCBot.gen.ac retrieves the address of the global variable PsInitialSystemProcess, which points to the EPROCESS structure of the system process.

W32/IRCBot.gen.ac can now find the process list in memory and go through it to find its own process. It then removes itself from the process list by calling NtSystemDebugControl() to write to kernel memory.

The malicious process is no longer visible in the Windows Task Manager or other tools such as Process Explorer. However, monitoring TCP connections will quickly reveal the presence of an offending process whose name can’t be found.

Rootkit Detective also detects processes hidden via DKOM.

Accessing kernel memory from userland is really bad, but it appears this hole has been plugged in later versions of Windows. Using this method of calling NtSystemDebugControl() to access kernel memory is not trivial, and we don’t expect this technique to be used widely. And this is a good thing because according to Artemis, Windows XP is still the most widely deployed operating system in corporate environments. My colleagues Igor Muttik and Dmitry Gryaznov, and Joel Yonts of Advanced Auto Parts demonstrated this during McAfee’s Focus 09 conference.

Nevertheless, I offer another reminder that the bad guys never hesitate to exploit any feature, whether documented or not, as long as they can gain control over innocent machines.

Log into privileged user accounts only when required, and keep your anti-virus software up to date!


Advertisements

Using Import Address Table hooking for testing

Posted in Rootkits with tags , , on 27 December, 2009 by __fastcall

Continuing my previous post about IAT hooking I found in Johannes blog again a nice code for IAT hooking.

For a procedure that is free of side effects, it is a relatively easy task to create a unit test that achieves sufficient code coverage by testing all (or at least all interesting) combinations of input data and verifying the computed results.

If, however, the procedure is not free of side effects, the state (global variables, external data, etc.) modified by the procedure has to be taken into account. A solid testcase has to test both the effects of the state on the correctness of the procedure and the correctness of the procedure’s modifications on the state. As a consequence, the testcase has to initialize the state to a ‘known state’ before running each test and validate the state after each test.

If the state can be queried and easily modified by the testcase’s initialization code to construct the individual testing scenarios, writing such a testcase may be laborious but does not pose a real problem. Things are a little different if the state is outside of the programmers control or at least hard to query and alter. This case is especially common when writing code that interfaces the operating system — a common example may be a library that uses the filesystem or the registry to query and modify data. While both filesystem and registry are accessibly to the testing code, several problems arise:

  1. The state is unknown on test case startup. Any affected files/keys have to be initialized to a defined state first.
  2. Parts of the data may be unaccessible for security reasons. As an example, the procedure under test may need to read settings from HKLM. The affected keys under HKLM thus belong to the state that affects the execution of the procedure and our test case needs to run the procedure using different initial states, i.e. using different values for the keys in HKLM. But, as the testcase should be able to run as normal user (maybe to ensure LUA compliance), modifying these keys is forbidden.
  3. The state may be altered concurrently by other programs running on the same system.

Such a test case may easily contain more code initializing and validating state (key and file creation/deletion etc) than actual test code. Needless to say, creating such test cases is a pain.

Continue reading

Userland hooking, IAT

Posted in Rootkits with tags , on 27 December, 2009 by __fastcall

I remember I had a conversation a few weeks ago with tweekier (this guy is a paing in the ass, he always makes me think) and a flash occured in my mind; I ‘ve never done a userland hooking the rootkit way. I have used several times the SetWindowsHookEx, I hooked some kernel functions, but boy I ‘ve never done it for a userland rootkit. I was dazed and confused during the x-mas hangovers so I didn’t want to think. I found a very good article from awarenetwork.org

[==============================================================================]
[---------------------------[ Userland API Hooking ]---------------------------]
 S0ban>   -  -- -   - - - = == ================================================]

       _.d####b._
     .############.
   .################.
  .##################.__ __ __ __ _ _ __ __
  ##############/�_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  ###########>"<######
  *#########(   )####*
   ##########>.<#####
    ################
     *############*
       "T######T"

0. Overview  ------------------------------------------------------------------]

API hooking is essentially the act of intercepting an API function call, and
modifying it's functionality somehow, either by redirecting it to a function
of our choice, or stopping the function from being called, or logging the
request... the possibilities are endless. This is useful for cracking
applications, especially when the application does gay stuff like hardcode
API offsets (funny story, that...) and check itself for integrity in memory.

Unfortunately, API hooking under Windows - without going down the rabbit hole
of Kernel Mode Programming - has long been a poorly documented subject. What
little documentation is available is often incomplete or erroneous, and based
more than theory than in practice, basically without adequate information for
someone to actually implement a working API hook.
 Continue reading