DC in the cloud
There could be many different reasons that require Domain Controller running in the cloud:
- Overal company direction to get rid of the on-prem data center with all of the supporting services including Active Directory, DNS and DHCP
- Legacy application has to be migrated with native network-level support for AD
- Isolated mirror of on-prem AD environment has to be created for tests
- Emergency option for a backup domain controller of an on-prem AD infrastructure
- Replication from regionally located domain controllers
Most likely I forgot to mention a couple of other good reasons to do that, BTW if you know a good use case - let us know in the comments
Security Issues
It seems like a lot of people who are about to do such a deployment of DC in the cloud, missing some of the important aspects.
This is going to be a VIRTUAL MACHINE in most of the cases
While on-prem most of us would probably opt to use physical Domains Controllers because of many reasons including security measures - when hardware such as disks and other stuff cannot be easily accessed remotely this creates an additional level of protection.
When VM is out there on the local hypervisor, the hypervisor is again most of the time physically in the server room and hardware is protected, although hypervisor creates an additional layer of API that can be used to access virtual hardware such as VM disks. However, I would argue that attacks and vulnerabilities on hypervisors are not so common.
Now let's compare this to the cloud. very rich and powerful APIs which intended for the good - optimized and simplified usage of resources in the cloud. However, while providing improved usability and access it opened additional ground for hackers to attack the infrastructure and cloud resources
IaaS snapshot credentials dumping attack (MITRE T1003)
Recently I saw this post from Forty North Security researcher about using Azure to perform credentials dumping via snapshotting Domain Controller disk and mounting it to a hostile VM, in a nutshell, it works like that:
- Make a snapshot of a Domains Controller's drive
- Convert snapshot into a disk (if necessary)
- Mount a virtual disk to a hostile VM
- Use credential dumping tools to obtain password hashes for the entire domain
This attack is a replica of a similar technique for AWS and it makes sense to mention how security researcher (Tanner Barnes) unveiled the opportunity:
- First, he got access to a Python script that had credentials for accessing the cloud storage account
- By crawling in the storage account researcher discovered a VM image and downloaded it
- VM image turned out to be a developer's workstation with built-in administrative permissions to the cloud
- Administrative permissions were used to perform a credential dumping attack on DC VM using cloud snapshots
It's important to mention that both researchers were actively using APIs provided by a cloud provider and because it is very user-friendly and a lot of tools are available it is way easier to do exploratory work such as that above for cloud rather than for on-prem hypervisors
While there are managed alternatives to running domain controller in a VM, sometimes it still may not be possible, so keep in mind that in certain cases security in the cloud should be taken more seriously than for similar systems on-prem
Cloud is great, but it is different - I think we should never forget about this
Mitigation
As Tanner Barnes mentioned in his analysis for the attack against AWS - some may think that encryption could be used to provide better security, but disk-level encryption will not stop someone who hacked an account with enough permissions to do the snapshot in the same AWS account. Potentially volume encryption could work as it may potentially prevent from reading data from hostile VM, but additional research is required on if this option works well on IaaS VMs
Detection
A better way per Tanner and I would completely agree is to lock snapshot permission creation permission to a group of accounts with MFA and audit every snapshot creation event, luckily this is possible on both Azure and AWS.
In Quest, we are developing new technology that will allow seamless integration of VM logs into the same InTrust Log Management system that is working for on-prem systems. In addition to that, we are going to provide support for collecting Azure Diagnostic logs using Azure Event Hubs.
Here is an example of how snapshot action looks like in the Azure activity logs, we are currently working on adding the ability to collect these logs into InTrust
