If you haven’t been paying attention closely enough, a new type of access control token, like a super browser token on steroids, is becoming hackers' theft target of choice.
It is known as a primary refresh token. In the Microsoft ecosystem, it’s the king of tokens.
Most access control tokens give users access to a single application, service, or site. If I use my browser to successfully login to an app/service/site, my browser will get a browser “cookie,” which is just a text file usually containing a randomly generated session ID, that gives that browser continued access to that app/service/site without having to re-logon again for a preset number of days or weeks.
My browser gets a separate access control token cookie for each app/service/site I successfully log on to. Most of us, if we go to our cookie directory, will see hundreds of cookies.
Hackers and their malware creations love to steal our browser cookies because they act as “bearer tokens.” Whoever has them is essentially seen as us to that app/service/site. Here is a great demo created by the late, great Kevin Mitnick (our former Chief Hacking Officer and owner) on a cookie being stolen and reused.
Hackers love cookie theft because it can work whether you are using a password, multi-factor authentication (MFA), biometrics, or some other super-duper authentication method. If the hacker gets your access control token cookie, it’s game over…for you and the involved app/site/service.
Hackers have been stealing browser cookies for decades, and just now some organizations, like Google, are trying to come up with ways to better protect them, such as device-bound cookies. Still, importantly, none of the existing cookie protections are all that great. Most can still be easily circumvented by hackers. Your cookies are still very valuable to any hacker who has them.
Most cybersecurity defenders have understood our cookie problem. What most defenders are not aware of is Microsoft’s new primary refresh tokens, which are sort of like an access control token cookie on steroids.
What is a Primary Refresh Token?
In short, it’s a Microsoft-only invention used in Microsoft ecosystems (AFAIK) that allows a user or device to access multiple apps/services/sites at once (i.e., Single-Sign-On) and usually for extended periods of time. They’ve been around since at least 2020, but are gaining in popularity.
Microsoft describes them this way:
“A Primary Refresh Token (PRT) is a key artifact of Microsoft Entra [formerly Microsoft Azure AD] authentication on Windows 10 or newer, Windows Server 2016 and later versions, iOS, and Android devices. It's a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices.
In this article, provide details on how a PRT is issued, used, and protected on Windows 10 or newer devices. We recommend using the latest versions of Windows 10, Windows 11 and Windows Server 2019+ to get the best SSO experience.”
When you logon to a Microsoft ecosystem, especially using a device officially “registered” with Microsoft Entra, a primary refresh token could/will be issued to your user for a particular device. It contains your device ID and an encrypted session symmetric key.
When you log in to the Microsoft ecosystem (e.g., Microsoft Entra, Microsoft O365, etc.), your Microsoft Windows 10/Microsoft Windows Server 2016 or later device will communicate with the Windows Cloud Authentication Provider. The Microsoft Entra plug-in will validate your credentials (e.g., password, MFA, Windows Hello, etc.) and return a primary refresh token and the included session key.
Windows will encrypt the session key with the Trusted Platform Module (TPM) chip encryption key (if available) and then store it locally using Windows Local Security Authority Subsystem Service (LSASS), where Microsoft stores and processes a lot of authentication info.
You can see if you and your device have a primary refresh token is present on a device running the following command in a command prompt:
dsregcmd /status and then ENTER.
Find the "SSO state" section and look for the "AzureAdPrt" value. It will be set to "YES" if you have a primary refresh token or "NO" if you don’t. The session key is the “bearer token.” There is currently no way to see “inside” a primary refresh token the way you can a browser cookie. You could be issued multiple primary refresh tokens, one for each user work account registered to the device.
An issued primary refresh token is good for two weeks (14 days) and continuously renewed every 4 hours as long as the related user is active on the involved device (as long as they don’t change their Microsoft Entra password). This means that users can continually use the apps/services/sites related to the primary refresh token in near perpetuity. The primary refresh token is cached locally in case the user doesn’t have an internet connection.
Note: Android-based primary refresh tokens have a maximum life of 90 days.
Once a user/device has a primary refresh token, it can be used to get one or more regular access control tokens for individual apps/sites/services without the user having to re-authenticate. It is the token to get other tokens. It’s similar to Kerberos’ Ticket-Granting Tickets (TGTs), if you are familiar with Kerberos with Microsoft Windows. Of course, all the involved apps/services/sites have to understand and use primary refresh tokens.
One other related point, primary refresh tokens are not subject to conditional access requirements, which Microsoft recommends that admins use to help better secure authentication sessions.
Here are some other links about primary refresh tokens if you want more info:
What Is a Primary Refresh Token?
Understanding Primary Refresh Tokens
Primary Refresh Token Attacks
You can understand why hackers want to get their hands on a user’s primary refresh token if they can. There are many ways for a hacker to get a victim’s primary refresh token. One way is for the hacker (or their malware program) to gain privileged access (i.e., Administrator, LocalSystem, etc.) to the victim’s Windows instance and then manually look for and extract or create new primary refresh tokens.
There are many tools that allow this, including the long-term beloved Mimikatz hacking tool. You can do an internet browser search on ‘mimikatz primary refresh token’ and it will come back with lots of articles on how to use Mimikatz to do this. Here is a great post on it including all the needed steps.
Attackers can use existing primary refresh tokens in unauthorized, “hidden” additional instances. With traditional browser access control cookie theft, the hacker could create a single unauthorized instance for a particular app/service/site for each compromised cookie. With a stolen primary refresh token, the hacker can access any app/service/site associated with the user and device (for apps/services/sites that are primary refresh token-aware).
What has become far more common is an attacker (often a nation-state group) using social engineering to trick the victim into approving a new device or user as part of a new primary refresh token (known as device code phishing). Attackers often use WhatsApp, Microsoft Teams, or Signal as part of their attack. Here is a good post on this type of attack.
Sometimes, the phishing attacks trick administrators into adding new, unauthorized devices to the user’s account. The scam either tricks the network administrators into thinking a legitimate user has lost or damaged the previously approved device or the victim themselves are tricked into accidentally approving a new device associated with their user account (because they are not aware of what is going on with the scam).
Here are some other examples of phishing attack stories involving primary refresh tokens attacks:
Phishing For Primary Refresh Tokens
Phishing For Primary Refresh Tokens in Microsoft Entra
Storm 2372 Conducts Device Code Phishing Campaign
Russian Threat Actors Targeting Microsoft
Device code phishing and primary refresh token attacks are far from new, but they are becoming more and more popular over time, starting with nation-state groups and now being used by other types of advanced attackers.
Defenses
The defense against primary refresh token attacks is essentially the same defenses that you would use to prevent local traditional browser cookie theft. Don’t allow potential victims to allow a hacker or malware to obtain access (especially elevated access) to a user’s device. If a hacker gains access to a user’s primary refresh token, they can abuse it into new instances or create new tokens altogether.
Use phishing-resistant authentication whenever you can. This is likely the only list of publicly available phishing-resistant authentication.
The best piece of advice I can give anyone to fight phishing of any type, including device code phishing, is this: If you receive an unexpected message, no matter where received (e.g., in-person, email, browser, social media, SMS, WhatsApp, Signal, Teams, etc.) and it is asking you to do something you've never done before...research any involved action requests outside of the information given in the message before performing. If more people followed this advice, there would be far less successful phishing. This applies to device code phishing.
We’ve always been worried about access control token cookie theft. Now, be aware of primary refresh token attacks. They are likely to play a bigger and bigger role over the years.
Here's what you'll get:
