Full Report
Written by: Thibault Van Geluwe de Berlaere, Karl Madden, Corné de Jong The Mandiant Red Team recently supported a client to visualize the possible impact of a compromise by an advanced threat actor. During the assessment, Mandiant moved laterally from the customer’s on-premises environment to their Microsoft Entra ID tenant and obtained privileges to compromise existing Entra ID service principals installed in the tenant. In this blog post, we will show a novel way of how adversaries can move laterally and elevate privileges within Microsoft Entra ID when organizations use a popular security architecture involving Intune-managed Privileged Access Workstations (PAWs) by abusing Intune permissions (DeviceManagementConfiguration.ReadWrite.All) granted to Entra ID service principals. We also provide remediation steps and recommendations to prevent and detect this type of attack. Pretext The customer had a mature security architecture following Microsoft’s recommended Enterprise Access model, including: An on-premises environment using Active Directory, following the Tiered Model. An Entra ID environment, synced to the on-premises environment using Microsoft Entra Connect Sync to synchronize on-premises identities and groups to Entra ID. This environment was administered using PAWs, which were not joined to the on-premises Active Directory environment, but instead were fully cloud-native and managed by Intune Mobile Device Management (MDM). IT administrators used a dedicated, cloud-native (non-synced) administrative account to log in to these systems. Entra ID role assignments (Global Administrator, Privileged Role Administrator, et cetera.) were exclusively assigned to these cloud-native administrative accounts. The separation of administrative accounts, devices and privileges between the on-premises environment and the Entra ID environment provided a strong security boundary: Using separate, cloud-native identities for Entra ID privileged roles ensures a compromise of the on-premises Active Directory cannot be used to compromise the Entra ID environment. This is a Microsoft best practice. Using separate physical workstations for administrative access to on-premises resources and cloud resources effectively creates an ‘air gap’ between the administration plane of the two environments. Air gaps are especially difficult for attackers to cross. The administrative accounts in Entra ID were assigned roles through Privileged Identity Management enforced by strong Conditional Access policies, requiring a managed, compliant device and multi-factor authentication. These are also Microsoft-recommended best practices. Attack Path As part of the assessment objectives, the Mandiant Red Team was tasked with obtaining Global Administrator privileges in the Entra ID tenant. Through various techniques out of scope for this blog post, Mandiant obtained privileges in the Entra ID tenant to add credentials to Entra ID service principals (microsoft.directory/servicePrincipals/credentials/update), allowing the Red Team to compromise any preinstalled service principal. A few publicly known techniques exist to abuse service principal privileges to obtain elevated permissions, most notably using the RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All Microsoft Graph permissions. None of these permissions were in use in the customer’s environment though, forcing the Mandiant Red Team to rethink their strategy. Mandiant used the excellent ROADTools framework to gain further insight into the customer’s Entra ID environment, and discovered a service principal that was granted the DeviceManagementConfiguration.ReadWrite.All permission. Figure 1: Service principal was granted DeviceManagementConfiguration.ReadWrite.All permissions (screenshot from ROADTools) This permission allows the service principal to "read and write Microsoft Intune device configuration and policies". Intune’s device management scripts are custom PowerShell scripts that can run on clients running Windows 10 and later. The ability to run scripts on local devices gives administrators an alternative to configuring devices with settings that are not available under the configuration policies or in the apps part of Intune. Management scripts are executed when the device starts, with administrative privileges (NT AUTHORITY\SYSTEM). Figure 2: Intune management scripts are executed at startup The DeviceManagementConfiguration.ReadWrite.All permission is sufficient to list, read, create and update management scripts through the Microsoft Graph API. Figure 3: Device management scripts can be modified with DeviceManagementConfiguration.ReadWrite.All The management script can easily be created or modified using the Microsoft Graph API. The following figure shows an example HTTP request to modify an existing script. PATCH https://graph.microsoft.com/beta/deviceManagement/ deviceManagementScripts/ { "@odata.type": "#microsoft.graph.deviceManagementScript", "displayName": "", "description": "", "scriptContent": "", "runAsAccount": "system", "enforceSignatureCheck": false, "fileName": "", "roleScopeTagIds": [ "" ], "runAs32Bit": false } The Graph API allows the caller to specify the PowerShell script content in Base64-encoded value, along with a display name, file name and description. The runAsAccount value can be configured as user or system, depending on the principal the script should be executed as. The roleScopeTagIds value references Scope Tags, an Intune mechanism that groups devices and users together. These can also be created and managed with the DeviceManagementConfiguration.ReadWrite.All permission. The DeviceManagementConfiguration.ReadWrite.All permission allowed Mandiant to move laterally to the PAWs used for Entra ID administration by modifying an existing device management script to execute a Mandiant-controlled PowerShell script. When the device reboots as part of the user’s daily work, the Intune management script is triggered and executes the malicious script. By launching a command-and-control implant, Mandiant could execute arbitrary commands on the PAWs. The Red Team waited for the victim to activate their privileged role through Azure Privileged Identity Management and impersonated the privileged account (e.g., through cookie or token theft), thereby obtaining privileged access to Entra ID. These steps allowed Mandiant to obtain Global Administrator privileges in Entra ID, completing the objective of this assessment. Remediation and Recommendations Mandiant recommends the following hardening recommendations to prevent the attack scenario: Review your organization’s security principals for the DeviceManagementConfiguration.ReadWrite.All permission: Organizations using Microsoft Intune for device management should treat the DeviceManagementConfiguration.ReadWrite.All permission as sensitive, as it gives the trustee a control relationship over the Intune-managed devices, and by extension, any identities associated with the device. Mandiant recommends organizations to regularly review the permissions granted to Azure service principals, paying special attention to the DeviceManagementConfiguration.ReadWrite.All permission, as well as other sensitive permissions (e.g., RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All).Organizations that use Intune to manage PAWs should be especially careful delegating Intune privileges (either through DeviceManagementConfiguration.ReadWrite.All or through Entra roles such as Intune Role Administrator). Enable multiple admin approval for Intune: Intune supports using Access Policies to require a second administrator to approve any changes before a change is applied. This would prevent an attacker from creating or modifying management scripts with a single compromised account. Consider enabling Microsoft Graph API activity logs: Enablement of Graph API Activity logs can help in detection and response endeavors providing detailed information about Graph API HTTP requests made to Microsoft Graph resources. Utilize capabilities provided by Workload ID Premium licenses: When licensed for Workload-ID Premium Mandiant recommends leveraging these capabilities to: Restrict privileged service principal usage from known trusted locations only. This limits the risk of unauthorized access and strengthens security by ensuring the use only from trusted locations. Enhance the security of service principals by enabling risk detections in Microsoft Identity Protection. This can proactively block access when suspicious activities or risk factors are identified. Proactively monitor service principal sign-ins: Proactively monitoring sign-ins from service principals can help detect anomalies and potential threats. Integrate this data into security operations to trigger alerts and enable rapid response to unauthorized access attempts. Through numerous adversarial emulation engagements, Red Team Assessments, and Purple Team Assessments, Mandiant has gained an in-depth understanding of the unique paths attackers may take in compromising their target’s cloud estate. Review our Technical Assurance services and contact us for more information.
Analysis Summary
The provided article does not detail a specific malware family, conventional attack tool, or a set of granular TTPs in the manner usually associated with conventional malware analysis reports. Instead, it describes an **attack scenario or methodology observed during a Red Team engagement**, focusing on lateral movement and privilege escalation within a Microsoft Entra ID environment, specifically by misusing permissions granted to a Service Principal, likely tied to Microsoft Intune capabilities.
For the purpose of this summary, the primary focus will be on the **Attack Technique/Procedure** described: **Abuse of Intune Permissions to compromise Service Principals**.
# Tool/Technique: Compromise via Lateral Movement to Entra ID Service Principal Abuse
## Overview
This describes an attack path observed during a Red Team engagement where an adversary successfully moved laterally from an on-premises environment into the client's Microsoft Entra ID tenant. The core focus is the compromise of an existing Entra ID Service Principal whose permissions allowed for further malicious actions, potentially leveraging Intune management capabilities.
## Technical Details
- Type: Technique / Attack Methodology
- Platform: Microsoft Azure/Microsoft Entra ID (Cloud Environment)
- Capabilities: Lateral movement, privilege escalation, compromise of cloud identity assets (Service Principals).
- First Seen: Not explicitly stated, but represents a contemporary cloud attack vector observed in late 2024.
## MITRE ATT&CK Mapping
Since this involves cloud environments and privilege misuse, the mapping leans heavily on Cloud-focused tactics and techniques:
- **TA0008 - Lateral Movement**
- T1078.004 - Valid Accounts: Cloud Accounts (Specifically focusing on compromised application/service identities)
- **TA0004 - Privilege Escalation**
- T1098 - Account Manipulation (Manipulating permissions associated with service principals)
- **TA0006 - Credential Access** (Needed to gain the initial foothold used for lateral movement)
- T1558.004 - Steal Application Access Token (Implied, required for subsequent abuse)
## Functionality
### Core Capabilities
- Establishing a foothold in the on-premises environment.
- Synchronizing or leveraging established synchronization mechanisms (e.g., Entra Connect Sync) to facilitate movement or bridge the gap to the cloud environment.
- Identifying and exploiting Service Principals that possess excessive or sensitive permissions within Entra ID (potentially related to Intune management).
### Advanced Features
- Lateral movement leveraging existing trust relationships between on-premises and cloud environments.
- The ability to leverage existing, legitimate, but misused permissions granted to a Service Principal ("abuse of Intune permissions") to perform actions on behalf of the service, potentially leading to deployment of malicious scripts or configuration changes.
## Indicators of Compromise
As this is a methodology summary, specific file hashes or malware indicators are not present. Indicators are purely behavioral/configuration based:
- File Hashes: N/A
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: Potential communication related to the initial lateral movement (on-premises), and subsequent Graph API or administrative endpoint calls targeting Entra ID/Intune resources. (None provided in output).
- Behavioral Indicators: Increased activity or unusual administrative actions performed by the compromised Service Principal identity.
## Associated Threat Actors
The context implies this scenario was executed by an **Advanced Threat Actor** during a specialized Red Team assessment, suggesting novel or sophisticated techniques are employed by well-resourced persistent threats.
## Detection Methods
The recommended detection methods focus on monitoring the environment's configuration and audit logs:
- Signature-based detection: Not applicable for configuration abuse.
- Behavioral detection: Monitoring service principal sign-ins and permission changes.
- YARA rules: Not applicable.
## Mitigation Strategies
The remediation recommendations focus heavily on configuration management and auditing within Microsoft 365/Entra ID:
- Review and restrict the permissions granted to existing Service Principals, especially those related to Intune configuration.
- Enable the **"Multiple Admin Approval for Intune Access"** policy to enforce stricter controls over administrative access via Graph API/Service Principals.
- Consider enabling **Graph API Activity Logs** for detailed auditing of API calls made by Service Principals.
- Utilize **Workload Identity Premium License capabilities** (if applicable) for enhanced identity protection.
- Proactively monitor Service Principal sign-ins and enable alerts specifically for managing scripts or sensitive configuration changes.
## Related Tools/Techniques
- **Privilege escalation via Application Consent Exploitation:** Similar concepts where initial access grants access to application identities.
- **Attacks against Microsoft Graph API:** The Service Principal abuse relies on accessing resources through the Graph API endpoint.
- **Golden SAML attacks** or **Kerberos Stomping** (if initially used for the on-premises compromise supporting lateral movement).