Select Monthly Archives
- September 2019
- August 2019
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- December 2013
- September 2012
Written By: Jayme Hancock May 06, 2019
One of the more common findings on penetration tests is open and unsecured file shares. Whether it’s NFS or SMB, these shares can be enumerated and analyzed for system data or network documentation, scripts can be searched for hard-coded passwords, and employee personnel lists can be used in social engineering engagements. But one particular risk opens up avenues for fast and easy network-wide exploitation: Virtual Machine files not secured by access control lists or encryption. In this blog post we’ll explore a few quick but devastating avenues of attack against virtual machine files. These VMs don’t need to be online – if we have access to a few key files, we can read the contents of the process lists, extract password hashes, and even extract plain-text passwords from memory. For the purposes of this blog, we’ll use VMware files in the examples – though the process is similar for other virtualization technologies.
Method 1: VMWare Hard Disks
One of the first files to look for and exfiltrate is the VMware Disk (VMDK) itself; the VMDK is the file that represents the hard drive in a virtual machine. This is usually the largest file in the directory, and assuming you have the infrastructure and bandwidth to exfiltrate it or move it to your penetration testing machine, the process is simple. In this example, we’ll be using a Kali system to attack a Windows 7 Virtual Machine’s VMDK file.
- Exfiltrate the VMDK from the open file share.
- Attach the VMDK as a secondary hard disk on the Kali VM in your virtualization software.
Figure 1 –The Attacker attaches the VMDK to their virtual machine.
- Start the Kali VM. Use the command “fdisk -l” to determine the location of the newly attached drive and partition. In this example, the partition is located at /etc/sdb1. Note that the “Size” field may differ from the physical size of the VMDK file, as some disk options don’t allocate space until it’s needed:
Figure 2 – The hard disk is attached as /dev/sdb1 in the Kali VM.
- Mount the disk to an empty directory using the command:
mount -t ntfs /dev/sdb1 /path/to/mountpoint
Verify that the disk is accessible by listing the directory:
Figure 3 – The hard disk is mounted in Kali.
- Next, we use the “samdump2” tool in Kali to extract Windows password hashes, using the command
samdump2 /path/to/SYSTEM /path/to/SAM
Figure 4 – Extracting password hashes from the exfiltrated VMDK.
- Finally, we can crack the password using Hashcat. In this case, the hash mask is 1000 (NTLM)
Figure 5 – Cracking the passwords with Hashcat.
- With plaintext passwords and usernames, we can now log into the remote system as local administrator, spray the password across other systems, or abuse other integrated services.
Method 2: Forensic Pwning
While the above method is extremely effective, what options do we have if the VMDK isn’t obtainable, is missing or damaged, or the password is uncrackable? Fortunately, we have options. Professional forensicators use a tool called Volatility (https://github.com/volatilityfoundation/volatility/) for in-depth memory forensics investigations. As penetration testers, we can leverage Volatility to extract sensitive information directly from the virtual machine’s memory, using its VMEM file. Note that you’ll need to install Volatility if you’re using Kali, as it’s not included on the image.
- The first step we need to perform is to identify the version of Windows we’re working with. This goes beyond just “Windows 7” or “Windows 2012” – Volatility needs a specific profile to perform most of the following commands. Once the VMEM file is exfiltrated and on our Kali VM, we can use the following command to analyze the VMEM file and determine what profile to use. In Figure 6, we can see the suggested profile is “Win7SP1x64”, so we’ll include that in future commands:
python vol.py -f vmemfile.mem imageinfo
Figure 6 – Analyzing the VMEM file for profile information.
- We can start by doing some basic system recon. In this case, we’ll run the module “pstree” to see what processes were running on the system at the time the VMEM was saved. This information could be useful for determining things like endpoint detection software or antivirus software that may prevent or detect future exploits:
python vol.py -f vmemfile.mem –profile=Win7SP1x64 pstree
Figure 7 – Analyzing process information.
- A number of recon and enumeration modules exist in Volatility, and I’d encourage you to explore them all. But we’re here to pwn, so let’s find some credentials. Volatility has a built in hashdump module which functions much like samdump2 in the first method, but we don’t need access to the physical files or a mounted disk. The hashes can be dumped with the following command:
python vol.py -f vmemfile.mem –profile=Win7SP1x64 hashdump
Figure 8 – Dumping password hashes from the VMEM file.
- As in Method 1, we can crack these hashes offline using Hashcat. But what if the passwords can’t be cracked? What if the VM has Microsoft’s Local Admin Password Solution (LAPS) enabled, or the password is strong enough to make offline cracking unfeasible? For some attacks, the password hash may be enough – pass the hash attacks are commonplace and many publicly available hacking tools support it. However, we have another option: the lsadump module. This module searches for plaintext passwords used by the Local Security Authority (LSA) and displays them in a format that makes cracking unnecessary – just remove the periods. The following command can be used:
python vol.py -f vmemfile.mem –profile=Win7SP1x64 lsadump
Figure 9 –Extracting plaintext passwords using lsadump.
You can see how quickly a Virtual Machine located on an insecure share can become a treasure trove for an attacker. Virtual Machines should be treated as if obtaining them resulted in physical access – because for all intents and purposes, it does. Fortunately, remediating the problem is pretty simple; put strong access control in place to secure file shares. Use firewall rules to block any unnecessary connections to file servers hosting Virtual Machines. Finally, encrypt virtual machines so they can’t be mounted without knowing the decryption password.