Back 
In this blog, we are going to discuss an attack vector that utilizes the STS AssumeRole and GetSessionToken API calls, and focus on what you have to do differently to detect, mitigate, and prevent abuse vs handling permanent access keys.
Imagine This
An attacker has just compromised one of your AWS credentials and gained access to your production AWS account. What do you do next? Revoke the credentials, of course. But just revoking the compromised credentials is not enough to keep the attacker out of your environment. In this blog post, we’ll explore temporary tokens and how they can provide an attacker continued access to your AWS environments, even after you have revoked compromised credentials.
Temporary tokens are provided by AWS Secure Token Service (STS) and are similar to permanent access keys in functionality and have been used to implement several common AWS features such as:
- Assuming roles, including the passing of roles to services
- Federated identities (e.g., single sign-on and cross-account access)
- Authentication of IoT devices
As with all security design, there are tradeoffs and security concerns from the use of temporary tokens:
- Temporary tokens can cause confusion during incident handling/response versus permanent access keys because their creation and use is logged in CloudTrail using different, somewhat confusing fields and values. As an example, there is no explicit json attribute that distinguishes a temporary token from a permanent API access key–you must infer from the access key id naming convention or other fields.
- The remediation options for Temporary Tokens can have with high impact; e.g., deletion of users
- Temporary tokens are harder to lock down since the creation of some types of temporary tokens cannot be restricted by policy.
- There is no tracking of which tokens have already been created, so auditing temporary token usage and identifying temporary tokens is difficult, as they must be derived from parsing CloudTrail logs. Further, there are no direct management functions (such as deletion) for temporary tokens. We’ll discuss in detail what mitigation steps apply later in the blog. This also makes it more difficult to assess exposure from credential risk because there is no easy way to list all temporary credentials that have been issued or are active/outstanding.
Temporary Tokens
Temporary tokens are implicitly created by AWS in the case of IoT device authentication or from assuming of roles by services. Temporary tokens can also be explicitly created by authenticated users calling STS AssumeRole or GetSessionToken, e.g.,
In addition to the access key id and secret, a temporary credential includes an expiration date and a session token, which must be included in any API calls (along with the access key and secret).
Temporary tokens essentially have the same functionality and similar security exposure as permanent access keys, but with a few differences:
- Expiration: Temporary tokens have an expiration, ranging from 15 minutes to 36 hours. This is good from a security viewpoint, as it reduces the time window for abuse in case of lost or stolen temporary tokens.
- API Access: T