AuthCodeFix aka ConsentFix

Som tradisjonen tro rett før årsslutt dukker det opp en ny sårbarhet eller et smart angrepsvektor, og defenders sitter igjen og forsøker å beskytte brukerne sine. Samtidig følger andre angripere og red teamere nøye med og tilpasser seg.

I år oppdaget PushSecurity et angrep de har kalt «ConsentFix», en videreutvikling av ClickFix-angrepet som er avhengig av at brukeren gir angriperen en URI som i praksis overleverer nøkkelen til Entra-riket. Metoden som ble observert i det fri, var avhengig av at brukeren manuelt kopierte og limte inn for å virke. I løpet av få dager publiserte John Hammond en video som demonstrerte en forbedret variant av angrepet som ikke lenger krevde kopiering og innliming; i stedet kunne brukeren rett og slett dra og slippe autentiseringskoden sin til angriperen.

Når vi ser nærmere på de tekniske detaljene rundt hvorfor dette angrepet fungerer og tilsynelatende omgår enhetscompliance og andre Conditional Access-krav, havner vi midt i OAuth 2.0 authorization code flow.

Angriperen konstruerer en Microsoft Entra-innloggings-URI som retter seg mot klienten «Microsoft Azure CLI» og ressursen «Azure Resource Manager», og åpner denne URI-en når brukeren besøker det ondsinnede nettstedet.

Mappet mot authorization code flow tilsvarer dette det første steget som en native public app som Azure CLI normalt ville kalt for å autentisere brukeren. Applikasjonen oppretter en listener på maskinen den kjøres på, på en tilfeldig høy port. Denne porten brukes som en såkalt reply URI.

Du kan enkelt reprodusere dette selv, for eksempel ved å bruke TokenTacticsV2, eller ved å konstruere URI-en manuelt.

Etter at brukeren har logget inn hos Entra ID, blir vedkommende omdirigert til reply-URI-en, for eksempel http://localhost:3001. I et normalt scenario ville Azure CLI nå akseptert kallet til denne URI-en og mottatt den viktige og kritiske informasjonen som ligger i omdirigeringen:

• code
  Dette er authorization_code, som applikasjonen bruker for å be om en bearer token, bestående av access token, ID token og eventuelt refresh token.
  Ifølge dokumentasjonen er denne koden gyldig i rundt 10 minutter og må innløses innenfor dette tidsvinduet.
• state
  Dette er en valgfri parameter, og applikasjonen bør verifisere at den er identisk i forespørselen og i responsen.

I angrepsscenariet blir brukeren også omdirigert, men siden ingen applikasjon kjører på localhost, støter nettleseren på en feil.

URI-en inneholder likevel den sensitive informasjonen, og det er akkurat dette angriperen vil at brukeren skal levere. Hvis brukeren gjør det, vil angriperen innløse token-materialet og deretter kunne bruke access token og refresh token for å nå ressursen, i dette tilfellet Azure Resource Manager.

I dette skjermbildet ser du hvordan bearer token hentes ut ved hjelp av URI-en brukeren har oppgitt.

Hvis du vil teste deteksjonene dine, sørg for at du utfører det siste steget fra et annet system, i et annet nettverk.

Deteksjons-artefakter

Når du reproduserer angrepet og sjekker SigninLogs og AADNonInteractiveUserSignInLogs, vil du se to hendelser for denne ene innloggingsaktiviteten. Den første hendelsen representerer selve brukerinnloggingen, mens den andre stammer fra angriperens infrastruktur.

Den store forskjellen er at den første hendelsen er en interaktiv innloggingshendelse, mens den andre er ikke-interaktiv. Dette speiler de to trinnene i autentiseringsflyten: først brukeren, deretter applikasjonen, eller i vårt tilfelle angriperen.

Normal oppførsel for Azure CLI ville vært at begge sign-in-hendelsene stammer fra samme IP-adresse. I vårt tilfelle er IP-adressene derimot forskjellige, og de kommer fra ulike land. Sistnevnte er selvsagt ikke en pålitelig indikator, ettersom angriperen kan oppholde seg i samme land som offeret for å skjule sporene sine.

Missing link

Da vi lette etter en god måte å koble sammen disse to hendelsene, var den naturlige første tanken å sjekke Unique Token Identifier (UTI). Microsoft bruker imidlertid ulike verdier for authorization code-UTI og bearer token-UTI, så denne fremgangsmåten fungerer ikke som en pålitelig kobling.

