Sideloaded AppX Package Can Steal Microsoft OAuth Tokens Through WWAHost.exe
Summary
The article demonstrates how a sideloaded AppX package with WindowsRuntimeAccess="all" can use WWAHost.exe and WebAuthenticationBroker to display Microsoft’s legitimate sign-in flow and capture OAuth authorization codes and access and refresh tokens, even after the user completes MFA. The demonstrated attack requires Developer Mode or an enterprise sideloading policy. The author recommends detecting MSAppHost/3.0 traffic to non-Microsoft destinations and restricting sideloading; captured refresh tokens can be revoked, and Conditional Access and token-lifetime controls can limit their use.
Key points
- A sideloaded AppX package can direct WWAHost.exe to render attacker-controlled JavaScript with access to Windows Runtime APIs, including WebAuthenticationBroker.
- The demonstrated flow used Microsoft’s real login page; after the user completed MFA, the attacker captured the authorization code and exchanged it for access and refresh tokens.
- Developer Mode or an enterprise AllowAllTrustedApps sideloading policy is required; package registration can then run as a standard user.
- The tested token included broad delegated Microsoft Graph scopes. Its effective access depends on the signed-in user’s permissions.
- The author confirmed that a captured refresh token could obtain new access tokens hours later, from another machine and network, without another sign-in.
- The recommended network detection flags MSAppHost/3.0 traffic to non-Microsoft destinations, with an allow-list to reduce false positives; the sign-in leg uses a different user agent.
- Defenders are advised to restrict Developer Mode and sideloading, audit package registration, and use Conditional Access, Token Protection where available, shorter refresh-token lifetimes, and Continuous Access Evaluation.
Attack Vectors
- Registering a sideloaded AppX package when Developer Mode or an enterprise sideloading policy is enabled.
- Using WindowsRuntimeAccess="all" to run remote JavaScript in WWAHost.exe and invoke WebAuthenticationBroker.
- Capturing the authorization code returned after the user completes Microsoft sign-in and MFA, then exchanging it for tokens.
Defensive Notes
- Alert on MSAppHost/3.0 user-agent traffic to destinations outside a carefully maintained Microsoft-owned-domain allow-list.
- Audit and restrict Developer Mode and enterprise sideloading policies; review AppX package registration and manifests for external ContentUriRules with WindowsRuntimeAccess="all".
- Use Conditional Access to require compliant or managed devices, and consider Token Protection where available.
- Shorten refresh-token lifetimes and enable Continuous Access Evaluation to limit persistence.
Tags
Threat ResearchOAuth Token TheftAppX SideloadingToken TheftMFA
Indicators of compromise
| Type | Indicator | Context |
|---|---|---|
| DOMAIN | login[.]microsoftonline[.]com | Microsoft’s legitimate login endpoint used in the demonstrated OAuth flow; the article lists it as Microsoft login infrastructure, not as a malicious domain. |
MITRE ATT&CK
T1071.001The article describes JavaScript communicating over HTTP(S) to deliver the payload and return the authorization code.T1105The AppX package loads remote JavaScript from an attacker-controlled URL through its ContentUriRules.T1133The article explicitly associates the attack with a legitimate remote Microsoft login flow and token issuance.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 obtain new access tokens.T1528The payload captures OAuth access and refresh tokens after sign-in.T1647The article describes registering a sideloaded AppX package, requiring Developer Mode or an enterprise sideloading policy.