mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-08-01 00:20:44 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -10,26 +10,26 @@ az-basic-information/
|
||||
|
||||
## Azure Pentester/Red Team Methodology
|
||||
|
||||
AZURE वातावरण का ऑडिट करने के लिए यह बहुत महत्वपूर्ण है: कौन से **सेवाएँ उपयोग की जा रही हैं**, क्या **प्रकट किया जा रहा है**, किसके पास **पहुँच** है, और आंतरिक Azure सेवाएँ और **बाहरी सेवाएँ** कैसे जुड़ी हुई हैं।
|
||||
AZURE वातावरण का ऑडिट करने के लिए यह बहुत महत्वपूर्ण है: कौन से **सेवाएँ उपयोग में हैं**, क्या **प्रकट किया जा रहा है**, किसके पास **पहुँच** है, और आंतरिक Azure सेवाएँ और **बाहरी सेवाएँ** कैसे जुड़ी हुई हैं।
|
||||
|
||||
Red Team के दृष्टिकोण से, **Azure वातावरण को समझौता करने का पहला कदम** Azure AD के लिए कुछ **क्रेडेंशियल्स** प्राप्त करना है। यहाँ कुछ विचार दिए गए हैं कि ऐसा कैसे किया जा सकता है:
|
||||
Red Team के दृष्टिकोण से, **Azure वातावरण को समझौता करने का पहला कदम** Azure AD के लिए कुछ **क्रेडेंशियल्स** प्राप्त करना है। यहाँ कुछ विचार दिए गए हैं कि आप ऐसा कैसे कर सकते हैं:
|
||||
|
||||
- **Leaks** github (या समान) में - OSINT
|
||||
- **Social** Engineering
|
||||
- **Password** पुन: उपयोग (पासवर्ड लीक)
|
||||
- Azure-Hosted Applications में कमजोरियाँ
|
||||
- [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) जिसमें मेटाडेटा एंडपॉइंट तक पहुँच है
|
||||
- [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) जो मेटाडेटा एंडपॉइंट तक पहुँच प्रदान करता है
|
||||
- **Local File Read**
|
||||
- `/home/USERNAME/.azure`
|
||||
- `C:\Users\USERNAME\.azure`
|
||||
- फ़ाइल **`accessTokens.json`** `az cli` में 2.30 से पहले - Jan2022 - **access tokens को स्पष्ट पाठ में** संग्रहीत किया गया था
|
||||
- फ़ाइल **`accessTokens.json`** `az cli` में 2.30 से पहले - Jan2022 - **access tokens को स्पष्ट पाठ में** संग्रहीत किया गया
|
||||
- फ़ाइल **`azureProfile.json`** में लॉग इन किए गए उपयोगकर्ता के बारे में **जानकारी** होती है।
|
||||
- **`az logout`** टोकन को हटा देता है।
|
||||
- पुराने संस्करणों में **`Az PowerShell`** ने **access tokens** को **स्पष्ट** पाठ में **`TokenCache.dat`** में संग्रहीत किया। यह **ServicePrincipalSecret** को भी **स्पष्ट** पाठ में **`AzureRmContext.json`** में संग्रहीत करता है। cmdlet **`Save-AzContext`** का उपयोग **tokens** को **संग्रहित** करने के लिए किया जा सकता है।\
|
||||
- पुराने संस्करणों में **`Az PowerShell`** ने **access tokens** को **स्पष्ट** पाठ में **`TokenCache.dat`** में संग्रहीत किया। यह **ServicePrincipalSecret** को भी **स्पष्ट** पाठ में **`AzureRmContext.json`** में संग्रहीत करता है। **`Save-AzContext`** cmdlet का उपयोग **tokens** को **संग्रहित** करने के लिए किया जा सकता है।\
|
||||
उन्हें हटाने के लिए `Disconnect-AzAccount` का उपयोग करें।
|
||||
- 3rd पार्टियों का **breached**
|
||||
- 3rd पार्टियों द्वारा **breached**
|
||||
- **Internal** Employee
|
||||
- [**Common Phishing**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (क्रेडेंशियल्स या Oauth App)
|
||||
- [**Common Phishing**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (क्रेडेंशियल्स या Oauth ऐप)
|
||||
- [Device Code Authentication Phishing](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
|
||||
- [Azure **Password Spraying**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
|
||||
|
||||
@@ -40,7 +40,7 @@ az-unauthenticated-enum-and-initial-entry/
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> जब आप क्रेडेंशियल्स प्राप्त करने में सफल हो जाते हैं, तो आपको यह जानने की आवश्यकता है कि **ये क्रेडेंशियल्स किसके हैं**, और **इनके पास क्या पहुँच है**, इसलिए आपको कुछ बुनियादी एन्यूमरेशन करने की आवश्यकता है:
|
||||
> एक बार जब आप क्रेडेंशियल्स प्राप्त करने में सफल हो जाते हैं, तो आपको यह जानने की आवश्यकता है कि **ये क्रेडेंशियल्स किसके हैं**, और **इनके पास क्या पहुँच है**, इसलिए आपको कुछ बुनियादी एन्यूमरेशन करने की आवश्यकता है:
|
||||
|
||||
## Basic Enumeration
|
||||
|
||||
@@ -64,7 +64,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
|
||||
- **IP whitelisting** -- आपको एक मान्य IP को समझौता करना होगा
|
||||
- **Geo restrictions** -- पता करें कि उपयोगकर्ता कहाँ रहता है या कंपनी के कार्यालय कहाँ हैं और उसी शहर (या कम से कम देश) से एक IP प्राप्त करें
|
||||
- **Browser** -- शायद केवल कुछ OS (Windows, Linux, Mac, Android, iOS) से एक ब्राउज़र की अनुमति है। पता करें कि पीड़ित/कंपनी कौन सा OS उपयोग करती है।
|
||||
- आप **Service Principal क्रेडेंशियल्स को समझौता करने** की कोशिश भी कर सकते हैं क्योंकि ये आमतौर पर कम सीमित होते हैं और इसका लॉगिन कम समीक्षा किया जाता है
|
||||
- आप **Service Principal क्रेडेंशियल्स** को भी समझौता करने की कोशिश कर सकते हैं क्योंकि ये आमतौर पर कम सीमित होते हैं और इसका लॉगिन कम समीक्षा किया जाता है
|
||||
|
||||
इसे बायपास करने के बाद, आप अपनी प्रारंभिक सेटअप पर वापस जाने में सक्षम हो सकते हैं और आपके पास अभी भी पहुँच होगी।
|
||||
|
||||
@@ -77,7 +77,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
|
||||
> [!CAUTION]
|
||||
> जानें **कैसे स्थापित करें** az cli, AzureAD और Az PowerShell को [**Az - Entra ID**](az-services/az-azuread.md) अनुभाग में।
|
||||
|
||||
आपको जानने की आवश्यकता है कि आप **कौन हैं** (आप किस वातावरण में हैं):
|
||||
आपको जानने की आवश्यकता है कि **आप कौन हैं** (आप किस वातावरण में हैं):
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="az cli" }}
|
||||
@@ -120,13 +120,13 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> Azure को सूचीबद्ध करने के लिए सबसे महत्वपूर्ण कमांडों में से एक है **`Get-AzResource`** Az PowerShell से, क्योंकि यह आपको **जानकारी देता है कि आपके वर्तमान उपयोगकर्ता के पास किन संसाधनों की दृश्यता है**।
|
||||
> Azure को सूचीबद्ध करने के लिए सबसे महत्वपूर्ण कमांडों में से एक है **`Get-AzResource`** Az PowerShell से, क्योंकि यह आपको **जानने देता है कि आपके वर्तमान उपयोगकर्ता के पास किन संसाधनों की दृश्यता है**।
|
||||
>
|
||||
> आप वही जानकारी **वेब कंसोल** में [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll) पर जाकर या "सभी संसाधन" खोजकर प्राप्त कर सकते हैं।
|
||||
|
||||
### ENtra ID Enumeration
|
||||
|
||||
डिफ़ॉल्ट रूप से, किसी भी उपयोगकर्ता को **सूचीबद्ध करने के लिए पर्याप्त अनुमतियाँ होनी चाहिए** जैसे, उपयोगकर्ता, समूह, भूमिकाएँ, सेवा प्रमुख... (देखें [डिफ़ॉल्ट AzureAD अनुमतियाँ](az-basic-information/#default-user-permissions)).\
|
||||
डिफ़ॉल्ट रूप से, किसी भी उपयोगकर्ता को **चीजों को सूचीबद्ध करने के लिए पर्याप्त अनुमतियाँ होनी चाहिए** जैसे, उपयोगकर्ता, समूह, भूमिकाएँ, सेवा प्रमुख... (देखें [डिफ़ॉल्ट AzureAD अनुमतियाँ](az-basic-information/#default-user-permissions)).\
|
||||
आप यहाँ एक गाइड पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
@@ -134,7 +134,7 @@ az-services/az-azuread.md
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> अब जब आपके पास **अपने क्रेडेंशियल्स के बारे में कुछ जानकारी है** (और यदि आप एक रेड टीम हैं, तो उम्मीद है कि आप **पकड़े नहीं गए हैं**)। यह पता लगाने का समय है कि वातावरण में कौन सी सेवाएँ उपयोग की जा रही हैं।\
|
||||
> अब जब आपके पास **आपकी क्रेडेंशियल्स के बारे में कुछ जानकारी है** (और यदि आप एक रेड टीम हैं, तो उम्मीद है कि आप **पता नहीं चले हैं**)। यह पता लगाने का समय है कि वातावरण में कौन सी सेवाएँ उपयोग की जा रही हैं।\
|
||||
> अगले अनुभाग में आप **कुछ सामान्य सेवाओं को सूचीबद्ध करने के कुछ तरीके** देख सकते हैं।
|
||||
|
||||
## App Service SCM
|
||||
@@ -155,7 +155,7 @@ Azure DevOps Azure से अलग है। इसमें रिपॉजि
|
||||
```bash
|
||||
az account management-group list --output table --debug
|
||||
```
|
||||
एक **MitM** करने के लिए और **सभी अनुरोधों** की जांच करने के लिए जो यह मैन्युअल रूप से भेज रहा है, आप कर सकते हैं:
|
||||
एक **MitM** करने के लिए टूल पर और **सभी अनुरोधों** की मैन्युअल रूप से जांच करने के लिए आप कर सकते हैं:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Bash" }}
|
||||
|
||||
@@ -8,29 +8,29 @@
|
||||
|
||||
### Management Groups
|
||||
|
||||
- यह **अन्य प्रबंधन समूहों या सब्सक्रिप्शन** को समाहित कर सकता है।
|
||||
- यह **प्रबंधन समूह स्तर पर शासन नियंत्रण** जैसे RBAC और Azure नीति को एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सब्सक्रिप्शन द्वारा **विरासत में** प्राप्त किया जाता है।
|
||||
- इसमें **अन्य प्रबंधन समूह या सदस्यता** हो सकती हैं।
|
||||
- यह **गवर्नेंस नियंत्रण** जैसे RBAC और Azure नीति को प्रबंधन समूह स्तर पर एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** लिया जाता है।
|
||||
- **10,000 प्रबंधन** समूह एकल निर्देशिका में समर्थित हो सकते हैं।
|
||||
- एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सब्सक्रिप्शन स्तर को शामिल नहीं करती है।
|
||||
- प्रत्येक प्रबंधन समूह और सब्सक्रिप्शन केवल **एक माता-पिता** का समर्थन कर सकता है।
|
||||
- एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
|
||||
- प्रत्येक प्रबंधन समूह और सदस्यता **केवल एक माता-पिता** का समर्थन कर सकती है।
|
||||
- कई प्रबंधन समूह बनाए जा सकते हैं, लेकिन **केवल 1 मूल प्रबंधन समूह** है।
|
||||
- मूल प्रबंधन समूह **सभी** **अन्य प्रबंधन समूहों और सब्सक्रिप्शन** को **समाहित करता है और इसे स्थानांतरित या हटाया नहीं जा सकता**।
|
||||
- एकल प्रबंधन समूह के भीतर सभी सब्सक्रिप्शन को **एक ही Entra ID टेनेट** पर भरोसा करना चाहिए।
|
||||
- मूल प्रबंधन समूह **सभी** **अन्य प्रबंधन समूहों और सदस्यताओं** को **धारण करता है** और **इसे स्थानांतरित या हटाया नहीं जा सकता**।
|
||||
- एकल प्रबंधन समूह के भीतर सभी सदस्यताओं को **एक ही Entra ID टेनेट** पर भरोसा करना चाहिए।
|
||||
|
||||
<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
|
||||
|
||||
### Azure Subscriptions
|
||||
|
||||
- यह एक और **तार्किक कंटेनर है जहां संसाधन** (VMs, DBs…) चलाए जा सकते हैं और बिल किया जाएगा।
|
||||
- इसका **माता-पिता** हमेशा एक **प्रबंधन समूह** होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सब्सक्रिप्शन अन्य सब्सक्रिप्शन को समाहित नहीं कर सकते।
|
||||
- इसका **माता-पिता** हमेशा एक **प्रबंधन समूह** होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सदस्यताएँ अन्य सदस्यताओं को नहीं रख सकती हैं।
|
||||
- यह **केवल एक Entra ID** निर्देशिका पर भरोसा करता है।
|
||||
- **अनुमतियाँ** जो सब्सक्रिप्शन स्तर (या इसके किसी भी माता-पिता) पर लागू होती हैं, वे सब्सक्रिप्शन के भीतर सभी संसाधनों को **विरासत में** मिलती हैं।
|
||||
- सदस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू **अनुमतियाँ** सभी संसाधनों पर **विरासत में** आती हैं।
|
||||
|
||||
### Resource Groups
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, उन **संसाधनों** को एक ही संसाधन समूह में जोड़ें जो **एक ही जीवनचक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
|
||||
[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, **संसाधनों** को उसी संसाधन समूह में जोड़ें जो **एक ही जीवन चक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
|
||||
|
||||
सभी **संसाधन** को **एक संसाधन समूह के भीतर होना चाहिए** और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटा दिया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
|
||||
सभी **संसाधन** को **एक संसाधन समूह के भीतर** होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
|
||||
@@ -42,7 +42,7 @@ Azure Resource ID का प्रारूप इस प्रकार है:
|
||||
|
||||
- `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
|
||||
|
||||
एक वर्चुअल मशीन जिसका नाम myVM है, एक संसाधन समूह `myResourceGroup` के तहत सब्सक्रिप्शन ID `12345678-1234-1234-1234-123456789012` में, Azure Resource ID इस प्रकार दिखता है:
|
||||
एक वर्चुअल मशीन जिसका नाम myVM है, एक संसाधन समूह `myResourceGroup` के तहत सदस्यता ID `12345678-1234-1234-1234-123456789012` में, Azure Resource ID इस प्रकार दिखता है:
|
||||
|
||||
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
|
||||
|
||||
@@ -50,11 +50,11 @@ Azure Resource ID का प्रारूप इस प्रकार है:
|
||||
|
||||
### Azure
|
||||
|
||||
Azure माइक्रोसॉफ्ट का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो एक विस्तृत श्रृंखला की सेवाएँ** प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, आर्टिफिशियल इंटेलिजेंस, और स्टोरेज शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे बनाने, और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
|
||||
Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं** की पेशकश करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और स्टोरेज शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
|
||||
|
||||
### Entra ID (पूर्व में Azure Active Directory)
|
||||
|
||||
Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure, और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी माइक्रोसॉफ्ट सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
|
||||
Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
|
||||
|
||||
### Entra Domain Services (पूर्व में Azure AD DS)
|
||||
|
||||
@@ -71,18 +71,18 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
- गुण निर्दिष्ट करें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
|
||||
- डिफ़ॉल्ट उपयोगकर्ता प्रकार “**सदस्य**” है
|
||||
- **बाहरी उपयोगकर्ता**
|
||||
- आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम निर्दिष्ट करें (यह माइक्रोसॉफ्ट ईमेल नहीं हो सकता)
|
||||
- आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम निर्दिष्ट करें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
|
||||
- गुण निर्दिष्ट करें
|
||||
- डिफ़ॉल्ट उपयोगकर्ता प्रकार “**अतिथि**” है
|
||||
|
||||
### Members & Guests Default Permissions
|
||||
|
||||
आप उन्हें [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) पर देख सकते हैं लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
|
||||
आप उन्हें [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) में देख सकते हैं, लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
|
||||
|
||||
- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सब्सक्रिप्शन, और उनके सार्वजनिक गुणों को पढ़ें
|
||||
- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
|
||||
- अतिथियों को आमंत्रित करें (_बंद किया जा सकता है_)
|
||||
- सुरक्षा समूह बनाएं
|
||||
- गैर-छिपे हुए समूह सदस्यता पढ़ें
|
||||
- गैर-छिपे समूह सदस्यताओं को पढ़ें
|
||||
- स्वामित्व वाले समूहों में अतिथियों को जोड़ें
|
||||
- नया अनुप्रयोग बनाएं (_बंद किया जा सकता है_)
|
||||
- Azure में 50 उपकरणों तक जोड़ें (_बंद किया जा सकता है_)
|
||||
@@ -96,17 +96,17 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
- अनुप्रयोगों को पंजीकृत करें: डिफ़ॉल्ट **हाँ**
|
||||
- गैर-प्रशासक उपयोगकर्ताओं को टेनेट बनाने से रोकें: डिफ़ॉल्ट **नहीं**
|
||||
- सुरक्षा समूह बनाएं: डिफ़ॉल्ट **हाँ**
|
||||
- माइक्रोसॉफ्ट Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट **नहीं**
|
||||
- यह पोर्टल तक API पहुंच को प्रतिबंधित नहीं करता (केवल वेब)
|
||||
- Microsoft Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट **नहीं**
|
||||
- यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
|
||||
- उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट **हाँ**
|
||||
- उपयोगकर्ता को साइन इन रखे: डिफ़ॉल्ट **हाँ**
|
||||
- उपयोगकर्ता को साइन इन रखने के लिए दिखाएं: डिफ़ॉल्ट **हाँ**
|
||||
- उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
|
||||
- अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट **हाँ** (Microsoft Graph के माध्यम से)
|
||||
- **अतिथि**
|
||||
- **अतिथि उपयोगकर्ता पहुंच प्रतिबंध**
|
||||
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच** सभी सदस्य उपयोगकर्ता अनुमतियों को डिफ़ॉल्ट रूप से अतिथि उपयोगकर्ताओं को प्रदान करता है।
|
||||
- **अतिथि उपयोगकर्ताओं को निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित पहुंच** डिफ़ॉल्ट रूप से केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक अतिथि पहुंच को प्रतिबंधित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
|
||||
- **अतिथि उपयोगकर्ता पहुंच उनकी अपनी निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
|
||||
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच** डिफ़ॉल्ट रूप से सभी सदस्य उपयोगकर्ता अनुमतियों को अतिथि उपयोगकर्ताओं को प्रदान करता है।
|
||||
- **अतिथि उपयोगकर्ताओं को निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)** डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
|
||||
- **अतिथि उपयोगकर्ता पहुंच उनके अपने निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
|
||||
- **अतिथि आमंत्रित कर सकते हैं**
|
||||
- **संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट**
|
||||
- **सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ शामिल हैं**
|
||||
@@ -120,22 +120,22 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
|
||||
### **Groups**
|
||||
|
||||
यहाँ **2 प्रकार के समूह** हैं:
|
||||
यहां **2 प्रकार के समूह** हैं:
|
||||
|
||||
- **सुरक्षा**: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
|
||||
- **Microsoft 365**: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को एक साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
|
||||
- इसका एक **ईमेल पता** होगा जो EntraID टेनेट के डोमेन के साथ होगा।
|
||||
|
||||
यहाँ **2 प्रकार की सदस्यताएँ** हैं:
|
||||
यहां **2 प्रकार की सदस्यताएँ** हैं:
|
||||
|
||||
- **नियुक्त**: एक समूह में विशिष्ट सदस्यों को मैन्युअल रूप से जोड़ने की अनुमति देता है।
|
||||
- **डायनामिक सदस्यता**: नियमों का उपयोग करके सदस्यता को स्वचालित रूप से प्रबंधित करता है, जब सदस्यों के गुण बदलते हैं तो समूह में समावेश को अपडेट करता है।
|
||||
|
||||
### **Service Principals**
|
||||
|
||||
एक **Service Principal** एक **पहचान** है जो **अनुप्रयोगों**, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंच के लिए **उपयोग** के लिए बनाई गई है। यह पहुंच **सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित** होती है, जिससे आपको **कौन से संसाधनों तक पहुंच प्राप्त है** और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि **स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें** बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
|
||||
एक **Service Principal** एक **पहचान** है जो **अनुप्रयोगों**, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंच के लिए बनाई गई है। यह पहुंच **सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित** होती है, जिससे आपको **कौन से संसाधनों तक पहुंचा जा सकता है** और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि **स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें** बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
|
||||
|
||||
यह **सेवा प्रमुख के रूप में सीधे लॉगिन करना संभव है** एक **गुप्त** (पासवर्ड), एक **प्रमाणपत्र**, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए **संघीय** पहुंच प्रदान करके।
|
||||
आप **सेवा प्रमुख के रूप में सीधे लॉगिन** कर सकते हैं, इसके लिए एक **गुप्त** (पासवर्ड), एक **प्रमाणपत्र**, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए **संघीय** पहुंच प्रदान करके।
|
||||
|
||||
- यदि आप **पासवर्ड** प्रमाणीकरण चुनते हैं (डिफ़ॉल्ट), तो **उत्पन्न पासवर्ड को सहेजें** क्योंकि आप इसे फिर से एक्सेस नहीं कर पाएंगे।
|
||||
- यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि **अनुप्रयोग के पास निजी कुंजी पर पहुंच होगी**।
|
||||
@@ -148,12 +148,12 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
|
||||
1. **अनुप्रयोग ID (Client ID):** Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
|
||||
2. **Redirect URIs:** URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
|
||||
3. **प्रमाणपत्र, गुप्त और संघीय क्रेडेंशियल्स:** यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
|
||||
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करे** यह जानकर कि **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) क्या है।
|
||||
3. **प्रमाणपत्र, गुप्त और संघीय क्रेडेंशियल्स:** सेवा प्रमुख के रूप में लॉगिन करने के लिए एक गुप्त या प्रमाणपत्र उत्पन्न करना संभव है, या इसके लिए संघीय पहुंच प्रदान करना (जैसे Github Actions)।
|
||||
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो किसी व्यक्ति के लिए **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करना संभव है** यदि वह **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानता है।
|
||||
4. **API Permissions:** निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच सकता है।
|
||||
5. **Authentication Settings:** ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
|
||||
6. **Service Principal**: एक सेवा प्रमुख तब बनाया जाता है जब एक ऐप बनाया जाता है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है।
|
||||
1. **सेवा प्रमुख** सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनके साथ इसे कॉन्फ़िगर किया गया था।
|
||||
6. **Service Principal**: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
|
||||
1. **सेवा प्रमुख** सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनसे इसे कॉन्फ़िगर किया गया था।
|
||||
|
||||
### Default Consent Permissions
|
||||
|
||||
@@ -161,21 +161,21 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
|
||||
- **उपयोगकर्ता सहमति की अनुमति न दें**
|
||||
- सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
|
||||
- **सत्यापित प्रकाशकों से चयनित अनुमतियों के लिए ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
|
||||
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
|
||||
- **सत्यापित प्रकाशकों से ऐप्स के लिए चयनित अनुमतियों के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
|
||||
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स या इस संगठन में पंजीकृत ऐप्स के लिए।
|
||||
- **डिफ़ॉल्ट** कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
|
||||
- User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
|
||||
- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे पहुंच प्रदान की है
|
||||
- offline_access - उन डेटा तक पहुंच बनाए रखें जिनकी उपयोगकर्ताओं ने इसे पहुंच दी है
|
||||
- openid - उपयोगकर्ताओं को साइन इन करें
|
||||
- profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
|
||||
- email - उपयोगकर्ता के ईमेल पते को देखें
|
||||
- **ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
|
||||
- सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच के लिए सहमति दे सकते हैं।
|
||||
- **अनुप्रयोगों के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
|
||||
- सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच देने के लिए सहमति दे सकते हैं।
|
||||
|
||||
**प्रशासक सहमति अनुरोध**: डिफ़ॉल्ट **नहीं**
|
||||
|
||||
- उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
|
||||
- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को निर्दिष्ट किया जाए जो अनुरोधों के लिए सहमति दे सकते हैं
|
||||
- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों पर सहमति दे सकते हैं
|
||||
- यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे
|
||||
|
||||
### **Managed Identity (Metadata)**
|
||||
@@ -184,14 +184,14 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
|
||||
प्रबंधित पहचान के दो प्रकार हैं:
|
||||
|
||||
- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सब्सक्रिप्शन द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
|
||||
- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सब्सक्रिप्शन के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सब्सक्रिप्शन में एक सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान का प्रबंधन उन संसाधनों से अलग किया जाता है जो इसका उपयोग करते हैं**।
|
||||
- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सदस्यता द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, तो Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
|
||||
- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान का प्रबंधन उन संसाधनों से अलग किया जाता है जो इसका उपयोग करते हैं**।
|
||||
|
||||
प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से जुड़े इसे एक्सेस किया जा सके।
|
||||
|
||||
### Enterprise Applications
|
||||
|
||||
यह केवल Azure में सेवा प्रमुखों को फ़िल्टर करने और जांचने के लिए एक **तालिका** है कि कौन से अनुप्रयोगों को असाइन किया गया है।
|
||||
यह केवल Azure में सेवा प्रमुखों को फ़िल्टर करने और उन अनुप्रयोगों की जांच करने के लिए एक **तालिका** है जो असाइन की गई हैं।
|
||||
|
||||
**यह "अनुप्रयोग" का एक और प्रकार नहीं है,** Azure में कोई वस्तु "Enterprise Application" नहीं है, यह केवल सेवा प्रमुखों, ऐप पंजीकरणों और प्रबंधित पहचान की जांच करने के लिए एक अमूर्तता है।
|
||||
|
||||
@@ -204,10 +204,10 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
- परिदृश्य: एक कंपनी चाहती है कि क्षेत्रीय IT प्रशासक केवल अपने क्षेत्र के उपयोगकर्ताओं का प्रबंधन करें।
|
||||
- कार्यान्वयन:
|
||||
- प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
|
||||
- अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को भरें।
|
||||
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को समाहित कर सकते हैं
|
||||
- अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को Populate करें।
|
||||
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को **धारण कर सकते हैं**
|
||||
- AUs **डायनामिक सदस्यताओं** का समर्थन करते हैं
|
||||
- AUs **AUs को समाहित नहीं कर सकते**
|
||||
- AUs **AUs को नहीं रख सकते**
|
||||
- प्रशासक भूमिकाएँ असाइन करें:
|
||||
- क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
|
||||
- परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।
|
||||
@@ -217,15 +217,15 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
- Entra ID का प्रबंधन करने के लिए कुछ **निर्मित भूमिकाएँ** हैं जिन्हें Entra ID प्रमुखों को Entra ID का प्रबंधन करने के लिए असाइन किया जा सकता है
|
||||
- भूमिकाएँ देखें [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
|
||||
- सबसे विशेषाधिकार प्राप्त भूमिका **ग्लोबल एडमिनिस्ट्रेटर** है
|
||||
- भूमिका के विवरण में इसके **सूक्ष्म अनुमतियाँ** देखी जा सकती हैं
|
||||
- भूमिका के विवरण में इसकी **सूक्ष्म अनुमतियाँ** देखी जा सकती हैं
|
||||
|
||||
## Roles & Permissions
|
||||
|
||||
**भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
|
||||
|
||||
**भूमिकाएँ** समूहों को असाइन की जाती हैं और समूह के सभी **सदस्यों** द्वारा **विरासत में** प्राप्त की जाती हैं।
|
||||
**भूमिकाएँ** समूहों को असाइन की गई हैं और समूह के सभी **सदस्यों** द्वारा **विरासत में** ली जाती हैं।
|
||||
|
||||
स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** मिल सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सब्सक्रिप्शन पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा सभी संसाधन समूहों पर जो सब्सक्रिप्शन के भीतर हैं और **संसाधनों** पर जो संसाधन समूह के भीतर हैं।
|
||||
स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा जो सदस्यता के भीतर सभी संसाधन समूहों और **संसाधनों** पर है।
|
||||
|
||||
### **Classic Roles**
|
||||
|
||||
@@ -237,27 +237,27 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
|
||||
### Built-In roles
|
||||
|
||||
[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित करते हैं**। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** बना सकते हैं।**
|
||||
[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित** करते हैं। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** बना सकते हैं।**
|
||||
|
||||
**निर्मित** भूमिकाएँ केवल उन **संसाधनों** पर लागू होती हैं जिनके लिए वे **निर्धारित** हैं, उदाहरण के लिए, Compute संसाधनों पर **निर्मित भूमिकाओं** के इन 2 उदाहरणों की जांच करें:
|
||||
|
||||
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | बैकअप वॉल्ट को डिस्क बैकअप करने की अनुमति प्रदान करता है। | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | डिस्क बैकअप करने के लिए बैकअप वॉल्ट को अनुमति प्रदान करता है। | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
| [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | पोर्टल में वर्चुअल मशीनों को देखें और एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें। | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
|
||||
ये भूमिकाएँ **तार्किक कंटेनरों** (जैसे प्रबंधन समूह, सब्सक्रिप्शन और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** अधिकार प्राप्त होंगे।
|
||||
ये भूमिकाएँ **लॉजिक कंटेनरों** (जैसे प्रबंधन समूह, सदस्यताएँ और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** अधिकार प्राप्त होंगे।
|
||||
|
||||
- यहाँ [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की एक सूची प्राप्त करें।
|
||||
- यहाँ [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की एक सूची प्राप्त करें।
|
||||
- यहां [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की सूची प्राप्त करें।
|
||||
- यहां [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की सूची प्राप्त करें।
|
||||
|
||||
### Custom Roles
|
||||
|
||||
- यह भी संभव है कि [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाई जाएँ
|
||||
- ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूह, सब्सक्रिप्शन और संसाधन समूह) में हो सकती है
|
||||
- [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाना भी संभव है
|
||||
- ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
|
||||
- यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
|
||||
- यह अनुमतियों को बाहर करने की भी अनुमति देता है
|
||||
- एक प्रमुख जिसके पास एक बाहर की गई अनुमति है, वह इसे उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
|
||||
- यह वाइल्डकार्ड का उपयोग करने की अनुमति देता है
|
||||
- अनुमतियों को बाहर करना संभव है
|
||||
- एक प्रमुख जिसके पास बाहर की गई अनुमति है, वह इसे उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
|
||||
- वाइल्डकार्ड का उपयोग करना संभव है
|
||||
- उपयोग किया गया प्रारूप JSON है
|
||||
- `actions` संसाधन पर नियंत्रण क्रियाओं के लिए हैं
|
||||
- `dataActions` वस्तु के भीतर डेटा पर अनुमतियाँ हैं
|
||||
@@ -295,7 +295,7 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
### Permissions order
|
||||
|
||||
- एक **principal को किसी resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति देने के लिए**।
|
||||
- एक स्पष्ट **deny role assignment की प्राथमिकता होती है** उस भूमिका पर जो अनुमति देती है।
|
||||
- एक स्पष्ट **deny role assignment प्राथमिकता लेता है** उस भूमिका पर जो अनुमति देती है।
|
||||
|
||||
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
|
||||
|
||||
@@ -303,34 +303,34 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
|
||||
Global Administrator एक भूमिका है Entra ID से जो **Entra ID tenant पर पूर्ण नियंत्रण प्रदान करती है**। हालाँकि, यह डिफ़ॉल्ट रूप से Azure resources पर कोई अनुमति नहीं देती है।
|
||||
|
||||
Global Administrator भूमिका वाले उपयोगकर्ताओं के पास '**User Access Administrator Azure भूमिका में Root Management Group में 'elevate' करने की क्षमता है**। इसलिए Global Administrators **सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।**\
|
||||
Global Administrator भूमिका वाले उपयोगकर्ताओं के पास '**User Access Administrator Azure role में Elevate करने की क्षमता है Root Management Group में**। इसलिए Global Administrators **सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।**\
|
||||
यह elevation पृष्ठ के अंत में किया जा सकता है: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azure Policies
|
||||
|
||||
**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके resources विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में resources पर सेटिंग्स को लागू या ऑडिट करने** की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी resources के पास ट्रैकिंग के लिए विशिष्ट टैग हैं।
|
||||
**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके resources विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में resources पर सेटिंग्स को लागू या ऑडिट करने** की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी resources में ट्रैकिंग के लिए विशिष्ट टैग हों।
|
||||
|
||||
Azure Policies **proactive** हैं: वे अनुपालन न करने वाले resources के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले resources को खोज और ठीक कर सकते हैं।
|
||||
Azure Policies **proactive** हैं: वे अनुपालन न करने वाले resources के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, जो आपको मौजूदा अनुपालन न करने वाले resources को खोजने और ठीक करने की अनुमति देती हैं।
|
||||
|
||||
#### **Key Concepts**
|
||||
|
||||
1. **Policy Definition**: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
|
||||
2. **Policy Assignment**: एक नीति को एक विशिष्ट दायरे (जैसे, subscription, resource group) पर लागू करना।
|
||||
3. **Initiatives**: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
|
||||
4. **Effect**: यह निर्दिष्ट करता है कि नीति सक्रिय होने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
|
||||
4. **Effect**: निर्दिष्ट करता है कि नीति सक्रिय होने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
|
||||
|
||||
**कुछ उदाहरण:**
|
||||
|
||||
1. **विशिष्ट Azure क्षेत्रों के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी resources विशिष्ट Azure क्षेत्रों में तैनात हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसका सारा डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हो।
|
||||
2. **नामकरण मानकों को लागू करना**: नीतियाँ Azure resources के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में resources को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
|
||||
3. **कुछ resource प्रकारों को प्रतिबंधित करना**: यह नीति कुछ प्रकार के resources के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे resource प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
|
||||
4. **टैगिंग नीतियों को लागू करना**: टैग Azure resources के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो resource प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी resources के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या resources की श्रेणीकरण के लिए उपयोगी है।
|
||||
5. **resources के लिए सार्वजनिक पहुंच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ resources, जैसे स्टोरेज खाते या डेटाबेस, के पास सार्वजनिक endpoints नहीं होने चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हैं।
|
||||
4. **टैगिंग नीतियों को लागू करना**: टैग Azure resources के साथ जुड़े कुंजी-मूल्य जोड़े हैं जो resource प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि कुछ टैग मौजूद होने चाहिए, या सभी resources के लिए विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या resources की श्रेणीकरण के लिए उपयोगी है।
|
||||
5. **resources के लिए सार्वजनिक पहुंच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ resources, जैसे स्टोरेज खाते या डेटाबेस, में सार्वजनिक एंडपॉइंट नहीं होना चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हैं।
|
||||
6. **स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना**: नीतियों का उपयोग resources पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
|
||||
|
||||
ध्यान दें कि Azure Policies को Azure की किसी भी स्तर पर जोड़ा जा सकता है, लेकिन वे **आमतौर पर root management group** या अन्य management groups में उपयोग की जाती हैं।
|
||||
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आमतौर पर root management group में** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
|
||||
|
||||
Azure policy json example:
|
||||
```json
|
||||
@@ -350,23 +350,23 @@ Azure policy json example:
|
||||
"mode": "All"
|
||||
}
|
||||
```
|
||||
### Permissions Inheritance
|
||||
### अनुमतियों का उत्तराधिकार
|
||||
|
||||
In Azure **permissions are can be assigned to any part of the hierarchy**. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are **inherited** by contained **resources** of the entity where they were assigned.
|
||||
Azure में **अनुमतियाँ किसी भी भाग को सौंपा जा सकता है**। इसमें प्रबंधन समूह, सदस्यताएँ, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। अनुमतियाँ उस इकाई के अंतर्गत **संसाधनों** द्वारा **उत्तराधिकार** में ली जाती हैं जहाँ उन्हें सौंपा गया था।
|
||||
|
||||
This hierarchical structure allows for efficient and scalable management of access permissions.
|
||||
यह पदानुक्रमित संरचना पहुँच अनुमतियों के प्रबंधन को कुशल और स्केलेबल बनाती है।
|
||||
|
||||
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azure RBAC vs ABAC
|
||||
### Azure RBAC बनाम ABAC
|
||||
|
||||
**RBAC** (role-based access control) is what we have seen already in the previous sections: **Assigning a role to a principal to grant him access** over a resource.\
|
||||
However, in some cases you might want to provide **more fined-grained access management** or **simplify** the management of **hundreds** of role **assignments**.
|
||||
**RBAC** (भूमिका-आधारित पहुँच नियंत्रण) वही है जो हमने पहले के अनुभागों में देखा है: **एक संसाधन पर पहुँच देने के लिए एक प्रमुख को भूमिका सौंपना**।\
|
||||
हालांकि, कुछ मामलों में आप **अधिक बारीक पहुँच प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **सौंपने** के प्रबंधन को **सरल** करना चाहते हैं।
|
||||
|
||||
Azure **ABAC** (attribute-based access control) builds on Azure RBAC by adding **role assignment conditions based on attributes** in the context of specific actions. A _role assignment condition_ is an **additional check that you can optionally add to your role assignment** to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can **add a condition that requires an object to have a specific tag to read the object**.\
|
||||
You **cannot** explicitly **deny** **access** to specific resources **using conditions**.
|
||||
Azure **ABAC** (गुण-आधारित पहुँच नियंत्रण) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में गुणों के आधार पर भूमिका सौंपने की शर्तें** जोड़ी जाती हैं। एक _भूमिका सौंपने की शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं** ताकि अधिक बारीक पहुँच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
|
||||
आप **विशिष्ट संसाधनों** के लिए **शर्तों** का उपयोग करके **पहुँच** को स्पष्ट रूप से **अस्वीकृत** **नहीं** कर सकते।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
|
||||
- [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)
|
||||
|
||||
+12
-13
@@ -43,14 +43,14 @@ Entra ID माइक्रोसॉफ्ट का क्लाउड-आध
|
||||
OIDC में **तीन प्रकार के टोकन** होते हैं:
|
||||
|
||||
- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट इस टोकन को संसाधन सर्वर को **संसाधनों तक पहुँचने** के लिए प्रस्तुत करता है। इसे केवल उपयोगकर्ता, क्लाइंट और संसाधन के विशिष्ट संयोजन के लिए उपयोग किया जा सकता है और **समाप्ति तक रद्द नहीं किया जा सकता** - जो कि डिफ़ॉल्ट रूप से 1 घंटा है।
|
||||
- **ID Tokens**: क्लाइंट को यह **टोकन प्राधिकरण सर्वर से प्राप्त होता है**। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह **उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है**।
|
||||
- **Refresh Tokens**: एक्सेस टोकन के साथ क्लाइंट को प्रदान किया जाता है। इसका उपयोग **नए एक्सेस और ID टोकन प्राप्त करने** के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। डिफ़ॉल्ट समाप्ति **90 दिन** है निष्क्रिय रिफ्रेश टोकन के लिए और **सक्रिय टोकन के लिए कोई समाप्ति नहीं** (एक रिफ्रेश टोकन से नए रिफ्रेश टोकन प्राप्त करना संभव है)।
|
||||
- एक रिफ्रेश टोकन को एक **`aud`** से, कुछ **scopes** से, और एक **tenant** से बंधा होना चाहिए और इसे केवल उस aud, scopes (और अधिक नहीं) और tenant के लिए एक्सेस टोकन उत्पन्न करने में सक्षम होना चाहिए। हालाँकि, यह **FOCI एप्लिकेशन टोकन** के साथ ऐसा नहीं है।
|
||||
- **ID Tokens**: क्लाइंट को यह **टोकन प्राधिकरण सर्वर से** प्राप्त होता है। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह **उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है**।
|
||||
- **Refresh Tokens**: क्लाइंट को एक्सेस टोकन के साथ प्रदान किया जाता है। इसका उपयोग **नए एक्सेस और ID टोकन प्राप्त करने** के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। निष्क्रिय रिफ्रेश टोकनों के लिए डिफ़ॉल्ट समाप्ति **90 दिन** है और सक्रिय टोकनों के लिए **कोई समाप्ति नहीं** है (एक रिफ्रेश टोकन से नए रिफ्रेश टोकन प्राप्त करना संभव है)।
|
||||
- एक रिफ्रेश टोकन को एक **`aud`**, कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और इसे केवल उस aud, scopes (और अधिक नहीं) और tenant के लिए एक्सेस टोकन उत्पन्न करने में सक्षम होना चाहिए। हालाँकि, यह **FOCI एप्लिकेशन टोकनों** के साथ ऐसा नहीं है।
|
||||
- एक रिफ्रेश टोकन एन्क्रिप्टेड होता है और केवल माइक्रोसॉफ्ट इसे डिक्रिप्ट कर सकता है।
|
||||
- नया रिफ्रेश टोकन प्राप्त करने से पिछले रिफ्रेश टोकन रद्द नहीं होता है।
|
||||
- नया रिफ्रेश टोकन प्राप्त करने से पिछले रिफ्रेश टोकन को रद्द नहीं किया जाता है।
|
||||
|
||||
> [!WARNING]
|
||||
> **Conditional access** के लिए जानकारी **JWT** के अंदर **स्टोर** की जाती है। इसलिए, यदि आप **अनुमत IP पते** से **टोकन का अनुरोध करते हैं**, तो वह **IP** टोकन में **स्टोर** किया जाएगा और फिर आप उस टोकन का उपयोग **गैर-अनुमत IP से संसाधनों तक पहुँचने** के लिए कर सकते हैं।
|
||||
> **Conditional access** के लिए जानकारी **JWT** के अंदर **स्टोर** की जाती है। इसलिए, यदि आप **अनुमत IP पते** से **टोकन** का अनुरोध करते हैं, तो वह **IP** टोकन में **स्टोर** किया जाएगा और फिर आप उस टोकन का उपयोग **गैर-अनुमत IP से संसाधनों तक पहुँचने** के लिए कर सकते हैं।
|
||||
|
||||
### Access Tokens "aud"
|
||||
|
||||
@@ -63,7 +63,7 @@ OIDC में **तीन प्रकार के टोकन** होते
|
||||
|
||||
<details>
|
||||
|
||||
<summary>aud उदाहरण</summary>
|
||||
<summary>aud examples</summary>
|
||||
|
||||
- **aad-graph (Azure Active Directory Graph API)**: पुराने Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग किया जाता है, जो एप्लिकेशनों को Azure Active Directory (Azure AD) में निर्देशिका डेटा पढ़ने और लिखने की अनुमति देता है।
|
||||
- `https://graph.windows.net/`
|
||||
@@ -71,7 +71,7 @@ OIDC में **तीन प्रकार के टोकन** होते
|
||||
* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure संसाधनों का प्रबंधन करने के लिए उपयोग किया जाता है। इसमें वर्चुअल मशीनों, स्टोरेज खातों, और अधिक जैसे संसाधनों को बनाने, अपडेट करने और हटाने जैसी क्रियाएँ शामिल हैं।
|
||||
- `https://management.core.windows.net/ or https://management.azure.com/`
|
||||
|
||||
- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग किया जाता है, जो क्लाउड में बड़े पैमाने पर समानांतर और उच्च-प्रदर्शन कंप्यूटिंग एप्लिकेशनों को कुशलतापूर्वक सक्षम करता है।
|
||||
- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग किया जाता है, एक सेवा जो क्लाउड में बड़े पैमाने पर समानांतर और उच्च-प्रदर्शन कंप्यूटिंग एप्लिकेशनों को कुशलतापूर्वक सक्षम करती है।
|
||||
- `https://batch.core.windows.net/`
|
||||
|
||||
* **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ बातचीत करने के लिए उपयोग किया जाता है, जो एक स्केलेबल डेटा स्टोरेज और एनालिटिक्स सेवा है।
|
||||
@@ -80,7 +80,7 @@ OIDC में **तीन प्रकार के टोकन** होते
|
||||
- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग किया जाता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित मीडिया प्रसंस्करण और वितरण सेवाएँ प्रदान करता है।
|
||||
- `https://rest.media.azure.net`
|
||||
|
||||
* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग किया जाता है, जो Microsoft 365 सेवाओं के डेटा के लिए एकीकृत एंडपॉइंट है। यह आपको Azure AD, Office 365, Enterprise Mobility, और Security सेवाओं जैसे सेवाओं से डेटा और अंतर्दृष्टि तक पहुँचने की अनुमति देता है।
|
||||
* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग किया जाता है, जो Microsoft 365 सेवाओं के डेटा के लिए एकीकृत एंडपॉइंट है। यह आपको Azure AD, Office 365, Enterprise Mobility, और Security सेवाओं जैसी सेवाओं से डेटा और अंतर्दृष्टि तक पहुँचने की अनुमति देता है।
|
||||
- `https://graph.microsoft.com`
|
||||
|
||||
- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL, PostgreSQL, और MariaDB जैसे ओपन-सोर्स रिलेशनल डेटाबेस इंजनों के लिए Azure Database सेवाओं तक पहुँचने के लिए उपयोग किया जाता है।
|
||||
@@ -92,7 +92,7 @@ OIDC में **तीन प्रकार के टोकन** होते
|
||||
|
||||
एक एक्सेस टोकन का स्कोप एक्सेस टोकन JWT के अंदर scp कुंजी के अंदर स्टोर किया जाता है। ये स्कोप परिभाषित करते हैं कि एक्सेस टोकन को क्या पहुँच प्राप्त है।
|
||||
|
||||
यदि एक JWT को एक विशिष्ट API से संपर्क करने की अनुमति है लेकिन **अनुरोधित क्रिया** को करने के लिए **स्कोप नहीं है**, तो यह उस JWT के साथ क्रिया करने में **असफल रहेगा**।
|
||||
यदि एक JWT को किसी विशिष्ट API से संपर्क करने की अनुमति है लेकिन **अनुरोधित क्रिया** को करने के लिए **स्कोप नहीं है**, तो यह उस JWT के साथ क्रिया करने में **असफल रहेगा**।
|
||||
|
||||
### Get refresh & access token example
|
||||
```python
|
||||
@@ -121,7 +121,6 @@ device_flow
|
||||
pprint(azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
|
||||
|
||||
# DECODE JWT
|
||||
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
|
||||
"""Decodes base64 encoded JWT blob"""
|
||||
@@ -147,13 +146,13 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
```
|
||||
## FOCI Tokens Privilege Escalation
|
||||
|
||||
पहले उल्लेख किया गया था कि रिफ्रेश टोकन को **स्कोप** से जोड़ा जाना चाहिए जिसके साथ इसे उत्पन्न किया गया था, **एप्लिकेशन** और **टेनेंट** से जिसे यह उत्पन्न किया गया था। यदि इनमें से कोई भी सीमा टूटती है, तो विशेषाधिकार बढ़ाना संभव है क्योंकि अन्य संसाधनों और टेनेंट के लिए एक्सेस टोकन उत्पन्न करना संभव होगा जिन तक उपयोगकर्ता की पहुंच है और जिनमें मूल रूप से निर्धारित से अधिक स्कोप हैं।
|
||||
पहले उल्लेख किया गया था कि रिफ्रेश टोकन को **स्कोप** से जोड़ा जाना चाहिए जिसके साथ इसे उत्पन्न किया गया था, **ऐप्लिकेशन** और **टेनेंट** से जिसे यह उत्पन्न किया गया था। यदि इनमें से कोई भी सीमा टूटती है, तो विशेषाधिकार बढ़ाना संभव है क्योंकि अन्य संसाधनों और टेनेंट के लिए एक्सेस टोकन उत्पन्न करना संभव होगा जिन तक उपयोगकर्ता की पहुंच है और जिनके लिए अधिक स्कोप हैं जितना कि मूल रूप से इरादा किया गया था।
|
||||
|
||||
इसके अलावा, **यह सभी रिफ्रेश टोकनों के साथ संभव है** [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra खाते, Microsoft व्यक्तिगत खाते, और Facebook और Google जैसे सामाजिक खाते) क्योंकि [**दस्तावेज़**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) में उल्लेख किया गया है: "रिफ्रेश टोकन उपयोगकर्ता और क्लाइंट के संयोजन से बंधे होते हैं, लेकिन **किसी संसाधन या टेनेंट से जुड़े नहीं होते**। एक क्लाइंट रिफ्रेश टोकन का उपयोग करके एक्सेस टोकन प्राप्त कर सकता है **किसी भी संसाधन और टेनेंट के संयोजन में** जहां उसे ऐसा करने की अनुमति है। रिफ्रेश टोकन एन्क्रिप्टेड होते हैं और केवल Microsoft identity platform उन्हें पढ़ सकता है।"
|
||||
इसके अलावा, **यह सभी रिफ्रेश टोकनों के साथ संभव है** [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra खाते, Microsoft व्यक्तिगत खाते, और फेसबुक और गूगल जैसे सामाजिक खाते) क्योंकि [**दस्तावेज़**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) में उल्लेख किया गया है: "रिफ्रेश टोकन उपयोगकर्ता और क्लाइंट के संयोजन से बंधे होते हैं, लेकिन **किसी संसाधन या टेनेंट से बंधे नहीं होते**। एक क्लाइंट रिफ्रेश टोकन का उपयोग करके एक्सेस टोकन प्राप्त कर सकता है **किसी भी संसाधन और टेनेंट के संयोजन में** जहां इसे ऐसा करने की अनुमति है। रिफ्रेश टोकन एन्क्रिप्टेड होते हैं और केवल Microsoft identity platform इन्हें पढ़ सकता है।"
|
||||
|
||||
इसके अलावा, ध्यान दें कि FOCI एप्लिकेशन सार्वजनिक एप्लिकेशन हैं, इसलिए **सर्वर पर प्रमाणीकरण के लिए कोई रहस्य आवश्यक नहीं है**।
|
||||
|
||||
फिर ज्ञात FOCI क्लाइंट्स [**मूल शोध**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए हैं, जिन्हें [**यहां पाया जा सकता है**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv)।
|
||||
फिर ज्ञात FOCI क्लाइंट्स [**मूल शोध**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए हैं जिन्हें [**यहां पाया जा सकता है**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv)।
|
||||
|
||||
### Get different scope
|
||||
|
||||
|
||||
@@ -6,36 +6,36 @@
|
||||
|
||||
जब एक डिवाइस AzureAD में शामिल होता है, तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है।
|
||||
|
||||
जब एक डिवाइस को पंजीकृत किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछना), फिर यह डिवाइस पंजीकरण सेवा के लिए टोकन का अनुरोध करता है और फिर अंतिम पुष्टि संकेत के लिए पूछता है।
|
||||
जब एक डिवाइस को रजिस्टर किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछता है), फिर यह डिवाइस रजिस्ट्रेशन सेवा के लिए टोकन का अनुरोध करता है और फिर अंतिम पुष्टि प्रॉम्प्ट के लिए पूछता है।
|
||||
|
||||
फिर, डिवाइस में दो RSA की जोड़े उत्पन्न होते हैं: **डिवाइस कुंजी** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **परिवहन** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है।
|
||||
फिर, डिवाइस में दो RSA कीपैर बनाए जाते हैं: **डिवाइस की** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **ट्रांसपोर्ट** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है।
|
||||
|
||||
फिर, **ऑब्जेक्ट** **AzureAD** में उत्पन्न होता है (Intune में नहीं) और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे उसने हस्ताक्षरित किया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD से जुड़ा है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)।
|
||||
फिर, **ऑब्जेक्ट** **AzureAD** में (Intune में नहीं) उत्पन्न होता है और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे इसके द्वारा हस्ताक्षरित किया गया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD से जुड़ा है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)।
|
||||
```bash
|
||||
dsregcmd /status
|
||||
```
|
||||
After the device registration a **Primary Refresh Token** is requested by the LSASS CloudAP module and given to the device. With the PRT is also delivered the **session key encrypted so only the device can decrypt it** (using the public key of the transport key) and it's **needed to use the PRT.**
|
||||
डिवाइस पंजीकरण के बाद, **प्राथमिक रिफ्रेश टोकन** LSASS CloudAP मॉड्यूल द्वारा अनुरोध किया जाता है और डिवाइस को दिया जाता है। PRT के साथ **सत्र कुंजी भी प्रदान की जाती है जिसे केवल डिवाइस ही डिक्रिप्ट कर सकता है** (परिवहन कुंजी के सार्वजनिक कुंजी का उपयोग करके) और इसे **PRT का उपयोग करने के लिए आवश्यक है।**
|
||||
|
||||
For more information about what is a PRT check:
|
||||
PRT क्या है, इसके बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### TPM - Trusted Platform Module
|
||||
### TPM - ट्रस्टेड प्लेटफॉर्म मॉड्यूल
|
||||
|
||||
The **TPM** **की रक्षा करता है** against key **निकासी** from a powered down device (if protected by PIN) nd from extracting the private material from the OS layer.\
|
||||
But it **की रक्षा नहीं करता** against **sniffing** the physical connection between the TPM and CPU or **using the cryptographic material** in the TPM while the system is running from a process with **SYSTEM** rights.
|
||||
**TPM** **कुंजी** **निकासी** के खिलाफ एक बंद डिवाइस (यदि पिन द्वारा सुरक्षित है) से और OS परत से निजी सामग्री निकालने से **सुरक्षा** करता है।\
|
||||
लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की स्निफिंग** या **SYSTEM** अधिकारों वाले प्रक्रिया से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने के खिलाफ **सुरक्षा** नहीं करता है।
|
||||
|
||||
If you check the following page you will see that **stealing the PRT** can be used to access like a the **user**, which is great because the **PRT is located devices**, so it can be stolen from them (or if not stolen abused to generate new signing keys):
|
||||
यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** **उपयोगकर्ता** की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है):
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Registering a device with SSO tokens
|
||||
## SSO टोकनों के साथ डिवाइस पंजीकरण
|
||||
|
||||
It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:
|
||||
एक हमलावर के लिए समझौता किए गए डिवाइस से Microsoft डिवाइस पंजीकरण सेवा के लिए एक टोकन अनुरोध करना और इसे पंजीकृत करना संभव होगा:
|
||||
```bash
|
||||
# Initialize SSO flow
|
||||
roadrecon auth prt-init
|
||||
@@ -50,14 +50,14 @@ registerdevice.py
|
||||
जो आपको **प्रमाणपत्र देगा जिसका उपयोग आप भविष्य में PRTs के लिए पूछने के लिए कर सकते हैं**। इसलिए स्थिरता बनाए रखना और **MFA को बायपास करना** क्योंकि नए डिवाइस को पंजीकृत करने के लिए उपयोग किया गया मूल PRT टोकन **पहले से ही MFA अनुमतियाँ दी गई थीं**।
|
||||
|
||||
> [!TIP]
|
||||
> ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक उपकरण को पंजीकृत करना यह नहीं दर्शाता कि उपकरण **Intune में नामांकित होने की अनुमति दी जाएगी**।
|
||||
> ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक डिवाइस को पंजीकृत करना यह नहीं दर्शाता कि डिवाइस **Intune में नामांकित होने की अनुमति दी जाएगी**।
|
||||
|
||||
> [!CAUTION]
|
||||
> यह हमला सितंबर 2021 में ठीक किया गया था क्योंकि आप अब SSO टोकन का उपयोग करके नए उपकरणों को पंजीकृत नहीं कर सकते। हालाँकि, एक वैध तरीके से उपकरणों को पंजीकृत करना अभी भी संभव है (यदि आवश्यक हो तो उपयोगकर्ता नाम, पासवर्ड और MFA होना)। जांचें: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md)।
|
||||
> यह हमला सितंबर 2021 में ठीक किया गया था क्योंकि आप अब SSO टोकन का उपयोग करके नए उपकरणों को पंजीकृत नहीं कर सकते। हालाँकि, यह अभी भी एक वैध तरीके से उपकरणों को पंजीकृत करना संभव है (यदि आवश्यक हो तो उपयोगकर्ता नाम, पासवर्ड और MFA होना)। जांचें: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md)।
|
||||
|
||||
## एक डिवाइस टिकट को ओवरराइट करना
|
||||
|
||||
यह संभव था कि **एक डिवाइस टिकट का अनुरोध करें**, **वर्तमान को ओवरराइट करें** और प्रवाह के दौरान **PRT चुराएं** (इसलिए TPM से इसे चुराने की आवश्यकता नहीं है। अधिक जानकारी के लिए [**इस वार्ता की जांच करें**](https://youtu.be/BduCn8cLV1A)।
|
||||
यह **डिवाइस टिकट** **अनुरोध** करने, डिवाइस के वर्तमान को **ओवरराइट** करने और प्रवाह के दौरान **PRT चुराने** के लिए संभव था (इसलिए इसे TPM से चुराने की आवश्यकता नहीं है। अधिक जानकारी के लिए [**इस वार्ता की जांच करें**](https://youtu.be/BduCn8cLV1A)।
|
||||
|
||||
<figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -70,15 +70,15 @@ registerdevice.py
|
||||
|
||||
हमले का सारांश:
|
||||
|
||||
- यह संभव है कि **SSO के माध्यम से एक डिवाइस से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करें
|
||||
- यह **SSO** के माध्यम से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है
|
||||
- यह **TPM सुरक्षा को पराजित करता है** क्योंकि कुंजी **नई कुंजी के निर्माण के दौरान स्निफ की जाती है**
|
||||
- यह **स्थिरता** भी प्रदान करता है
|
||||
|
||||
<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक उपकरण होना चाहिए (फ्लाई पर पंजीकृत या एक वैध उपकरण से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए।
|
||||
उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक डिवाइस होना चाहिए (फ्लाई पर पंजीकृत या एक वैध डिवाइस से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए।
|
||||
|
||||
फिर, यह एक नई कुंजी उत्पन्न करना संभव है:
|
||||
फिर, एक नई कुंजी उत्पन्न करना संभव है:
|
||||
```bash
|
||||
roadtx genhellokey -d <device id> -k tempkey.key
|
||||
```
|
||||
@@ -86,7 +86,7 @@ roadtx genhellokey -d <device id> -k tempkey.key
|
||||
|
||||
<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी एक्सेस चुराना**। अधिक जानकारी के लिए देखें:
|
||||
एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी पहुंच चुराना**। अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
|
||||
|
||||
@@ -30,7 +30,7 @@
|
||||
|
||||
[**दस्तावेज़ीकरण**](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.4) से निर्देश:
|
||||
|
||||
1. यदि अभी तक स्थापित नहीं है तो `brew` स्थापित करें:
|
||||
1. यदि अभी तक `brew` स्थापित नहीं है, तो इसे स्थापित करें:
|
||||
```bash
|
||||
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
||||
```
|
||||
@@ -51,7 +51,7 @@ brew upgrade powershell
|
||||
|
||||
### az cli
|
||||
|
||||
[**Azure कमांड-लाइन इंटरफेस (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) एक क्रॉस-प्लेटफ़ॉर्म टूल है जो Python में लिखा गया है, जो (अधिकतर) Azure और Entra ID संसाधनों का प्रबंधन और प्रशासन करने के लिए है। यह Azure से कनेक्ट करता है और कमांड लाइन या स्क्रिप्ट के माध्यम से प्रशासनिक आदेशों को निष्पादित करता है।
|
||||
[**Azure Command-Line Interface (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) एक क्रॉस-प्लेटफ़ॉर्म टूल है जो Python में लिखा गया है, जो (अधिकतर) Azure और Entra ID संसाधनों का प्रबंधन और प्रशासन करने के लिए है। यह Azure से कनेक्ट करता है और कमांड लाइन या स्क्रिप्ट के माध्यम से प्रशासनिक आदेशों को निष्पादित करता है।
|
||||
|
||||
[**स्थापना निर्देशों के लिए इस लिंक का पालन करें¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install)।
|
||||
|
||||
@@ -63,7 +63,7 @@ Azure CLI में आदेशों को इस पैटर्न का
|
||||
```bash
|
||||
az account management-group list --output table --debug
|
||||
```
|
||||
In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can do:
|
||||
एक **MitM** करने के लिए टूल पर और **सभी अनुरोधों** की मैन्युअल रूप से जांच करने के लिए आप कर सकते हैं:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Bash" }}
|
||||
@@ -93,7 +93,7 @@ $env:HTTP_PROXY="http://127.0.0.1:8080"
|
||||
|
||||
### Az PowerShell
|
||||
|
||||
Azure PowerShell एक मॉड्यूल है जिसमें Azure संसाधनों को सीधे PowerShell कमांड लाइन से प्रबंधित करने के लिए cmdlets होते हैं।
|
||||
Azure PowerShell एक मॉड्यूल है जिसमें Azure संसाधनों को PowerShell कमांड लाइन से सीधे प्रबंधित करने के लिए cmdlets होते हैं।
|
||||
|
||||
[**स्थापना निर्देशों**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell) के लिए इस लिंक का पालन करें।
|
||||
|
||||
@@ -105,27 +105,27 @@ Azure PowerShell AZ मॉड्यूल में कमांड इस प
|
||||
```bash
|
||||
Get-AzResourceGroup -Debug
|
||||
```
|
||||
In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can set the env variables `HTTPS_PROXY` and `HTTP_PROXY` according to the [**docs**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
|
||||
एक **MitM** करने के लिए और **सभी अनुरोधों** की जांच करने के लिए जो यह मैन्युअल रूप से भेज रहा है, आप पर्यावरण चर `HTTPS_PROXY` और `HTTP_PROXY` को [**docs**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy) के अनुसार सेट कर सकते हैं।
|
||||
|
||||
### Microsoft Graph PowerShell
|
||||
|
||||
Microsoft Graph PowerShell एक क्रॉस-प्लेटफ़ॉर्म SDK है जो सभी Microsoft Graph APIs, जैसे SharePoint, Exchange, और Outlook, तक पहुँचने की अनुमति देता है, एकल एंडपॉइंट का उपयोग करके। यह PowerShell 7+, MSAL के माध्यम से आधुनिक प्रमाणीकरण, बाहरी पहचान, और उन्नत क्वेरी का समर्थन करता है। न्यूनतम विशेषाधिकार पहुँच पर ध्यान केंद्रित करते हुए, यह सुरक्षित संचालन सुनिश्चित करता है और नवीनतम Microsoft Graph API सुविधाओं के साथ संरेखित करने के लिए नियमित अपडेट प्राप्त करता है।
|
||||
|
||||
Follow this link for the [**installation instructions**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation).
|
||||
[**installation instructions**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation) के लिए इस लिंक का पालन करें।
|
||||
|
||||
Commands in Microsoft Graph PowerShell are structured like: `<Action>-Mg<Service> <parameters>`
|
||||
Microsoft Graph PowerShell में कमांड इस प्रकार संरचित होते हैं: `<Action>-Mg<Service> <parameters>`
|
||||
|
||||
#### Debug Microsoft Graph PowerShell
|
||||
|
||||
Using the parameter **`-Debug`** it's possible to see all the requests the tool is sending:
|
||||
पैरामीटर **`-Debug`** का उपयोग करके यह देखना संभव है कि उपकरण सभी अनुरोधों को कैसे भेज रहा है:
|
||||
```bash
|
||||
Get-MgUser -Debug
|
||||
```
|
||||
### ~~**AzureAD Powershell**~~
|
||||
|
||||
Azure Active Directory (AD) मॉड्यूल, जो अब **अवशिष्ट** है, Azure AD संसाधनों को प्रबंधित करने के लिए Azure PowerShell का हिस्सा है। यह Entra ID में उपयोगकर्ताओं, समूहों और अनुप्रयोग पंजीकरणों को प्रबंधित करने के लिए cmdlets प्रदान करता है।
|
||||
Azure Active Directory (AD) मॉड्यूल, जो अब **deprecated** है, Azure AD संसाधनों को प्रबंधित करने के लिए Azure PowerShell का हिस्सा है। यह Entra ID में उपयोगकर्ताओं, समूहों और अनुप्रयोग पंजीकरणों को प्रबंधित करने के लिए cmdlets प्रदान करता है।
|
||||
|
||||
> [!TIP]
|
||||
> इसे Microsoft Graph PowerShell द्वारा प्रतिस्थापित किया गया है
|
||||
|
||||
[**स्थापना निर्देशों**](https://www.powershellgallery.com/packages/AzureAD) के लिए इस लिंक का पालन करें।
|
||||
इस लिंक पर [**स्थापना निर्देश**](https://www.powershellgallery.com/packages/AzureAD) के लिए जाएं।
|
||||
|
||||
@@ -6,59 +6,59 @@
|
||||
|
||||
### On-Prem मशीनें जो क्लाउड से जुड़ी हैं
|
||||
|
||||
एक मशीन को क्लाउड से जोड़ने के विभिन्न तरीके हैं:
|
||||
क्लाउड से जुड़ने के विभिन्न तरीके हैं:
|
||||
|
||||
#### Azure AD से जुड़ी
|
||||
|
||||
<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### कार्यस्थल से जुड़ी
|
||||
#### Workplace से जुड़ी
|
||||
|
||||
<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large</a></p></figcaption></figure>
|
||||
|
||||
#### हाइब्रिड से जुड़ी
|
||||
#### Hybrid से जुड़ी
|
||||
|
||||
<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large</a></p></figcaption></figure>
|
||||
|
||||
#### AADJ या हाइब्रिड पर कार्यस्थल से जुड़ी
|
||||
#### AADJ या Hybrid पर Workplace से जुड़ी
|
||||
|
||||
<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large</a></p></figcaption></figure>
|
||||
|
||||
### टोकन और सीमाएँ <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
|
||||
### Tokens और सीमाएँ <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
|
||||
|
||||
Azure AD में, विशिष्ट सीमाओं के साथ विभिन्न प्रकार के टोकन होते हैं:
|
||||
Azure AD में, विभिन्न प्रकार के टोकन होते हैं जिनकी विशिष्ट सीमाएँ होती हैं:
|
||||
|
||||
- **एक्सेस टोकन**: APIs और Microsoft Graph जैसे संसाधनों तक पहुँचने के लिए उपयोग किया जाता है। ये एक विशिष्ट क्लाइंट और संसाधन से जुड़े होते हैं।
|
||||
- **रीफ्रेश टोकन**: नए एक्सेस टोकन प्राप्त करने के लिए अनुप्रयोगों को जारी किए जाते हैं। इन्हें केवल उसी अनुप्रयोग द्वारा या अनुप्रयोगों के समूह द्वारा उपयोग किया जा सकता है, जिन्हें जारी किया गया था।
|
||||
- **प्राइमरी रीफ्रेश टोकन (PRT)**: Azure AD से जुड़े, पंजीकृत, या हाइब्रिड जुड़े उपकरणों पर सिंगल साइन-ऑन के लिए उपयोग किया जाता है। इन्हें ब्राउज़र साइन-इन प्रवाह में और उपकरण पर मोबाइल और डेस्कटॉप अनुप्रयोगों में साइन इन करने के लिए उपयोग किया जा सकता है।
|
||||
- **Windows Hello for Business कुंजी (WHFB)**: पासवर्ड रहित प्रमाणीकरण के लिए उपयोग किया जाता है। इसका उपयोग प्राइमरी रीफ्रेश टोकन प्राप्त करने के लिए किया जाता है।
|
||||
- **Access tokens**: APIs और Microsoft Graph जैसी संसाधनों तक पहुँचने के लिए उपयोग किए जाते हैं। ये एक विशिष्ट क्लाइंट और संसाधन से जुड़े होते हैं।
|
||||
- **Refresh tokens**: नए access tokens प्राप्त करने के लिए अनुप्रयोगों को जारी किए जाते हैं। इन्हें केवल उसी अनुप्रयोग द्वारा या अनुप्रयोगों के समूह द्वारा उपयोग किया जा सकता है जिनके लिए इन्हें जारी किया गया था।
|
||||
- **Primary Refresh Tokens (PRT)**: Azure AD से जुड़े, पंजीकृत, या हाइब्रिड जुड़े उपकरणों पर सिंगल साइन-ऑन के लिए उपयोग किए जाते हैं। इन्हें ब्राउज़र साइन-इन प्रवाह में और उपकरण पर मोबाइल और डेस्कटॉप अनुप्रयोगों में साइन इन करने के लिए उपयोग किया जा सकता है।
|
||||
- **Windows Hello for Business keys (WHFB)**: पासवर्ड रहित प्रमाणीकरण के लिए उपयोग किए जाते हैं। इसका उपयोग Primary Refresh Tokens प्राप्त करने के लिए किया जाता है।
|
||||
|
||||
टोकन का सबसे दिलचस्प प्रकार प्राइमरी रीफ्रेश टोकन (PRT) है।
|
||||
टोकन का सबसे दिलचस्प प्रकार Primary Refresh Token (PRT) है।
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### पिवोटिंग तकनीकें
|
||||
### Pivoting Techniques
|
||||
|
||||
**समझौता की गई मशीन से क्लाउड तक**:
|
||||
|
||||
- [**पास द कुकी**](az-pass-the-cookie.md): ब्राउज़र से Azure कुकीज़ चुराएं और लॉगिन करने के लिए उनका उपयोग करें
|
||||
- [**प्रक्रियाओं के एक्सेस टोकन डंप करें**](az-processes-memory-access-token.md): क्लाउड के साथ समन्वयित स्थानीय प्रक्रियाओं की मेमोरी को डंप करें (जैसे एक्सेल, Teams...) और स्पष्ट पाठ में एक्सेस टोकन खोजें।
|
||||
- [**प्राइमरी रीफ्रेश टोकन फ़िशिंग**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** इसका दुरुपयोग करने के लिए PRT को फ़िश करें
|
||||
- [**PRT पास करें**](pass-the-prt.md): Azure तक पहुँचने के लिए डिवाइस PRT चुराएं।
|
||||
- [**प्रमाणपत्र पास करें**](az-pass-the-certificate.md)**:** एक मशीन से दूसरी मशीन पर लॉगिन करने के लिए PRT के आधार पर एक प्रमाणपत्र उत्पन्न करें
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): ब्राउज़र से Azure कुकीज़ चुराना और उनका उपयोग करके लॉगिन करना
|
||||
- [**Dump processes access tokens**](az-processes-memory-access-token.md): क्लाउड के साथ समन्वयित स्थानीय प्रक्रियाओं की मेमोरी को डंप करना (जैसे excel, Teams...) और स्पष्ट पाठ में access tokens खोजना।
|
||||
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT को धोखा देकर इसका दुरुपयोग करना
|
||||
- [**Pass the PRT**](pass-the-prt.md): Azure तक पहुँचने के लिए डिवाइस PRT चुराना।
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md)**:** एक मशीन से दूसरी मशीन पर लॉगिन करने के लिए PRT के आधार पर एक प्रमाणपत्र उत्पन्न करना
|
||||
|
||||
**AD से समझौता करने से लेकर क्लाउड से समझौता करने और क्लाउड से AD से समझौता करने तक**:
|
||||
**AD से समझौता करने से लेकर क्लाउड तक और क्लाउड से AD तक समझौता करने**:
|
||||
|
||||
- [**Azure AD कनेक्ट**](azure-ad-connect-hybrid-identity/)
|
||||
- **क्लाउड से ऑन-प्रेम पर पिवोट करने का एक और तरीका है** [**Intune का दुरुपयोग करना**](../az-services/intune.md)
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
|
||||
- **क्लाउड से ऑन-प्रेम पर पिवट करने का एक और तरीका** [**Intune का दुरुपयोग करना**](../az-services/intune.md)
|
||||
|
||||
#### [Roadtx](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
यह उपकरण कई क्रियाएँ करने की अनुमति देता है जैसे Azure AD में एक मशीन को पंजीकृत करना ताकि PRT प्राप्त किया जा सके, और विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs (वैध या चुराए गए) का उपयोग करना। ये सीधे हमले नहीं हैं, लेकिन यह विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs के उपयोग को सुविधाजनक बनाता है। अधिक जानकारी के लिए देखें [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
|
||||
यह उपकरण कई कार्य करने की अनुमति देता है जैसे Azure AD में एक मशीन को पंजीकृत करना ताकि PRT प्राप्त किया जा सके, और विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs (वैध या चुराए गए) का उपयोग करना। ये सीधे हमले नहीं हैं, लेकिन यह विभिन्न तरीकों से संसाधनों तक पहुँचने के लिए PRTs के उपयोग को सुविधाजनक बनाता है। अधिक जानकारी के लिए देखें [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
|
||||
|
||||
+8
-8
@@ -11,9 +11,9 @@ Azure Arc नए आंतरिक सर्वरों (जुड़े ह
|
||||
1. स्थानीय डोमेन के भीतर Azure Arc Servers Onboarding GPO बनाती है।
|
||||
2. EnableAzureArc.ps1 ऑनबोर्डिंग स्क्रिप्ट को ऑनबोर्डिंग प्रक्रिया के लिए बनाए गए निर्दिष्ट नेटवर्क शेयर में कॉपी करती है, जिसमें Windows इंस्टॉलर पैकेज भी शामिल है।
|
||||
|
||||
इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम जैसे अन्य पैरामीटर की भी आवश्यकता होती है। स्क्रिप्ट को टेनेट ID, संसाधन समूह, और अन्य आवश्यक जानकारी भी प्रदान करनी होती है।
|
||||
इस स्क्रिप्ट को चलाते समय, सिस्टम प्रशासकों को दो मुख्य पैरामीटर प्रदान करने की आवश्यकता होती है: **ServicePrincipalId** और **ServicePrincipalClientSecret**। इसके अतिरिक्त, इसमें अन्य पैरामीटर जैसे डोमेन, शेयर होस्ट करने वाले सर्वर का FQDN, और शेयर नाम की आवश्यकता होती है। स्क्रिप्ट को टेनेट ID, संसाधन समूह, और अन्य आवश्यक जानकारी भी प्रदान करनी होती है।
|
||||
|
||||
DPAPI-NG एन्क्रिप्शन का उपयोग करके निर्दिष्ट शेयर पर AzureArcDeploy निर्देशिका में एक एन्क्रिप्टेड सीक्रेट उत्पन्न किया जाता है। एन्क्रिप्टेड सीक्रेट को encryptedServicePrincipalSecret नामक फ़ाइल में संग्रहीत किया जाता है। इसका प्रमाण DeployGPO.ps1 स्क्रिप्ट में पाया जा सकता है, जहां एन्क्रिप्शन को $descriptor और $ServicePrincipalSecret को इनपुट के रूप में कॉल करके ProtectBase64 द्वारा किया जाता है। डिस्क्रिप्टर में 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 सुरक्षा समूहों द्वारा डिक्रिप्ट किया जा सकता है, जैसा कि स्क्रिप्ट टिप्पणियों में उल्लेख किया गया है।
|
||||
```powershell
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -26,16 +26,16 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
|
||||
|
||||
हमारे पास निम्नलिखित शर्तें हैं:
|
||||
|
||||
1. हम आंतरिक नेटवर्क में सफलतापूर्वक प्रवेश कर चुके हैं।
|
||||
1. हम सफलतापूर्वक आंतरिक नेटवर्क में प्रवेश कर चुके हैं।
|
||||
2. हमारे पास Active Directory के भीतर एक कंप्यूटर खाते को बनाने या उस पर नियंत्रण करने की क्षमता है।
|
||||
3. हमने AzureArcDeploy निर्देशिका को समाहित करने वाले एक नेटवर्क शेयर का पता लगाया है।
|
||||
3. हमने AzureArcDeploy निर्देशिका को शामिल करने वाले एक नेटवर्क शेयर का पता लगाया है।
|
||||
|
||||
AD वातावरण में एक मशीन खाते को प्राप्त करने के कई तरीके हैं। सबसे सामान्य तरीकों में से एक मशीन खाता कोटा का शोषण करना है। एक और तरीका कमजोर ACLs या विभिन्न अन्य गलत कॉन्फ़िगरेशन के माध्यम से मशीन खाते से समझौता करना है।
|
||||
AD वातावरण के भीतर एक मशीन खाते को प्राप्त करने के कई तरीके हैं। सबसे सामान्य तरीकों में से एक मशीन खाता कोटा का शोषण करना है। एक और तरीका कमजोर ACLs या विभिन्न अन्य गलत कॉन्फ़िगरेशन के माध्यम से मशीन खाते से समझौता करना है।
|
||||
```powershell
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
```
|
||||
एक बार मशीन खाता प्राप्त हो जाने पर, इस खाते का उपयोग करके प्रमाणीकरण करना संभव है। हम या तो netonly ध्वज के साथ runas.exe कमांड का उपयोग कर सकते हैं या Rubeus.exe के साथ पास-दी-टिकट का उपयोग कर सकते हैं।
|
||||
एक बार मशीन खाता प्राप्त हो जाने पर, इस खाते का उपयोग करके प्रमाणीकरण करना संभव है। हम या तो netonly ध्वज के साथ runas.exe कमांड का उपयोग कर सकते हैं या Rubeus.exe के साथ पास-थ-टिकट का उपयोग कर सकते हैं।
|
||||
```powershell
|
||||
runas /user:fake01$ /netonly powershell
|
||||
```
|
||||
@@ -43,7 +43,7 @@ runas /user:fake01$ /netonly powershell
|
||||
```powershell
|
||||
.\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr
|
||||
```
|
||||
हमारी कंप्यूटर खाता के लिए TGT को मेमोरी में संग्रहीत करके, हम सेवा प्रमुख गुप्त को डिक्रिप्ट करने के लिए निम्नलिखित स्क्रिप्ट का उपयोग कर सकते हैं।
|
||||
हमारी कंप्यूटर खाता के लिए TGT को मेमोरी में संग्रहीत करके, हम सेवा प्रमुख रहस्य को डिक्रिप्ट करने के लिए निम्नलिखित स्क्रिप्ट का उपयोग कर सकते हैं।
|
||||
```powershell
|
||||
Import-Module .\AzureArcDeployment.psm1
|
||||
|
||||
@@ -54,7 +54,7 @@ $ebs
|
||||
```
|
||||
वैकल्पिक रूप से, हम [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG) का उपयोग कर सकते हैं।
|
||||
|
||||
इस बिंदु पर, हम ArcInfo.json फ़ाइल से Azure से कनेक्ट करने के लिए आवश्यक शेष जानकारी एकत्र कर सकते हैं, जो कि encryptedServicePrincipalSecret फ़ाइल के समान नेटवर्क शेयर पर संग्रहीत है। इस फ़ाइल में विवरण शामिल हैं जैसे: TenantId, servicePrincipalClientId, ResourceGroup, और अधिक। इस जानकारी के साथ, हम Azure CLI का उपयोग करके समझौता किए गए सेवा प्रमुख के रूप में प्रमाणीकरण कर सकते हैं।
|
||||
इस बिंदु पर, हम ArcInfo.json फ़ाइल से Azure से कनेक्ट करने के लिए आवश्यक शेष जानकारी एकत्र कर सकते हैं, जो एन्क्रिप्टेडServicePrincipalSecret फ़ाइल के समान नेटवर्क शेयर पर संग्रहीत है। इस फ़ाइल में विवरण शामिल हैं: TenantId, servicePrincipalClientId, ResourceGroup, और अधिक। इस जानकारी के साथ, हम Azure CLI का उपयोग करके समझौता किए गए सेवा प्रमुख के रूप में प्रमाणीकरण कर सकते हैं।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
+2
-2
@@ -29,11 +29,11 @@ Azure PowerShell भी टोकन और संवेदनशील डे
|
||||
|
||||
## Security Recommendations
|
||||
|
||||
संवेदनशील डेटा के स्पष्ट पाठ में संग्रहीत होने को देखते हुए, इन फ़ाइलों और निर्देशिकाओं को सुरक्षित करना महत्वपूर्ण है:
|
||||
संवेदनशील डेटा को स्पष्ट पाठ में संग्रहीत करने को देखते हुए, इन फ़ाइलों और निर्देशिकाओं को सुरक्षित करना महत्वपूर्ण है:
|
||||
|
||||
- इन फ़ाइलों के लिए एक्सेस अधिकारों को सीमित करना।
|
||||
- अनधिकृत एक्सेस या अप्रत्याशित परिवर्तनों के लिए इन निर्देशिकाओं की नियमित रूप से निगरानी और ऑडिट करना।
|
||||
- जहां संभव हो, संवेदनशील फ़ाइलों के लिए एन्क्रिप्शन का उपयोग करना।
|
||||
- उपयोगकर्ताओं को ऐसे संवेदनशील जानकारी को संभालने के लिए जोखिमों और सर्वोत्तम प्रथाओं के बारे में शिक्षित करना।
|
||||
- उपयोगकर्ताओं को ऐसे संवेदनशील जानकारी को संभालने के जोखिमों और सर्वोत्तम प्रथाओं के बारे में शिक्षित करना।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+7
-7
@@ -4,13 +4,13 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Azure में जुड़े मशीनों पर, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणित करना संभव है जो **Azure AD CA द्वारा आवश्यक उपयोगकर्ता के लिए जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
Azure में जुड़े मशीनों में, एक मशीन से दूसरी मशीन पर प्रमाणपत्रों का उपयोग करके प्रमाणित करना संभव है जो **Azure AD CA द्वारा आवश्यक उपयोगकर्ता के लिए जारी किए जाने चाहिए** (विषय के रूप में) जब दोनों मशीनें **NegoEx** प्रमाणीकरण तंत्र का समर्थन करती हैं।
|
||||
|
||||
बहुत सरल शब्दों में:
|
||||
|
||||
- कनेक्शन शुरू करने वाली मशीन (क्लाइंट) को **उपयोगकर्ता के लिए Azure AD से एक प्रमाणपत्र की आवश्यकता होती है**।
|
||||
- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) का उपयोग करके साइन करता है और **इसे Azure AD को भेजता है**।
|
||||
- Azure AD JWT हस्ताक्षर को क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके सत्यापित करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
- क्लाइंट एक JSON वेब टोकन (JWT) हेडर बनाता है जिसमें PRT और अन्य विवरण होते हैं, इसे व्युत्पन्न कुंजी (सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके) से साइन करता है और **इसे Azure AD को भेजता है**।
|
||||
- Azure AD क्लाइंट सत्र कुंजी और सुरक्षा संदर्भ का उपयोग करके JWT हस्ताक्षर की पुष्टि करता है, PRT की वैधता की जांच करता है और **प्रतिक्रिया** में **प्रमाणपत्र** भेजता है।
|
||||
|
||||
इस परिदृश्य में और [**Pass the PRT**](pass-the-prt.md) हमले के लिए आवश्यक सभी जानकारी प्राप्त करने के बाद:
|
||||
|
||||
@@ -20,16 +20,16 @@ Azure में जुड़े मशीनों पर, एक मशीन
|
||||
- सुरक्षा संदर्भ
|
||||
- व्युत्पन्न कुंजी
|
||||
|
||||
उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **मांगना संभव है**:
|
||||
उपकरण [**PrtToCert**](https://github.com/morRubin/PrtToCert)** के लिए उपयोगकर्ता के लिए **P2P प्रमाणपत्र** **मांगना संभव है**।
|
||||
```bash
|
||||
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
|
||||
```
|
||||
सर्टिफिकेट्स की अवधि PRT के समान होगी। सर्टिफिकेट का उपयोग करने के लिए, आप पायथन टूल [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) का उपयोग कर सकते हैं जो **remote machine** पर **authenticate** करेगा, **PSEXEC** चलाएगा और पीड़ित मशीन पर **CMD** खोलेगा। इससे हमें Mimikatz का फिर से उपयोग करने की अनुमति मिलेगी ताकि हम किसी अन्य उपयोगकर्ता का PRT प्राप्त कर सकें।
|
||||
प्रमाणपत्रों की अवधि PRT के समान होगी। प्रमाणपत्र का उपयोग करने के लिए, आप python टूल [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) का उपयोग कर सकते हैं जो दूरस्थ मशीन पर **प्रमाणित** करेगा, **PSEXEC** चलाएगा और पीड़ित मशीन पर **CMD** खोलेगा। इससे हमें Mimikatz का फिर से उपयोग करने की अनुमति मिलेगी ताकि हम किसी अन्य उपयोगकर्ता का PRT प्राप्त कर सकें।
|
||||
```bash
|
||||
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- 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}}
|
||||
|
||||
+4
-4
@@ -4,7 +4,7 @@
|
||||
|
||||
## Why Cookies?
|
||||
|
||||
ब्राउज़र **cookies** प्रमाणीकरण और MFA को **बायपास** करने का एक शानदार तंत्र हैं। क्योंकि उपयोगकर्ता पहले ही एप्लिकेशन में प्रमाणीकरण कर चुका है, सत्र **cookie** का उपयोग उस उपयोगकर्ता के रूप में **डेटा** तक पहुँचने के लिए किया जा सकता है, बिना पुनः प्रमाणीकरण की आवश्यकता के।
|
||||
Browser **cookies** प्रमाणीकरण और MFA को **बायपास** करने के लिए एक शानदार तंत्र हैं। क्योंकि उपयोगकर्ता पहले ही एप्लिकेशन में प्रमाणीकरण कर चुका है, सत्र **cookie** का उपयोग उस उपयोगकर्ता के रूप में **डेटा** तक पहुँचने के लिए किया जा सकता है, बिना पुनः प्रमाणीकरण की आवश्यकता के।
|
||||
|
||||
आप देख सकते हैं कि **ब्राउज़र कुकीज़ कहाँ स्थित हैं**:
|
||||
|
||||
@@ -14,7 +14,7 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
## Attack
|
||||
|
||||
चुनौतीपूर्ण भाग यह है कि वे **cookies एन्क्रिप्टेड** हैं **उपयोगकर्ता** के लिए Microsoft Data Protection API (**DPAPI**) के माध्यम से। यह एन्क्रिप्टेड है [उपयोगकर्ता से जुड़े क्रिप्टोग्राफिक कुंजी](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) का उपयोग करके जिनसे कुकीज़ संबंधित हैं। आप इसके बारे में अधिक जानकारी यहाँ पा सकते हैं:
|
||||
चुनौतीपूर्ण भाग यह है कि वे **कुकीज़ एन्क्रिप्टेड** हैं उपयोगकर्ता के लिए Microsoft Data Protection API (**DPAPI**) के माध्यम से। यह एन्क्रिप्टेड है [उपयोगकर्ता से जुड़े क्रिप्टोग्राफिक कुंजी](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) का उपयोग करके जिनकी कुकीज़ हैं। आप इसके बारे में अधिक जानकारी यहाँ पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords
|
||||
@@ -24,11 +24,11 @@ Mimikatz के साथ, मैं इस कमांड के साथ **
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
For Azure, हम प्रमाणीकरण कुकीज़ के बारे में चिंतित हैं जिनमें **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, और **`ESTSAUTHLIGHT`** शामिल हैं। ये वहाँ हैं क्योंकि उपयोगकर्ता हाल ही में Azure पर सक्रिय रहा है।
|
||||
Azure के लिए, हम प्रमाणीकरण कुकीज़ के बारे में चिंतित हैं जिनमें **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, और **`ESTSAUTHLIGHT`** शामिल हैं। ये इसलिए हैं क्योंकि उपयोगकर्ता हाल ही में Azure पर सक्रिय रहा है।
|
||||
|
||||
बस login.microsoftonline.com पर जाएं और कुकी **`ESTSAUTHPERSISTENT`** (जो “Stay Signed In” विकल्प द्वारा उत्पन्न होती है) या **`ESTSAUTH`** जोड़ें। और आप प्रमाणित हो जाएंगे।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/](https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/)
|
||||
|
||||
|
||||
+1
-1
@@ -2,6 +2,6 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**पोस्ट देखें** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) हालांकि इसी विषय पर एक और पोस्ट [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) पर मिल सकती है।
|
||||
**इस पोस्ट को देखें** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) हालांकि इसी विषय पर एक और पोस्ट [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) में मिल सकती है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
-2
@@ -4,13 +4,13 @@
|
||||
|
||||
## **बुनियादी जानकारी**
|
||||
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में समझाया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **स्मृति में स्पष्ट-टेक्स्ट में एक्सेस टोकन स्टोर कर सकते हैं**। इसलिए केवल **प्रक्रिया की** **स्मृति** को **डंप** करना और **JWT टोकन के लिए grep करना** आपको क्लाउड में MFA को बायपास करते हुए पीड़ित के कई संसाधनों तक पहुंच प्रदान कर सकता है।
|
||||
जैसा कि [**इस वीडियो**](https://www.youtube.com/watch?v=OHKZkXC4Duw) में समझाया गया है, कुछ Microsoft सॉफ़्टवेयर जो क्लाउड के साथ समन्वयित होते हैं (Excel, Teams...) **स्मृति में स्पष्ट-टेक्स्ट में एक्सेस टोकन स्टोर कर सकते हैं**। इसलिए केवल **प्रक्रिया की स्मृति को डंप करना** और **JWT टोकन के लिए grep करना** आपको क्लाउड में कई संसाधनों पर पहुंच प्रदान कर सकता है, MFA को बायपास करते हुए।
|
||||
|
||||
चरण:
|
||||
|
||||
1. अपने पसंदीदा टूल के साथ EntraID उपयोगकर्ता के साथ समन्वयित एक्सेल प्रक्रियाओं को डंप करें।
|
||||
2. चलाएँ: `string excel.dmp | grep 'eyJ0'` और आउटपुट में कई टोकन खोजें
|
||||
3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर लगते हैं और उनके ऊपर टूल चलाएँ:
|
||||
3. उन टोकनों को खोजें जो आपको सबसे अधिक रुचिकर हैं और उनके ऊपर टूल चलाएँ:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
+15
-15
@@ -8,42 +8,42 @@
|
||||
|
||||
### Trust
|
||||
|
||||
जब Azure AD के साथ एक ट्रस्ट स्थापित किया जाता है, तो **AD में एक Read Only Domain Controller (RODC) बनाया जाता है।** **RODC कंप्यूटर खाता**, जिसका नाम **`AzureADKerberos$`** है। इसके अलावा, एक द्वितीयक `krbtgt` खाता जिसका नाम **`krbtgt_AzureAD`** है। यह खाता उन **Kerberos कुंजियों** को रखता है जो Azure AD टिकटों के लिए बनाता है।
|
||||
जब Azure AD के साथ एक ट्रस्ट स्थापित किया जाता है, तो **एक Read Only Domain Controller (RODC) AD में बनाया जाता है।** **RODC कंप्यूटर खाता**, जिसका नाम **`AzureADKerberos$`** है। इसके अलावा, एक द्वितीयक `krbtgt` खाता जिसका नाम **`krbtgt_AzureAD`** है। यह खाता **Kerberos कुंजियों** को रखता है जो Azure AD टिकटों के लिए उपयोग करता है।
|
||||
|
||||
इसलिए, यदि यह खाता समझौता कर लिया जाता है, तो किसी भी उपयोगकर्ता का अनुकरण करना संभव हो सकता है... हालाँकि यह सच नहीं है क्योंकि इस खाते को डोमेन एडमिन, एंटरप्राइज एडमिन, प्रशासकों जैसे किसी सामान्य विशेषाधिकार प्राप्त AD समूह के लिए टिकट बनाने से रोका गया है...
|
||||
इसलिए, यदि यह खाता समझौता कर लिया जाता है, तो किसी भी उपयोगकर्ता का अनुकरण करना संभव हो सकता है... हालाँकि यह सच नहीं है क्योंकि इस खाते को किसी सामान्य विशेषाधिकार प्राप्त AD समूह जैसे Domain Admins, Enterprise Admins, Administrators के लिए टिकट बनाने से रोका गया है...
|
||||
|
||||
> [!CAUTION]
|
||||
> हालाँकि, एक वास्तविक परिदृश्य में ऐसे विशेषाधिकार प्राप्त उपयोगकर्ता होंगे जो उन समूहों में नहीं हैं। इसलिए **नया krbtgt खाता, यदि समझौता कर लिया जाए, तो उनका अनुकरण करने के लिए उपयोग किया जा सकता है।**
|
||||
> हालाँकि, एक वास्तविक परिदृश्य में ऐसे विशेषाधिकार प्राप्त उपयोगकर्ता होंगे जो उन समूहों में नहीं हैं। इसलिए **नया krbtgt खाता, यदि समझौता किया गया, तो उनका अनुकरण करने के लिए उपयोग किया जा सकता है।**
|
||||
|
||||
### Kerberos TGT
|
||||
|
||||
इसके अलावा, जब एक उपयोगकर्ता Windows पर हाइब्रिड पहचान का उपयोग करके प्रमाणीकरण करता है, तो **Azure AD एक आंशिक Kerberos टिकट के साथ PRT जारी करेगा।** TGT आंशिक है क्योंकि **AzureAD के पास ऑन-प्रिम AD में उपयोगकर्ता की सीमित जानकारी** है (जैसे सुरक्षा पहचानकर्ता (SID) और नाम)।\
|
||||
इसके अलावा, जब एक उपयोगकर्ता Windows पर हाइब्रिड पहचान का उपयोग करके प्रमाणीकरण करता है, तो **Azure AD एक आंशिक Kerberos टिकट के साथ PRT जारी करेगा।** TGT आंशिक है क्योंकि **AzureAD के पास ऑन-प्रेम AD में उपयोगकर्ता की सीमित जानकारी** है (जैसे सुरक्षा पहचानकर्ता (SID) और नाम)।\
|
||||
Windows तब **इस आंशिक TGT को पूर्ण TGT के लिए विनिमय कर सकता है** `krbtgt` सेवा के लिए सेवा टिकट का अनुरोध करके।
|
||||
|
||||
### NTLM
|
||||
|
||||
चूंकि ऐसी सेवाएँ हो सकती हैं जो kerberos प्रमाणीकरण का समर्थन नहीं करती हैं बल्कि NTLM करती हैं, इसलिए एक **आंशिक TGT का अनुरोध करना संभव है जो एक द्वितीयक `krbtgt`** कुंजी का उपयोग करके हस्ताक्षरित है जिसमें **`KERB-KEY-LIST-REQ`** फ़ील्ड को **PADATA** अनुरोध के भाग में शामिल किया गया है और फिर एक पूर्ण TGT प्राप्त करें जो प्राथमिक `krbtgt` कुंजी के साथ हस्ताक्षरित है **जो प्रतिक्रिया में NT हैश को शामिल करता है**।
|
||||
चूंकि ऐसी सेवाएँ हो सकती हैं जो kerberos प्रमाणीकरण का समर्थन नहीं करती हैं बल्कि NTLM करती हैं, इसलिए **एक आंशिक TGT को द्वितीयक `krbtgt`** कुंजी का उपयोग करके हस्ताक्षरित करने के लिए अनुरोध करना संभव है जिसमें **`KERB-KEY-LIST-REQ`** फ़ील्ड को **PADATA** अनुरोध के भाग में शामिल किया गया है और फिर एक पूर्ण TGT प्राप्त करें जो प्राथमिक `krbtgt` कुंजी के साथ हस्ताक्षरित हो **NT है।** उत्तर में हैश।
|
||||
|
||||
## Abusing Cloud Kerberos Trust to obtain Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
|
||||
जब AzureAD एक **आंशिक TGT** उत्पन्न करता है, तो यह उपयोगकर्ता के बारे में उसके पास मौजूद विवरण का उपयोग करेगा। इसलिए, यदि एक ग्लोबल एडमिन डेटा को संशोधित कर सकता है जैसे कि **AzureAD में उपयोगकर्ता का सुरक्षा पहचानकर्ता और नाम**, जब उस उपयोगकर्ता के लिए TGT का अनुरोध किया जाता है, तो **सुरक्षा पहचानकर्ता एक अलग होगा**।
|
||||
जब AzureAD एक **आंशिक TGT** उत्पन्न करता है, तो यह उपयोगकर्ता के बारे में उसके पास मौजूद विवरण का उपयोग करेगा। इसलिए, यदि एक Global Admin उपयोगकर्ता के AzureAD में **सुरक्षा पहचानकर्ता और नाम** जैसे डेटा को संशोधित कर सकता है, तो उस उपयोगकर्ता के लिए TGT का अनुरोध करते समय **सुरक्षा पहचानकर्ता एक अलग होगा**।
|
||||
|
||||
यह Microsoft Graph या Azure AD Graph के माध्यम से करना संभव नहीं है, लेकिन **API Active Directory Connect** का उपयोग करना संभव है जो समन्वयित उपयोगकर्ताओं को बनाने और अपडेट करने के लिए उपयोग किया जाता है, जिसे ग्लोबल एडमिन्स द्वारा **किसी भी हाइब्रिड उपयोगकर्ता के SAM नाम और SID को संशोधित करने के लिए उपयोग किया जा सकता है**, और फिर यदि हम प्रमाणीकरण करते हैं, तो हमें संशोधित SID वाला आंशिक TGT प्राप्त होता है।
|
||||
यह Microsoft Graph या Azure AD Graph के माध्यम से करना संभव नहीं है, लेकिन **API Active Directory Connect** का उपयोग करके किया जा सकता है जिसका उपयोग Global Admins **किसी भी हाइब्रिड उपयोगकर्ता के SAM नाम और SID को संशोधित करने के लिए** कर सकते हैं, और फिर यदि हम प्रमाणीकरण करते हैं, तो हमें संशोधित SID वाला आंशिक TGT प्राप्त होता है।
|
||||
|
||||
ध्यान दें कि हम इसे AADInternals के साथ कर सकते हैं और [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet के माध्यम से समन्वयित उपयोगकर्ताओं को अपडेट कर सकते हैं।
|
||||
ध्यान दें कि हम AADInternals के साथ यह कर सकते हैं और [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet के माध्यम से समन्वयित उपयोगकर्ताओं को अपडेट कर सकते हैं।
|
||||
|
||||
### Attack prerequisites <a href="#attack-prerequisites" id="attack-prerequisites"></a>
|
||||
|
||||
हमले की सफलता और डोमेन एडमिन विशेषाधिकारों की प्राप्ति कुछ पूर्वापेक्षाओं को पूरा करने पर निर्भर करती है:
|
||||
हमले की सफलता और Domain Admin विशेषाधिकारों की प्राप्ति कुछ पूर्वापेक्षाओं को पूरा करने पर निर्भर करती है:
|
||||
|
||||
- समन्वय API के माध्यम से खातों को बदलने की क्षमता महत्वपूर्ण है। यह ग्लोबल एडमिन की भूमिका या AD Connect समन्वय खाता होने से प्राप्त किया जा सकता है। वैकल्पिक रूप से, हाइब्रिड आइडेंटिटी एडमिनिस्ट्रेटर की भूमिका भी पर्याप्त होगी, क्योंकि यह AD Connect को प्रबंधित करने और नए समन्वय खातों की स्थापना की अनुमति देती है।
|
||||
- एक **हाइब्रिड खाता** होना आवश्यक है। इस खाते को पीड़ित खाते के विवरण के साथ संशोधित करने के लिए अनुकूल होना चाहिए और प्रमाणीकरण के लिए भी सुलभ होना चाहिए।
|
||||
- सक्रिय निर्देशिका में एक **लक्षित पीड़ित खाता** की पहचान करना आवश्यक है। हालाँकि हमले को पहले से समन्वयित किसी भी खाते पर निष्पादित किया जा सकता है, Azure AD टेनेट को ऑन-प्रिमिस सुरक्षा पहचानकर्ताओं को पुन: उत्पन्न नहीं करना चाहिए, जिससे टिकट प्राप्त करने के लिए एक असमर्थित खाते को संशोधित करने की आवश्यकता होती है।
|
||||
- इसके अलावा, इस खाते में डोमेन एडमिन समकक्ष विशेषाधिकार होना चाहिए लेकिन इसे सामान्य AD प्रशासक समूहों का सदस्य नहीं होना चाहिए ताकि AzureAD RODC द्वारा अमान्य TGT उत्पन्न करने से बचा जा सके।
|
||||
- सबसे उपयुक्त लक्ष्य **AD Connect Sync सेवा द्वारा उपयोग किया जाने वाला सक्रिय निर्देशिका खाता है**। यह खाता Azure AD के साथ समन्वयित नहीं है, जिससे इसका SID एक संभावित लक्ष्य बन जाता है, और यह स्वाभाविक रूप से पासवर्ड हैश को समन्वयित करने की भूमिका के कारण डोमेन एडमिन समकक्ष विशेषाधिकार रखता है (मानते हुए कि पासवर्ड हैश समन्वय सक्रिय है)। एक्सप्रेस इंस्टॉलेशन वाले डोमेन के लिए, इस खाते का उपसर्ग **MSOL\_** है। अन्य उदाहरणों के लिए, खाते को डोमेन ऑब्जेक्ट पर निर्देशिका पुनरुत्पादन विशेषाधिकारों के साथ सभी खातों को सूचीबद्ध करके पहचाना जा सकता है।
|
||||
- Synchronization API के माध्यम से खातों को बदलने की क्षमता महत्वपूर्ण है। यह Global Admin की भूमिका या AD Connect समन्वय खाता होने से प्राप्त किया जा सकता है। वैकल्पिक रूप से, Hybrid Identity Administrator भूमिका भी पर्याप्त होगी, क्योंकि यह AD Connect को प्रबंधित करने और नए समन्वय खातों की स्थापना की अनुमति देती है।
|
||||
- **हाइब्रिड खाता** का होना आवश्यक है। इस खाते को पीड़ित खाते के विवरण के साथ संशोधन के लिए अनुकूल होना चाहिए और प्रमाणीकरण के लिए भी सुलभ होना चाहिए।
|
||||
- Active Directory में एक **लक्षित पीड़ित खाता** की पहचान करना आवश्यक है। हालाँकि हमले को पहले से समन्वयित किसी भी खाते पर निष्पादित किया जा सकता है, Azure AD टेनेट को ऑन-प्रेम सुरक्षा पहचानकर्ताओं को पुन: उत्पन्न नहीं करना चाहिए, जिससे टिकट प्राप्त करने के लिए एक असमर्थित खाते को संशोधित करने की आवश्यकता होती है।
|
||||
- इसके अलावा, इस खाते को डोमेन एडमिन समकक्ष विशेषाधिकार होना चाहिए लेकिन इसे सामान्य AD प्रशासक समूहों का सदस्य नहीं होना चाहिए ताकि AzureAD RODC द्वारा अमान्य TGT उत्पन्न करने से बचा जा सके।
|
||||
- सबसे उपयुक्त लक्ष्य **Active Directory खाता है जिसका उपयोग AD Connect Sync सेवा द्वारा किया जाता है।** यह खाता Azure AD के साथ समन्वयित नहीं है, जिससे इसका SID एक संभावित लक्ष्य बन जाता है, और यह स्वाभाविक रूप से डोमेन एडमिन समकक्ष विशेषाधिकार रखता है क्योंकि इसका उपयोग पासवर्ड हैश को समन्वयित करने में किया जाता है (मानते हुए कि पासवर्ड हैश समन्वय सक्रिय है)। एक्सप्रेस स्थापना वाले डोमेन के लिए, इस खाते का उपसर्ग **MSOL\_** है। अन्य उदाहरणों के लिए, इस खाते को डोमेन ऑब्जेक्ट पर निर्देशिका पुनरुत्पादन विशेषाधिकारों के साथ सभी खातों को सूचीबद्ध करके पहचाना जा सकता है।
|
||||
|
||||
### The full attack <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
|
||||
इसे मूल पोस्ट में चेक करें: [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/)
|
||||
Check it in the original post: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
-2
@@ -2,8 +2,8 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Check the techinque in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) and [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
**तकनीक की जांच करें:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) और [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
|
||||
ब्लॉग पोस्ट Azure AD में एक विशेषाधिकार वृद्धि की भेद्यता पर चर्चा करता है, जो एप्लिकेशन एडमिन या समझौता किए गए ऑन-प्रिमाइस सिंक खातों को एप्लिकेशनों को क्रेडेंशियल असाइन करके विशेषाधिकार बढ़ाने की अनुमति देता है। यह भेद्यता Azure AD के एप्लिकेशनों और सेवा प्रिंसिपलों के प्रबंधन के "डिजाइन द्वारा" व्यवहार से उत्पन्न होती है, जो विशेष रूप से डिफ़ॉल्ट Office 365 एप्लिकेशनों को प्रभावित करती है। हालांकि रिपोर्ट किया गया, यह मुद्दा Microsoft द्वारा भेद्यता के रूप में नहीं माना जाता है क्योंकि एडमिन अधिकार असाइनमेंट व्यवहार का दस्तावेजीकरण किया गया है। पोस्ट में विस्तृत तकनीकी अंतर्दृष्टि प्रदान की गई है और Azure AD वातावरण में सेवा प्रिंसिपल क्रेडेंशियल की नियमित समीक्षा करने की सलाह दी गई है। अधिक विस्तृत जानकारी के लिए, आप मूल ब्लॉग पोस्ट पर जा सकते हैं।
|
||||
ब्लॉग पोस्ट Azure AD में एक विशेषाधिकार वृद्धि की भेद्यता पर चर्चा करता है, जो एप्लिकेशन एडमिन या समझौता किए गए ऑन-प्रिमाइस सिंक खातों को एप्लिकेशनों को क्रेडेंशियल असाइन करके विशेषाधिकार बढ़ाने की अनुमति देता है। यह भेद्यता Azure AD के एप्लिकेशनों और सेवा प्रिंसिपलों के प्रबंधन के "डिजाइन द्वारा" व्यवहार से उत्पन्न होती है, जो विशेष रूप से डिफ़ॉल्ट Office 365 एप्लिकेशनों को प्रभावित करती है। हालांकि रिपोर्ट किया गया, यह मुद्दा Microsoft द्वारा विशेषाधिकार असाइनमेंट व्यवहार के दस्तावेजीकरण के कारण भेद्यता के रूप में नहीं माना जाता है। पोस्ट में विस्तृत तकनीकी अंतर्दृष्टि प्रदान की गई है और Azure AD वातावरण में सेवा प्रिंसिपल क्रेडेंशियल की नियमित समीक्षा की सलाह दी गई है। अधिक विस्तृत जानकारी के लिए, आप मूल ब्लॉग पोस्ट पर जा सकते हैं।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+6
-6
@@ -1,10 +1,10 @@
|
||||
# Az- Synchronising New Users
|
||||
# Az- नए उपयोगकर्ताओं का समन्वय
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Syncing AzureAD users to on-prem to escalate from on-prem to AzureAD
|
||||
## ऑन-प्रेम से AzureAD में बढ़ने के लिए AzureAD उपयोगकर्ताओं का समन्वय करना
|
||||
|
||||
AzureAD से **on-prem AD** में एक नए उपयोगकर्ता को समन्वयित करने के लिए ये आवश्यकताएँ हैं:
|
||||
AzureAD से **ऑन-प्रेम AD** में एक नए उपयोगकर्ता को समन्वयित करने के लिए ये आवश्यकताएँ हैं:
|
||||
|
||||
- **AzureAD उपयोगकर्ता** के पास एक प्रॉक्सी पता होना चाहिए (एक **मेलबॉक्स**)
|
||||
- लाइसेंस की आवश्यकता नहीं है
|
||||
@@ -12,12 +12,12 @@ AzureAD से **on-prem AD** में एक नए उपयोगकर्
|
||||
```powershell
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
जब AzureAD में ऐसे उपयोगकर्ता पाए जाते हैं, तो **on-prem AD से इसे एक्सेस करने के लिए** आपको बस **एक नया खाता बनाना** है जिसमें **proxyAddress** SMTP ईमेल हो।
|
||||
जब AzureAD में ऐसे उपयोगकर्ता पाए जाते हैं, तो **on-prem AD से इसे एक्सेस करने के लिए** आपको बस **एक नया खाता बनाना** होगा जिसमें **proxyAddress** SMTP ईमेल हो।
|
||||
|
||||
स्वचालित रूप से, यह उपयोगकर्ता **AzureAD से on-prem AD उपयोगकर्ता में सिंक हो जाएगा**।
|
||||
स्वतः, यह उपयोगकर्ता **AzureAD से on-prem AD उपयोगकर्ता के लिए सिंक हो जाएगा**।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि इस हमले को करने के लिए आपको **Domain Admin** की आवश्यकता नहीं है, आपको बस **नए उपयोगकर्ता बनाने** की अनुमति चाहिए।
|
||||
> ध्यान दें कि इस हमले को करने के लिए आपको **Domain Admin** की आवश्यकता नहीं है, आपको बस **नए उपयोगकर्ताओं को बनाने** के लिए अनुमतियाँ चाहिए।
|
||||
>
|
||||
> इसके अलावा, यह **MFA को बायपास नहीं करेगा**।
|
||||
>
|
||||
|
||||
+10
-10
@@ -24,7 +24,7 @@
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. प्रारंभ में, एक अनुप्रयोग (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोगकर्ता द्वारा एक्सेस किया जाता है। यह कदम बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जा सकता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।
|
||||
1. प्रारंभ में, एक अनुप्रयोग (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोगकर्ता द्वारा उपयोग किया जाता है। यह कदम बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जाता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।
|
||||
2. इसके बाद, SP उपयोगकर्ता प्रमाणीकरण के लिए उपयुक्त IdP (जैसे, AD FS, Okta) की पहचान करता है। फिर यह एक SAML (सिक्योरिटी असेर्शन मार्कअप लैंग्वेज) AuthnRequest तैयार करता है और क्लाइंट को चुने हुए IdP पर पुनः मार्गदर्शित करता है।
|
||||
3. IdP आगे बढ़ता है, उपयोगकर्ता को प्रमाणीकरण करता है। प्रमाणीकरण के बाद, IdP द्वारा एक SAMLResponse तैयार किया जाता है और उपयोगकर्ता के माध्यम से SP को अग्रेषित किया जाता है।
|
||||
4. अंततः, SP SAMLResponse का मूल्यांकन करता है। यदि सफलतापूर्वक मान्य किया गया, जो IdP के साथ एक विश्वास संबंध को इंगित करता है, तो उपयोगकर्ता को पहुंच दी जाती है। यह लॉगिन प्रक्रिया के पूर्ण होने का संकेत है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।
|
||||
@@ -39,31 +39,31 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
|
||||
- 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 हमला:**
|
||||
|
||||
- ADFS में, SAML Response को एक टोकन-हस्ताक्षर प्रमाणपत्र द्वारा हस्ताक्षरित किया जाता है।
|
||||
- ADFS में, SAML प्रतिक्रिया को एक टोकन-हस्ताक्षर प्रमाणपत्र द्वारा हस्ताक्षरित किया जाता है।
|
||||
- यदि प्रमाणपत्र से समझौता किया जाता है, तो Azure AD में किसी भी उपयोगकर्ता के रूप में प्रमाणीकरण करना संभव है जो Azure AD के साथ समन्वयित है!
|
||||
- हमारे PTA दुरुपयोग की तरह, एक उपयोगकर्ता के लिए पासवर्ड परिवर्तन या MFA का कोई प्रभाव नहीं होगा क्योंकि हम प्रमाणीकरण प्रतिक्रिया को जाली बना रहे हैं।
|
||||
- हमारे PTA दुरुपयोग की तरह, उपयोगकर्ता के लिए पासवर्ड परिवर्तन या MFA का कोई प्रभाव नहीं होगा क्योंकि हम प्रमाणीकरण प्रतिक्रिया को जाली बना रहे हैं।
|
||||
- प्रमाणपत्र को DA विशेषाधिकार के साथ AD FS सर्वर से निकाला जा सकता है और फिर इसे किसी भी इंटरनेट से जुड़े मशीन से उपयोग किया जा सकता है।
|
||||
- अधिक जानकारी [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) में है।
|
||||
|
||||
### गोल्डन SAML
|
||||
|
||||
वह प्रक्रिया जहां एक **पहचान प्रदाता (IdP)** उपयोगकर्ता साइन-इन को अधिकृत करने के लिए एक **SAMLResponse** उत्पन्न करता है, अत्यंत महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, **प्रतिक्रिया** को **हस्ताक्षरित** या **एन्क्रिप्टेड** किया जा सकता है **IdP की निजी कुंजी** का उपयोग करके। यह प्रक्रिया **सेवा प्रदाता (SP)** को SAMLResponse की प्रामाणिकता की पुष्टि करने की अनुमति देती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।
|
||||
एक **पहचान प्रदाता (IdP)** द्वारा उपयोगकर्ता साइन-इन को अधिकृत करने के लिए **SAMLResponse** उत्पन्न करने की प्रक्रिया महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, **प्रतिक्रिया** को **हस्ताक्षरित** या **एन्क्रिप्टेड** किया जा सकता है, जो **IdP की निजी कुंजी** का उपयोग करता है। यह प्रक्रिया **सेवा प्रदाता (SP)** को SAMLResponse की प्रामाणिकता की पुष्टि करने की अनुमति देती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।
|
||||
|
||||
[गोल्डन टिकट हमले](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket) के साथ एक समानांतर खींचा जा सकता है, जहां उपयोगकर्ता की पहचान और अनुमतियों (गोल्डन टिकट के लिए KRBTGT, गोल्डन SAML के लिए टोकन-हस्ताक्षर निजी कुंजी) को **प्रमाणीकरण वस्तु** (TGT या SAMLResponse) को जाली बनाने के लिए हेरफेर किया जा सकता है। यह किसी भी उपयोगकर्ता का अनुकरण करने की अनुमति देता है, SP तक अनधिकृत पहुंच प्रदान करता है।
|
||||
|
||||
गोल्डन SAML कुछ लाभ प्रदान करते हैं:
|
||||
|
||||
- इन्हें **दूर से** बनाया जा सकता है, बिना उस डोमेन या संघ का हिस्सा बने।
|
||||
- इन्हें **दूरस्थ रूप से** बनाया जा सकता है, बिना डोमेन या संघ का हिस्सा बने।
|
||||
- ये **दो-कारक प्रमाणीकरण (2FA)** सक्षम होने पर भी प्रभावी रहते हैं।
|
||||
- टोकन-हस्ताक्षर **निजी कुंजी स्वचालित रूप से नवीनीकरण नहीं होती**।
|
||||
- **एक उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता**।
|
||||
- टोकन-हस्ताक्षर **निजी कुंजी स्वचालित रूप से नवीनीकरण नहीं करती है**।
|
||||
- **उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता है**।
|
||||
|
||||
#### AWS + AD FS + गोल्डन SAML
|
||||
|
||||
@@ -133,7 +133,7 @@ Export-AADIntADFSSigningCertificate
|
||||
# Impersonate a user to to access cloud apps
|
||||
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
|
||||
```
|
||||
यह क्लाउड केवल उपयोगकर्ताओं का ImmutableID बनाना और उनकी नकल करना भी संभव है।
|
||||
यह भी संभव है कि केवल क्लाउड उपयोगकर्ताओं का ImmutableID बनाया जाए और उनकी नकल की जाए।
|
||||
```powershell
|
||||
# Create a realistic ImmutableID and set it for a cloud only user
|
||||
[System.Convert]::ToBase64String((New-Guid).tobytearray())
|
||||
|
||||
+14
-14
@@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **पासवर्ड हैश समन्वय** हाइब्रिड पहचान को पूरा करने के लिए उपयोग किए जाने वाले साइन-इन तरीकों में से एक है। **Azure AD Connect** एक ऑन-प्रिमाइस सक्रिय निर्देशिका उदाहरण से एक क्लाउड-आधारित Azure AD उदाहरण में एक उपयोगकर्ता के पासवर्ड का हैश, हैश का हैश समन्वय करता है।
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **पासवर्ड हैश समन्वय** हाइब्रिड पहचान को पूरा करने के लिए उपयोग किए जाने वाले साइन-इन तरीकों में से एक है। **Azure AD Connect** एक ऑन-प्रिमिस सक्रिय निर्देशिका उदाहरण से एक उपयोगकर्ता के पासवर्ड का हैश, हैश का हैश, एक क्लाउड-आधारित Azure AD उदाहरण में समन्वयित करता है।
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -13,33 +13,33 @@
|
||||
सभी **उपयोगकर्ता** और **पासवर्ड हैश का हैश** ऑन-प्रिम से Azure AD में समन्वयित होते हैं। हालाँकि, **स्पष्ट-पाठ पासवर्ड** या **मूल** **हैश** Azure AD को नहीं भेजे जाते।\
|
||||
इसके अलावा, **निर्मित** सुरक्षा समूह (जैसे डोमेन प्रशासक...) **Azure AD में समन्वयित नहीं होते**।
|
||||
|
||||
**हैश समन्वय** हर **2 मिनट** में होता है। हालाँकि, डिफ़ॉल्ट रूप से, **पासवर्ड समाप्ति** और **खाता** **समाप्ति** Azure AD में **समन्वयित नहीं होते**। इसलिए, एक उपयोगकर्ता जिसका **ऑन-प्रिम पासवर्ड समाप्त हो गया है** (बदला नहीं गया) पुरानी पासवर्ड का उपयोग करके **Azure संसाधनों** तक पहुँच जारी रख सकता है।
|
||||
**हैश समन्वय** हर **2 मिनट** में होता है। हालाँकि, डिफ़ॉल्ट रूप से, **पासवर्ड समाप्ति** और **खाता** **समाप्ति** Azure AD में **समन्वयित नहीं होते**। इसलिए, एक उपयोगकर्ता जिसका **ऑन-प्रिम पासवर्ड समाप्त हो गया है** (बदला नहीं गया) पुराने पासवर्ड का उपयोग करके **Azure संसाधनों** तक पहुँच जारी रख सकता है।
|
||||
|
||||
जब एक ऑन-प्रिम उपयोगकर्ता Azure संसाधन तक पहुँच प्राप्त करना चाहता है, तो **प्रमाणीकरण Azure AD पर होता है**।
|
||||
|
||||
**PHS** की आवश्यकता **पहचान सुरक्षा** और AAD डोमेन सेवाओं जैसी सुविधाओं के लिए होती है।
|
||||
**PHS** की आवश्यकता होती है जैसे **पहचान सुरक्षा** और AAD डोमेन सेवाओं के लिए।
|
||||
|
||||
## Pivoting
|
||||
|
||||
जब PHS कॉन्फ़िगर किया जाता है, तो कुछ **विशेषाधिकार प्राप्त खाते** स्वचालित रूप से **बनाए जाते हैं**:
|
||||
जब PHS कॉन्फ़िगर किया जाता है, तो कुछ **विशिष्ट खाते** स्वचालित रूप से **बनाए** जाते हैं:
|
||||
|
||||
- खाता **`MSOL_<installationID>`** ऑन-प्रिम AD में स्वचालित रूप से बनाया जाता है। इस खाते को **डायरेक्टरी समन्वय खाते** की भूमिका दी जाती है (देखें [दस्तावेज़](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) जिसका अर्थ है कि इसके पास **ऑन-प्रिम AD में पुनरुत्पादन (DCSync) अनुमतियाँ हैं**।
|
||||
- खाता **`MSOL_<installationID>`** स्वचालित रूप से ऑन-प्रिम AD में बनाया जाता है। इस खाते को **डायरेक्टरी समन्वय खाते** की भूमिका दी जाती है (देखें [दस्तावेज़](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) जिसका अर्थ है कि इसके पास **ऑन-प्रिम AD में पुनरुत्पादन (DCSync) अनुमतियाँ हैं**।
|
||||
- एक खाता **`Sync_<name of on-prem ADConnect Server>_installationID`** Azure AD में बनाया जाता है। इस खाते को Azure AD में **किसी भी उपयोगकर्ता** (समन्वयित या केवल क्लाउड) का पासवर्ड **रीसेट** करने की अनुमति है।
|
||||
|
||||
पिछले दो विशेषाधिकार प्राप्त खातों के पासवर्ड **SQL सर्वर में** संग्रहीत होते हैं जहाँ **Azure AD Connect स्थापित है।** व्यवस्थापक स्पष्ट-पाठ में उन विशेषाधिकार प्राप्त उपयोगकर्ताओं के पासवर्ड निकाल सकते हैं।\
|
||||
इन दो पूर्व विशेषाधिकार प्राप्त खातों के पासवर्ड **SQL सर्वर में** संग्रहीत होते हैं जहाँ **Azure AD Connect स्थापित है।** व्यवस्थापक स्पष्ट-पाठ में उन विशेषाधिकार प्राप्त उपयोगकर्ताओं के पासवर्ड निकाल सकते हैं।\
|
||||
डेटाबेस `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf` में स्थित है।
|
||||
|
||||
एक टेबल में से कॉन्फ़िगरेशन निकालना संभव है, जिसमें एक एन्क्रिप्टेड है:
|
||||
एक टेबल में से कॉन्फ़िगरेशन निकालना संभव है, जिसमें से एक एन्क्रिप्टेड है:
|
||||
|
||||
`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)।
|
||||
|
||||
### Finding the **Azure AD connect server**
|
||||
|
||||
यदि **सर्वर जहाँ Azure AD connect स्थापित है** डोमेन से जुड़ा हुआ है (दस्तावेज़ में अनुशंसित), तो इसे निम्नलिखित के साथ खोजा जा सकता है:
|
||||
यदि **सर्वर जहाँ Azure AD connect स्थापित है** डोमेन से जुड़ा है (दस्तावेज़ में अनुशंसित), तो इसे निम्नलिखित के साथ ढूंढना संभव है:
|
||||
```powershell
|
||||
# ActiveDirectory module
|
||||
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAccountName,Description | fl
|
||||
@@ -82,7 +82,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
|
||||
|
||||
# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
|
||||
```
|
||||
यह केवल **क्लाउड** उपयोगकर्ताओं के पासवर्ड को संशोधित करना भी संभव है (भले ही यह अप्रत्याशित हो)।
|
||||
यह केवल **क्लाउड** उपयोगकर्ताओं के पासवर्ड को **संशोधित** करना भी संभव है (भले ही यह अप्रत्याशित हो)।
|
||||
```powershell
|
||||
# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
|
||||
# The CloudAnchor is of the format USER_ObjectID.
|
||||
@@ -91,10 +91,10 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
|
||||
# Reset password
|
||||
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
|
||||
```
|
||||
यह उपयोगकर्ता का पासवर्ड डंप करना भी संभव है।
|
||||
इस उपयोगकर्ता का पासवर्ड डंप करना भी संभव है।
|
||||
|
||||
> [!CAUTION]
|
||||
> एक और विकल्प होगा **एक सेवा प्रमुख को विशेषाधिकार प्राप्त अनुमतियाँ सौंपना**, जिसे **Sync** उपयोगकर्ता **अनुमतियाँ** देने के लिए सक्षम है, और फिर **उस सेवा प्रमुख तक पहुँच प्राप्त करना** एक प्रिवेस्क के तरीके के रूप में।
|
||||
> एक और विकल्प होगा **एक सेवा प्रिंसिपल को विशेषाधिकार प्राप्त अनुमतियाँ सौंपना**, जिसे **Sync** उपयोगकर्ता **अनुमतियाँ** देने के लिए सक्षम है, और फिर **उस सेवा प्रिंसिपल तक पहुँच प्राप्त करना** एक तरीके के रूप में प्रिवेस्क के लिए।
|
||||
|
||||
### Seamless SSO
|
||||
|
||||
@@ -104,7 +104,7 @@ PHS के साथ Seamless SSO का उपयोग करना संभ
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
+34
-34
@@ -12,17 +12,17 @@ az-primary-refresh-token-prt.md
|
||||
```
|
||||
Dsregcmd.exe /status
|
||||
```
|
||||
In the SSO State section, you should see the **`AzureAdPrt`** set to **YES**.
|
||||
SSO State अनुभाग में, आपको **`AzureAdPrt`** **YES** पर सेट होना चाहिए।
|
||||
|
||||
<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
In the same output you can also see if the **device is joined to Azure** (in the field `AzureAdJoined`):
|
||||
एक ही आउटपुट में आप यह भी देख सकते हैं कि **डिवाइस Azure से जुड़ा है** (क्षेत्र `AzureAdJoined` में):
|
||||
|
||||
<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## PRT कुकी
|
||||
|
||||
The PRT cookie is actually called **`x-ms-RefreshTokenCredential`** and it's a JSON Web Token (JWT). A JWT contains **3 parts**, the **header**, **payload** and **signature**, divided by a `.` and all url-safe base64 encoded. A typical PRT cookie contains the following header and body:
|
||||
PRT कुकी वास्तव में **`x-ms-RefreshTokenCredential`** कहलाती है और यह एक JSON वेब टोकन (JWT) है। एक JWT में **3 भाग** होते हैं, **header**, **payload** और **signature**, जो `.` द्वारा विभाजित होते हैं और सभी url-safe base64 में एन्कोडेड होते हैं। एक सामान्य PRT कुकी में निम्नलिखित header और body होती है:
|
||||
```json
|
||||
{
|
||||
"alg": "HS256",
|
||||
@@ -34,33 +34,33 @@ The PRT cookie is actually called **`x-ms-RefreshTokenCredential`** and it's a J
|
||||
"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
|
||||
}
|
||||
```
|
||||
The actual **Primary Refresh Token (PRT)** is encapsulated within the **`refresh_token`**, which is encrypted by a key under the control of Azure AD, rendering its contents opaque and undecryptable to us. The field **`is_primary`** signifies the encapsulation of the primary refresh token within this token. To ensure that the cookie remains bound to the specific login session it was intended for, the `request_nonce` is transmitted from the `logon.microsoftonline.com` page.
|
||||
वास्तविक **Primary Refresh Token (PRT)** **`refresh_token`** के भीतर संकुचित है, जिसे Azure AD के नियंत्रण में एक कुंजी द्वारा एन्क्रिप्ट किया गया है, जिससे इसकी सामग्री हमारे लिए अपारदर्शी और अव्याख्येय हो जाती है। फ़ील्ड **`is_primary`** इस टोकन के भीतर प्राथमिक रिफ्रेश टोकन के संकुचन को दर्शाता है। यह सुनिश्चित करने के लिए कि कुकी उस विशेष लॉगिन सत्र से बंधी रहे जिसके लिए इसे बनाया गया था, `request_nonce` को `logon.microsoftonline.com` पृष्ठ से भेजा जाता है।
|
||||
|
||||
### PRT Cookie flow using TPM
|
||||
### PRT कुकी प्रवाह TPM का उपयोग करते हुए
|
||||
|
||||
The **LSASS** process will send to the TPM the **KDF context**, and the TPM will used **session key** (gathered when the device was registered in AzureAD and stored in the TPM) and the previous context to **derivate** a **key,** and this **derived key** is used to **sign the PRT cookie (JWT).**
|
||||
**LSASS** प्रक्रिया TPM को **KDF संदर्भ** भेजेगी, और TPM **सत्र कुंजी** (जो AzureAD में डिवाइस पंजीकरण के समय एकत्र की गई थी और TPM में संग्रहीत है) और पिछले संदर्भ का उपयोग करके एक **कुंजी** उत्पन्न करेगा, और यह **उत्पन्न कुंजी** **PRT कुकी (JWT)** पर हस्ताक्षर करने के लिए उपयोग की जाती है।
|
||||
|
||||
The **KDF context is** a nonce from AzureAD and the PRT creating a **JWT** mixed with a **context** (random bytes).
|
||||
**KDF संदर्भ** AzureAD से एक नॉनस और PRT को मिलाकर एक **JWT** है जिसमें एक **संदर्भ** (यादृच्छिक बाइट्स) है।
|
||||
|
||||
Therefore, even if the PRT cannot be extracted because it's located inside the TPM, it's possible to abuseLSASS to **request derived keys from new contexts and use the generated keys to sign Cookies**.
|
||||
इसलिए, भले ही PRT को निकाला नहीं जा सकता क्योंकि यह TPM के भीतर स्थित है, LSASS का दुरुपयोग करके **नए संदर्भों से उत्पन्न कुंजी का अनुरोध करना और उत्पन्न कुंजी का उपयोग करके कुकी पर हस्ताक्षर करना संभव है**।
|
||||
|
||||
<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## PRT Abuse Scenarios
|
||||
## PRT दुरुपयोग परिदृश्य
|
||||
|
||||
As a **regular user** it's possible to **request PRT usage** by asking LSASS for SSO data.\
|
||||
This can be done like **native apps** which request tokens from **Web Account Manager** (token broker). WAM pasess the request to **LSASS**, which asks for tokens using signed PRT assertion. Or it can be down with **browser based (web) flow**s where a **PRT cookie** is used as **header** to authenticate requests to Azure AS login pages.
|
||||
एक **सामान्य उपयोगकर्ता** के रूप में, **SSO डेटा के लिए LSASS से PRT उपयोग का अनुरोध करना** संभव है।\
|
||||
यह **Web Account Manager** (टोकन ब्रोकर) से टोकन का अनुरोध करने वाले **स्थानीय ऐप्स** की तरह किया जा सकता है। WAM अनुरोध को **LSASS** को भेजता है, जो हस्ताक्षरित PRT असर्शन का उपयोग करके टोकन के लिए पूछता है। या इसे **ब्राउज़र आधारित (वेब) प्रवाह** के साथ किया जा सकता है जहां **PRT कुकी** को Azure AS लॉगिन पृष्ठों के लिए अनुरोधों को प्रमाणित करने के लिए **हेडर** के रूप में उपयोग किया जाता है।
|
||||
|
||||
As **SYSTEM** you could **steal the PRT if not protected** by TPM or **interact with PRT keys in LSASS** using crypto APIs.
|
||||
**SYSTEM** के रूप में, आप **PRT को चुरा सकते हैं यदि यह TPM द्वारा सुरक्षित नहीं है** या **LSASS में PRT कुंजी के साथ इंटरैक्ट कर सकते हैं** क्रिप्टो एपीआई का उपयोग करके।
|
||||
|
||||
## Pass-the-PRT Attack Examples
|
||||
## Pass-the-PRT हमले के उदाहरण
|
||||
|
||||
### Attack - ROADtoken
|
||||
### हमला - ROADtoken
|
||||
|
||||
For more info about this way [**check this post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken will run **`BrowserCore.exe`** from the right directory and use it to **obtain a PRT cookie**. This cookie can then be used with ROADtools to authenticate and **obtain a persistent refresh token**.
|
||||
इस तरीके के बारे में अधिक जानकारी के लिए [**इस पोस्ट की जांच करें**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)। ROADtoken **`BrowserCore.exe`** को सही निर्देशिका से चलाएगा और इसका उपयोग **PRT कुकी प्राप्त करने** के लिए करेगा। इस कुकी का उपयोग ROADtools के साथ प्रमाणित करने और **एक स्थायी रिफ्रेश टोकन प्राप्त करने** के लिए किया जा सकता है।
|
||||
|
||||
To generate a valid PRT cookie the first thing you need is a nonce.\
|
||||
You can get this with:
|
||||
एक मान्य PRT कुकी उत्पन्न करने के लिए आपको सबसे पहले एक नॉनस की आवश्यकता है।\
|
||||
आप इसे प्राप्त कर सकते हैं:
|
||||
```powershell
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
@@ -80,7 +80,7 @@ AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-
|
||||
```powershell
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
फिर आप [**roadtoken**](https://github.com/dirkjanm/ROADtoken) का उपयोग करके एक नया PRT प्राप्त कर सकते हैं (उपयोगकर्ता की प्रक्रिया से हमले के लिए उपकरण में चलाएँ):
|
||||
फिर आप [**roadtoken**](https://github.com/dirkjanm/ROADtoken) का उपयोग करके एक नया PRT प्राप्त कर सकते हैं (उपयोगकर्ता के एक प्रक्रिया से हमले के लिए उपकरण में चलाएँ):
|
||||
```powershell
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
@@ -88,7 +88,7 @@ As oneliner:
|
||||
```powershell
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
फिर आप **जनित कुकी** का उपयोग करके **टोकन** **जनरेट** कर सकते हैं ताकि Azure AD **ग्राफ** या Microsoft ग्राफ का उपयोग करके **लॉगिन** कर सकें:
|
||||
फिर आप **जनित कुकी** का उपयोग **टोकन उत्पन्न** करने के लिए कर सकते हैं ताकि Azure AD **ग्राफ** या Microsoft ग्राफ का उपयोग करके **लॉगिन** किया जा सके:
|
||||
```powershell
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
@@ -96,9 +96,9 @@ roadrecon auth --prt-cookie <prt_cookie>
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### Attack - Using roadrecon
|
||||
### हमला - रोडरकॉन का उपयोग करना
|
||||
|
||||
### Attack - Using AADInternals and a leaked PRT
|
||||
### हमला - AADInternals और एक लीक किए गए PRT का उपयोग करना
|
||||
|
||||
`Get-AADIntUserPRTToken` **उपयोगकर्ता का PRT टोकन** Azure AD से जुड़े या हाइब्रिड जुड़े कंप्यूटर से प्राप्त करता है। PRT टोकन प्राप्त करने के लिए `BrowserCore.exe` का उपयोग करता है।
|
||||
```powershell
|
||||
@@ -108,7 +108,7 @@ $prtToken = Get-AADIntUserPRTToken
|
||||
# Get an access token for AAD Graph API and save to cache
|
||||
Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
```
|
||||
या अगर आपके पास Mimikatz से मान हैं, तो आप AADInternals का उपयोग करके एक टोकन भी उत्पन्न कर सकते हैं:
|
||||
या अगर आपके पास Mimikatz से मान हैं तो आप AADInternals का उपयोग करके एक टोकन भी उत्पन्न कर सकते हैं:
|
||||
```powershell
|
||||
# Mimikat "PRT" value
|
||||
$MimikatzPRT="MC5BWU..."
|
||||
@@ -143,18 +143,18 @@ Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
फिर [https://portal.azure.com](https://portal.azure.com) पर जाएं
|
||||
फिर जाएं [https://portal.azure.com](https://portal.azure.com)
|
||||
|
||||
> [!CAUTION]
|
||||
> बाकी डिफ़ॉल्ट होना चाहिए। सुनिश्चित करें कि आप पृष्ठ को ताज़ा कर सकते हैं और कुकी गायब नहीं होती है, यदि ऐसा होता है, तो आपने गलती की हो सकती है और आपको प्रक्रिया को फिर से करना होगा। यदि ऐसा नहीं होता है, तो आप ठीक होंगे।
|
||||
> बाकी डिफ़ॉल्ट होना चाहिए। सुनिश्चित करें कि आप पृष्ठ को रिफ्रेश कर सकते हैं और कुकी गायब नहीं होती, यदि ऐसा होता है, तो आपने गलती की हो सकती है और आपको प्रक्रिया को फिर से करना होगा। यदि नहीं होती है, तो आप ठीक होंगे।
|
||||
|
||||
### हमला - Mimikatz
|
||||
|
||||
#### चरण
|
||||
|
||||
1. **PRT (प्राथमिक रिफ्रेश टोकन) LSASS** (स्थानीय सुरक्षा प्राधिकरण उपप्रणाली सेवा) से निकाला जाता है और आगे के उपयोग के लिए संग्रहीत किया जाता है।
|
||||
2. **सत्र कुंजी अगली निकाली जाती है**। चूंकि यह कुंजी प्रारंभ में जारी की जाती है और फिर स्थानीय डिवाइस द्वारा फिर से एन्क्रिप्ट की जाती है, इसलिए इसे DPAPI मास्टरकी का उपयोग करके डिक्रिप्ट करना आवश्यक है। DPAPI (डेटा सुरक्षा एपीआई) के बारे में विस्तृत जानकारी इन संसाधनों में पाई जा सकती है: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) और इसके अनुप्रयोग की समझ के लिए, [Pass-the-cookie हमला](az-pass-the-cookie.md) देखें।
|
||||
3. सत्र कुंजी के डिक्रिप्शन के बाद, **PRT के लिए व्युत्पन्न कुंजी और संदर्भ प्राप्त होते हैं**। ये **PRT कुकी के निर्माण के लिए महत्वपूर्ण हैं**। विशेष रूप से, व्युत्पन्न कुंजी का उपयोग उस JWT (JSON वेब टोकन) पर हस्ताक्षर करने के लिए किया जाता है जो कुकी बनाता है। इस प्रक्रिया का एक व्यापक विवरण डिर्क-जान द्वारा प्रदान किया गया है, जिसे [यहां](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) देखा जा सकता है।
|
||||
2. **सत्र कुंजी अगली निकाली जाती है**। चूंकि यह कुंजी प्रारंभ में जारी की जाती है और फिर स्थानीय डिवाइस द्वारा फिर से एन्क्रिप्ट की जाती है, इसलिए इसे DPAPI मास्टरकी का उपयोग करके डिक्रिप्ट करना आवश्यक है। DPAPI (डेटा सुरक्षा एपीआई) के बारे में विस्तृत जानकारी इन संसाधनों में पाई जा सकती है: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) और इसके अनुप्रयोग की समझ के लिए, [Pass-the-cookie attack](az-pass-the-cookie.md) देखें।
|
||||
3. सत्र कुंजी के डिक्रिप्शन के बाद, **PRT के लिए व्युत्पन्न कुंजी और संदर्भ प्राप्त होते हैं**। ये **PRT कुकी के निर्माण** के लिए महत्वपूर्ण हैं। विशेष रूप से, व्युत्पन्न कुंजी का उपयोग कुकी का गठन करने वाले JWT (JSON वेब टोकन) पर हस्ताक्षर करने के लिए किया जाता है। इस प्रक्रिया का एक व्यापक विवरण डिर्क-जान द्वारा प्रदान किया गया है, जिसे [यहां](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) देखा जा सकता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि यदि PRT TPM के अंदर है और `lsass` के अंदर नहीं है, तो **mimikatz इसे निकालने में असमर्थ होगा**।\
|
||||
@@ -163,7 +163,7 @@ HttpOnly: Set to True (checked)
|
||||
आप इन विवरणों को निकालने की प्रक्रिया का **गहन विवरण** यहां पा सकते हैं: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
|
||||
> [!WARNING]
|
||||
> अगस्त 2021 के सुधारों के बाद अन्य उपयोगकर्ताओं के PRT टोकन प्राप्त करने के लिए यह ठीक से काम नहीं करेगा क्योंकि केवल उपयोगकर्ता ही अपना PRT प्राप्त कर सकता है (एक स्थानीय व्यवस्थापक अन्य उपयोगकर्ताओं के PRTs तक पहुंच नहीं सकता), लेकिन वह अपने PRT तक पहुंच सकता है।
|
||||
> अगस्त 2021 के फिक्स के बाद अन्य उपयोगकर्ताओं के PRT टोकन प्राप्त करने के लिए यह ठीक से काम नहीं करेगा क्योंकि केवल उपयोगकर्ता ही अपना PRT प्राप्त कर सकता है (एक स्थानीय व्यवस्थापक अन्य उपयोगकर्ताओं के PRTs तक पहुंच नहीं सकता), लेकिन वह अपने PRT तक पहुंच सकता है।
|
||||
|
||||
आप **mimikatz** का उपयोग करके PRT निकाल सकते हैं:
|
||||
```powershell
|
||||
@@ -179,15 +179,15 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
|
||||
<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Prt** के लेबल वाले भाग को **कॉपी** करें और इसे सहेजें।\
|
||||
सत्र कुंजी (जो **`ProofOfPossesionKey`** फ़ील्ड का **`KeyValue`** है) को भी निकालें जिसे आप नीचे हाइलाइटेड देख सकते हैं। यह एन्क्रिप्टेड है और इसे डिक्रिप्ट करने के लिए हमें अपने DPAPI मास्टरकीज़ का उपयोग करने की आवश्यकता होगी।
|
||||
**कॉपी** करें उस भाग को जो **Prt** के रूप में लेबल किया गया है और इसे सहेजें।\
|
||||
सत्र कुंजी (जो **`ProofOfPossesionKey`** फ़ील्ड का **`KeyValue`** है) को भी निकालें जिसे आप नीचे हाइलाइटेड देख सकते हैं। यह एन्क्रिप्टेड है और हमें इसे डिक्रिप्ट करने के लिए अपने DPAPI मास्टरकीज़ का उपयोग करने की आवश्यकता होगी।
|
||||
|
||||
<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> यदि आप कोई PRT डेटा नहीं देखते हैं, तो इसका मतलब हो सकता है कि आपके पास **कोई PRT नहीं है** क्योंकि आपका डिवाइस Azure AD से जुड़ा नहीं है या यह हो सकता है कि आप **पुराने संस्करण** का Windows 10 चला रहे हैं।
|
||||
> यदि आप कोई PRT डेटा नहीं देखते हैं, तो इसका मतलब यह हो सकता है कि आपके पास **कोई PRT नहीं है** क्योंकि आपका डिवाइस Azure AD से जुड़ा नहीं है या यह हो सकता है कि आप **Windows 10 का पुराना संस्करण** चला रहे हैं।
|
||||
|
||||
सत्र कुंजी को **डिक्रिप्ट** करने के लिए आपको **SYSTEM** के रूप में अपनी विशेषाधिकारों को **उच्च करना** होगा ताकि आप कंप्यूटर संदर्भ के तहत चल सकें और **DPAPI मास्टरकी का उपयोग करके इसे डिक्रिप्ट कर सकें**। आप ऐसा करने के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं:
|
||||
सत्र कुंजी को **डिक्रिप्ट** करने के लिए आपको अपनी विशेषताओं को **SYSTEM** में **उच्च करना** होगा ताकि आप कंप्यूटर संदर्भ के तहत चल सकें और **DPAPI मास्टरकी का उपयोग करके इसे डिक्रिप्ट कर सकें**। आप ऐसा करने के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं:
|
||||
```
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
|
||||
@@ -224,11 +224,11 @@ HttpOnly: Set to True (checked)
|
||||
|
||||
#### विकल्प 2 - roadrecon का उपयोग करके PRT
|
||||
|
||||
- पहले PRT को नवीनीकरण करें, जो इसे `roadtx.prt` में सहेज लेगा:
|
||||
- पहले PRT को नवीनीकरण करें, जो इसे `roadtx.prt` में सहेज देगा:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- अब हम `roadtx browserprtauth` का उपयोग करके इंटरैक्टिव ब्राउज़र के माध्यम से **टोकन अनुरोध** कर सकते हैं। यदि हम `roadtx describe` कमांड का उपयोग करते हैं, तो हम देखते हैं कि एक्सेस टोकन में एक MFA दावा शामिल है क्योंकि इस मामले में मैंने जो PRT का उपयोग किया था, उसमें भी एक MFA दावा था।
|
||||
- अब हम `roadtx browserprtauth` के साथ इंटरैक्टिव ब्राउज़र का उपयोग करके **टोकन अनुरोध** कर सकते हैं। यदि हम `roadtx describe` कमांड का उपयोग करते हैं, तो हम देखते हैं कि एक्सेस टोकन में एक MFA क्लेम शामिल है क्योंकि इस मामले में मैंने जो PRT का उपयोग किया था, उसमें भी एक MFA क्लेम था।
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
@@ -237,7 +237,7 @@ roadtx describe < .roadtools_auth
|
||||
|
||||
#### विकल्प 3 - roadrecon का उपयोग करके व्युत्पन्न कुंजी
|
||||
|
||||
mimikatz द्वारा डंप की गई संदर्भ और व्युत्पन्न कुंजी के साथ, roadrecon का उपयोग करके एक नया साइन किया हुआ कुकी उत्पन्न करना संभव है:
|
||||
संदर्भ और mimikatz द्वारा डंप की गई व्युत्पन्न कुंजी होने पर, roadrecon का उपयोग करके एक नया साइन किया हुआ कुकी उत्पन्न करना संभव है:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
टेस्ट शुरू करने के लिए आपके पास **सदस्यता पर Reader अनुमतियों के साथ एक उपयोगकर्ता** और **AzureAD में Global Reader भूमिका** के साथ पहुंच होनी चाहिए। यदि फिर भी आप **Storage खातों की सामग्री तक पहुंचने में असमर्थ हैं** तो आप इसे **Storage Account Contributor भूमिका** के साथ ठीक कर सकते हैं।
|
||||
टेस्ट शुरू करने के लिए आपके पास **सदस्यता पर Reader permissions** और **AzureAD में Global Reader role** के साथ एक उपयोगकर्ता का एक्सेस होना चाहिए। यदि फिर भी आप **Storage accounts के कंटेंट तक पहुँचने में असमर्थ हैं** तो आप इसे **Storage Account Contributor role** के साथ ठीक कर सकते हैं।
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user