This post is about how to find, and record a list of, all of the AWS accounts at your company. If you want to inventory the resources within the accounts, look at CloudMapper’s collect functionality.

Once a company decides to begin securing their cloud infrastructure, a first step is asset inventory, where they try to identify all of the AWS accounts in use at the company. Standing things up in the cloud is easy, so your company may have more accounts than you expect.

Create a spreadsheet

Begin by making an inventory list of the accounts you know about. This should include:

• Account name: This is the name people refer to this account as, such as “prod” or “dev”. If it isn’t already, you’ll want to prefix the names of your accounts with the business units or some other technique to differentiate the multiple “prod” accounts you might have for different product lines.<p> You should also check the alias used to log into the account as an IAM user. Information about AWS account alias’s can be found here. To find out the alias used by an account, run aws iam list-account-aliases (despite the pluralized name of this command, an account can only have one alias).
• Account ID: The 12-digit account number.
• Root email address: This is the address that AWS contacts with problems about the account, and that is used to login as the root user to the account.
• Description: The purpose of the account, such as “Hosts Contoso.com”
• Business unit/POC: This is group at the company that is responsible for this account along with a point of contact or group email alias that can be contacted.
• Payer: It’s good to know who is paying for this, as this might help give you traction in implementing changes if you can convince the payer for why you want changes made to this account.

Compliance statuses

Once you develop your cloud security strategy with a set of baseline requirements for AWS accounts, you’ll want to keep track of the progress for each account with complying with that policy. This will be things like having CloudTrail turned on and sending logs to a central S3 bucket, having SSO support, having no IAM users, grants read-only access to a compliance checking scanner, etc. You’ll want to add columns for those or possibly create a separate list to keep track of those items.

Example

Here’s a sample inventory list:

Finding your AWS accounts

After you’ve compiled a list of accounts that you know about, perform the following:

• Ask your TAM: If you have a support contract with AWS, ask you Technical Account Manager about what all of the AWS accounts are that use your company domain name as the root email address.
• Search company emails: You may have the ability to search all of the company emails for emails from AWS when an account was setup. There may be laws or company culture that restricts you from doing this. If you can do this, the emails you are looking for will have the subject “Welcome to Amazon Web Services” and be from “no-reply-aws@amazon.com”. The email body includes “Welcome to Amazon Web Services, Thank you for creating an Amazon Web Services (AWS) account.”
• Search network logs: If you have network or DNS logs at your company, you can identify employees that visit https://console.aws.amazon.com and check if they belong to groups that you knew were using AWS.
• Ask your finance team: Find all of the people at the company that are paying AWS.
• Ask around: Ask your developers and devops team about what accounts they have and are using for business purposes. They might have set up development accounts with their personal emails and are only using the free tier, so these might not be discovered by other methods.

Identify trust relationships of accounts

Once you get access to the accounts, run CloudMapper’s collect commands to get the metadata for the accounts, and then run the wot command (described here). This will identify all of the trust relationships between your accounts, and in doing so, it will also find “unknown” accounts that haven’t been recorded in your config.yaml file. These trust relationships will be things like IAM roles that can be assumed from other AWS accounts or S3 buckets that grant access to other account to read or write to them.

In addition to your own accounts, this will find vendors that have access to your accounts. Create a list of those vendors and their AWS account IDs.

The wot command will find most of these trust relationships, but additionally run the following against the account-data directory to ensure any ARN with a 12-digit ID in it has been found in the different resource policies.

grep -hoE ":\d{12}:" -r * | sort | uniq -c

Perform recon

Bug bounty hunters are really good at discovering the assets of a company. Look at the techniques they use. Jason Haddix explains this well in his talk Bug Bounty Hunter Methodology v3 starting at 10:51.

You’ll have some advantage because you can likely get a list of actual domains and subdomains in use at your company. With this list, if you don’t already know these domains are being hosted on services on AWS, find the IP that is hosting them and compare this with https://ip-ranges.amazonaws.com/ip-ranges.json to see if it is hosted on AWS.

Do this for any acquired companies you have. Do some Google searches for common text on your domains, such as “Copyright Contoso 2018” that may appear in the footer of sites.

Next steps

Now that you know what AWS accounts you have, you’ll want to start inventorying more things. This can include:

• Vendors that are connected to your AWS accounts.
• Trusted IP addresses in your Security Groups. Use CloudMapper’s sg_ips command (explained here) to find these.
• The resource and services used by your accounts. Use CloudMapper’s stats command (explained here) to help you identify these.

You’ll also want to understand the data classifications of the AWS accounts, which will help you set priorities and requirements. Some accounts may just be for testing and contain no business data, so you may wish to either ignore these accounts or get the people using them to use other, more official, test accounts.

Set a quarterly task to true-up these inventories, meaning to perform those steps again to ensure the information remains accurate.