How Attackers Leverage Over-Permissions

Do you have over excessive permissions in your Entra ID? 

Also, this blog post delves into the anatomy of a potential attack where an adversary exploits service principals with ‘User.DeleteRestore.All’ permission to execute malicious account deletions within Entra ID. By abusing this excessive privilege, attackers can disrupt organizational operations, sabotage user access, and complicate recovery efforts while covering their tracks.

MUST KNOW: Attackers often destroy the Microsoft 365/Azure environment as part of a broad attack. The destruction can be done by deleting many objects.

Understanding Service Principals in Entra ID

Service principals, the programmatic entities representing applications or automated processes in Microsoft Entra ID, are often granted extensive permissions to streamline operations. However, these entities can also become prime targets for threat actors, particularly when permissions like ‘’User.DeleteRestore.All’ are misconfigured or overprovisioned.

Among these, permissions like ‘User.DeleteRestore.All’, ‘Application.ReadWrite.All’, ‘Policy.ReadWrite.ConditionalAccess’, and many others, can be classified as “high-impact permissions” because they directly influence critical identity, application, and security configurations in Microsoft Entra ID.

The heart of application access in Microsoft Entra ID lies in the concept of Service Principals, unique programmatic identities that enable applications and scripts to authenticate and interact with directory resources. While service principals play an integral role in streamlining cloud operations, they can also introduce security challenges if misconfigured or overprivileged.

A service principal is an identity created to represent an application or automated process within Microsoft Entra ID. Unlike user accounts, service principals are designed explicitly for non-interactive authentication. They enable tools and applications to access Azure resources securely and without manual intervention. Service principals form the backbone of Azure automation, facilitating everything from CI/CD pipelines to application integrations.

At their core, service principals authenticate using a client secret, certificate, or other credentials, which allows them to access resources with the permissions assigned to them. These permissions are defined by Azure roles or custom role definitions and range from highly restrictive to dangerously broad. Mismanagement of these permissions can lead to severe security vulnerabilities.

Advantages of Service Principals

Service principals offer several advantages, making them essential in modern cloud environments. Their primary strength lies in automating secure resource interactions. Unlike user accounts, which require manual password resets and interactive logins, service principals provide a non-interactive way to authenticate. This makes them ideal for integrating applications or automating routine tasks.

Another key advantage is the granular access control they provide. Administrators can assign specific permissions to service principals based on their roles, ensuring that applications have only the access they need. This flexibility allows organizations to enforce the principle of least privilege while maintaining operational efficiency.

Service principals also enhance scalability. They are widely used in CI/CD pipelines, enabling developers to deploy applications, configure infrastructure, and manage resources programmatically. Their role in automation is indispensable, particularly in large-scale environments with complex operations.

The Security Risks of Service Principals

While service principals are powerful tools, they also represent a significant security risk if not properly managed. One of the most critical issues is the risk of excessive permissions. Service principals are often overprovisioned, granting them permissions far beyond what they require. Permissions like ‘User.DeleteRestore.All, Directory.ReadWrite.All’, or ‘Application.ReadWrite.All’ can give an attacker who compromises a service principal control over sensitive resources or the entire tenant.

Another significant risk is credential leakage. Service principals use client secrets or certificates to authenticate, and if these credentials are stored insecurely or exposed in public repositories, attackers can exploit them to impersonate the service principal. Once compromised, the attacker can use the service principal’s permissions to execute malicious actions undetected.

Another challenge is the lack of visibility into service principal activity. Since service principals operate programmatically, their activities may go unnoticed in traditional monitoring systems, giving attackers more opportunities to exploit vulnerabilities.

Additionally, privilege escalation is a significant concern. Misconfigured roles can allow a service principal to assign higher privileges or modify access policies. In a worst-case scenario, an attacker could use a compromised service principal to create backdoors or elevate privileges, gaining control over critical resources.

