One of the things we always need to understand when it comes to information security in order to protect or attack a given environment is the attack surface we have at our disposal. To achieve this, it’s common for attackers to use enumeration techniques and from there look for flaws in services, configurations, as well as other types of vulnerabilities that may occur due to the lack of proper application of security patches and implementation or deployment malfunctions.
Wondering how to understand the customer cloud attack surface, develop protection techniques and use-cases for our cloud-focused SOCs, and use the enumeration information in attacks and cloud architecture consulting work at Tempest, we started to investigate and dedicate time to role enumeration methodologies and techniques. We started with existing research from other companies; however, we decided to add some “extra spice” to what was already published and began researching roles that some services create when started in an Amazon Web Services (AWS) account. The result of this research was quite interesting. We were able to list twenty-eight (28) services immediately. Still, we believe that by digging deeper, we are likely to come up with a few dozen extra (probably more than 100 services), especially considering that we have almost three hundred (300) existing AWS services.
As a result of a first analysis, we managed, in an unauthenticated way and without generating audit events on a target account, only in possession of the account id, to identify if the following services listed below are present in the account::
- Access Analyzer Service Found
- Amazon Certificate Manager (ACM) Service Found
- Audit Manager Service Found
- Backup Service Found
- Batch Service Found
- CloudTrail Service Found
- Cognito IDP Service Found
- Config Service Found
- Direct Connect Service Found
- EKS Service Found
- Elastic Container Service (ECS) Found
- Elastic File System (EFS) Service Found
- Elasticsearch/Opensearch Service Found
- EventBridge Service Found
- GuardDuty Service Found
- Inspector Service Found
- Lightsail Service Found
- Macie Service Found
- Network Firewall Service Found
- Organizations Service Found
- RDS Service Found
- Redshift Service Found
- Resource Access Manager (RAM) Service Found
- Route53 Resolver Service Found
- Security Hub Service Found
- Support Service Found
- System Manager Service (SSM) Found
- Trusted Advisor Service Found
As stated before, we started based on some existing research. For practical purposes, we used the PACU Framework (https://github.com/RhinoSecurityLabs/pacu/) in this scenario, an open-source tool created by Rhino Security to perform offensive tests in environments hosted on AWS. PACU allows analysts working with offensive security consulting to perform enumerations, privilege elevation, lateral movement, persistence, etc.
Within our research scope, we used PACU and two of its unauthenticated enumeration modules, one for IAM (Identity & Access Management) users and one for roles; the latter method was used for our needs.
When using the role enumeration module, it needs only one piece of information, namely the account id. However, if you want to use your own wordlist, then we need to add an extra parameter. Therefore, the parameters used were:
We created a wordlist file and placed the default roles created by the services used in AWS through a “linked role” of the service, which was the target of our enumeration. If the role exists in the account we are evaluating; then we can conclude that the account is using that particular service.
Thus, the initial result simulating the creation of these linked roles was a list of twenty-eight (28) services as listed below:
With this wordlist in hand, we created a bash script to map the findings with the services into a more accessible and more direct nomenclature, and then we will have the results according to the script output below:
As can be seen in the previous images, it’s evident that it’s possible to use the technique to identify if the listed services above are present in the account without the need for authentication.
Regarding an example for offensive works, an interesting approach is that we can use this enumeration of services to verify the existence of protection services such as Guard Duty, Security Hub, Config, Inspector, which can give some insight into extra security precautions and good practices for the account when they attempt to use an access key or access the control plane, allowing the attacker to better prepare himself by seeking to act in a more stealthy way for greater effectiveness in the attack. On the defense, governance, and risk side, this enumeration can become a scoring system to validate if the account has services and the best practices, such as Organizations, Cloudtrail, Access Analyzer, Guard Duty, and others.
In addition to these possibilities of better understanding how the company’s cloud environment is architected, we can, from the standard permissions involved in each of these roles, create a standard map of privileges in the IAM for the service(s) found in the enumeration.
We’ll map to a second part of this enumeration article all the policies linked to these roles and publish it, here at SideChannel, the possible risks and impacts that may exist in its environment.
Due to the way this role enumeration works will only generate events in the source account (the attacker’s), i.e., it won’t generate events in your account, making this enumeration invisible for detection in the target organization.
 – RHINO Security Labs. Assume the Worst: Enumerating AWS Roles through ‘AssumeRole’. Available on https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/ . Accessed in 01/Out/2021.
 – Github. Rhino Security Labs/PACU Framework. Available on https://github.com/RhinoSecurityLabs/pacu/ . Accessed in 02/Out/2021.