Compliant Device Bypass: alt hvad du behøver at vide

Hvad er der sket indtil nu?

• I december 2024 holdt Yuya Chudo sit foredrag »Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise« på konferencen Black Hat Europe. I sessionen viste han, hvordan man misbruger en hårdkodet og sjældent kendt undtagelse for device compliance i Conditional Access (CA) i kombination med den udokumenterede »FOCI-feature« i Entra ID. I foredraget fremlagde han også svaret fra Microsoft MSRC (VULN-123240), nemlig at adfærden er by design og nødvendig, for at nye enheder kan gennemføre Intune Enrollment.
• Nogle dage efter konferencen offentliggjorde Sunny Chau proof-of-concept-værktøjet TokenSmith sammen med et ledsagende blogindlæg, hvilket gjorde teknikken tilgængelig for et bredere publikum.
• Derudover er der offentliggjort en PoC skrevet i PowerShell.
• Siden slutningen af december har vi hos glueckkanja AG undersøgt, hvordan teknikken kan forhindres og detekteres. I dette blogindlæg deler vi nogle af vores indsigter om angrebet og diskuterer mulighederne for mitigering og detektion.

TL;DR

Der findes ressourcer med en indbygget undtagelse fra bestemte Grant Controls og betingelser i Conditional Access, som løser bestemte problemer. En af dem er undtagelsen af Company Portal-appen fra device compliance, som løser hønen-og-ægget-problemet med at få enheder enrolleret i Intune, før de betragtes som compliant. Adfærden er dokumenteret her. Det betyder, at du kan få access- og refresh-tokens til denne app fra en unmanaged enhed, selv hvis en CA-politik håndhæver device compliance for »All resources«.

{: .post__screenshot}

Microsoft har implementeret en funktion kaldet Family of Client IDs (FOCI), som gør det muligt for en gruppe af Microsofts OAuth-klientapplikationer at hente access-tokens som enhver anden klient i familien ved hjælp af deres refresh-token. En adfærd, der ellers ikke er tilladt i OAuth2-standarden. Læs Secureworks' oprindelige arbejde for flere detaljer. Da Company Portal-appen er et »family member«, kan de refresh-tokens, der anmodes om til den, bruges til at hente tokens til andre apps i familien.

FOCI-funktionen er begrænset, og samtykket mellem klient-id og ressource skal være eksplicit konfigureret og givet. For Company Portal-appen er dette samtykke blandt andet givet til adgang til Microsoft Graph med et begrænset scope og til Azure AD Graph API med den aktuelle brugers rettigheder. Det betyder, at et refresh-token fra Company Portal kan bruges til at hente for eksempel access-tokens til Azure AD Graph API med scopet user_impersonation, hvilket giver os mulighed for at gøre en hel del med for eksempel AADInternals eller ROADrecon

For at udføre angrebet skal angriberen enten have gyldige credentials fra offeret samt mulighed for at gennemføre MFA, hvis Conditional Access kræver det, eller et gyldigt refresh-token.

Hvilken risiko og blast radius er der?

Hvilke af de mulige ressourcer (scopes) er berørt af compliance-undtagelsen?

Angriberen har som allerede beskrevet mulighed for at anmode om tokens til en anden FOCI-applikation. Microsoft har dog kun implementeret et bypass af kravet om device compliance for adgang til tokens til bestemte ressourceapplikationer med forskellige API-permission-scopes. Særligt de følgende delegerede API-rettigheder er følsomme og interessante for angribere:

Da de tildelte rettigheder ikke gælder applikationen selv, afhænger konsekvensen af, hvilke privilegier den kaldende part (brugerkontoen) har, og hvilke delegerede permission scopes der er autoriseret til at udføre API-kald inden for scopet.

Lad os se nærmere på, hvor kritiske de viste delegerede permission scopes er, og hvilken autorisation de potentielt giver til at kalde følsomme API'er.

Hvilke privilegier og delegerede scopes er kritiske?

Azure AD Graph API

Det gamle programmatiske interface tilbyder mange API'er til at administrere directory-indstillinger og -objekter i Entra ID (Azure AD). Det omfatter Conditional Access-politikker, directory-roller, CRUD på grupper og enheder samt operationer på den indloggede bruger, for eksempel skift af adgangskode. En komplet liste over alle understøttede operationer findes i Azure AD Graph API-referencen. Dette API bliver endeligt udfaset den 30. juni 2025 (ifølge Microsofts seneste meddelelser).

