MITRE Att&ck View: Securing AWS Temporary Tokens

We have previously blogged about the risk and challenges in Securing AWS Temporary Tokens.

In this blog, we will take a fresh look from the MITRE Att&ck chain viewpoint, in order to highlight new insights and specific cloud techniques used by adversaries, in an effort to help users be more effective in detecting, mitigating, and preventing different but similar attacks.

Recap: Securing AWS Temporary Tokens

Let’s summarize the challenges with temporary tokens and the common mitigation steps, before we contrast this with what we can glean from an Att&ck analysis. 

Here is the original attack scenario:

The key steps are:

1. A permanent Access Key A is compromised
2. Key A is used immediately to generate an extra credential i.e. Temporary Token B (for backdoor purposes and obfuscation)
3. Key A is used to escalate privileges via AssumeRole, which returns Temporary Token C
4. Temporary Token C is then used to access an S3 Bucket
5. Temporary Token C is used to exfiltrate data from the S3 Bucket

When mitigating this scenario, the defender first deleted/inactivated Access Key A, then also had to remember to “revoke” Temporary Token C. Revocation in this case meant using a specific role policy to deny all API calls by Temporary Token C based on its creation time.

However, this did not remove the adversary’s access, as there was still the existing Temporary Token B, which could also be used to escalate privileges and generate more temporary tokens (D) in order to continue access to the S3 Bucket:

To completely mitigate the situation, the Temporary Token D must be “revoked” in the same manner as Temporary Token C (using the role policy based on creation time). However, this mitigation approach doesn’t work for Temporary Token B, which was created not by AssumeRole, but by GetSessionToken. In this case, the only way to mitigate/remove Temporary Token B is to delete the IAM user that “owns” it (i.e. the same IAM user that had the compromised Key A) or to restrict that IAM user’s permissions.

These mitigation steps and their differences can be summarized here:

This table reflects an incident-focus in dealing with temporary tokens. When taking a larger viewpoint, it’d be reasonable to think about a more complete set of preventative, detection, and mitigation measures:

MITRE Att&ck

Let’s now look at the scenario from the Att&ck viewpoint and see what new insights we have. The original attack scenario has been reorganized in more of an attack chain flow along with MITRE references for the tactics/techniques involved:

Notice how this primary attack scenario reflects what a defender might be focused on if they were in the middle of an incident. These would be the primary artifacts seen when tracing back from data exfiltration events to the originating credentials. Role Assumption is a good example of a new technique that isn’t yet in the Privilege Escalation tactic in Att&ck, but is common in cloud attacks. Netskope is working to identify additional techniques such as this, so that defensive measures can be specific and clear.

This Att&ck reorganization is easier to understand and also allows a defender to mine the Att&ck knowledge base for ways to detect and mitigate this attack at each step.

Let’s now look at the secondary attack:

Here, it is more obvious, that Temporary Token B is part of an attempt at Persistence (backdoor access) and possibly Defense Evasion, and it’s clearer how it provides the same access to the S3 Bucket.

Here’s a summary of the tactics and techniques in the atta