SessionId er derimot en god kobling mellom de to, selv om det er en langlevende ID som kan inneholde flere slike hendelseskombinasjoner, også legitime.

Med tilleggskunnskap om begrensningene i auth code flow, samt bruker- og applikasjons-ID som ytterligere koblinger, kan du bruke tid som en viktig deteksjonsfaktor:

• Begge hendelsene deler samme SessionId
• Begge hendelsene deler samme ApplicationId
• Begge hendelsene deler samme UserId
• Den andre hendelsen må komme etter den første
• Den andre hendelsen må skje innenfor et tidsvindu på omtrent 10 minutter etter den første. Du bør ikke bruke nøyaktig 10 minutter, siden Microsoft skriver «[...] they expire after about 10 minutes»
• Du bør kun ta hensyn til den aller neste hendelsen nummer to, ikke etterfølgende hendelser

Fun fact
ResourceIdentity er ikke en god kobling, ettersom angriperen kan endre ressursen siden den ikke er bundet til auth code. Den målrettede applikasjons-ID-en kan ikke endres.

Reduser støyen

Denne kunnskapen ga oss allerede en god fungerende deteksjon, men det var også godartede positive treff i miksen. Moderne utviklere bruker skyressurser som ser ut som lokale instanser, men som gir uregelmessige innloggingsmønstre i loggene.

Den avgjørende forskjellen er tidskomponenten. Mens angrepet krever brukerinteraksjon for å kopiere og lime inn eller dra og slippe URI-en, er GitHub Codespace-bruksscenarioet vi identifiserte som kilde til de godartede positive varslene, helt automatisert og innløser auth code i løpet av få sekunder.

Å filtrere bort alt som gjennomfører denne autentiseringsdansen i løpet av noen få sekunder, kan derfor med stor sannsynlighet fjernes som godartet.

En annen støykilde kan være skiftende egress-punkter for internettrafikken din, spesielt i SD-WAN-, ZTNA- eller Secure Web Gateway-scenarier.

Berørte first-party-applikasjoner

Selv om den opprinnelige rapporten viser «Microsoft Azure CLI» som den misbrukte applikasjonen, finnes det en rekke ulike Microsoft first-party-apper med pre-consent i hver tenant som tilbyr localhost som redirect. Og det er ikke bare disse som er mål. Angriperen kan også misbruke reply-, test- og dev-URL-er som ikke er offentlig oppløsbare.

Her er en liste over de mest bemerkelsesverdige applikasjonene som også har høye pre-consented tillatelser til ressurser.

• 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 fullstendig liste over disse appene er nå inkludert i EntraScopes.com av kollegaen vår Fabian Bader.

Tiltak og beskyttelse

Begrens angrepsflaten og målgruppen

Alternativ 1: Krev User Assignment

Forutsetninger:

• Legg til service principal for berørte first-party-apper ved hjelp av Microsoft Graph API eller PowerShell
• Aktiver user assignment-kravet på service principal-objektet via Microsoft Graph API eller PowerShell
• Etabler en prosess for å tildele brukere ved forespørsel, via Access Packages, PIM-for-Groups (for just-in-time-tilgang), eller en kombinasjon av 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:

• Muliggjør styring av brukertildelinger gjennom Access Packages eller manuelt gruppemedlemskap for å begrense eksponeringen mot denne angrepsteknikken.
• Mulighet til å tilby just-in-time-tilgang kombinert med tildeling av eligible gruppemedlemskap, som gir midlertidig tilgang til CLI-verktøy og dermed reduserer angrepsflaten ytterligere.
• Anvendes før Conditional Access-policyer evalueres.
• Begrenser angrepsflaten også i andre scenarier.

Ulempe:

• Kan kun avgrenses til spesifikke brukere og kan ikke kombineres med andre krav som bruk av bestemte enheter
• Alle legitime CLI-brukere må identifiseres
• Sideeffekter og organisatorisk påvirkning må vurderes nøye ved å gjennomgå tidligere sign-ins.

Alternativ 2: Blokker tilgang ved hjelp av Conditional Access-policyer

Forutsetninger:

• Opprett en Conditional Access-policy som blokkerer tilgang til CLI-verktøy, med unntak for legitime brukere, ved å målrette «Microsoft Graph Command Line Tools» og «Windows Azure Service Management API»
• Administrer unntak via gruppemedlemskap, enten manuelt eller gjennom entitlement management (for eksempel Access Packages).

Fordel:

• Forhindrer tokenutstedelse for ikke-legitime eller ikke-privilegerte brukere.
• Muliggjør granulær avgrensning basert på tilleggsbetingelser som enhet eller nettverk.

Ulempe:

• Alle legitime CLI-brukere må identifiseres og ekskluderes.
• Sideeffekter og organisatorisk påvirkning må vurderes nøye ved å gjennomgå tidligere sign-ins og evaluere policyen i report-only-modus.

Blokker tokenutstedelse via authorization code flow

Forutsetninger:

• Microsoft Entra ID P1-lisenser
• Entra ID Registered Devices, Hybrid- eller Entra ID-joined-enheter på Windows-plattformen
• Aktiver Web Account Manager (WAM) i Azure CLI, Azure PowerShell og Microsoft Graph PowerShell (standard i nyeste versjoner)
• Konfigurer Conditional Access som retter seg mot:
  • Cloud App targeting mot følgende apper:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client apps under Mobile apps and desktop clients for å kreve Token Protection.
  • Velg Windows som device platform for målrettingen av policyen

Fordel:

Token protection i Microsoft Entra krever proof-of-possession (PoP), som kun kan håndheves når klienten kommuniserer direkte med en tiltrodd token broker som Web Account Manager (WAM) på Windows. Fordi nettlesere ikke kan etablere denne sikre kanalen, blir authorization code flow som initieres i en nettleser blokkert under token protection-policyer.

Når policyen håndhever token protection som krever broker-styrt PoP, kan ikke authorization code som returneres til en nettleser, innløses, ettersom nettleseren ikke kan produsere den nødvendige broker-signerte bekreftelsen under vekslingen fra code til token.

I dette tilfellet vil angrep med AuthCodeFix være fullstendig avverget, så lenge applikasjonen kan beskyttes av Token Protection.

Som vist i skjermbildet under, hindrer Token Protection innløsingen av authorization code flow som initieres av offeret gjennom en phishing-handling.

Ulempe:

• Kun følgende ressurser er offisielt støttet:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API er indirekte dekket av de nevnte ressursene, og Microsoft Graph PowerShell er listet som en støttet klient. Vi kunne i testingen vår verifisere at angrepet blir avverget i dette scenariet. «Windows Azure Service Management API» er ikke oppført som støttet ressurs. Begge CLI-klientene (Azure CLI og Azure PowerShell) støtter WAM, som er et klientside-krav for å bruke Token Protection. Microsoft har annonsert i et blogginnlegg at token protection-funksjonaliteten skal utvides til Azure management-scenarier.
• Enkelte bugs i Microsoft Graph PowerShell tvinger deg til midlertidig å deaktivere WAM-integrasjonen
• Sideeffekter og organisatorisk påvirkning må vurderes nøye ved å gjennomgå tidligere sign-ins og evaluere policyen i report-only-modus. Cloud app targeting vil også påvirke produktivitetstilgang til Microsoft 365.
• Begrenset omfang på grunn av tilgjengelighet på støttede plattformer og Entra ID-integrerte enheter.

Blokker videre tokenutstedelse via compliant network-sjekk eller trusted network

Alternativ: Blokker tilgang utenfor Compliant network med Global Secure Access

Forutsetning:

• Entra ID P1-lisens
• Entra ID Registered Devices, Hybrid- eller Entra ID-joined-enheter på Windows-, macOS-, Android- og iOS-plattformer
• Global Secure Access-klient på alle berørte klienter og aktivert Entra Internet Access for M365 Traffic Profile
• Conditional Access-policy for å håndheve network compliant-sjekken skal gjelde alle cloud apps

Fordel:

Blokker ytterligere tokenutstedelse ved å håndheve en trusted network-sjekk. Dette tiltaket sørger for at angripere ikke kan hente nye tokens ved hjelp av refresh token fra authorization code flow. Det forhindrer imidlertid ikke den opprinnelige innløsingen av authorization code eller utstedelsen av det første access token, som forblir gyldig utenfor compliant network fordi det opprinnelig ble bedt om av offeret.

Å håndheve GSA med Compliant Network-betingelsen blokkerer også andre Token Replay-scenarier og gir ekstra logger som kan være svært nyttige for deteksjon og hunting.

