Azure AD Conditional Access Token protection (CATP) First Impressions

Token stealing is a severe threat in Office 365 and any cloud environment. Attackers use various technologies and tactics to steal tokens instead of passwords. With those stolen tokens, they will access critical resources and perform malicious activities in the victim environment. So, every organization should have a proper defense methodology and methods to handle token theft. 

To help you with this, Microsoft rolls out the Azure AD Conditional Access Token Protection (aka CATP) to protect your Office 365 resources from malicious attackers who try to compromise your organization’s security. 

In this blog post, we will explore what token protection is and additional perspectives.

What is token protection?

Azure AD Conditional Access Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker can steal a token by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is relatively rare, but its damage can be significant.

Token protection creates a cryptographically secure tie between the token and the device (client secret) it’s issued to. Without the client’s secret, the bound token is useless. When users register a Windows 10 or newer device in Azure AD, their primary identity is bound to the device. This connection means that any issued sign-in token is tied to the device, significantly reducing the chance of theft and replay attacks.

Azure AD Conditional Access Token protection (CATP) is a feature that allows you to control how and when users can access your organization’s resources. One of the ways to enhance the security of your access policies is to use token protection, which binds the sign-in tokens to the devices they are issued to. This way, even if an attacker manages to steal a token, they cannot use it without the device’s secret.

Token protection (sometimes referred to as token binding in the industry) is a mechanism that creates a cryptographically secure tie between the token and the device (client secret) it’s issued to. When users register a Windows 10 or newer device in Azure AD, their primary identity is bound to the device. This connection means that any issued sign-in token is tied to the device, significantly reducing the chance of theft and replay attacks. Without the client’s secret, the bound token is useless.

Token protection is currently in public preview and supports sign-in tokens (refresh tokens) for applications accessing Exchange Online and SharePoint Online on Windows devices. It doesn’t support access tokens or web cookies yet.

Why use Token Protection?

Token protection can help you prevent unauthorized access to your organization’s resources by ensuring that only the intended devices can use the tokens they receive. This can reduce the risk of attacks such as:

– Token hijacking: An attacker intercepts a token during transmission or storage and uses it to impersonate the user.

– Token replay: An attacker reuses a valid token that was previously issued to a different device or application.

– Token phishing: An attacker tricks users into entering their credentials on a fake website and captures the returned token.

Using token protection, you can make these attacks much more complicated and sometimes impossible. The attacker must also obtain the device’s secret, which is not transmitted or stored anywhere.

Once you have created your policy, it will apply to any sign-in attempts from Windows 10 or newer devices using desktop applications that access Exchange Online or SharePoint Online. The users must have their devices registered in Azure AD and use compatible applications such as the OneDrive sync client or Teams native client.

For example, Suppose a user tries to sign in using an incompatible application or device. In that case, they will be blocked from accessing Exchange Online and SharePoint Online until they switch to a compatible one.

Token Protection Thoughts 

CATP works by adding a claim to the access token that indicates the policy applied when the token was issued. This claim is called the Conditional Access Authentication Context Class Reference (CA_ACR), and it contains a unique identifier for the policy. When a token is presented to a resource, the resource can validate the CA_ACR claim and check if the policy is still valid and matches the current conditions of the request. If the policy is invalid or does not match, the resource can reject the token and prompt the user to re-authenticate.

One of the benefits of CATP is that it can reduce the impact of token theft and misuse by attackers. For example, suppose an attacker manages to steal an access token from a user’s device or browser. If the token has a CA_ACR claim that requires device compliance, the attacker will not be able to use the token from their own device, as it will fail the compliance check. Similarly, suppose the token has a CA_ACR claim that requires multi-factor authentication (MFA). In that case, the attacker cannot use the token without providing an additional factor, such as a phone call or a code.

CATP can also help prevent attackers from using stolen tokens to access sensitive resources or perform privileged actions. For example, suppose an administrator has a policy requiring MFA to access Azure resources or perform administrative tasks. Suppose an attacker steals an access token from the administrator’s device or browser. In that case, they will not be able to use it to access Azure resources or perform administrative tasks, as they will be prompted for MFA.

CATP is a powerful feature that can enhance the security of Azure AD and protect against token theft and misuse. However, CATP is not a silver bullet. It does not eliminate the need for other security best practices, such as securing devices and browsers, using strong passwords and MFA, and monitoring suspicious activity. CATP should be part of a comprehensive security strategy covering all identity and access management aspects.

Embrace the RED

Token protection is not foolproof and can be bypassed by attackers. Below are some techniques an attacker can use to circumvent token protection and gain access to cloud resources.

