Skip to content

Article by Nick Frichette, Wes Ladd (@righteousgambit), and skdg

Unauthenticated Enumeration of IAM Users and Roles

You can enumerate AWS Account IDs, Root User account e-mail addresses, IAM roles, IAM users, and gain insights to enabled AWS and third-party services by abusing Resource-Based Policies, even in accounts for which you have no access. Quiet Riot offers a scalable method for enumerating each of these items with configurable wordlists per item type. Furthermore - it also allows you to enumerate Azure Active Directory and Google Workspace valid email addresses - which can then be used to test for valid Root User accounts in AWS, assuming that the email address is the same.

Ultimately, if you want to perform these techniques at scale - Quiet Riot is your best bet, but if you want to do it manually, you can a number of ways to do so. Another way to enumerate IAM principals would be to use S3 Bucket Policies. Take the following example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Example permissions",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::123456789123:role/role_name"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::*bucket you own*"
        }
    ]
}

You would apply this policy to a bucket you own. By specifying a principal in the target account (123456789123), you can determine if that principals exists. If setting the bucket policy succeeds you know the role exists. If it fails you know the role does not.

There are a few ways to do this, for example, Pacu's module will attempt to change the AssumeRole policy of a role in your account and specify a role in another account. If the role exists, the policy will be updated and no error will be returned. If the role does not exist, the policy will not be updated and instead return an error.

Warning

Doing either of these techniques will generate a lot of CloudTrail events, specifically UpdateAssumeRolePolicy or PutBucketPolicy in your account. If your intention is to be stealthy it is not advised (or required) to use a target's credentials. Instead you should use your own account (the CloudTrail events will be generated there).

Note

While this works for both IAM users and roles, this will also work with service-linked roles. This will allow you to enumerate various services the account uses, such as GuardDuty or Organizations.

Another method uses the AWS Console. Based on error responses from the AWS Console it is possible to determine if a given email address belongs to the root user of an AWS account.

From the AWS Console, ensure the Root user radio button is selected and enter an email address that you suspect owns an AWS account.

If that email address is valid, you will be prompted to enter a password. If that email address is invalid, you will receive an error message:

There was an error - An AWS account with that sign-in information does not exist. Try again or create a new account.