Short-term AWS access tokens allow attackers to linger for a longer while

Attackers usually gain access to an organization’s cloud assets by leveraging compromised user access tokens obtained via phishing, by using malware, or by finding them in public code repositories.

These are long-term access tokens associated with an AWS IAM or federated users (i.e, users who have authenticated via a third-party identity platform). They grant users – whether legitimate or malicious ones – specific roles and privileges.

If the permission level is high enough, this compromised user account can create additional IAM users with long-term access tokens.

But, it can also create users that will have short-term access tokens – generated on demand via AWS’s Secure Token Service (STS) and valid for a maximum of 36 hours – and, therefore, time-limited access to cloud assets.

Why would they do that, you may ask. Aren’t long-term access tokens always the better option?

Attackers abuse AWS STS to get more access tokens

“The extra STS tokens effectively serve as insurance in the event that the IAM user token is revoked. Any additional [long-term access] tokens they might have generated sit idle and are only used to restart this process if the initial [long-term access] token and subsequent [short-term access] tokens are discovered and revoked,” Red Canary detection engineers Thomas Gardner and Cody Betsworh explained.

Attackers may abuse AWS STS to get many access tokens. (Source: Red Canary)

“One added benefit of abusing short-term tokens is that it helps conceal the long-term [access] token used to create them, particularly from organizations that aren’t collecting or 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 token used to create them.”

Attackers are thus be able to retain access to the cloud assets for a longer time and use that access to move laterally, escalate privileges, exfiltrate data, etc.

Seek and destroy

Gardner and Betsworh contend that defenders who work with AWS should be familiar with the fact that adversaries abuse AWS’s Secure Token Service, know how this abuse can be detected, and know what to do if they identifying unauthorized logins into AWS.

To detect abuse, defenders should be:

• Logging all event data related to AWS accounts for analysis (via the AWS CloudTrail service)
• Build alerting to detect role chaining events and MFA abuse and build queries to identify chained credentials by token or MFA device
• Have a process in place for account inspection prior to responding to a threat

If they discover unauthorized AWS logins or evidence data exfiltration, the clean-up must involve revoking permissions for all temporary credentials confirmed to be leveraged in the attack, rotating all the long-term access tokens, and setting up a “Deny-All” policy for users whose tokens were involved in suspicious activity.

“Delete any resources created by adversary, and iterate through all CloudTrail log data to identify active short-term tokens impacting production assets,” they added.