Most unauthenticated recon within AWS isn't technically unauthenticated, because there are credentials that are required. The difference is that for unauthenticated recon, we use our own attacker AWS keys, so we are unauthenticated to our target environment, and any logs of our enumeration/attempts will show up in our own account only. This is almost as unauthenticated as you can get when enumerating AWS resources, besides something like open S3 buckets, but even then, some kind of credential can help the process due to how permissions are set up in some buckets.

One integral part to most unauthenticated/cross-account attacks is the knowledge of the target AWS account ID. The account ID allows us to associate resources with that specific account from our own. This means that our first API call to AWS will actually be from the CompromisedUser and not our PersonalUser. The reason for this is because we don't have the account ID yet, and we need it. Luckily, there has been research done to gain information about a set of keys without logging anything to CloudTrail, like we covered in Chapter 15, Pentesting CloudTrail .

We'll be using the iam__detect_honeytokens module to gather the information that we require:

1. As the CompromisedUser, we will run the Pacu command, run iam__detect_honeytokens. The reason for this is because the module uses an AWS API call that is not logged to CloudTrail to enumerate the current user's ARN, which contains the account ID, we will have gathered the account ID without them being aware. The following screenshot shows the output when running that module in our test environment:

We can see that our CompromisedUser has the username CompromisedUser and it resides in account ID 216825089941. We could run the whoami command now to see that this information was added to the Pacu database if we wanted to do so. Now that we have the account ID, we can get started with out unauthenticated recon. This unauthenticated portion will involve enumerating IAM users and roles in the account and potentially S3 buckets associated with the company or account.

2. We'll kick that off by first noting the account ID we just enumerated, then swapping keys to the PersonalUser in Pacu by running the swap_keys command.

3. As the PersonalUser, we will then run the iam__enum_users module to try and detect any users in the target account. We'll pass the account ID we just got to this module so that it knows where to look for users. We will also pass Test as the value for the --role-name argument, because we have a role in our personal account named Test and it is required for the UpdateAssumeRolePolicy API call. The final command will end up being run iam__enum_users --role-name Test --account-id 216825089941. Many logs will be created in your own account's CloudTrail, but not the target's account. The following screenshot shows the execution of that comment, where we can see that three separate IAM users were discovered:

4. Next, we are going to want to do the same thing with the iam__enum_roles module by running the following command: run iam__enum_roles --role-name Test --account-id 216825089941. The following screenshot shows the execution of that module, where we can see that four IAM roles were enumerated:

Now, let's look at the user and role names that we enumerated. We found three users:

• Test
• ExampleUser
• LambdaReadOnlyTest

Test and ExampleUser aren't all that helpful in our recon, but LambdaReadOnlyTest indicates that our target is probably using the Lambda service in their account.

We also found four roles:

• MyOwnRole
• LambdaEC2FullAccess
• CloudFormationAdmin
• SSM

These role names are much more helpful that the users we enumerated. MyOwnRole is kind of useless, but LambdaEC2FullAccess indicates that Lambda is in use in their environment, just like we deduced from that one user, but this role name also indicates two more potential possibilities:

• There may be Lambda functions that are launched into VPCs, giving them internal access to that network
• There may be Lambdas that directly interact with the EC2 service, meaning that our target also probably uses the EC2 service within their environment

The CloudFormationAdmin role indicates that CloudFormation is likely utilized within the environment, so we will want to keep that in mind as we begin our attack. It may be able to help us gather more information about the target environment with a small amount of API calls.

The SSM role indicates that this role was created for the systems manager. We can assume that this means they are using the systems manager in their environment to remotely control/manage EC2 instances or on-premise servers.

Now, without creating any logs in the target account, we have enumerated multiple users and roles that exist, as well as gathered a reasonable amount of information on how their infrastructure might be set up across different AWS services.

The last part of our unauthenticated reconnaissance will be to look at S3 buckets with the Pacu s3__bucket_finder module. Hypothetically, we will assume our target Acme Co. owns the domain acme.com, so we will pass that to this module to look for existing buckets. We can do this with the following command:

run s3__bucket_finder -d acme.com

The output should show us if there are any buckets that were discovered and then if any of those buckets were listable. Unfortunately, our scan did not provide any actionable results, as can be seen in the following screenshot:

As you can see from the preceding screenshot, the module has external dependencies. Currently, this is the only module that utilizes the install_dependencies function and it does so to Git clone Sublist3r for sub-domain mutations and Buckets.txt for bucket bruteforcing. Because we only used the -d argument, neither of those external dependencies were utilized.

Now, we have done what we can from outside of our target account. It is time to grab the CompromisedUser credentials and start the authenticated phase of our two-part reconnaissance.