Conditional Access Policies (CAPs) are the core of Entra ID’s perimeter defense for the vast majority of Enterprise Microsoft 365 (M365) and Azure environments. The core ideas of conditional access are:

1. Require specific auth strength in scenarios where you wish to grant access
2. Block access in undesirable scenarios
3. If a scenario are neither covered by a or b, then the minimal auth strength (password) would be sufficient

A special condition for CAP requirements is that authentication can be required to come from an “Intune Compliant” device (also known as “company managed” to the user), otherwise the authentication would be unsuccessful. In our adversarial engagements, more hardened M365 environments often have this requirement for a large subset of cloud apps used by the company, making running post-exploitation Entra ID tools like GraphRunner, RoadRecon, Teamfiltration, etc. difficult. The conundrum is that you would need to be on a compliant device to get properly authenticated, however getting valid access & refresh token from the Endpoint device tends to be time consuming / loud, and it might not be practical to run something like GraphRunner directly on the beachhead device.

Few weeks ago in BlackHat EU 2024, TEMP43487580 (@TEMP43487580) gave a talk related to this topic. Dirk-jan, (@_dirkjan) who also previously worked on the same attack path, disclosed the relevant client ID in a tweet and mentioned looking into the Company Intune Portal in the same thread. According to Dirk-jan himself, the “cat is out of the bag” for bypassing the CAP auth requirement for an Intune compliant device.

1

> Client_id: 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223

Folks in the adversarial simulation team in JUMPSEC got super excited about the possibility of getting a PoC working. I worked on this on a Friday night, helped by our Tom Ellson and a working bypass was completed based on this.

Behind the scenes I’ve been working on an Entra authentication util called TokenSmith for a while now. With the opportune timing of this new PoC, I decided to incorporate the bypass into the tool and release it in the current state. You can find TokenSmith on: https://github.com/JumpsecLabs/TokenSmith.

You can also skip the PoC sections of the post if you don’t want to read about the discovery process.

How do I defend against this?

The Intune Device Enrollment Service can be explicitly set on Entra ID conditional access as one of the cloud apps that must satisfy compliant device enrollment. However the dilemma is that you cannot enroll any new compliant device that way for your starters because a device must go through the Non-compliant > Compliant journey first via this very client. Seeing how it works it is also highly unlikely Microsoft would change the underlying functionality any time soon.

A more productive way would be to ensure that the Intune Company Portal Desktop app requires some form of MFA by conditional access by testing with running the Portal app on a VM and attempting to sign in, or by using TokenSmith. It is unfortunately not as simple as firing up the ‘What if’ tool in Entra ID because the 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223 client is not a searchable Enterprise App in Azure.

You would have to go into the Sign In logs for a user (Entra ID admin center > Users > YourTestUser > Sign in logs) and filter for Application > 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223  , and Click into the individual logins to see whether they were Successful and whether the MFA enforcing conditional access policy is applied.

Limitations and Future Development

As explained above you must be able to authenticate to the service to get tokens (fair enough), so requiring MFA to enroll devices is a reasonable defensive measure. However, what about AiTM phishing to bypass the MFA? It would be interesting to see how AiTM phishing can factor into this, for example, if the Evilginx server can AiTM a login to Intune instead of the commonly implemented login to Office.com. Another limitation I observed is that if non-compliant devices can only get tokens for the enrollment service, trying to redeem access tokens for other clients (for example Az PowerShell) with the Refresh tokens obtained would be blocked. Though I have yet to fully explore what is possible to do using this client alone, and getting access to both MS Graph and AD Graph is already very useful indeed!