Det tildelte delegerede scope »user_impersonation« giver applikationen, i dette tilfælde Company Portal, mulighed for at handle på brugerens vegne. Enhver rettighed, som den indloggede bruger har til et Entra-objekt, et scope eller på directory-niveau, kan derfor bruges som autorisation i API-kaldene. Brugeren kan være ejer af et Entra ID-objekt, altså en applikation, en gruppe eller andre objekter, eller have fået tildelt rettigheder gennem Entra ID-rolletildelinger. Ved aktive højt privilegerede rolletildelinger ville det give angriberen mulighed for at ændre objekter eller kompromittere tenanten. Selv helt uden privilegier kan standardbrugerrettighederne bruges til omfattende rekognoscering og enumerering af directory-objekter i tenanten.

Scenarierne og konsekvensen af at misbruge Azure AD Graph API afhænger derfor af den berørte brugers aktive eller permanent tildelte privilegier. API'er til adgang til Microsoft 365-tjenester, for eksempel til eksfiltrering af OneDrive, indgår ikke i Azure AD Graph.

Microsoft Graph API

Sammenlignet med Azure AD Graph er det delegerede scope til Microsoft Graph API begrænset til et bestemt omfang. Ved siden af OpenID-scopes (openid, email, profile) er der grundlæggende læseoperationer på brugerens vegne (ServicePrincipalEndpoint.Read.All, User.Read).

Alle enhedsobjekter kan listes og læses ved at kalde »device«-endpointet i Microsoft Graph med standardrettigheder via »Device.Read.All«. Det kan hjælpe angribere med at få indblik i enhedsobjekter.

Hvis en kompromitteret bruger er tildelt rollen »Intune Administrator« eller en hvilken som helst delegering i Microsoft Intune RBAC, bør følgende tildelte delegerede API-rettigheder betragtes som problematiske:

• »DeviceManagementConfiguration.Read.All«
• »DeviceManagementConfiguration.ReadWrite.All«

Disse delegerede rettigheder tillader CRUD-operationer, for eksempel på Device Compliance- og Configuration-politikker, men også udrulning af Management Scripts til yderligere ondsindet aktivitet på målenhederne.

Device Registration Service

Med denne rettighed kan angriberen joine eller registrere en enhed i Entra ID. Det ville til gengæld give mulighed for at enrollere enheden i Intune og, afhængigt af Intune-konfigurationen, få en gyldig og compliant enhed, der giver adgang til endnu flere beskyttede tjenester.

Andre FOCI-applikationer

At anmode om adgang til andre privilegerede interfaces, for eksempel Azure Resource Manager API, ligger inden for FOCI's rækkevidde og er også interessant for angriberen. Denne ressource er dog fortsat beskyttet og ikke undtaget fra Conditional Access-grant-controlet »compliant device«.

Kan vi detektere denne angrebsteknik?

Som beskrevet ovenfor kommer den største risiko fra adgang til MS Graph og Azure AD Graph.

Da applikations-id'et for Microsoft Intune Company Portal-appen altid bruges i dette tilfælde, er hovedopgaven ved at bygge en detektion at udelukke legitim brug som for eksempel enhedsregistreringer. Ifølge vores observationer består forskellen i, hvilke ressourcer der tilgås først i en session → ved et angreb typisk MS Graph eller Azure AD Graph.

Her er en fungerende detektion, som vi har testet i flere miljøer af forskellig størrelse:

Hvordan skal vi reagere, når vi opdager mistænkelig aktivitet?

Start jeres incident response-proces med en defineret playbook, der indeholder:

• Hunting efter mistænkelig eller anomal aktivitet fra den kompromitterede bruger
  • Oversigt over ikke-interaktive sign-ins til ressourceapplikationer inklusive IP-adresser og UserAgents baseret på sessionId
  • Kontrol af, om Microsoft Entra Audit Logs viser kritiske operationer fra brugeren eller IP-adresserne, for eksempel tilføjede credentials til ejede app-registreringer
  • Identifikation af, om brugeren har registreret enheder i den berørte session
  • Kontrol af Intune audit logs for operationer fra applikationen »Company Portal« og den berørte bruger
• Hunting efter relaterede alerts på de berørte entiteter
  • Opslag af entiteter i AlertEvidence-tabellen for at identificere andre alerts baseret på SessionId, IP-adresser og bruger
• Fastlæggelse af brugerens kritikalitet (ud fra privilegier) i Exposure Management
• Gennemgang af hunting-resultaterne og verifikation af, om handlingen var legitim som led i en device enrollment.
• Identifikation af den initiale adgangsvektor og nulstilling af brugerens credentials og om nødvendigt enheder.