Note: The permissions mentioned in this blog post are just a few. You can explore a bunch of permissions in the Microsoft Graph.

Exploitation of Service Principal Permissions in Entra ID

The potential for exploitation is vast regarding service principals in Microsoft Entra ID. These programmatic identities enable secure automation, seamless application integration, and access to Azure resources. However, when service principals are granted excessive or misconfigured permissions, they become high-value targets for attackers, providing pathways for lateral movement, privilege escalation, and data exfiltration.

Attackers often exploit service principals because they are less monitored than user accounts, can hold significant permissions, and are frequently used in automated processes where credentials are stored in code or configuration files. Below, we explore the key ways attackers can exploit permissions assigned to service principals, focusing on high-impact scenarios.

Note: You can find many attack paths via the service principle and its permissions.

Privilege Escalation

Attackers can exploit service principals with excessive permissions to elevate their access within the Azure tenant. For instance, if a service principal is assigned the ‘RoleManagement.ReadWrite.Directory’ permission, an attacker who compromises it could assign themselves or other accounts high-privilege roles like Global Administrator or Application Administrator.

This escalation allows the attacker to gain control over additional resources, configure backdoors, or further manipulate the environment.

Account and Resource Deletion

Permissions such as ‘User.DeleteRestore.All or Directory.ReadWrite.All’ allow attackers to delete or modify critical accounts and resources. If compromised, a service principal with these permissions could delete key user accounts, groups, or even applications. This could lead to significant operational disruption, mainly if privileged accounts or essential applications are targeted.

Attackers can also exploit this capability to delete logs or evidence of their activities, making detection and recovery more complex.

Note: The “User.DeleteRestore.All” permission does not allow resetting a user’s password.

Tampering with Security Configurations

Service principals with permissions like ‘Policy.ReadWrite.ConditionalAccess’ or ‘PrivilegedAccess.ReadWrite.AzureAD’ enable attackers to modify security policies. For example:

• Conditional Access Policies: An attacker could disable or weaken Conditional Access policies, such as removing MFA requirements, to facilitate further attacks.
• Privileged Access Configurations: Attackers could alter Privileged Identity Management (PIM) settings to create long-term backdoors or simplify privilege escalation.

Tampering with these configurations weakens the tenant’s overall security posture and creates vulnerabilities that are difficult to detect.

Resource Hijacking

Permissions like ‘Application.ReadWrite.All’ or ‘Device.ReadWrite.All’ can allow attackers to hijack or modify applications and devices in the environment. For instance:

• Attackers could update application credentials or redirect APIs to malicious endpoints.
• They could tamper with configurations, deregister devices, or create rogue devices to bypass security controls.

Such activities can disrupt normal operations and facilitate further attacks, such as data exfiltration or C2 operations.

Backdoors

Attackers can use compromised service principles to create persistent backdoors in the environment. For instance:

• Using ‘Application.ReadWrite.All’, attackers can register rogue applications with excessive permissions, ensuring they maintain access even after the compromised service principal is detected and revoked.
• Permissions like ‘Group.ReadWrite.All’ can allow attackers to modify group memberships, adding their accounts to privileged groups for long-term access.

Such backdoors are often challenging to detect, especially in environments with limited monitoring of service principal activities.

Note: There are more, such as Abuse of Third-Party Integrations, Unauthorized Application Access, Token Theft, Replay Attacks, and more.

Attack Scenario: Leveraging User.DeleteRestore.All

The ‘User.DeleteRestore.All’permission in Entra ID allows the deletion and restoration of user accounts across an organization’s directory and a few more actions. While it’s a powerful tool for administrators managing user lifecycles, it can be devastating in the hands of an attacker. This scenario explores how an adversary compromises a service principal to exploit this permission for malicious account deletions, detailing each attack step from compromise to impact.

