Compliant Device Bypass - alt du trenger å vite

Hva har skjedd så langt?

• I desember 2024 holdt Yuya Chudo foredraget «Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise» på konferansen Black Hat Europe. I sesjonen viste han hvordan man kan misbruke et hardkodet og lite kjent unntak i Conditional Access (CA) for device compliance i kombinasjon med den udokumenterte «FOCI-funksjonen» i Entra ID. I foredraget presenterte han også svaret fra Microsoft MSRC (VULN-123240) om at denne atferden er tilsiktet og nødvendig for at nye enheter skal kunne gjennomføre Intune Enrollment.
• Noen dager etter konferansen publiserte Sunny Chau proof-of-concept-verktøyet TokenSmith sammen med et tilhørende blogginnlegg, noe som gjorde teknikken tilgjengelig for et bredere publikum.
• I tillegg har en PoC skrevet i PowerShell blitt publisert.
• Siden slutten av desember har vi i glueckkanja AG undersøkt hvordan denne teknikken kan forhindres og oppdages. I dette blogginnlegget vil vi dele noen av innsiktene våre om angrepet og diskutere muligheter for tiltak og deteksjon.

TL;DR

Det finnes enkelte ressurser med et innebygd unntak fra bestemte Grant Controls/Conditions i Conditional Access for å løse visse problemer. Ett av dem er unntaket for Company Portal-appen fra Device Compliance, som løser høna-og-egget-problemet med å få enheter registrert i Intune før de anses som compliant. Denne atferden er dokumentert her. Det betyr at du kan hente access- og refresh-token for denne appen fra en uadministrert enhet, selv om en CA-policy håndhever Device Compliance for «All resources».

{: .post__screenshot}

Microsoft har implementert en funksjon som heter Family of Client IDs (FOCI), som lar en gruppe Microsoft OAuth-klientapplikasjoner hente access-token som hvilken som helst annen klient i familien ved hjelp av sin refresh-token. En atferd som ellers ikke er tillatt i OAuth2-standarden. Les Secureworks opprinnelige arbeid for flere detaljer. Ettersom Company Portal-appen er et «familiemedlem», kan de forespurte refresh-tokenene for den brukes til å hente token for andre apper i familien.

FOCI-funksjonen er begrenset, og samtykket mellom client id og ressursen må konfigureres og gis eksplisitt. For Company Portal-appen er dette samtykket blant annet gitt for tilgang til Microsoft Graph med et begrenset scope og til Azure AD Graph API med gjeldende brukers tillatelse. Det betyr at en refresh-token for Company Portal kan brukes til å hente for eksempel access-token for Azure AD Graph API med scopet user_impersonation, noe som lar oss gjøre en rekke ting med for eksempel AADInternals eller ROADrecon.

For å gjennomføre angrepet trenger angriperen enten gyldige innloggingsopplysninger for offeret og mulighet til å utføre MFA hvis Conditional Access krever det, eller en gyldig refresh-token.

Hvilken risiko og hvilket skadeomfang finnes?

Hvilke av de mulige ressursene (scopes) påvirkes av compliance-unntaket?

Angriperen har muligheten til å be om token for en annen FOCI-applikasjon, slik det allerede er beskrevet. Microsoft har imidlertid kun implementert en omgåelse av kravene til device compliance for tilgang til token for visse ressursapplikasjoners ulike API-tillatelsesscoper. Særlig følgende delegerte API-tillatelser er sensitive og av interesse for angripere:

Ettersom de tildelte tillatelsene ikke gjelder selve applikasjonen, avhenger effekten av privilegiene til den som kaller (brukerkontoen) og av hvilke delegerte tillatelsesscoper som er autorisert til å utføre API-kall innenfor scopet.

La oss se nærmere på hvor kritiske de viste delegerte tillatelsesscopene er og på potensiell autorisasjon til å kalle sensitive APIer.

Hvilke privilegier og delegerte scoper er kritiske?

Azure AD Graph API

Det eldre programmatiske grensesnittet tilbyr mange APIer for å håndtere kataloginnstillinger og objekter i Entra ID (Azure AD). Det inkluderer Conditional Access-policyer, katalogroller, CRUD på grupper og enheter og operasjoner på den innloggede brukeren, for eksempel bytte av passord. En fullstendig liste over alle støttede operasjoner finnes i referansen for Azure AD Graph API. Dette APIet tas helt ut av bruk 30. juni 2025 (basert på Microsofts siste kunngjøringer).

