Compliant Device Bypass - allt du behöver veta

Vad har hänt hittills?

• I december 2024 höll Yuya Chudo sitt föredrag ”Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise” på konferensen Black Hat Europe. I sessionen visade han hur man kan missbruka ett hårdkodat och föga känt undantag i Conditional Access (CA) för enhetsefterlevnad i kombination med den odokumenterade ”FOCI-funktionen” i Entra ID. I föredraget presenterade han även svaret från Microsoft MSRC (VULN-123240) om att det här beteendet är avsiktligt och krävs för att nya enheter ska kunna genomföra Intune Enrollment.
• Några dagar efter konferensen publicerade Sunny Chau proof-of-concept-verktyget TokenSmith tillsammans med ett medföljande blogginlägg, vilket gjorde tekniken tillgänglig för en bredare publik.
• Dessutom har en PoC skriven i PowerShell publicerats.
• Sedan slutet av december har vi på glueckkanja AG undersökt hur den här tekniken kan förhindras och detekteras. I det här blogginlägget vill vi dela med oss av några av våra insikter om attacken och diskutera möjligheter till åtgärder och detektering.

TL;DR

Det finns vissa resurser med ett inbyggt undantag från specifika Grant Controls/Conditions i Conditional Access för att lösa särskilda problem. Ett av dem är undantaget för Company Portal-appen från Device Compliance, som löser hönan-och-ägget-problemet med att få enheter registrerade i Intune innan de betraktas som efterlevande. Det här beteendet är dokumenterat här. Det innebär att du kan hämta access- och refresh-token för den här appen från en ohanterad enhet, även om en CA-policy tvingar fram Device Compliance för ”All resources”.

{: .post__screenshot}

Microsoft har implementerat en funktion som kallas Family of Client IDs (FOCI), som tillåter en grupp Microsoft OAuth-klientapplikationer att hämta access-token som vilken annan klient som helst i familjen med hjälp av sin refresh-token. Ett beteende som annars inte är tillåtet enligt OAuth2-standarden. Läs Secureworks ursprungliga arbete för mer detaljer. Eftersom Company Portal-appen är en ”familjemedlem” kan de begärda refresh-token för den användas för att hämta token för andra appar i familjen.

FOCI-funktionen är begränsad och samtycket mellan client id och resursen måste konfigureras och beviljas uttryckligen. För Company Portal-appen har det här samtycket bland annat beviljats för åtkomst till Microsoft Graph med ett begränsat scope och till Azure AD Graph API med den aktuella användarens behörighet. Det innebär att en refresh-token för Company Portal kan användas för att hämta exempelvis access-token för Azure AD Graph API med scopet user_impersonation, vilket låter oss göra en hel del saker med till exempel AADInternals eller ROADrecon.

För att genomföra attacken behöver angriparen antingen giltiga inloggningsuppgifter för offret samt möjlighet att utföra MFA om Conditional Access kräver det, eller en giltig refresh-token.

Vilken risk och vilket skadeomfång finns?

Vilka av de möjliga resurserna (scopes) påverkas av efterlevnadsundantaget?

Angriparen har möjlighet att begära token för en annan FOCI-applikation, som redan beskrivits ovan. Microsoft har dock endast implementerat ett kringgående av kraven på enhetsefterlevnad för åtkomst av token till vissa resursapplikationers olika API-behörighets-scopes. I synnerhet är följande delegerade API-behörigheter känsliga och av intresse för angripare:

Eftersom de beviljade behörigheterna inte gäller själva applikationen beror påverkan på anroparens (användarkontots) privilegier och på vilka delegerade behörighets-scopes som är auktoriserade att utföra API-anrop inom scopet.

Låt oss titta närmare på hur kritiskt det visade delegerade behörighets-scopet är och på potentiell auktorisering att anropa känsliga API:er.

Vilka privilegier och delegerade scopes är kritiska?

Azure AD Graph API

Det äldre programmatiska gränssnittet erbjuder många API:er för att hantera kataloginställningar och objekt i Entra ID (Azure AD). Det inkluderar Conditional Access-policyer, katalogroller, CRUD på grupper och enheter samt operationer på den inloggade användaren, till exempel byte av lösenord. En fullständig lista över alla operationer som stöds finns i referensen för Azure AD Graph API. Det här API:et tas ur bruk helt den 30 juni 2025 (enligt Microsofts senaste tillkännagivanden).

