Unauthenticated Enumeration
Unauthenticated AWS Enumeration
Theory
AWS IAM has a powerful but little-known security quirk that enables unauthenticated enumeration of IAM principals in any AWS account. This technique exploits how AWS validates principals specified in resource-based policies. When you attempt to add a principal to a resource-based policy such as an SNS topic policy, S3 bucket policy, or Lambda function policy, AWS validates whether that principal actually exists before accepting the policy change. The validation happens at the IAM service level, and AWS returns different error messages depending on whether the principal is valid or invalid.
This validation mechanism creates an information disclosure vulnerability:
If the principal exists in the target account, AWS accepts the policy change and returns success.
If the principal doesn't exist, AWS rejects the policy change with an error message indicating that the principal is invalid.
By systematically testing different potential principal names, an attacker can enumerate which IAM users, roles, and even root user email addresses exist in a target AWS account, all without ever authenticating to that target account.
The key insight is that you need credentials to your own AWS account to create the resources used for enumeration (like SNS topics or S3 buckets), but you don't need any credentials or permissions in the target account. You create a resource in your account, attempt to modify its resource-based policy to grant access to a principal in the target account, and observe whether AWS accepts or rejects the change.
The technique works for several types of principals including IAM users, IAM roles, and AWS account IDs. Additionally, there's a special case for enumerating root user email addresses using legacy S3 ACLs (Access Control Lists), which allow specifying email addresses that correspond to root users. Since root users have unrestricted administrator access to their AWS accounts, identifying valid root user emails is particularly valuable for social engineering or credential stuffing attacks.
Services Supporting Resource-Based Policies
Multiple AWS services support resource-based policies that can be leveraged for principal enumeration. Each service has slightly different characteristics in terms of API rate limits, error message verbosity, and performance. The most commonly used services for enumeration include SNS topics, which provide fast validation with good API rate limits, SQS queues which work similarly to SNS, Lambda functions which allow testing principal validity through permission grants, S3 buckets which support both modern bucket policies and legacy ACLs for root user enumeration, ECR repositories (both public and private) which provide additional enumeration vectors, and Secrets Manager secrets which can validate principals through resource policies.
Different services have different performance characteristics. SNS typically provides the fastest enumeration because it has relatively high API rate limits and returns clear error messages distinguishing between invalid principals and other types of errors. ECR repositories (especially ECR Public) can be distributed across multiple AWS regions, allowing parallel enumeration that significantly increases throughput. S3 ACLs are required for root user email validation but are inherently slower due to lower rate limits and the deprecated nature of ACLs.
The choice of service also affects stealth. Using less common services like ECR Private or Secrets Manager might generate fewer alerts in security monitoring tools that focus on SNS or S3 activity. Additionally, distributing enumeration across multiple services and regions helps avoid rate limiting and reduces the concentration of suspicious API calls that might trigger automated detection.
Service Role Enumeration for Footprinting
Beyond enumerating human users and custom IAM roles, resource-based policy validation can identify which AWS services are enabled in a target account through service-linked roles. AWS automatically creates service-linked roles with predictable names when certain services are enabled. For example, when you enable GuardDuty, AWS creates a role named AWSServiceRoleForAmazonGuardDuty. When you enable AWS Security Hub, AWS creates AWSServiceRoleForSecurityHub.
By testing for the existence of these predictable service-linked role names, an attacker can footprint which security and operational services are enabled in the target account. This information is invaluable for planning attacks because it reveals the target's security posture. If GuardDuty is enabled, you know that certain malicious activities will trigger automatic alerts. If CloudTrail organization trails are configured, you know that logging is centralized. If AWS Config is running, you know that configuration changes are being tracked and potentially enforced.
Service enumeration is faster than user or role enumeration because the wordlist is much smaller—there are only a few hundred service-linked role names compared to millions of possible usernames. A complete service footprint can typically be obtained in under a minute. Additionally, service-linked roles persist even after a service is disabled in some cases, so their presence doesn't always guarantee active monitoring, but it indicates historical or current security investments.
Common service-linked roles that reveal security posture include AWSServiceRoleForAmazonGuardDuty indicating threat detection, AWSServiceRoleForSecurityHub suggesting compliance monitoring, AWSServiceRoleForAccessAnalyzer showing permission analysis capabilities, AWSServiceRoleForAmazonMacie indicating data classification, AWSServiceRoleForCloudTrail revealing audit logging, AWSServiceRoleForConfig showing configuration tracking, and AWSServiceRoleForTrustedAdvisor indicating best practice monitoring. Each discovered role informs your understanding of the defenses you'll face.
Root User Email Address Enumeration
The AWS root user is the most powerful identity in an AWS account, with unrestricted access to all resources and the ability to perform privileged operations that even administrator IAM users cannot execute. The root user is identified by the email address provided when the AWS account was created. Unlike IAM users and roles which can be enumerated through modern resource-based policies, root user email addresses can only be validated through the legacy S3 ACL mechanism.
S3 ACLs are an older access control mechanism that predates IAM policies. When creating or modifying S3 ACLs, you can specify grantees using canonical user IDs or email addresses. If you specify an email address, AWS checks whether that email corresponds to a root user account. If it does, the ACL modification succeeds. If it doesn't, you receive an error indicating the email is invalid. This validation behavior enables brute-forcing root user emails.
Root user email enumeration is significantly slower than IAM principal enumeration for several reasons. S3 ACL operations have lower rate limits than policy operations, ACLs have been deprecated in favor of bucket policies so AWS may intentionally throttle them, and you can only test one email at a time per S3 bucket. A typical enumeration rate is around 10-50 emails per second, compared to hundreds or thousands per second for SNS-based IAM principal enumeration.
However, the value of identifying a valid root user email is immense. Root users often have weaker security configurations than IAM users, many organizations don't enforce MFA on root users, use predictable passwords, or haven't logged in with the root user in years. If an attacker identifies a valid root user email, they can attempt password resets, phishing campaigns specifically targeting that email, credential stuffing with leaked password databases, or social engineering attacks to gain access. Since the root user has unlimited privileges, compromising it grants complete control over the AWS account.
Attackers typically generate root user email wordlists based on the target organization's domain, common naming patterns like admin@domain.com or aws@domain.com or root@domain.com, employee names discovered through OSINT, and email patterns observed in the organization's public-facing infrastructure. Tools like quiet_riot can automatically generate millions of potential email addresses using common first/last name combinations and test them against target accounts.
Practice
Account ID Discovery
Before enumerating IAM principals, you first need to know the target AWS account ID. Account IDs are 12-digit numbers that uniquely identify every AWS account. Several unauthenticated techniques can reveal account IDs.
If you've discovered an AWS access key through OSINT, code repositories, or other means, you can determine which account it belongs to without authenticating. The sts:GetAccessKeyInfo API call accepts an access key ID and returns the associated account ID.
This API call is unique because it doesn't require any authentication credentials. You can call it anonymously.
It also leaves no CloudTrail log in the target account, making it completely undetectable from the target's perspective. The only requirement is that the access key ID must be valid (20 characters starting with AKIA for permanent keys or ASIA for temporary keys), though the key itself doesn't need to be active.
Public S3 buckets can leak their owner's account ID through various mechanisms including bucket policies, error messages, and server access logs.
Additionally, some S3 error messages reveal account information, and bucket logging configurations might expose canonical user IDs that can be correlated to account IDs.
If you discover an SNS topic ARN through application source code, error messages, or configuration files, the account ID is embedded in the ARN format.
Similarly, ARNs for SQS queues, Lambda functions, and other resources exposed through application interfaces, APIs, or error messages reveal account IDs.
Quiet riot includes an account ID enumeration mode that attempts to validate account IDs through resource-based policy validation.
Account ID brute-forcing is generally impractical due to the 1 trillion possible combinations (000000000000 to 999999999999). However, if you have partial information such as the first 6 digits from an error message or log, you can brute-force the remaining digits in minutes.
Enumerating IAM Users
Once you have a target account ID, you can enumerate which IAM users exist in that account using resource-based policy validation.
Quiet riot automates IAM user enumeration by creating resources in your AWS account and testing whether principals in the target account are valid.
Quiet riot will create SNS topics in your account and attempt to grant permissions to each username@target-account combination. Valid users return success, invalid users return errors. The tool automatically handles rate limiting, multi-threading, and result collection.
To create an username wordlist, you can refers to this page.
You can manually test for valid IAM users by creating an SNS topic in your account and attempting to grant permissions to principals in the target account.
After testing, remove the permission to prepare for the next test:
This manual process becomes tedious quickly, which is why automated tools like quiet_riot are preferred.
Lambda function resource policies provide an alternative validation mechanism with slightly different performance characteristics.
Lambda enumeration is generally slower than SNS but might avoid detection in environments that specifically monitor SNS activity.
Enumerating IAM Roles
IAM role enumeration follows the same resource-based policy validation technique as user enumeration but targets role ARNs instead of user ARNs.
Quiet riot's role enumeration mode tests for valid IAM roles in the target account.
Common role name patterns:
Role enumeration is often more valuable than user enumeration because roles are designed to be assumed, potentially providing attack paths through cross-account access or privilege escalation.
The manual role enumeration process is identical to user enumeration, just targeting role ARNs.
When enumerating roles, pay special attention to roles with cross-account trust policies, as these might be assumable from your account or other accounts you control.
Service Footprinting
Service-linked role enumeration reveals which AWS services are enabled in the target account, providing critical intelligence about the security posture.
Quiet riot includes a dedicated service enumeration scan that tests for all known AWS service-linked roles.
Security services to watch for:
AWSServiceRoleForAmazonGuardDuty - Threat detection service that monitors for malicious activity
AWSServiceRoleForSecurityHub - Centralized security findings aggregation
AWSServiceRoleForAccessAnalyzer - Analyzes resource policies for external access
AWSServiceRoleForAmazonMacie - Data classification and protection
AWSServiceRoleForCloudTrail - Audit logging of API calls
AWSServiceRoleForConfig - Resource configuration tracking and compliance
AWSServiceRoleForTrustedAdvisor - Best practice recommendations
If these security services are enabled, you know the target has invested in monitoring and detection capabilities. This should inform your attack methodology. for example, GuardDuty detects certain types of reconnaissance and credential usage patterns.
You can manually test for specific service roles to footprint individual services.
Note that service-linked roles sometimes persist even after a service is disabled, so their existence indicates historical or current service usage but doesn't guarantee active monitoring.
Root User Email Enumeration
Enumerating root user email addresses uses S3 ACLs instead of modern resource-based policies, resulting in slower but potentially higher-value enumeration.
Quiet riot supports root user email enumeration through its S3 ACL validation mode.
You can manually test root user emails by creating an S3 bucket and attempting to grant ACL permissions using email addresses.
This manual process is very slow due to S3 ACL rate limits. Automated tools are strongly recommended for any significant enumeration effort.
Multi-Account and Multi-Region Enumeration
To maximize enumeration speed and avoid rate limiting, distribute your enumeration across multiple AWS accounts you control and multiple AWS regions.
Quiet riot supports approximately 1,100 API calls per second from a single account using its multi-threaded, multi-service, multi-region architecture. By using 10 accounts, you could theoretically reach 11,000 enumerations per second, allowing you to test millions of potential principals in hours instead of days.
Resources
Last updated