Az - Conditional Access Policies & MFA Bypass
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
Azure Voorwaardelike Toegang beleide is reëls wat in Microsoft Azure opgestel is om toegangbeheer na Azure dienste en toepassings af te dwing op grond van sekere voorwaardes. Hierdie beleide help organisasies om hul hulpbronne te beveilig deur die regte toegangbeheer onder die regte omstandighede toe te pas. Voorwaardelike toegang beleide definieer basies Wie kan toegang hê tot Wat van Waar en Hoe.
Hier is 'n paar voorbeelde:
Aanmeld Risiko Beleid: Hierdie beleid kan ingestel word om multi-faktor verifikasie (MFA) te vereis wanneer 'n aanmeld risiko opgespoor word. Byvoorbeeld, as 'n gebruiker se aanmeld gedrag ongewoon is in vergelyking met hul gereelde patroon, soos om van 'n ander land aan te meld, kan die stelsel vra vir addisionele verifikasie.
Toestel Nakoming Beleid: Hierdie beleid kan toegang tot Azure dienste beperk slegs tot toestelle wat voldoen aan die organisasie se sekuriteitsstandaarde. Byvoorbeeld, toegang kan slegs toegestaan word vanaf toestelle wat opdatering antivirus sagteware het of 'n sekere bedryfstelsel weergawe gebruik.
Dit is moontlik dat 'n voorwaardelike toegang beleid sekere inligting nagaan wat maklik gemanipuleer kan word, wat 'n omseiling van die beleid moontlik maak. En as die beleid byvoorbeeld MFA geconfigureer het, sal die aanvaller in staat wees om dit te omseil.
Wanneer 'n voorwaardelike toegang beleid geconfigureer word, is dit nodig om die gebruikers wat geraak word en teiken hulpbronne (soos alle wolk toepassings) aan te dui.
Dit is ook nodig om die voorwaardes te configureer wat die beleid sal aktiveer:
Netwerk: IP, IP-reekse en geografiese liggings
Kan omseil word deur 'n VPN of Proxy te gebruik om met 'n land te verbind of te probeer om vanaf 'n toegelate IP-adres aan te meld
Microsoft risiko's: Gebruiker risiko, Aanmeld risiko, Insider risiko
Toestel platforms: Enige toestel of kies Android, iOS, Windows phone, Windows, macOS, Linux
As “Enige toestel” nie gekies is nie, maar al die ander opsies gekies is, is dit moontlik om dit te omseil deur 'n ewekansige gebruikersagent te gebruik wat nie met daardie platforms verband hou nie
Kliënt toepassings: Opsies is “Blaaier”, “Mobiele toepassings en desktop kliënte”, “Exchange ActiveSync kliënte” en Ander kliënte”
Om aanmelding te omseil met 'n nie-geselecteerde opsie
Filter vir toestelle: Dit is moontlik om 'n reël te genereer wat verband hou met die gebruikte toestel
Verifikasie vloei: Opsies is “Toestel kode vloei” en “Verifikasie oordrag”
Dit sal nie 'n aanvaller beïnvloed nie, tensy hy probeer om enige van daardie protokolle in 'n phishing poging te misbruik om toegang tot die slagoffer se rekening te verkry
Die moontlike resultate is: Blokkeer of Gee toegang met potensiële voorwaardes soos vereis MFA, toestel moet nakom…
Dit is moontlik om 'n voorwaarde in te stel gebaseer op die toestel platform (Android, iOS, Windows, macOS...), egter, dit is gebaseer op die gebruikersagent so dit is maklik om te omseil. Selfs om al die opsies MFA af te dwing, as jy 'n gebruikersagent gebruik wat nie erken word nie, sal jy in staat wees om die MFA of blok te omseil:
Net om die blaaier 'n onbekende gebruikersagent te laat stuur (soos Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile) is genoeg om hierdie voorwaarde nie te aktiveer nie.
Jy kan die gebruikersagent handmatig in die ontwikkelaar gereedskap verander:
Of gebruik 'n blaaier uitbreiding soos hierdie een.
As dit in die voorwaardelike beleid ingestel is, kan 'n aanvaller net 'n VPN in die toegelate land gebruik of probeer om 'n manier te vind om vanaf 'n toegelate IP-adres toegang te verkry om hierdie voorwaardes te omseil.
Dit is moontlik om voorwaardelike toegang beleide te configureer om te blokkeer of te dwing byvoorbeeld MFA wanneer 'n gebruiker probeer om toegang te verkry tot 'n spesifieke toepassing:
Om te probeer om hierdie beskerming te omseil, moet jy kyk of jy slegs in enige toepassing kan aanmeld. Die hulpmiddel AzureAppsSweep het tens of toepassings-ID's hardcoded en sal probeer om in hulle aan te meld en jou laat weet en selfs die token gee as dit suksesvol is.
Om spesifieke toepassings-ID's in spesifieke hulpbronne te toets, kan jy ook 'n hulpmiddel soos gebruik:
Boonop is dit ook moontlik om die aanmeldmetode te beskerm (bv. as jy probeer aanmeld vanaf die blaaiers of vanaf 'n desktoptoepassing). Die hulpmiddel Invoke-MFASweep voer 'n paar kontroles uit om te probeer om hierdie beskermings te omseil.
Die hulpmiddel donkeytoken kan ook vir soortgelyke doeleindes gebruik word, alhoewel dit ononderhoude lyk.
Die hulpmiddel ROPCI kan ook gebruik word om hierdie beskermings te toets en te sien of dit moontlik is om MFAs of blokke te omseil, maar hierdie hulpmiddel werk vanuit 'n whitebox perspektief. Jy moet eers die lys van toepassings wat in die tenant toegelaat is aflaai en dan sal dit probeer om in hulle aan te meld.
Een Azure MFA opsie is om 'n oproep te ontvang op die geconfigureerde telefoonnommer waar die gebruiker gevra sal word om die karakter # te stuur.
Aangesien karakters net tones is, kan 'n aanvaller die stempos boodskap van die telefoonnommer kompromitteer, die boodskap as die toon van # konfigureer en dan, wanneer die MFA aangevra word, seker maak dat die slagoffer se telefoon besig is (dit bel) sodat die Azure oproep na die stempos omgeleid word.
Beleide vra dikwels vir 'n nakomingstoestel of MFA, so 'n aanvaller kan 'n nakomingstoestel registreer, 'n PRT token kry en op hierdie manier die MFA omseil.
Begin deur 'n nakomingstoestel in Intune te registreer, dan kry die PRT met:
Vind meer inligting oor hierdie tipe aanval op die volgende bladsy:
Az - Pass the PRTHierdie skrip verkry 'n paar gebruikersakkrediteer en kyk of dit kan aanmeld in 'n paar toepassings.
Dit is nuttig om te sien of jy nie MFA benodig om aan te meld in 'n paar toepassings nie wat jy later mag misbruik om privileges te verhoog.
Kry al die beleide
MFASweep is 'n PowerShell-skrip wat probeer om in te teken op verskeie Microsoft-dienste met 'n verskafde stel geloofsbriewe en sal probeer om te identifiseer of MFA geaktiveer is. Afhangende van hoe voorwaardelike toegangbeleide en ander multi-faktor verifikasie-instellings geconfigureer is, kan sommige protokolle eindig as enkel-faktor. Dit het ook 'n addisionele kontrole vir ADFS-konfigurasies en kan probeer om in te teken op die plaaslike ADFS-bediener as dit opgespoor word.
Hierdie hulpmiddel het gehelp om MFA-omseilings te identifiseer en dan API's in verskeie produksie AAD-huurders te misbruik, waar AAD-klante geglo het dat hulle MFA afgedwing het, maar ROPC-gebaseerde verifikasie suksesvol was.
Jy moet toestemming hê om al die toepassings te lys om die lys van die toepassings te genereer om te brute-force.
Donkey token is 'n stel funksies wat daarop gemik is om sekuriteitskonsultante te help wat Conditional Access Policies moet valideer, toetse vir 2FA-geaktiveerde Microsoft-portale, ens.
Toets elke portaal of dit moontlik is om te log in sonder MFA:
Omdat die Azure portaal nie beperk is nie, is dit moontlik om 'n token van die portaal-eindpunt te versamel om enige diens wat deur die vorige uitvoering opgespoor is, te bekom. In hierdie geval is Sharepoint geïdentifiseer, en 'n token om toegang daartoe te verkry, word aangevra:
Aangesien die token die toestemming Sites.Read.All (van Sharepoint) het, selfs al kan jy nie Sharepoint vanaf die web toegang nie weens MFA, is dit moontlik om die token te gebruik om toegang te verkry tot die lêers met die gegenereerde token:
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
