This article is covering multiple ways to enumerate the resources within an AWS environment. We’ll explain how to perform enumeration, what you should look for, and multiple ways of doing it, both automated and manual.

1. What you should look for

First, the easiest way to identify attack vectors or misconfigurations is to perform a complete enumeration. This includes all the resources, permissions, and configurations.

However, not everything deserves the same attention. A higher focus should be put on services from which you can exfiltrate access credentials or on IAM resources that can lead to privilege escalation.

Additionally, you must know your goal. If you’re performing a cloud security configuration review, then you should focus on anything that can be improved, like encryption at rest or in transit, proper logging practices, and so on. Whereas, if you’re on a penetration testing/red team engagement, the previously mentioned aspects would not be of interest and the focus should be on practical exploitation.

2. Prerequisites

The ideal way to perform discovery and enumeration is by having read-only access over all the resources within the target account.

For this, there are two options:

• The client provides a role with global read-only permissions that we will assume from our account
• The client provides access to a user within the target account that has global read-only permissions

From these options, the simpler one for both parties is the role-based approach. For the second option, we would need to receive a set of access keys in order to perform checks from AWS CLI and automated tools.

There’s also the scenario where the client wants to simulate an insider threat and gives us the same level of access as another account, a case in which we might have both read and write permissions.

3 Manual discovery and enumeration

3.1Enumerate everything

A good approach, especially when you also want to improve your AWS knowledge, is to enumerate literally everything by using AWS CLI.

How can you do this? Well, an AWS CLI command has the next structure:

aws [options] <command> <subcommand> [parameters]

# For example:
aws --region eu-central-1 ec2 describe-instances --instance-ids $instance_id

Every command and subcommand has good documentation that can be accessed appending help at the end of the command.

So, if you’re new to AWS and don’t know where to start, just type aws help and see the list of available services.

Next, choose a service or just take each one at a time and start the enumeration. There are 3 keywords available for every service that are pointing to an enumeration subcommand: describe, list, and get. The exception is the s3 service which uses ls as a subcommand for enumeration.

Nonetheless, just choose a service and hit aws service help. Now, look for subcommands that contain “describe”, “list” and “get”. Let’s do an example with Lambda Functions.

In the above screenshot, we got a list of the commands that we can use to enumerate the Lambda service. Note that some subcommands will require information already gathered in order to enumerate. For example, by running list-functions we’ll get the list of lambda functions. Based on this information we can enumerate further with other commands like get-policy.

One trick to simplify the process is to directly run the subcommand. If you’re missing arguments, the AWS CLI will return an error and specify what mandatory parameters you should feed.

This process is very time-consuming but is helping you to better understand what AWS has to offer, what you should enumerate, and what are the common services that you can prioritize in the next engagement.

The last thing to keep in mind is that some AWS resources are region dependent, meaning that if you configured your AWS CLI on eu-central-1 and that resource is created in us-east-1, then you would not be able to identify it without mentioning the right region.

In part II of this article, we’ll provide a list of the most useful enumeration commands based on the service’s importance and the risk that a misconfiguration can bring there.

3.2 CIS Benchmarks

You can use the CIS benchmarks to go through some of the most common and of interest services in order to see what the target is using.

Although these resources are better for performing a cloud configuration review if you have limited experience with AWS this would help you to get started. The benchmark is especially useful for learning because it details the risk, but also provides remediation solutions.

References:

• CIS Amazon Web Services Foundations Benchmark v1.4.0
• CIS AWS End User Compute Services Benchmark v1.0.0
• CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0

The CIS benchmarks can be downloaded from https://downloads.cisecurity.org/ once you made a free account.

3.3 AWS Resource Groups & Tag Editor

At the moment, AWS doesn’t have a central dashboard for viewing all the resources and services used. However, if you have access to the web console, you can use the service AWS Resource Groups & Tag Editor for enumerating all the resources within the account. The next screenshot exemplifies this:

The advantages are:

• You can search across all regions at once
• You can search for all the services at once
• You get an exportable list with all the identified resources

The disadvantages, however:

• The search result will identify maximum 500 items in a single search
• You get a lot of results that are not of interest

To overcome the disadvantages, you should adjust the Resource Types so that you will get only resources of interest and also stay below the 500 results limit. A nice feature is the CSV export which can help you to process and analyze the results more efficiently.

4. Tools

There are multiple tools available for enumeration and each one is good for specific scenarios. I’ll present you 3 tools that make my life easier and a few mentions that I’m sure you’ll like to have them bookmarked.

4.1 ScoutSuite

URL: https://github.com/nccgroup/ScoutSuite

This is my favorite one and it also supports Azure and GCP. The tools enumerate the most important resources like IAM, EC2, Lambda Function, EKS, Secrets, S3, and more.

Besides that, it displays the result on a web page which makes it easy to navigate through the identified resources and check their configuration.

Even better, it marks certain misconfigurations and correlates them with the CIS benchmark. The tool is especially useful when you have to review multiple AWS accounts or services with numerous resources.

4.2 pacu

URL: https://github.com/RhinoSecurityLabs/pacu

This is an exploitation framework similar to Metasploit. It has multiple modules for enumeration, however, what makes this tool different is the ability to exploit the cloud environment once you have access to it.

It has some cool modules like backdooring an EC2 instance, checking for privilege escalation vectors, and more.

4.3 iam_enumeration

URL: https://github.com/andresriancho/enumerate-iam

This script is useful for determining what permissions you have. Let’s say you managed to exfiltrate a set of access credentials and now you are trying to determine what permissions are associated with them. The tool does exactly that. However, it doesn’t try to write operations, meaning that it will not discover all the permissions.

Pacu also has an IAM enumeration module but is more limited than this script.

4.4 Rhino Security privilege escalation scripts

URLs: https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation, https://github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/aws_escalate.py

I love the research done by Rhino Security (authors of Pacu). Make sure to check their blog for some good quality research on Cloud security. They have two articles on AWS privilege escalation vectors where they explain and exemplifies over 20 vectors of privilege escalation.

Even more, they created a script that will check if any of the known vectors are possible to be executed in the context of your permissions.

4.5 PMapper

URL: https://github.com/nccgroup/PMapper

This is a tool for analyzing IAM resources (roles, users, permissions, etc.). The nice thing is that it can generate a graph that can be analyzed in order to see who can assume what role, what policy is attached to what service, and so on.

5. Manual vs Automation

Automation:

• Fast
• Mostly based on “one command” checks
• Useful when the scope is big
• Might provide false positives
• Does not cover cross-account analysis

Manual:

• Takes more time
• Identifies complex misconfigurations and attack vectors
• Identifies logic issues
• Identifies weak points that might impose a security risk
• Good for cross-account analysis

6. Final thoughts

We saw what are the approaches when it comes to performing a cloud configuration review whether you’re doing a manual review, using tools, or both. For the best outcome, it is recommended a combination of manual configuration review and automation enumeration. Use tools to catch some low-hanging fruits, get a feel of the environment, and do the rest manually to cover those complex scenarios that would make a great article or presentation.