By the same token: How adversaries infiltrate AWS cloud accounts

01/05/2024 EDITOR’S NOTE: Thank you to the Amazon Web Services security team for providing valuable feedback on this article, which we’ve updated in several areas to add clarity.

Adversaries have been abusing the cloud for years; they are getting better at it and establishing their own workflows for persistence, defense evasion, initial access, and other tactics. Blue teams must understand how their organizations leverage cloud APIs in order to effectively respond to these advances.

While initial access vectors are pretty consistent from traditional network or endpoint-based intrusions to their cloud-based successors (e.g., malware, phishing for credentials, public repository searches, etc.), adversaries rely heavily on identities and APIs once the’ve gained access to their victim’s cloud environment. Much like living-off-the-land binaries (LOLbins) on a typical workstation, adversaries abuse the very same APIs that legitimate users leverage for everyday work. However, before they can access those APIs, they must authenticate themselves into an authorized AWS account, which is typically accomplished by stealing credentials from a legitimate AWS IAM user or principal (we use these terms interchangeably).

Defenders who work with AWS in particular should be familiar with the Secure Token Service (STS), one of the key AWS services that adversaries abuse to leverage permissions associated with authorized user identities and roles in the cloud. In this blog, we’ll walk through how the STS works, how adversaries can abuse it by leveraging sufficiently privileged IAM user accounts, how you can detect that abuse, and how to respond to a compromised identity.

We’re going to discuss two types of AWS credentials throughout this blog:

• AKIA keys: Long-term access keys associated with an AWS IAM users
• ASIA keys: Short-term session tokens created in response to a valid request via STS

What is STS?

AWS STS is a web service that allows you to provision short-term access to AWS resources. We’ll do a deep dive on benefits and best practices for STS at a later time because it offers many security benefits, but key differences between this and traditional user authentication are:

• STS tokens are fixed to a pre-defined duration of no more than 36-hours (although the default is 12-hours), and once that time period lapses, so too does the access and permissions granted by the token.
• STS tokens are safer than long-term credentials because, even if stolen, they soon expire.

The following diagram illustrates the process for generating STS tokens:

With short-term credentials, you can grant ephemeral access to AWS resources without needing to create corresponding AWS principal or user accounts with long-lived credentials.

How adversaries compromise long-term credentials and generate short-term ones

Compromising long-term IAM keys (AKIA)

Adversaries compromise IAM keys by leveraging a lot of the same techniques used to compromise traditional endpoints or SaaS applications. IAM keys or credentials can be collected via:

• Previously compromised endpoints (e.g., malware infections)
• Public repositories that inadvertently contain credential materials
• Phishing emails seeking to steal AWS principal or user account credentials

Once an adversary has access to a sufficiently privileged long-term IAM key or credential, they can analyze it to determine the privileges that are accessible to it by leveraging APIs like the following:

• GetCallerIdentity
• GetUser
• ListUserPolicies
• ListAttachedUserPolicies
• GetPolicy
• GetPolicyVersion

Depending on the principal’s permission level, adversaries may also be able to use it to create additional IAM users with long-term credentials/AKIA keys to persist in the event that their initial AKIA keys and all of the ASIA short term tokens it generated are discovered and revoked.

Note that administrators can configure user or principal accounts to require that certain actions can only be invoked by an MFA authenticated STS token. Doing so increases the complexity for an adversary, but even so there are numerous ways of stealing or intercepting MFA codes, including phishing and other social engineering attacks.

Creating short-term STS tokens (ASIA)

With a user or principal’s long-term IAM credential in hand, adversaries can then request the creation of STS tokens. They typically leverage the sts:GetSessionToken API call to do this.

From here, if the principal account has sufficient permissions, they can leverage API calls like sts:AssumeRole to conduct role chaining and create multiple new short-term tokens, also for the purpose of persistence if defenders start revoking the newly minted STS tokens.

Abusing short-term tokens

Once the adversary has access to the IAM user account via the AKIA key and their backup ASIA short term tokens (generated via STS), they can begin working on their actual objectives. In this case, we’ll use S3 bucket data exfiltration as our example. The extra STS tokens effectively serve as insurance in the event that the long-term IAM key is revoked (without also revoking the STS tokens it was leveraged to generate). Any additional AKIA keys they might have generated sit idle and are only used to restart this process if the initial AKIA key and subsequent ASIA tokens are discovered and revoked.

To summarize, an intrusion might look something like this:

1. Adversary acquires a sufficiently privileged, long-term AWS credential
2. Adversary generates a second long-term AKIA key. This allows the original compromised key (AKIA key A) to be used to generate short-term ASIA tokens, and the newly created key (AKIA key B) as a backup access key in case AKIA key A is revoked.
3. Adversary leverages ASIA token A to begin exfiltrating data from an S3 bucket, rotating through additional short-term ASIA tokens as needed to complete their final objective.
4. If the adversary observes the AKIA key A being revoked, they can fall back to AKIA key B, creating new ASIA tokens with it via STS. They can repeat this process as needed until they accomplish their goal or are completely evicted from the victim’s cloud environment.

Note: One added benefit of abusing short-term tokens is that it helps conceal the long-term AKIA key used to create them, particularly from organizations that aren’t monitoring the right logs from their AWS infrastructure. As such, organizations may end up playing whack-a-mole with the short-term tokens, deleting them ad hoc, and never identifying the long-term key used to create them. By contrast, if the adversary abused the long-term key, it would be much easier to revoke their long-term IAM access, thereby preventing them from creating new short-term tokens and evicting their access.

The following is an illustrated timeline of how an adversary might abuse the initial AKIA key and subsequent ASIA tokens it leveraged STS to generate.

Detecting and analyzing stolen tokens

The following detection guidance may help you stay one step ahead of adversaries abusing AWS tokens:

• Log and monitor all CloudTrail event data, sending it to a data lake for analysis, custom detection, and additional retention time as needed (AWS stores management events for 90-days by default)
• Define a process for account inspection of cloud threats prior to responding to the threat
• Build alerting to detect role chaining events and MFA abuse
• Build queries/dashboards to identify chained credentials by token or MFA device

Detection engineers can build queries and analytics for many events, including the following: