Compliant Device Bypass - alles wat je moet weten

Wat is er tot nu toe gebeurd?

• In december 2024 gaf Yuya Chudo zijn talk “Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise” op de conferentie Black Hat Europe. In die sessie liet hij zien hoe je een hardcoded en nauwelijks bekende uitzondering in Conditional Access (CA) voor device compliance kunt misbruiken in combinatie met de ongedocumenteerde “FOCI-Feature” in Entra ID. In de talk presenteerde hij ook de reactie van Microsoft MSRC (VULN-123240) dat dit gedrag by design is en nodig is voor een geslaagde Intune Enrollment van nieuwe devices.
• Een paar dagen na de conferentie publiceerde Sunny Chau de proof-of-concept-tool TokenSmith, inclusief een begeleidende blogpost, waarmee de techniek voor een breder publiek beschikbaar werd.
• Daarnaast is er een PoC geschreven in PowerShell gepubliceerd.
• Sinds eind december onderzoeken wij bij glueckkanja AG hoe deze techniek te voorkomen en te detecteren is. In deze blogpost delen we een deel van onze inzichten over de aanval en bespreken we opties voor mitigatie en detectie.

TL;DR

Er zijn resources met een ingebouwde uitzondering op bepaalde Grant Controls/Conditions in Conditional Access, bedoeld om specifieke problemen op te lossen. Een daarvan is de uitzondering van de Company Portal App voor Device Compliance, die het kip-en-eiprobleem oplost om devices in Intune te enrollen voordat ze als compliant worden beschouwd. Dit gedrag is hier gedocumenteerd. Dit betekent dat je vanaf een unmanaged device een access token en een refresh token voor deze app kunt krijgen, zelfs als een CA-policy Device Compliance voor “All resources” afdwingt.

{: .post__screenshot}

Microsoft heeft een feature geïmplementeerd die Family of Client IDs (FOCI) heet en waarmee een groep Microsoft OAuth-clientapplicaties met hun refresh token access tokens kan opvragen als elke andere client in de family. Gedrag dat in de OAuth2-standaard verder niet is toegestaan. Lees het originele werk van Secureworks voor meer details. Omdat de Company Portal App een “family member” is, kunnen de daarvoor opgevraagde Refresh Tokens worden gebruikt om tokens voor andere apps in de family te krijgen.

De FOCI-feature is beperkt en de consent tussen de client id en de resource moet expliciet worden geconfigureerd en gegeven. In het geval van de Company Portal App is die consent onder andere gegeven voor toegang tot Microsoft Graph met een beperkte scope en tot de Azure AD Graph API met de permissies van de huidige gebruiker. Dit betekent dat een Company Portal refresh token gebruikt kan worden om bijvoorbeeld access tokens voor de Azure AD Graph API met de scope user_impersonation te verkrijgen, waarmee we een hoop dingen kunnen doen met bijvoorbeeld AADInternals of ROADrecon

Om de aanval uit te voeren heeft de aanvaller óf geldige credentials van het slachtoffer plus de mogelijkheid om MFA uit te voeren als Conditional Access dat vereist, óf een geldig refresh token nodig.

Welk risico en welke blast radius bestaan er?

Welke van de mogelijke resources (scopes) worden geraakt door de compliance-uitzondering?

De aanvaller heeft de mogelijkheid om tokens voor een andere FOCI-applicatie op te vragen, zoals hiervoor al beschreven. Microsoft heeft de bypass voor de device compliance-vereisten echter alleen geïmplementeerd voor het opvragen van tokens naar bepaalde resource-applicaties met verschillende API-permission scopes. Met name de volgende delegated API-permissies zijn gevoelig en interessant voor aanvallers:

Omdat de gegeven permissies niet voor de applicatie zelf gelden, hangt de impact af van de privileges van de aanroeper (het gebruikersaccount) en van welke delegated permission scopes gemachtigd zijn om API-calls op die scope uit te voeren.

Laten we de kritikaliteit van de genoemde delegated permission scopes en de mogelijke autorisatie om gevoelige API's aan te roepen nader bekijken.

Welke privileges en delegated scope zijn kritiek?

Azure AD Graph API

De legacy programmeerinterface biedt veel API's om directory-instellingen en objecten in Entra ID (Azure AD) te beheren. Daaronder vallen Conditional Access-policies, directory roles, CRUD op groepen en devices en operaties op de aangemelde gebruiker, zoals het wijzigen van het wachtwoord. Een volledige lijst van alle ondersteunde operaties staat in de Azure AD Graph API reference. Deze API wordt op 30 juni 2025 volledig uitgefaseerd (op basis van de recentste aankondigingen van Microsoft).