Det tilldelade delegerade scopet ”user_impersonation” tillåter applikationen (i det här fallet Company Portal) att agera för användarens räkning. Varje behörighet som den inloggade användaren har till ett Entra-objekt, ett scope eller på katalognivå kan alltså användas som auktorisering i API-anropen. Användaren kan vara ägare till ett Entra ID-objekt (applikation, grupp eller andra objekt), eller ha tilldelats behörigheter via Entra ID-rolltilldelningar. Vid aktiva högprivilegierade rolltilldelningar skulle detta tillåta angriparen att ändra objekt eller kompromettera tenanten. I värsta fall, även helt utan privilegier, kan standardbehörigheterna för användare utnyttjas för omfattande spaning och uppräkning av katalogobjekt i tenanten.

Scenarierna och påverkan av att missbruka Azure AD Graph API beror därför på den drabbade användarens aktiva eller permanent tilldelade privilegier. API:er för åtkomst till Microsoft 365-tjänster (till exempel för exfiltrering av OneDrive) ingår inte i Azure AD Graph.

Microsoft Graph API

Jämfört med Azure AD Graph är det delegerade scopet till Microsoft Graph API begränsat till ett visst scope. Vid sidan av OpenID-scopes (openid, email, profile) och grundläggande läsoperationer för användarens räkning (ServicePrincipalEndpoint.Read.All, User.Read).

Att lista och läsa alla enhetsobjekt kan göras genom att anropa ”device”-endpointen i Microsoft Graph med standardbehörigheter via ”Device.Read.All”. Detta kan hjälpa angripare att få insikt i enhetsobjekt.

Om en komprometterad användare har tilldelats ”Intune Administrator” eller någon delegering i Microsoft Intune RBAC bör följande beviljade delegerade API-behörigheter betraktas som problematiska:

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

De här delegerade behörigheterna tillåter CRUD-operationer, exempelvis på Device Compliance- och Configuration Policies, men även distribution av Management Scripts för vidare skadlig aktivitet på målenheter.

Device Registration Service

Med den här behörigheten kan angriparen ansluta eller registrera en enhet till Entra ID. Detta gör i sin tur att de till och med kan registrera enheten i Intune och, beroende på Intune-konfigurationen, få en giltig och efterlevande enhet för att komma åt ännu fler skyddade tjänster.

Andra FOCI-applikationer

Att begära åtkomst till andra privilegierade gränssnitt, till exempel Azure Resource Manager API, ligger inom ramen för FOCI och är också av intresse för angriparen. Den här resursen är dock fortfarande skyddad och kringgås inte av grant-kontrollen ”compliant device” i Conditional Access.

Kan vi detektera den här attacktekniken?

Som beskrivits ovan kommer den största risken från åtkomst till MS Graph och Azure AD Graph.

Eftersom applikations-ID:t för Microsoft Intune Company Portal-appen alltid används i det här fallet är huvuduppgiften vid utformningen av en detektering att utesluta legitim användning genom till exempel enhetsregistreringar. Enligt vår observation handlar detta om vilka resurser som först nås i en session → vid en attack vanligtvis MS Graph eller Azure AD Graph.

Här är en fungerande detektering som vi har testat i flera miljöer av olika storlek:

Hur bör vi reagera när vi detekterar misstänkta aktiviteter?

Starta din incident response-process med en definierad playbook som innehåller:

• Jakt efter misstänkt eller avvikande aktivitet från den komprometterade användaren
  • Sammanställning av icke-interaktiva inloggningar till resursapplikationer, inklusive IP-adresser och UserAgents, baserat på sessionId
  • Kontroll av om Microsoft Entra Audit Logs visar kritiska operationer utförda av användaren eller IP-adresserna (till exempel tillagda credentials på egna app-registreringar)
  • Identifiering av om användaren har registrerat enheter i den drabbade sessionen
  • Kontroll av Intune-granskningsloggarna efter operationer från applikationen ”Company Portal” och den drabbade användaren
• Jakt efter relaterade larm hos de påverkade entiteterna
  • Sökning efter entiteter i tabellen AlertEvidence för att identifiera andra larm baserat på SessionId, IP-adresser och användare
• Identifiering av användarens kritikalitet (utifrån privilegier) i Exposure Management
• Granskning av jaktresultaten och verifiering av om åtgärden var legitim som en del av en enhetsregistrering.
• Identifiering av den initiala åtkomstvektorn och återställning av användarens inloggningsuppgifter och vid behov enheter.

Kan vi åtgärda attacken?

