Each IAM user in an account has a limit of two access key pairs. Our test user already has one created, so one more can be created before our limit has been hit. Considering the scenario where the keys we have been using are someone else's and we happened to gain access to them, a simple form of persistence we could use would be to just create a second set of keys for our user. By doing so, we would have two sets of keys for the same user: one that we compromised, and one that we created ourselves.

This is a little too simple, though, because if we were to get detected and someone on the defensive side was to just remove our user, it would delete both of our methods of access to the environment in one go. We can instead target a different privileged user in the environment to create our backdoor keys for.

First, we will want to see what users exist in the account, so we will run the following AWS CLI command:

aws iam list-users --profile Test

This command will return some identifying information about each IAM user in the account. Each one of these users is a possible target for our backdoor keys, but we need to consider users who already have two sets of access keys. If a user already has two sets and someone tries to create a third set, an API error is thrown, which could end up being very noisy to a listening defender, ultimately getting us caught.

I want to target the user Mike, who was one of the users returned from our AWS CLI command. Before trying t7o add access keys to Mike, I will check to make sure that he doesn't already have two sets of access keys with the following command:

aws iam list-access-keys --user-name Mike --profile Test 

The following screenshot shows the output of that command, and that Mike already has two sets of access keys:

This means that we should not target Mike. This is because trying to create another set of keys would fail, resulting in an error from the AWS API. A vigilante defender may be able to correlate that error to your malicious activity, ultimately getting you caught.

There is another user that appeared previously with a user name of Sarah, so let's check how many access keys she has set up:

aws iam list-access-keys --user-name Sarah --profile Test

This time, the results show up as an empty array, which indicates that there are no access keys set up for Sarah:

Now we know we can target Sarah for our persistence, so let's run the following command to create a new pair of keys:

aws iam create-access-key --user-name Sarah --profile Test

The response should look something like the following screenshot:

Now we can use the keys that were returned to access any permission associated with Sarah. Keep in mind that this method can be used for privilege escalation in addition to persistence in a scenario where your initial access user has a low number of privileges, but iam:CreateAccessKey is one of them.

Let's store credentials of Sarah locally with the AWS CLI so we don't need to worry about them in the meantime. To do so, we can run the following command:

aws configure --profile Sarah

Then we can fill in the values that we are prompted for. Similarly, we can add these keys into Pacu with the set_keys command.