IAM Principals

IAM Identities (opens in new tab), sometimes referred to as IAM Principals, provide access to an AWS Account and its resources. These principals typically provide for authentication or validate authentication was performed. Principals are a core concept for Resource Policies that are attached to resources (like an S3 Bucket) and define who is allowed to act on the resource.

This room will explain the multiple types of IAM Principals (opens in new tab) and their significance for attack and defense tactics.

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:

IAM Users (opens in new tab) are the most basic form of an IAM Principal. They represent a person or application. IAM Users exist in a single AWS account, and AWS acts as both the authentication and identity store for IAM Users.

Take a look at the users that exist in your TryHackMe Account via this AWS Console Link (opens in new tab).

IAM Users can have both a LoginProfile and up to two Access Keys. The LoginProfile is a password that can grant access to the AWS Web Console. Access Keys are AWS generated and consist of a Key ID and Secret.

           Patton:~ chris$ aws iam list-users
{
    "Users": [
        {
            "Path": "/",
            "UserName": "chris",
            "UserId": "AIDAZOHYBCCPYTATBILBQ",
            "Arn": "arn:aws:iam::123456789012:user/chris",
            "CreateDate": "2021-10-25T12:02:11+00:00",
            "PasswordLastUsed": "2021-11-14T13:25:57+00:00"
        }
    ]
}
Patton:~ chris$ aws iam list-access-keys --user-name chris
{
    "AccessKeyMetadata": [
        {
            "UserName": "chris",
            "AccessKeyId": "AKIAZOH4EXAMPLEBQBNT",
            "Status": "Active",
            "CreateDate": "2021-10-26T09:36:17+00:00"
        }
    ]
}
        

IAM Users are the most common way that AWS accounts are compromised, usually due to careless handling of the IAM Access Keys generated. They're often committed to GitHub, stored in config files insecurely, or shared via insecure means.

An IAM Role (opens in new tab) is an AWS Principal intended to be assumed by a person, Service, or Resource. For example, an EC2 Instance might require permissions to S3. With AWS IAM, an EC2 Instance is permitted to assume a specific role that has access to S3. Roles are also used when larger organizations use an external identity provider to access AWS. Roles are also required when AWS itself wants to take action on your account.

Take a look at the roles in your TryHackMe Account via this AWS Console Link (opens in new tab).

IAM Roles have what is known as an AssumeRoleTrust Policy. This trust policy specifies what principals are permitted to assume a role. Click on any of the roles in your account and check out the Trust relationship tab.

In this screenshot, we can see the role can be assumed (via the line Effect: Allow) by the AWS Service "support.amazonaws.com"

You can also see the same information by listing the roles in the AWS CLI:

           Patton:~ chris$ aws iam list-roles
{
    "Roles": [
        {
            "Path": "/aws-service-role/support.amazonaws.com/",
            "RoleName": "AWSServiceRoleForSupport",
            "RoleId": "AROAZOHYLBEXAMPLEREIPZ",
            "Arn": "arn:aws:iam::123456789012:role/aws-service-role/support.amazonaws.com/AWSServiceRoleForSupport",
            "CreateDate": "2021-10-24T23:16:42+00:00",
            "AssumeRolePolicyDocument": {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": {
                            "Service": "support.amazonaws.com"
                        },
                        "Action": "sts:AssumeRole"
                    }
                ]
            },
            "Description": "Enables resource access for AWS to provide billing, administrative and support services",
            "MaxSessionDuration": 3600
        },
        {
            "Path": "/",
            "RoleName": "teacher",
            "RoleId": "AROAZOHYLEXAMPLERC2",
            "Arn": "arn:aws:iam::123456789012:role/teacher",
            "CreateDate": "2021-10-30T23:11:31+00:00",
            "AssumeRolePolicyDocument": {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": {
                            "AWS": "arn:aws:iam::432109876543:root"
                        },
                        "Action": "sts:AssumeRole",
                        "Condition": {}
                    }
                ]
            },
            "Description": "Role to check in on students",
            "MaxSessionDuration": 3600
        }
    ]
}
        

The IAM service API call "AssumeRole" is the operation that leverages this trust policy. We'll discuss how that is used and how you can leverage that in an attack scenario in the room discussing AWS Credentials. 

The Root User (opens in new tab) is a special form of IAM Principal meant to represent the account's owner. Root users have full privileges in the account, subject to any Service Control Policies (which we will discuss later). The username for the root user in AWS is always the email address used to create the account. 

You will rarely encounter the root user in day-to-day AWS development. As a defender, you want to ensure that the root mailboxes for all your AWS accounts are monitored. Amazon will send critical security and operational notices for each account to its root email address. As an attacker, if you have access to the email box for the root user, you can potentially reset the password and take control of the AWS Account! We'll show how the password reset process works in a future room.

