Malware: Exploring mutex objects

A mutex, also called a lock is a program object commonly used to avoid simultaneous access to a resource, such a variable.

It’s used in concurrent programming to allow multiple program threads to share the same resource.

Mutexs are usually used by malware creators to avoid the infection of a system by different instances of the same malware.

When the trojan infects a system, the first step is to obtain a handle to a “named” mutex, if the process fails, then the malware exits.

The easiest way to check for the presence of a Mutex is using the CreateMutex Function

HANDLE WINAPI CreateMutex(

	__in_opt  LPSECURITY_ATTRIBUTES lpMutexAttributes,   

	__in      BOOL bInitialOwner,   __in_opt  LPCTSTR lpName );

This is the same function that malware uses for checking if the system is infected so one approach to detect the presence of a piece of malware is trying to obtain a handle to the created mutex.

Here is a list of some malwares (md5’s) and the Mutex created:

60f733d6d0b077e4a668fb49aab44a30, xx464dg433xx16

fb663100308285afb4debdcab8d67fe2, 6E523163793968624

47c6313ec393d0c55d57529e2a9a418d, Security Tool

72631c3c853d706daf1153b3c8fea54f, psec_once

c37f47c9071eed101a67532e5d412171, YMING

cdcd59a5fb80808cad7376c001586c6e, 290541776

6013de3fed84d40bb173ec23f408a67e, mymutsglwork

62a3f867becfea136aea4ec83a4d9c44, 5BB0650C

5f33aa0b5660bc932af969301635d818, XGBPPAQHSE

2e40abf579e4d8d5d1ba7df34d5e507a, _!SHMSFTHISTORY!_

I’ve uploaded a small piece of code in .NET (console) using PInvoke that takes the name of the mutex to check for.

• Source Code http://alienvault-labs-garage.googlecode.com/svn/trunk/CheckMutex.cs [no longer available]
• Binary http://alienvault-labs-garage.googlecode.com/svn/trunk/CheckMutex.exe [no longer available]

(Tested on Windows XP SP2 and Windows 7)

Example:

You can use this small application to quickly check if a system is compromised if you know the name of the mutex created by the malware.

In the previous post, we talked about the Windows Kernel Objects as well as the “Object directories”.

We learnt how to query a directory using WinDBG and we found that Mutex as well as other kernel objects are present inside directories.

So now I will explain how to query object directories from user land via NtQueryDirectoryObject to list mutexs present in the system.

We will use the functions NtOpenDirectoryObject and NtQueryDirectoryObject

NTSTATUS WINAPI NtOpenDirectoryObject(   

	__out  PHANDLE DirectoryHandle,   

	__in   ACCESS_MASK DesiredAccess,   

	__in   POBJECT_ATTRIBUTES ObjectAttributes );

NTSTATUS WINAPI NtQueryDirectoryObject(

	   __in       HANDLE DirectoryHandle,   

	   __out_opt  PVOID Buffer,   

	   __in       ULONG Length,   

	   __in       BOOLEAN ReturnSingleEntry,  

	   __in       BOOLEAN RestartScan,   

	   __inout    PULONG Context,   

	   __out_opt  PULONG ReturnLength );

So the best approach to enumerate the Mutex objects is to traverse all the directories beginning with the root directory (”“\”“) and check for “Mutex objects” inside the directory.

We have to take into account that a directory may contains another directory so we have to traverse all of them.

Here is another piece of code to enumerate all the mutex present in the system:

• Source Code http://alienvault-labs-garage.googlecode.com/svn/trunk/EnumerateMutex.cs [no longer available]
• Binary http://alienvault-labs-garage.googlecode.com/svn/trunk/EnumerateMutex.exe [no longer available]

(Tested on Windows XP SP2 and Windows 7)

Example:

Remember that Windows Objects belongs to a namespace and each user session has a different namespace so you will retrieve different results from different user sessions.

I was looking at some mutex results an then I found these:

0x16F:Mutant                   VMwareGuestDnDDataMutex

0x170:Mutant                   VMwareGuestCopyPasteMutex

I think is another interesting trick to detect the presence of a system running inside Vmware.

Searching the Internet I found this report from ThreatExpert about a malware called W32.Neshuta that creates exactly the previous two mutexs.

So the question is if the malware checks for the presence of Vmware with this technique (I bet you a beer) or it uses the same mutants to hide and deceive computer users.