Searching for Mutants

I feel somewhat sorry for posting such a creepy title in spring. But don't worry, "mutant" is just how a mutex is called in the Windows kernel. A mutex helps to serialize access to a resource. Some applications employ a mutex to ensure that only a single instance is running. And that way, a mutex may lead us directly into the dark realms of some malware. Scary, isn't it?

A mutex is a concept that is widely used in concurrent programming. Assume that that there is a global counter variable that is set to 0 and two threads. The threads will increment the variable by reading its value, incrementing and finally storing the new value. If both threads process the variable in sequence, the we will end with a value of 2. Now assume that thread 1 gets interrupted after it has read the counter (still at 0). While thread 1 is suspended, thread 2 processes the variable and the counter now is 1. Finally the scheduler resumes thread 1. It also increments the previously stored value and writes it back into the global variable. And the counter now reads... 1! Crash!

In order to ensure mutual-exclusive access to the counter both threads should mark their three steps as a "critical section" or acquire a mutex on the global variable, compute and store the new value and then end the critical section or release the mutex. The second thread could then wait for the mutex to be released and then process the counter in a safe way.

There are two kinds of mutexes in the Windows kernel. Fast mutexes, also known as executive mutexes, are frequently used all over the kernel. As their name implies, they provide a mutual exclusion mechanism at a low overhead (guard mutexes of Windows Server 2003 and later are even faster). However, for the rest of this article we will be interested in mutex (or mutant) objects only.

Applications may create a global mutant with their name or some magic string. If a second instance of that application is launched, the creation of the mutant will fail and the program terminates. The mutant provides an easy means to ensure that only a single instance of that application is running. Malicious software uses this technique to avoid multiple infections of the same system.

Other software, both malicious and non-malicious, may create named mutants of other strains of malware in order to "vaccinate" a system. So, the existence of a known-bad mutant is not proof of an infection, but it justifies a closer examination.

The definition of the _KMUTANT structure is available from the kernel's debug symbol file:

kd> dt _KMUTANT
nt!_KMUTANT
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 MutantListEntry  : _LIST_ENTRY
   +0x018 OwnerThread      : Ptr32 _KTHREAD
   +0x01c Abandoned        : UChar
   +0x01d ApcDisable       : UChar

From the proper _OBJECT_TYPE structure we learn about the pool tag ("Muta") and that mutant objects reside in the nonpaged pool. The Microsoft debugger tells us about the typical allocation sizes:

kd> !poolfind Muta

Searching NonPaged pool (810c2000 : 812c2000) for Tag: Muta

810dd5e0 size:   40 previous size:   18  (Allocated) Muta (Protected)
810dd650 size:   40 previous size:   30  (Allocated) Muta (Protected)
810e15f0 size:   50 previous size:   30  (Allocated) Muta (Protected)
810e1a48 size:   40 previous size:   30  (Allocated) Muta (Protected)
810e3d50 size:   50 previous size:   30  (Allocated) Muta (Protected)
810e3e20 size:   50 previous size:   30  (Allocated) Muta (Protected)
810e5dd0 size:   40 previous size:   40  (Allocated) Muta (Protected)

A closer examination shows that _KMUTANT always is of the same size. Again it is the _OBJECT_HEADER that varies in size; some headers also contain an object name, which is exactly what we're interested in.

Again, I wrote a plugin for the Volatility memory analysis framework. Please make a backup copy of your installation before you unzip the archive in the Volatility base directory. If you use the version from the current Volatility SVN, then please copy only the plugin file.

Let's try the plugin on exemplar7 of hogfly's fine collection of malware memory dumps. There are two suspicious mutants:

>volatility mutantscan -s -f exemplar7.vmem

Phys.Addr. Obj Type   #Ptr #Hnd Signal Thread     CID        Name
0x01825480 0x817c9858    2    1      0 0x813dada8 312:532    9g234sdfdfgjf2304
0x018e2278 0x817c9858    2    1      0 0x8145a020 1092:1440  DLL32M

The full list contains a lot of nameless mutants. Therefore I recommend to apply the -s or --silent switch, which cuts the list down to named mutants.

The above output tells us whether the mutant is in its signaled ("released") state and which thread acquired the mutant. From the associated thread object we then learn about the client ID (CID), which is shown in the format of process:thread. Both identifiers are printed in decimal.

Now we query the list of running processes (truncated) to find the processes by their PID:

Name                 Pid    PPid   Thds   Hnds   Time
pp04.exe             312    264    1      33     Thu Jan 08 01:51:57 2009
rundll32.exe         1092   1948   2      46     Thu Jan 08 01:52:03 2009

Searching sites like ThreatExpert for the suspicious mutant names 9g234sdfdfgjf2304 and DLL32M then may provide us with further leads for our investigation.

Archives

Imprint

This blog is a project of:
Andreas Schuster
Im Äuelchen 45
D-53177 Bonn
impressum@forensikblog.de

Copyright © 2005-2012 by
Andreas Schuster
All rights reserved.
Powered by Movable Type 5.12