Welcome back for Part II. I am going to be taking a look at memory forensics by way of Volatility.
Let's kick this section off by running the volatility command, "imageinfo". The imageinfo command does just that. It provides us the image information required so we can specify what profile to pass to volatility when we start running more commands against our image.
In our case this is what the results looked like:
So now we know that we are running Windows 7 Service Pack 1 on an x86 platform, which is correct. So when we run future commands we will specify --profile=Win7SP1x86.
When I am running volatility I will typically run pslist first. Let's do that and see what we can find.
At first glance we see some interesting ones. I don't know about you, but ssl.exe, ogyr.exe, WinMail.exe, and cmd.exe seem a bit odd to me. I say cmd.exe because I know it wasn't running while I had the system up so it's worth taking a look at. I also say, WinMail because I don't use it, and it has no reason to be running. Back to the whole, "know what's normal" comment I made in Part I.
I always run psscan after I run pslist. Why not just run psscan and forget about pslist? Good question, but it's the deltas that I am after between the two commands. The lack of information in pslist can be an indication in itself. That's why I will run pslist and psscan. I want to see what's not showing up in pslist and vice versa.
What do you mean? Well, pslist is a volatility plugin that shows similar information if you were to run tasklist. Why does this matter? Well, windows uses doubly-linked lists of EPROCESS structures, meaning that each item points to the item before and after it (see pic below).
Malware can unlink these list and basically hides a malicious process from the pslist command, which is simply walking the list and telling you what it sees.
Malware does this via Direct Kernel Object Manipulation (DKOM). I'm no malware author, but from reading it seems like this is a standard (i'm sure a bit more technical) implementation of how it's done - They find a current process by way of PsGetCurrentProcess, then they find the EPROCESS to hide, and then change FLINK and BLINK so it points to a valid memory region.
Here is a pictorial reference of what an unlinking might look like and why "walking the list" shouldn't be relied upon.
Psscan fixes this issue of un-linking processes by scanning through memory looking for specific EPROCESS data structures. Let's run it real quick and see if we can find anything different.
In this case I don't really see anything out of the ordinary between pslist and psscan. I do notice the ipconfig.exe could be hidden. I'll have to look into it. It could also be a ghost process. I didn't highlight it in red because it doesn't seem too significant.
Now I am going to run Psxview. I looked at the source code for Psxview (written by Michael Ligh - Author of Malware Cookbook) and what I gathered is that.... Psxview will determine processes and cross references them by enumerating processes from PsActiveProcessHead (pslist), enumerating processes with pool tag scanning (psscan), enumerating process indirectly by ETHREAD scanning (check_thrdproc), by walking the PspCidTable, by using the csrss.exe handle table.
If you're wondering what PspCidTable is like I did... The PspCidTable contains handles to all the processes and threads that are present on the system. It is used by the thread scheduler to keep track of which threads are to be scheduled.
Now i've highlighted these two items because from what I read if there are zeros in either pslist, psscan, or thrdproc it's an indication of DKOM. I don't believe these are anything to worry about so I will write them off as possible "ghost processes" vice calling it kernel manipulation. I've tried calling both items via their PID and offsets and I get, "Unable to read PEB for task." This usually happens when I have a ghost process that was exited prior to capturing the memory image.
Let's go ahead and see if there are any network connections. Since I am using a Windows 7 image I will use the netscan command, which will look for connections and also sockets.
I really didn't see that much here either. I saw a couple items that I couldn't scratch off the list. I compared a clean state and an infection state and the remaining connections were as follows:
I wasn't able to duplicate these port numbers either. Note: I am running this in a closed environment so that could also impact the results. From Part I we know that upon execution it attempts a DNS query against dns1[dot]nsdnsrv[dot]com, which according to Zeus tracker is currently offline.
I'm going to go ahead and run malfind and see what it can come up with.
Along with a laundry list of other items we got some hits on a couple of the items. We notice that some of the same processes matched the output from psscan and pslist. We listed them as suspect, so this is helping to validate our assumptions earlier.
Let's go ahead and run the zeusscan2 command and see if we can find anything.
We can see that we got some hits here using the zeusscan2 command in volatility.
After dumping those files from running malfind I decided to move them over to my Windows XP box and ran Bintext against them. I also tossed them in Dependency Walker. If you compare the items in Depends now with what he had in Part I you will see a lot more items listed here. I'm guessing this is because malware has to unpack itself while running, and since we dumped these from memory it was running.
Here is the output from Bintext and also Dependency Walker.
After Bintext and Depends I wanted to take a look at a couple more items. Specifically the pstree so I can get and idea of what spawned what.
As we can see it appears that ssl.exe was executed, and then spawned ogyr.exe, which makes sense given then Pid and PPid. We could have determined this above when looking at the output from psscan and pslist, but I always enjoy running other commands. Likewise with svchost.exe and dwm.exe. How of these items came up in malfind, which is what I highlighted them in here/
I was curious what DLLs were loaded with ogyr.exe (still wondering if this is a playful word for "orgy"). Do the authors have a sense of humor?
I wanted to run one more volatility command to bring it back full circle. The printkey command allows you to print a specific registry key. In this case I picked the \Run key, which is/can be used as a persistence mechanism for malware authors. This exe will run every time the system is restarted. As you can see our ogyr.exe is set to execute at run time.
So this is going to wrap up the Zeus Analysis. I don't have a good enough understanding of Assembly to start digging into the guts yet. I need to crawl before I can walk.
I wanted to highlight this section and show how useful memory forensics can be. We were pretty much able to obtain an equal amount of information just by using memory forensics alone.
I hope you enjoyed these two posts. In the meantime I need to study for my GREM cert so I need to focus :)