Now that we have created a user and access keys and understand how IAM policies work, it is time to put them to work to make some AWS API calls:

1. First, let's get the AWS command-line interface (CLI) installed. The easiest way to do so (if you have Python and pip installed on your computer) is to run the following pip command:

pip install awscli --upgrade --user

2. You can then check to see if the installation was successful by running the following command:

aws --version

3. To add our user credentials to the AWS CLI so that we can make API calls, we can run the following command that stores our credentials under the Test profile (note that profiles allow you to manage multiple different sets of credentials from the command line):

aws configure --profile Test

4. You will be prompted for a few different values, including your access key ID and secret key, which we were presented with after we created our Test user earlier on. Then, you'll be asked for the default region name, and in our example, we will choose the us-west-2 (Oregon) region. Lastly, you will be asked for the default output format. We will choose json as our default format, but there are other available values, such as table. The following screenshot shows us setting up credentials for the Test profile in our newly installed AWS CLI:

Our new profile will now be stored in the AWS CLI credentials file, which is in the following file: ~/.aws/credentials.

5. To update the credentials/settings for that profile, you can run that same command again, and to add in new sets of credentials as you compromise them, you can just change the name of the profile from Test to whatever makes sense for the keys you are adding. Now that we have the AWS CLI installed and our Test profile set up, it is simple to begin using our credentials. One thing to keep in mind is that because we are using AWS CLI profiles, you will need to remember to include the --profile Test argument in all your AWS CLI commands, so that the correct credentials are used to make the API call.

6. A very useful command to start out with is the GetCallerIdentity API provided by the Security Token Service (STS) (https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html). This API call is provided to every single AWS user and role, and it cannot be denied through IAM policies. This allows us to use this API as a method of enumerating some common account information about our keys. Go ahead and run the following command:

aws sts get-caller-identity --profile Test

You should see output like the following screenshot:

The output includes a user ID, account ID, and an ARN of the current user. The user ID is how your user is referenced on the backend of the APIs, and in general, it will not be required by us while making API calls. The account ID is the ID of the account that this user belongs to.

In situations where you have an account ID, there are ways to enumerate what users and roles exist in the account without creating logs in the target account, but this attack is generally not very helpful in a post-exploitation scenario and is more helpful for something like social engineering. The Amazon Resource Name (ARN) of the current user includes the account ID and the user name.

All other API calls that we make with the AWS CLI will be run in a similar fashion, and most AWS services are supported in the AWS CLI. A small trick to list out services you can target and how to reference them is to run the following command:

aws a

Basically, this command tries to target the a service, but because that is not a real service, the AWS CLI will print out all the available services, as you can see in the following screenshot:

This same trick can be used to list what APIs are available for each service. Let's suppose that we know we want to target the EC2 service, but we don't know the name of the command we want to run. We can run the following command:

aws ec2 a

This will try to run the a EC2 API call, which doesn't exist, so the AWS CLI will print out all valid API calls that you can choose from, as you can see in the following screenshot:

For more information on an AWS service or API call, such as a description, limitations, and the supported arguments, we can use the help command. For an AWS service, you can use the following command:

aws ec2 help

And for a specific API call, you can use the following command:

aws ec2 describe-instances help

To finish off this section, let's utilize the AmazonEC2FullAccess policy that we attached to our user earlier on:

1. If we want to list all the instances in the default region (we chose us-west-2 earlier), we can run the following command:

aws ec2 describe-instances --profile Test

If you don't have any EC2 instances running in your account, you will likely see output like what is shown in the following screenshot:

2. Without specifying a region, that will automatically target the us-west-2 region, because we input that as our default when we set up our credentials. This can be done manually per API call by using the --region argument, like in the following command:

aws ec2 describe-instances --region us-east-1 --profile Test

Our test account has an EC2 instance running in us-east-1, so the output will be different this time. It will look like the following screenshot:

The data will be returned in a JSON format, because that is what we specified as our default when setting up our credentials. It will include lots of information relevant to the EC2 instances that it found in the region and the account you targeted, such as the instance ID, the size of the instance, what image was used to launch the instance, the networking information, and much more.

Various parts of this information can be gathered and reused in subsequent requests. An example of this would be noting what EC2 security groups are attached to each instance. You are provided with the name of the security group and the ID, which could then be used in a request that tried to describe the firewall rules that are applied to those groups.

3. In the results of our ec2:DescribeInstances call, we can see that the sg-0fc793688cb3d6050 security group is attached to our instance. We can pull information about this security group by feeding that ID into the ec2:DescribeSecurityGroups API call, like in the following command:

aws ec2 describe-security-groups --group-ids sg-0fc793688cb3d6050 --region us-east-1 --profile Test

Now, we are presented with the inbound and outbound firewall rules that are applied to the instance that we described previously. The following screenshot shows the command and some of the inbound traffic rules applied to our instance:

We can see that under the IpPermissions key, inbound access to port 22 from any IP address (0.0.0.0/0) is allowed. Not shown in the screenshot is the IpPermissionsEgress key that specifies the rules for outbound traffic from the EC2 instance.