Addressing Data Exfiltration: Token Theft Talk

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 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, MFA (and moving towards phishing-resistant credentials), 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:

 

• Renewable artifacts, also known as sign-in session artifacts, maintain single sign-on (SSO) and app state between the client and Entra ID.
• Non-renewable artifacts, also known as 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.

 

Apps 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 Conditional Access (RBCA) to ensure your users have the proper policy controls applied when token theft is suspected. When RBCA 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 RBCA to block resource access with tainted artifacts. When user risk increases, CAE issues signals to all CAE-capable workloads to enforce RBCA policy immediately.

 

Pictures speak a thousand words – this infographic illustrates how different technologies work together to address token theft.

 

 

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: