AuthCodeFix aka ConsentFix

Som traditionen bjuder strax före årets slut dyker en ny sårbarhet eller smart attackvektor upp, och försvararna får kämpa med att skydda sina användare. Samtidigt följer andra angripare och red teamers noga med och anpassar sig.

I år upptäckte PushSecurity en attack som de döpte till "ConsentFix", en vidareutveckling av ClickFix-attacken som bygger på att användaren förser angriparen med en URI som i princip lämnar över nyckeln till hela Entra-kungariket. Metoden som setts i verkligheten krävde att användaren manuellt kopierade och klistrade in för att fungera. Inom några dagar släppte John Hammond en video som visade en förbättrad version av attacken som inte längre krävde kopiering och inklistring; i stället kunde användaren helt enkelt dra och släppa sin auth code till angriparen.

När vi tittar närmare på de tekniska detaljerna bakom varför attacken fungerar och till synes kringgår device compliance och andra Conditional Access-krav, hamnar vi i OAuth 2.0 authorization code flow.

Angriparen skapar en Microsoft Entra-inloggnings-URI som riktar in sig på klienten "Microsoft Azure CLI" och resursen "Azure Resource Manager", och öppnar denna URI när användaren besöker den skadliga webbplatsen.

Mappat mot authorization code flow motsvarar detta det första steget som en native public app som Azure CLI normalt anropar för att autentisera användaren. Applikationen skapar en listener på maskinen där den körs, på en slumpmässig hög port. Denna port används som en så kallad reply URI.

Du kan enkelt reproducera detta själv, till exempel med TokenTacticsV2, eller genom att skapa URI:n manuellt.

Efter att användaren har loggat in i Entra ID omdirigeras hen till reply URI:n, t.ex. http://localhost:3001. I ett normalt scenario skulle Azure CLI nu acceptera anropet till denna URI och ta emot den viktiga och kritiska information som ingår i omdirigeringen:

• code
  Detta är authorization_code som applikationen använder för att begära en bearer token, som består av access-, ID- och eventuellt refresh-token.
  Enligt dokumentationen är koden giltig i ungefär 10 minuter och måste lösas in inom denna tid.
• state
  Detta är en valfri parameter, och applikationen bör verifiera att den är identisk i förfrågan och svaret.

I attackscenariot omdirigeras användaren också, men eftersom ingen applikation körs på localhost stöter webbläsaren på ett fel.

Men URI:n innehåller fortfarande den känsliga informationen, och det är detta som angriparen vill att användaren ska lämna över. Om användaren gör det löser angriparen nu in token-materialet och kan sedan använda access- och refresh-token för att komma åt resursen, i detta fall Azure Resource Manager.

I den här skärmbilden ser du hur du hämtar bearer token med hjälp av URI:n som användaren tillhandahåller.

Om du vill testa dina detektioner, se till att du kör det sista steget från ett annat system, i ett annat nätverk.

Detektionsartefakter

När du reproducerar attacken och kontrollerar SigninLogs och AADNonInteractiveUserSignInLogs ser du två händelser för denna enda inloggningsaktivitet. Den första händelsen representerar den faktiska användarinloggningen, medan den andra kommer från angriparens infrastruktur.

Den stora skillnaden är att den första händelsen är en interaktiv inloggningshändelse, medan den andra är icke-interaktiv. Detta motsvarar autentiseringsflödets två steg: först användaren, sedan applikationen eller i vårt fall angriparen.

Normalt beteende för Azure CLI vore att båda inloggningshändelserna kommer från samma IP-adress. I vårt fall är IP-adresserna dock olika, och de kommer från olika länder. Det senare är förstås ingen tillförlitlig indikator, eftersom angriparen kan befinna sig i samma land som offret för att dölja sina spår.

Den saknade länken

När vi letade efter ett bra sätt att koppla ihop de två händelserna var den naturliga första tanken att kontrollera Unique Token Identifier (UTI). Microsoft använder dock olika värden för authorization code-UTI och bearer token-UTI, så den metoden fungerar inte som en tillförlitlig länk.

Däremot är SessionId en bra länk mellan de två, även om det är ett långlivat ID som kan innehålla flera sådana händelsekombinationer, även legitima.

