Skip to content

Commit 2fbcbe7

Browse files
committed
f
1 parent 303e3fb commit 2fbcbe7

File tree

2 files changed

+67
-8
lines changed
  • src/pentesting-cloud/azure-security

2 files changed

+67
-8
lines changed

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

Lines changed: 40 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -98,6 +98,46 @@ az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUr
9898
az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
9999
```
100100

101+
### Applications Privilege Escalation
102+
103+
**As explained in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** it was very common to find default applications that have **API permissions** of type **`Application`** assigned to them. An API Permission (as called in the Entra ID console) of type **`Application`** means that the application can access the API without a user context (without a user login into the app), and without needing Entra ID roles to allow it. Therefore, it's very common to find **high privileged applications in every Entra ID tenant**.
104+
105+
Then, if an attacker has any permission/role that allows to **update the credentials (secret o certificate) of the application**, the attacker can generate a new credential and then use it to **authenticate as the application**, gaining all the permissions that the application has.
106+
107+
Note that the mentioned blog shares some **API permissions** of common Microsoft default applications however some time after this report Microsoft fixed this issue and now it's not possible to login as Microsoft applications anymore. However, it's still possible to find **custom applications with high privileges that could be abused**.
108+
109+
How to enumerate the API permissions of an application:
110+
111+
```bash
112+
# Get "API Permissions" of an App
113+
## Get the ResourceAppId
114+
az ad app show --id "<app-id>" --query "requiredResourceAccess" --output json
115+
## e.g.
116+
[
117+
{
118+
"resourceAccess": [
119+
{
120+
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
121+
"type": "Scope"
122+
},
123+
{
124+
"id": "d07a8cc0-3d51-4b77-b3b0-32704d1f69fa",
125+
"type": "Role"
126+
}
127+
],
128+
"resourceAppId": "00000003-0000-0000-c000-000000000000"
129+
}
130+
]
131+
132+
## For the perms of type "Scope"
133+
az ad sp show --id <ResourceAppId> --query "oauth2PermissionScopes[?id=='<id>'].value" -o tsv
134+
az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2PermissionScopes[?id=='e1fe6dd8-ba31-4d61-89e7-88639da4683d'].value" -o tsv
135+
136+
## For the perms of type "Role"
137+
az ad sp show --id <ResourceAppId> --query "appRoles[?id=='<id>'].value" -o tsv
138+
az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?id=='d07a8cc0-3d51-4b77-b3b0-32704d1f69fa'].value" -o tsv
139+
```
140+
101141
## Service Principals
102142

103143
### `microsoft.directory/servicePrincipals/credentials/update`
@@ -188,14 +228,6 @@ az rest --method POST \
188228
--body "{\"id\": \"$credID\"}"
189229
```
190230

191-
### Applications Privilege Escalation
192-
193-
**As explained in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** it was very common to find default applications that have **API permissions** of type **`Application`** assigned to them. An API Permission (as called in the Entra ID console) of type **`Application`** means that the application can access the API without a user context (without a user login into the app), and without needing Entra ID roles to allow it. Therefore, it's very common to find **high privileged applications in every Entra ID tenant**.
194-
195-
Then, if an attacker has any permission/role that allows to **update the credentials (secret o certificate) of the application**, the attacker can generate a new credential and then use it to **authenticate as the application**, gaining all the permissions that the application has.
196-
197-
Note that the mentioned blog shares some **API permissions** of common Microsoft default applications however some time after this report Microsoft fixed this issue and now it's not possible to login as Microsoft applications anymore. However, it's still possible to find **custom applications with high privileges that could be abused**.
198-
199231
---
200232

201233
## Groups

src/pentesting-cloud/azure-security/az-services/az-azuread.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -790,6 +790,33 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92
790790
# Get Cloud Applications Administrators (full access over apps)
791791
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"
792792
793+
# Get "API Permissions" of an App
794+
## Get the ResourceAppId
795+
az ad app show --id "<app-id>" --query "requiredResourceAccess" --output json
796+
## e.g.
797+
[
798+
{
799+
"resourceAccess": [
800+
{
801+
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
802+
"type": "Scope"
803+
},
804+
{
805+
"id": "d07a8cc0-3d51-4b77-b3b0-32704d1f69fa",
806+
"type": "Role"
807+
}
808+
],
809+
"resourceAppId": "00000003-0000-0000-c000-000000000000"
810+
}
811+
]
812+
813+
## For the perms of type "Scope"
814+
az ad sp show --id <ResourceAppId> --query "oauth2PermissionScopes[?id=='<id>'].value" -o tsv
815+
az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2PermissionScopes[?id=='e1fe6dd8-ba31-4d61-89e7-88639da4683d'].value" -o tsv
816+
817+
## For the perms of type "Role"
818+
az ad sp show --id <ResourceAppId> --query "appRoles[?id=='<id>'].value" -o tsv
819+
az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?id=='d07a8cc0-3d51-4b77-b3b0-32704d1f69fa'].value" -o tsv
793820
```
794821
795822
{{#endtab }}

0 commit comments

Comments
 (0)