Introducing Quiet Riot

A Scalable AWS Enumeration and Footprinting Tool


This is a screenshot of the initialization of the Quiet Riot scanning tool.
Quiet Riot Initialization

Today I am releasing Quiet Riot, an “unauthenticated” tool for enumeration of services, roles, and users in an AWS account or in every AWS account in existence.

Update: I’ve also written a follow-up post describing additional capabilities, overall tool impacts, and relevant mitigations.

AWS IAM and Resource-Based Policies Background

AWS services that work with IAM include a number of services that support “resource-based policies”. These resource-based policies allow direct access to AWS service-level resources and are evaluated prior to Identity-based policies when determining whether a given user (unauthenticated user, any authenticated AWS principal, or a specific AWS IAM principal) has access to the specified resource. You can see the approximate policy evaluation logic of AWS IAM below:

This is a picture of the policy evaluation logic for determining what access is authorized in AWS.
AWS Policy Evaluation Logic

Furthermore, AWS defines an IAM Principal as the following:

  • AWS account and root user

Why it matters

To determine the validity of a particular resource-based policy, the AWS IAM engine validates the form of a particular policy and critically, the validity of included AWS principals, at the time the policy is attached to the relevant resource. Many services that support such resource-based policies will throw an error for an invalid AWS principal in the policy. This means that a policy containing a single AWS principal can be used as a proxy to validate whether that principal exists or not….EVEN FOR ACCOUNTS THAT YOU DON’T OWN.

E̵x̵p̵l̵o̵i̵t̵a̵t̵i̵o̵n̵ “Featureploitation”

Originally identified by Daniel Grzelak and subsequently re-discovered a number of times, this technique can help attackers with a key capability — enumerating attack targets (Account IDs) and the associated footprint (root account e-mail, roles, users).

While AWS considers this capability a “feature”, I am curious to see what scale of featureploitation might change the perspective. To this end, I have developed an Offensive Security Tool (OST) to exploit this AWS feature for the maximum possible impact. Even this idea is not new. Will Bengston has previously suggested a similar technique. Seeing as how I haven’t found a tool that implements Will’s suggestion and I have limited software development experience, I decided to take the opportunity to hone my Python chops further.

Quiet Riot Capabilities

To use Quiet Riot, once you clone the repository, you can run as the entry-point (and with sufficient credentials available to the aws cli) to perform automated deployment of scanning infrastructure (SNS topic, ECR-Public repository, and ECR-Private repository) and initiate dictionary-attack scanning for Account IDs, roles, and users across AWS. On completion, the scanning tool writes the results to the results/ directory and deletes the associated infrastructure.

Footprinting, Account IDs, and future state

I have included the beginnings of a wordlists directory, but would invite pull requests geared towards including better wordlists. In particular, static vendor users and roles and AWS “service-linked” roles give strong insights into the services and platforms/applications that a particular AWS account has configured.

I have included a list of AWS Account IDs identified so far by the tool. Given that there are 1 trillion potential Account IDs, it is unlikely I will ever enumerate all of them…but that won’t stop me from trying. See progress on this topic (wordlists/provided_account_ids.txt).

Finally, I have included a wordlist (wordlists/service-roles.txt) that can be used specifically to identify what services are used or have been used in a given account. Often the hardest place to start for attackers is with determining the footprint of a given cloud environment…and AWS resources-based policy validation is here to help. The use of the following AWS services should be identifiable by the configuration of their associated “service-linked” role:

  • CloudTrail

Author’s Note: While limited testing has been performed without incurring costs, the author takes no responsibility for costs incurred by running the tool.

Leave a Comment

Your email address will not be published.