SquarePhish 2.0 - Turning QR Codes into Entra ID Primary Refresh Tokens

SquarePhish 2.0 - Turning QR Codes into Entra ID Primary Refresh Tokens

Speakers: Nevada (Senior Security Researcher, CrowdStrike); Kam (CrowdStrike)

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=YTMmiIxL9ig

Overview

In this insightful talk at Cloud Village, Nevada and Kam from CrowdStrike unveiled SquarePhish 2.0, an advanced phishing framework designed to weaponize QR codes for the acquisition of Primary Refresh Tokens (PRTs) from Microsoft Entra ID (formerly Azure Active Directory). Building upon their earlier work, SquarePhish 2.0 significantly enhances an attacker's ability to achieve persistent, single sign-on access across an organization's Microsoft ecosystem, bypassing traditional multi-factor authentication (MFA) and network controls. The presentation meticulously detailed the evolution of the tool, the underlying technical mechanisms, and crucial defensive strategies.

The core innovation of SquarePhish 2.0 lies in its sophisticated multi-stage phishing flow, which leverages Microsoft's legitimate device code flow for authentication, combined with the often-overlooked security implications of QR codes. By orchestrating a sequence of legitimate Microsoft interactions, the tool tricks users into granting attackers highly privileged tokens, specifically the PRT, which acts as a master key for persistent access. This approach presents a formidable challenge for defenders, as it circumvents many common detection mechanisms by keeping the user on trusted Microsoft domains for the critical authentication steps.

This talk is particularly significant for security professionals, red teamers, and incident responders because it highlights a real-world, actively exploited technique used by sophisticated threat actors like Storm-2372. Understanding SquarePhish 2.0's methodology is critical for assessing organizational risk, developing robust detection capabilities, and implementing effective preventative measures against advanced phishing campaigns targeting cloud identities. The speakers not only demonstrated the offensive capabilities but also provided actionable defensive recommendations, emphasizing the importance of monitoring specific Entra ID authentication protocols and client IDs.

Background

▶ Watch: Introduction to SquarePhish 2.0 and QR codes (0:00)

Traditional phishing techniques have evolved significantly in response to enhanced security measures. Early credential phishing, relying on fake login pages to capture usernames and passwords, became largely obsolete with the widespread adoption of Multi-Factor Authentication (MFA). Similarly, payload fishing, which aimed to execute malicious code (e.g., via macros in documents) to establish a C2 channel, faces increasing hurdles due to sophisticated Endpoint Detection and Response (EDR) solutions and stricter operating system protections. While spear phishing remains effective by targeting specific individuals with highly customized lures, the landscape continues to shift towards more advanced token-based attacks.

A more modern and prevalent technique involves invisible or reverse proxies like Evilginx or Modlishka. These tools sit between the user and the legitimate authentication service, transparently proxying traffic and capturing post-authentication tokens and session cookies in real-time. This method effectively bypasses MFA because the user authenticates directly with the legitimate service, with the proxy simply relaying the session. However, these techniques often involve users visiting a malicious URL, which can still be detected by advanced email security gateways or user awareness.

The talk then pivoted to the OAuth 2.0 framework, a critical component of modern authentication. Key elements of OAuth 2.0 include the client ID, which identifies the application requesting access; the client secret, a confidential credential for server-side applications (though not always required for public clients or first-party Microsoft applications using a public flow); the resource owner (the user); and crucially, access tokens and refresh tokens. Access tokens are short-lived and grant immediate access to resources, while refresh tokens are longer-lived and can be exchanged for new access tokens, providing persistent access without re-authentication.

The device code flow within OAuth 2.0 is designed for input-constrained devices, such as smart TVs, IoT devices, or command-line interface (CLI) applications, where entering a full username and password directly is cumbersome or impossible. The legitimate process involves the device displaying a short alphanumeric code and a URL (e.g., microsoft.com/devicelogin). The user then navigates to this URL on a separate, input-capable device (like a phone or computer), enters the code, and authenticates. Once authenticated, the device receives the tokens.

