Compliant Device Bypass - All you need to know!

What happened so far?

• In December 2024 Yuya Chudo gave his talk “Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise” at the Black Hat Europe conference. In this session he showed how to abuse a hardcoded rarely known exclusion in Conditional Access (CA) for device compliance in combination with the undocumented “FOCI-Feature” in Entra ID. In the talk he also presented the response from Microsoft MSRC (VULN-123240) that this behavior is by design and required for successful Intune Enrollment of new devices.
• Some days after the conference Sunny Chau published the proof-of-concept tool TokenSmith including a companion blog posts - what made the technique available for a broader audience.
• In addition, a PoC written in PowerShell has been published.
• Since the end of December, we at glueckkanja AG have been investigating how to prevent and detect this technique. In this blog post we would like to share some of our insights regarding the attack and discuss mitigation and detection options.

TL;DR

There are some resources with a built-in exclusion to specific Grant Controls/Conditions in Conditional Access to solve certain problems. One of them is the exclusion of the Company Portal App for Device Compliance to solve the chicken-egg-problem to get devices enrolled in Intune before they are considered compliant. This behavior is documented here. This means you can get access and refresh token for this app from an unmanaged device even if a CA policy is enforcing Device Compliance for “All resources”.

Microsoft has implemented a feature called Family of Client IDs (FOCI) which allows a group of Microsoft OAuth client applications to obtain access tokens as any other client in the family using their refresh token. A behavior otherwise not allowed in the OAuth2 standard. Read the original work of Secureworks for more details. Since the Company Portal App is a “family member” the requested Refresh Tokens for it can be used to get tokens for other apps in the family.

The FOCI feature is limited and the consent between the client id and the resource must be explicitly configured and granted. In the case of the Company Portal App this consent has been granted, among others, for access to Microsoft Graph using a restricted scope and to the Azure AD Graph API with the permission of the current user. This means a Company Portal refresh token can be used to obtain e.g. Azure AD Graph API access tokens with the scope user_impersonation, allowing us to do a lot of things with eg. AADInternals or ROADrecon

To execute the attack, the attacker requires either valid credentials of the victim as well as the ability to perform MFA if this is required by Conditional Access or a valid refresh token.

What risk and blast radius exists?

Which of the possible resources (scopes) are affected from the compliance exclusion?

The Attacker has the option to request tokens for another FOCI application as already described before. However, Microsoft has implemented a bypass for the device compliance requirements only for accessing tokens to certain resource applications various API permission scope. In particular, the following delegated API permissions are sensitive and of interest to attackers:

Since the granted permissions are not for the application itself, the impact depends on the privileges of the caller (user account) and which delegated permission scopes are authorized to execute API calls on the scope.

Let us have a closer look at the criticality of the shown delegated permission scope and potential authorization to call sensitive APIs?

Which privileges and delegated scope are critical?

Azure AD Graph API

The legacy programmatic interface offers many APIs to manage directory settings and objects in Entra ID (Azure AD). This includes Conditional Access policies, directory roles, CRUD on groups and devices and operations on the signed-in user, such as change password. A full list of all supported operations can be found in the Azure AD Graph API reference. This API will be fully retired on June 30, 2025 (based on Microsoft latest announcements).

The assigned delegated scope “user_impersonation” allows the application (in this case, Company Portal) to act on behalf of the user. So, every permission that the signed-in user has to an Entra object, scope or directory-level can be used as authorization in the API calls. The user might be the owner of an Entra ID object (application, group, or other objects), or they might be assigned permissions through Entra ID role assignments. In the case of active high privileged role assignments, this would allow the attacker to modify objects or compromise the tenant. At least, even without any privileges, default user permissions can be used for extensive reconnaissance and enumeration of directory objects in the tenant.

Therefore, the scenarios and impact to abuse the Azure AD Graph API depends on the active or permanent assigned privileges of the affected user. APIs to access Microsoft 365 services (e.g., for exfiltration of OneDrive) are not included in Azure AD Graph.

Microsoft Graph API

In comparison to Azure AD Graph, the delegated scope to Microsoft Graph API is restricted to a certain scope. Alongside OpenID scopes (openid, email, profile) and basic read operations on behalf of the user (ServicePrincipalEndpoint.Read.All, User.Read).

List and read of all device objects can be achieved by calling “device” endpoint in Microsoft Graph with default permissions by using “Device.Read.All”. This could help attackers to gain insights of device objects.

In case of a compromised user with assignment to “Intune Administrator” or any delegation in Microsoft Intune RBAC, the following granted delegated API permission should be considered problematic:

• ”DeviceManagementConfiguration.Read.All”
• “DeviceManagementConfiguration.ReadWrite.All”

Those delegated permissions allow CRUD operations, for example on Device Compliance and Configuration Policies but also deployment of Management Scripts for further malicious activity on target devices.

Device Registration Service

With this permission the attacker is able to join or register a device to Entra ID. In turn this would allow them to even enroll the device in Intune and depending on the Intune configuration get a valid and compliant to device to access even more protected services.

