STS Credentials Lab

• how to create an IAM User
• how to create long-term access keys
• how to export long-term access keys as shell environment variables
• how to validate the identity that is currently active
• how to assume a new role using the aws sts assume-role command
• how to export temporary session credentials as shell environment variables

Select the Cloud details button at the top of the room:

Where needed generate the environment required for the room. The "Generate Environment" button will appear if the room contains an environment that needs to be generated. 

For any issues with the environment, select the "Reset Environment" button. Review this article for more information.

To view the credentials required for the environment, select the credentials tab. You can use these credentials to access the environment in various ways. More information can be found here:

We will start by creating the IAM user "padawan". IAM Users are the easiest way to grant access to a system outside of your cloud environment. 

Run these commands in your CloudShell:

           [cloudshell-user@ip-10-1-94-78 ~]$ aws iam create-user --user-name padawan
{
    "User": {
        "Path": "/",
        "UserName": "padawan",
        "UserId": "AIDAZOHYLBQBMPAQSXF3G",
        "Arn": "arn:aws:iam::123456789012:user/padawan",
        "CreateDate": "2021-10-30T22:48:36+00:00"
    }
}
        

aws iam add-user-to-group --user-name padawan --group-name padawans

Having created the identity and granted permissions (by adding the user to the group) you have configured authorization for this user. In this task we configure the ability to authenticate to the AWS APIs.

To use the Padawan user on the AttackBox, you'll need to generate an access key like so:

           [cloudshell-user@ip-10-1-94-78 ~]$ aws iam create-access-key --user-name padawan
{
    "AccessKey": {
        "UserName": "padawan",
        "AccessKeyId": "AKIAZOEXAMPLE",
        "Status": "Active",
        "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "CreateDate": "2021-10-30T22:48:53+00:00"
    }
}
        

Using the information above, go to your AttackBox and issue these two commands:

export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export AWS_ACCESS_KEY_ID=AKIAZOEXAMPLE

Like running aws configure, setting these environment variables tells the AWS CLI what credentials to use. Next we will verify you're using the right set of credentials.

The aws sts get-caller-identity command (opens in new tab) is the AWS equivalent of the Unix command whoami. You should use it regularly to make sure you know which account and user/role you're working with.

           user@machine$ aws sts get-caller-identity
{
    "UserId": "AIDAZOHYLBQBMPAQSXF3G",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/padawan"
}
        

Now that you've used long-term access keys from an IAM User, we are going to generate short-term keys for an IAM Role. In many attack scenarios, you'll be leveraging these short term credentials, so it's important to understand the basics of these role credentials.

The next step is to assume the role (opens in new tab) of Jedi Master.

To do this, you'll need three things:

1. Permission to assume the "jedi" role. This is provided by the policy attached to the "padawans" IAM Group. Refer to Task 2 where we added the user to the padawans IAM Group.
2. The Amazon Resource Name (ARN) of the Role you want to assume. This will be arn:aws:iam::Account-ID-From-TASK4:role/jedi
3. A Role Session Name - This string will appear in CloudTrail logs and help administrators distinguish who or why a specific role was assumed. For this we shall use the name of someone who almost became a Jedi master.

           user@machine$ aws sts assume-role --role-arn arn:aws:iam::Account-ID-From-TASK4:role/jedi --role-session-name Ahsoka
{
    "Credentials": {
        "AccessKeyId": "ASIAZOHYLBQBDEXAMPLE",
        "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "SessionToken": "IQoJb3JpZ2luX2VjEEgaCXVzLWVhc3QtMSJGMEQCIFTdMvEsoMLGygfmP5c9mjfWuUXAtro5oODwxSGgY7ncAiBvamMVsFfdaUDKjjDs/
        ucCGqaydbZYDRy2XqEcigBzBSqbAgjg//////////8BEAAaDDY0OTA2MDg3OTM2MiIM7DMiASHRTnXU+SJrKu8B+bTZr6DmOIKMai10A
        k2cnRQrcpvlfFLKQqhAOkfX6s3BJR0P6l3XNa7Bs3buoajzYlTvyBYw/1Bnn/DQ1yj+TZLsoM29pORwFbcAefaxUZjrXrcZORT97EeVj1ZrDw/
jFwQCS3Su2ETpBCNmbX4yTlNEUX8RWlRlCYRBSLbSa9ZfvGfVqJjG/
        7X8Xvh3R5E3IUjTcn/0pksOavXawxbRciDt0KKw87xFu1nzoAb1uj5u+drO1R1SWZBwgmDbYLGF2QrKMvs8U1NwTcBb0YAhK4JGKeOmL      
LpSNWsUrYXmapSzCwb8gfX9RDg0wF/0ilswpqb3iwY6ngFqjjSgiD+rikPTE9xYNMFdexpJ712iKHcnbjJU7VAnUv93RYZtZycj2yCTO9IwhJa8O484mxIMDg0VBV/
        lU5zkXsoihp0Z9dfFgvoPOOeKkeA5FYuTADK4iSR4YK6pEMenU5j8SeHt8aoR3WdYf3uObs0Zyts0XYx9hxLYXWayRNp7TushFaECg
        nkQRJYulS5DykRHiib5PfP/Xjjcrw==",
        "Expiration": "2021-10-31T00:20:06+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAZOHYLBQBOHPGGIRC2:Ahsoka",
        "Arn": "arn:aws:sts::123456789012:assumed-role/jedi/Ahsoka"
    }
}
        

Now take the output of the assume-role command and set the three AWS CLI environment variables required to use temporary credentials for the Role (rather than the user):

export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export AWS_ACCESS_KEY_ID=ASIAZOHYLBQBDEXAMPLE
export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEEgaCXVzLWVhc3QtMSJGMEQCIFTdMvEsoMLGygfmP5c9mjfWuUXAtro5oODwxSGgY7ncAiBvam
MVsFfdaUDKjjDs/ucCGqaydbZYDRy2XqEcigBzBSqbAgjg//////////8BEAAaDDY0OTA2MDg3OTM2MiIM7DMiASHRTnXU+SJrKu8B+bTZr6DmOIKMa
i10Ak2cnRQrcpvlfFLKQqhAOkfX6s3BJR0P6l3XNa7Bs3buoajzYlTvyBYw/1Bnn/DQ1yj+TZLsoM29pORwFbcAefaxUZjrXrcZORT97EeVj1ZrDw/
jFwQCS3Su2ETpBCNmbX4yTlNEUX8RWlRlCYRBSLbSa9ZfvGfVqJjG/7X8Xvh3R5E3IUjTcn/
0pksOavXawxbRciDt0KKw87xFu1nzoAb1uj5u+drO1R1SWZBwgmDbYLGF2QrKMvs8U1NwTcBb0YAhK4JGKeOmLLpSNWsUrYXmapSzCwb8gfX9RDg0wF/
0ilswpqb3iwY6ngFqjjSgiD+rikPTE9xYNMFdexpJ712iKHcnbjJU7VAnUv93RYZtZycj2yCTO9IwhJa8O484mxIMDg0VBV/lU5zkXsoihp0Z9dfFgv
oPOOeKkeA5FYuTADK4iSR4YK6pEMenU5j8SeHt8aoR3WdYf3uObs0Zyts0XYx9hxLYXWayRNp7TushFaECgnkQRJYulS5DykRHiib5PfP/Xjjcrw==

Now that you've configured the AWS CLI environment with your new credentials, verify you're acting as the Jedi role:

           user@machine$ aws sts get-caller-identity
{
    "UserId": "AROAZOHYLBQBOHPGGIRC2:Ahsoka",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/jedi/Ahsoka"
}