AWS: Assuming Access Key Compromise

Jordan Drysdale//*

In this blog, we are assuming that we have obtained an access key, a secret key and maybe a .pem key from a network user who left these things lying around. What services do they have access to? How far can we get?

Here we stand again, on the shoulders of giants with the prospect of using their efforts to take advantage of someone else’s mistake. In this case, that giant is Carnal0wnage. His effort, the WeirdAAL ( toolkit, is another brilliant piece of work designed to audit the privileges belonging to a stolen set of AWS keys.

I cloned the utility in to /opt/ and checked out the, which sends you back over to the wiki. Some commands here:


cd weirdAAL

apt-get install python3-venv (if required)

python3 -m venv weirdAAL

source weirdAAL/bin/activate

pip3 install -r requirements.txt


cp env.sample .env

vim .env (insert keys in ignition, here)


Then, head over to usage and run the recon_all. My command looked like this:

python3 -m recon_all -t MyTarget > recon_out.file


We get results sorted per ‘enumerable’ service on AWS. This compromised user did not have IAM or root privileges.

However, the user has some EC2 privileges and access to a few other services.

To wrap up cleanly, we’ve compromised a domain user and stolen their AWS credentials (access and secret key). Using Carnal0wnage’s recon_all flag, we know exactly what this user can do on AWS. Further research might lead us in to another series of tools for AWS investigations: (H/T @dafthack).

Another day, another way. Cheers, and happy cloud securing.

*Join Jordan and Kent Tuesday, August 7th for their webcast as they walk through an Active Directory best practices environment. The deployment includes two Amazon Web Services (AWS) Active Directory Domain Controllers in a multi-availability zone configuration. The best practices will also cover some AWS basics, deploying your domain in the cloud, and lots more. Register here: