Bypass Intune Conditional Access Using TokenSmith: Detection & Response

Blackhat EU 2024 brought the Cybersecurity Community numerous findings from great security researchers and hackers from across the globe.

Perhaps none of these have been more impactful than a talk given by TEMP43487580 about bypassing Conditional Access Policy in Microsoft Intune.

Further support was provided by researcher Dirk-Jan and to quote him directly "the cat is now out of the bag."

Our Threat Detection and Response Principal Richard Alldrin dove further into this exploit and found ways to detect it with high fidelity utilizing Entra ID P2 sign-in logs within Defender XDR.

Understanding the Exploit

Leveraging TokenSmith, a tool documented on GitHub by JumpsecLabs, we were able to bypass Microsoft Intune’s Conditional Access Policies (CAPs). Specifically, we targeted variations of CAPs requiring device compliance for access and successfully used captured tokens to enumerate the tenant with GraphRunner.

This exploit demonstrates how adversaries can bypass Conditional Access Policies designed to enforce device compliance utilizing Intune Company Portal.

Key exploit flow:

1. Prepare the tenant with a device-compliant CAP policy.
2. Log in to the Microsoft Intune Company Portal using a non-compliant device.
3. Successfully pass Multi-Factor Authentication (MFA), but encounter a stalled screen.
4. Extract the error URL from the browser’s developer console and paste it into TokenSmith.
5. If successful, retrieve access and refresh tokens.
6. Import tokens into a post-exploitation tool like GraphRunner to enumerate the tenant.

Note: The Microsoft Intune Company Portal used in this attack is not the standard “intune.microsoft.com” login portal.

Detection Insights

While no alerts were generated by Microsoft Entra ID P2, Defender Identity, or Cloud Apps, we were able to create a robust detection mechanism.

Using advanced queries in Microsoft Defender XDR, we flagged the following suspicious activities:

• Successful logins to Microsoft Intune Company Portal with a non-compliant device.
• CAP policies enforcing “RequireCompliantDevice” or “Block” returning results like CAP.result == failure or CAP.result == notApplied.

Here’s the detection query we developed:

AADSignInEventsBeta
| where ApplicationId == "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223"
and ErrorCode == "0"
| extend CAP = parse_json(ConditionalAccessPolicies)
| mv-expand CAP
| where (CAP.enforcedGrantControls has "RequireCompliantDevice" and CAP.result == "failure")
or (CAP.enforcedGrantControls has "Block" and CAP.result == "notApplied")
and IsCompliant == "0"
| project
 Timestamp,
 AccountDisplayName,
 AccountUpn,
 Application,
 ApplicationId,
 EndpointCall,
 LogonType,
 ErrorCode,
 CAP.displayName,
 CAP.result,
 SessionId,
 ResourceDisplayName,
 DeviceName,
 AadDeviceId,
 IsCompliant,
 IsManaged,
 Browser,
 IPAddress,
 CAP.enforcedGrantControls,
 CAP.conditionsSatisfied,
 CAP.conditionsNotSatisfied,
 CAP.includeRulesSatisfied,
 ConditionalAccessStatus

SOC Action Plan

Upon detecting this exploit, the following steps should be immediately implemented:

1. Revoke active user sessions and tokens.
2. Enforce password resets and re-registration of MFA.
3. Review Entra ID sign-in logs for suspicious activities.
4. Block sign-ins or disable compromised accounts.
5. Investigate lateral movement and unauthorized access attempts.
6. Monitor for post-exploitation activities, especially involving tools like GraphRunner.

Prevention & Future Mitigations

Currently, no direct prevention options have been identified, but we fully expect Microsoft to respond given the high probability of abuse in utilizing Tokensmith.

Organizations should have Adversary Emulation teams work with Threat Hunters, Detection Engineers, and SOC Teams to understand how to further detect abuse of this exploit.

Conclusion

This detection provides a significant value-add for organizations using Microsoft Intune and highlights our commitment to staying ahead of threat actors.

We encourage the community to deploy our detection query and collaborate on additional prevention mechanisms.

Cybertorch would like to thank TEMP43487580, Dirk-Jan, and the team at JumpSecLabs for their research and contributions in bringing this exploit path to light.

For further updates, feel free to contact us at Cybertorch and stay tuned for more insights into our Purple Team engagements!