AuthCodeFix aka ConsentFix

Come da tradizione poco prima della fine dell'anno, appare una nuova vulnerabilità o un vettore di attacco astuto, e i Defender si ritrovano a cercare di proteggere i loro utenti. Nel frattempo, altri attaccanti e red teamer osservano da vicino e si adattano.

Quest'anno, PushSecurity ha rilevato un attacco che ha chiamato «ConsentFix», un'evoluzione dell'attacco ClickFix che si basa sull'utente per fornire all'attaccante un URI che di fatto consegna la chiave del regno di Entra. Il metodo usato in the wild si basava su un'azione manuale di copia e incolla da parte dell'utente per funzionare. Nel giro di pochi giorni, John Hammond ha pubblicato un video che mostrava una versione migliorata dell'attacco che non richiedeva più il copia e incolla; l'utente poteva semplicemente trascinare e rilasciare il suo auth code all'attaccante.

Se esaminiamo i dettagli tecnici del motivo per cui questo attacco funziona e apparentemente aggira la device compliance e altri requisiti di Conditional Access, ci ritroviamo nell'authorization code flow di OAuth 2.0.

L'attaccante crea un URI di login di Microsoft Entra che punta al client «Microsoft Azure CLI» e alla risorsa «Azure Resource Manager», e apre questo URI quando l'utente visita il sito web malevolo.

Mappato all'authorization code flow, questo corrisponde al primo passo che una native public app come Azure CLI normalmente chiamerebbe per autenticare l'utente. L'applicazione crea un listener sulla macchina su cui viene eseguita, su una porta alta casuale. Questa porta viene utilizzata come cosiddetto reply URI.

Puoi riprodurre facilmente questo scenario, ad esempio usando TokenTacticsV2, oppure costruendo l'URI manualmente.

Dopo che l'utente accede con successo a Entra ID, viene reindirizzato al reply URI, ad esempio http://localhost:3001. In uno scenario normale, Azure CLI ora accetterebbe la chiamata a questo URI e riceverebbe l'informazione importante e critica che fa parte del redirect:

• code
  Questo è l'authorization_code, che l'applicazione usa per richiedere un bearer token, il quale è composto da access, ID e opzionalmente refresh token.
  Secondo la documentazione, questo codice è valido per circa 10 minuti e deve essere riscattato entro questo tempo.
• state
  Questo è un parametro opzionale, e l'applicazione dovrebbe verificare che sia identico nella richiesta e nella risposta.

Nello scenario di attacco, l'utente viene comunque reindirizzato, ma poiché nessuna applicazione è in esecuzione su localhost, il browser incontra un errore.

Ma l'URI contiene ancora le informazioni sensibili, ed è proprio questo che l'attaccante vuole che l'utente gli fornisca. Se l'utente asseconda la richiesta, l'attaccante riscatterà ora il materiale del token e potrà poi usare l'access e il refresh token per accedere alla risorsa, in questo caso Azure Resource Manager.

In questo screenshot vedrai come recuperare il bearer token usando l'URI fornito dall'utente.

Se vuoi testare le tue detection, assicurati di eseguire l'ultimo passaggio da un sistema diverso, in una rete diversa.

Artefatti di detection

Quando riproduci l'attacco e controlli i SigninLogs e gli AADNonInteractiveUserSignInLogs, vedrai due eventi per questa singola attività di sign-in. Il primo evento rappresenta il sign-in effettivo dell'utente, mentre il secondo proviene dall'infrastruttura dell'attaccante.

La grande differenza è che il primo evento è un sign-in interattivo, mentre il secondo è non interattivo. Questo si traduce nelle due fasi del flow di autenticazione: prima l'utente, poi l'applicazione o, nel nostro caso, l'attaccante.

Il comportamento regolare di Azure CLI sarebbe che entrambi gli eventi di sign-in provengano dallo stesso indirizzo IP. Tuttavia, nel nostro caso gli indirizzi IP sono diversi e provengono da paesi diversi. Naturalmente, quest'ultimo non è un indicatore affidabile, poiché l'attaccante potrebbe risiedere nello stesso paese della vittima per nascondere le proprie tracce.

Anello mancante

Cercando un buon modo per collegare questi due eventi, la prima idea naturale è stata di controllare lo Unique Token Identifier (UTI). Tuttavia, Microsoft usa valori diversi per l'UTI dell'authorization code e l'UTI del bearer token, quindi questo approccio non funziona come collegamento affidabile.

Tuttavia, il SessionId è un buon collegamento tra i due, anche se è un ID di lunga durata e potrebbe contenere più combinazioni di questi eventi, anche legittime.