Prior research and tools have explored the abuse of device code flow for phishing. Dr. Azure Ntori seminar was among the first to publicly discuss device code phishing. Nevada and Kam's own earlier tool, FishingSuits, was an initial iteration focused on SMS-based delivery, grappling with the inherent 15-minute timeout of the device code. Other notable contributions include Jenko Wong's work at Defcon 29, Bobby Cook's popularization of the technique with Token Tactics and "The Art of the Device Code Fish," Black Hills InfoSec's "dynamic device code fishing," and Dennis Neep's "novel technique" (which Microsoft later patched). These prior efforts laid the groundwork for understanding the vulnerabilities and potential of device code flow in phishing campaigns.

The appeal of device code flow for attackers stems from several factors: users interact with legitimate Microsoft URLs for authentication, bypassing many web security warnings; the attack can bypass network controls by leveraging the user's personal device (phone); and most importantly, it yields post-authentication tokens, rendering MFA irrelevant once the tokens are acquired. Historically, challenges included the 15-minute timeout window, difficulties in obtaining consent for SMS-based phishing in engagements, and the lack of a direct path to Single Sign-On (SSO) tokens.

Key Findings

▶ Watch: Key OAuth 2.0 components: client ID, refresh tokens (2:55)

The talk's central contribution is SquarePhish 2.0, an advanced framework that overcomes the historical limitations of device code phishing and weaponizes QR codes to acquire Primary Refresh Tokens (PRTs). The key findings and advancements presented include:

1. Multi-Stage QR Code Phishing Flow: SquarePhish 2.0 introduces a sophisticated two-stage process. The initial QR code, embedded in an email, directs the user to a malicious SquarePhish server. However, this server acts only as a trigger. Upon scanning, the user is immediately redirected to a legitimate Microsoft device code login URL. Simultaneously, the SquarePhish server initiates the device code flow in the background and sends a second, legitimate-looking email to the user containing the actual device code and another legitimate Microsoft authentication URL. This design cleverly circumvents the 15-minute timeout limitation of the device code flow, as the user is already engaged in the process when the timed interaction begins. It also leverages legitimate Microsoft domains for the critical authentication steps, enhancing credibility and bypassing URL scanning defenses.

1. Acquisition of Primary Refresh Tokens (PRTs): A significant leap from SquarePhish 1.0, which only provided programmatic access via the Family of Client IDs (FoCI), SquarePhish 2.0 focuses on obtaining PRTs. PRTs are highly potent tokens that enable seamless single sign-on (SSO) across all Microsoft applications on a device, providing long-term persistence and broad access. This capability was made possible by research from Dirk-Jan Mollema, who demonstrated how to acquire a PRT using the Microsoft Authentication Broker Client ID. This specific client ID, though not part of the FoCI, allows for an exchange that yields a PRT. The speakers highlighted that this technique is not theoretical; the threat actor Storm-2372 has been observed utilizing it in the wild.

