In this blog, I will show you how important MSA Tickets are. These tickets are of utmost importance when the device needs to authenticate a Microsoft Endpoint. I will show you how I stumbled upon that registry location in which the X-device token is stored to fetch the Autopilot Profile
1. Introduction
In one of my previous blogs, I showed you how the device fetched its Autopilot profile.
https://call4cloud.nl/2022/12/the-token-games-the-ballad-of-autopilot-and-profiles
An essential part of that journey is probably the X-Device-Token. So, let’s dive into the beautiful world of tokens and how I stumbled upon them.
2. Get MSA Ticket
As I mentioned in my previous blog, to be able to retrieve the Autopilot profile, the device needs to send the X-Device-Token to the Autopilot service: ztd.dds.microsoft.com
This X-Device token is nothing more than a good old MSA Ticket. After successful authentication, this MSA ticket, AKA the Security token, will be received from the Security Token Service (STS). This token will be used to authenticate itself to other endpoints, such as DDS.Microsoft.com.
At the moment the device receives the Security Token, it will be temporarily stored/cached in the registry: Software\Microsoft\IdentityCRL\Immersive\Token AKA the IdentityStorage. We could notice the same flow when looking at the Wlidsvc.dll and the SaveIdentity function.
When Autopilot kicks off, it seems to be looking for that same registry location. As shown below the Autopilot.dll (GetMsadeviceTicket function) mentions the same IdentityCRL
As shown below, when looking at Procmon, when the device reaches out to login.live.nl to get its security token, we will also notice this registry key being called upon. (RegOpen and RegSet)
Taking a closer look at this registry key, we will notice that this registry key not only contains the Security Token that is used for fetching the Autopilot profile but also some other Security tokens. For each HostingApp (Service) it holds the corresponding Token
As shown above, this {8A6E5826-EA01-989D-989D-158EE04D1518} HostingApp, is referring to the dds.microsoft.com (also ztd.dds.microsoft.com) Endpoint/Service. We can also spot the same GUID when looking at the IdentityCRL registry key I mentioned
Please note: This DeviceTicket is, of course, protected by the Data Protection API (DPAPI), so retrieving the SYSTEM token as defaultuser0 could be difficult.
Just asking.. but did you pay attention in my previous blog when I was showing you the Fiddler Trace I got when the device reached out to login.live.com/deviceaddcredential.srf? It showed us the HWDeviceID
When looking at the IdentityCRL registry key with the tokens in it, the DeviceId really looks familiar. It is exactly the same ID you will find in the Token registry key!
When reinstalling the same device with the same build, the DeviceId above also changes. I wonder why this DeviceID changes each time the device is reinstalled, but I guess that’s stuff for another blog.
It’s good to know that MSATickets (DeviceTicket) can also be used to authenticate the device to other Microsoft endpoints. A good example would be when Autopilot kicks off, and your device will be Azure Ad Joined. In the request, we will notice that instead of the X-Device-Token, the MSA-DDID is mentioned.
Guess what happens when we convert this specific MSA-DDID from Base64
As shown above, that looks like the same kind of token we got when the device was reaching out to the ztd.dds.microsoft.com endpoint. When looking at the registry and converting it to something more readable, we will notice the registration.windows.net endpoint
Everyone gets an MSA ticket, you get one, you get one, and everyone gets one!
3. Not Autopilot Enrolled Device
With all this information about MSA Tickets and the DeviceID, I wondered if it was possible if I could find out if the device was indeed converted to an Autopilot device (Not enrolled with Autopilot!!) without looking at the Autopilot devices list in Intune or by resetting the device.
Before enrolling the device I configured an Autopilot profile and made sure the “convert all targeted devices to Autopilot” option was set to Yes.
Convert All targeted Devices to Autopilot | Intune Flow (call4cloud.nl)
After setting up the prereqs, I enrolled a new virtual machine without uploading the hash to the Autopilot service and enrolled it to Azure Ad and Intune.
To determine if the device was indeed converted to an Autopilot device, I need to get myself some MSA Tickets!!!! As shown below after executing the PowerShell script in the system session it showed me the ztd.dds.Microsoft token
If you want to know how I exactly got it, I am describing the Powershell script in a separate blog
Fetch the Autopilot Profile with PowerShell and a token (call4cloud.nl)
With this token, I could call upon the Autopilot service (HostingApp) and fetch back a response with the headers in. Guess what those headers contain! The Autopilot Profile
As shown above, with the MSA ticket, we could determine if a device that wasn’t converted to an Autopilot device and would be enrolled with Autopilot the next wipe!
Conclusion
For the last couple of months, I have spent a lot of time trying to find out how Autopilot exactly works and how the good old Windows XP activation process is used to fetch the Autopilot Profile. Besides the WAP, the MSA ticket is quite Important. I hope this blog showed you why!
Great work! – reverse engineering MS products that we have to work with. More tool for debuggin!