Ulempe:

• Gjelder kun for brukere og enheter som har Global Secure Access-klienten utplassert
• Begrenset omfang på grunn av tilgjengelighet på Entra ID-integrerte enheter
• Håndheving av Compliant Networks via CA vil kreve enkelte unntak, som Intune, for å unngå høna-og-egget-problemer. Grundig testing er nødvendig før utrulling

Hunting-spørringer

Når alle forutsetningene for token theft-tiltak er på plass, som utplassering av GSA-klienten (inkludert innhenting av NetworkAccessTraffic-logger) og bruk av WAM-autentisering, får vi flere muligheter for threat hunting og verifisering.

Bruk av GSA-logger og WAM-autentisering til hunting eller verifisering av deteksjonstillit

Denne hunting-spørringen benytter NetworkAccessTraffic-logger fra Global Secure Access (GSA), som inkluderer den initierende prosessen for kommunikasjon med Microsoft Entra-tokenendepunktet. Dette gjør det mulig å avgjøre om en tokenforespørsel kommer direkte fra en nettleser, og om det er gjort ytterligere tokenforespørsler utenfor GSA-nettverket.

Denne spørringen fungerer og gir pålitelige resultater kun når forutsetningene er oppfylt; ellers gir den høy falsk-positiv-rate.

Hvorfor dette er viktig: Ved innlogging via CLI eller PowerShell-moduler med Web Account Manager (WAM) på Windows-enheter, involverer flyten ingen nettleserbasert authorization code. Denne sign-in-oppførselen er standard i den nyeste versjonen. Hvis den initierende prosessen er en nettleser-executable (for eksempel msedge.exe), er dette en sterk indikator på mistenkelig aktivitet. På macOS initieres prosessen av Company Portal-appen (com.microsoft.CompanyPortalMac.ssoextension) når Platform SSO brukes.

Token Binding og PoP: WAM-autentisering binder normalt tokens til enheten ved å håndheve Proof-of-Possession (PoP). Angripere kan ikke utstede ytterligere bundne tokens uten PoP, så et ubundet refresh token er en annen sterk indikator.

Begrensninger: Alle de nevnte signalene er kun tilgjengelige når enheten som logger på er registrert hos eller joined til Microsoft Entra ID.

Logikk for konfidensskår: Spørringen kombinerer flere signaler for å beregne en konfidensskår:

• Tilstedeværelse av en nettleserprosess som initierer tokenforespørsler.
• Deteksjon av og nedgradering til ubundne tokens.
• Endringer i nettverksleverandør (inkludert Compliant til non-compliant) mellom sign-ins.

Disse signalene kan brukes i spørringen til å jakte på aktivitet, eller til å utlede en konfidensskår i en hendelse basert på tidligere deteksjon.

Følgende skår vises avhengig av betingelsene:

En svært høy konfidensskår vises når NetworkAccessTraffic-logger indikerer en kjent nettleserprosess i stedet for initiering av en tokenforespørsel, og en nedgradering av et ubundet token er oppdaget.

En høy konfidensskår vises når sign-in skjer fra en annen Network Provider (ASN) og et non-compliant network som involverer ubundne tokens.

En middels konfidensskår vises når kun en endring i Network Provider og compliant network identifiseres, sammen med en endring i typen token som er brukt.

Du finner den siste versjonen av hunting-spørringen på GitHub.

Jakt etter aktivitet via utstedte tokens

Du bør vurdere å utvide undersøkelsen din utover sign-in-hendelser til også å omfatte aktivitet utført med tokens utstedt av angriperen. Kollegaen vår Thomas Naunheim har publisert en KQL-funksjon kalt MicrosoftCloudActivity, som kan bistå i denne utvidede hunting-prosessen. I tillegg kan berørt SessionId korreleres med mistenkelige UniqueId-verdier identifisert under tidligere hunts for dypere analyse.

I dette eksempelet brukte angriperen refresh token som ble hentet under angrepet, til å utstede et access token for Microsoft Graph API. Dette tokenet ble deretter brukt til å opprettholde vedvarende tilgang og lateral movement ved å legge til en client secret på en applikasjon eid av offeret. Spørringen gir detaljer om Graph API-operasjonen, inkludert token protection-status og om operasjonen skjedde utenfor Global Secure Access-nettverket.

Videre lesing

• 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