Compliant Device Bypass, tutto quello che devi sapere

Cosa è successo finora?

• A dicembre 2024 Yuya Chudo ha tenuto il suo intervento "Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise" alla conferenza Black Hat Europe. Nella sessione ha mostrato come sfruttare un'esclusione hardcoded e poco conosciuta nel Conditional Access (CA) per la device compliance, combinandola con la "FOCI-Feature" non documentata di Entra ID. Nel talk ha anche presentato la risposta di Microsoft MSRC (VULN-123240), secondo cui questo comportamento è by design e necessario per l'Intune Enrollment di nuovi dispositivi.
• Alcuni giorni dopo la conferenza, Sunny Chau ha pubblicato lo strumento proof-of-concept TokenSmith insieme a un blog post di accompagnamento, rendendo la tecnica accessibile a un pubblico più ampio.
• Inoltre è stato pubblicato un PoC scritto in PowerShell.
• Da fine dicembre, noi di glueckkanja AG stiamo studiando come prevenire e rilevare questa tecnica. In questo blog post condividiamo alcune delle nostre osservazioni sull'attacco e discutiamo opzioni di mitigazione e rilevamento.

TL;DR

Esistono alcune risorse con un'esclusione integrata su specifici Grant Control e condizioni del Conditional Access, pensata per risolvere determinati problemi. Una di queste è l'esclusione della Company Portal App dalla Device Compliance, per risolvere il classico problema dell'uovo e della gallina, ovvero far arrivare i dispositivi in Intune prima che siano considerati compliant. Questo comportamento è documentato qui. Questo significa che puoi ottenere access e refresh token per questa app da un dispositivo non gestito, anche se una policy CA impone la Device Compliance per «All resources».

{: .post__screenshot}

Microsoft ha implementato una funzionalità chiamata Family of Client IDs (FOCI) che consente a un gruppo di applicazioni client OAuth Microsoft di ottenere access token come qualsiasi altro client della famiglia utilizzando il proprio refresh token. Un comportamento altrimenti non consentito dallo standard OAuth2. Leggi il lavoro originale di Secureworks per maggiori dettagli. Poiché la Company Portal App è un «family member», i Refresh Token richiesti per essa possono essere usati per ottenere token per altre app della famiglia.

La funzionalità FOCI è limitata e il consenso tra client id e resource deve essere configurato e concesso in modo esplicito. Nel caso della Company Portal App questo consenso è stato concesso, tra gli altri, per l'accesso a Microsoft Graph con uno scope ristretto e all'Azure AD Graph API con i permessi dell'utente corrente. Questo significa che un refresh token di Company Portal può essere usato per ottenere, ad esempio, access token per l'Azure AD Graph API con lo scope user_impersonation, permettendoci di fare molte cose con AADInternals o ROADrecon.

Per eseguire l'attacco, l'attaccante ha bisogno delle credenziali valide della vittima e della capacità di eseguire l'MFA se richiesto dal Conditional Access, oppure di un refresh token valido.

Quali rischi e quale blast radius esistono?

Quali delle possibili risorse (scope) sono interessate dall'esclusione della compliance?

L'attaccante ha la possibilità di richiedere token per un'altra applicazione FOCI, come già descritto. Microsoft, però, ha implementato il bypass dei requisiti di device compliance solo per l'accesso ai token di determinate applicazioni resource su specifici scope di permessi API. In particolare, i seguenti permessi API delegati sono sensibili e di interesse per gli attaccanti:

Poiché i permessi concessi non sono per l'applicazione stessa, l'impatto dipende dai privilegi del chiamante (account utente) e da quali scope di permessi delegati sono autorizzati a eseguire chiamate API su quello scope.

Diamo un'occhiata più da vicino alla criticità degli scope di permessi delegati mostrati e alle potenziali autorizzazioni per chiamare API sensibili.

Quali privilegi e scope delegati sono critici?

Azure AD Graph API

L'interfaccia programmatica legacy offre molte API per gestire directory settings e oggetti in Entra ID (Azure AD). Include Conditional Access policy, directory roles, operazioni CRUD su gruppi e dispositivi, oltre a operazioni sull'utente autenticato, come il cambio password. Un elenco completo di tutte le operazioni supportate è disponibile nella documentazione dell'Azure AD Graph API. Questa API sarà completamente ritirata il 30 giugno 2025 (in base agli ultimi annunci di Microsoft).