This scenario illustrates how a threat actor can abuse ‘User.DeleteRestore.All’ to target privileged identity objects, including Global Administrators (GA) and critical account objects, thereby incapacitating operations and establishing long-term control over the Entra ID tenant.

The Attack Path – Strategic Deletion of Account Objects

Gaining Initial Access Through Credential Exploitation

The attack begins with the compromise of an entity associated with a service principal or a privileged user account provisioned with the User.DeleteRestore.All permission. Credential compromise typically occurs through a combination of tactics, techniques, and procedures (TTPs) such as:

• Credential Stuffing: Weak client secret policies allow the attacker to brute-force or reuse known compromised credentials.
• Token Theft occurs when the attacker intercepts or steals access tokens used by the SP, bypassing authentication and MFA policies not enforced for non-human identities.

With valid credentials, the adversary gains unauthorized access to the Service Principal and leverages its permissions to authenticate via the Microsoft Graph API.

Note: Credentials can be stolen through many actions. Once an attacker has them, he will proceed to the next step. Another scenario is to gain access via the Service Principal.

Now, you can connect using either Use client secret credentials by Microsoft or Connect-MgGraph-Interactive.ps1. This method of accessing the Service Principal via Secret or equivalent is powerful because it can easily bypass the Entra ID CAP without warning.

Once you are in, you can get the context of the Microsoft Graph and the environment.

Entra ID Reconnaissance and Enumeration

From an attacker’s perspective, Service Principals in Entra ID are a goldmine of opportunities, given their inherent trust in cloud environments and their critical role in automation and application management. Unlike user accounts, service principals often operate with elevated privileges and are subject to less scrutiny, making them attractive targets for enumeration, exploitation, and persistence.

Service principals frequently have broad access to critical resources, including Azure subscriptions, storage accounts, and key vaults. Attackers exploit this over-permissioning by leveraging enumeration techniques through the Microsoft Graph API or Azure CLI. Queries targeting app roles, secrets, certificates, and OAuth permissions help map an organization’s operational landscape. For example, extracting secrets or certificates linked to service principals enables unauthorized authentication, often unnoticed due to insufficient monitoring.

Attackers can escalate privileges by exploiting misconfigurations, such as assigning excessive permissions to a service principal or abusing the OAuth consent framework to gain unauthorized API access. These identities also provide a path for persistence. Attackers can implant malicious secrets or certificates, ensuring continuous access to the environment even after initial detection efforts.

Service principal activity is rarely scrutinized to the level of human accounts. Attackers exploit this by operating under the radar, using compromised service principals to exfiltrate sensitive data, disrupt automation workflows, or establish footholds for lateral movement across the network.

The Commands

First, run the “Who AM I” – the MgGraph version/approach. These can be values such as AppName, Environment, ContextScope, etc. In a nutshell, it can be everything under the Get-MgContext.

An example can be the command Get-MgUser -UserId (Get-MgContext).Accountor event short command with the(Get-MgContext).Account.

Then, you can proceed with other commands as potential options.

Note: These commands can be run by a specific User.DeleteRestore.Allpermissions.

Potential MgGraph Recon and Enum Commands

The following command ‘Get-MgServicePrincipal’ can extract all service principals in Entra ID along with their app and delegated permissions. An attacker can use this to identify service principals with excessive or sensitive permissions, such as access to critical resources or privileged APIs. 

Analyzing the exported data, they can target service principals for credential theft, privilege escalation, or persistence. This enables attackers to exploit misconfigurations or weak permission policies to move laterally or maintain access undetected.

Get-MgServicePrincipal -All -Property * | Select-Object DisplayName, AppId, Id, @{Name=”ApplicationPermissions”;Expression={($_.AppRoles | ForEach-Object Value) -join “, “}}, @{Name=”DelegatedPermissions”;Expression={($_.Oauth2PermissionScopes | ForEach-Object Value) -join “, “}} # | Export-Csv -Path “ServicePrincipalsWithPermissions.csv” -NoTypeInformation

