How Attackers Can Abuse IAM Roles Anywhere for Persistent AWS Access

When AWS introduced IAM Roles Anywhere in July 2022 (AWS Announcement), I made my first contribution to Stratus Red Team. I believed this new configuration option, due to its nature, could clearly allow attackers to gain persistence in AWS. Two years later, I haven’t seen this being exploited in the wild. Still, since I didn’t write about it at the time, I decided to create a small article, similar to the one I wrote a month ago about “Gaining AWS Persistence by Updating a SAML Identity Provider”, but this time focusing on how attackers can gain persistence in AWS by using IAM Roles Anywhere.

If you’d like to hear this blog post in a podcast format, check out the episode here:

Understanding IAM Roles Anywhere

AWS Identity and Access Management (IAM) Roles Anywhere allows you to obtain temporary security credentials in IAM from workloads that run outside AWS. To do this, the external workloads must use X.509 certificates issued by your Certificate Authority (CA). You register the CA with IAM Roles Anywhere as a trust anchor to establish trust between your Public Key Infrastructure (PKI) and IAM Roles Anywhere. This way, your workloads using the certificate can call AWS to assume a role because AWS can verify that the certificate used to obtain the role is signed by a CA it trusts.

Figure 1. AWS AWS Security Blog — IAM Roles Anywhere relationship between different components and resources

Exploiting IAM Roles Anywhere

An attacker with sufficient permissions could exploit IAM Roles Anywhere to gain persistent access to an AWS account. Here’s how the exploitation might happen:

1. Create a Malicious CA and Trust Anchor: The attacker generates their own CA certificate and private key. They then register this CA as a trust anchor in the victim’s AWS account using the CreateTrustAnchor API action.
2. Create or Backdoor an IAM Role: The attacker either creates a new IAM role or modifies an existing one by updating its trust policy to allow assumptions via the malicious trust anchor. This involves using CreateRole or UpdateAssumeRolePolicy.
3. Create a Profile: The attacker creates a profile in IAM Roles Anywhere using the CreateProfile API action. The profile specifies which roles can be assumed using the trust anchor.
4. Obtain Temporary Credentials: With the trust anchor and profile in place, the attacker uses their malicious CA to sign a client certificate. They then use the aws_signing_helper utility to obtain temporary AWS credentials, effectively gaining persistent access to the account.

The following script automates these steps, demonstrating how an attacker could set up IAM Roles Anywhere for persistence easily:

• GitHub: setup_roles_anywhere.sh

Figure 2. Example of script that automates IAM Roles Anywhere configuration

Also, you can simulate the events with Stratus Red Team:

• Stratus Red Team: AWS IAM Roles Anywhere Persistence

Detection and Prevention

It would be beneficial if this access appeared in Access Analyzer as external access, but it seems that is not the case, Access Analyzer does not consider Roles Anywhere as external access. To safeguard against this technique, consider the following:

• Monitor CloudTrail Logs: Set up alerts for CreateProfile and CreateTrustAnchor events. Since adding new trusts and profiles is probably not a frequent operation, any occurrence should be investigated. Additionally UpdateProfile and UpdateTrustAnchor might be suspicious if you are already using this feature.
• Restrict Permissions: Limit who can perform:rolesanywhere:CreateTrustAnchor , rolesanywhere:UpdateTrustAnchor , rolesanywhere:CreateProfile , rolesanywhere:UpdateProfile

If you want to read more about post-exploitation techniques in AWS, I’ve also written these articles:

• Gaining AWS Persistence by Updating a SAML Identity Provider: How permissions to UpdateSAMLProvider can allow attackers to gain persistence. Read more
• Manipulating AWS ALB to Mine Sensitive Data: How access to an ALB configuration might allow bypassing authentication or injecting JavaScript. Read more
• Backdooring AWS AppSync: How access to AppSync might allow backdooring the API and stealing information. Read more
• Misusing AWS CloudFront: How access to CloudFront might allow injecting malicious JavaScript via CloudFront Functions. Read more