Side booting with Microsoft Intune

Published by Matt Stiles, Security Testing & Assurance (STA) on 18 November 2025

Microsoft Intune has changed the state of play when it comes to local privilege escalation (LPE), reviving a once-forgotten initial access technique, as a living-off-the-land (LoTL) privilege escalation technique for insider threats.

I have performed a range of purple team exercises and endpoint resilience assessments (ERA) at CyberCX, achieving privileged access to the endpoint during each; by leveraging an often overlooked Microsoft Intune setting “Restrict users from recovering the BitLocker key(s) for their owned devices”. Which can be found under Device Settings in the Entra ID Admin Centre.

This setting, when toggled to “No”, allows all users to retrieve the BitLocker recovery key for their own devices. In all but one assessment, the device was already provisioned and Entra-joined. The one exception was during a purple team assessment where compromised user credentials were used to self-register a new device and configure BitLocker ourselves, instead of retrieving recovery keys for an already configured device. Otherwise, each assessment followed the same flow.

The diagram illustrates an attack path leveraging the live OS technique to achieve privileged access over Microsoft Intune managed devices. This method, popularised in the early 2000s, prompted the development of key endpoint controls:

Secure Boot: Ensures the integrity of the boot process.
Full Disk Encryption (FDE): Protects the confidentiality and integrity of data.

FDE without Secure Boot:

OS data remains encrypted due to Trusted Platform Module (TPM) dependency, but adversaries can boot a second OS from external media.

Secure Boot without FDE:

Adversaries can remove the drive, bypass Secure Boot on a second device, and access OS contents.

Secure Boot with FDE:

Combines integrity of boot process (Secure Boot) with data protection (FDE), preventing unauthorised access to both the boot process and data.

By the mid-2010s, Microsoft BitLocker had become the standard FDE solution for consumer Windows-based endpoints, simply because it was already integrated within the OS. This effectively reduced the prevalence of the live OS attacks against the consumer endpoint. However, manual recovery key management was burdensome for large fleets. Microsoft Intune has simplified this by automatically backing up recovery keys for Entra-joined devices, reducing operational overhead and improving endpoint resilience.

So what?

Many organisations have a compliance requirement (i.e. ISO 27001:2022, NIST SP 800-171) that in some form and fashion requires FDE to be implemented on end-user devices. It can often feel like organisations lose sight of the intent of FDE; it provides:

confidentiality from untrusted parties with physical access to the device, and
integrity of the boot process (spooky foreshadowing)

Giving users the ability to retrieve their own recovery keys mean that the integrity of the boot process can be broken, as the user can decrypt and modify the OS partition.

How do adversaries do it?

After retrieving the recovery key, the adversary can boot into the Windows Recovery Environment (WinRE); from which they can decrypt the OS partition. The next step would be to modify the filesystem or Windows Registry of the primary OS from within the environment to achieve privileged access the next time a full boot of the primary OS occurs. There are many different ways adversaries have done this in the past, including:

Swapping the utilman. exe from the cmd. exe executables, then invoking the Accessibility functionality from the Windows logon screen, or
My preferred method – to modify the Windows Registry to change the setup option to spawn a NT Authority\SYSTEM PowerShell terminal at the Windows logon screen.

Any of these approaches allow the adversary to achieve temporary privileged access, and perform a secondary action, such as adding their own account to the endpoint’s local administrators group for persistent privileged access.

Wait, what about Secure Boot and what is the Windows Recovery Environment?

Secure Boot can help prevent insider threats from booting an external OS to modify the decrypted OS partition; but they also do not need to use an external OS. Microsoft includes an external OS beside the primary OS, called the Windows Recovery Environment (WinRE). Its purpose is to provide a platform to recover from faults. As we are not removing physical disks, Secure Boot is unaffected. Windows comes pre-loaded with an external OS that can be used to perform living-off-the-land OS side booting.

So why should I care?

The endpoint security posture of many organisations relies on users not having privileged access to their own device. Unless an organisation has finished their shift to becoming a cloud-only organisation, having privileged access over the endpoint is still highly valuable to an adversary. As an adversary can disable endpoint security controls and stage subsequent attacks from a compromised trusted device.

