The VMDK file is locked by the ESX hypervisor when the host is active. Without access to the vCenter instance or SAN/NAS/Storage device directly, this is a problem.
This is a problem particularly when your target is privileged information... like the NTDS.DIT file for an Active Directory domain.
As you can probably guess, this was an issue I recently investigated and an attack that was devised from it.
VMware places a lock on the active VMDK file to prevent any sort of tampering/corruption/access issues with a live host. This is, by design, a safeguard against a number of attacks. When presented with hypervisor access (strictly on specific hosts), but the ability to administer parts of the system, this is a fairly easy issue to bypass.
In this case, I was after the NTDS.DIT file. This attack blended a number of operational security flaws and strategies to bypass active security controls.
First, with access to the hypervisor and disks, the issue is removing any restrictions by VMware to accessing the VMDK file which operates as the fixed disk for the host. Without a command line or vCenter, you aren't left with many options.
So what do you do?
Snapshot the host.
Snapshotting the host creates a new VMDK delta file. Essentially, for hypervisors, this becomes the "new hard disk", with the OLD, original VMDK file as the "reference disk." The new VMDK DELTA FILE is where the host goes to write/read any changes from the reference disk. The lock on the original disk is essentially "moved" to the new disk. The old disk exists as a reference and restore point.
From this point onward, you are able to clone/copy the original VMDK file as you see fit with NO restrictions from VMware.
Next, you take the original VMDK file and copy it to a new location. This allows you to spin up a NEW host with the old disk, enabling you to modify or play with the original machine. As Active Directory logs changes and syncs via DFS, you will have a copy of the schema as of whatever that period of update is set by the network administrator.
The problem now becomes "How do I get that NTDS.DIT file?"
I'm glad you asked.
This is an OLD SCHOOL trick from a LONG TIME ago.
You have the ability now to treat the DOMAIN CONTROLLER as if it's a physical host. In ye olden days, this was gold.
Spin up the newly cloned DC as an ISOLATED VM. DO NOT UNDER ANY CIRCUMSTANCES ALLOW IT TO CONNECT TO THE NETWORK OR YOU WILL DESTROY AD. Period. No questions asked. DON'T DO IT.
Spin up the new host and it will likely fail. This is good.
Load up an ISO (you can do this on another host, but windows security will be an issue for permissions.) that allows you to obtain file system access. (Hiren's is a nice choice.)
Boot the ISO on the new host with the ISO as your boot/live disk.
(Edit: Yes, I know that in certain environments, just loading up an ISO or live disk *cough*kali or a vanilla Linux*cough* and copying the files out directly is much shorter and completely valid as an attack here. The issue at hand was an additional layer of security that made that type of attack here unfeasible and unnecessarily "loud".)
Navigate to the system drive: \windows\system32.
You will see two files of interest. CMD.EXE and UTILMAN.EXE.
UTILMAN is awesome. It's the accessibility option/menus for windows that HAPPENS to be accessible pre-login. (Windows + U or the icon in the lower left corner.)
Rename UTILMAN.EXE to something else. DON'T DELETE IT.
Make a copy of CMD.EXE (or whatever executable you want) and rename it UTILMAN.EXE.
Reboot the target into windows. You may want to try DIRECTORY SERVICES RESTORE MODE and it may only boot to that. Without network connections, the DC will likely take 30 minutes to boot, if at all.
Directory services restore mode is fantastic. Typically, you can't login to a DC as a local admin as windows keeps you from doing so, to prevent this exact type of attack.
DSR allows you to do so.
Eventually, you will boot into windows in DSR. Hotkey WINDOWS KEY + U or click the icon in the bottom left corner... VOILA! You are presented, prelogin with a command line running in the context of NT AUTHORITY / SYSTEM. This is a non-interactive, super user account.
Change the local password through this command line to one of your choosing.
Next, login locally to the AD domain controller with this and you are now the administrator of the machine.
From this point, extraction of the SYSTEM hive and NTDS.DIT is fairly simple. Copy/paste the files to a different location, reset the security descriptors and exfiltrate the data. Since you DON'T WANT TO HOOK IT UP TO THE NETWORK, an alternate drive/vmdk to copy to works... or you can simply add the VMDK as a hard drive on another host you do control.
That's it. A nice way to obtain privileged, secured system data from a host with only hypervisor access.
Enjoy.
