This blog will be the first one in the Windows Enrollment Attestation / MDM Hardening series. In it, I will take a closer look at a beautiful function/feature that was added to the mdmregistration.dll and the omadmclient.exe last year. This function is part of the recently announced Windows Enrollment Attestation.
1. The beginning of Windows Enrollment Attestation / MDM hardening
A little over a year ago, I was describing how you could export and import the Intune MDM device certificate when that certificate somehow ended up in the wrong certificate store. This blog dates back to 2022-09 (remember that date)
Intune | MDM-only | Enrollment | Missing Device Certificate (call4cloud.nl)
You could do so by running a simple script… nothing fancy, right? In that same story, I described that: For the people with some “funny” ideas, no, you can’t export the MS-Organization-Access certificate with the private key attached when you have a TPM!
The MS-Organization, AKA Entra ID Certificate, is protected by the TPM, and you cannot export the certificate. When the TPM protects the certificate, the private key stays within the TPM, and a corresponding public key will be used in the certificate. If this Ms-Org certificate is lost, you will end up in a world of pain.
The TPM will make sure that the private key will be protected against unauthorized access (AKA me exporting it and importing it on a different device that isn’t Azure Ad joined/Entra Joined)
TenantID and the Azure Device and Intune MDM Certificate (call4cloud.nl)
If we look at how this Entra Certificate is being stored by using the certutil -store my command, we will notice that it will use The Microsoft Platform Crypto Provider to do so.
If it uses the Microsoft Platform Crypto Provider it will protect the keys with the TPM, and with it, we will be unable to export it (even NOT when trying to export it as system)
Nice, right? This is how it is done! Of course, this blog is about the MDM enrollment, not the Entra ID certificate… so what about the MDM Intune Device Certificate?
2. The NOT so hardened MDM enrollment?
When we go back in time (before 2023) and look at how our device was enrolled into MDM in the past, we will notice that the Intune MDM device certificate created during the Autopilot enrollment is NOT protected by the TPM.
If we take a look at the MDM certificate with the certutil command we also used for the ms-organization certificate, we will notice that instead of the Microsoft Platform Crypto Provider, it mentions the Microsoft Software Key Storage Provider (KSP)
The TPM will NOT protect the certificate if it is delivered on our device and uses the KSP. If it’s not protected, the private key can be easily exported!
Wait, what? Yep. Back in the day, we could easily export the private key of the Intune MDM Device certificate because the TPM did NOT protect it. That’s weird, right? The MDM enrollment was NOT hardened like we would expect it to be.
The funny thing is that I wasn’t familiar with the IDA tool back in the day and how I could combine that information with my findings and logs. But now I can …
3. The more hardened MDM enrollment
So what happened? Let me tell you! After the blog I wrote, about how we could export the certificate with the private key a lot of things changed!
Intune | MDM-only | Enrollment | Missing Device Certificate (call4cloud.nl)
If we look at a Windows 10 device with a newer build > 2022-09, which I used when I exported the private key (to be precise, the 2023-02 update), we could spot a slightly different flow. During the MDM enrollment, we will notice that it doesn’t use the Microsoft Software Key Storage provider anymore but the same one the Entra ID uses.
As shown above, when we enroll our device with an up-to-date Windows build, the Intune Certificate and its private key will now be protected by the TPM. With the private key protected by the TPM, we also can’t export it anymore… Which is great!
With this adjustment, Microsoft started hardening the MDM enrollment! At first, I thought this MDM hardening process could be the exact reason we had many issues with the Intune certificate (missing private key), but that doesn’t seem to be the case. Let me tell you why
After logging in remotely with Powershell on many devices with our RMM tool, I concluded that if the Intune certificate was successfully renewed on a device, it was still using the old Microsoft Software Key Storage provider.
Looking at the installation date and the updates, it was installed before 2023 and had all updates installed.
So, even when it got the latest update installed and should have been capable of using the TPM for enrollment, it was still using the Microsoft Software Key Storage Provider and NOT taking advantage of the TPM to protect the keys to the kingdom.
I guess it’s pretty safe to assume that the MDM hardening only happens during the enrollment process and NOT during the MDM renewal process, or did I miss something? (I guess I did, as this is the second blog in the MDM recovery series)
So, how does MDM hardening work? I guess we need to examine a particular function I stumbled upon.
I noticed this function in the Omadmclient and mdmregistration.dll/dmenrollengine.dll while I was trying to find out how the MDM certificate could be automatically recovered using the Entra ID Device token when we configured the AllowRecoveryCSP.
4. Use TPM For Enrollment
When trying to figure out how that allowrecovery CSP was working, I decided to take another look at the Fiddler trace I had. After moving out all of the trash and exporting it to Excel, this is what it got me.
It starts the enrollment process. From there, it starts the function BeginCreateKeyinTPM and shows us the CryptoProviderUseResult, which mentions the Microsoft Platform Crypto Provider.
I opened the wonderful IDA tool and searched for those keywords (createkey) in the mdmregistration.dll. Within a couple of minutes of looking for CreateKey and working my way through the dmenrollengine.dll code, I noticed that during the MDM enrollment, while requesting the Intune certificate, it is trying to determine if the UseTPMForEnrollmentkey feature is enabled.
I decided also to record the corresponding video of this flow from above
If we look closer at the pseudocode behind that code, things will start making sense … at least for me…
For everyone unfamiliar with pseudocode, this part of the mdmregistration.dll checks if a specific feature, “UseTPMForEnrollmentKey,” is enabled.
If this feature is enabled, it attempts to use the “Microsoft Platform Crypto Provider” for key storage.
If the feature is not enabled or if specific conditions are met (e.g., the key is not ready in TPM), it will fall back on using the good old “Microsoft Software Key Storage Provider.”
This nice feature was added in the insider preview build 25115.1000
It’s obvious that it took a while before it ended up in the regular Windows builds, so at the start of 2023, the UseTpmforEnrollmentkey Functionality was added to the regular Windows code.
This is weird and funny at the same time because I didn’t notice it at all. This is great: The TPM is now protecting the private key when we are MDM enrolling the device. Good to know is that this “hardening” only seems to happen now when enrolling the device, not when renewing the Intune certificate, as it seems.
But the mdmregistration.dll isn’t the only one containing that functionality. This functionality is also being used in the OMADMClient. The weirdly named _lambda function calls upon this UseTPMForEnrollmentKey function.
This _lambda function is simply placed at the bottom of the RunSyncMLSession OMADMClient function.
I assume this function was added to check where the keys are stored so that the certificate and its keys could be successfully detected when syncing the device.
So now we have MDM Hardening V1, which will protect the private keys using the TPM function UseTPMForEnrollmentkey when the device is enrolled.
Check out part 2 of this MDM device attestation series here as it prepares for the second piece of the hardening puzzle!
https://call4cloud.nl/2024/07/all-the-intune-certificate-recovery-we-cannot-see
Conclusion
Microsoft hardened the MDM enrollment at the end of 2022 by ensuring the TPM protected the keys. This was the first step in securing your MDM enrollments like a boss!
The funny thing? No one noticed!!!. This is one to be very proud of, at least in my opinion! Watch out for the following parts in this series, as the UseTPMForEnrollmentkey was just the first part of the MDM / Windows hardening puzzle.