Other FOCI applications

Requesting access to other privileged interfaces, for example Azure Resource Manager API is in scope of FOCI and interests of the attacker well. However, this resource is still protected and not bypassed to the Conditional access grant control “compliant device”.

Can we detect this attack technique?

As described above, the greatest risk comes from access to MS Graph and Azure AD Graph.

Since the application ID of the Microsoft Intune Company Portal App is always used in this case, the main task for creating a detection is to exclude legitimate use by e.g. device registrations, which according to our observation consists of which resources are accessed first in a session → in case of an attack usually MS Graph or Azure AD Graph.

Here is a working detection that we tested in several environments different sizes:

How should we respond when we detect suspicious activities?

Initialize your incident response process using a defined playbook which contains:

• Hunting for suspicious or anomalous activity by the compromised user
  • Summary of non-interactive sign-in to Resource Applications including IP addresses and UserAgents based on sessionId
  • Check if Microsoft Entra Audit Logs shown critical operations by the user or IP addresses (e.g., added credentials to owned app registrations)
  • Identify if the user has registered devices in the affected session
  • Check Intune audit logs for operations by application “Company Portal” and the affected user
• Hunting for related alerts by the impacted entities
  • Lookup for entities in the AlertEvidence table to identify other alerts based on SessionId, IP Addresses and User
• Identify criticality of the user (by privileges) in Exposure Management
• Review of hunting results and verify if the action was legitimate as part of a device enrollment.
• Identity the initial access vector and reset the users’ credentials and when needed devices.

Can we mitigate the attack?

Since the configured exclusion is required for Intune enrollment, there is no mitigation that would not break other parts of Microsoft 365. Access to the Azure AD Graph resource cannot be scoped or blocked directly. Any Conditional Access policy using “Block” as grant control will prevent access but might have other implications.

But for mitigation it is crucial to understand that this Conditional Access bypass is not a complete attack. It is a technique which as a step allows a range of attacks.

An attack path could be

1. Account Compromise via Phishing and AiTM
2. Conditional Access Bypass
3. Reconnaissance using e.g. ROADrecon, GraphRunner or AADInternals
4. Lateral Movement, Privilege Escalation or Persistence through a newly registered device enrolled in Intune

Since we are not able to mitigate the Conditional Access bypass without breaking Intune enrollment, it is more than reasonable to implement mitigations at the other steps off the attack path and also implement reasonable detections.

To reduce the probability and impact we suggest increasing the strengths of other controls and implement the following soon:

• Enforce MFA for “All Users” and “All Cloud Apps” through Conditional Access. If you only enforce Device Compliance Single Factor Authentication is enough with this technique.
• Do not use Device Compliance or MFA in your rulesets, always enforce both! Using OR would never restrict all access to compliant device, because an access token with MFA in scope would be sufficient to access the tenant.
• Restrict Security Information Registration to Compliant Devices, Phishing Resistant Authentication or TAP. In our tests we did not manage to bypass Device Compliance for the Security Info Registration.
• Require Phishing Resistant Authentication or TAP for Join or Register Devices Without it will be possible to register a device with e.g. AADInternals and this technique.
• Require MFA and “Sign-in frequency every time” for Microsoft Intune Enrollment This limits the timespan an attacker could use fresh credentials to enroll a new device to Intune.

  🚧 Caution: Sign-in frequency every time = Every five minutes
  Microsoft factors for five minutes of clock skew when “every time” is selected in a conditional access policy, so that users do not get prompted more often than once every five minutes.

• Block personally owned devices in the Intune Enrollment restrictions. Without these restrictions, an attacker could enroll a new device and gain additional foothold.
• Set device compliance to fail when no compliance policy is assigned to a device in Intune. By default each device is considered compliant, even if no policy is actually applied. Change this and make a device compliance policy a requirement.

In the long run, we would like to encourage you to invest in rollout password-less, phishing-resistant authentication like Windows Hello for Business and Passkeys (incl. Platform Credentials by using macOS Platform SSO). This will allow you to subsequently enforce phishing resistant authentication and block AiTM attacks. Instead of password allow the usage of Temporary Access Pass (TAP) for limited time and scenarios, e.g. onboarding new devices or employees. To support the usage of TAPs for various use cases we have built MyWorkID.

Conclusion

Conditional Access as the Zero Trust engine for Entra ID is, in itself, already complicated. Added built-in exclusions in the backend of Entra by Microsoft make it even harder for many to understand the impact of policies and protections. Still the idea of Zero Trust and defense in depth holds up.

The device compliance policy prevents most AiTM attacks and multi-factor authentication makes it harder for any attacker to abuse leaked or otherwise compromised credentials.

All these security measures must be used together and not one instead of the other. This ensures a secure environment, even if one of the defenses is tampered with or overcome.

We strongly recommend deploying the provided detection in Microsoft Defender XDR to ensure detection of potential abuse. Make sure your SOC is prepared to investigate those incidents and provide them with the necessary playbooks.