Blog Post

Microsoft Entra Blog
4 MIN READ

Addressing data exfiltration: Token theft talk

annabarh's avatar
annabarh
Icon for Microsoft rankMicrosoft
Jan 02, 2024

Let’s continue our discussion on preventing data exfiltration. In previous blogs, we shared Microsoft’s approach to securing authentication sessions with Continuous Access Evaluation (CAE) and discussed securing cross-tenant access with Tenant Restrictions v2. Today our topic is stolen authentication artifacts.

 

Stolen authentication artifacts – tokens and cookies – can be used to impersonate the victim and gain access to everything the victim had access to. Up until a few years ago, token theft was a rare attack and was most often exercised by corporate Red Teams. Why? Because it’s simpler to steal a password than a cookie. However, with multifactor authentication (MFA) becoming more prevalent, we’re seeing real-life attacks involving artifact theft and replay.

 

Before diving into details, it’s important to note that Microsoft recommends that the first line of defense against token theft is protecting your devices by deploying endpoint protections, device management, phishing-resistant MFA, and antimalware, as described in Token tactics: How to prevent, detect, and respond to cloud token theft | Microsoft Security Blog.

 

Now, let’s discuss types of authentication artifacts and what techniques are recommended for each type to minimize the impact of theft. All authentication artifacts can be roughly divided into two buckets:

 

  • Sign-in session artifacts, maintain single sign-on (SSO) and app state between the client and Entra ID.
  • Apps session artifacts, grant data access to client applications.

 

 

It may be obvious that the first priority would be protecting the most powerful device SSO artifacts - Primary Refresh Tokens (PRT). The good news is that PRTs on all operating system platforms have been hardened against theft from day one. The level of protection depends on operated system capabilities, with Windows offering the strongest protection. PRT protection is not controllable by policy and is always on.

 

Offering similar protection for all artifacts is on our roadmap, but delivering these capabilities is going to be a multi-year journey. If you want to learn more about various challenges of building comprehensive protection against token theft, watch this RSA presentation. In the meantime, you can reduce token theft by carefully orchestrating Entra ID security products.

 

Addressing token theft of sign-in session artifacts

 

Conditional Access: Token protection policy offers cryptographic protection against replay of stolen tokens. This feature leverages and builds on top of already existing cryptographic protections of PRTs. When token protection policy is on, use of unprotected sign-in sessions is blocked. In combination with PRT protection always being on, it extends cryptographic protection to all renewable artifacts. Token protection is in public preview for Office and Outlook on Windows. Start in report-only mode first to evaluate the impact for your organization.

 

Client Applications that are not yet in scope of token protection can be protected by enabling compliant network check for Entra Global Secure Access. This policy will ensure that authentication artifacts always come from your organization’s network. It means that stolen tokens can only be replayed from your organization’s network, thus significantly reducing blast radius of the attack.

 

Addressing token theft of app session artifacts

 

Depending on your network configuration, you might be able block usage of stolen access tokens and workload cookies outside of your corporate network by using Conditional Access: Block access by location and strictly enforce location policies for continuous access evaluation (CAE). This new CAE enforcement mode blocks access from outside allowed IP ranges, thus blocking any usage of stolen tokens from outside your network and significantly reducing blast radius of the attack. To take advantage of this capability, your users must access both Entra ID and workloads from enumerable IP addresses. CAE strictly enforce locations policy can be enforced for corpnet users accessing data via Entra Global Secure Access (GSA) because Entra GSA is able to pass along IP address of user’s device. When configuring Named Locations in Conditional Access (CA), make sure to include range of IP addresses from which your users access both Entra ID and workloads (e.g. SharePoint Online).

 

Detecting token theft

 

To detect stolen artifacts, you can enable risk detections with Microsoft Entra ID Protection to elevate user risk when token theft is suspected. Anomalous token, token issuer anomaly, and adversary in the middle detections can be indicative of token theft. Each detection is calculated offline, whereas anomalous token can also be calculated in real-time at sign-in to catch the threat and flag the sign in as compromised. To take full advantage of these detections, we recommend configuring risk-based access policies to ensure your users have the proper policy controls applied when token theft is suspected. When risk-based access policies are applied against token theft detections, it forces the user to complete multifactor authentication and reset their password, and when applicable, require an admin to revoke user tokens.

 

Continuous Access Evaluation works together with risk-based access policies to block resource access with tainted artifacts. When user risk increases, CAE issues signals to all CAE-capable workloads to enforce risk-based access policy immediately.

 

As token theft attacks are becoming more prevalent Microsoft constantly improves defenses against such attacks. Stay tuned for new updates in this area soon.

 

Anna Barhudarian

Principal Product Manager, Identity Division

 

 

Learn more about Microsoft Entra:

Updated Apr 03, 2024
Version 6.0
  • annabarh Thank you for the great article! I have one question re refresh tokens

     

    According to Microsoft DocumentationWhen a client acquires an access token to access a protected resource, the client also receives a refresh token. The refresh token is used to obtain new access and refresh token pairs when the current access token expires.

    Refresh tokens are also used to acquire extra access tokens for other resources. Refresh tokens are bound to a combination of user and client, but aren't tied to a resource or tenant. A client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."

     

    In this article's above diagram (Yellow Square) it is mentioned that "Refresh Tokens [are] renewable and long-living artifacts to maintain sign-in state for a specific app. Used to acquire other artifacts for that app"

     

    Question is: are refresh tokens bound to specific app or can be used to get access tokens for any app? Is the difference because of how Entra ID treats Refresh Tokens? 

     

    P.S> RSA talk referenced above also compares Refresh Tokens with "season pass" which can be exchanged to token (access token) to any ride (app/resource). 

     

    Thank you in advance!!!!

     

  • Great question! In this blog I used word 'app' as synonymous to 'client' and word 'workload' for service. I updated the blog to clearly distinguish between clients and workloads. Hopefully, it resolves the confusion.