Abusing Intimate Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments: (In)tune to Takeovers
Recently, a client received assistance from the Mandiant Red Team in visualizing the potential consequences of an advanced threat actor breach. In order to compromise the tenant’s installed Entra ID service principals, Mandiant migrated laterally from the customer’s on-premises environment to their Microsoft Entra ID tenant during the evaluation.
Using a popular security architecture that involves Intune-managed Privileged Access Workstations (PAWs), we will discuss in this blog post a new method by which adversaries can move laterally and elevate privileges within Microsoft Entra ID by abusing Intune permissions (DeviceManagementConfiguration.ReadWrite.All) granted to Entra ID service principals. We also offer suggestions and corrective actions to stop and identify this kind of attack.
A pretext
The client had a well-developed security architecture that adhered to the Enterprise Access model suggested by Microsoft, which included:
- An Active Directory-based on-premises setting that adheres to the Tiered Model.
- A Microsoft Entra Connect Sync-synchronized Entra ID environment that synchronizes on-premises identities and groups with Entra ID. PAWs, which were completely cloud-native and controlled by Intune Mobile Device Management (MDM), were used to administrate this environment. They were not connected to the on-premises Active Directory system. To access these systems, IT managers used a specific, cloud-native (non-synced) administrative account. These cloud-native administrative accounts were the only ones allocated Entra ID roles (Global Administrator, Privileged Role Administrator, etc.).
A robust security barrier was created by separating administrative accounts, devices, and privileges between the Entra ID environment and the on-premises environment:
- Because Entra ID privileged roles are associated with unique, cloud-native identities, a compromise of the on-premises Active Directory cannot be utilized to compromise the Entra ID environment. This is an excellent practice for Microsoft.
- An “air gap” between the administration planes of the two environments is successfully created by using distinct physical workstations for administrative access to cloud and on-premises resources. Attackers find it very challenging to get through air gaps.
- Strong Conditional Access regulations imposed by Privileged Identity Management assigned roles to the administrative accounts in Entra ID, necessitating multi-factor authentication and a managed, compliant device. Additionally, Microsoft recommends these best practices.
Attack Path
One of the objectives of the evaluation was to assign the Mandiant Red Team the task of obtaining Global Administrator access to the Entra ID tenant. Mandiant was able to add credentials to Entra ID service principals (microsoft.directory/servicePrincipals/credentials/update) by using a variety of methods that are outside the purview of this blog post. This gave the Red Team the ability to compromise any preloaded service principal.
There are a number well-known methods for abusing service principal rights to get higher permissions, most notably through the usage of RoleManagement.See AppRoleAssignment and ReadWrite.Directory.Application and ReadWrite.All.ReadWrite.All rights for Microsoft Graph.
However, the Mandiant Red Team had to reconsider their approach because none of these rights were being used in the customer’s environment.
Mandiant found a service principle that was given the DeviceManagementConfiguration after using the superb ROADTools framework to learn more about the customer’s Entra ID system.Go ahead and write.Permission is granted.
The service principal is able to “read and write Microsoft Intune device configuration and policies” with this authorization.
Clients running Windows 10 and later can execute the unique PowerShell scripts used by Intune for device management. Administrators have an alternative to configuring devices with settings not accessible through the configuration policies or the apps section of Intune by using the ability to run scripts on local devices. When the device boots up, management scripts with administrator rights (NT AUTHORITY\SYSTEM) are run.
The configuration of Device Management.Go ahead and write.To list, read, create, and update management scripts via the Microsoft Graph API, all permissions are required.
The Microsoft Graph API makes it simple to write or edit the management script. An example HTTP request to alter an existing script is displayed in the accompanying figure.
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 caller can provide a display name, file name, and description in addition to the Base64-encoded value of the PowerShell script content using the Graph API. Depending on which principle the script should be run as, the runAsAccount parameter can be set to either user or system. RoleScopeTagIds references Intune’s Scope Tags, which associate people and devices. The DeviceManagementConfiguration can likewise be used to construct and manage them.Go ahead and write. Permission is granted.
The configuration of Device Management.Go ahead and write.By changing an existing device management script to run a PowerShell script under Mandiant’s control, Mandiant was able to go laterally to the PAWs used for Entra ID administration with full authorization. The malicious script is run by the Intune management script when the device reboots as part of the user’s regular workday.
By implanting a command-and-control device, Mandiant could give the PAWs any instructions. The Red Team obtained privileged access to Entra ID by waiting for the victim to activate their privileged role through Azure Privileged Identity Management and then impersonating the privileged account (for example, by stealing cookies or tokens). By taking these actions, Mandiant was able to fulfill the assessment’s goal and gain Global Administrator rights in Entra ID.
Remediation and Recommendations
To avoid the attack scenario, Mandiant suggests the following hardening measures:
Review your organization’s security principals for the DeviceManagementConfiguration.ReadWrite.All permission: DeviceManagementConfiguration should be handled by organizations that use Microsoft Intune for device management.Go ahead and write.Since it grants the trustee authority over the Intune-managed devices and, consequently, any identities connected to the devices, all permissions are considered sensitive.
Mandiant advises businesses to routinely check the authorizations given to Azure service principals, with a focus on the DeviceManagementConfiguration.Along with other sensitive permissions (like RoleManagement), there is the ReadWrite.All permission.See AppRoleAssignment and ReadWrite.Directory.Application and ReadWrite.All.ReadWrite.All.
Businesses that manage PAWs with Intune should exercise extra caution when assigning Intune privileges (either via DeviceManagementConfiguration).Use Entra roles like Intune Role Administrator or ReadWrite.All.
Enable Intune’s multiple admin approval: Intune allows you to use Access Policies to demand a second administrator’s approval before applying any changes. By doing this, an attacker would be unable to use a single compromised account to create or alter management scripts.
Think about turning on activity logs for the Microsoft Graph API: Graph API Activity logs, which provide comprehensive details about Graph API HTTP requests made to Microsoft Graph resources, can be enabled to aid in detection and response efforts.
Make use of the features that Workload ID Premium licenses offer: With a Workload-ID Premium license, Mandiant suggests using these features to:
Limit the use of privileged service principals to known, reliable places only. By guaranteeing that only trustworthy places are used, this reduces the possibility of unwanted access and improves security.
Enable risk detections in Microsoft Identity Protection to improve service principal security. When risk factors or questionable activity are found, this can proactively prohibit access.
Keep an eye on service principal sign-ins proactively: Monitoring service principal sign-ins proactively can aid in identifying irregularities and possible dangers. Incorporate this information into security procedures to set off notifications and facilitate quick action in the event of unwanted access attempts.
Mandiant has a thorough grasp of the various ways attackers may compromise their target’s cloud estate with some hostile emulation engagements, Red Team Assessments, and Purple Team Assessments.
