Obtain D.C. Hashes within Azure in 4 Easy Steps
Extraction without Interaction
A while back, I read this article from @_StaticFlow_ about a tool release for stealing hashes from a domain controller running in AWS. I tested the process manually and was able to extract the password hashes without ever needing to interact with the domain controller itself. The general process for doing this is as follows:
- Make a snapshot of the domain controller’s hard drive within AWS
- Convert the snapshot into a volume within AWS
- Mount the volume to a different virtual machine you control (I tested with a Debian ec2 instance)
- Use something like SecretsDump to obtain the password hashes from the mounted volume
(Or, use @_StaticFlow_’s CloudCopy tool to automate the process within AWS)
Recognizing how useful this type of shadow copy abuse could be for our red team engagements, I wanted to know if it was possible to follow the same process against domain controllers within Azure.
1. Set Up the V.M. within Azure
To start, I deployed a Server 2016 Datacenter virtual machine within Azure, installed the Active Directory role, and added a new user to Active Directory (so I could validate the hashes later on).
2. Take a Snapshot of the D.C.’s disk
Next, I took a snapshot of the domain controller’s disk within Azure by clicking the “Create snapshot” button.
Once you click on the “Create snapshot” button, you are taken to a new page to provide information about the snapshot.
All that is really needed is the name of the snapshot that you are going to create and the resource group it will reside within. Click the “Create” button at the bottom to create the snapshot.
3. Convert the Snapshot into a Mountable Virtual Disk
With the snapshot created, I then converted it into a mountable virtual disk. Click on the “All services” option on the left, specify the “Compute” services, and then access the “Disks” option.
Once in the Disks menu, select “Add” a disk, and then you will be presented with the following screen.
Note: Make sure the region you are creating the disk in is the same region that your snapshot resides.
For the “Source type”, select “Snapshot”, and then your “Source snapshot” should be the snapshot that you just created. Once you have everything selected, create the disk.
4. Attach the Disk to a New or Already Running V.M.
The final step is to create a new virtual machine (if you don’t already have another one running) and attach the newly created disk to it. If you’re creating a new virtual machine, just add an additional data disk during the virtual machine configuration step (make sure you select the disk you just created which contains the hashes).
Once the virtual machine is created, mount the disk, and then browse it like a normal folder! In my case, I copied the SYSTEM, SECURITY, and ntds.dit files off the mounted disk onto my Debian VM itself and installed Impacket. From there, I ran secretsdump against the correct files and obtained the password hashes.
From here, there are several ways you could abuse the domain hashes, including creating a golden ticket.
You can attempt to prevent an attack such as this by following a few best practices. First, start by ensuring all users have enabled multi-factor authentication. Additionally, confirm that only administrative users have the ability to see and interact with sensitive systems/data within Azure. Administrators can also create rules that can prevent users from making snapshots of disks within Azure. To do this, you will need to restrict the “Microsoft.Compute/snapshots/write” permission. A full list of operations can be reviewed here.
As a red team lead, I’m constantly looking for new avenues to compromise systems and it looks like cloud services are still ripe for exploration . If you have any questions, don’t hesitate to Contact Us at FortyNorth Security and we’ll be happy to help in any way we can!