AWS IAM Recon
This post will focus on tools for performing IAM permission enumeration on AWS accounts. Custom, poorly written IAM roles and policies are some of the most common misconfigurations in regards to AWS architecture. That said, we'll discuss various resources that can help you breathe easier. First is MAMIP, a simple change log to assist in the monitoring of Managed AWS IAM policies: https://github.com/zoph-io/MAMIP. Managed IAM policies are something in constant flux, updates are constantly made to ensure proper configuration but also to support additional function(s) for associated services. If you're not one for writing custom policies with zero trust (least privilege), they're the next best thing and present a set-it-and forget-it option focused on ease of use.
Pentesters tend to leverage IAM for privilege escalation and lateral movement in order to pivot between services and associated resources hosted on AWS. In order to learn common methods for exploitation, a few options come to mind. CloudGoat by Rhino Security offers a set of activities focused on AWS misconfiguration scenarios and how to exploit them successfully: https://github.com/RhinoSecurityLabs/cloudgoat. An alternative option is the BlackSky labs built by HTB https://www.hackthebox.com/blog/BlackSky-cloud-hacking. Hailstorm is a lab that leverages AWS exercises to explain and teach exploitation in cloud environments across multiple services. As someone who beta tested the labs prior to release, I'll tell you they are extremely accurate as to what you can expect to find out in the wild.
Let's say you're not sure where your current environment stands from an IAM perspective... weirdAAL is a tool that enumerates IAM accounts across global AWS footprints. It's a great tool for both blue and red teamers alike. It simply shows you every action available under each associated AWS service. From here, attacks are possible when leveraging the AWS CLI to perform actions. You can review weirdALL and associated usage steps here: https://github.com/carnal0wnage/weirdAAL/wiki/Usage. Install and configuration for reference:
git clone https://github.com/carnal0wnage/weirdAAL.git
cd weirdAAL
python3 -m venv weirdAAL
source weirdAAL/bin/activate
pip3 install -r requirements.txt
Create a .env file with aws credentials such as
[default]
aws_access_key_id =
aws_secret_access_key =
Setup DB
python3 create_dbs.py
Invoke it
python3 weirdAAL.py -m ec2_describe_instances -t ec2test # Just some ec2 tests
python3 weirdAAL.py -m recon_all -t MyTarget # Check all permissions
You will see output such as:
[+] elbv2 Actions allowed are [+]
['DescribeLoadBalancers', 'DescribeAccountLimits', 'DescribeTargetGroups']
With two sides of the coin, you have the ability to enumerate and test existing users/permission sets to ensure they only operate as intended.
There's one more extremely helpful resource that focuses on privilege escalation methods within AWS IAM. RhinoSecurity has a repo for listing IAM permission actions and their associated potential impacts: https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation#aws-iam-privilege-escalation-methods. It's worth looking over the required permission sets within each method listed to see if they either exist in your account(s) and/or outputs.
At the end of the day, there are a few pieces of wisdom worth passing along. For any service-to-service communication, IAM roles should always be leveraged effectively to support basic functions. If you're leveraging AWS CLI credentials, rotation should happen frequently. The same applies to native secrets manager and SSM parameter store. Privileged Access Management solutions such as Teleport https://goteleport.com or a native approach to session management via AWS SSM https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html are highly recommended. These solutions provide a way to track user activity via recording as well as build trails to identify potential threats, both pair effectively well with the AWS CloudTrail service to track usage based events.