Entra ID Destruction: How Attackers Leverage User.DeleteRestore.All

Imagine a grand circus where every act is perfectly timed, and every performer has a specific role. Among the performers is the juggler, a key part of the show, responsible for keeping multiple objects in motion—balls, clubs, and flaming torches. The juggler’s role is critical, but to perform, they need access to backstage props, the performance schedule, and occasionally the manager’s office to coordinate with the other acts.

Now, imagine that this juggler is handed an all-access pass to the entire circus—not just the areas they need for their act, but to the safes holding ticket money, the equipment for other performers, and even the master control system for the lights and stage. It’s excessive and unnecessary for their role, but no one questions it.

One day, a clever intruder disguises themselves as the juggler and uses this all-access pass to cause chaos. They sabotage the trapeze, empty the safes, and turn off the spotlight at the climactic moment, leaving the entire circus in disarray. The real juggler is blamed, the audience is confused, and the intruder walks away unnoticed, having exploited the misplaced trust and excessive access.

In the world of Entra ID, service principals are like the juggler—trusted entities with specific responsibilities. But when they are given permissions far beyond what they need, like User.DeleteRestore.All, it’s akin to that all-access pass.

This blog delves into how attackers can use overprovisioned permissions like User.DeleteRestore.All. By strategically deleting and restoring user accounts, attackers can disrupt operations, evade detection, and establish long-term persistence.

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.

Entra ID Objects Destruction: How Attackers Leverage User.DeleteRestore.All

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.

Understanding Service Principals in Entra ID

Service principals, the programmatic entities representing applications or automated processes in Microsoft Entra ID (formerly Azure AD), 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” due to their ability to directly influence critical identity, application, and security configurations in Microsoft Entra ID.

The heart of application in Microsoft Entra ID lies in the concept of Service Principals—unique programmatic identities designed to enable applications and scripts to authenticate and interact with resources in the directory. 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, etc., which allows them to access resources under their assigned permissions. 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 that make them essential in modern cloud environments. Their primary strength lies in their ability to automate resource interactions securely. 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 only access what 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 a high-value target for attackers, providing a pathway 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 specific scenarios with high-impact permissions.

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 command and control (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 like 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 more few 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, leveraging this capability to incapacitate operations and establish 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 Principle and leverages its permissions to authenticate via Microsoft Graph API.

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

Now, you can connect via the Use client secret credentials by Microsoft or the Connect-MgGraph-Interactive.ps1. This method of accessing the Service Principle 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 due to their inherent trust within cloud environments and 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 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 take advantage of 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 commandGet-MgUser -UserId (Get-MgContext).Accountor event short command with the(Get-MgContext).Account.

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

Note: These commands can run based on the specific User.DeleteRestore.Allpermissions.

Potential MgGraph Recon and Enum Commands

The following command with the Get-MgServicePrincipalextracts 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.

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 for privilege escalation or to 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 is designed to enumerate 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 is used to enumerate all users in the directory, providing 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 filters and lists only enabled user accounts in the directory. This gives attackers a focused list of active accounts that can be immediately exploited without requiring reactivation. This impact is direct, as active accounts represent 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 aids attackers in prioritizing 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 change the Azure AD directory or user data significantly. 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 potentially hijack or exploit these service principals for 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 permission, 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, unable to regain control over 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 departmental confusion. 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, the attacker can run the delete command for many objects. The Remove-MgUser will be part of this action. The script to remove users will be the 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 status of the users and ensure they are removed. You can run the Generate-DeletedAccountsReport.ps1.

TIP: In some cases, the User.DeleteRestore.Allpermissions cannot remove High-Exssesive 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 the legitimate restoration capabilities of a system to obscure their malicious activities. Rather than simply deleting or modifying resources, attackers cycle particular objects—such as user accounts, service principals, or groups—through deletion and restoration events. This repetitive process creates a large volume of legitimate-looking audit log entries, making it difficult for defenders to discern what occurred and 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 where forensic efforts are delayed, and the attacker’s movements are more complex to pinpoint, increasing the complexity and time 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 a deleted state.

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 create noise hindering 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 a real-life scenario, the 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 effectively proceed to the next phase after leveraging Obfuscation Through Restoration, Abuse, or Creating 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, and this stage typically can involve persistence, privilege escalation, lateral movement, and eventually, subscription takeover or data exfiltration, more Enumration scenarios, Persistence, Create New Backdoor via Secret, run Privilege escalation, and Lateral Movement.

In this scenario, the next action after deleting the users (Systematic Deletion Accounts) will be to run more ENUM actions. This time, the results will be for significant action such as lateral movement, priv escalations, and gain 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 underscore 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 execute data exfiltration, sabotage critical configurations, or erase traces by re-deleting the accounts. To mitigate these risks, organizations must adopt a Zero Trust Architecture (ZTA), enforce the Principle of Least Privilege (PoLP), and leverage Cloud Security Tools and Controls solutions to monitor account lifecycle activities for anomalous behavior.

Useful Resources

User.DeleteRestore.All by graphpermissions.merill.net.

Permanently delete an item

Persistence via App Registration in Entra ID