The Get-MgGroup -Filter “securityEnabled eq true” -All command retrieves all security-enabled groups in the directory, including their display names and unique identifiers. By understanding the group structure, attackers can pinpoint groups with elevated permissions or sensitive access. The impact of this reconnaissance lies in the potential to exploit group memberships to escalate privileges or access restricted resources.

The Get-MgOauth2PermissionGrant -All command enumerates OAuth2 permission grants, revealing applications and accounts with elevated API permissions, such as access to emails, files, or directory data. Attackers can exploit these permissions to impersonate users or exfiltrate sensitive data. The impact is substantial, as tenant-wide permissions can allow attackers to compromise multiple users and resources simultaneously.

A command that can assist attackers in lateral movement within an Entra ID environment involves identifying privileged service principals or accounts with broad access to resources. One such command enumerates service principals with specific roles or directory-wide permissions, enabling attackers to identify potential pivot points.

Additional MgGraph Recon and Enum Commands

Here are some Microsoft Graph PowerShell commands for reconnaissance and enumeration, focusing on attacker techniques to gather valuable information within an Entra ID environment.

The Get-MgUser -All -Property “displayName,userPrincipalName,jobTitle,assignedLicenses” command enumerates all users in the directory, returning details such as their display names, user principal names, job titles, and assigned licenses. This information allows attackers to identify key users, such as administrators or executives, and their organizational roles. The impact of this enumeration is significant, as it enables attackers to prioritize high-value targets for phishing, impersonation, or direct exploitation.

The Get-MgRoleManagementDirectoryRoleDefinition -All command enumerates all directory roles and their descriptions, such as Global Administrator or Security Administrator. This allows attackers to map privileged roles in the directory and prioritize them for exploitation. The impact of this enumeration is profound, as it reveals high-value roles that, if compromised, could provide complete administrative control over the directory.

The Get-MgUser -Filter “accountEnabled eq true” command returns only enabled user accounts in the directory. This gives attackers a focused list of active accounts they can exploit immediately, without requiring reactivation. This impact is direct because active accounts serve as live access points into the environment.

The Get-MgUser -Filter “department eq ‘IT'” command identifies users within a specific department, such as IT, which often includes individuals with administrative privileges or knowledge of internal systems. This focused enumeration helps attackers prioritize technical personnel for exploitation. The impact of targeting IT users is critical, as compromising them can lead to broader access to the organization’s infrastructure.

The Get-MgServicePrincipal -Filter “servicePrincipalType eq ‘ManagedIdentity'” command identifies managed identities within the directory. These identities represent Azure resources that authenticate using Azure AD. Attackers can target these identities to access connected Azure services or bypass security controls. The impact is critical, as compromising a managed identity can enable attackers to move laterally within the Azure environment and exploit additional services.

The Get-MgServicePrincipal -All | Where-Object { $_.AppRoles -match “Directory.ReadWrite.All” -or $_.AppRoles -match “User.ReadWrite.All” } | Select-Object DisplayName, AppId, AppRoles command enumerates applications (service principals) with elevated permissions, such as Directory.ReadWrite.All and User.ReadWrite.All. These permissions allow applications to make significant changes to the Azure AD directory or user data. The impact of this enumeration is severe, as attackers can exploit these high-permission applications to modify directory structures, access sensitive user information, or manipulate configurations, enabling large-scale compromise or persistent control.

The Get-MgApplication -All | Where-Object { $_.DisplayName -notmatch “approved|official” } | Select-Object DisplayName, AppId, RequiredResourceAccess command identifies shadow IT applications, which are unapproved or unofficial applications that may have been registered in the directory. These applications often bypass organizational controls, creating vulnerabilities. The impact of discovering shadow IT applications is critical, as attackers can exploit them to access sensitive resources or use their permissions to infiltrate the organization unnoticed.

