The standard deployment for Intune that we often see is a user having a laptop assigned to them, where their account is configured as a Standard User. The laptops are configured with BitLocker, which prevents the user from simply booting the laptop into another operating system and escalating their privilege to that of local administrator. However, Microsoft allows any Intune user who is assigned a device to access the BitLocker keys for their device. This allows them to unlock the device while booted into Command Prompt and escalate to an administrator account (such as by pulling the SAM or changing one of the executables that runs as SYSTEM).
A popular way to manage devices in corporate networks these days is to assign devices to individual users and manage them through Microsoft Intune. This was especially the case after 2020 when organisations were allowing employees to work from home, but still needed to retain control over the devices for configuration changes.
In Microsoft’s own words, Intune is:
Microsoft Intune is a cloud-based service that focuses on mobile device management (MDM) and mobile application management (MAM). You control how your organisation’s devices are used, including mobile phones, tablets, and laptops. You can also configure specific policies to control applications. For example, you can prevent emails from being sent to people outside your organisation. Intune also allows people in your organisation to use their personal devices for school or work.
Another relevant feature is BitLocker, which can be tightly integrated with Intune. BitLocker encrypts the disks on the system with a password, file from a USB drive, or (most commonly) key material from a Trusted Platform Module (TPM). When configured with a TPM, BitLocker will decrypt the disk transparently to the user, with no additional prompts (unless otherwise configured), as long as the devices motherboard and operating system haven’t changed. This feature ensures that even if a device is lost or stolen, it isn’t possible to read any of the files on the device without knowing the username and password of a valid user account. The checks performed by BitLocker serve as protection from an attacker removing the drive and viewing or modifying the files directly. If this is performed as part of authorised maintenance or troubleshooting, the drive can still be unlocked using a BitLocker Recovery Key.
BitLocker and Intune
One of the nice features that BitLocker deployed via Intune provides is the ability to backup BitLocker Recovery Keys to Azure AD. This allows organisational administrators to view Recovery Keys and help users them recover their device. However, Microsoft also allows any user (including Standard Users) assigned to a device to view its Recovery Keys. This is a feature of Intune that cannot be disabled.
The My Account Portal will show Recovery Keys for any assigned devices
Escalating to Local Administrator
There is no shortage of ways to escalate to a Local Administrator once you can read and write files on the disk, but here are some examples (provided by Twitter):
- Write a DLL to System32 that is loaded by a privileged service
- Replace a services executable
- Rewrite a configuration file for a high privilege program
- Change permissions of sensitive files
- Read and write a SAM file with new users added
Keep in mind that no endpoint protection is going to be able to protect you from this kind of attack, as someone can trivially turn the endpoint protection off (or modify it in such a way that it looks enabled but is not functioning).
This video shows a simple escalation to a Local Administrator, though this is only one possible example of how it could be performed:
- Open the Restart options by holding Shift while selecting the Restart option.
- Select Troubleshoot, Advanced options, Command Prompt, to reboot to a command prompt.
- Enter the BitLocker Recovery Key obtained earlier through the My Account portal.
- Replace the GoogleUpdate.exe binary with a malicious version that adds a new Local Administrator user with a known password (in this case, “zxsecurity”).
- Exit and continue to Windows 10.
- Wait for GoogleUpdate.exe to execute.
- Open command prompt and run “net users”, observing the new account has been added successfully.
Threat Modelling, and why this probably doesn’t matter
As mentioned in the introduction, physical access is generally considered to be a winning situation for any attacker, but it’s still important to understand whether this affects people using Intune. Here are the threats against this system as I see it:
- Attackers targeting your organisation and who have stolen a laptop.
- Users who aren’t malicious, but want to install prohibited software or otherwise modify a device.
- A malicious insider who wants to escalate their privilege locally for further attacks against the organisation.
Thankfully, Microsoft protects users well against the first situation. Even if an attacker steals a laptop, without the login credentials to a user account on the domain, there is no way for them to obtain BitLocker Recovery Keys. Even with phished credentials, an attacker would also require some kind of Two Factor bypass as long as the organisation they’re attacking has robust Conditional Access rules.
Giving users a low privilege account is a good idea, even if there is some kind of technical escalation to a full administrator account. Most users aren’t going to stumble upon this kind of exploit, so it is likely that users will still be restricted by their limited access as intended. Note, however, if you’re a school, this doesn’t apply. Many students devote their time to bypassing restrictions on their school-issued devices and are exactly the kind of users who would exploit this to its fullest extent.
The malicious insider is the worst case for most organisations and is also the situation under which this entire self-service model for BitLocker keys breaks down. The insider has valid login credentials, including the relevant 2FA access for their account, so none of the standard Microsoft protections help you here. As mentioned previously, even EDR/Defender are unlikely to help you, because once a user has full read and write access to a device, they can modify the configuration of any installed software in a way of their choosing before Windows has booted.
If you’re using Microsoft Intune and assigning devices to end-users, you should be aware that all your users are potentially local administrators on their own devices (and as such, the software on their devices is not to be relied upon). This matters most in the case of an insider threat situation.
As Microsoft do not allow organisations to restrict access to the BitLocker Recovery Key feature in the Account Portal, you should have a plan for how you are going to manage this risk.
Most recent posts
- CVE-2021-27938 XSS in Silverstripe CreateQueuedJobTask
- All my Intune users could become Local Administrators and it's a Feature?
- Microsoft GovTech presentation: Azure Security Faux Pas
- DoS Preparation - Maturity Model
- AWSUG Presentation: AWS Security Faux Pas