By Rodrigo Montoro

When we think about a chain of attacks, reconnaissance is one of the main phases because based on the information previously discovered, it’s possible to be provided with information to carry out the next phases and moves of the attack.

In the Amazon Web Services (AWS) ecosystem, there aren’t many resources available to map IAM (Identity and Access Management) users and the Root account. Some well-known methods for enumeration without authentication on a target account are implemented in the PACU Framework [1]; among these, the main ones are enumeration of roles and possible IAM users, one of its features.

An already known method to validate whether or not an email has an AWS account, which in practice is the account’s Root user, is via a website to try to create a new user with the email itself, and if it already has an account, it will basically be alerted. The great difficulty of exploring this vector is that this automation process is more complex due to the fact that we have to subvert the CAPTCHA mechanism (Completely Automated Public Turing Test to Tell Computers and Humans Apart), as well as the other controls of the AWS website.

Within some research and consulting work that is being done within Tempest with AWS Organizations, we observed an interesting behavior when someone tries to create a new account via Organizations; if they already had an account, an error is generated with the following result “EMAIL_ALREADY_EXISTS”. Based on this, we researched whether this behavior could be automated and used to enumerate accounts and their respective emails, and to our surprise, we found that it could.

The first point was to analyze the errors that AWS Organizations create an account could return (Figure 1) and enumerate this list to understand the behavior of each error and how we can abuse this. For the purposes of this post, we’ll only use the “EMAIL_ALREADY_EXISTS” error mentioned above.

Figure 1: List of possible errors for creating AWS Organizations

After reviewing the list of possible errors, we simulate the account creation command:

Figure 2: Using the AWS CLI to simulate creating a new Organization

As a result of the command (Figure 2), you can see that a creation ID Status was returned. Since we don’t know the result of this command yet, we can check whether the account was created or some error happened, as illustrated in Figure 3:

Figure 3: Result of the Account Creation Command from a Status ID

As can be seen in the result of Figure 3, this account already has an AWS account, hence the result “EMAIL_ALREADY_EXISTS” as the return. In order to determine if there was any mechanism to mitigate this enumeration process, through returns or similar errors, the same sequence of commands above was executed for an account that doesn’t exist yet, and with this, it was possible to observe that the account was successfully created.

Figure 4: Result of the Account Creation Command for a Non-existent Organization

To make the process easier and to leave the possibility of doing this for multiple accounts, we created a simple bash script to automate the enumeration process. However, it’s recommended that you don’t try to execute it against a large list due to the fact of possible blocking and the fact that this process is not completely “silent”.

Figure 5: Bash Script to automate the process of checking and enumerating root accounts

Figure 6 displays one run of the bash script against a list of possible enumeration targets and their respective output.

Figure 6: Result of running the Bash script enumeration against a given target list

The process presented consists of an active enumeration technique, and with that, an email will be sent for validation and ownership if the email in question doesn’t already have an AWS Organizations account associated. That said, is important to have a more assertive list aiming to decrease the possible “noise” and, in particular, for cases where more stealthy jobs need to be performed. Another point to note is that the Organizations has an account limit, so it will be necessary to remove accounts created in the enumeration process to make room for expanding the search limit. Remember that accounts created via Organizations do not have passwords, so the user will have to reset, log in and delete those passwords.

Finally, this technique won’t generate events in your AWS accounts, so a good way to get the possible email attempt from the Root account is to monitor the ConsoleLogin event with Failure in Response in CloudTrail, as a brute force will probably be the next step after that confirmation. As mentioned, awareness and receiving non-standard email, such as creating an AWS account, can be a means of detection as well, but outside the control plane.

Happy Hacking!


[1] โ€“ RhinoSecurityLabs. PACU, 2021. Available at: Accessed on: August 15, 2021.