AlienVault R&D Labs Portal. Get the latest news from our research.
Header

A couple of days ago, I was surfing our wild Internet when I came up with a dirty piece of software dedicated to steal accounts of a popular build-with-bricks videogame.

The program offered a premium account of the videogame for free. The real fact is that it was a stealer, which installs a keylogger on your computer to record and send your private information to the bad actors.

When the user executes the program, the keylogger silently installs itself and then hides its directories and processes. If we take a look at the installation directory, it has these files:

d6192e6ac19bedf50772769568b8a1bf RKJ.00 (encrypted configuration file)
c8602a35ed53655f62eb70e52627f7ef RKJ.01 (aux exec file)
cabd1ee6acc039dd33ba48f886f3b12d RKJ.02 (aux exec file 2)
29c88770640993a5f0df70bfa272bb09 RKJ.exe (main executable)

It looks like an Ardamax Keylogger installation, latest version. This is a pretty popular keylogger among bad guys, it has trial and paid versions. It can monitor keystrokes, login credentials, clipboard and even take screenshots and pictures from the webcam.

A couple of minutes after the infection, the machine started to connect to Google’s email server using an encrypted channel (SSL SMTP). Is the keylogger reporting results to the administrator using this? In that case, we could probably analyse the sample and get the email account credentials of the malware administrator.

As the configuration file is encrypted, the easiest way to get some more information is by doing some reverse engineering. Let’s going to infect a machine, dump the memory (keylogger.mem) and analyse it with volatility.

$ python vol.py -f keylogger.mem pslist

The keylogger process is hidden for Windows Task Manager, but volatility can show it to us.

Offset(V) Name PID PPID Thds
0x862d6528 RKJ.exe 1832 1528 1

Time to dump process memory.

$ python vol.py -f keylogger.mem memdump -p 1832 --dump-dir=/tmp/

And if we carefully study the strings contained in that memory dump (take care of the encoding!)…

$ strings -a --encoding=l 1832.dmp
[...]
Logs from "%USERNAME%
[censored].server232@gmail.com --> username
smtp.googlemail.com --> password
[...]

Luckily Google had disabled the email account due to service abuse, no need to report the issue.

What about the encrypted configuration file?

We have seen some people infected by this keylogger wondering how to decrypt the file to see where is the malware leaking information to. Well, if you can not do memory analysis or some debugging it is quite easy to decrypt.

After a quick cryptanalysis of the file, it is quite obvious that it is encrypted with XOR cipher or something similar. You can easily decrypt it by using a XOR analysis tool like xortool. Let’s give a try:

$ python xortool.py -b keylogger/RKJ.00

xortool will generate some output files with possible decryptions. In this case the 33rd file was the good shot, encrypted with key “Z|NY”. If we open it with an editor, we can see all configuration parameters and reporting credentials in plain text.

Take care of the channels you allow on your network! We have seen how Google do a great job on cancelling accounts of this kind, but we should never have a blind faith on a legit connection because it could be a potential way to leak private information to the outside.

Hardening Cuckoo Sandbox against VM aware malware

December 19th, 2012 | Posted by Alberto Ortega in Code | Malware | Windows - (Comments Off)

Some time ago, we wrote a post about how a lot of malware samples check the execution environment, and if it is unwanted (VM, debugger, sandbox, …) the execution unexpectedly finishes.

We use Cuckoo Sandbox in the lab for our analysis tasks, we really love how customizable it is.

Sometimes we have to deal with malware aware of the execution environment, and this is a problem when you are using public virtualization products. Let’s see how modifying some parts of cuckoo we are able to fake crucial parts of the system to the malware sample, so it will not be able to detect the VM (in this case, VirtualBox).

Pafish will help us to test our work, it is a demo tool that performs some anti(debugger/VM/sandbox) tricks, most of them often used by malware. When it is executed, it writes a log with the successful detections, so we can easily track and solve them.

To monitor the malware activity, cuckoo executes the sample with cuckoomon, the part responsible of hooking system calls to save the malware actions. With this powerful hooking system, we can modify the hooks to return fake responses if we do not like the call. For example, calls to check files / registry keys / processes to detect the VM.

