AuthCodeFix aka ConsentFix

Som traditionen byder lige inden årets udgang, dukker der en ny sårbarhed eller en snedig angrebsvektor op, og forsvarerne står tilbage og forsøger at beskytte deres brugere. Imens kigger andre angribere og red teamere nøje med og tilpasser sig.

I år opdagede PushSecurity et angreb, som de døbte "ConsentFix", en videreudvikling af ClickFix-angrebet, der bygger på, at brugeren selv udleverer en URI til angriberen og dermed i praksis rækker nøglen til hele Entra-kongeriget videre. Den metode, der er set i felten, krævede en manuel copy and paste-handling fra brugeren for at fungere. I løbet af få dage udgav John Hammond en video, der demonstrerede en forbedret udgave af angrebet uden behov for copy and paste, hvor brugeren i stedet blot kunne trække og slippe sin auth code over til angriberen.

Når vi ser på de tekniske detaljer bag, hvorfor angrebet virker og tilsyneladende omgår device compliance og andre Conditional Access-krav, ender vi i OAuth 2.0 authorization code flow.

Angriberen laver en Microsoft Entra login-URI, der peger på klienten "Microsoft Azure CLI" og ressourcen "Azure Resource Manager", og åbner denne URI, når brugeren besøger det ondsindede website.

Oversat til authorization code flow svarer det til det første trin, som en native public app som Azure CLI normalt ville kalde for at autentificere brugeren. Applikationen opretter en listener på den maskine, den kører på, på en tilfældig høj port. Denne port bruges som en såkaldt reply URI.

Du kan nemt reproducere det selv, for eksempel med TokenTacticsV2 eller ved at bygge URI'en manuelt.

Efter brugeren har logget ind i Entra ID, bliver brugeren omdirigeret til reply-URI'en, f.eks. http://localhost:3001. I et normalt scenarie ville Azure CLI nu tage imod kaldet til denne URI og modtage de vigtige og kritiske oplysninger, der er en del af redirectet:

• code
  Dette er authorization_code, som applikationen bruger til at anmode om et bearer token, der består af access token, ID token og eventuelt refresh token.
  Ifølge dokumentationen er denne code gyldig i omkring 10 minutter og skal indløses inden for dette tidsrum.
• state
  Dette er en valgfri parameter, og applikationen bør verificere, om den er identisk i request og response.

I angrebsscenariet bliver brugeren også omdirigeret, men da der ikke kører nogen applikation på localhost, løber browseren ind i en fejl.

URI'en indeholder dog stadig de følsomme oplysninger, og det er præcis dem, angriberen vil have brugeren til at udlevere. Hvis brugeren gør det, indløser angriberen tokenmaterialet og kan derefter bruge access token og refresh token til at tilgå ressourcen, i dette tilfælde Azure Resource Manager.

På dette skærmbillede kan du se, hvordan man henter bearer token ved hjælp af den URI, brugeren har udleveret.

Hvis du vil teste dine detektioner, så sørg for at udføre det sidste trin fra et andet system på et andet netværk.

Detektionsartefakter

Når du reproducerer angrebet og tjekker SigninLogs og AADNonInteractiveUserSignInLogs, vil du se to hændelser for denne ene sign-in-aktivitet. Den første hændelse repræsenterer det egentlige brugerlogin, mens den anden stammer fra angriberens infrastruktur.

Den store forskel er, at den første hændelse er et interaktivt sign-in, mens den anden er ikke-interaktiv. Det svarer til de to faser i authentication flowet: først brugeren, derefter applikationen eller i vores tilfælde angriberen.

Normal adfærd for Azure CLI ville være, at begge sign-in-hændelser stammer fra den samme IP-adresse. I vores tilfælde er IP-adresserne forskellige, og de stammer fra forskellige lande. Sidstnævnte er naturligvis ikke en pålidelig indikator, da angriberen kunne opholde sig i det samme land som offeret for at skjule sine spor.

Missing link

Da vi ledte efter en god måde at koble de to hændelser sammen på, var den første naturlige idé at kigge på Unique Token Identifier (UTI). Microsoft bruger dog forskellige værdier for authorization code UTI og bearer token UTI, så den tilgang fungerer ikke som en pålidelig kobling.

