OAuth Token Theft Through Microsoft’s Front Door | Huntress
Summary
Huntress describes a proof-of-concept attack in which a sideloaded AppX package uses WWAHost.exe and WindowsRuntimeAccess="all" to run attacker-controlled JavaScript and invoke a real Microsoft sign-in flow. In testing against the author’s own Entra ID tenant, the flow captured OAuth authorization codes and access and refresh tokens despite MFA. Developer Mode or an enterprise sideloading policy is required; the article recommends detecting MSAppHost/3.0 traffic to non-Microsoft destinations and restricting sideloading.
Key points
- A sideloaded AppX package can run remote JavaScript inside the Microsoft-signed WWAHost.exe process with broad Windows Runtime access.
- The proof of concept invoked WebAuthenticationBroker and captured authorization codes and tokens after the user completed a legitimate Microsoft login and MFA.
- Testing was performed on Windows 11 24H2 against the author’s own tenant; the article does not report a victim incident.
- The captured delegated token included broad Microsoft Graph scopes, with effective access limited by the signed-in user’s existing privileges.
- A refresh token was reused hours later from another machine without re-authentication; the article says revocation or Continuous Access Evaluation can end its persistence.
- Developer Mode or enterprise AllowAllTrustedApps sideloading policy is the prerequisite; package registration otherwise fails.
- Defenders are advised to alert on MSAppHost/3.0 traffic to non-Microsoft destinations, audit AppX sideloading, restrict Developer Mode, and use Conditional Access, Token Protection, shorter refresh-token lifetimes, and CAE.
Attack Vectors
- Registering a sideloaded AppX package when Developer Mode or an enterprise sideloading policy is enabled.
- Using WindowsRuntimeAccess="all" to run attacker-controlled JavaScript in an AppX host and invoke WebAuthenticationBroker.
- Capturing the authorization code and exchanging it for OAuth access and refresh tokens after the user completes legitimate sign-in and MFA.
Defensive Notes
- Monitor proxy traffic for MSAppHost/3.0 user-agent requests to destinations outside Microsoft-owned infrastructure, with an appropriately tuned allow-list.
- Audit and restrict Developer Mode and enterprise sideloading policy; review AppX registration and related PowerShell, process, and network events.
- Require compliant or managed devices for token issuance and use Token Protection where available.
- Shorten refresh-token lifetimes and enable Continuous Access Evaluation to limit persistence.
Tags
OAuth Token TheftCredential CompromiseApp SideloadingToken TheftMicrosoft Entra IDDetection and Mitigation
Indicators of compromise
| Type | Indicator | Context |
|---|---|---|
| DOMAIN | login[.]microsoftonline[.]com | Microsoft login and token infrastructure used for the legitimate sign-in flow in the proof of concept; listed by the article as an indicator. |
MITRE ATT&CK
T1071.001Attacker JavaScript communicates over HTTP(S) to deliver the payload and receive the authorization code.T1105The sideloaded AppX package loads remote JavaScript from an attacker-controlled URL.T1133The article identifies use of the remote Microsoft sign-in and token-issuance flow.T1218The article describes using the Microsoft-signed WWAHost.exe to render and run attacker-controlled web content.T1219The article describes reusing refresh tokens from other machines to access Microsoft services.T1528The payload captures OAuth access and refresh tokens returned after sign-in.T1647The article identifies registering a sideloaded AppX package, enabled by Developer Mode or policy, as part of the attack.