Stephan van Rooij

Software architect with a passion for home automation.

Hacking Primary refresh tokens, oops created a virus

H

Windows has some cleaver ways to handle SSO in combination with Azure AD. They use this so called Primary Refresh Token. These highly sensitive key materials, are usually stored in the systems TPM (trusted platform module), a hardware device that can protect keys. And are “unlocked” when the user logs in.

A post, by Lee Christensen and the accompanying RequestAADRefreshToken source, inspired me to check out what he had found.

Getting the token

I recommend you reading this post, where Lee explained the research to get these token in great detail. To summarize, here is what happening:

  1. Chrome extension talks to BrowserCore.exe executable
  2. BrowserCore calls MicrosoftAccountTokenProvider.dll COM object
  3. The MicrosoftAccountTokenProvider uses data from the TPM to call the Azure AD endpoint
  4. Chrome extension set the x-ms-RefreshTokenCredential cookie for the login.microsoftonline.com domain to the value got from the Token Provider.

If you then reload the page (at the login domain) if sees the cookie and won’t ask you for your account details.

Without actual details on how this works, Microsoft described the process on their documentation page.

Check if computer is allowed to get SSO tokens

Start a command prompt and run dsregcmd.exe /status, check for the SSO section, it should display AzureAdPrt : YES

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : YES
      AzureAdPrtUpdateTime : 2022-10-18 07:44:27.000 UTC
      AzureAdPrtExpiryTime : 2022-11-01 07:44:26.000 UTC
       AzureAdPrtAuthority : https://login.microsoftonline.com/***
             EnterprisePrt : NO
    EnterprisePrtAuthority :
                 OnPremTgt : NO
                  CloudTgt : YES
         KerbTopLevelNames : .windows.net,.windows.net:1433,.windows.net:3342,.azure.net,.azure.net:1433,.azure.net:3342

Get a token for our own app

I forked Lee’ code. To try if I got it to work. I converted the code to NET6.0 because I did not have the original target framework installed.

And then this happened:

Virus warning

When clicking the details, it showed me the following error:

Virus warning

I had created a virus with the description VirTool:MSIL/Radkt.B!MTB. I guess Microsoft Defender doesn’t like unsigned applications requesting tokens from the MicrosoftAccountTokenProvider.dll. Google could not enlighten me either.

Conclusion

It is possible to get these tokens by calling a common dll on your windows device, if it’s enrolled for SSO and if you disable Microsoft Defender. These tokens can also be put in an incognito browser window and work without issue.

I’ve not tested what happens if you extract such a token and use it on a different machine, possibly from a different IP.

Thinks that need further investigation:

  • Are PRT tokens revoked if a new PRT is requested?
  • What is the lifetime of the PRT?
  • Will it work from a different IP-address?
  • Why does Microsoft Defender thinks my program is a virus? And how can we circumvent this, signing the app, white listing it?

Externalize user accounts: OpenID Connect

E

Externalizing user accounts, what is he thinking? The previous post should give you a clear view what this means and why you should consider it. This post will go a into details of “delegating login” to a separate application.

Externalize user accounts: An introduction

E

Externalizing user accounts, what is he thinking? In this post I’ll explain why every company should consider externalizing their user account management from their applications.

Like what you're seeing? Consider Sharing on Twitter or Sponsoring me