Braving the Storm-2372: The Tempest Decoded

Braving the Storm-2372: The Tempest Decoded

Speakers: Jenko Hwong

Conference: Cloud Village

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

Overview

Jenko Hwong's Cloud Village talk, "Braving the Storm-2372: The Tempest Decoded," provides a critical and in-depth analysis of the Microsoft-attributed Storm-2372 attack campaign. While Microsoft's February 2023 update initially highlighted device code phishing, Hwong argues that the true severity and underlying mechanisms of the attack, particularly the Primary Refresh Token (PRT) hijack and device registration abuse, were significantly downplayed and largely overlooked by the wider security community. This oversight is particularly concerning given that the core techniques had been publicly documented by researcher Dirk-Jan since late 2021.

The presentation aims to shed light on the sophisticated attack chain that impacts virtually "every corporate Microsoft user" who leverages domain-joined devices and Single Sign-On (SSO) within Azure environments. Hwong dissects the attacker's methodology, from initial access via impersonating first-party Microsoft applications to establishing persistent access through the creation of new user-bound Windows Hello keys. The talk serves as an urgent call to action for Azure red and blue teams, emphasizing the need for a deeper understanding of these techniques beyond superficial phishing awareness, and advocating for more effective defensive strategies against this pervasive threat.

Hwong's analysis underscores a broader issue within the security community: a slow reaction time to publicly available research and a tendency for vendors to generalize or minimize critical vulnerabilities. By detailing the technical intricacies and practical defensive implications, the talk contributes crucial "two cents" to the ongoing discussion, pushing for better detection, prevention, and incident response capabilities against advanced token-based attacks in Azure.

Background

▶ Watch: Introduction to Storm-2372 and its overlooked significance (0:00)

The genesis of the Storm-2372 campaign, as publicly disclosed by Microsoft in February 2023, initially focused on device code phishing. While this specific phishing vector gained high-profile attention, Hwong highlights that the technique itself has been known within the security community for at least four and a half years, with public discussions dating back to October 2020 by "notori cinema." The real heart of the Storm-2372 attack, however, lay in its exploitation of Primary Refresh Token (PRT) hijacks and the abuse of device registration services – techniques that had been thoroughly researched and publicized by Dirk-Jan for approximately 18 months prior to Microsoft's alert. Dirk-Jan, whom Hwong refers to as the "godfather of PRT hijacks, device registration, and SSO abuse," had not only detailed the Tactics, Techniques, and Procedures (TTPs) but also released a toolset named Rot that could execute these attacks.

The device registration flow is fundamental to modern enterprise Azure environments. It allows users to join their devices to a domain, enabling seamless Single Sign-On (SSO) to Azure and Office 365 applications. During this legitimate process, a PRT – an "uber token" – is issued to the device. This PRT is crucial for minting subsequent refresh and OAuth tokens, facilitating a streamlined user experience where logging into a laptop grants access to various cloud services without repeated authentication. The PRT is tied to a hidden device certificate and can be linked to a user's PIN for enhanced convenience.

The underlying vulnerability that Storm-2372 exploited, and that Dirk-Jan's research had previously exposed, stems from Microsoft's implementation of OAuth for SSO. This implementation, while designed for user convenience and lateral movement across applications, inadvertently creates a significant attack surface. Attackers can impersonate first-party Microsoft applications, such as Outlook or the Microsoft authentication broker, without needing to create their own traceable applications. This impersonation is potent because of the Family of Client IDs (FOSAI), a concept detailed by SecureWorks research several years prior. FOSAI allows an attacker, once they have a token blessed for one Microsoft application, to pivot and gain access to over 30 other applications within the Microsoft ecosystem, effectively facilitating lateral movement across an organization's cloud infrastructure. The core problem, as Hwong emphasizes, is that Microsoft's SSO approach allows permissions and scopes to be changed on tokens without the user re-approving, a deviation from standard OAuth specifications and a critical enabler for this attack.

Key Findings

▶ Watch: Acknowledging Dirk John's foundational research on PRT hijacks (2:40)

Jenko Hwong's presentation reveals several critical findings regarding the Storm-2372 campaign and the broader landscape of Azure security:

1. Under-Reported Severity and Pre-Existing Research: The most significant finding is that the core techniques behind Storm-2372, specifically PRT hijack and device registration abuse, were not novel. Researcher Dirk-Jan had publicly detailed these TTPs and released the Rot toolset 18 months prior to Microsoft's high-profile February 2023 alert. Microsoft's initial communication, by focusing primarily on device code phishing, significantly downplayed the true severity and advanced capabilities of the attack, which leveraged the PRT to gain deep and persistent access.

1. Multi-Stage Attack Chain: The attack is not a single event but a sophisticated, multi-stage process with distinct objectives:

