diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
index 9ab97e32a..506814b74 100644
--- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
+++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
@@ -98,6 +98,46 @@ az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUr
 az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
 ```
 
+### Applications Privilege Escalation
+
+**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**.
+
+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.
+
+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**.
+
+How to enumerate the API permissions of an application:
+
+```bash
+# Get "API Permissions" of an App
+## Get the ResourceAppId
+az ad app show --id "<app-id>" --query "requiredResourceAccess" --output json
+## e.g.
+[
+  {
+    "resourceAccess": [
+      {
+        "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
+        "type": "Scope"
+      },
+      {
+        "id": "d07a8cc0-3d51-4b77-b3b0-32704d1f69fa",
+        "type": "Role"
+      }
+    ],
+    "resourceAppId": "00000003-0000-0000-c000-000000000000"
+  }
+]
+
+## For the perms of type "Scope"
+az ad sp show --id <ResourceAppId> --query "oauth2PermissionScopes[?id=='<id>'].value" -o tsv
+az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2PermissionScopes[?id=='e1fe6dd8-ba31-4d61-89e7-88639da4683d'].value" -o tsv
+
+## For the perms of type "Role"
+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
+```
+
 ## Service Principals
 
 ### `microsoft.directory/servicePrincipals/credentials/update`
@@ -188,14 +228,6 @@ az rest --method POST \
   --body "{\"id\": \"$credID\"}"
 ```
 
-### Applications Privilege Escalation
-
-**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**.
-
-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.
-
-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**.
-
 ---
 
 ## Groups
diff --git a/src/pentesting-cloud/azure-security/az-services/az-azuread.md b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
index 6d387a0f8..4777919cf 100644
--- a/src/pentesting-cloud/azure-security/az-services/az-azuread.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
@@ -790,6 +790,33 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92
 # Get Cloud Applications Administrators (full access over apps)
 az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"
 
+# Get "API Permissions" of an App
+## Get the ResourceAppId
+az ad app show --id "<app-id>" --query "requiredResourceAccess" --output json
+## e.g.
+[
+  {
+    "resourceAccess": [
+      {
+        "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
+        "type": "Scope"
+      },
+      {
+        "id": "d07a8cc0-3d51-4b77-b3b0-32704d1f69fa",
+        "type": "Role"
+      }
+    ],
+    "resourceAppId": "00000003-0000-0000-c000-000000000000"
+  }
+]
+
+## For the perms of type "Scope"
+az ad sp show --id <ResourceAppId> --query "oauth2PermissionScopes[?id=='<id>'].value" -o tsv
+az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2PermissionScopes[?id=='e1fe6dd8-ba31-4d61-89e7-88639da4683d'].value" -o tsv
+
+## For the perms of type "Role"
+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
 ```
 
 {{#endtab }}