Kan vi mitigere angrebet?

Da den konfigurerede undtagelse er nødvendig for Intune enrollment, findes der ingen mitigering, som ikke ville ødelægge andre dele af Microsoft 365. Adgang til Azure AD Graph-ressourcen kan ikke scopes eller blokeres direkte. Enhver Conditional Access-politik med »Block« som grant control vil forhindre adgang, men kan have andre konsekvenser.

Til mitigering er det afgørende at forstå, at dette Conditional Access-bypass ikke er et komplet angreb. Det er en teknik, der som ét skridt muliggør en række angreb.

En angrebssti kunne være

1. Kompromittering af konto via phishing og AiTM
2. Conditional Access-bypass
3. Rekognoscering med for eksempel ROADrecon, GraphRunner eller AADInternals
4. Lateral movement, privilege escalation eller persistens gennem en nyregistreret enhed enrolleret i Intune

Da vi ikke kan mitigere dette Conditional Access-bypass uden at ødelægge Intune enrollment, er det mere end rimeligt at implementere mitigeringer i de øvrige skridt af angrebsstien og samtidig etablere fornuftige detektioner.

For at reducere sandsynlighed og konsekvens anbefaler vi at styrke de øvrige kontroller og implementere følgende snarest:

• Håndhæv MFA for »All Users« og »All Cloud Apps« via Conditional Access. Hvis I kun håndhæver device compliance, er single factor authentication nok med denne teknik.
• Brug ikke device compliance eller MFA i jeres regelsæt, håndhæv altid begge. Et OR ville aldrig begrænse al adgang til compliant enheder, fordi et access-token med MFA i scope ville være nok til at tilgå tenanten.
• Begræns Security Information Registration til compliant enheder, phishing-resistent autentificering eller TAP. I vores test lykkedes det os ikke at omgå device compliance for Security Info Registration.
• Kræv phishing-resistent autentificering eller TAP for join eller registrering af enheder. Uden det vil det være muligt at registrere en enhed med for eksempel AADInternals og denne teknik.
• Kræv MFA og »Sign-in frequency every time« for Microsoft Intune Enrollment. Det begrænser det tidsrum, hvor en angriber kan bruge friske credentials til at enrollere en ny enhed i Intune.

  🚧 Bemærk: Sign-in frequency every time = hvert femte minut Microsoft indregner fem minutters clock skew, når »every time« vælges i en Conditional Access-politik, så brugerne ikke bliver bedt om at logge ind oftere end hvert femte minut.

• Blokér personligt ejede enheder i Intune Enrollment restrictions. Uden disse begrænsninger kan en angriber enrollere en ny enhed og få yderligere fodfæste.
• Sæt device compliance til at fejle, når ingen compliance-politik er tildelt en enhed i Intune. Som standard betragtes hver enhed som compliant, selv hvis ingen politik reelt er anvendt. Lav det om, og gør en device compliance-politik til et krav.

På længere sigt vil vi opfordre jer til at investere i udrulning af password-løs, phishing-resistent autentificering som Windows Hello for Business og passkeys, inklusive Platform Credentials via macOS Platform SSO. Det giver jer mulighed for efterfølgende at håndhæve phishing-resistent autentificering og blokere AiTM-angreb. I stedet for adgangskoder kan I tillade brug af Temporary Access Pass (TAP) i afgrænsede perioder og scenarier, for eksempel onboarding af nye enheder eller medarbejdere. For at understøtte brugen af TAPs i forskellige use cases har vi bygget MyWorkID.

Konklusion

Conditional Access som Zero Trust-motor for Entra ID er i sig selv allerede kompliceret. Yderligere indbyggede undtagelser i Entras backend fra Microsofts side gør det endnu sværere for mange at forstå konsekvensen af politikker og beskyttelser. Alligevel holder idéen om Zero Trust og defense in depth.

Device compliance-politikken forhindrer de fleste AiTM-angreb, og multifaktorautentificering gør det sværere for enhver angriber at misbruge lækkede eller på anden vis kompromitterede credentials.

Alle disse sikkerhedsforanstaltninger skal bruges sammen og ikke som erstatning for hinanden. Det sikrer et sikkert miljø, selv hvis et af forsvarene manipuleres eller brydes.

Vi anbefaler kraftigt at udrulle den viste detektion i Microsoft Defender XDR, så potentielt misbrug bliver opdaget. Sørg for, at jeres SOC er klar til at undersøge den type hændelser, og udstyr dem med de nødvendige playbooks.