Image: cdn.builder.io · rights & removal

OAuth Token Theft Through Microsoft's Front Door

Reporting by Huntress LabsRead the original at huntress.com

Executive Summary

A method for credential harvesting was demonstrated by exploiting the interaction between a sideloaded AppX package and Windows' underlying Web Runtime API, specifically targeting the legacy WebAuthenticationBroker. The attack relies on enabling Developer Mode to allow registration of a package that specifies broad access rights via ContentUriRules="all." This setup allows remote JavaScript execution within the trusted WWAHost.exe process, which inherits full Windows Runtime API access. This capability was used to trigger a legitimate-looking Microsoft login flow directly from the host process, capturing authorization codes and subsequently exchanging them for persistent access tokens, including refresh tokens.
The core finding is that by abusing established, signed components of the operating system—specifically the shared WinRT activation layer—an attacker can initiate an authentication sequence that appears entirely legitimate to the end-user and standard security controls. The demonstrated mechanism proves that a single vulnerability in the application packaging chain allows for the exfiltration of tokens with broad Microsoft Graph scopes, including audit log write permissions, which persist even after Multi-Factor Authentication.

Facts Only

* The attack utilized WWAHost.exe, a Microsoft-signed binary, to render web content within an AppX package.
* The manifest declared ContentUriRules="all" for WindowsRuntimeAccess.
* The process executed under Developer Mode, enabling sideloading via Add-AppxPackage -Register without UAC prompts.
* Attacker JavaScript called WebAuthenticationBroker.authenticateAsync() using Microsoft Office's client ID and an OOB redirect URI.
* The user observed a real Microsoft login dialog served from login.microsoftonline.com, rendered by the signed process.
* An authorization code was captured via the WebAuthBroker callback to an external listener.
* The captured code was exchanged for access and refresh tokens with broad Microsoft Graph scopes.
* Refresh tokens persisted after the session ended.
* Outbound connections from AppX hosts were observed to non-Microsoft IPs, logged via Security Event ID 5156.
* The attack leveraged the shared WinRT layer, specifically exposing WebAuthBroker functionality.

Full Take

The demonstration reveals a critical gap where end-to-end security and identity controls fail when trusting signed application infrastructure. The success hinges on exploiting legacy API surfaces (like WebAuthenticationBroker) that remain accessible within trusted host processes, rather than finding flaws in the individual binaries themselves. This shifts the defense focus from patching individual components to controlling the activation layer, specifically the `WindowsRuntimeAccess="all"` grant, which acts as a universal bypass for caller validation across all signed AppX hosts. The pattern is a systemic failure where assumed trust in Microsoft artifacts allows for deep lateral movement of credentials.
The significance lies not just in the token theft but in the nature of persistence and detection evasion. The method successfully bypassed traditional signature-based defenses because the execution path involved legitimate, signed processes engaging in legitimate authentication protocols. This necessitates a paradigm shift: security must audit the semantic capabilities granted by runtime access rather than merely inspecting binary hashes or process names. The proposed network detection rule—keying on the distinct user agents associated with different hosts communicating externally—is a necessary reflection of this reality.
What is missing in the narrative is a formalized understanding of the boundary between legitimate application hosting and malicious remote invocation within the WinRT subsystem. How does enterprise policy effectively govern these shared activation layers? And what are the long-term implications for trusting platform integrity when modern systems rely on layered, interconnected trust boundaries?

From the original · Huntress Labs

Introduction: The Login Page That Isn't Phishing I was hunting for the next regsvr32 . Not that binary specifically, but its category: a Microsoft-signed binary already on every Windows box that will fetch remote code and run it, so an attacker never has to drop anything unsigned.

Read the full story at huntress.com

Sentinel — Human

Confidence

This text is highly technical and appears to be authored by an expert who has performed detailed, end-to-end testing on a specific, nuanced vulnerability chain within the Windows ecosystem.

Signals Detected

Erratic sentence length variance and dense, specific technical terminology mixed with narrative framing.

Deep, focused progression from a theoretical exploit to an end-to-end PoC, supported by layered, self-referential analysis of the resulting attack surface.

Highly specific referencing of internal API structures (WWAHost.exe, WebAuthenticationBroker) and subsequent cross-referencing with Windows build specifics and SIEM/EDR concepts.

Specific validation steps (e.g., error codes, specific User Agent strings, Entra ID claims) appear technically grounded, suggesting direct empirical testing rather than pure generation.

Human Indicators

Presence of highly idiosyncratic voice and an explicit focus on the nuance between 'Proven' vs. 'Available' in terms of vulnerability measurement, which is a characteristic of deep expert analysis.

The inclusion of specific, practical mitigation steps (PowerShell commands, GPO configuration, Sigma rule definition) indicates the writer's direct operational experience.

The transition from describing the exploit to proposing a granular detection rule demonstrates an integrated approach typical of security research/reporting.