Med ytterligare kännedom om begränsningarna i auth code flow och med användar- och applikations-ID som ytterligare länkar kan du använda tid som en viktig detektionsfaktor:

• Båda händelserna delar samma SessionId
• Båda händelserna delar samma ApplicationId
• Båda händelserna delar samma UserId
• Den andra händelsen måste inträffa efter den första
• Den andra händelsen måste inträffa inom ungefär ett 10-minutersfönster efter den första. Du bör inte använda exakt 10 minuter eftersom Microsoft skriver "[...] they expire after about 10 minutes"
• Du bör endast beakta den allra närmaste andra händelsen, inte efterföljande

Kul fakta
ResourceIdentity är ingen bra länk, eftersom angriparen kan byta resurs då den inte är bunden till auth code. Det riktade applikations-ID:t kan inte ändras.

Minska bruset

Denna kunskap gav oss redan en fungerande detektion, men det fanns även godartade träffar i mixen. Moderna utvecklare använder molnresurser som ser ut som lokala instanser, men som ger upphov till oregelbundna inloggningsmönster i loggarna.

Den avgörande skillnaden är tidskomponenten. Medan attacken kräver att användaren kopierar och klistrar in eller drar och släpper URI:n, är det GitHub Codespace-scenario som vi identifierade som källa till de godartade larmen helt automatiserat och löser in auth code inom bara några sekunder.

Så allt som genomför denna autentiseringsdans inom några sekunder kan med stor sannolikhet filtreras bort som godartat.

En annan källa till brus kan vara växlande egress-punkter för din internettrafik, särskilt i SD-WAN-, ZTNA- eller Secure Web Gateway-scenarier.

Berörda first-party-applikationer

Även om den ursprungliga rapporten visar "Microsoft Azure CLI" som den missbrukade applikationen finns det många olika Microsoft first-party-appar med pre-consent i varje tenant som erbjuder localhost som redirect. Och det är inte bara dessa som är måltavlor. Angriparen kan även missbruka test- och dev-URL:er för reply som inte går att slå upp publikt.

Här är en lista över de mest anmärkningsvärda applikationerna som dessutom har höga pre-consentade behörigheter på resurser.

• 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 fullständig lista över dessa appar finns nu med i EntraScopes.com tack vare vår kollega Fabian Bader.

Åtgärder och skydd

Begränsa attackytan och målgruppen

Alternativ 1: Kräv User Assignment

Förutsättningar:

• Lägg till service principal för berörda first-party-appar med Microsoft Graph API eller PowerShell
• Tillämpa kravet på user assignment på service principal-objektet med Microsoft Graph API eller PowerShell
• Etablera en process för att tilldela användare på begäran via Access Packages, PIM-for-Groups (för just-in-time-åtkomst) eller en kombination av båda.

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

Fördel:

• Möjliggör hantering av user assignments via Access Packages eller manuellt gruppmedlemskap för att begränsa exponeringen för denna attackteknik.
• Möjlighet att erbjuda just-in-time-åtkomst i kombination med eligible gruppmedlemskap, vilket ger tillfällig åtkomst till CLI-verktyg och därmed ytterligare minskar attackytan.
• Tillämpas innan Conditional Access-policyer utvärderas.
• Begränsar attackytan även för andra scenarier.

Nackdel:

• Kan endast riktas mot specifika användare och inte kombineras med andra krav som användning av specifika enheter
• Alla legitima användare av CLI-verktyg måste identifieras
• Sidoeffekter och organisatorisk påverkan måste bedömas noggrant genom att granska tidigare inloggningar.

Alternativ 2: Blockera åtkomst med Conditional Access-policyer

Förutsättningar:

• Skapa en Conditional Access-policy för att blockera åtkomst till CLI-verktyg, med undantag för legitima användare, genom att rikta in dig på "Microsoft Graph Command Line Tools" och "Windows Azure Service Management API"
• Hantera undantag via gruppmedlemskap, antingen manuellt eller genom entitlement management (t.ex. Access Packages).

Fördel:

