Locating Hidden Clampi DLLs (VAD-style)

The "Reflective Dll Injection", [1] framework is very similar to ManualMap, [2] written by Darawak in 2005. Both programs include a built-in PE loader that can map a DLL into a remote process without calling LoadLibrary() or LoadLibraryEx(). By avoiding the API calls, it is possible to load the DLL without creating a corresponding InMemoryOrderModuleList entry in the PEB of the host process. Common monitoring tools and anti-virus programs walk the InMemoryOrderModuleList entries to enumerate the loaded DLLs. Aside from preventing the initial entry, Darawak also showed how to hide DLLs by unlinking existing entries (see CloakDll, [3]).

Clampi, [4] is an example of a trojan with an integrated PE loader that has been around since at least December 2007. The authors did this to increase modularity and stealthiness at the same time. Clampi downloads DLLs from a C&C and stores them encrypted in the registry (the DLL never gets written to disk). When the Clampi process begins, it queries and decrypts the registry values, which yield a DLL in virtual memory. Then Clampi's PE loader begins to fill in the IAT and relocations. Each DLL implements a different set of information-stealing tactics, which then become available to Clampi without it ever being "registered" in the PEB.

Clampi uses IEXPLORE.EXE as the host process where it hides and executes the malicious DLLs. On a system infected with Clampi, I used listdlls.exe to show IEXPLORE.EXE's DLLs. As it turns out, all 85 DLLs are legitimate and have corresponding files on disk. This means that Clampi's integrated PE loader either failed and did not load any DLLs into IEXPLORE.EXE or it suceeded and the DLLs are hidden.

Aaron Walters posed the question, [5] of how to use volatile memory forensics to locate hidden DLLs. I took a snapshot of the infected VMware system and analyzed the .vmem file using Volatility, [6]. In particular, I used the 'pslist' command to locate the PID of IEXPLORE.EXE from the memory image. Then, I used the 'dlllist' command to compare with the listdlls.exe output. Everything checks out - exactly 85 DLLs.

A good place to begin looking for the hidden DLLs is the VAD (virtual address descriptor). Even though the DLLs are not listed in the PEB, they are still loaded into virtual memory of IEXPLORE.EXE. Therefore, by walking the VAD tree with Volatility, we can identify suspicious virtual memory segments based on their VAD pool type (VadS) and page protections, [8]. In particular, I looked for segments with the following protections:

#define MM_EXECUTE 2
#define MM_EXECUTE_READ 3
#define MM_EXECUTE_READWRITE 6
#define MM_EXECUTE_WRITECOPY 7












The output shows three VadS entries with MM_EXECUTE_READWRITE protections. None of the entries have a corresponding FileObject like DLLs mapped via LoadLibrary() or LoadLibraryEx(). For comparison, here is the Vad entry for ws2_32.dll, which IEXPLORE.EXE mapped with LoadLibrary. Note the start and end address in virtual memory (71ab0000 - 71ac6fff), the page protection (MM_EXECUTE_WRITECOPY) and FileObject Name (\Windows\system32\ws2_32.dll).









It is also possible to narrow the suspicious Vad search results by looking at the data that the virtual memory of each Vad entry contains. The 'vaddump' command reconstructs the memory and dumps it to disk for analysis. Then we can either use GT2, [9] or a hex editor to see what it contains. GT2 identifies the Vad entry at 0x1ddd0000 as being a Win32 PE file (a DLL).











An advantage to this method is that it also detects injected code that was never a DLL in the first place. For example, a Trojan could use WriteProcessMemory() to transfer a block of shell code and then invoke it with CreateRemoteThread(). In this case, we're just looking for executable pages that contain valid x86 instructions. We might also cross-reference the pages we find with thread start addresses.

The following screenshot shows the contents of the suspicious Vad entry at 0x04310000. The hex editor view shows the remote thread "header" used by Clampi, which is the string "BEGIN" followed by several 0xCC bytes. The thread code starts immediately after the 0xCC bytes. IDA Pro can disassemble the instructions as 32-bit code and come up with a clean function ready for static analysis.













In conclusion, volatile memory forensics can detect hidden DLLs and code blocks, even if an attacker uses reflective dll injection, manual mapping, or a similar technique. I'm looking forward to reading about other ways to detect hidden DLLs and code blocks.

[1] Harmony Security "Reflective Dll Injection"
[2] ManualMap by Darawk
[3] CloakDll by Darawk
[4] ThreatExpert search for criticalfactor.cc (Clampi C&C)
[5] Volatility Blog - Reflective Dll Injection
[6] Volatility
[7] The Vad Tree: A process-eye view of physical memory
[8] ReactOS MMVAD structure for Windows XP
[9] GetType2 file detection utility