How abuse and manipulation of access tokens leads to compromise

With the increase in the number of online accounts each individual uses, many online services now provide a “Sign in with…” option for users to use credentials from other identity providers to reduce the number of credentials and simplify the login process.

Similarly, corporate environments are increasingly using Single Sign-On (SSO) to limit the amount of credentials employees have to manage to access various corporate resources.

SSO and “Sign in with” technologies (in addition to other forms of online authentication), rely on popular frameworks such as OAuth 2.0 and OpenID Connect to standardise online authentication. The backbone of these frameworks are access tokens.

OAuth Token Flow Chart

Source: https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/

What are Access Tokens?

In basic terms, access tokens are code fragments that contain data about the user, permissions, groups and timeframes that are passed from an authentication server to a user’s device once credentials are verified. The general workflow of an access token is as follows;

1. A user enters a known username and password to prove their identity.
2. The authentication server receives these credentials and issues an access token once verified.
3. The token is sent to the user’s browser or device to store the token.
4. Every time the user requests access to new data from the application, the token is verified again.
5. When the session is over (meaning the user logs out), the access token is discarded.

Different identity providers have different types of access tokens with varying levels of information based on the type of access requested.

For example, Facebook offers 5 types of access tokens.

As a result, applications that use “Sign in with” or SSO for authentication use access tokens to access the application programming interfaces (API)’s of external identity providers, such as Google and Microsoft. This allows the user to use their existing credentials from the external identity provider, rather than having to create a new set of credentials.

What happens when Access Tokens are compromised?

Access tokens are required to flow through the public internet so that authentication between a user and a web application can be completed. As a result, vulnerable access tokens can be targeted in Adversary-in-the-middle (AiTM) attacks where a malicious actor can intercept access tokens rather than credentials.

AiTM attack flow chart

Source: https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/

Who is vulnerable to an access token compromise?

Basically, anyone who uses online services.

The difficulty with an access token compromise is that it bypasses traditional cybersecurity measures such as strong passwords or passphrases and MFA. The security of access tokens is in the hands of app developers and identity providers which mean they can be harvested, forged and abused by the exploitation of software vulnerabilities, poor secure design principles and weak encryption. Once access tokens are intercepted, a malicious actor basically has initial access into a system can cause a wide range of attacks such as:

• business email compromise
• misdirection of funds
• malware execution
• data exfiltration
• espionage and information gathering.

Microsoft’s big blunder

Microsoft is currently reeling from a major attack from a Chinese hacking group named “Storm-0558”. Threat actors gained access to the Microsoft Account (MSA) consumer signing key allowing them to forge access tokens for Azure Active Directory (now known as Entra ID) and Exchange Online.

Due to a race condition vulnerability, signing keys were exposed in a crash dump that was leaked to the Microsoft internal corporate environment. In April 2021, Storm-0558 was able to compromise a Microsoft Engineer’s corporate account (the root cause of this compromise is unknown due to log limitations) and gain access to the leaked crash dump and therefore get access to the signing keys.

Between April and July 2023, Storm-0558 used the signing keys to forge access tokens for Microsoft’s customer environments including US Federal Government departments such as the Department of State and Department of Treasury.

Once access into customer environments was established, Storm-0558 used fairly standard tooling observed in Business Email Compromise (BEC) incidents to exfiltrate mailboxes and data held in other Microsoft services such as SharePoint, OneDrive and Teams.

The ramifications of this attack are enormous as Microsoft’s Entra ID and Exchange Online are one of the largest cloud identity and email providers used across all industries. Microsoft services hold immense amounts of sensitive data which is now in the hands of malicious actors. This affects any individual, small business or corporate enterprise that uses Microsoft’s online services.

Furthermore, Storm-0558 has targeted US and European government agencies which increases the risk of geopolitical tensions, espionage and information gathering by adversaries.

Microsoft’s Blog Post: Analysis of Storm-0558 techniques for unauthorized email access

How to protect against token compromise?

While the benefit of the migration to cloud services means less workload on users and IT teams, there is less visibility into backend operations and logging, unless of course you pay for it.

For a compromise to personal or individual accounts there is little to no accountability for large identity providers to provide logging or any insight into how the compromise occurred.

Business and enterprise customers are also at the behest of how valuable, readable and useful logging is from enterprise applications and identity platforms. Many applications and platforms require higher tier subscriptions for longer log retention and more extensive logging, making it harder to respond to incidents involving token compromise.

Due to log retention limitations from their own platform, Microsoft was unable to identify how their engineer’s account was compromised in the first place during the Storm-0558 attack. Following this attack, Microsoft increased log retention from 90 days to 180 days for their lower tier customers and announced deeper log visibility that is turned on by default.

Regulators and governments are also increasing scrutiny on large tech companies like Microsoft regarding the importance of logging for online services. Eric Goldstien, the Executive Assistant for Cybersecurity at the US Government’s cybersecurity agency, CISA, stated:

“While vendors can offer wider logging access at specific cloud licensing levels, this approach makes it harder to investigate intrusions. Asking organizations to pay more for necessary logging is a recipe for inadequate visibility into investigating cybersecurity incidents and may allow adversaries to have dangerous levels of success in targeting American organizations”.

Further reading:

• Results of Major Technical Investigations for Storm-0558 Key Acquisition
• Chinese hackers forged authentication tokens to breach government emails
• Thanks Storm-0558! Microsoft to expand default access to cloud logs
• Expanding audit logging and retention within Microsoft Purview for increased security visibility
• What DFIR experts need to know about the current state of the Unified Audit Log
• Weaponization of Token Theft – A Red Team Perspective
• Mitre ATT&CK: Steal Application Access Token