This is the third blog in the Windows Enrollment Attestation / MDM Hardening series. In it, I will examine what happens when we combine the amazing AllowRecovery CSP and the MDM hardening and how they lead to the InitiateRecovery feature.
1. Introduction
In the first blog of the Windows Enrollment Attestation series, I focused on how the MDM Certificate’s private keys are now stored in the TPM during the MDM Enrollment (as they should!)
So, instead of using the Microsoft Software Key Storage provider, it now uses the Microsoft Crypto Provider (TPM) to store those important keys. It does so by using a functionality called UseTPMForEnrollmentKey.
Storing the private keys in the TPM is vital to making the MDM Enrollment secure. In the first blog post of this series, we learned that if we have issues with the Intune Certificate, the AllowRecovery Registry setting will restore the Intune MDM Certificate to life.
From there on, I had a crazy idea because when looking at the Recovery CSP Status documentation, I started thinking about something, and I was getting a crazy idea.
I needed to read it several times to see the big picture.
2. DM Recovery
Let’s take a closer look at the red-marked number 5
“Recovery Has Failed to start because the MDM keys are already protected by the TPM“
If you read that pretty clear sentence above, the recovery doesn’t start when it’s already protected… so one of the core functions of this recovery is making sure the existing MDM keys will protected by the TPM…
While reading that same sentence repeatedly, I wondered what would happen on an existing device with its keys stored in the Microsoft Software key storage provider and if we trigger the “Recovery” ourselves.
Luckily, we can by using the /recovery/initiaterecovery CSP !!!
This node will initiate a recovery action. Nice? Of course, we could configure this CSP in Intune, but that would be fun. I first tried to use the localmdm PowerShell command to trigger the recovery myself.
But it didn’t do anything? Let me tell you what happened and how I got it working
3. Local_Management
At first, I wondered why it got me the 202 status, but it became clear within a few minutes. When using the localmdm tool with this excellent initiate recovery command
Send-LocalMDMRequest -OmaUri ./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/Recovery/InitiateRecovery -Cmd Exec -Data “1”
we will get another “enrollment” on our device, the Local_Management one. So, if we fire off a localmdm request it will be targeted at that specific local enrollment.
After running the InitiateRecovery command and opening that specific local_management enrollment, we will notice that some new DWORD values popped up!
The recovery was initiated at the local_management enrollment, creating the “WasRecoveryInitiatedByServer” key and some more RecoveryStatus registry values.
Mmm, okay, fair… I can’t use the localmdm tool to trigger this, which is too bad as deploying it in Intune and spotting it in the SyncML tool and my traces will take longer.
Luckily, I am always up for messing around with my enrollments and VMs. After watching Procmon, I noticed that it was trying to find the proper enrollment by looking at one particular registry value: EnrollmentType!
This enrollmenttype is set to 14. When comparing that enrollmenttype with the actual Intune Enrollment we will spot a small difference
This enrollment type defines the enrollment type… uhh, who would have expected that, Sherlock? 🙂 What if I am going to do a stupid thing? And let me tell you, I am good at doing silly things! I changed the Enrollmenttype from 6 to 14 in the Intune enrollment node to see what would happen.
After changing this registry value to 14 for a few seconds, I fired off the localmdmrequest again. I also added a PowerShell command to change this registry key back to 6 after firing off the CSP otherwise, my enrollment would end up in a very, very bad state.
Of course, before kicking off the PowerShell command, I also ensured the IsRecoveryAllowed was set to zero in my Intune enrollment.
As shown above, the recovery was now initiated at my Intune enrollment! That’s exactly what I wanted! Now I knew how to trigger it manually, I started over and reinstalled my physical device.
4. InitiateRecovery
I reinstalled my device with a pre-2023 Windows build that still had the Intune MDM device certificate stored in the “wrong” aka not really secure storage provider.
From there on, I initiated the recovery by running the PowerShell localmdm command. This is what happened!!!!
If you don’t want to watch the YouTube video, here is a simple overview of what happened!
Whoop, Whoop, and can we get another whoop!!
Oh my… so if we initiate a recovery, the Intune MDM Device certificate will be “renewed” and while doing so its private keys will get stored in the TPM!(Microsoft Platform Crypto Provider)
Damn… So, let’s do a quick resume… last year, the first step in the MDM hardening process started. All new devices got the MDM enrollment hardened (usetpmforenrollmentkey). The second step in this MDM hardening process shows us that Microsoft is moving forward and giving us the possibility to harden existing MDM enrollments by using the recovery CSP. Let me drop this here:
I am so amazed!!!I am flabbergasted all the way!
The usetpmforenrollment function that is used to harden the MDM enrollment is also connected with the DM Certificate Recovery …
I guess the Circle is almost round. I was curious about what would happen if I initiated the recovery in a virtual machine!!! Why? Because that led me to the hardening treasure!
5. DmGetTargetAik
The first attempt to Initiate the recovery of the MDM Certificate was made on a physical device with a real TPM. If you try to perform the recovery on a virtual machine with a virtual TPM, it won’t work. Let me show you why!
If we try to remotely initiate the recovery from Intune by configuring a CSP, we will notice that it will fail with a status 0x82ae0004 (0x80090016)
Besides this error, the RecoveryStatus you will notice that it will also mention Status 6 and the recovery error code: (0x80090016) 2148073494
6 – Recovery has failed to start because the TPM isn’t ready for attestation. In the event logs, we will notice the corresponding output. ReadyForAttestation:False
ReadyForAttestation…ow my… I am getting flashbacks to my Ready For Attestation blog
Ready For Attestation False and the 0x81039001 TPM time-out (call4cloud.nl)
When we try to initiate recovery, the device also needs to perform Attestation. To perform an attestation, a valid AIK Certificate is needed.
While manually triggering the recovery, I also watched Procmon go and noticed it looped through the Microsoft Crypto folder in the programdata to find the AIK certificate.
If it doesn’t find a valid AIK certificate for key attestation, the recovery will fail.
Of course, even when Attestation fails because it couldn’t find the AIK certificate, the certificate will still rely on the Microsoft Platform Crypto Provider to store the keys.
When taking a look at which DLL and function is being used to get the AIK, we will notice that the DMcmnutils.dll with the function DmGetTargetAik is indeed trying to find the AIK
To go a bit deeper into trying to understand what this module was trying to do, I opened the pseucode in the IDA tool.
A small summary of what is happening in the above code.
1. Attempts to open a storage provider named “Microsoft Platform Crypto Provider“
2. Opens a cryptographic key named “Windows AIK” within the provider.
3. Retrieves a property called “SmartCardKeyCertificate” associated with the cryptographic key.
Okay, so the device must have the AIK Certificate to perform attestation when initiating the certificate recovery.
Conclusion
MDM Hardening is a big big thing! Microsoft started working on this a couple of years ago and implemented the first phase (UseTpmForEnrollmentkey) at the end of 2022 / the beginning of 2023.
From there, MS implemented the Recovery CSP to ensure the Intune Certificate’s private key will be moved to the TPM. With the Intune Certificate and its private key in the TPM, we can attest the MDM certificate on a physical device. Please stick with me; I will explain this in the last blog!
Check out the last part of the MDM hardening series here:
IsTPMAttested | 80180032 | Windows Enrollment Attestation (call4cloud.nl)