Fun Fact: Before 2017, AWS Accounts and Amazon Retail accounts that shared the same email address were linked. This created what is known as the "Underwear Problem," where a startup's AWS account was the same account the founder used to buy underwear. This is important because full access to the account may also be shared if an Amazon retail password is shared amongst people.

AWS recommends you do not use the root user account for day-to-day activities; you should always use an IAM User or Role. The root user is necessary for a few operations which are documented here (opens in new tab). 

It's not possible as an IAM User to identify the root email address of the account you're in. However, if the AWS Account is a member of an AWS organization, you can discover the email address of the Organization's Master Account. Try it with this command:

aws organizations describe-organization

IAM Groups (opens in new tab) are collections of IAM Users. Groups are useful in that you can apply policies to the group, and users in the group would inherit the permissions. Only granting permissions via IAM Groups is considered a best practice in many circles.

You can see the IAM Groups in your account via the AWS Console here. (opens in new tab)

Throughout your TryHackMe AWS journey, your IAM User will be granted the proper permissions for the room you're using. This will be done by adding your IAM User to an IAM Group that matches the room you're in.

           Patton:~ chris$ aws iam list-groups
{
    "Groups": [
        {
            "Path": "/",
            "GroupName": "TeachersPets",
            "GroupId": "AGPAZOHYEXAMPLEHQS5U",
            "Arn": "arn:aws:iam::649060879362:group/TeachersPets",
            "CreateDate": "2021-11-14T13:56:25+00:00"
        }
    ]
}
Patton:~ chris$ aws iam get-group --group-name TeachersPets
{
    "Users": [
        {
            "Path": "/",
            "UserName": "student",
            "UserId": "AIDAZOHYLEXAMPLEDWE7V",
            "Arn": "arn:aws:iam::649060879362:user/student",
            "CreateDate": "2021-10-26T10:00:57+00:00"
        },
        {
            "Path": "/",
            "UserName": "student1",
            "UserId": "AIDAZOHEXAMPLEAQSXF3G",
            "Arn": "arn:aws:iam::649060879362:user/student1",
            "CreateDate": "2021-10-30T22:48:36+00:00"
        }
    ],
    "Group": {
        "Path": "/",
        "GroupName": "TeachersPets",
        "GroupId": "AGPAZOHYEXAMPLEHQS5U",
        "Arn": "arn:aws:iam::649060879362:group/TeachersPets",
        "CreateDate": "2021-11-14T13:56:25+00:00"
    }
}
        

Technically, IAM Groups are not Principals because they are only a grouping of privileges, not an actual authenticated entity.

From an API and IAM perspective, AWS has several services. These services do not always align with how they appear in the AWS Console or the marketing names used. For example, AWS VPC - their software-defined network construct is part of the EC2 namespace. The call to create a VPC is "ec2:CreateVPC" and not "vpc:CreateVPC". Amazon CloudWatch is a combination of several services, including CloudWatch Events (events:*), CloudWatch Metrics (metrics:*), CloudWatch Logs (logs:*), etc. Because of the AWS "two-pizza team" (opens in new tab) organizational structure, there isn't consistency between services around how API calls are named. Some services use "Get*" for describing resources, while others use "Describe*". The AWS Python SDK (boto3) documentation (opens in new tab) is an excellent source for understanding the AWS API service calls.

From the perspective of IAM Principals, AWS Services can act on resources in your account. Often, a Service like Lamdba or EC2 will need to assume a role for your application to access resources. In the context of AWS IAM, services are always in the form of <servicename>.amazonaws.com.

AWS Services are often represented in the Assume Role Trust policies of IAM Roles. 

There is a unique principal "*" which represents Everyone. Depending on the AWS Service, the Everyone principal could mean anyone on the internet or any AWS Customer. The Everyone principal is how resources are made public, either on purpose or by accident. 

The Everyone principal is typically used in AWS Resource policies (which we will discuss in a future room). 

Most companies in AWS have adopted a multi-account strategy. AWS Accounts are created according to application, team, or environment (dev, QA, production). Each employee having multiple IAM Users becomes an untenable situation. Most enterprises leverage a centralized identity store (like Active Directory) and SAML Authentication (opens in new tab) service (ADFS, Okta, etc.) or OpenID to grant employees access to assume a specific IAM Role in specific accounts they are authorized to access.

An Identity Provider is created with a SAML metadata document. Once authenticated by the corporate identity system, a SAML Assertion document is passed to AWS. This assertion lists the AWS accounts and AWS Roles the user is permitted to assume.

With federated access, the authentication system provides multi-factor authentication. 

Federated access requires that one or more IAM Roles trust the SAML Identity Provider created in your account. If you look at the TryHackMe-IAM-Role in your account (direct link (opens in new tab)), you'll see the Trust Relationship is a sample SAML Provider in your account.