1. Automated Device Registration and PRT Creation: SquarePhish 2.0 automates the entire process of device registration and PRT creation. Once an attacker obtains the initial refresh token for the Authentication Broker Client ID, a companion tool called Gimme PRT (leveraging Dirk-Jan Mollema's ROTX library) takes over. Gimme PRT registers a fake device with Microsoft Entra ID, associates the acquired token with it, and then generates the PRT. This automation streamlines the post-exploitation phase for attackers, making PRT acquisition accessible and efficient.

1. Enhanced Evasion Techniques with QR Codes: The use of QR codes itself is a key finding. They can conceal malicious URLs, bypassing traditional email security warnings that scan embedded links. The talk also noted that scanning a QR code from a phone often only displays a partial URL, allowing attackers to use long, legitimate-looking subdomains to mask their malicious intent. The addition of an ASCII QR code option provides an even sneakier method, as it renders the QR code as HTML text, potentially evading some image-based QR code scanners.

1. User-Friendly GUI and Metrics: Kam led the development of a comprehensive graphical user interface (GUI) for SquarePhish 2.0, moving away from the command-line interface of its predecessor. This GUI simplifies campaign management, allowing red teamers to configure SMTP settings, server details, email templates, client IDs, and track campaign metrics such as emails sent, QR codes scanned, and tokens acquired. This enhancement significantly lowers the barrier to entry for using the tool.

1. Patching of the "Novel Technique": While not a "finding" in the sense of a new capability, the speakers acknowledged that Dennis Neep's "novel technique," which allowed for device code submission on behalf of the user (eliminating the need for the user to type the code), was unfortunately patched by Microsoft. This highlights the ongoing cat-and-mouse game between attackers and defenders and the dynamic nature of these vulnerabilities.

In summary, SquarePhish 2.0 represents a significant advancement in phishing tradecraft, combining the stealth of QR codes with the power of device code flow to achieve persistent, MFA-bypassing access via Primary Refresh Tokens, directly addressing the limitations of previous methods.

Technical Deep Dive

▶ Watch: Prior art and history of device code fishing (4:30)

SquarePhish 2.0 orchestrates a complex, multi-stage attack flow designed to appear legitimate to the end-user while covertly capturing highly valuable authentication tokens. The core technical components involve OAuth 2.0 device code flow, specific Microsoft client IDs, and the exploitation of token exchange mechanisms.

The attack initiates with an attacker sending an email containing a QR code. This QR code, critically, does not link directly to Microsoft's device code login page. Instead, it points to the attacker's SquarePhish server. This initial link serves merely as a trigger and does not have a 15-minute timeout, allowing the initial phishing email to sit in an inbox indefinitely. When the victim scans this QR code with their phone, they are directed to the SquarePhish server.

Upon receiving the scan, the SquarePhish server performs two immediate actions:

1. It redirects the victim's browser to Microsoft's legitimate device code login page (e.g., microsoft.com/devicelogin). This ensures that all subsequent user interaction for authentication occurs on a trusted Microsoft domain, significantly reducing suspicion and bypassing URL-based security warnings.
2. In the background, the SquarePhish server initiates the OAuth 2.0 device code flow with Microsoft Entra ID. This involves the server requesting a device code and a verification URI from Microsoft. Crucially, SquarePhish 2.0 defaults to using the Microsoft Authentication Broker Client ID. This specific client ID (e.g., d3590ed6-c45b-4238-8043-4245fc20d848), as discovered by Dirk-Jan Mollema, is instrumental because it allows for the eventual exchange of the acquired refresh token for a Primary Refresh Token (PRT).

After initiating the device code flow, the SquarePhish server sends a second email to the victim. This email contains the device code generated by Microsoft and another legitimate Microsoft authentication URL. This is where the 15-minute timeout window for the device code officially begins. However, the victim is already engaged in the process, having just scanned the QR code and been redirected to the Microsoft login page. The seamless transition from scanning to receiving the second email and then entering the code creates a highly convincing lure.

The victim then navigates to the Microsoft authentication URL (if not already there), enters the provided device code, and proceeds with authentication. If they are already logged into their Microsoft account, they might only need to confirm the sign-in. If not, they will enter their credentials and perform any required MFA. Because the authentication occurs directly with Microsoft, the MFA challenge is legitimate and successfully completed by the user.

Once the user successfully authenticates, Microsoft issues a refresh token (and an access token) to the SquarePhish server, which initiated the device code flow. This refresh token, specifically for the Authentication Broker Client ID, is the attacker's primary target.

Family of Client IDs (FoCI): While SquarePhish 2.0 primarily targets PRTs, it retains support for the Family of Client IDs (FoCI). FoCI refers to an undocumented Microsoft functionality that allows for the programmatic exchange of tokens between different first-party Microsoft applications (e.g., swapping a Teams token for a OneDrive token). This enables attackers to pivot from access to one application to another within the Microsoft ecosystem, broadening their post-exploitation capabilities. SquarePhish 1.0 heavily relied on this, and the Refresh tool (developed by Kam) was designed specifically for post-exploitation leveraging FoCI to dump data from SharePoint, OneDrive, and other services.

Primary Refresh Token (PRT) Acquisition with Gimme PRT: The acquisition of the refresh token for the Authentication Broker Client ID is a critical step towards obtaining a PRT. To convert this refresh token into a PRT, the speakers introduced Gimme PRT. This is a standalone Python tool that leverages Dirk-Jan Mollema's ROTX library. Gimme PRT automates the following steps:

1. It uses the acquired refresh token for the Authentication Broker Client ID.
2. It registers a fake device with Microsoft Entra ID on behalf of the victim.
3. It then uses this device registration to acquire a PRT, which is essentially a refresh token bound to a device, granting SSO access across all Microsoft applications for that user on that "device."
4. Optionally, it performs cleanup by de-registering the fake device.

The PRT provides attackers with highly persistent and pervasive access. With a PRT, an attacker can effectively impersonate the victim across all Microsoft services without re-authenticating, even bypassing future MFA prompts for new sessions. Another of Dirk-Jan Mollema's tools, browser_auth, can then be used with the acquired PRT to instantiate a browser session (e.g., using Selenium with Firefox) authenticated as the victim, providing full interactive GUI access to their Microsoft tenant.

SquarePhish 2.0 GUI: Kam rebuilt SquarePhish from the ground up in Go, introducing a user-friendly GUI. This GUI centralizes configuration for SMTP settings (for sending the second email), server settings (for hosting the initial QR code trigger), and email templates (subject, body, pretexts). It also provides crucial operational metrics, displaying the number of emails sent, QR codes scanned, and successful token captures. The GUI allows for specifying target recipients, choosing between inline embedded QR codes, ASCII QR codes (generated as HTML), or raw URL links for the initial lure.

ASCII QR Codes: A subtle but effective evasion technique is the ASCII QR code option. Instead of embedding a graphical image of a QR code, SquarePhish 2.0 can generate the QR code using HTML characters. This can potentially bypass some email security solutions that primarily scan image attachments or embedded image objects for malicious QR codes, allowing the lure to appear more benign.

The Patched "Novel Technique": The talk briefly touched upon Dennis Neep's "novel technique," which aimed to eliminate the need for the user to manually enter the device code. This technique involved the attacker submitting the device code on behalf of the user, requiring only a single redirect. However, Microsoft patched this vulnerability, forcing SquarePhish 2.0 to revert to the two-email, user-input device code flow.

In essence, SquarePhish 2.0 leverages a meticulous understanding of OAuth 2.0, Microsoft's authentication mechanisms, and the social engineering potential of QR codes to create a powerful and evasive phishing framework capable of delivering the ultimate prize: the Primary Refresh Token.

Demo / Proof of Concept

▶ Watch: Advantages of device code flow for fishing (5:30)

The demonstration provided a clear, step-by-step walkthrough of the SquarePhish 2.0 attack chain, showcasing the attacker's perspective via the GUI and the victim's experience from receiving the phishing email to full account compromise. The demo was pre-recorded and redacted to protect sensitive token information, ensuring a smooth and secure presentation.

The demo began with the attacker setting up the SquarePhish 2.0 GUI. On the right side of the screen, the SquarePhish application was visible, allowing for configuration of various parameters. The presenter highlighted the need for an SMTP server for the automated sending of the second email; a cheap service like Namecheap was mentioned as an example. The attacker navigated through the GUI's configuration settings, showing how to set up the HTML template for the second email, server-side settings, and critically, selecting the Microsoft Authentication Broker Client ID as the target client ID, along with the pretext (e.g., "authentication broker").

Next, the attacker moved to the "Send Email" page within the GUI. Here, they specified the recipient (the victim's email address), configured the initial phishing email body, and selected the option to embed a QR code. The GUI's preview function showed what the initial email, including the embedded QR code, would look like. The attacker then initiated the sending of this first email.

On the left side of the screen, representing the victim's inbox, the initial phishing email promptly appeared. The presenter emphasized that this email, containing the QR code that links to the SquarePhish server, could sit in the inbox indefinitely without timing out. Off-screen, the victim was simulated scanning this QR code with their phone. This action served as the "trigger" for the attack.

Immediately after the QR code scan and subsequent redirection to the legitimate Microsoft device code login page, a second email appeared in the victim's inbox. This email, sent by the SquarePhish server via the configured SMTP server, contained the actual device code and a link to microsoft.com/devicelogin. The victim then navigated to this legitimate Microsoft page (or was already redirected there), entered the provided device code, and proceeded with authentication. In the demo, the victim was already logged into their Microsoft account, so they simply confirmed the sign-in; however, the presenter clarified that if not logged in, the victim would enter their password and complete any MFA prompts at this stage.

Upon successful authentication by the victim, the SquarePhish GUI on the attacker's side refreshed, displaying a newly acquired token. This token was the refresh token for the Authentication Broker Client ID.

The next stage of the demo involved converting this refresh token into a Primary Refresh Token (PRT). The attacker opened a command-line interface and executed Gimme PRT, a Python script. The acquired refresh token was pasted into Gimme PRT as input. The script then proceeded to register a fake device with Microsoft Entra ID using the provided token, subsequently creating and outputting the PRT to a text file. The presenter ensured that the sensitive token data was redacted during this step.

Finally, to demonstrate the power of the PRT, the attacker used another tool from Dirk-Jan Mollema's suite, browser_auth. This tool leverages Selenium and Firefox to launch a web browser session, automatically authenticating as the victim using the newly acquired PRT. A Firefox window with a red banner appeared, signifying the attacker's session. When the attacker clicked "Sign in," they were automatically logged into the victim's Microsoft account, gaining full access to all Microsoft applications and services (e.g., Outlook, OneDrive, SharePoint) without needing to re-enter credentials or bypass any further MFA challenges. This vividly illustrated the persistent, single sign-on access afforded by the PRT.

The demo concluded by briefly mentioning the previously implemented (and now patched) Dennis Neep technique, which would have eliminated the need for the second email and manual device code entry, but confirmed that the current flow relies on the described two-email process. The entire demonstration effectively proved the efficacy of SquarePhish 2.0 in acquiring PRTs and achieving comprehensive account compromise.

Defensive Implications

▶ Watch: QR codes: hiding malicious URLs, bypassing warnings (6:40)

The sophisticated nature of SquarePhish 2.0 and its reliance on legitimate Microsoft infrastructure for critical authentication steps presents significant challenges for defenders. However, the talk outlined several actionable strategies to detect and prevent such attacks within Microsoft Entra ID environments.

The primary defensive recommendation revolves around monitoring device code authentication events, particularly those involving specific client IDs.

1. Monitor for Authentication Broker Client ID with Device Code Protocol:

The most direct detection strategy is to look for instances where the Microsoft Authentication Broker Client ID (d3590ed6-c45b-4238-8043-4245fc20d848) is used in conjunction with the device code authentication protocol. For most users in typical corporate environments, this combination should be highly unusual. The Authentication Broker Client ID is primarily associated with internal Microsoft services or specific device-enrollment scenarios. If a standard user is observed authenticating via device code flow using this client ID, it is a strong indicator of a potential SquarePhish attack or similar malicious activity. Defenders should implement detection rules in their Security Information and Event Management (SIEM) or Entra ID logs (e.g., Azure AD sign-in logs) to alert on such occurrences. A small subset of legitimate users (e.g., developers, IT administrators managing specific device types) might use this legitimately, so an allow list approach can be adopted, flagging all other users.

1. Monitor for Any Device Code Authentication:

Even more broadly, organizations should scrutinize any use of the device code authentication protocol within their environment. In many corporate settings, legitimate use cases for device code flow (like logging into smart TVs or IoT devices) are rare or non-existent for the general user base. Developers might use it for CLI tools, but this should be a small, identifiable group. Therefore, detecting any device code authentication outside of a known, approved, and allow-listed group of users or applications should trigger an investigation. Blocking device code flow entirely via Conditional Access Policies (CAPs) is a highly effective preventative measure if there are no legitimate use cases. The speakers mentioned that Microsoft might be implementing a dedicated switch to disable this flow, which would simplify prevention.

1. Conditional Access Policies (CAPs):

Conditional Access Policies (CAPs) in Microsoft Entra ID offer a powerful mechanism to prevent the abuse of device code flow. Organizations can configure CAPs to:

• Block device code flow entirely: If an organization determines that there are no legitimate use cases for device code authentication for any or most users, they can simply block this authentication flow. This is the most robust preventative measure.
• Restrict device code flow to trusted locations/IPs: If device code flow is required for specific use cases, CAPs can restrict its usage to trusted network locations, VPNs, or specific IP ranges.
• Require compliant devices: Mandating that only compliant devices (e.g., Intune-managed devices) can use device code flow adds another layer of security, making it harder for attackers to register fake devices.

1. Enhanced Email Security and User Awareness:

While SquarePhish is designed to bypass some email security, robust email security gateways are still crucial for detecting and quarantining initial phishing emails. Solutions that can analyze embedded QR codes, even ASCII-based ones, are beneficial. Furthermore, ongoing user awareness training is paramount. Users should be educated about the risks of scanning QR codes from unknown sources, the multi-stage nature of modern phishing attacks, and the importance of verifying URLs (even if they appear legitimate on a phone scan, a full URL display might reveal anomalies). Emphasize that legitimate Microsoft authentication should typically not involve scanning QR codes or entering device codes unless explicitly initiated by the user for a known, trusted application.

1. Device Registration Monitoring:

Since Gimme PRT registers a fake device, monitoring Entra ID for unusual or high volumes of device registrations, especially those not initiated through standard corporate device enrollment processes, can be an indicator of compromise. Correlating device registration events with suspicious authentication attempts could reveal malicious activity.

By implementing a combination of proactive monitoring, granular Conditional Access Policies, and continuous user education, organizations can significantly reduce their attack surface against sophisticated phishing techniques like SquarePhish 2.0.

Key Takeaways

• SquarePhish 2.0 leverages QR codes and Microsoft's legitimate device code flow to acquire highly privileged Primary Refresh Tokens (PRTs), enabling persistent, single sign-on access across Microsoft Entra ID.
• The attack employs a sophisticated two-stage flow: an initial QR code trigger leads to a legitimate Microsoft authentication, followed by a second email containing the device code, effectively bypassing the 15-minute timeout.
• PRTs are the ultimate prize, providing attackers with persistent, MFA-bypassing access across all Microsoft applications, as demonstrated by the use of the Microsoft Authentication Broker Client ID and the Gimme PRT tool.
• Defenders should prioritize monitoring Entra ID sign-in logs for device code authentication events, especially those involving the Authentication Broker Client ID, as these are strong indicators of compromise in most environments.
• Conditional Access Policies (CAPs) should be configured to restrict or entirely block device code flow if it's not a legitimate requirement for the majority of users, providing a robust preventative measure.
• Despite its sophistication, user awareness about the dangers of scanning unknown QR codes and vigilance against multi-stage phishing lures remain critical layers of defense.

About the Speaker(s)

Nevada is a Senior Security Researcher on the NG SIM team at CrowdStrike. He has a long-standing career in information security, specializing in offensive security tool development and research. His work, including the SquarePhish project, focuses on identifying and exploiting vulnerabilities in modern authentication mechanisms and cloud environments.

Kam is also a member of CrowdStrike, working alongside Nevada. He specializes in offensive tool development and purple team exercises. Kam was instrumental in the coding and development of SquarePhish 2.0, particularly the creation of its user-friendly graphical user interface (GUI), enhancing its usability for red team operations.