• Initial Access (Device Code Flow): Attackers initiate device code phishing, often impersonating legitimate Microsoft applications like Outlook or the authentication broker, to trick users into authenticating. This stage does not require endpoint compromise and yields a refresh token, allowing access to numerous SSO apps.
• Privilege Escalation (PRT Hijack): Using the obtained token and tools like Rot, attackers can register a fake device within the victim's tenant and easily hijack the Primary Refresh Token (PRT), which is an "uber token" capable of minting new refresh and OAuth tokens.
• Persistence (Windows Hello Key Creation): Within a critical 15-minute window after a user performs MFA during the phishing flow, the attacker can create a new, user-bound Windows Hello key. This key provides robust persistence, allowing the attacker to generate new PRTs even if the initially compromised device key is revoked.

1. Fundamental OAuth Weakness in Microsoft's Implementation: Hwong highlights a crucial deviation from standard OAuth specifications: Microsoft's SSO implementation allows attackers to pivot between different application scopes and permissions without requiring the user to re-approve these changes. This "one big umbrella" approach for Microsoft apps facilitates lateral movement and makes it easier for attackers to escalate privileges from a seemingly innocuous initial authorization.

1. Ineffective and Noisy Defensive Guidance: Microsoft's defensive recommendations often fall short. Generic advice like "train your people" or "patch Windows" is deemed unhelpful, as MFA is bypassed in this attack. While some Conditional Access Policies (CAPs) are suggested, Hwong argues many are difficult to implement without breaking legitimate workflows (e.g., blocking device code flow for Azure CLI or device registration itself). Furthermore, many "hunting queries" provided are based on weak indicators like user click delays, leading to high false positives rather than reliable detection.

1. Improving, But Still Challenging, Log Visibility: Azure logs are described as a "crap show" due to their inconsistency and noise. However, Hwong points to a significant improvement: the introduction of the Unique Token Identifier (UTI) field in sign-in, Graph, and some app logs. This new field offers unprecedented granularity at the access token level, potentially allowing defenders to track specific token activity across different IPs or services, although it's not universally present.

Technical Deep Dive

▶ Watch: How the attack works remotely without endpoint compromise, including persistence (4:35)

The Storm-2372 attack chain leverages several sophisticated techniques, primarily centered around OAuth token manipulation and device registration abuse, orchestrated through tools like Dirk-Jan's Rot.

The attack begins with initial access through device code phishing. The attacker, without needing any prior endpoint compromise, crafts a phishing page that prompts the victim to enter a device code. This code is generated by the attacker's script (e.g., a simple shell script using curl commands). Crucially, the attacker impersonates a legitimate Microsoft first-party application, such as the Microsoft authentication broker or Outlook, leveraging its client ID. This impersonation is highly effective because users see a familiar Microsoft URL for authentication, and the subsequent consent prompt is vague, only showing the app's name without detailed permissioning. The victim then authenticates, potentially using Multi-Factor Authentication (MFA), directly with Microsoft's official login portal. Upon successful authentication, the attacker receives an OAuth token blessed by the user, with scopes relevant to the attack, such as those related to enrollment services. This token, due to Microsoft's Family of Client IDs (FOSAI) implementation, can often be exchanged for tokens accessing over 30 other Microsoft applications, granting significant lateral movement capabilities.

Once the attacker possesses a valid OAuth token, the privilege escalation phase begins, primarily through PRT hijack and device registration abuse. Using Dirk-Jan's Rot toolset, the attacker can register a fake device within the victim's Azure tenant. This fake device can be configured with arbitrary attributes, such as a Windows 11 operating system, even if the attacker is running a different OS (e.g., macOS as demonstrated by Hwong). During this registration process, a Primary Refresh Token (PRT) is issued to the attacker's fake device. The PRT is an "uber token" that can be used to mint new refresh tokens and access tokens for various Microsoft services, effectively bypassing subsequent authentication prompts for the attacker. Hwong demonstrates the power of this by showing how the PRT can be used to pivot directly into a live browser session, making it easier to navigate cloud resources like OneDrive.

The final stage is establishing persistence. A particularly insidious aspect of this attack, also detailed in Dirk-Jan's research, is the ability to create a new, user-bound Windows Hello key. This can be achieved if the attacker operates within a specific 15-minute window after the user has performed MFA during the initial phishing attempt. Unlike a device-bound key, a user-bound Windows Hello key provides a robust persistence mechanism. Even if the original fake device is detected and removed, or its device key revoked, the attacker can use the user-bound Windows Hello key to generate an entirely new PRT and regain access, further demonstrating the deep level of compromise.

From a defensive perspective, log visibility presents significant challenges. Hwong describes Azure's sign-in and activity logs as a "crap show" due to their inconsistent structure and excessive noise. While fields like Session ID, transfer method, and authentication method (showing device flow) are important, the Session ID often aggregates unrelated backend activities, making it difficult to isolate specific user actions. A recent improvement, however, is the introduction of the Unique Token Identifier (UTI) in sign-in, Graph, and some app logs. This field offers unprecedented granularity by tying activity directly to a specific access token, potentially enabling defenders to track token movement across different IP addresses – a key indicator of compromise.

Conditional Access Policies (CAPs) are a primary defensive control, but their effective implementation is complex. While blocking device code flow outright might seem logical, it can disrupt legitimate services like the device registration service itself (which the attack abuses) or the Azure CLI. Hwong suggests restricting device code flow or device registration to trusted IP addresses or locations, but acknowledges the practical difficulties for large, globally distributed organizations. Furthermore, Continuous Access Evaluation (CAE), designed to revoke access tokens quickly upon compromise, has limited support, requiring specific Microsoft apps to participate by generating and receiving signals, thus not offering comprehensive protection.

Demo / Proof of Concept

▶ Watch: Summarizing the three distinct stages of the Storm-2372 attack (6:00)

Jenko Hwong provided a clear, step-by-step demonstration of the Storm-2372 attack chain, starting with the initial device code phishing and culminating in PRT hijack and persistence.

The demonstration began with the attacker initiating a device code flow using a simple shell script, which internally leveraged curl commands. Hwong showcased his HTML "skills" by presenting a basic, yet effective, phishing page designed to mimic a legitimate Microsoft login. This page instructed the victim to enter a generated user code, often under the pretense of a security incident or verification ("Security incidents are the flavor of the month. Oh my gosh. Log in. Type in this code. Make sure it's you."). The critical point here is that the phishing page directs the user to an official Microsoft login URL (device login), ensuring that the victim authenticates directly with Microsoft, including providing their legitimate Multi-Factor Authentication (MFA) code.

After the victim successfully authenticated, the demonstration highlighted the minimal user experience: a confirmation screen with the app's name (which users rarely understand) and a confirmation message. However, behind the scenes, the attacker's script received the crucial payload – an OAuth token authorized by the victim, with scopes allowing interaction with enrollment services.

The next phase of the demo utilized Dirk-Jan's Rot toolset. Hwong, running the script on his Mac, used Rot to register a fake device within the victim's Azure tenant. He opted for Rot's default setting, registering it as a Windows 11 device, and Microsoft happily issued a device ID. With this fake device registered, the attacker successfully obtained a Primary Refresh Token (PRT). Hwong vividly demonstrated the power of this PRT by using it to "flip into browser sessions," showing how the attacker could instantly access cloud resources like OneDrive directly in a web browser, bypassing further authentication. This highlights the seamless pivot from API tokens to browser-based access.

The final part of the demonstration focused on persistence. Hwong showed how, by operating within a 15-minute window after the victim's MFA, the attacker could generate an additional, user-bound Windows Hello key. This key provides a powerful persistence mechanism, allowing the attacker to generate a full new PRT even if the initial device key is revoked. To prove this, Hwong popped back into a live browser session using the newly created Windows Hello key.

From a defensive standpoint, the demo included screenshots from Entra (Azure AD), showcasing how the attacker's registered device appeared: labeled as "attacker host," running a "Windows OS" (an older version due to Rot's defaults), and appearing as a legitimate registered device. Hwong also pointed out where the persistent Windows Hello key would appear in the Entra portal – under the user's "authentication methods." He noted that while Microsoft has improved defaults for new tenants (potentially disabling the ability for users to add authentication methods), many existing organizations likely still have these options enabled, making them vulnerable. The demo effectively illustrated the attacker's perspective and the subtle indicators defenders should look for.

Defensive Implications

▶ Watch: Introduction to the demo script showcasing device code flow (7:40)

Defending against sophisticated attacks like Storm-2372 requires a multi-faceted approach, moving beyond generic security advice to specific, technical controls and vigilant monitoring. Jenko Hwong outlined several critical implications for blue teams:

1. Conditional Access Policies (CAPs) are Paramount, but Complex:

• Block Device Code Flow: This is a crucial first step. CAPs should be configured to block device code flow for most users. However, Hwong cautions that this can break legitimate workflows for services like the device registration service itself (which is central to the attack) and the Azure CLI. Organizations must carefully identify and whitelist specific users or IP ranges for these legitimate uses, potentially restricting device registration to company-controlled IP addresses.
• Force Reauthentication: Implement CAPs to force users to reauthenticate with MFA under specific conditions, such as when joining a new device to the domain.
• IP-Based Restrictions: For sensitive actions like device registration or accessing critical resources, consider restricting access based on trusted IP addresses or geographical locations.