Everything that was described above, happens before application control, endpoint detection and response (EDR) solutions are enabled, and therefore they can’t stop these insider threats from achieving privileged access. The activity often looks like a magic trick in a SIEM, the device is restarted, then the next logs that are sent to the SIEM are related to the NT Authority\SYSTEM account adding a new user to the local administrators group. Which is oftentimes written off as benign activity because the lack of contextual insight.

Ok and?

Well, it really depends on the environment and organisation. Security is all about custom and contextual considerations. Often, privileged access is exactly what the adversary would need to degrade endpoint defences. Here are some of the impacts I have encountered having gained privileged access by abusing Microsoft Intune on a managed device:

Having privileged access to a trusted endpoint that can pass certificate-based network access control (NAC), or Entra ID device compliance checks
Disabling the Windows Services of local Privilege Access Management (PAM) solutions and Managed Detection and Response (MDR) agent; this was also possible due to lack of tamper protections being enabled
Modifying the local copy of the application control policy
Installing virtualisation to defeat software application control and EDR.

Ultimately gaining privileged access to a trusted endpoint is way more powerful in a hybrid AD-Entra environment. However, it can still be powerful in cloud-only environments to have privileged access to a trusted device.

What can I do about it?

While chatting with a previous customer, they mentioned that the ability for either users to be able to self-service themselves was key in their response to the 19^th of July 2024 CrowdStrike outage. This is a reasonable justification for why the setting should be enabled. Although this should not be the norm, rather an exception that is outlined in a break glass procedure.

Ideally organisations have a key management strategy (also required by ISO 27001:2022), that strips the ability for all users to access their BitLocker recovery keys. Instead implement a system where IT helpdesk groups, or similar, can retrieve recovery keys on behalf of users. The groups either get assigned the explicit microsoft.directory/bitlockerKeys/key/read permission, or more generally add the built-in Helpdesk Administrator tenant role to the groups. This is typically the more preferred role because it allows the members to retrieve the recovery key for any managed device, unlike the Cloud Device administrator, without being overly too permissive as well. The following built-in tenant roles have the microsoft.directory/bitlockerKeys/key/read permission:

Cloud Device Administrator
Helpdesk Administrator
Intune Administrator
Security Administrator
Global Administrator
Security Reader
Global Reader

Demo

The following is a demonstration of the attack path in my test tenant, which is a freshly deployed CDX environment with a Microsoft 365 E5 license; and the important settings are:

Global administrator role is added as local administrator on the device during Microsoft Entra join (Preview) is set to No
Registering user is added as local administrator on the device during Microsoft Entra join (Preview) is set to None
Restrict users from recovering the BitLocker key(s) for their owned devices is set to No (this is the default value)
An Automatic Enrolment policy was created within Microsoft Intune.

These settings combine mean that I can enrol a new device into Entra, configure BitLocker to store the recovery keys into Entra, retrieve said keys, and the low privileged Entra identity will not be added to the device’s local administrator group while enrolling the device.

The below screenshot shows that the newly registered device, registered by adelev, is a managed device as well.

When setting up BitLocker, the user is prompted to save credentials; the first option is to save the credentials within Microsoft Intune.

The BitLocker recovery keys have now been stored in Microsoft Intune.

BitLocker is configured on the new device.

The next step is to access the Microsoft Intune Company Portal website (https://portal.manage.microsoft.com), the Microsoft Intune Company Portal app does not let users access their recovery code currently.

Once at the initial WinRE’s landing page, navigate through the following screens:

Troubleshoot > Advanced options > Command Prompt

After clicking the Command Prompt button, the user is prompted to supply the recovery key, shown below:

After successfully decrypting the OS partition, it is accessible from the WinRE command prompt.

Then it is just a matter of performing steps for the selected method; I’ve chosen to perform my preferred Windows Registry modification method to spawn a SYSTEM-level prompt on the next full reboot. The following screenshot illustrates the modified registry keys within the OS’ own SYSTEM hive, after it had been loaded as a temporary hive within the WinRE registry.

The following screenshot shows the spawned SYSTEM-level prompt, and it being used to add a cloud identity to the local administrators group.

The following screenshot shows the adelev identity is a member of the local administrators group, but due to the newly introduced User Access Control (UAC) split token mechanism in Windows 11, the user only has medium-integrity access. The final step was to step up to high-integrity access, which is also shown.