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:
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:
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:
Adversary acquires a sufficiently privileged, long-term AWS credential
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.
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.
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
EC2 instance profiles enumerating S3 buckets or Lambda functions shortly after performing basic IAM reconnaissance
IAM user sessions :
IAM user accounts creating unusual numbers of session tokens
EC2 Instance profiles :
EC2 instance profiles interacting with the IAM service
IAM user sessions :
The use of a session token to update the principal’s long lived access keys
EC2 Instance profiles :
EC2 instance profiles attempting to create/modify several distinct resources in a short time period
IAM user sessions :
IAM users assuming several distinct roles in a short time period
Responding to a compromised identity
After identifying an unauthorized login or data exfiltration from AWS, there are a handful of actions defenders can and should take to respond accordingly. The following list offers a high-level description of relevant response actions:
Delete/rotate long-term IAM user access keys (AKIA keys)
Attach an explicit “Deny-All” IAM policy to the IAM users (AKIA keys) involved in suspicious activity
Delete any resources created by adversary
Iterate through all CloudTrail log data to identify active short-term (ASIA) tokens impacting production assets.
Note: this image was taken from an existing presentation on cloud incident response. The guidance remains relevant, but we mostly discussed sessions created by GetSessionToken in this blog and not AssumeRole.
AWS STS is a critical security control for limiting the use of static credentials and the duration of access for users across their cloud infrastructure. However, under certain IAM configurations that are common across many organizations, adversaries can also create and abuse these STS tokens to access cloud resources and perform malicious actions.
It’s critical that security teams understand how adversaries abuse these short-term tokens, have visibility into them, and understand how to detect and respond to threats that abuse them accordingly.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.