Article by Nick Frichette.

AWS IAM Persistence Methods

After gaining a foothold in an AWS environment, an attacker may attempt to establish persistence. Doing this will allow them to return to the account later on to continue their activities. This article is a collection of such persistence techniques. It's worth noting at the time of writing, that this is a small subset of the world of possibilities available to an attacker, and more techniques will be added over time.

More complex methods that require additional explanation will link to their respective Hacking the Cloud articles.

IAM User Access Keys

Technique seen in the wild
- SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto
- Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor
Required IAM Permission
- iam:CreateAccessKey

AWS IAM users can create pairs of access keys to programmatically interact with the AWS API. These credentials can be used with the AWS CLI and allow those with access to those credentials to perform actions as the associated user.

Access keys created this way are long lived (starting with AKIA), meaning that they do not time out or expire by default. Because of this, creating access keys for a user you'd like to maintain access to can be an incredibly simple and easy form of persistence in an AWS environment.

Tip

Aside from the opportunity to maintain persistence in an AWS environment, iam:CreateAccessKey can also potentially be used for lateral movement to create credentials for other users.

Technique seen in the wild
- Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor
Required IAM Permission
- iam:CreateLoginProfile

AWS IAM users can be configured to access the AWS console with a username and password. An adversary with the iam:CreateLoginProfile permission can create login profiles for other users (specifying the password of their choosing). Through this method an adversary can maintain access to an IAM user by logging into the AWS console and performing operations from there.

IAM Role Assume Role Policy

Required IAM Permission
- iam:UpdateAssumeRolePolicy

In order to assume an IAM role, a role trust policy must be attached to it. This policy specifies the identities that are permitted to assume the role.

An adversary could invoke iam:UpdateAssumeRolePolicy, specifying that their own, attacker-controlled AWS account is permitted to assume the role in the environment. This would allow the adversary to maintain access to that role, and use it when needed.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<attacker_aws_account_id>:role/secret_admin"
  }
}

Tip

For the defensive side; it is a good idea to regularly audit role trust policies that establish trust with AWS accounts outside of your organization. In most cases, this will likely identify SaaS and vendor AWS accounts, however it may turn up something much more nefarious.

EC2 Instance Persistence

EC2 instances which have an IAM role attached to them will have their own instance metadata service (IMDS) available. If an adversary has code execution on the EC2 instance, or is able to abuse server side request forgery in an application running on the host, they can steal IAM credentials from the IMDS.

By maintaining access to an EC2 instance which has a role with the permissions you want, this can be an effective and quiet method to keep access to an AWS environment. No additional API calls are required to use those credentials.

Lambda Persistence

Technique Article
- Lambda Persistence