Eftersom det konfigurerade undantaget krävs för Intune-registrering finns det ingen åtgärd som inte samtidigt bryter andra delar av Microsoft 365. Åtkomst till Azure AD Graph-resursen kan inte begränsas i scope eller blockeras direkt. Varje Conditional Access-policy som använder ”Block” som grant-kontroll förhindrar åtkomst, men kan få andra konsekvenser.

För åtgärder är det dock avgörande att förstå att det här kringgåendet av Conditional Access inte är en fullständig attack. Det är en teknik som utgör ett steg som möjliggör en rad attacker.

En attackväg kan vara

1. Kontokompromettering via phishing och AiTM
2. Kringgående av Conditional Access
3. Spaning med till exempel ROADrecon, GraphRunner eller AADInternals
4. Lateral förflyttning, privilegieeskalering eller persistens via en nyregistrerad enhet som registrerats i Intune

Eftersom vi inte kan åtgärda kringgåendet av Conditional Access utan att bryta Intune-registreringen är det mer än rimligt att införa åtgärder i attackvägens övriga steg och även införa rimliga detekteringar.

För att minska sannolikhet och påverkan föreslår vi att du stärker andra kontroller och snart inför följande:

• Tvinga fram MFA för ”All Users” och ”All Cloud Apps” via Conditional Access. Om du bara tvingar fram Device Compliance räcker enfaktorsautentisering med den här tekniken.
• Använd inte Device Compliance eller MFA i dina regeluppsättningar, tvinga alltid fram båda. Att använda OR skulle aldrig begränsa all åtkomst till efterlevande enheter, eftersom en access-token med MFA i scope skulle räcka för att komma åt tenanten.
• Begränsa registrering av säkerhetsinformation till efterlevande enheter, phishing-resistent autentisering eller TAP. I våra tester lyckades vi inte kringgå Device Compliance för registrering av säkerhetsinformation.
• Kräv phishing-resistent autentisering eller TAP för att ansluta eller registrera enheter. Utan det går det att registrera en enhet med till exempel AADInternals och den här tekniken.
• Kräv MFA och ”Sign-in frequency every time” för Microsoft Intune Enrollment. Detta begränsar tidsspannet under vilket en angripare kan använda färska inloggningsuppgifter för att registrera en ny enhet i Intune.

  🚧 Observera: Sign-in frequency every time = var femte minut Microsoft räknar med fem minuters klockavvikelse när ”every time” väljs i en Conditional Access-policy, så att användare inte tillfrågas oftare än en gång var femte minut.

• Blockera privatägda enheter i Intune Enrollment-restriktionerna. Utan de här restriktionerna kan en angripare registrera en ny enhet och skaffa sig ytterligare fotfäste.
• Ställ in att enhetsefterlevnad ska misslyckas när ingen efterlevnadspolicy är tilldelad en enhet i Intune. Som standard betraktas varje enhet som efterlevande, även om ingen policy faktiskt tillämpas. Ändra detta och gör en enhetsefterlevnadspolicy till ett krav.

På lång sikt vill vi uppmuntra dig att investera i att rulla ut lösenordsfri, phishing-resistent autentisering som Windows Hello for Business och Passkeys (inklusive Platform Credentials via macOS Platform SSO). Det gör att du därefter kan tvinga fram phishing-resistent autentisering och blockera AiTM-attacker. Tillåt i stället för lösenord användning av Temporary Access Pass (TAP) under begränsad tid och för särskilda scenarier, till exempel onboarding av nya enheter eller medarbetare. För att stödja användningen av TAP i olika användningsfall har vi byggt MyWorkID.

Slutsats

Conditional Access som Zero Trust-motor för Entra ID är i sig redan komplicerat. Microsofts inbyggda undantag i Entras backend gör det ännu svårare för många att förstå vilken påverkan policyer och skydd har. Ändå håller idén om Zero Trust och djupförsvar.

Enhetsefterlevnadspolicyn förhindrar de flesta AiTM-attacker och multifaktorautentisering gör det svårare för en angripare att missbruka läckta eller på annat sätt komprometterade inloggningsuppgifter.

Alla de här säkerhetsåtgärderna måste användas tillsammans och inte den ena i stället för den andra. Det säkerställer en säker miljö, även om något av försvaren manipuleras eller kringgås.

Vi rekommenderar starkt att du distribuerar den tillhandahållna detekteringen i Microsoft Defender XDR för att säkerställa att potentiellt missbruk upptäcks. Se till att din SOC är beredd att utreda sådana incidenter och förse dem med nödvändiga playbooks.