Det tildelte delegerte scopet «user_impersonation» lar applikasjonen (i dette tilfellet Company Portal) handle på vegne av brukeren. Enhver tillatelse den innloggede brukeren har til et Entra-objekt, et scope eller på katalognivå kan altså brukes som autorisasjon i API-kallene. Brukeren kan være eier av et Entra ID-objekt (applikasjon, gruppe eller andre objekter), eller ha tildelte tillatelser via Entra ID-rolletildelinger. Ved aktive høyprivilegerte rolletildelinger vil dette la angriperen endre objekter eller kompromittere tenanten. I det minste kan standard brukertillatelser, selv uten noen privilegier, brukes til omfattende rekognosering og opplisting av katalogobjekter i tenanten.

Scenarioene og effekten av å misbruke Azure AD Graph API avhenger derfor av den berørte brukerens aktive eller permanent tildelte privilegier. APIer for tilgang til Microsoft 365-tjenester (for eksempel for eksfiltrering av OneDrive) er ikke inkludert i Azure AD Graph.

Microsoft Graph API

Sammenlignet med Azure AD Graph er det delegerte scopet til Microsoft Graph API begrenset til et bestemt scope. Ved siden av OpenID-scoper (openid, email, profile) og grunnleggende leseoperasjoner på vegne av brukeren (ServicePrincipalEndpoint.Read.All, User.Read).

Listing og lesing av alle enhetsobjekter kan gjøres ved å kalle «device»-endepunktet i Microsoft Graph med standardtillatelser via «Device.Read.All». Dette kan hjelpe angripere med å få innsikt i enhetsobjekter.

Ved en kompromittert bruker med tildeling til «Intune Administrator» eller en delegering i Microsoft Intune RBAC bør følgende tildelte delegerte API-tillatelser anses som problematiske:

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

Disse delegerte tillatelsene tillater CRUD-operasjoner, for eksempel på Device Compliance- og Configuration Policies, men også utrulling av Management Scripts for videre ondsinnet aktivitet på målenheter.

Device Registration Service

Med denne tillatelsen kan angriperen joine eller registrere en enhet til Entra ID. Det gjør igjen at de til og med kan enrolle enheten i Intune og, avhengig av Intune-konfigurasjonen, få en gyldig og compliant enhet for å få tilgang til enda flere beskyttede tjenester.

Andre FOCI-applikasjoner

Å be om tilgang til andre privilegerte grensesnitt, for eksempel Azure Resource Manager API, ligger innenfor FOCI og er også av interesse for angriperen. Denne ressursen er imidlertid fortsatt beskyttet og omgås ikke av grant-kontrollen «compliant device» i Conditional Access.

Kan vi oppdage denne angrepsteknikken?

Som beskrevet over kommer den største risikoen fra tilgang til MS Graph og Azure AD Graph.

Ettersom applikasjons-IDen til Microsoft Intune Company Portal-appen alltid brukes i dette tilfellet, er hovedoppgaven ved utforming av en deteksjon å utelukke legitim bruk gjennom for eksempel enhetsregistreringer, som ifølge våre observasjoner handler om hvilke ressurser som nås først i en sesjon → ved et angrep vanligvis MS Graph eller Azure AD Graph.

Her er en fungerende deteksjon som vi har testet i flere miljøer av ulik størrelse:

Hvordan bør vi reagere når vi oppdager mistenkelig aktivitet?

Start incident response-prosessen din med en definert playbook som inneholder:

• Jakt etter mistenkelig eller avvikende aktivitet fra den kompromitterte brukeren
  • Oppsummering av ikke-interaktive innlogginger til ressursapplikasjoner, inkludert IP-adresser og UserAgents, basert på sessionId
  • Kontroll av om Microsoft Entra Audit Logs viser kritiske operasjoner utført av brukeren eller IP-adressene (for eksempel tillagte credentials på egne app-registreringer)
  • Identifisering av om brukeren har registrert enheter i den berørte sesjonen
  • Kontroll av Intune-revisjonsloggene for operasjoner fra applikasjonen «Company Portal» og den berørte brukeren
• Jakt etter relaterte varsler hos de påvirkede entitetene
  • Søk etter entiteter i AlertEvidence-tabellen for å identifisere andre varsler basert på SessionId, IP-adresser og bruker
• Identifisering av brukerens kritikalitet (basert på privilegier) i Exposure Management
• Gjennomgang av jaktresultatene og verifisering av om handlingen var legitim som del av en enhetsregistrering.
• Identifisering av den initiale tilgangsvektoren og tilbakestilling av brukerens innloggingsopplysninger og eventuelle enheter.

Kan vi motvirke angrepet?