The first technique is to compromise a device already enrolled in Azure AD with a valid token. This can be done by exploiting a vulnerability in the device’s operating system or applications or using phishing or social engineering to trick the user into installing malware. Once the attacker has control of the device, they can use the token to access resources as long as the device remains compliant and the user does not change their password.

The second technique is to spoof a legitimate user’s device state and identity. This can be done using tools such as Mimikatz or Rubeus to extract the device certificate and the user’s credentials from a compromised device or network. Then, the attacker can use these credentials to register a new device in Azure AD and request a token. The token will be issued if the device certificate matches the one stored in Azure AD and the user’s credentials are valid.

The third technique is to exploit a misconfiguration or a weakness in the token protection policy. For example, some administrators may exclude specific applications or IP addresses from token protection, which allows an attacker to use these applications or IP addresses to access resources without validation. Another example is when administrators use legacy authentication protocols such as Basic Authentication or NTLM, which do not support token protection and can be easily compromised.

Adversary-in-the-middle (AitM) frameworks: These are tools that insert malicious infrastructure between the user and the legitimate application they are trying to access. When the user is phished, the malicious infrastructure captures both the credentials and the token of the user.

Pass-the-cookie attacks: These are attacks that involve extracting browser cookies from a compromised device and passing them to another web browser on a different system. This allows the attacker to bypass security checkpoints and access corporate resources.

There are various techniques that attackers can use to manipulate access tokens, including token theft, token modification, and token replay attacks.

Token protection is not a silver bullet to prevent all token theft attacks. You should know some limitations and bypasses as a red teamer or a penetration tester. Attackers will be focused on the limitations to gain access. 

• Token protection only applies to sign-in tokens for desktop applications accessing Exchange Online and SharePoint Online on Windows devices. It does not apply to access tokens or web cookies other applications or platforms use.
• Token protection only works on Windows 10 or newer devices that are Azure AD joined, hybrid Azure AD joined, or Azure AD registered. It does not work on Windows Server, Surface Hub, or other devices not registered in Azure AD.
• Token protection does not prevent an attacker from stealing the sign-in token and the client secret from the same device. If an attacker has access to the device where the sign-in token and the client secret are stored, they can use them to impersonate the user until the sign-in token expires or is revoked.
• Token protection does not prevent attackers from exploiting vulnerabilities in the applications supporting token protection. Suppose an attacker can exploit a vulnerability in the OneDrive sync client, Teams native client, or Office 365 ProPlus client. In that case, they can access Exchange Online or SharePoint Online without needing the sign-in token or the client secret.
• Token protection does not prevent an attacker from using other methods of compromising user accounts or credentials. For example, attackers can still use phishing, password spraying, credential stuffing, keylogging, pass-the-hash, pass-the-ticket, or other techniques to access user accounts or credentials.

More information 

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud

Pass the Cloud with a Cookie

Requirements and Limitations

Below are the prerequisites that require for a Conditional Access Policy with token protection, 

• Windows 10 and higher.
• A device configured with Azure AD joined, hybrid Azure AD joined, or Azure AD registered. 
• OneDrive and Microsoft Teams clients versions: 
  • OneDrive-version 22.217 or later. 
  • Teams client-version 1.6.00.1331 or later. 

• Azure AD B2B (external users) are not supported and shouldn’t be included in your Conditional Access policy.
• The following applications don’t support signing in using protected token flows, and users are blocked when accessing Exchange and SharePoint:
  • Power BI Desktop client
  • PowerShell modules accessing Exchange, SharePoint, or Microsoft Graph scopes
  • PowerQuery extension for Excel
  • Extensions to Visual Studio Code, which access Exchange or SharePoint
  • Visual Studio
• The following Windows client devices aren’t supported:
  • Windows Server
  • Surface Hub

Upcoming releases on the Token Protection roadmap include: 

• More resources and access scenarios. 
• Adding web applications to improve defense-in-depth capabilities for web applications using MSAL.js.   
• Sign-in session token protection to address refresh token theft scenarios on Mac, iOS, Android, and Linux clients. 
• App session token protection, which limits theft and replay of access tokens. 

The first impression is kind of good because it is a start of a new beginning. Once it is available for more applications, it can provide better defense coverage for tokens.

Token protection is currently in preview and supports sign-in tokens for applications accessing Exchange Online and SharePoint Online on Windows 10 or newer devices. To enable token protection, you need to create a Conditional Access policy that requires it for specific services. Token protection can enhance your security posture by reducing the risk of attackers impersonating your users with stolen tokens. However, it also has some limitations and compatibility issues that you should be aware of before deploying it.

What next? The next posts will be:

• Monitor Token Protection and Token theft.
• The ways to Bypass Token protection.