Attacking Primary Refresh Tokens using their MacOS implementation

While Microsoft Entra Primary Refresh Tokens remain mostly undocumented, on Windows there has been quite some research in how they work and how they can be attacked or protected. Despite several hiccups (read: vulnerabilities) in getting there, the implementation is now mostly secure if you have a Trusted Platform Module (TPM). On other platforms, the Primary Refresh Token is also used but its implementation is undocumented. We decided to investigate how Microsoft implemented Primary Refresh Tokens on MacOS, how they are protected and how hard (or easy) it is for attackers to steal them. During the investigation, we encountered more undocumented protocol features, leading to the discovery of deviceless Primary Refresh Tokens (PRTs). These deviceless PRTs, which as the name implies are only tied to a user and not a device. In some environments this might already be enough for an attacker to achieve their goal, since these PRTs could be obtained during phishing.

In this session, we will talk about the PRT internals, their protection on MacOS, and even on how we can combine this knowledge with regular PRTs for extra persistence in the environment.

We will describe how Primary Refresh Tokens (PRT) are implemented on Windows. This mostly follows the documentation on the Microsoft website. Due to the lack of documentation for macOS we started exploring the ways this is implemented.. During our research we found the implementation on macOS is very different than on Windows and even varies per Microsoft application.

This research led to uncover an undocumented API that allows to request a deviceless PRT via a newer version of the protocol. This API also allows a workflow that enables us to recant a device claim or generate a new PRT without one based on an SSO-flow.

With this new token we can then register our own device in AAD and thereby bypass most conditional access policies.
The talk will show this in a live or recorded demo and feature a release of the updated ROADtools, created and maintained by Dirk-Jan, that allows the use of these API calls. After demonstrating the attack we will also show some detection opportunities.