De toegewezen delegated scope “user_impersonation” staat de applicatie (in dit geval Company Portal) toe om namens de gebruiker te handelen. Elke permissie die de aangemelde gebruiker op een Entra-object, een scope of op directory-niveau heeft, kan dus als autorisatie in de API-calls worden gebruikt. De gebruiker kan owner zijn van een Entra ID-object (applicatie, groep of ander object), of permissies hebben via Entra ID role assignments. Bij actieve high privileged role assignments zou dit de aanvaller in staat stellen objecten te wijzigen of de tenant te compromitteren. En zelfs zonder enige privileges kunnen op zijn minst de default user permissions worden gebruikt voor uitgebreide reconnaissance en enumeratie van directory-objecten in de tenant.

De scenario's en de impact van misbruik van de Azure AD Graph API hangen daarom af van de actieve of permanent toegewezen privileges van de betrokken gebruiker. API's voor toegang tot Microsoft 365-services (bijvoorbeeld voor exfiltratie van OneDrive) zitten niet in Azure AD Graph.

Microsoft Graph API

Vergeleken met Azure AD Graph is de delegated scope voor de Microsoft Graph API beperkt tot een bepaalde scope. Naast de OpenID-scopes (openid, email, profile) en basale leesoperaties namens de gebruiker (ServicePrincipalEndpoint.Read.All, User.Read).

Alle device-objecten kunnen worden opgesomd en gelezen door met default permissions het “device”-endpoint in Microsoft Graph aan te roepen via “Device.Read.All”. Dat kan aanvallers helpen om inzicht te krijgen in device-objecten.

Bij een gecompromitteerde gebruiker met de rol “Intune Administrator” of met een delegatie in Microsoft Intune RBAC moeten de volgende gegeven delegated API-permissies als problematisch worden beschouwd:

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

Deze delegated permissies maken CRUD-operaties mogelijk, bijvoorbeeld op Device Compliance- en Configuration-policies, maar ook het uitrollen van Management Scripts voor verdere kwaadaardige activiteit op de doeldevices.

Device Registration Service

Met deze permissie kan de aanvaller een device joinen of registreren in Entra ID. Daarmee kan hij het device zelfs in Intune enrollen en, afhankelijk van de Intune-configuratie, een geldig en compliant device krijgen om nog meer beschermde services te benaderen.

Andere FOCI-applicaties

Toegang vragen tot andere privileged interfaces, bijvoorbeeld de Azure Resource Manager API, valt binnen de scope van FOCI en is voor de aanvaller ook interessant. Die resource is echter nog steeds beschermd en wordt niet gebypassed voor de Conditional Access grant control “compliant device”.

Kunnen we deze aanvalstechniek detecteren?

Zoals hierboven beschreven zit het grootste risico in toegang tot MS Graph en Azure AD Graph.

Omdat in dit geval altijd de application ID van de Microsoft Intune Company Portal App wordt gebruikt, is de belangrijkste taak bij het bouwen van een detectie het uitsluiten van legitiem gebruik, bijvoorbeeld door device-registraties. Volgens onze observatie zit het onderscheid in de vraag welke resources als eerste in een sessie worden benaderd → bij een aanval doorgaans MS Graph of Azure AD Graph.

Hier is een werkende detectie die we in verschillende omgevingen van uiteenlopende grootte hebben getest:

Hoe reageren we als we verdachte activiteit detecteren?

Start je incident response-proces met een gedefinieerd playbook dat het volgende bevat:

• Hunten naar verdachte of afwijkende activiteit van de gecompromitteerde gebruiker
  • Overzicht van non-interactive sign-ins naar resource-applicaties, inclusief IP-adressen en UserAgents op basis van sessionId
  • Controleren of de Microsoft Entra Audit Logs kritieke operaties door de gebruiker of vanaf de IP-adressen tonen (bijvoorbeeld toegevoegde credentials bij app-registraties waarvan de gebruiker owner is)
  • Vaststellen of de gebruiker in de betrokken sessie devices heeft geregistreerd
  • De Intune-auditlogs controleren op operaties door de applicatie “Company Portal” en door de betrokken gebruiker
• Hunten naar gerelateerde alerts van de betrokken entiteiten
  • Entiteiten opzoeken in de tabel AlertEvidence om andere alerts te vinden op basis van SessionId, IP-adressen en gebruiker
• De kritikaliteit van de gebruiker (op basis van privileges) bepalen in Exposure Management
• De hunting-resultaten reviewen en verifiëren of de actie legitiem was als onderdeel van een device enrollment.
• De initiële toegangsvector identificeren en de credentials van de gebruiker resetten, en waar nodig ook devices.

Kunnen we de aanval mitigeren?