The Get-MgServicePrincipal -All | Where-Object { $_.AppId -eq $null } | Select-Object DisplayName, Id command identifies orphaned service principals, which are service principals not linked to any active application. Orphaned service principals can pose a security risk if their permissions remain valid. The impact of identifying these entities is significant because attackers can hijack or exploit them to gain unauthorized access to resources.

The Get-MgServicePrincipal -All | Where-Object { $_.SignInActivity.LastSignInDateTime -lt (Get-Date).AddMonths(-6) } | Select-Object DisplayName, AppId, LastSignInDateTime command queries service principals with no recent sign-in activity. These inactive service principals might represent abandoned or underused applications. The impact of this discovery lies in the potential misuse of such entities, as attackers can target them to remain under the radar while leveraging their permissions to access sensitive resources or carry out malicious activities undetected.

Note: Many Microsoft Graph API enumeration and reconnaissance commands require specific permissions. Some will fail if those permissions are not granted.

MUST KNOW: This remains a significant blind spot where security and monitoring tools struggle to detect numerous activities.

Systematic Deletion of High-Value Accounts

By exploiting the User.DeleteRestore.All an attacker can execute a calculated and systematic campaign to destabilize an organization by targeting high-value accounts. This tactic disrupts operations and erodes the organization’s ability to respond effectively, creating cascading failures across security, operations, and recovery efforts.

The removal of High-Excessive accounts can cripple tenant-wide governance by stripping the organization of its ability to manage critical configurations, enforce security policies, and execute incident response measures. Without these accounts, the organization is left vulnerable to prolonged attacks and unable to regain control of its cloud infrastructure.

Break-glass accounts, designed as last-resort mechanisms for emergency recovery, are another prime target. Their deletion effectively neutralizes the organization’s fail-safe systems, leaving no path for recovery in a catastrophic event. This tactic ensures the attacker can maintain dominance over the environment while further deepening the organization’s reliance on compromised systems.

Service accounts, often used for automation and application integration, present a unique opportunity for operational sabotage. Their removal disrupts critical workflows, halts business processes, and triggers widespread confusion across departments. Additionally, this disruption is a diversion, directing attention to restoring operations while the attacker pivots to other objectives, such as exfiltrating data or escalating privileges.

The attacker ensures that account deletions occur in phases, sequentially targeting primary and backup accounts to maximize disruption. By focusing on privileged identities, the adversary ensures that response and recovery efforts are delayed or incapacitated.

Once the attacker is in the environment, they can run the delete command on many objects. The Remove-MgUser will be part of this action. The script to remove users is BulkDeleteUsers.ps1.

You can add more filters to delete specific users based on their particular permissions. For example, the Bulk_Delete_Users_Filtered.ps1

Once users are deleted using the script, the attacker can seamlessly advance to the next phase of their attack chain.

Then we need to check the users’ status and ensure they are removed. You can run the Generate-DeletedAccountsReport.ps1.

TIP: In some cases, the User.DeleteRestore.Allpermissions cannot remove High-Excessive permissions objects.

Obfuscation Through Restoration Abuse

The adversary leverages the restoration capabilities inherent in the permission to further obfuscate their actions and create operational noise. Accounts may be selectively restored but with altered attributes. For example, Role Manipulation, Authentication Bypass, Credential Hijacking, etc.

This tactic is used by adversaries to exploit a system’s legitimate restoration capabilities to obscure their malicious activities. Rather than simply deleting or modifying resources, attackers cycle specific objects, such as user accounts, service principals, or groups, through deletion and restoration events. This repetitive process generates a large volume of legitimate-looking audit log entries, making it difficult for defenders to determine what occurred and to identify the valid sequence of malicious actions.

In other words, the attacker isn’t just making changes; they’re intentionally flooding logs and administrative records with restoration operations to hide the details of their attack or maintain covert persistence. The result is an environment in which forensic efforts are delayed and the attacker’s movements are more difficult to pinpoint, increasing the time and complexity required for detection and response.

