Source URL: https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments/
Source: Cloud Blog
Title: (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments
Feedly Summary: 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/