Til gengæld er SessionId en god kobling mellem de to, om end det er et langtlevende ID, der kan indeholde flere af disse hændelseskombinationer, også legitime.

Med den ekstra viden om begrænsningerne i auth code flowet samt bruger-id og applikations-id som yderligere koblinger kan du bruge tid som en vigtig detektionsfaktor:

• Begge hændelser deler det samme SessionId
• Begge hændelser deler det samme ApplicationId
• Begge hændelser deler det samme UserId
• Den anden hændelse skal ligge efter den første hændelse
• Den anden hændelse skal ligge inden for et vindue på cirka 10 minutter efter den første hændelse. Du bør ikke bruge præcis 10 minutter, da Microsoft skriver "[...] they expire after about 10 minutes"
• Du bør kun se på den allerførste efterfølgende hændelse, ikke på de senere

Fun fact
ResourceIdentity er ikke en god kobling, da angriberen kan skifte ressource, fordi den ikke er bundet til auth code. Det målrettede applikations-id kan ikke ændres.

Reducer støjen

Denne viden gav os allerede en velfungerende detektion, men der var også benign positives i blandingen. Moderne udviklere bruger cloudressourcer, der fremstår som lokale instanser, men resulterer i uregelmæssige loginmønstre i loggene.

Den afgørende forskel er tidskomponenten. Hvor angrebet kræver brugerinteraktion i form af copy and paste eller drag and drop af URI'en, er det GitHub Codespace-scenarie, vi identificerede som kilden til de benigne alarmer, fuldt automatiseret og indløser auth code inden for få sekunder.

At filtrere alt fra, der gennemfører denne authentication-dans på få sekunder, kan altså med stor sandsynlighed fjernes som benignt.

En anden kilde til støj kan være skiftende egress-punkter for din internettrafik, især i SD-WAN-, ZTNA- eller Secure Web Gateway-scenarier.

Berørte first-party-applikationer

Selvom den oprindelige rapport peger på "Microsoft Azure CLI" som den misbrugte applikation, findes der en lang række forskellige Microsoft first-party-apps med pre-consent i hver eneste tenant, som tilbyder localhost som redirect. Og det er ikke kun dem, der er et mål. Angriberen kunne også misbruge test- og dev-reply-URL'er, der ikke kan slås op offentligt.

Her er en liste over de mest bemærkelsesværdige applikationer, som samtidig har høje pre-consentede permissions på ressourcer.

• 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)

En komplet liste over disse apps er nu inkluderet i EntraScopes.com af vores kollega Fabian Bader.

Mitigering og beskyttelse

Begræns angrebsfladen og målgruppen

Mulighed 1: Kræv User Assignment

Forudsætninger:

• Tilføj service principal for de berørte first-party-apps via Microsoft Graph API eller PowerShell
• Anvend kravet om user assignment på service principal-objektet via Microsoft Graph API eller PowerShell
• Etablér en proces til at tildele brugere efter anmodning via Access Packages, PIM-for-Groups (til just-in-time-adgang) eller en kombination af begge.

// 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

Fordel:

• Gør det muligt at styre user assignments via Access Packages eller manuelt gruppemedlemskab og dermed begrænse eksponeringen for denne angrebsteknik.
• Mulighed for just-in-time-adgang kombineret med eligible gruppemedlemskab, hvilket giver midlertidig adgang til CLI-værktøjer og yderligere reducerer angrebsfladen.
• Anvendes, før Conditional Access-politikker evalueres.
• Begrænser også angrebsfladen i andre scenarier.

Ulempe:

• Kan kun scopes til bestemte brugere og ikke kombineres med andre krav som brug af bestemte enheder
• Alle legitime brugere af CLI-værktøjer skal identificeres
• Sideeffekter og organisatorisk påvirkning skal vurderes grundigt ved at gennemgå tidligere sign-ins.

Mulighed 2: Blokér adgang med Conditional Access-politikker

Forudsætninger:

• Opret en Conditional Access-politik, der blokerer adgang til CLI-værktøjer med undtagelse af legitime brugere, ved at målrette mod "Microsoft Graph Command Line Tools" og "Windows Azure Service Management API"
• Håndtér undtagelser via gruppemedlemskab, enten manuelt eller gennem entitlement management (f.eks. Access Packages).

Fordel:

• Forhindrer tokenudstedelse til ikke-legitime eller ikke-privilegerede brugere.
• Giver mulighed for granulær scoping ud fra yderligere betingelser som enhed eller netværk.

Ulempe:

• Alle legitime brugere af CLI-værktøjer skal identificeres og undtages.
• Sideeffekter og organisatorisk påvirkning skal vurderes grundigt ved at gennemgå tidligere sign-ins og evaluere politikken i report-only-tilstand.

Blokér tokenudstedelse via authorization code flow

Forudsætninger:

• Microsoft Entra ID P1-licenser
• Entra ID Registered Devices, hybrid- eller Entra ID-joinede enheder på Windows-platformen
• Aktivér Web Account Manager (WAM) i Azure CLI, Azure PowerShell og Microsoft Graph PowerShell (standard i de nyeste versioner)
• Konfigurér Conditional Access-målretning:
  • Cloud App-målretning mod følgende apps:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client apps under Mobile apps and desktop clients skal kræve Token Protection.
  • Vælg Windows som device platform for målretning af politikken

Fordel:

Microsoft Entras token protection kræver proof‑of‑possession (PoP), som kun kan håndhæves, når klienten kommunikerer direkte med en betroet token broker som Web Account Manager (WAM) på Windows. Fordi browsere ikke kan etablere denne sikre kanal, blokeres et authorization code flow, der er startet i en browser, under token protection-politikker.

Når politikken håndhæver token protection med krav om broker‑styret PoP, kan den authorization code, der returneres til en browser, ikke indløses, fordi browseren ikke kan producere det påkrævede broker‑signerede bevis under udvekslingen fra code til token

I dette tilfælde er angreb med AuthCodeFix fuldt mitigeret, så længe applikationen kan beskyttes med Token Protection.

Som vist på skærmbilledet nedenfor mitigerer Token Protection med succes indløsningen af det authorization code flow, som offeret har startet via en phishing-handling.

Ulempe:

• Kun følgende ressourcer er officielt understøttet:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API er indirekte dækket af de ovennævnte ressourcer, og Microsoft Graph PowerShell er anført som en understøttet klient. Vi kunne i vores test verificere, at angrebet i dette scenarie bliver mitigeret. “Windows Azure Service Management API" er ikke anført som en understøttet ressource. Begge CLI-klienter (Azure CLI og Azure PowerShell) understøtter WAM, som er et krav på klientsiden for at kunne bruge Token Protection. Microsoft har i et blogindlæg annonceret en udvidelse af token protection-funktionaliteten til Azure-managementscenarier.
• Nogle fejl i Microsoft Graph PowerShell tvinger dig til midlertidigt at deaktivere WAM-integrationen
• Sideeffekter og organisatorisk påvirkning skal vurderes grundigt ved at gennemgå tidligere sign-ins og evaluere politikken i report-only-tilstand. Cloud app-målretningen vil også påvirke den produktive adgang til Microsoft 365.
• Begrænset omfang på grund af tilgængeligheden på understøttede platforme og Entra ID-integrerede enheder.

Blokér yderligere tokenudstedelse via compliant network check eller trusted network

Mulighed: Blokér adgang uden for Compliant network med Global Secure Access

Forudsætning:

• Entra ID P1-licens
• Entra ID Registered Devices, hybrid- eller Entra ID-joinede enheder på Windows-, macOS-, Android- og iOS-platformen
• Global Secure Access Client på alle berørte klienter og aktiveret Entra Internet Access for M365 Traffic Profile
• Conditional Access-politik til at håndhæve network compliant check bør anvendes på alle cloud apps

Fordel:

Blokér yderligere tokenudstedelse ved at håndhæve en trusted network check. Denne mitigering sikrer, at angribere ikke kan hente nye tokens med refresh token fra authorization code flowet. Den forhindrer dog ikke den indledende indløsning af authorization code eller udstedelsen af det første access token, som forbliver gyldigt uden for det compliant netværk, fordi det oprindeligt blev anmodet af offeret.

At håndhæve GSA med Compliant Network-betingelsen blokerer også andre Token Replay-scenarier og tilføjer yderligere logs, som kan være meget nyttige til detektioner og hunting.

Ulempe:

• Kun anvendeligt for brugere og enheder med udrullet Global Secure Access-klient
• Begrænset omfang på grund af tilgængeligheden på Entra ID-integrerede enheder
• Håndhævelse af Compliant Networks via CA kræver nogle undtagelser som Intune for at undgå hønen-og-ægget-problemer. Grundig test er nødvendig før udrulning

Hunting-forespørgsler

Når alle forudsætninger for mitigering af tokentyveri er på plads, herunder udrulning af GSA-klienten (inklusive ingestion af NetworkAccessTraffic-logs) og udnyttelse af WAM-authentication, får vi yderligere muligheder for threat hunting og verifikation.

Brug af GSA-logs og WAM-authentication til hunting eller til at verificere konfidensen i detektionsresultater

Denne hunting-forespørgsel bruger NetworkAccessTraffic-logs fra Global Secure Access (GSA), som indeholder den initierende proces for kommunikationen med Microsoft Entras token endpoint. Det hjælper med at afgøre, om en tokenanmodning kom direkte fra en browser, og om der blev foretaget yderligere tokenanmodninger uden for GSA-netværket.

Denne forespørgsel virker og leverer kun pålidelige resultater, når forudsætningerne er opfyldt. Ellers fører den til en høj false-positive-rate.

Hvorfor det betyder noget: Når man logger ind via CLI eller PowerShell-moduler med Web Account Manager (WAM) på Windows-enheder, involverer flowet ikke en browserbaseret authorization code. Denne sign-in-adfærd er standard i den nyeste version. Hvis den initierende proces er en browser-eksekverbar (f.eks. msedge.exe), er det derfor en stærk indikator på mistænkelig aktivitet. På macOS initieres processen af Company Portal-appen (com.microsoft.CompanyPortalMac.ssoextension), når Platform SSO anvendes.

Token Binding og PoP: WAM-authentication binder typisk tokens til enheden ved at håndhæve Proof-of-Possession (PoP). Angribere kan ikke udstede yderligere bundne tokens uden PoP, så et ubundet refresh token er endnu en stærk indikator.

Begrænsninger: Alle de nævnte signaler er kun tilgængelige, når den tilgående enhed er registreret hos eller joinet til Microsoft Entra ID.

Logikken bag confidence score: Forespørgslen kombinerer flere signaler til at beregne en confidence score:

• Tilstedeværelsen af en browserproces, der initierer tokenanmodninger.
• Detektion af og nedgradering til ubundne tokens.
• Skift af netværksudbyder (inklusive fra compliant til non-compliant) mellem sign-ins.

Disse signaler kan bruges i forespørgslen til at hunte efter aktivitet eller til at udlede en confidence score i tilfælde af en hændelse på baggrund af den forudgående detektion.

Følgende scoring vises afhængigt af betingelserne:

En meget høj confidence score vises, når NetworkAccessTraffic-logs peger på en kendt browserproces som initiator af en tokenanmodning, og der er registreret en nedgradering til et ubundet token.

En høj confidence score vises, når login sker fra en anden netværksudbyder (ASN) og et non-compliant netværk med ubundne tokens involveret.

En middel confidence score vises, når der kun konstateres et skift af netværksudbyder og et compliant netværk sammen med et skift i den anvendte tokentype.

Du finder den nyeste version af hunting-forespørgslen på GitHub.

Hunting efter aktiviteter med udstedte tokens

Du bør overveje at udvide din undersøgelse ud over sign-in-hændelser, så den også omfatter aktiviteter udført med tokens udstedt af angriberen. Vores kollega Thomas Naunheim har offentliggjort en KQL-funktion ved navn MicrosoftCloudActivity, som kan hjælpe i denne udvidede hunting-proces. Derudover kan det berørte SessionId korreleres med mistænkelige UniqueId-værdier fundet under tidligere hunts til en dybere analyse.

I dette eksempel brugte angriberen det refresh token, der blev opnået under angrebet, til at udstede et access token til Microsoft Graph API. Dette token blev derefter brugt til at opretholde vedvarende adgang og lateral movement ved at tilføje en client secret til en applikation ejet af offeret. Forespørgslen giver detaljer om Graph API-operationen, herunder token protection-status og om operationen fandt sted uden for Global Secure Access-netværket.

Yderligere læsning

• 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