# OAuth Token Theft Through Microsoft's Front Door

Sideloaded AppX package with WindowsRuntimeAccess="all" lets attacker JS in WWAHost.exe call WebAuthenticationBroker, harvesting Microsoft Office OAuth access and refresh tokens after real MFA.

- Payout: Research
- Severity: high
- Program: Microsoft
- Write-up by: Huntress
- Disclosed: 2026-09-23
- Write-up quality: 8/10
- Original: https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door
- Library page: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-stealing-oauth-tokens-through-microsofts-front-door
- Tags: area:os domain:desktop impact:ato impact:data-leak kind:research platform:threat-intel sev:high tech:oauth technique:source-review vuln:auth-bypass vuln:misconfiguration vuln:secrets-leak

**Target:** WWAHost.exe AppX web host / WebAuthenticationBroker WinRT API
**Root cause:** ContentUriRules with WindowsRuntimeAccess="all" grants remote JavaScript full WinRT access with no caller validation, so a sideloaded package's page can invoke WebAuthenticationBroker using a first-party client ID and the oob redirect URI.
**Steps:**
1. Enable Developer Mode (admin) so Add-AppxPackage -Register works; otherwise 0x80073CFF.
2. Create minimal AppxManifest.xml whose ContentUriRules point at attacker server with `WindowsRuntimeAccess="all"`.
3. Register as standard user: `Add-AppxPackage -Register .\AppxManifest.xml`.
4. Serve JS that calls `WebAuthenticationBroker.authenticateAsync()` with Office client ID `d3590ed6-52b3-4102-aeff-aad2292ab01c` and redirect `urn:ietf:wg:oauth:2.0:oob`.
5. Victim completes real Microsoft login and MFA in WWAHost-rendered dialog; auth code returns to attacker JS and is POSTed to listener.
6. Exchange code for access+refresh tokens; refresh token mints new access tokens without MFA.
**How found:** Hunting for signed binaries usable like regsvr32 (LOLBAS-absent, network-capable, executes fetched content); filtered for AppX web hosts, noticed WWAHost.exe plus the manifest flag WindowsRuntimeAccess="all" granting full WinRT including the OAuth broker API, then tested whether a controlled page could reach it.
**Exploitation:** Post-compromise: with Developer Mode on, attacker registers a sideloaded AppX package pointing at their server, victim authenticates through the genuine login.microsoftonline.com dialog rendered by signed WWAHost.exe, and the oob redirect delivers the auth code to attacker JS, which exchanges it for broad Graph-scoped tokens exfiltrated to attacker infrastructure.
**Escalation:** Refresh token persists across machines, networks, logoffs and reimages until revoked; delegated scopes scale with victim privilege (admin victim yields Directory.Read.All etc.); AuditLog.Create allows log tampering.
**Insight:** Manifest capability flags like WindowsRuntimeAccess="all" on signed host processes are worth grepping for: a trusted binary plus a permissive capability declaration can expose powerful WinRT APIs (auth brokers, credential pickers, DPAPI) to remote content without any unsigned code.

## Proof of concept (copied exactly from the original report)

**Sideloaded AppX registration command**

```
Add-AppxPackage -Register .\AppxManifest.xml
There's no UAC prompt, no SmartScreen, and no signature check: the package loads attacker-hosted JavaScript inside WWAHost.exe.
```

**Sigma rule for MSAppHost beaconing**

```
title: Sideloaded AppX Web Host Beaconing to Non-Microsoft Host
id: 8b1e2f34-5a6c-47d8-9e0a-1b2c3d4e5f60
status: experimental
description: >
    Detects the MSAppHost/3.0 (EdgeHTML) user agent making outbound requests to
    destinations outside Microsoft-owned domains. AppX web hosts (WWAHost.exe and
    the wider class) only legitimately contact Microsoft endpoints; this user agent
    to any other host indicates a sideloaded AppX package with
    WindowsRuntimeAccess="all" reaching attacker-controlled infrastructure.
author: Andrew Schwartz
date: 2026/07/21
logsource:
    category: proxy
detection:
    selection:
        c-useragent|contains: 'MSAppHost/3.0'
    filter_microsoft:
        cs-host|endswith:
            - '.microsoft.com'
            - '.microsoftonline.com'
            - '.msauth.net'
            - '.msftauth.net'
            - '.windows.com'
            - '.windows.net'
            - '.windowsupdate.com'
            - '.live.com'
            - '.office.com'
            - '.office365.com'
            - '.sharepoint.com'
            - '.msn.com'
            - '.bing.com'
            - '.msftconnecttest.com'
    condition: selection and not filter_microsoft
falsepositives:
    - First-party Microsoft Store / AppX telemetry to Microsoft-owned
      domains not present in the filter list (extend the allow-list to tune)
level: high
Write that into your proxy, your SIEM, or your firewall. MSAppHost/3.0 to Microsoft endpoints is normal: Store telemetry, and the like. MSAppHost/3.0 to anywhere else is the attack.
```

**Developer Mode registry enable command**

```
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" `
  /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f
```