Loading...

(In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments

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 AUTHORITYSYSTEM).

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/<script id>

{
“@odata.type”: “#microsoft.graph.deviceManagementScript”,
“displayName”: “<display name>”,
“description”: “<description>”,
“scriptContent”: “<PowerShell script in base64 encoding>”,
“runAsAccount”: “system”,
“enforceSignatureCheck”: false,
“fileName”: “<filename>”,
“roleScopeTagIds”: [
“<existing role scope tags>”
],
“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.

Leave a Reply

Your email address will not be published. Required fields are marked *