Bypassing Entra ID Conditional Access by Forging TPM-Bound Authentication

TLDR: This research reveals how to bypass device-based Conditional Access policies in Microsoft Entra ID by abusing undocumented RPC calls and internal Windows APIs. By interacting with the aadcloudap plugin in lsass.exe, an attacker can sign arbitrary authentication requests and decrypt session keys, effectively forging a compliant device state. This technique allows for full authentication as any user without needing administrative privileges on the target machine.

Conditional Access policies are the bedrock of modern identity security. When an organization mandates that only "compliant" or "hybrid-joined" devices can access cloud resources, they are betting everything on the integrity of the device's identity. This research proves that this bet is often misplaced. By reverse-engineering the internal communication between lsass.exe and the aadcloudap plugin, it is possible to bypass these hardware-backed security controls entirely.

The Mechanics of the Bypass

The core of this issue lies in how Windows handles device authentication. When a device registers with Entra ID, it generates a Device Key and a Transport Key. These keys are typically stored in the Trusted Platform Module (TPM) and are marked as non-exportable. Previous research, such as the work leading to CVE-2021-33781, focused on exporting derived keys to forge tokens. However, this new approach does not require extracting the keys from the TPM.

Instead, the attack leverages the fact that the operating system itself must be able to use these keys to perform authentication. The aadcloudap plugin, which runs within the Local Security Authority Subsystem Service (lsass.exe), is responsible for these operations. By identifying undocumented RPC methods within this plugin, an attacker can instruct the system to perform cryptographic operations on their behalf.

The researcher identified a specific function, SignPayload, which can be invoked to sign arbitrary data using the device's private key. Because the request is coming from a process that the system trusts—or by impersonating the AAD Token Broker service—the TPM performs the signing operation without ever exposing the raw private key to the user space.

Technical Execution

To reproduce this, you need to interact with the aadcloudap plugin. The researcher released a tool called BAADTokenBroker that automates the interaction with these undocumented APIs.

The attack flow follows these steps:

1. Compromise: Gain code execution on a machine that is already joined to the target Entra ID tenant.
2. Impersonation: Impersonate the AppContainer SID associated with the AAD Token Broker. This is critical because the CheckPackageSidForRequestSign function validates the caller's identity.
3. Signing: Use the SignPayload function to sign a crafted logon request.
4. Decryption: Use the NgcDecryptWithSymmetricPopKey function to decrypt the session key returned by Entra ID.
5. Forging: With the signed request and the decrypted session key, you can generate a valid Primary Refresh Token (PRT) or acquire access tokens for any user.

The following command demonstrates how the tool initiates the creation of a PRT:

.\BAADTokenBroker.ps1 -Command Create-PRTCookie -Username user@domain.com -Password 'your-password'

Once you have the PRT, you can import it into your own browser's cookie store. Because the PRT is cryptographically bound to the device identity, Entra ID treats your machine as the legitimate, compliant corporate device.

Real-World Applicability

For a pentester, this is a game-changer. During a standard engagement, you often find yourself on a workstation that is domain-joined but lacks the necessary device compliance to access the client's O365 or Azure environment. Previously, you might have tried to steal session cookies or perform an ASR (Attack Surface Reduction) bypass. Now, you can simply use this tool to "upgrade" your current session to a compliant state.

The impact is significant. Even if the organization has enforced strict Conditional Access policies requiring MFA and specific device health checks, this technique renders those controls moot. You are not just stealing a token; you are forging the entire authentication context.

Defensive Considerations

Defending against this is difficult because the attack exploits the intended design of the Windows authentication stack. Microsoft has categorized this behavior as "by design," meaning a patch is unlikely.

Blue teams should focus on detection rather than prevention. Monitor for suspicious RPC activity targeting lsass.exe, specifically calls originating from unexpected processes that attempt to interact with the aadcloudap plugin. Additionally, analyze your Sign-in Logs in Entra ID. Look for multiple successful authentications from the same DeviceId but involving different user accounts. This is a strong indicator that an attacker is using a single compromised machine to pivot across multiple identities.

Finally, move beyond device-based policies. Relying solely on "corporate device" status is no longer sufficient. Implement phishing-resistant MFA, such as FIDO2 security keys, which are much harder to forge than a device-bound PRT. If your security model relies on the assumption that a device is "safe" just because it is managed, it is time to re-evaluate your architecture. The hardware is only as secure as the software that talks to it.