# OAuth Token Theft via Sideloaded AppX Packages Abusing Microsoft-Signed Web Hosts (WWAHost.exe)

> Huntress researcher Andrew Schwartz demonstrates a post-compromise technique that sideloads a malicious AppX package declaring WindowsRuntimeAccess="all" to abuse the Microsoft-signed AppX web host WWAHost.exe and the legacy WebAuthenticationBroker WinRT API. The attacker's JavaScript invokes WebAuthenticationBroker.authenticateAsync() using Microsoft Office's first-party Entra ID client ID, presenting the real login.microsoftonline.com sign-in UI inside a chromeless native host and capturing the resulting OAuth authorization code via an out-of-band (oob) redirect URI, yielding persistent, MFA-surviving Microsoft 365/Entra ID access.

- **Published:** 2026-09-23T00:00:00Z
- **Last reviewed:** 2026-09-23T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2628
- **ID:** TL-2026-2628
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 7 (full data via the Threadlinqs MCP server — Purple tier)

## Description

This technique targets Windows endpoints where Developer Mode or the enterprise 'Allow all trusted apps to install' (AllowAllTrustedApps) sideloading policy is enabled. An attacker with existing code execution registers a minimal, self-signed AppX package as a standard user via `Add-AppxPackage -Register`. The package's AppxManifest.xml declares `WindowsRuntimeAccess="all"` on its ContentUriRules, pointing the web content URI at attacker-controlled infrastructure. When activated, the package is rendered by WWAHost.exe (Windows Web App Host) — a Microsoft-signed binary — which grants the attacker's hosted JavaScript full Windows Runtime API access rather than the sandboxed access a normal browser tab would receive.

From inside this trusted host, the JavaScript calls the legacy `WebAuthenticationBroker.authenticateAsync()` API, supplying Microsoft Office's real first-party Entra ID application (client) ID (`d590ed36-52b3-4102-aeff-aad2292ab01c`) and the `urn:ietf:wg:oauth:2.0:oob` out-of-band redirect URI. Because WebAuthenticationBroker is a legacy WinRT API inherited by any AppX host through the shared Windows Runtime activation layer (not gated to individual host binaries), the broker opens a genuine, unmodified `login.microsoftonline.com` sign-in dialog with no browser chrome or address bar. The victim authenticates normally, including completing MFA — nothing is spoofed or intercepted at the credential layer, so MFA is not bypassed technically, it is simply irrelevant: the user is a legitimate, willing participant in a real Microsoft authentication ceremony staged inside a trusted-looking native surface.

The resulting OAuth authorization code is returned to the attacker's JavaScript through the oob callback rather than a browser redirect, and is exchanged offline for access and refresh tokens scoped to whatever delegated permissions the Office client ID carries — observed scopes include Mail.ReadWrite, Mail.Send, Files.Read, Files.ReadWrite.All, FileStorageContainer.Selected, Channel.Create, ChannelMessage.Send, Chat.ReadWrite, TeamMember.ReadWrite.All, Calendar.ReadWrite, Contacts.ReadWrite, Directory.Read.All, Directory.AccessAsUser.All, and notably AuditLog.Create, which the researcher flags as enabling investigation evasion. The refresh token then permits silent, indefinite token regeneration from any machine until an administrator revokes it or a Continuous Access Evaluation (CAE) event fires — giving the attacker durable, cross-device access to the victim's full Microsoft 365 and Entra ID footprint without ever touching the victim's password or MFA factor again.

Huntress ties the technique to a broader body of AppX/MSIX packaging-abuse research, including Nick Powers' DEF CON 34 talk 'MSIX'd Up: Weaponizing the Modern Windows App Packaging Ecosystem' and Dirk-jan Mollema's askWAM tool, which requests Entra ID tokens directly from the Windows Web Account Manager (WAM) broker. The published defense is a single invariant network signature: any HTTP(S) request bearing the `MSAppHost/3.0` User-Agent — the fixed identifier for AppX web hosts — to a destination outside Microsoft's own domains is anomalous, regardless of which specific WinRT API a given AppX host abuses.

## MITRE ATT&CK

- T1528 Steal Application Access Token
- T1550.001 Application Access Token
- T1078.004 Cloud Accounts
- T1218 System Binary Proxy Execution
- T1112 Modify Registry
- T1087.004 Cloud Account
- T1530 Data from Cloud Storage
- T1114.002 Remote Email Collection
- T1534 Internal Spearphishing
- T1071.001 Web Protocols
- T1567 Exfiltration Over Web Service

## Sources

- [Stealing OAuth Tokens Through Microsoft's Front Door](https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door)
- [DEF CON 34 - Nick Powers - MSIX'd Up: Weaponizing the Modern Windows App Packaging Ecosystem](https://defcon.org/html/defcon-34/dc-34-speakers.html)
- [askWAM - Ask the Web Account Manager (WAM) for Entra ID tokens](https://github.com/dirkjanm/askWAM)
- [What is MSIX? (MSIX/AppX packaging overview)](https://learn.microsoft.com/en-us/windows/msix/overview)
- [Traitorware: How Hackers Abuse Legitimate Apps to Hijack Microsoft 365](https://www.huntress.com/resources/traitorware-how-hackers-abuse-legitimate-apps-to-hijack-microsoft-365)
- [6 Months of Researching OAuth Application Attacks](https://www.huntress.com/blog/never-just-one-termite-6-months-of-researching-oauth-application-attacks)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2628