Con la conoscenza aggiuntiva dei limiti dell'auth code flow e con user id e application id come collegamenti supplementari, puoi usare il tempo come importante fattore di detection:

• Entrambi gli eventi condividono lo stesso SessionId
• Entrambi gli eventi condividono lo stesso ApplicationId
• Entrambi gli eventi condividono lo stesso UserId
• Il secondo evento deve essere successivo al primo
• Il secondo evento deve avvenire entro una finestra temporale di circa 10 minuti dopo il primo. Non dovresti usare esattamente 10 minuti, poiché Microsoft scrive «[...] they expire after about 10 minutes»
• Dovresti considerare solo il secondo evento immediatamente successivo, non quelli seguenti

Fun fact
Il ResourceIdentity non è un buon collegamento, poiché l'attaccante può cambiare la risorsa dato che non è legata all'auth code. L'application ID di destinazione non può essere modificato.

Ridurre il rumore

Questa conoscenza ci ha già fornito una detection funzionante, ma nel mix c'erano anche benign positive. Gli sviluppatori moderni usano risorse cloud che appaiono come istanze locali, ma che producono pattern di login irregolari nei log.

La differenza chiave è la componente temporale. Mentre l'attacco richiede l'interazione dell'utente per copiare e incollare o trascinare l'URI, il caso d'uso di GitHub Codespace che abbiamo identificato come fonte degli alert benign positive è completamente automatizzato e riscatta l'auth code in pochi secondi.

Quindi filtrare tutto ciò che esegue questa danza di autenticazione in pochi secondi può molto probabilmente essere rimosso come benigno.

Un'altra fonte di rumore potrebbero essere gli egress point mutevoli per il tuo traffico internet, in particolare negli scenari SD-WAN, ZTNA o Secure Web Gateway.

Applicazioni first-party interessate

Mentre il report iniziale mostra «Microsoft Azure CLI» come l'applicazione abusata, ci sono molte diverse app first-party di Microsoft con pre-consent in ogni tenant che offrono localhost come redirect. E non sono le uniche a essere un obiettivo. L'attaccante potrebbe anche abusare di reply test e dev URL che non sono pubblicamente risolvibili.

Ecco una lista delle applicazioni più rilevanti che hanno anche permessi pre-consented elevati sulle risorse.

• Microsoft Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46)
• Microsoft Azure PowerShell (1950a258-227b-4e31-a9cf-717495945fc2)
• Visual Studio (04f0c124-f2bc-4f59-8241-bf6df9866bbd)
• Visual Studio Code (aebc6443-996d-45c2-90f0-388ff96faa56)
• MS Teams PowerShell Cmdlets (12128f48-ec9e-42f0-b203-ea49fb6af367)

Una lista completa di queste app è ora inclusa in EntraScopes.com dal nostro collega Fabian Bader.

Mitigazioni e protezioni

Limitare la superficie di attacco e l'audience

Opzione 1: Require User Assignment

Prerequisiti:

• Aggiungi il service principal per le app first-party interessate usando la Microsoft Graph API o PowerShell
• Applica il requisito di user assignment sull'oggetto service principal usando la Microsoft Graph API o PowerShell
• Stabilisci un processo per assegnare gli utenti su richiesta tramite Access Packages, PIM-for-Groups (per accesso just-in-time), o una combinazione di entrambi.

// Example for Microsoft Graph PowerShell
Connect-MgGraph -Identity
$AppId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46" // Microsoft Azure CLI
$sp = Get-MgServicePrincipal -Filter "appId eq '$AppId'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$false

Vantaggio:

• Consente la gestione degli user assignment tramite Access Packages o membership manuale ai gruppi per limitare l'esposizione a questa tecnica di attacco.
• Opzione per fornire accesso just-in-time combinato con l'assegnazione di membership eligible ai gruppi, permettendo un accesso temporaneo ai CLI tool e riducendo ulteriormente la superficie di attacco.
• Applicato prima di valutare le Conditional Access policy.
• Limita la superficie di attacco anche per altri scenari.

Svantaggio:

• Può essere applicato solo a utenti specifici e non combinato con altri requisiti come l'uso di dispositivi specifici
• Tutti gli utenti legittimi dei CLI tool devono essere identificati
• Gli effetti collaterali e l'impatto organizzativo devono essere valutati con attenzione esaminando i sign-in precedenti.

Opzione 2: Bloccare l'accesso tramite Conditional Access Policy

Prerequisiti:

• Crea una Conditional Access policy per bloccare l'accesso ai CLI tool, escludendo gli utenti legittimi, puntando a «Microsoft Graph Command Line Tools» e «Windows Azure Service Management API»
• Gestisci le esclusioni tramite membership ai gruppi, sia manualmente sia tramite entitlement management (ad esempio, Access Packages).

Vantaggio:

• Impedisce l'emissione di token per utenti non legittimi o non privilegiati.
• Consente uno scoping granulare basato su condizioni aggiuntive come device o network.

Svantaggio:

• Tutti gli utenti legittimi dei CLI tool devono essere identificati ed esclusi.
• Gli effetti collaterali e l'impatto organizzativo devono essere valutati con attenzione esaminando i sign-in precedenti e valutando la policy in modalità report-only.

Bloccare l'emissione di token tramite authorization code flow

Prerequisiti:

• Licenze Microsoft Entra ID P1
• Dispositivi Entra ID Registered, Hybrid o Entra ID-joined su piattaforma Windows
• Abilitare Web Account Manager (WAM) in Azure CLI, Azure PowerShell e Microsoft Graph PowerShell (default nelle ultime versioni)
• Configurare Conditional Access puntando a:
  • Cloud App targeting alle seguenti app:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client app sotto Mobile apps and desktop clients per richiedere Token Protection.
  • Selezionare Windows come device platform per applicare la policy

Vantaggio:

La token protection di Microsoft Entra richiede il proof-of-possession (PoP), che può essere applicato solo quando il client comunica direttamente con un trusted token broker come il Web Account Manager (WAM) su Windows. Poiché i browser non possono stabilire questo canale sicuro, l'authorization code flow avviato in un browser viene bloccato dalle policy di token protection.

Quando la policy applica la token protection che richiede PoP gestito dal broker, l'authorization code restituito a un browser non può essere riscattato perché il browser non può produrre la prova firmata dal broker richiesta durante lo scambio da codice a token.

In questo caso, gli attacchi con AuthCodeFix saranno completamente mitigati fintanto che l'applicazione può essere protetta da Token Protection.

Come mostrato nello screenshot qui sotto, Token Protection mitiga con successo il riscatto dell'authorization code flow avviato dalla vittima tramite un'azione di phishing.

Svantaggio:

• Solo le seguenti risorse sono ufficialmente supportate:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    La Microsoft Graph API è coperta indirettamente dalle risorse menzionate in precedenza e Microsoft Graph PowerShell è elencato come client supportato. Abbiamo potuto verificare nei nostri test che l'attacco in questo scenario viene mitigato. «Windows Azure Service Management API» non è elencata come risorsa supportata. Entrambi i client CLI (Azure CLI e Azure PowerShell) supportano WAM, che è un requisito lato client per usare Token Protection. Microsoft ha annunciato in un blog post di voler estendere le capacità di token protection agli scenari di Azure management.
• Alcuni bug in Microsoft Graph PowerShell ti costringono a disabilitare temporaneamente l'integrazione WAM
• Gli effetti collaterali e l'impatto organizzativo devono essere valutati con attenzione esaminando i sign-in precedenti e valutando la policy in modalità report-only. Il cloud app targeting influenzerà anche l'accesso produttivo a Microsoft 365.
• Scope limitato per via della disponibilità sulle piattaforme supportate e sui dispositivi integrati con Entra ID.

Bloccare ulteriori emissioni di token tramite compliant network check o trusted network

Opzione: Bloccare l'accesso al di fuori del Compliant network con Global Secure Access

Prerequisiti:

• Licenza Entra ID P1
• Dispositivi Entra ID Registered, Hybrid o Entra ID-joined su piattaforma Windows, macOS, Android e iOS
• Global Secure Access Client su tutti i client interessati e Entra Internet Access abilitato per M365 Traffic Profile
• La Conditional Access Policy per applicare il network compliant check deve essere applicata a tutte le cloud app

Vantaggio:

Bloccare l'emissione di token aggiuntivi imponendo un trusted network check. Questa mitigazione garantisce che gli attaccanti non possano ottenere nuovi token usando il refresh token dell'authorization code flow. Tuttavia, non impedisce il riscatto iniziale dell'authorization code o l'emissione del primo access token, che rimane valido al di fuori del compliant network perché era stato originariamente richiesto dalla vittima.

Applicare GSA con la condizione Compliant Network blocca anche altri scenari di Token Replay e aggiunge log supplementari che possono essere molto utili per detection e hunting.

Svantaggio:

• Applicabile solo a utenti e dispositivi con il Global Secure Access client distribuito
• Scope limitato per via della disponibilità sui dispositivi integrati con Entra ID
• Applicare i Compliant Network tramite CA richiederà alcune esclusioni come Intune per evitare problemi da uovo e gallina. È necessario un test dettagliato prima del rollout

Hunting queries

Una volta soddisfatti tutti i prerequisiti per le mitigazioni contro il furto di token, come il deployment del client GSA (inclusa l'ingestion dei log NetworkAccessTraffic) e sfruttando l'autenticazione WAM, otteniamo opzioni aggiuntive per il threat hunting e la verifica.

Sfruttare i log GSA e l'autenticazione WAM per l'hunting o per verificare la confidence sui risultati di detection

Questa hunting query sfrutta i log NetworkAccessTraffic di Global Secure Access (GSA), che includono il processo iniziatore per la comunicazione con l'endpoint dei token di Microsoft Entra. Questo aiuta a determinare se una richiesta di token è originata direttamente da un browser e anche se sono state effettuate ulteriori richieste di token al di fuori della rete GSA.

Questa query funziona e fornisce risultati affidabili solo quando i prerequisiti sono soddisfatti; altrimenti porta a un alto tasso di falsi positivi.

Perché è importante: Quando si effettua il sign-in tramite CLI o moduli PowerShell usando Web Account Manager (WAM) su dispositivi Windows, il flow non coinvolge un authorization code basato su browser. Questo comportamento di sign-in è il default nell'ultima versione. Pertanto, se il processo iniziatore è un eseguibile di browser (ad esempio, msedge.exe), questo è un forte indicatore di attività sospetta. Su macOS, il processo viene iniziato dall'app Company Portal (com.microsoft.CompanyPortalMac.ssoextension) quando si usa Platform SSO.

Token Binding e PoP: L'autenticazione WAM tipicamente lega i token al dispositivo imponendo il Proof-of-Possession (PoP). Gli attaccanti non possono emettere ulteriori token vincolati senza PoP, quindi un refresh token non vincolato è un altro forte indicatore.

Limitazioni: Tutti i segnali menzionati sono disponibili solo quando il dispositivo che accede è registrato o joined a Microsoft Entra ID.

Logica del Confidence Score: La query combina più segnali per calcolare un confidence score:

• Presenza di un processo browser che avvia richieste di token.
• Detection e down grade a token non vincolati.
• Cambiamenti del network provider (incluso da Compliant a non-compliant) tra un sign-in e l'altro.

Questi segnali possono essere usati nella query per l'hunting di attività o per derivare un confidence score in caso di incidente basato sulla detection precedente.

Verrà mostrato il seguente scoring a seconda delle condizioni:

Un confidence score molto alto viene mostrato quando i log NetworkAccessTraffic indicano un processo browser familiare invece dell'iniziazione di una richiesta di token, ed è stato rilevato un downgrade di un token non vincolato.

Un confidence score alto viene mostrato quando il sign-in avviene da un Network Provider (ASN) diverso e da una rete non compliant che coinvolge token non vincolati.

Un confidence score medio viene mostrato quando viene identificato solo un cambio di Network Provider e una rete compliant, insieme a un cambio del tipo di token utilizzato.

Troverai la versione più recente della hunting query su GitHub.

Hunting per attività basate sui token emessi

Dovresti considerare di estendere l'investigazione oltre gli eventi di sign-in per includere le attività eseguite usando i token emessi dall'attaccante. Il nostro collega Thomas Naunheim ha pubblicato una funzione KQL chiamata MicrosoftCloudActivity, che può assistere in questo processo di hunting esteso. Inoltre, il SessionId interessato può essere correlato con valori UniqueId sospetti identificati durante hunt precedenti per un'analisi più approfondita.

In questo esempio, l'attaccante ha sfruttato il refresh token ottenuto durante l'attacco per emettere un access token per la Microsoft Graph API. Questo token è stato poi usato per mantenere accesso persistente e movimento laterale aggiungendo un client secret a un'applicazione posseduta dalla vittima. La query fornisce dettagli sull'operazione della Graph API, incluso lo stato di token protection e se l'operazione è avvenuta al di fuori della rete Global Secure Access.

Ulteriori letture

• ConsentFix: Analysing a browser-native ClickFix-style attack that hijacks OAuth consent grants - PushSecurity
• Hacking Endpoint to Identity (Microsoft 365): "ConsentFix" - YouTube
• Microsoft identity platform and OAuth 2.0 authorization code flow
• Microsoft Azure CLI on entrascpes.com