Restoring a user “with role” in the context of Obfuscation Through Restoration Abuse typically means reinstating a deleted account that originally had certain administrative privileges or permissions. When the user is restored, the goal may be to reinstate some of those roles or to manipulate the restored account’s privileges. For example, assigning them a different set of roles, removing MFA requirements, or altering their original permissions.

Restore Modification typically refers to changing a user’s attributes or permissions immediately after they are restored from deletion.

Note: This script wasn’t uploaded to my GitHub account.

Creating random users as part of an obfuscation strategy in an attack scenario serves several key purposes. It’s a tactic attackers might employ to blend malicious activity into legitimate environments or to create noise that hinders detection and response efforts. Here’s the deeper meaning behind this tactic:

• Distraction of Defenders
• Obfuscation of Malicious Activity
• Increasing the Complexity of Forensic Investigations

In real-world scenarios, actors create dummy accounts for obfuscation, often seen in espionage or nation-state attacks.

Using random user creation as part of an attack scenario, attackers aim to confuse defenders, increase operational noise, and maintain stealth. Defenders must focus on robust monitoring, behavior analysis, and privilege management to counteract these tactics effectively.

Attackers can proceed to the next phase after leveraging Obfuscation Through Restoration, Abuse, or the Creation of Dummy users. This tactic disrupts monitoring and complicates forensic investigations, paving the way for further malicious actions.

The attack chain can lead to the following: this stage typically involves persistence, privilege escalation, lateral movement, and, eventually, subscription takeover or data exfiltration, along with additional enumeration scenarios. Persistence, create a new backdoor via Secret, run Privilege escalation, and Lateral Movement.

In this scenario, the next action after deleting the users (systematic objects deletion) will be to run more ENUM actions. This time, the results will be for significant action such as lateral movement, priv escalations, and gaining persistence with higher permissions. Maybe Owner, Global Admin, or equivalent.

Elevate Privileges as Possible

If the restored user is part of an application with administrative permissions, escalate further by modifying the application’s settings, creating new accounts, or granting additional permissions.

For example, if the restored user is an Application Administrator, you can create or modify service principals:

# Assign the Application Administrator role to a service principal
$servicePrincipal = Get-MgServicePrincipal -Filter “displayName eq ‘TargetApplication'”
$roleTemplateId = “158c047a-c907-4556-b7ef-446551a6b5f7” # Application Administrator Role Template ID

New-MgRoleManagementDirectoryRoleAssignment -DirectoryScopeId “/” `
-PrincipalId $servicePrincipal.Id `
-RoleDefinitionId $roleTemplateId

Write-Output “Assigned Application Administrator to: $($servicePrincipal.DisplayName)”

The exploitation of ‘User.DeleteRestore.All’ permissions underscores the critical need for robust identity and access management practices. Attackers can leverage restored accounts, especially those tied to administrative roles, to escalate privileges further, modifying application settings, creating backdoors, or granting new permissions to service principals. For example, as shown above, attackers can exploit a restored Application Administrator to assign roles to service principals, thereby gaining deeper access to critical resources.

Summary

Attackers with c permissions possess a powerful vector for stealth and persistence. By deleting privileged accounts, they exploit organizational blind spots to disrupt operations and obscure malicious activity. The subsequent restoration of these accounts, often as duplicates, allows attackers to regain control under the guise of legitimate administrative actions. 

This Advanced Persistent Threat (APT) tactic enables the injection of backdoors, privilege escalation, and the modification of IAM (Identity and Access Management) policies to ensure long-term dominance. Once access is solidified, attackers can exfiltrate data, sabotage critical configurations, or erase traces by re-deleting the accounts. To mitigate these risks, organizations must adopt a Zero Trust Architecture (ZTA), enforce Least Privilege, and leverage Cloud Security Tools and Controls to monitor account lifecycle activities for anomalous behavior.