Log in

View Full Version : VM Snapshot Comparison to detect hidden files


Kayaker
September 4th, 2007, 18:23
An interesting idea to detect hidden files by a string comparison of VM snapshots:

Find out hidden files comparing VMware’s snapshots
http://zairon.wordpress.com/2007/08/31/find-out-hidden-files-comparing-vmwares-snapshots/


Hope you don't mind me bringing this up here for discussion Zairon. I'm curious, in the examples you've worked on do you have any idea *where* the exposed strings of hidden files/processes originated from?

Say for example a malware has hidden its driver through some DKOM technique such as unlinking from the PsLoadedModuleList. It's hidden from normal API routines and manual tracing of the linked list of loaded modules. However at some point it still has to load so there may be a rogue string buffer on the heap somewhere that was used by LoadDriver, or perhaps when it was extracted as a resource from an exe file.

I assume that's where some of these "traces" of the hidden file presence comes from, various string buffers that haven't yet been purged from memory. That's what makes this technique so clever. Following the preys spoor like a hunter, I love it

I wonder if there's a way of mapping the string back to its original location in memory in what would be the active VM?

Regards,
Kayaker

ZaiRoN
September 5th, 2007, 06:32
Hey K!

Quote:
I'm curious, in the examples you've worked on do you have any idea *where* the exposed strings of hidden files/processes originated from?
Not exactly, my first thought was: "there should be something in memory". Your comment about dkom was more or less my second thought. That's why I tried.
At first I wanted to perform a scan over VMware's process memory but the problem was: "what kind of string do I have to search?". Pretty impossible. So, I tried comparing the snapshots obtaining some nice results.

Quote:
I wonder if there's a way of mapping the string back to its original location in memory in what would be the active VM?
Interesting point. Now we could include the VMware's process memory in the game

bye!

Kayaker
September 5th, 2007, 16:04
On further study, I'm not so sure.. However I did discover a very interesting fact that opens up a whole new avenue for snapshot forensics.

According to a sample chapter on dumping and analyzing physical memory:

Quote:
When a VMware session is suspended, the contents of “physical memory” are
contained in a file with the .vmem extension.The format of this file is very similar
to that of a memory dump using dd.exe


Windows Memory Analysis
http://www.syngress.com/book_catalog/SAMPLE_159749156X.PDF

A similar comparison between a dd-style RAM dump and a .vmem file is mentioned here:

http://windowsir.blogspot.com/2006/09/win2003sp1-and-ram-dump-parsing.html


dd.exe is a well known forensic tool for dumping physical memory:

http://www.gmgsystemsinc.com/fau/


So I thought to apply some of the forensic analysis techniques to either a dd style RAM dump or the VMWare .vmem file.

One of the caveats with dd.exe is that the new version no longer supports the \\.\PhysicalMemory pseudo-device as input, which was the traditional syntax used to generate a RAM dump. I believe the option isn't available because physical memory can't be accessed from user mode in Win2003 or Vista. An older version would be more useful for XP. The alternative is a kernel version KnTTools, but is only available to institutions etc.


Nevertheless I decided to try dumping the physical image of a VMWare session and see what happened. To dump to the VM shared drive you first have to map the network drive to a letter (i.e. \\.host\Shared Folders\VMShared is mapped to Z:.

Usage: dd if=[SOURCE] of=[DESTINATION] [OPTIONS]

The syntax then being:

dd if=\\.\c: of=Z:\VMShared\image1.dmp --localwrt conv=noerror

This created a dump file pretty much the same size as the full 4Gb vmdk VM image. Not particularly useful at the moment but still a nice way of creating a full physical VM snapshot on the fly.


Giving up on DD for the time being I decided to go with the tenet that a .vmem snapshot is similar enough to a dd RAM dump that you could apply the same forensic techniques to it.

In the DFRWS 2005 Forensics Challenge the winning entry used a memparser program to reconstruct process information from a memory dump, including processes hidden by Hacker Defender.

http://dfrws.org/2005/challenge/betzReport.shtml
http://sourceforge.net/projects/memparser

I compiled the memparser source from sourceforge and applied it the .vmem snapshot. Sure enough it parsed correctly through the EPROCESS structures for all processes running when the snapshot was taken. The only glitch with the XP snapshot was that Memparser was created for Win2K so the EPROCESS offset for some of the fields were incorrect. This should easily be fixed through the source files.

Here is the somewhat successful output from a random snapshot I made which at least shows the theory works:

Code:

>C:\...\My Virtual Machines\XP Vx>memparser winxphome-Snapshot1.vmem

MemParser v1.3 Chris Betz, (c) 2005
No process list loaded.
In Windows 2000 Mode
Options:
l: Load the process list
<enter>: Quit
l

Searching for processes in memory dump
00%--05%--10%--15%--20%--25%--30%--35%--40%--45%--50%--55%--60%--65%--70%--75%--
80%--85%--90%--95%--100%
Enumerating process structures.
Sorting processes by PID
Checking for processes hidden by detachment from process link-list or processes
no longer active
Searching for all threads.
MemParser v1.3 Chris Betz, (c) 2005
Process List:
Proc# PPID PID InProcList Name: Threads:
0 3850 0 Yes én¦?
1 0 0 Yes
2 152 792 No én¦??
3 57 2064 No én¦?
...<snip>
23 15555 58824 No én¦?
In Windows 2000 Mode
Options:
#: Select a process
s: Show System Information
<enter>: Quit



There are various other forensic scripts around that one should be able to apply to the VM snapshot to get more information as well. As well as the previous links I mentioned the following is also indispensable:

http://computer.forensikblog.de/en/


Knowing now that VM snapshots contain such a wealth of information that can succumb to forensic analysis it would be interesting to see what else they can tell us.

Kayaker

Kayaker
September 11th, 2007, 22:29
Just a small update, Memparser correctly parses a VMWare snapshot from Win2K, including detecting a process (notepad) hidden by FU rootkit. This means the source can be tweaked for OS version specific EPROCESS offsets.

Code:

Searching for processes in memory dump --100%
Enumerating process structures.
Sorting processes by PID
Checking for processes hidden by detachment from process
link-list or processes no longer active
Searching for all threads.
MemParser v1.3 Chris Betz, (c) 2005
Process List:
Proc# PPID PID InProcList Name: Threads:
0 0 0 Yes Idle
1 0 8 Yes System
2 8 140 Yes SMSS.EXE
3 140 164 Yes CSRSS.EXE
4 140 184 Yes WINLOGON.EXE
5 184 212 Yes SERVICES.EXE
...
14 748 756 Yes explorer.exe
15 756 820 Yes VMwareTray.exe
16 756 844 Yes VMwareUser.exe
17 756 964 Yes CMD.EXE
18 756 1048 No NOTEPAD.EXE


dELTA
September 12th, 2007, 02:12
Very interesting work ZaiRoN and Kayaker, keep us posted on any progress!

ZaiRoN
September 19th, 2007, 13:34
I got some requests so I decided to make it available for everyone. It's more or less the original program I used for my first test; I wanted to add something more, but it's impossible at the moment... I'm too busy.
Anyway, tell me about everything (bugs/comments/...).

Regards,
Z.