• Förhindrar utfärdande av token för icke-legitima eller icke-privilegierade användare.
• Möjliggör granulär inriktning baserat på ytterligare villkor som enhet eller nätverk.

Nackdel:

• Alla legitima användare av CLI-verktyg måste identifieras och undantas.
• Sidoeffekter och organisatorisk påverkan måste bedömas noggrant genom att granska tidigare inloggningar och utvärdera policyn i report-only-läge.

Blockera utfärdande av token via authorization code flow

Förutsättningar:

• Microsoft Entra ID P1-licenser
• Entra ID Registered Devices, Hybrid- eller Entra ID-joined enheter på Windows-plattformen
• Aktivera Web Account Manager (WAM) i Azure CLI, Azure PowerShell och Microsoft Graph PowerShell (standard i de senaste versionerna)
• Konfigurera Conditional Access-inriktning:
  • Cloud App-inriktning mot följande appar:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client apps under Mobile apps and desktop clients för att kräva Token Protection.
  • Välj Windows som device platform för att rikta policyn

Fördel:

Microsoft Entras token protection kräver proof-of-possession (PoP), vilket endast kan framtvingas när klienten kommunicerar direkt med en betrodd token broker som Web Account Manager (WAM) på Windows. Eftersom webbläsare inte kan upprätta denna säkra kanal blockeras authorization code flow som initieras i en webbläsare under token protection-policyer.

När policyn framtvingar token protection som kräver broker-hanterad PoP kan authorization code som returneras till en webbläsare inte lösas in, eftersom webbläsaren inte kan producera det broker-signerade bevis som krävs under utbytet av code mot token

I detta fall åtgärdas attacker med AuthCodeFix fullständigt så länge applikationen kan skyddas av Token Protection.

Som visas i skärmbilden nedan blockerar Token Protection framgångsrikt inlösen av authorization code flow som offret initierat genom en phishing-åtgärd.

Nackdel:

• Endast följande resurser stöds officiellt:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API täcks indirekt av de tidigare nämnda resurserna och Microsoft Graph PowerShell listas som en klient som stöds. Vi kunde i våra tester verifiera att attacken i detta scenario åtgärdas. "Windows Azure Service Management API" listas inte som en resurs som stöds. Båda CLI-klienterna (Azure CLI och Azure PowerShell) stöder WAM, vilket är ett krav på klientsidan för att använda Token Protection. Microsoft har i ett blogginlägg aviserat att utöka token protection-funktionerna för Azure management-scenarier.
• Vissa buggar i Microsoft Graph PowerShell tvingar dig att tillfälligt inaktivera WAM-integrationen
• Sidoeffekter och organisatorisk påverkan måste bedömas noggrant genom att granska tidigare inloggningar och utvärdera policyn i report-only-läge. Cloud app-inriktningen påverkar även produktivitetsåtkomsten till Microsoft 365.
• Begränsad omfattning på grund av tillgänglighet på plattformar som stöds och Entra ID-integrerade enheter.

Blockera ytterligare utfärdande av token via compliant network-kontroll eller betrott nätverk

Alternativ: Blockera åtkomst utanför Compliant network med Global Secure Access

Förutsättning:

• Entra ID P1-licens
• Entra ID Registered Devices, Hybrid- eller Entra ID-joined enheter på Windows-, macOS-, Android- och iOS-plattformen
• Global Secure Access Client på alla berörda klienter och aktiverad Entra Internet Access för M365 Traffic Profile
• En Conditional Access-policy för att framtvinga network compliant-kontroll bör tillämpas på alla cloud apps

Fördel:

Blockera ytterligare utfärdande av token genom att framtvinga en kontroll av betrott nätverk. Denna åtgärd säkerställer att angripare inte kan få nya token med hjälp av refresh token från authorization code flow. Den förhindrar dock inte den initiala inlösen av authorization code eller utfärdandet av den första access token, som förblir giltig utanför compliant network eftersom den ursprungligen begärdes av offret.

Att framtvinga GSA med villkoret Compliant Network blockerar även andra Token Replay-scenarier och lägger till ytterligare loggar som kan vara mycket användbara för detektioner och hunting.

Nackdel:

