MSATicket to Paradise

Last Updated on February 16, 2023 by rudyooms

In this blog, I am going to show you how important MSA Tickets are. These tickets are of utmost importance when the device needs to perform authentication to 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

I will divide this blog into multiple parts

  1. Introduction
  2. GetMSATicket
  3. Not Autopilot Enrolled Device
  4. Conclusion

1. Introduction

In one of my previous blogs, I was showing you how the device was fetching its Autopilot profile.

An important part of that journey is probably the X-Device-Token. So let’s dive into the wonderful world of tokens and how I stumbled upon them.

2. GetMSATicket

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. This MSA ticket AKA the Security token will be received from the Security Token Service (STS) after successful authentication. 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 look for that same registry location. As shown below the Autopilot.dll (GetMsaTicket function) is mentioning 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 become 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 am wondering why this DeviceID changes each time the device gets reinstalled but I guess that’s stuff for another blog in the future.

It’s good to know that MSATickets can also be used to authenticate the device to other Microsoft endpoints. A good example would be when Autopilot kicks off and your device is going to 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 spend 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!

One thought on “MSATicket to Paradise

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  57  =  66