Ettersom det konfigurerte unntaket kreves for Intune-registrering, finnes det ingen tiltak som ikke samtidig bryter andre deler av Microsoft 365. Tilgang til Azure AD Graph-ressursen kan ikke scopes eller blokkeres direkte. Enhver Conditional Access-policy som bruker «Block» som grant-kontroll vil hindre tilgang, men kan ha andre konsekvenser.

For tiltak er det imidlertid avgjørende å forstå at denne omgåelsen av Conditional Access ikke er et komplett angrep. Det er en teknikk som utgjør ett steg som muliggjør en rekke angrep.

En angrepssti kan være

1. Kontokompromittering via phishing og AiTM
2. Omgåelse av Conditional Access
3. Rekognosering med for eksempel ROADrecon, GraphRunner eller AADInternals
4. Lateral bevegelse, privilegieeskalering eller persistens via en nyregistrert enhet enrollet i Intune

Ettersom vi ikke klarer å motvirke omgåelsen av Conditional Access uten å bryte Intune-registreringen, er det mer enn rimelig å innføre tiltak på de andre stegene i angrepsstien og også innføre fornuftige deteksjoner.

For å redusere sannsynligheten og effekten foreslår vi at du styrker andre kontroller og snart innfører følgende:

• Håndhev MFA for «All Users» og «All Cloud Apps» via Conditional Access. Hvis du kun håndhever Device Compliance, holder enfaktorautentisering med denne teknikken.
• Ikke bruk Device Compliance eller MFA i regelsettene dine, håndhev alltid begge. Å bruke OR vil aldri begrense all tilgang til compliant enheter, ettersom en access-token med MFA i scope vil være nok til å få tilgang til tenanten.
• Begrens registrering av sikkerhetsinformasjon til compliant enheter, phishing-resistent autentisering eller TAP. I testene våre klarte vi ikke å omgå Device Compliance for registrering av sikkerhetsinformasjon.
• Krev phishing-resistent autentisering eller TAP for å joine eller registrere enheter. Uten det er det mulig å registrere en enhet med for eksempel AADInternals og denne teknikken.
• Krev MFA og «Sign-in frequency every time» for Microsoft Intune Enrollment. Dette begrenser tidsrommet en angriper kan bruke ferske innloggingsopplysninger til å registrere en ny enhet i Intune.

  🚧 NB: Sign-in frequency every time = hvert femte minutt Microsoft regner med fem minutters klokkeavvik når «every time» velges i en Conditional Access-policy, slik at brukerne ikke blir spurt oftere enn en gang hvert femte minutt.

• Blokker privateide enheter i Intune Enrollment-restriksjonene. Uten disse restriksjonene kan en angriper registrere en ny enhet og skaffe seg ytterligere fotfeste.
• Sett device compliance til å feile når det ikke er tildelt en compliance-policy på en enhet i Intune. Som standard betraktes hver enhet som compliant, selv om ingen policy faktisk er anvendt. Endre dette og gjør en device compliance-policy til et krav.

På lang sikt vil vi oppfordre deg til å investere i utrulling av passordløs, phishing-resistent autentisering som Windows Hello for Business og Passkeys (inkludert Platform Credentials via macOS Platform SSO). Det lar deg deretter håndheve phishing-resistent autentisering og blokkere AiTM-angrep. Tillat i stedet for passord bruk av Temporary Access Pass (TAP) i begrenset tid og for bestemte scenarioer, for eksempel onboarding av nye enheter eller ansatte. For å støtte bruken av TAP i ulike bruksområder har vi bygget MyWorkID.

Oppsummering

Conditional Access som Zero Trust-motor for Entra ID er allerede komplisert i seg selv. Microsofts innebygde unntak i backend av Entra gjør det enda vanskeligere for mange å forstå hvilken effekt policyer og beskyttelser har. Likevel holder ideen om Zero Trust og forsvar i dybden.

Device compliance-policyen forhindrer de fleste AiTM-angrep, og multifaktorautentisering gjør det vanskeligere for en angriper å misbruke lekkede eller på annen måte kompromitterte innloggingsopplysninger.

Alle disse sikkerhetstiltakene må brukes sammen, ikke det ene i stedet for det andre. Det sikrer et trygt miljø, selv om ett av forsvarene manipuleres eller omgås.

Vi anbefaler sterkt at du ruller ut den angitte deteksjonen i Microsoft Defender XDR for å sikre at potensielt misbruk oppdages. Sørg for at SOCen din er klar til å etterforske slike hendelser, og gi dem de nødvendige playbookene.