• Gäller endast användare och enheter med utrullad Global Secure Access-klient
• Begränsad omfattning på grund av tillgänglighet på Entra ID-integrerade enheter
• Att framtvinga Compliant Networks via CA kräver vissa undantag som Intune för att undvika hönan-och-ägget-problem. Noggrann testning behövs innan utrullning

Hunting-queries

När alla förutsättningar för att åtgärda token-stöld är uppfyllda, som att rulla ut GSA-klienten (inklusive insamling av NetworkAccessTraffic-loggar) och dra nytta av WAM-autentisering, får vi ytterligare möjligheter för threat hunting och verifiering.

Använda GSA-loggar och WAM-autentisering för hunting eller för att verifiera säkerheten i detektionsresultat

Denna hunting-query utnyttjar NetworkAccessTraffic-loggar från Global Secure Access (GSA), som innehåller den initierande processen för kommunikation med Microsoft Entra token endpoint. Detta hjälper till att avgöra om en token-begäran kom direkt från en webbläsare och även om några ytterligare token-begäranden gjordes utanför GSA-nätverket.

Denna query fungerar och ger tillförlitliga resultat endast när förutsättningarna är uppfyllda; i annat fall leder den till en hög andel falska positiva.

Varför detta är viktigt: Vid inloggning via CLI- eller PowerShell-moduler med Web Account Manager (WAM) på Windows-enheter involverar flödet ingen webbläsarbaserad authorization code. Detta inloggningsbeteende är standard i den senaste versionen. Om den initierande processen är en webbläsar-körbar fil (t.ex. msedge.exe) är detta därför en stark indikator på misstänkt aktivitet. På macOS initieras processen av appen Company Portal (com.microsoft.CompanyPortalMac.ssoextension) vid användning av Platform SSO.

Token Binding och PoP: WAM-autentisering binder vanligtvis token till enheten genom att framtvinga Proof-of-Possession (PoP). Angripare kan inte utfärda ytterligare bundna token utan PoP, så en obunden refresh token är ännu en stark indikator.

Begränsningar: Alla nämnda signaler är endast tillgängliga när den enhet som ansluter är registrerad i eller joined till Microsoft Entra ID.

Logik för confidence score: Queryn kombinerar flera signaler för att beräkna en confidence score:

• Förekomst av en webbläsarprocess som initierar token-begäranden.
• Detektion av och nedgradering till obundna token.
• Byten av nätverksleverantör (inklusive från compliant till non-compliant) mellan inloggningar.

Dessa signaler kan användas i queryn för att jaga aktivitet eller för att härleda en confidence score i händelse av en incident, baserat på den tidigare detektionen.

Följande poängsättning visas beroende på villkoren:

En mycket hög confidence score visas när NetworkAccessTraffic-loggar indikerar en välkänd webbläsarprocess i stället för att initiera en token-begäran, och en nedgradering av en obunden token har upptäckts.

En hög confidence score visas när inloggningen sker från en annan nätverksleverantör (ASN) och ett non-compliant-nätverk som involverar obundna token.

En medelhög confidence score visas när endast ett byte av nätverksleverantör och compliant network identifieras, tillsammans med en förändring i vilken token-typ som används.

Du hittar den senaste versionen av hunting-queryn på GitHub.

Jaga aktiviteter utförda med utfärdade token

Du bör överväga att utöka din undersökning bortom inloggningshändelser till att omfatta aktiviteter som utförts med token utfärdade av angriparen. Vår kollega Thomas Naunheim har publicerat en KQL-funktion vid namn MicrosoftCloudActivity, som kan hjälpa till i denna utökade hunting-process. Dessutom kan det berörda SessionId korreleras med misstänkta UniqueId-värden som identifierats under tidigare jakter för djupare analys.

I det här exemplet använde angriparen den refresh token som erhölls under attacken för att utfärda en access token för Microsoft Graph API. Denna token användes sedan för att upprätthålla persistent åtkomst och lateral movement genom att lägga till en client secret på en applikation som ägdes av offret. Queryn ger detaljer om Graph API-operationen, inklusive statusen för token protection och om operationen skedde utanför Global Secure Access-nätverket.

Vidare 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