Lo scope delegato «user_impersonation» consente all'applicazione (in questo caso Company Portal) di agire per conto dell'utente. Ogni permesso che l'utente autenticato ha su un oggetto Entra, uno scope o a livello di directory può quindi essere usato come autorizzazione nelle chiamate API. L'utente potrebbe essere il proprietario di un oggetto Entra ID (applicazione, gruppo o altro), oppure potrebbe avere permessi assegnati tramite role assignment di Entra ID. In caso di role assignment attivi ad alto privilegio, questo consentirebbe all'attaccante di modificare oggetti o compromettere il tenant. Anche senza alcun privilegio, i default user permission possono comunque essere usati per un'estesa ricognizione ed enumerazione degli oggetti di directory nel tenant.

Gli scenari e l'impatto dell'abuso dell'Azure AD Graph API dipendono quindi dai privilegi assegnati in modo attivo o permanente all'utente compromesso. Le API per accedere ai servizi Microsoft 365 (ad esempio per l'esfiltrazione da OneDrive) non sono incluse in Azure AD Graph.

Microsoft Graph API

Rispetto ad Azure AD Graph, lo scope delegato verso Microsoft Graph API è limitato a un ambito ben definito. Include gli scope OpenID (openid, email, profile) e operazioni di lettura di base per conto dell'utente (ServicePrincipalEndpoint.Read.All, User.Read).

L'elenco e la lettura di tutti gli oggetti device si possono ottenere chiamando l'endpoint «device» in Microsoft Graph con i permessi di default usando «Device.Read.All». Questo può aiutare gli attaccanti a ottenere informazioni sugli oggetti device.

Nel caso di un utente compromesso a cui è assegnato «Intune Administrator» o una qualsiasi delega nel RBAC di Microsoft Intune, i seguenti permessi API delegati concessi vanno considerati problematici:

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

Questi permessi delegati consentono operazioni CRUD, ad esempio su Device Compliance e Configuration Policy, ma anche il deployment di Management Script per ulteriori attività malevole sui dispositivi target.

Device Registration Service

Con questo permesso l'attaccante è in grado di fare join o register di un dispositivo su Entra ID. Questo gli permetterebbe a sua volta di enrollare il dispositivo in Intune e, a seconda della configurazione Intune, ottenere un dispositivo valido e compliant per accedere ad altri servizi protetti.

Altre applicazioni FOCI

Richiedere l'accesso ad altre interfacce privilegiate, ad esempio l'Azure Resource Manager API, rientra nel perimetro FOCI ed è di interesse per l'attaccante. Questa resource, però, resta protetta e non è bypassata dal grant control di Conditional Access «compliant device».

Possiamo rilevare questa tecnica di attacco?

Come descritto sopra, il rischio maggiore deriva dall'accesso a MS Graph e Azure AD Graph.

Poiché l'application ID della Microsoft Intune Company Portal App è sempre lo stesso in questo caso, il compito principale per costruire un rilevamento è escludere l'uso legittimo dovuto ad esempio a device registration, che in base alle nostre osservazioni si distingue per quali risorse vengono accedute per prime in una sessione. In caso di attacco si tratta di solito di MS Graph o Azure AD Graph.

Ecco un rilevamento funzionante che abbiamo testato in diversi ambienti di dimensioni differenti:

Come dobbiamo rispondere quando rileviamo attività sospette?

Avvia il tuo processo di incident response utilizzando un playbook definito che contenga:

• Hunting di attività sospette o anomale da parte dell'utente compromesso
  • Riepilogo dei sign-in non interattivi verso Resource Application, inclusi IP e UserAgent basati su sessionId
  • Verifica se i Microsoft Entra Audit Log mostrano operazioni critiche da parte dell'utente o degli IP (ad esempio credenziali aggiunte a app registration di proprietà)
  • Identifica se l'utente ha registrato dispositivi nella sessione interessata
  • Controlla gli audit log di Intune per operazioni dell'applicazione «Company Portal» e dell'utente coinvolto
• Hunting di alert correlati sulle entità impattate
  • Cerca le entità nella tabella AlertEvidence per identificare altri alert basati su SessionId, IP e utente
• Identifica la criticità dell'utente (per privilegi) in Exposure Management
• Revisiona i risultati dell'hunting e verifica se l'azione era legittima nell'ambito di un device enrollment.
• Identifica il vettore di accesso iniziale e resetta le credenziali dell'utente, e se serve anche i dispositivi.

Possiamo mitigare l'attacco?

Poiché l'esclusione configurata è necessaria per l'Intune enrollment, non esiste una mitigazione che non rompa altre parti di Microsoft 365. L'accesso alla resource Azure AD Graph non può essere ristretto o bloccato direttamente. Qualsiasi Conditional Access policy che usi «Block» come grant control impedirà l'accesso, ma potrebbe avere altre implicazioni.

Per la mitigazione è cruciale però capire che questo bypass del Conditional Access non è un attacco completo. È una tecnica che, come passaggio, abilita una serie di attacchi.

Un possibile attack path potrebbe essere:

1. Account Compromise via phishing e AiTM
2. Bypass del Conditional Access
3. Reconnaissance con, ad esempio, ROADrecon, GraphRunner o AADInternals
4. Lateral Movement, Privilege Escalation o Persistence tramite un dispositivo appena registrato ed enrollato in Intune

Dato che non possiamo mitigare il bypass del Conditional Access senza rompere l'Intune enrollment, è più che ragionevole implementare mitigazioni negli altri step dell'attack path e mettere in campo detection adeguate.

Per ridurre probabilità e impatto suggeriamo di rafforzare gli altri controlli e implementare a breve quanto segue:

• Applica MFA per «All Users» e «All Cloud Apps» tramite Conditional Access. Se applichi solo Device Compliance, con questa tecnica basta un'autenticazione a fattore singolo.
• Non usare Device Compliance o MFA nelle tue regole, applicali sempre entrambi. Un OR non limiterebbe mai l'accesso solo ai dispositivi compliant, perché un access token con MFA nello scope sarebbe sufficiente per accedere al tenant.
• Restringi la Security Information Registration ai Compliant Device, alla Phishing Resistant Authentication o al TAP. Nei nostri test non siamo riusciti a bypassare la Device Compliance per la Security Info Registration.
• Richiedi Phishing Resistant Authentication o TAP per Join o Register Devices. Senza questa protezione sarà possibile registrare un dispositivo, ad esempio con AADInternals e questa tecnica.
• Richiedi MFA e «Sign-in frequency every time» per l'Intune Enrollment. Questo limita la finestra temporale in cui un attaccante potrebbe usare credenziali fresche per enrollare un nuovo dispositivo in Intune.

  🚧 Attenzione, Sign-in frequency every time significa ogni cinque minuti. Microsoft applica un clock skew di cinque minuti quando in una policy di Conditional Access si seleziona «every time», in modo che agli utenti non venga chiesto di autenticarsi più di una volta ogni cinque minuti.

• Blocca i dispositivi di proprietà personale nelle restrizioni di Intune Enrollment. Senza queste restrizioni un attaccante potrebbe enrollare un nuovo dispositivo e guadagnare un ulteriore appoggio.
• Imposta la device compliance in modo che fallisca quando nessuna compliance policy è assegnata a un dispositivo in Intune. Per impostazione predefinita ogni dispositivo è considerato compliant, anche se non viene applicata alcuna policy. Cambia questo comportamento e rendi obbligatoria una device compliance policy.

Sul lungo periodo ti incoraggiamo a investire nel rollout di autenticazione passwordless e phishing-resistant come Windows Hello for Business e Passkey (incluse le Platform Credential tramite macOS Platform SSO). Questo ti consentirà di applicare progressivamente autenticazione phishing-resistant e di bloccare gli attacchi AiTM. Al posto della password, abilita l'uso del Temporary Access Pass (TAP) per tempi e scenari limitati, ad esempio l'onboarding di nuovi dispositivi o dipendenti. Per supportare l'uso dei TAP in vari casi d'uso abbiamo costruito MyWorkID.

Conclusioni

Il Conditional Access, come motore Zero Trust per Entra ID, è già di per sé complicato. Le esclusioni integrate aggiunte da Microsoft nel backend di Entra rendono ancora più difficile per molti capire l'impatto di policy e protezioni. Nonostante ciò, l'idea di Zero Trust e di defense in depth regge.

La device compliance policy impedisce gran parte degli attacchi AiTM e l'autenticazione a più fattori rende più difficile per qualsiasi attaccante abusare di credenziali leaked o comunque compromesse.

Tutte queste misure di sicurezza vanno usate insieme, e non l'una al posto dell'altra. Questo garantisce un ambiente sicuro anche se una delle difese viene manomessa o superata.

Consigliamo vivamente di implementare il rilevamento fornito in Microsoft Defender XDR per assicurare l'individuazione di potenziali abusi. Assicurati che il tuo SOC sia pronto a investigare questi incidenti e forniscigli i playbook necessari.