With the widespread adoption of hybrid environments and the Zero Trust model, Microsoft Entra ID (formerly Azure AD) has established itself as a central component of modern authentication. To provide a seamless experience for users whilst maintaining a high level of security, Microsoft relies on a key mechanism: the Primary Refresh Token (PRT).
Present on end-user devices or registered with Entra ID, the PRT plays a vital role in Single Sign-On (SSO) and access to the organisation’s cloud resources. Indeed, its importance in the authentication chain makes it an attractive target for attackers.
In this article, we will examine how the Primary Refresh Token works, its role within the Microsoft ecosystem, and the security implications associated with its use. We will also discuss the main known exploitation techniques and the measures that can be taken to mitigate the associated risks.
The Primary Refresh Token (PRT) is a central component of the Microsoft Entra ID authentication mechanism. Issued to a user on a trusted device, it enables a seamless Single Sign-On (SSO) experience for applications and services federated with Entra ID.
In practical terms, thanks to the PRT, a user logged in to their workstation can access services such as Outlook, Teams, SharePoint or the Azure portal without having to re-enter their credentials at every authentication.
In modern Microsoft environments, the PRT plays a role comparable to that of the Ticket Granting Ticket (TGT) in a traditional Active Directory environment: it serves as the starting point for obtaining the tokens required to access the organisation’s various resources.
This central position in the authentication chain also makes it a particularly attractive target for an attacker who has compromised a user’s workstation. Depending on the context, the ability to exploit or hijack a PRT can grant access to numerous resources protected by the Microsoft authentication ecosystem.
However, understanding the exploitation scenarios requires a thorough understanding of several internal mechanisms of the PRT. Before discussing exploitation techniques, we will therefore outline the various components involved in its acquisition, storage and use.
The following table sets out the key terms that will be used throughout this article.
| Acronym | Role |
| PRT (Primary Refresh Token) | An authentication token issued by Entra ID to a user on a trusted device. It enables the user to obtain new access tokens without the need for interactive re-authentication. |
| Session Key | A symmetric cryptographic key associated with the PRT. It is used to verify the legitimacy of its use and to protect certain exchanges with Entra ID. |
| WAM (Web Account Manager) | Windows authentication broker used by applications to request and obtain tokens from Entra ID. |
| CloudAP (Cloud Auth Provider) | A Windows authentication component responsible for managing secrets related to Entra ID and interacting with the TPM. |
| LSASS | A Windows system process hosting several authentication mechanisms and the associated security components, including CloudAP. |
| TPM (Trusted Platform Module) | A secure hardware component used to protect certain cryptographic keys and prevent them from being exported outside the machine. |
PRT acquisition is a low-level process orchestrated by the operating system as soon as the user logs on (Windows Logon).
lsass.exe process. Whilst the PRT is opaque, the Session Key is protected by the system DPAPI. In a secure scenario (Hybrid Join or Entra Joined), the private part of this key is cryptographically bound to the machine’s TPM.The PRT has a ‘rolling’ validity period of 14 days, which is continuously renewed whilst the device is in use. Its use is delegated to the Web Account Manager (WAM), the Windows token broker, in two distinct ways:
BrowserCore.exe binary or natively) to generate a temporary derivative called a PRT Cookie (or x-ms-RefreshTokenCredential). This cookie is a short-lived, signed JWT, injected into the HTTP headers to initialise the web session. It is often this cookie, which is easier to generate than to extract the master PRT, that is the primary target for attackers.For Active Directory (on-premises) experts, the PRT is the exact equivalent of the Kerberos TGT (Ticket Granting Ticket): a ‘master credential’ obtained upon login that enables the user to request subsequent service tickets.
However, a structural difference changes the game when it comes to lateral movement:
This combination is crucial: stealing a PRT (or misusing one on-site) not only allows the user’s identity to be impersonated, but also enables the machine’s compliance status (Device Claims: Managed, Compliant) to be ‘stolen’. This is the only means of circumventing Conditional Access policies, which would otherwise block the simple use of a stolen password from an unmanaged attacking machine.
Why has the PRT become the number one target for attackers on modern workstations? The answer can be summed up in one word: Pivot.
Historically, compromising a workstation allowed attackers to harvest hashes or Kerberos tickets to move laterally across the local network (on-premises). Today, with hybrid environments, initial access to a compromised machine provides, via the PRT, direct and transparent access to the user’s digital identity in the cloud.
In practical terms, this means that malware or a physical attacker can turn local access into global access to the company’s Microsoft tenant (Outlook, SharePoint, Azure Portal), all whilst bypassing MFA (since the PRT is already a validated form of strong authentication).
In order to assess the advantages and limitations of the various techniques presented in this section, we will consider two distinct operational contexts.
This technique involves extracting the PRT blob and the decrypted Session Key from LSASS memory and transferring them to the attacker’s machine. Once exfiltrated, these elements are used with a tool such as roadtx (from the ROADtools suite) to obtain access tokens from outside the system.
On the victim’s machine, the attacker can use mimikatz from a privileged environment to dump and parse the memory of the CloudAP module.
mimikatz.exe "privilege::debug" "sekurlsa::cloudap" "exit"
This retrieves the PRT and the associated Session Key (ProofOfPossessionKe.Keyvalue).
The Session Key value obtained is encrypted using DPAPI; it must be decrypted in order to actually obtain the desired PRT/Session Key pair.
mimikatz.exe "token::elevate" "Dpapi::cloudapkd /keyvalue:<KeyValue> /unprotect" "exit"
Now that these two items have been collected, there is no longer any need to interact with the victim. From any machine, roadtx can be used to obtain tokens for the desired Azure resources. In the following example, the PRT and the Session Key are used to obtain a valid Access Token for graph.microsoft.com.
roadtx gettokens --prt <PRT> --prt-sessionkey <Session Key> --resource https://graph.microsoft.com/
The token obtained can be used as it is to access the victim’s Microsoft account.
PRT could also be used to generate a “PRT cookie” that allows users to sign in to Microsoft applications via a browser.
Advantages and disadvantages of the method:
This method is excellent from an educational perspective; it enables a full understanding of how PRTs work and is the most straightforward from a methodological point of view: the attacker goes straight to the point and directly extracts the PRT and its Session Key for subsequent use.
The main advantage is that the stolen PRT is valid for 14 days and can be renewed using the Session Key to extend this period.
Note: Microsoft’s documentation states that when a PRT is renewed, a new Session Key is generated and transmitted after being encrypted with a “Transport Key” (which should prevent the PRT from being renewed without the latter). However, in practice, tools such as roadtx show that a simple renewal often retains the same Session Key (see image below). This allows an attacker in possession of the PRT and the Session Key to maintain access for a very long time without needing the Transport Key, provided Microsoft does not enforce a full cryptographic key rotation.
The first major drawback of this method is that it relies on being able to extract the Session Key. However, in the vast majority of cases, the target machine is equipped with a TPM, which prevents access to the Session Key. If an attacker attempts to use Mimikatz on a machine equipped with a TPM, the PRT will indeed be extracted, but the KeyValue field will not contain the required private key. It will contain a handle or an opaque reference.
The second drawback concerns the ‘stealth’ of the attack. Indeed, quite apart from the Mimikatz tool – whose signature is recognised by all EDRs – dumping the LSASS memory is extremely conspicuous and is therefore highly likely to be detected.
Finally, this method requires administrator access to the machine, which may be a stumbling block depending on the scenario.
This method is therefore only suitable in certain very specific cases. It would, for example, be suitable in the unlikely event of an audit on a machine without a TPM.
As mentioned earlier, the presence of a TPM renders the main ‘Session Key’ unusable, as it is hardware-sealed. To circumvent this limitation without abandoning the idea of exfiltrating the data, we need to look at the internal mechanics of token generation.
To avoid having to access the TPM chip (a slow operation) with every web request, the CloudAP process generates an intermediate key called the ‘Derived Key’. This key, calculated from the Session Key (TPM) and a random context, is stored in plain text in LSASS memory to quickly sign ‘PRT Cookie’ requests.
The attack therefore involves stealing this trio: PRT (Cookie) + Context + Derived Key.
Note: The attack described in this section is no longer possible following the introduction of KDFv2 in 2021.
On the victim machine, the attacker proceeds in the same way as before by dumping the CloudAP memory via Mimikatz. However, they no longer seek the main Session Key (which is protected by the TPM), but rather the fields specific to the derived context.
Returning to the example given at the end of the previous section, where the TPM prevented the desired key from being obtained, we can see that the context and the associated Derived Key remain fully accessible in plain text.
From the victim’s machine, the attacker also extracts an initial PRT cookie (see next section).
In practical terms, this PRT cookie takes the form of a standard JWT comprising three key elements: the PRT itself, a nonce that links the cookie to the current authentication attempt, and the context used to generate the Derived Key for signing the token.
Example of a PRT cookie:
Upon receipt, EntraID first checks that the nonce matches the challenge issued during initialisation. It then decrypts the PRT to extract the associated Session Key. By combining this with the context contained in the cookie, the service is then able to recalculate the Derived Key and validate the JWT’s signature, thereby ensuring that the issuer does indeed hold the legitimate PRT.
At this point, the three crucial elements are obtained:
Once these elements have been exfiltrated, the attacker can use roadrecon on their own machine to generate new PRT cookies on the fly.
Note: It is this step that can no longer be carried out since the introduction of KDFv2 (Key Derivation Function Version 2). This new derivation function generates the Derived Key based not only on a context but also on the entire JWT body, which prevents the exfiltration of a Derived Key for the purpose of reusing it later.
roadrecon auth --prt-cookie <old_prt_cookie> --prt-context <context> --derived-key <derived-key>>This command modifies the JWT payload of the first PRT cookie (which expires quickly) and re-signs it so that it ‘appears’ to be authentic.
This cookie can then be used in a browser (during Microsoft authentication) to access the victim’s Microsoft resources.
Once the cookie has been added, the attacker simply needs to refresh the login page to gain access to the victim’s account.
Advantages and disadvantages of the method:
This technique is significantly more robust than the previous one, as it is compatible with the presence of a TPM, which is standard on almost all modern computers. It allows the attacker to ‘bring back’ the victim’s identity to their own machine and use it independently.
As long as the main PRT is valid (up to 14 days) and the context has not been invalidated on the server side, the attacker can generate new cookies at will from their own machine.
This method is therefore more realistic than the previous one in the context of an audit where discretion is not a priority. However, it shares the same major flaws in terms of OPSEC. It still requires administrator privileges on the victim machine and involves the use of Mimikatz (or a manual memory dump) on the critical lsass.exe process.
This is an extremely ‘noisy’ operation: virtually all modern EDR solutions will block access to LSASS or detect the tool’s signature, making this method difficult to apply during a discreet Red Team operation when facing active monitoring.
The two previous methods were based on a ‘brute-force’ approach: extracting cryptographic secrets (keys and PRTs) from the memory of lsass.exe. Although intuitive and extremely powerful, they now come up against multiple security measures such as TPM, KDFv2 or even PPL (Protected Process Light) and EDR behavioural monitoring, which prevent access to this critical process.
To circumvent these protections, the modern approach involves adopting a ‘Living Off the Land’ (LotL) strategy. Instead of attempting to steal the key (which is prohibited), we simply ask the operating system to use it for us (which is legitimate).
The concept is simple: Windows has native APIs (COM) used by browsers (Edge, Chrome) to request SSO. The attacker can invoke these same APIs to request the generation of a valid cookie, without ever touching LSASS or knowing the encryption keys.
To illustrate this technique, we will use RoadToken, a PoC developed by Dirk-jan Mollema. It simulates the behaviour of the official Chrome extension ‘Windows Accounts’ by interacting directly with the Windows BrowserCore binary.
Unlike previous attacks, which require administrator privileges, this attack can be executed within the context of the current user, which significantly reduces the required attack surface.
The attacker must first obtain a nonce – a challenge issued by Microsoft – which must be embedded in the PRT cookie.
roadrecon auth --prt-init
Next, from the target machine (or via a C2 such as Cobalt Strike), the attacker runs the tool to request a PRT cookie in a “legitimate” manner.
Windows receives the request and asks CloudAP to sign the token. The system then returns the PRT cookie to the calling application – in this case, our malicious tool – in the correct manner.
.\ROADtoken.exe <nonce>
Once the cookie has been obtained, it can be used as described above.
Advantages and disadvantages of the method:
This is by far the most discreet method and the one with the fewest prerequisites.
However, it has a major drawback in terms of persistence. Unlike previous methods, where the elements needed to generate a PRT cookie or access tokens at will were stolen, here only a ready-to-use cookie or token is retrieved.
These have a limited lifespan (often one hour for an access token, or tied to the current session for a cookie). If the attacker wishes to maintain access, they must re-execute the attack on the victim machine regularly.
Note: Although the technique is stealthy (‘Living Off the Land’), the RoadToken tool itself is a well-known, unsigned executable. In a real-world environment, an EDR would almost certainly detect and block it. An advanced attacker would re-implement this tool directly within their implant (Beacon) or via an obfuscated PowerShell script.
Exploiting PRTs is not a ‘vulnerability’ in the traditional sense, but rather an abuse of functionality. Single Sign-On (SSO) is designed to be transparent and seamless for the user, which necessarily implies a certain attack surface.
Microsoft has implemented several safeguards over the years, making the misuse of PRTs increasingly complex. The main safeguards are:
lsass.exe, this mechanism prevents processes not signed by Microsoft (such as Mimikatz) from opening a handle on LSASS, even with Administrator rights. Although there are techniques to bypass this, it makes the attack much more noticeable and complex.But despite these safeguards, there is no miracle ‘patch’.
The crux of the problem lies in the legitimacy of the action: for SSO to work, the browser (or the CloudAP plug-in) must be able to obtain a token transparently. If a legitimate process can do so, a malicious process running in the same user context could, in theory, always find a way to do so as well.
Since it is impossible to prevent all attacks, modern defences focus on detecting behavioural anomalies. These anomalies can take many forms:
Whilst this article has focused on the use of PRTs within the Windows ecosystem (the traditional domain of enterprises), it is crucial to bear in mind that the concept of the ‘Primary Refresh Token’ is now operating system-agnostic.
In a modern ‘Zero Trust’ strategy, identity must be verified everywhere. This is why PRT mechanisms (or their functional equivalents) have been ported to macOS (via the Microsoft Enterprise SSO plug-in) and to Linux (via the Intune agent and authentication brokers).
This opens up a vast field of investigation for auditors and attackers, who must be able to adapt to the multitude of environments they may encounter depending on the companies targeted.
Sources :
Author: Maël BRZUSZEK – Pentester @Vaadata