Omdat de geconfigureerde uitzondering nodig is voor Intune enrollment, is er geen mitigatie die niet andere delen van Microsoft 365 kapotmaakt. Toegang tot de resource Azure AD Graph kan niet direct worden gescoped of geblokkeerd. Elke Conditional Access-policy die “Block” als grant control gebruikt, voorkomt toegang, maar kan andere consequenties hebben.

Voor mitigatie is het belangrijk te begrijpen dat deze Conditional Access-bypass geen volledige aanval is. Het is een techniek die als tussenstap een reeks aanvallen mogelijk maakt.

Een aanvalspad kan zijn

1. Account compromise via phishing en AiTM
2. Conditional Access-bypass
3. Reconnaissance met bijvoorbeeld ROADrecon, GraphRunner of AADInternals
4. Lateral movement, privilege escalation of persistence via een nieuw geregistreerd device dat in Intune is geënrolleerd

Omdat we de Conditional Access-bypass niet kunnen mitigeren zonder Intune enrollment te breken, is het meer dan verstandig om mitigaties bij de andere stappen van het aanvalspad in te bouwen en daarnaast zinvolle detecties te implementeren.

Om de waarschijnlijkheid en de impact te verkleinen raden we aan om andere controls te versterken en het volgende op korte termijn te implementeren:

• Dwing MFA af voor “All Users” en “All Cloud Apps” via Conditional Access. Als je alleen Device Compliance afdwingt, is single factor authentication met deze techniek al voldoende.
• Gebruik Device Compliance of MFA niet als alternatieven in je rulesets, dwing altijd beide af. Met OR beperk je toegang nooit volledig tot compliant devices, omdat een access token met MFA in scope al genoeg is om de tenant te benaderen.
• Beperk Security Information Registration tot compliant devices, phishing-resistant authenticatie of TAP. In onze tests lukte het ons niet om Device Compliance voor de Security Info Registration te bypassen.
• Vereis phishing-resistant authenticatie of TAP voor Join or Register Devices. Zonder die eis is het mogelijk om met bijvoorbeeld AADInternals en deze techniek een device te registreren.
• Vereis MFA en “Sign-in frequency every time” voor Microsoft Intune Enrollment. Dat beperkt de periode waarin een aanvaller verse credentials kan gebruiken om een nieuw device in Intune te enrollen.

  🚧 Let op: Sign-in frequency every time = elke vijf minuten Microsoft rekent met vijf minuten clock skew wanneer “every time” in een Conditional Access-policy is geselecteerd, zodat gebruikers niet vaker dan één keer per vijf minuten een prompt krijgen.

• Blokkeer personally owned devices in de Intune Enrollment restrictions. Zonder die restricties kan een aanvaller een nieuw device enrollen en extra voet aan de grond krijgen.
• Zet device compliance op fail wanneer er in Intune geen compliance policy aan een device is toegewezen. Standaard wordt elk device als compliant beschouwd, ook als er feitelijk geen policy is toegepast. Verander dat en maak een device compliance policy verplicht.

Op langere termijn moedigen we je aan te investeren in de uitrol van wachtwoordloze, phishing-resistant authenticatie zoals Windows Hello for Business en passkeys (inclusief Platform Credentials via macOS Platform SSO). Daarmee kun je vervolgens phishing-resistant authenticatie afdwingen en AiTM-aanvallen blokkeren. Sta in plaats van een wachtwoord het gebruik van een Temporary Access Pass (TAP) toe voor beperkte tijd en beperkte scenario's, bijvoorbeeld het onboarden van nieuwe devices of medewerkers. Om het gebruik van TAP's voor verschillende use cases te ondersteunen hebben we MyWorkID gebouwd.

Conclusie

Conditional Access als Zero Trust-engine voor Entra ID is op zichzelf al ingewikkeld. Door Microsoft ingebouwde uitzonderingen in de backend van Entra maken het voor veel mensen nog moeilijker om de impact van policies en beschermingsmaatregelen te doorzien. Toch houdt het idee van Zero Trust en defense in depth stand.

De device compliance-policy voorkomt de meeste AiTM-aanvallen en multi-factor authentication maakt het voor een aanvaller moeilijker om gelekte of anderszins gecompromitteerde credentials te misbruiken.

Al deze securitymaatregelen moeten samen worden gebruikt en niet als vervanging van elkaar. Zo blijft de omgeving veilig, ook als een van de verdedigingslagen wordt gemanipuleerd of doorbroken.

We raden sterk aan om de geleverde detectie in Microsoft Defender XDR uit te rollen, zodat mogelijk misbruik daadwerkelijk wordt opgemerkt. Zorg ervoor dat je SOC voorbereid is om dit soort incidenten te onderzoeken en geef het team de nodige playbooks.