When we execute pafish for the first time, it will detect VirtualBox using different tricks:

[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 "Identifier"
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\Description\System "SystemBiosVersion"
[pafish] VirtualBox traced using Reg key HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
[pafish] VirtualBox traced using file C:\WINDOWS\system32\drivers\VBoxMouse.sys
[pafish] End

As we can see, it has detected our VM by reading some registry keys and looking for a file.

The piece of code responsible of hook RegOpenKeyExA (the call used by the detection) is this one (hook_reg.c):

HOOKDEF(LONG, WINAPI, RegOpenKeyExA,
  __in        HKEY hKey,
  __in_opt    LPCTSTR lpSubKey,
  __reserved  DWORD ulOptions,
  __in        REGSAM samDesired,
  __out       PHKEY phkResult
) {
    LONG ret = Old_RegOpenKeyExA(hKey, lpSubKey, ulOptions, samDesired,
        phkResult);
    LOQ("psP", "Registry", hKey, "SubKey", lpSubKey, "Handle", phkResult);
    return ret;
}

So we can modify it:

/* Hardened */
HOOKDEF(LONG, WINAPI, RegOpenKeyExA,
  __in        HKEY hKey,
  __in_opt    LPCTSTR lpSubKey,
  __reserved  DWORD ulOptions,
  __in        REGSAM samDesired,
  __out       PHKEY phkResult
) {
    LONG ret;
    if (strstr(lpSubKey, "VirtualBox") != NULL) {
        ret = 1;
        LOQ("s", "Hardening", "Faked RegOpenKeyExA return");
    }
    else if (strstr(lpSubKey, "ControlSet") != NULL) {
        ret = 1;
        LOQ("s", "Hardening", "Faked RegOpenKeyExA return");
    }
    else {
        ret = Old_RegOpenKeyExA(hKey, lpSubKey, ulOptions, samDesired,
            phkResult);
    }
    LOQ("psP", "Registry", hKey, "SubKey", lpSubKey, "Handle", phkResult);
    return ret;
}

We have changed the code to check if “VirtualBox” or “ControlSet” is in the provided SubKey to read. If it is, we will log a Hardening warning in cuckoo log and fake the response.

We have to do the same with RegQueryValueExA:

HOOKDEF(LONG, WINAPI, RegQueryValueExA,
  __in         HKEY hKey,
  __in_opt     LPCTSTR lpValueName,
  __reserved   LPDWORD lpReserved,
  __out_opt    LPDWORD lpType,
  __out_opt    LPBYTE lpData,
  __inout_opt  LPDWORD lpcbData
) {
    LONG ret = Old_RegQueryValueExA(hKey, lpValueName, lpReserved, lpType,
        lpData, lpcbData);
    LOQ("psLB", "Handle", hKey, "ValueName", lpValueName,
        "Type", lpType, "Buffer", lpcbData, lpData);
    return ret;
}

We change it to:

/* Hardened */
HOOKDEF(LONG, WINAPI, RegQueryValueExA,
  __in         HKEY hKey,
  __in_opt     LPCTSTR lpValueName,
  __reserved   LPDWORD lpReserved,
  __out_opt    LPDWORD lpType,
  __out_opt    LPBYTE lpData,
  __inout_opt  LPDWORD lpcbData
) {
    LONG ret;
    if (strstr(lpValueName, "SystemBiosVersion") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else if (strstr(lpValueName, "Identifier") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else if (strstr(lpValueName, "ProductId") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else {
        ret = Old_RegQueryValueExA(hKey, lpValueName, lpReserved, lpType,
            lpData, lpcbData);
    }
    LOQ("psLB", "Handle", hKey, "ValueName", lpValueName,
        "Type", lpType, "Buffer", lpcbData, lpData);
    return ret;
}

If the malware sample tries to read a registry key with “SystemBiosVersion“, “Identifier” or “ProductId” in the value name, it will fail.

With these two changes, we have covered the two registry keys detections done by pafish. Then we have to change the call used to access the files.

The call used is GetFileAttributesA, which is not hooked by default, so we add it (hook_file.c):

/* Hardened */
HOOKDEF(DWORD, WINAPI, GetFileAttributesA,
  __in      LPCTSTR lpFileName
) {
    BOOL ret;
    if (strstr(lpFileName, "VBox") != NULL) {
        ret = INVALID_FILE_ATTRIBUTES;
        LOQ("s", "Hardening", "Faked GetFileAttributesA return");
    }
    else {
        ret = Old_GetFileAttributesA(lpFileName);
    }
    LOQ("s", "GetFileAttributesA", lpFileName);
    return ret;
}

After that, we have to compile our new cuckoomon.dll and replace the original.

You can find it in cuckoo/analyzer/windows/dll/cuckoomon.dll, you can replace it while cuckoo is running, no need to stop it.

And we are done, we have placed some measures to disallow the samples to detect our VM by using these functions. We can execute pafish again with our new cuckoomon.dll to check the results:

[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] End

It only traced our VM by using the mouse activity, we could hook that too. We can also take a look at cuckoo log to see the responses faked by our hardened monitor:

"pafish.exe","620","532","registry","RegOpenKeyExA","SUCCESS","0x00000000","Registry->0x80000002","SubKey->HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0","Handle->0x0000003c"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Hardening->Faked RegQueryValueExA return"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Handle->0x0000003c","ValueName->Identifier","Type->0","Buffer->0x0022f64c"
"pafish.exe","620","532","registry","RegOpenKeyExA","SUCCESS","0x00000000","Registry->0x80000002","SubKey->HARDWARE\Description\System","Handle->0x00000040"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Hardening->Faked RegQueryValueExA return"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Handle->0x00000040","ValueName->SystemBiosVersion","Type->0","Buffer->0x0022f64c"
"pafish.exe","620","532","registry","RegOpenKeyExA","FAILURE","0x00000001","Hardening->Faked RegOpenKeyExA return"
"pafish.exe","620","532","registry","RegOpenKeyExA","FAILURE","0x00000001","Registry->0x80000002","SubKey->SOFTWARE\Oracle\VirtualBox Guest Additions","Handle->0x77c05c94"
"pafish.exe","620","532","filesystem","GetFileAttributesA","FAILURE","0xffffffff","Hardening->Faked GetFileAttributesA return"
"pafish.exe","620","532","filesystem","GetFileAttributesA","FAILURE","0xffffffff","GetFileAttributesA->C:\WINDOWS\system32\drivers\VBoxMouse.sys"

It is quite difficult to cover all functions used by malware to detect VMs, but with modifications in some common functions we can cover ~90% of the cases.

You can download the modifications made in this post from here, it is a patch compatible with the last stable version of the software. You can also download the compiled library, ready to use in your cuckoo installation.

Defenses of any sort, virtual or physical, are a means of forcing your attacker to attack you on your terms, not theirs. As we build more elaborate defenses within information security, we force our attacker’s hand. For instance, in many cases, implementing multi-factor authentication systems just forces the attacker to go after that system directly to achieve their goals. Take the breach at RSA, for example. It has been attributed to attackers who needed the SecurID information to go after their real targets in the defense industry.

Recently, our lab has been talking about Sykipot:

 

As we discussed, this malware has been used to launch targeted attacks via “spear phishing” campaigns against targets mainly in the US, since around 2007. According to our research, these attacks originate from servers in China with what appears to be the purpose of obtaining information from the defense sector: the same sector that makes extensive use of PC/SC x509 Smartcards for authentication.

Smartcards have a long history of usage in the Defense Sector, for both physical and information access management, and historically have merely forced attackers to route around the smartcard authentication system through other, more vulnerable attack vectors.

It should come as no surprise, then, that we recently discovered a variant of Sykipot with some new, interesting features that allow it to effectively hijack DOD and Windows smart cards. This variant, which appears to have been compiled in March 2011, has been seen in dozens of attack samples from the past year.

Like we have shown with previous Sykipot attacks, the attackers use a spear phishing campaign to get their targets to open a PDF attachment which then deposits the Sykipot malware onto their machine (the attackers here took advantage of a zero-day exploit in Adobe). Then, unlike previous strains, the malware uses a keylogger to steal PINs for the cards. When a card is inserted into the reader, the malware then acts as the authenticated user and can access sensitive information. The malware is controlled by the attackers from the command & control center.

Here is more detail on the attack:

Smartcard access

The first one is that it creates a new thread with a keylogger routine. The code is very basic, it stores the window name and the keys pressed under a file named MSF5F0.dat on an unencrypted format, example:

Title:Internet Explorer
www.google.es
Title:My Computer

It uses the WIN32 APIʼs functions [GetKeyState, GetAsyncKeyState,
GetForegroundWindow, GetWindowTextA].

It also saves the information contained in the clipboard using the native functions:
OpenClipboard, GetClipboardDataand CloseClipboard.

This code is very similar to other pieces of APTʼs like:

http://contagiodump.blogspot.com/2010/07/apt-activity-monitor-keylogger.html

Apart from this we found two more modules that attracted our attention. The first one is capable of listing all the certificates that are stored on the windows key store:

 

This next routine is called if the command “cl” is present on the config file fetched from the C&C.

When you insert a smart card into a reader attached to a Windows computer, the certificate on the smart card is registered to the local certificate store on the client computer.

The second one is even more interesting:

 

It loads:

C:\Program Files\ActivIdentity\ActivClient\acpkcs201.dll

(a module that handles some of the functions related with ActivIdentityʼs ActivClient solution.)

ActivClient is a smart card-based PKI authentication solution for compliance with:

  • U.S. Government Smart Card Interoperability Specifications GSC-IS 2.1
  • U.S. General Services Administration (GSA) Basic Services Interface (BSI)

(In fact it is one of the platforms used to support the Department of Defense common access card – DoD CAC)

This routine is called if the commandcm is present on the config file fetched from the C&C:


So, the modus operandi of the attackers is listing the certificates present on the victimʼs
computer included the smartcards, stealing the PIN using the keylogger module and then
use this information to log onto remote resources protected with certificates/smartcards.

To log onto protected resources they have implemented the command “krundll”, if the C&C sends that command, the victim receives a new dll that implements the required code to login using the certificate and the stolen PIN. This DLL implements the “LoginFunc” and “GetFunc”. These methods will contain all the code depending on the application used:

Summary

We have seen how the attackers are implementing different techniques to bypass two-factor authentication with smartcard/PIN to access protected resources on the victimʼs network. By capturing the PIN for the smartcard and binding the certificate, malware can silently use the card to authenticate to secure resources, so long as the card remains physically present in the card reader. This is similar to what Mandiant described on the 2011 M-Trends report as a “Smart Card Proxy”. While trojans that have targeted smartcards are not new, there is obvious siginficance to the targeting of a particular smartcard system in wide deployment by the US DoD and other government agencies, particularly given the nature of the information the attackers seem to be targeting for exfiltration.

Implications

As defenses get better, attackers will continue to change their tactics to adapt, and as seen here, will hijack the very systems designed to provide more security, if necessary. An interesting by-product of this malware’s necessity of having the card physically present is that attackers can only leverage it for secure authentication to target systems, during times that the user them is physically present at the workstation, making unauthorized activity that much more difficult to discern from legitimate usage. Although smart cards are designed to provide a two factor system of ‘chip and pin’, again we see that true two-factor authentication is not possible without a physical component that is not accessible digitally.


jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

Exploring Windows Objects ACL’s

December 29th, 2009 | Posted by jaime.blasco in Windows - (Comments Off)

In the last post, we talked about mutex objects and how to enumerate them. Today we’ll learn how to check mutex access lists from WinDBG as well as from user-mode extending the EnumerateMutex example.

Let’s see an example using WinDBG. First query the “\BaseNamedObjects” directory that usually contains mutex objects:

lkd> !object \BaseNamedObjects
Object: e18ce788  Type: (823ed418) Directory
    ObjectHeader: e18ce770 (old version)
    HandleCount: 71  PointerCount: 593
    Directory Object: e1001150  Name: BaseNamedObjects

    Hash Address  Type          Name
    ---- -------  ----          ----
     00  e15a8880 SymbolicLink  Local
         81e996d0 Event         userenv: Machine Group Policy has been applied
         82286598 Mutant        SHIMLIB_LOG_MUTEX
         82308700 Mutant        ZonesCacheCounterMutex
         e1dfe298 Section       CTF.AsmListCache.FMPDefaultS-1-5-21-507921405-412668190-839522115-500
         817e3ea0 Timer         userenv: refresh timer for 1048:768
         e1f12ed8 Section       MSCTF.MarshalInterface.FileMap.MPJ.DI.HDGDJDJ
         813f90d0 Event         CorDBIPCLSEventReadName_5752
         e25994a8 Section       Cor_Private_IPCBlock_4760
         e2319518 Section       Cor_Private_IPCBlock_4448
         e1fc1818 Section       MSCTF.MarshalInterface.FileMap.ILD.FOB.FNOEBJE
         8231e468 Event         userenv: machine policy force refresh event
         82196f50 Event         jjCSCSessEvent_UM_KM_0
         82111148 Event         AgentToWkssvcEvent

Now query one of them:

lkd> !object \BaseNamedObjects\SHIMLIB_LOG_MUTEX
Object: 82286598  Type: (823c55e0) Mutant
    ObjectHeader: 82286580 (old version)
    HandleCount: 8  PointerCount: 9
    Directory Object: e18ce788  Name: SHIMLIB_LOG_MUTEX

And query the object header at 82286580:

lkd> dt nt!_OBJECT_HEADER  82286580
   +0x000 PointerCount     : 9
   +0x004 HandleCount      : 8
   +0x004 NextToFree       : 0x00000008
   +0x008 Type             : 0x823c55e0 _OBJECT_TYPE
   +0x00c NameInfoOffset   : 0x10 ''
   +0x00d HandleInfoOffset : 0 ''
   +0x00e QuotaInfoOffset  : 0 ''
   +0x00f Flags            : 0x20 ' '
   +0x010 ObjectCreateInfo : 0x8055a000 _OBJECT_CREATE_INFORMATION
   +0x010 QuotaBlockCharged : 0x8055a000
   +0x014 SecurityDescriptor : 0xe1756a7e
   +0x018 Body             : _QUAD

The security descriptor is at 0xe1756a7e so, convert it:

lkd> ?? 0xe1756a7e & ~0x7
unsigned int 0xe1756a78

And then we can check the information we wanted:

lkd> !sd 0xe1756a78 0
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544
->Group   : S-1-5-18
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x44
->Dacl    : ->AceCount   : 0x2
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-18

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x18
->Dacl    : ->Ace[1]: ->Mask : 0x00120001
->Dacl    : ->Ace[1]: ->SID: S-1-5-32-544

->Sacl    :  is NULL

So now that we now how to check an object ACL via WinDBG, let’s take advantage of .NET classes inside System.Security.AccessControl namespace to query objects ACL’s.

We can query a previously created mutex object via Mutex.OpenExisting method:

[SecurityPermissionAttribute(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.UnmanagedCode)]
public static Mutex OpenExisting(
    string name,
    MutexRights rights
)

We’ll use MutexRights.ReadPermissions to be able to read ACL information and then call Mutex.GetAccessControl to read access control information.

Here is the EnumerateMutex example extended to print ACL information from mutexs inside object directories:

(Tested on Windows XP SP2 and Windows 7)

Example:

This method can be useful to identify weak ACL’s that can lead to a local Denial of Service. Example Winsock Mutex Vulnerability

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

Malware: Exploring mutex objects

December 28th, 2009 | Posted by jaime.blasco in Code | Malware | Windows - (1 Comments)

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.

(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:

(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.

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn