An IAM role has a document associated with it that is known as its trust policy. The trust policy is a JSON policy document (for example IAM policies such as ReadOnlyAccess or AdministratorAccess) that specifies who/what can assume that role and under what conditions that is allowed or denied. A common trust policy document that allows the AWS EC2 service permission to assume a certain role might look like the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

This policy allows the EC2 service access to assume the role it belongs to. A scenario where this policy might be used is when an IAM role is added to an EC2 instance profile, which is then attached to an EC2 instance. Then, temporary credentials for the attached role are accessible from within the instance and the EC2 service will use it for anything that it needs access to.

Some features of IAM roles that work out very nicely for us attackers are as follows:

• Role trust policies can be updated at will
• Role trust policies can provide access to other AWS accounts

In terms of establishing persistence, this is perfect. That means, generally, that all we need to do is update the trust policy of a privileged role in a target account to create a trust relationship between that role and our own personal attacker AWS account.

In our example scenario, we have two AWS accounts created. One of them (account ID 012345678912) is our own personal attacker account, which means we personally registered this through AWS. The other (account ID 111111111111) is the account that we have compromised keys for. We want to establish cross-account persistence to guarantee our future access to the environment. This means that even after the compromise is detected by a defender, we can still regain access to the environment through cross-account methods, allowing us to maintain access to our target environment without opening any other security holes in the process.