Cover Photo by Kafka Anokhina on Unsplash
This is a personal blog and all content therein is my personal opinion and not that of my employer.
Introduction
In this post, I’m going to talk about an issue I spotted recently, to make you aware of an overly privileged built-in role in Microsoft Entra and the potential attack path that it exposes.
The Issue
I was doing some work to harden an Azure tenant and noticed an issue around Role Based Access Control (RBAC) for Bitlocker.
What Is Bitlocker?
BitLocker is a security feature that provides data-at-rest encryption for disk volumes, protecting against data theft or exposure from lost or stolen devices
You can increase the strength of Bitlocker as a device data-at-rest protection capability by combining it with a Trusted Platform Module (TPM) chip which is a common hardware component installed on Windows devices.
The TPM works with BitLocker to ensure that a device hasn’t been tampered with while the system is offline.
In addition to the TPM, BitLocker can lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device that contains a startup key.
So, a Bitlocker recovery key then, allows you to decrypt a hard drive encrypted by Bitlocker in the scenario where the user has lost their pre boot PIN.
Sounds like something we’d want to ensure doesn’t fall into the wrong hands right?…
Bitlocker Recovery
Microsoft have a good article on this which covers the process and also the permissions you might need.
There is a self recovery option where you can have Bitlocker recovery keys written to Microsoft Entra or Active Directory Domain Services (On-premise AD that we all know and love).
This enables a scenario where a user can retrieve their own recovery keys for their devices from https://myaccount.microsoft.com/
You can also retrieve them from Azure Portal or Entra Admin Center if you have the appropriate permission microsoft.directory/bitlockerKeys/key/read with the appropriate scope (to read your own or every users if you are an administrator).
Concerns
Reading the Bitlocker recovery process, it seems as though Microsoft are adhering to fundamental security best practices such as the principle of Least Privilege and Separation of Duties (SoD)
Microsoft themselves recommend saving BitLocker recovery keys to Microsoft Entra ID or AD DS to enable BitLocker administrators or helpdesk analysts to assist users in attaining their keys.
By default, users can retrieve their BitLocker reecovery keys from Microsoft Entra ID.
This can be disabled globally within the tenant. For more information, see Restrict member users’ default permissions.
The recovery process documentation also states that there are a few Microsoft Entra ID roles that allow a delegated administrator to read BitLocker recovery passwords from the devices in the tenant including Cloud Device Administrator or Helpdesk Administrator built-in roles or by creating custom roles with the microsoft.directory/bitlockerKeys/key/read permission.
Nowhere does it mention the Global Reader role.
It is also possible for roles to be delegated to access BitLocker recovery passwords for devices in specific Administrative Units.
The Microsoft Entra Admin Center allows administrators to retrieve BitLocker recovery passwords.
So, you’d need to have a privileged role like Global Administrator, Cloud Device Administrator or Helpdesk Administrator to access recovery keys that don’t belong to your devices right?…
Enter GLOBAL READER
Global Reader is a role often granted to anyone who needs to be able to view configuration and metadata in Entra without having the ability to actually change configuration.
It’s also a common concept in Azure that Reader roles only let you read configuration and metadata in the control plane but provides no data plane access.
For that reason, it’s not at all uncommon to grant this role to not only staff who don’t directly administer Azure or Entra but also third parties who need “read only” access to perform assessments such as security posture reviews.
I had for years made the assumption (always dangerous, I know) that Global Reader followed the same control plane only model that Reader roles in Azure adhere to.
I had also noticed that more recently, Microsoft have started to tag roles and permissions that they deem privileged with a PRIVILEGED label in the admin portals and in their documentation. I decided to check the documentation (never a bad thing)…
Can A READER Role Access ALL Bitlocker Keys?
The Entra Built-in Roles documentation for Global Reader has the following description:
This is a privileged role. Users in this role can read settings and administrative information across Microsoft 365 services but can’t take management actions. Global Reader is the read-only counterpart to Global Administrator. Assign Global Reader instead of Global Administrator for planning, audits, or investigations. Use Global Reader in combination with other limited admin roles like Exchange Administrator to make it easier to get work done without the assigning the Global Administrator role. Global Reader works with Microsoft 365 admin center, Exchange admin center, SharePoint admin center, Teams admin center, Microsoft 365 Defender portal, Microsoft Purview compliance portal, Azure portal, and Device Management admin center.
That all sounds pretty reasonable until you look at the permissions the role has and the first one labelled as privileged reads:
| Action | Description |
|---|---|
| microsoft.directory/bitlockerKeys/key/read | Read bitlocker metadata and key on devices. PRIVILEGED |
Remember how this role is Global in scope?…
Microsoft’s Response
I haven’t raised with Microsoft Security Response Center because this isn’t a vulnerability, it’s an insecure design choice.
I raised with Microsoft support and was advised that this is intended behaviour (which doesn’t seem to align with the role description which states that it grants the ability to read settings and administrative information across Microsoft 365 services) and if I am concerned then I should instead create a custom role that includes only the permissions that meet my requirements.
I fundamentally disagree with this statement but since there is no suggestion that they will budge on this, I’m making you aware so that you can take your own precautions such as:
Create and assign a custom role in Microsoft Entra ID and use it instead of Global Reader (this does have a disadvantage in that you now have to maintain that role and add the appropriate future permissions to it as Microsoft develop new and existing products/features)
Setup a SOC alert for anyone reading bitlocker keys that are not their own. I’ve quickly started you off with basic KQL below to surface these events for reading of bitlocker keys but you would want to enhance it to reduce false positives by only triggering where the key doesn’t belong to the user reading it and where that user does not hold the appropriate built-in or custom admin role for your organisation (such as those mentioned in Microsoft’s own Bitlocker recovery process documentation).
AuditLogs | where ActivityDisplayName == “Read Bitlocker Key"
Is This A Recent Change By Microsoft?
It appears to have been like this for many years - the documentation for that permission within the Global Reader role was last amended in October 2022 and that wasn’t to add the permission to the role, it was to reflect a change to the permission name.
Call To Action
Since Microsoft won’t do anything, I’m asking you to:
- Share this blog post far and wide!
- Upvote this feedback request requesting that Microsoft remove this permission from Global Reader
- Raise it with Microsoft Support if you have a support plan
- Raise it with your Microsoft account team
Summary
Apart from learning that it’s possible to read the Bitlocker recovery key of every user device in your Entra tenant with only the Global Reader role, this serves as a reminder to regularly check the permissions that are applied to RBAC roles, not only in those that you define but also built-in vendor supplied roles.
As ever, thanks for reading and feel free to leave comments down below!
If you like what I do and appreciate the time and effort and expense that goes into my content you can always 