Organizations continue to implement cloud-based services, a shift that has led to the wider adoption of hybrid identity environments that connect on-premises Active Directory with Microsoft Entra ID (formerly Azure AD). To manage devices in these hybrid identity environments, Microsoft Intune (Intune) has emerged as one of the most popular device management solutions. Since this trusted enterprise platform can easily be integrated with on-premises Active Directory devices and services, it is a prime target for attackers to abuse for conducting lateral movement and code execution.
This research will give a background on Intune, how it is being used within organizations and show how to use this cloud-based platform to deploy custom Windows applications to achieve code execution on user devices. Additionally, this research includes the public release of new Microsoft Sentinel rules to help defenders detect the usage of Intune for lateral movement and defensive hardening guidance for the Intune platform.
Background
Prior work
Abuse of PowerShell script deployment using Intune
Andy Robbins wrote an excellent blog post in 2020 titled, “Death from Above: Lateral Movement from Azure to On-Prem AD,” which covers how to abuse Intune to deploy a PowerShell script to target hosts, along with defensive guidance for protecting against that attack scenario. Our resulting X-Force research builds upon Robbins’ research by showing how to perform targeted code execution with the use of Windows applications and how to perform ad-hoc triggering for Windows hosts to download and run those applications. This research also includes newly created Microsoft Sentinel rules to detect the misuse of Intune to facilitate lateral movement and hardening guidance for the Intune platform.
Maestro – Abusing Intune for lateral movement over C2
Chris Thompson released a tool named Maestro at DEF CON 32 Demo Labs that can be used to perform user and device reconnaissance via Intune, along with command execution via Intune PowerShell scripts or Windows applications from a C2 framework. Make sure to check this tool and Chris’ research out! The following X-Force research differs, as it shows how to conduct this lateral movement activity via the Microsoft Intune web interface and how to package up multiple files to be deployed as part of a custom Windows application for code execution. Additionally, this X-Force research includes more ways of triggering Intune PowerShell scripts and Windows applications to run, along with the release of Microsoft Sentinel detection rule logic to detect lateral movement activity that abuses Intune.
Hybrid identity environments
Many companies have begun adopting a hybrid identity environment, which means the connection of an on-premises Active Directory environment with Microsoft Entra ID (formerly Azure AD). This allows organizations to be more flexible and efficient, which includes better management of user devices and user access to cloud-based applications. Specifically, when devices are hybrid-joined, they are visible and can be managed both in on-premises Active Directory and Microsoft Entra ID. Due to this configuration, the compromise of cloud-based device management solutions can facilitate lateral movement to on-premises devices, such as user workstations that are hybrid-joined.
Microsoft Intune
Microsoft Intune is a cloud-based device management solution that can be used to manage the configuration of devices that are connected to Azure, such as hybrid-joined devices. The following sections highlight how Intune can be used and managed by organizations.
Device management solutions
Microsoft offers several solutions for managing devices within an enterprise. Some of those solutions are listed below:
- Azure Stack
- Windows Admin Center
- SCCM (Configuration Manager)
- Azure Arc
- Microsoft Intune
Microsoft Intune use cases
The primary strategic use cases for organizations to use Microsoft Intune are:
- Patch management
- Allowing secure Office 365 access from personal devices
- Enabling a Bring Your Own Device (BYOD) program
- Device configuration management
- Ability to manage multiple platforms (Windows, macOS, Linux)
Microsoft Intune role-based access
Microsoft provides detailed documentation on the different roles that are available in Intune, along with the privileges of each role. The two privileged roles within Intune that allow the creation of PowerShell scripts or Windows applications are Global Administrator and Intune Service Administrator (aka Intune Administrator).
Scripts and applications that can be deployed with Microsoft Intune
There are several options for performing code execution on Windows hosts via Microsoft Intune. PowerShell scripts can be deployed to allow for code execution via direct command execution within the script. Other types of code execution on Windows devices include the deployment of applications. A couple of the notable application types are listed below:
- Line of Business (LOB) Apps – This can be a Microsoft Software Installer (MSI) file or secure app package (.appx, .appxbundle)
- Windows App (Win32) – This is a .intunewin file, which is a compressed format that contains the necessary application files
Microsoft Intune log files
Log files are written by the Intune Management Extension at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. These logs can be useful to see when a device has been checking in with Intune and if any PowerShell scripts or Windows applications have been run.
When Intune runs a PowerShell script, it creates a temporary copy of the script on disk at C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Scripts and then stores the results of the script at C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Results. After the script is completed, the temporary script and results are removed.
When Intune runs a Windows application, the application is deployed and run from C:\Windows\IMECache\[UNIQUE_GUID]. Once the application is finished executing, the directory is removed.
Common lateral movement execution techniques
There are several lateral movement techniques that are well known by security product vendors and defensive security practitioners, which have readily available documentation in the MITRE ATT&CK Framework. These Windows lateral movement techniques primarily take advantage of administrative protocols and services that can execute programs or scripts. Some of the common lateral movement techniques used by threat actors and offensive security practitioners include the use of Windows Management Instrumentation (WMI), scheduled tasks, services and distributed component object model (DCOM) to execute programs or scripts. From an operational security perspective, finding a unique technique that can execute scripts and programs while originating from trusted software is crucial. Such techniques can blend in with typical enterprise activity and may be ignored by defensive security teams.
Offensive use cases for Microsoft Intune
If you have compromised an Azure user with the appropriate permissions shown in the Microsoft Intune Role-Based Access section, then you can perform code execution on any Windows host that has the Intune agent installed by deploying PowerShell scripts or a Windows application. This can be used as a stealthy and unique lateral movement execution trigger that originates from trusted enterprise software.
The scenario shown in the following section assumes obtained privileged access within the Intune admin center. Additionally, as a part of this scenario, the objective is to obtain interactive command and control (C2) access via a Cobalt Strike beacon on a target host while using Intune as a lateral movement execution trigger.
User and host targeting
Intune uses Entra ID groups to control where scripts or applications are run. Therefore, if a host or group of hosts you are targeting are not already a member of a group, you will need to create one for them so you can control where your script or application is run. Typically, within hybrid identity environments, you can view a user’s associated device(s) within Entra ID. This will allow you to make a list of targeted hosts. This information can also be retrieved using automated tools and scripts, such as ROADtools.
If you need to create a new Microsoft Entra ID group to assign your target host(s), select “Groups” > “New group” within the Intune admin center.
Figure 1: Creating a new group
You can choose to select either target hosts or users, as shown in the respective screenshots below. In this case, we are creating a group to target the WIN-8675309 host.
Figure 2: Adding target device to a group
Figure 3: Adding target user to group
A summary of your group will be shown, and you can then create it.
Figure 4: Summary of a group to create
Ad-hoc triggering
There are multiple ways to perform immediate ad-hoc triggering of your deployed PowerShell script or Windows application from Intune. These include:
- Forcing a device restart via the Intune admin center
- Forcing a device sync via the Intune admin center
- Restarting the “IntuneManagementExtension” Windows service on a target host (if you have connectivity)
Alternatively, you can wait for the next time the device restarts on its own or the next time the host’s Intune agent checks in with Intune for any new PowerShell scripts or Windows applications.
Deploying a Windows application
Deploying a Windows application instead of a PowerShell script is an alternative method for performing code execution. This method is more flexible, as it allows for the packaging of multiple files that get deployed and executed on a target host by the Intune agent. This is beneficial from an attacker’s perspective for payload deployment, such as deploying a DLL sideloading payload that requires multiple files. The process of deploying a Dism.exe DLL sideload payload via an Intune Windows application will be detailed below.
Use the Win32 Content Prep Tool from Microsoft to package the payload files within an .intunewin file. This is a compressed file format that allows the secure deployment of an application. Details on how this packaging works can be found in this blog post. In this example, we have a directory that contains an executable and DLL file. We use the Win32 Content Prep Tool to package those files into an .intunewin file.
Figure 5: Building compressed intunewin file
The output .intunewin file will be written to the output directory you specified. In this case, we have packaged Dism.exe and DismCore.dll in the Dism.intunewin file.
Figure 6: Output file
Now that you have the Windows application package created, you can proceed with deploying it. Within Intune admin center, navigate to “Apps” > “Windows apps” > “Add”.
Figure 7: Add application
Select “Windows app (Win32)” from the dropdown menu:
Figure 8: Choosing Windows app
Upload the .intunewin file that was previously created and populate the information for your application.
Figure 9: Populating app information
Next, add an install command, which will be the executable (Dism.exe) in this case. For the uninstall command, you can enter anything. Additionally, we are choosing to run this application as “System” and for device restart behavior we have selected “No specific action”. When choosing “System”, this means it will run as the NT AUTHORITY\SYSTEM account.
Figure 10: Filling in program information
Detection rules are used to prevent the installation of an application when it already exists. Therefore, if the result of a detection rule is successful, an application will not be installed. Since we want our application to run no matter what, we have uploaded a PowerShell script in this case that attempts to execute a non-existent binary. This way, the detection script will always fail, which means that the application is not present, and the installation will continue.
Figure 11: Adding detection rules
Skip the “Dependencies” and “Supersedence” sections and add the group with your target host(s) within the “Assignments” section:
Figure 12: Adding group assignments
After creating the Windows application, you will see it within the Intune admin center and the “Assigned” column should say “Yes”. This means that the Windows application has been assigned to the groups you specified and is waiting to be deployed and run.
Figure 13: Showing app is assigned
To perform ad-hoc triggering of the Intune agent on the target host, we will restart the “IntuneManagementExtension” service. It can take up to five minutes after the service has been restarted for the target host to download and run your Windows application from Intune. If the target host has not downloaded and run your Windows application after five minutes, the service may have to be restarted again. Other methods to perform ad-hoc triggering are in the Ad-Hoc Triggering section.
Figure 14: Restarting IntuneManagementExtension service
After the service has been restarted, you can monitor AgentExecutor.log and IntuneManagementExtension.log within the C:\ProgramData\Microsoft\IntuneManagementExtension\Logs directory on the target host. Once the last modified date on the AgentExecutor.log file has been updated, the Intune agent should have downloaded and run the Windows application. Additionally, you can monitor the C:\Windows\IMECache directory to see when your application files have been downloaded. There will be a subfolder created with a unique GUID.
At this point, the Windows application has been deployed and executed, and we have obtained a Cobalt Strike beacon on the target host of WIN-8675309.
Figure 15: Obtaining beacon
Detecting and preventing Intune lateral movement activity
Several defensive considerations will be outlined in this section to increase configuration hardening and detection capabilities for Intune against the attack scenarios described in this research.
Setup Intune audit logging
To create detection or threat-hunting rules for lateral movement activity that abuses Intune, you first need to enable audit logging. Within the Intune admin center, select “Tenant administration” > “Diagnostic settings” > “Add diagnostic setting”:
Figure 16: Adding diagnostic setting
Select “AuditLogs” and “OperationalLogs”, and then choose to send your logs to a Log Analytics workspace:
Figure 17: Enabling audit logs
You will start to see the IntuneAuditLogs and IntuneOperationalLogs schemas start to populate within your Log Analytics workspace.
Figure 18: Showing schemas available in Log Analytics Workspace
After you start receiving Intune logs in your Log Analytics workspace, you can use that workspace in a Microsoft Sentinel instance to start building threat-hunting and analytic rules, which will be outlined in the following section.
New Microsoft Sentinel rules
There are currently no publicly available analytic rules for Microsoft Sentinel to detect the Intune attack scenarios described in this research. Therefore, provided in the sections below are multiple pieces of rule logic that can be applied as scheduled analytic rules within Microsoft Sentinel for the below attack scenarios within Intune:
- User-created PowerShell script or Windows application
- User-created and deleted PowerShell script
- User-created and deleted Windows application
- User-created PowerShell script or Windows application and forced a device restart
- User-created PowerShell script or Windows application and forced a device sync
For each of these analytic rules, it is recommended to perform testing and tuning in your environment appropriately. The KQL queries highlighted below can be copied and pasted from this KQL-Queries repository.
User-created PowerShell script or Windows application
The rule logic linked below will alert any time a user has created a PowerShell script or Windows application for deployment.
CreatedPSScriptOrWindowsApp.kql
An example of this rule triggering in Microsoft Sentinel is shown in the screenshots below.
Figure 19: Alert triggering
Figure 20: Event details for alert
User-created and deleted PowerShell script
The rule logic linked below returns any users who have created and deleted a PowerShell script within 24 hours. This could be evidence of an attacker attempting to cover their tracks after deploying a PowerShell script.
CreatedAndDeletedPSScript.kql
An example of this rule triggering in Microsoft Sentinel is shown in the screenshots below:
Figure 21: Alert triggering
Figure 22: Event details
User-created and deleted Windows application
The rule logic linked below returns any users who have created and deleted a Windows application within 24 hours. This could be evidence of an attacker attempting to cover their tracks after deploying a Windows application.
CreatedAndDeletedWindowsApp.kql
An example of this rule triggering in Microsoft Sentinel is shown in the screenshots below:
Figure 23: Alert triggering
Figure 24: Event details
User-created PowerShell script or Windows application and forced a device restart
The rule logic linked below returns any users who have created a PowerShell script or Windows application and have also issued a device restart within 24 hours.
CreatedPSScriptOrWindowsAppForcedRestart.kql
An example of this rule triggering in Microsoft Sentinel is shown in the screenshots below:
Figure 25: Alert triggering
Figure 26: Event details
User-created PowerShell script or Windows application and forced a device sync
The rule logic below returns any users who have created a PowerShell script or Windows application and have also issued a device sync within 24 hours.
CreatedPSScriptOrWindowsAppForcedSync.kql
An example of this rule triggering in Microsoft Sentinel is shown in the screenshots below:
Figure 27: Alert triggering
Figure 28: Event details
Configure admin approval for script or app deployment
Approval policies can be created so that a member in a specified group will be required to approve any new script or application deployments. Applying these policies in conjunction with the detection rules previously outlined can significantly bolster the security posture of your Intune instance.
Approval for scripts
Navigate to “Tenant administration” > “Multi Admin Approval” > “Access policies” > “Create”.
Figure 29: Creating access policy
Fill in the required information, such as the access policy name, description and profile type. For the profile type, select “Script”.
Figure 30: Filling access policy information
Add a group or multiple groups that will be responsible for approving any new script deployments.
Figure 31: Adding approval group
After creating your policy, you will see it populated in the “Access policies” tab.
Figure 32: Viewing created policy
Now that the policy is applied, when a user tries to create a new script they will receive the below message. After submitting the request with business justification, an approver from a specified group will need to allow the script to be deployed.
Figure 33: Submitting script for approval
Approval for applications
The same steps previously outlined can also be performed to require approval for any application deployment. Ensure you choose “App” from the Profile type dropdown menu when creating the access policy.
Figure 34: Creating application access policy
You can see a summary of our policy that we have created that includes the Profile type of “App”.
Figure 35: Summary of application access policy
Now that the policy is applied when a user tries to create a new application, they will receive the message below. After submitting the request with a business justification, an approver from a specified approval group will need to approve it before the application is deployed.
Figure 36: Submitting application for approval
Microsoft Entra ID best practices
Microsoft has a Microsoft Entra ID best practice guide that highlights detailed guidance on securing your Microsoft Entra ID configuration. Some of the more important recommendations related to the abuse of privileged roles in Microsoft Intune are:
- Enable multi-factor authentication (MFA) for privileged Azure roles
- Review privileged Azure access on a regular basis
- Cloud-only accounts should be used for privileged Azure roles
Conclusion
The adoption of hybrid identity architecture and the use of cloud-based services continues to increase. Organizations depend on these cloud-based services to manage their enterprise infrastructure, which includes managing user endpoints and personal devices that connect to Office 365 and other cloud-based services. As such, being able to properly detect the misuse of cloud-based services such as Microsoft Intune has become more critical than ever. X-Force aims for this research to highlight and inspire further investigation into defending other business-critical cloud-based services that can be abused by threat actors for lateral movement and code execution.
Acknowledgments
A special thank you to the below people for giving feedback on this research and providing blog post content review:
Adversary Simulation, X-Force Red