1. Enhanced Monitoring of Device Registration and Authentication Methods:

• Anomalous Device Registrations: Defenders must actively monitor device registration service logs for suspicious activity. Look for devices registered with unusual operating systems, device names, or from unexpected IP addresses. Pay close attention to registrations occurring outside of typical business hours or provisioning processes.
• Scrutinize New Authentication Methods: Monitor the addition of Windows Hello keys as authentication methods, particularly those not associated with a physical, managed device. If possible, restrict users' ability to add authentication methods without administrative approval, as this is a key persistence mechanism for attackers. Be aware that Microsoft's defaults for new tenants may have improved, but existing tenants likely retain more permissive settings.

1. Advanced Log Analysis and Hunting:

• Focus on Specific Fields: While Azure logs can be noisy, prioritize fields like Session ID, transfer method, authentication method (specifically device flow), and the newly introduced Unique Token Identifier (UTI). The UTI, where available, provides invaluable granularity at the access token level, allowing defenders to track specific token activity, especially if it moves across IP addresses, indicating a potential compromise.
• Suspicious API Calls: Hunt for suspicious Graph API calls, particularly those related to discovery and enumeration (e.g., hitting the /user endpoint to enumerate the entire directory or other objects like service principles). Normal user activity rarely involves such broad discovery, making these strong indicators of attacker reconnaissance.
• Don't Rely on Weak Indicators: Disregard hunting queries based on highly unreliable indicators like user click delays during phishing attempts, as these generate excessive false positives and are impractical for real-time detection.

1. Broader Threat Landscape Awareness:

• Beyond Device Code Phishing: Recognize that device code phishing is just one initial access vector. Attackers can also steal browser sessions or session cookies through traditional means, leading to the same PRT hijack and device registration abuse. Defensive strategies must be generalized to cover these alternative entry points.
• Understand Continuous Access Evaluation (CAE) Limitations: While CAE aims to revoke access tokens quickly, its limited support and reliance on app participation mean it's not a silver bullet. Don't assume full protection.
• Address Service Principle Abuse: Attacks related to OAuth often involve service principles (both user-created and Microsoft's own). Monitor for abuse of federated identities and two-legged service principles. Follow researchers like Eric Woodruff who highlight how elevated privileges (e.g., App Administrator) can be used to take over Microsoft service principles and escalate to Global Admin.
• Review Entra Defaults: Re-evaluate default permissions in Entra ID. For instance, default members' ability to hit /users and enumerate the entire directory aids attackers in crafting more convincing secondary phishing attacks.

By implementing these specific, technically informed defensive measures, organizations can significantly enhance their resilience against Storm-2372-like attacks and the broader category of token-based identity compromise in Azure.

Key Takeaways

• Storm-2372 Underestimated a Known Threat: The attack campaign highlighted a critical, yet previously documented, vulnerability involving Primary Refresh Token (PRT) hijacks and device registration abuse, which Microsoft's initial reporting downplayed.
• Multi-Stage Token Compromise: The attack chain is sophisticated, moving from initial device code phishing to PRT theft for privilege escalation, and finally, establishing deep persistence via user-bound Windows Hello keys.
• OAuth Implementation Weakness: Microsoft's Single Sign-On (SSO) implementation allows attackers to pivot between various first-party applications and change token scopes without user re-approval, facilitating lateral movement.
• Targeted Defensive Actions are Crucial: Generic security advice is insufficient. Defenders must implement specific Conditional Access Policies (CAPs) to restrict device code flow and registration, and actively monitor for anomalous device registrations and authentication method additions.
• Improving Log Granularity, But Still Challenging: While new fields like the Unique Token Identifier (UTI) offer better visibility into access token activity, effective detection still requires careful filtering, understanding attacker TTPs, and moving beyond noisy "hunting queries."
• Vast Attack Surface: The underlying vulnerabilities affect virtually all corporate Microsoft users relying on domain-joined devices and SSO, underscoring the widespread impact and the need for immediate, focused defensive efforts.

About the Speaker(s)

Jenko Hwong is a security researcher with a focus on Azure security, particularly around identity, OAuth, and cloud-based attack techniques. Throughout his talk, he demonstrates a deep technical understanding of both red team offensive tactics and blue team defensive strategies within Microsoft's cloud ecosystem. Hwong emphasizes the importance of ongoing research and community discussion to address complex vulnerabilities that may be under-reported or misunderstood. He makes his scripts and resources available on his GitHub (DC33 repo for this talk), indicating a commitment to sharing knowledge and tools with the security community. He identifies himself as "just a research guy looking at the stuff, playing with it," highlighting a hands-on, investigative approach to cybersecurity challenges.