A sideloaded AppX package can abuse WWAHost.exe and WindowsRuntimeAccess=”all” to open a real Microsoft login flow, capture OAuth authorization codes, and steal access plus refresh tokens even when MFA is completed. The article also shows that the abuse is detectable with a proxy rule for MSAppHost/3.0 traffic to non-Microsoft destinations and highlights Developer Mode as the key prerequisite. #WWAHost #WebAuthenticationBroker #MSAppHost #DeveloperMode #EntraID #MicrosoftOffice
Keypoints
- WWAHost.exe, a Microsoft-signed AppX web host, can render attacker-controlled web content from a sideloaded package.
- When the AppX manifest sets WindowsRuntimeAccess=”all”, the remote JavaScript inherits access to Windows Runtime APIs, including WebAuthenticationBroker.
- The attack can launch a legitimate Microsoft login dialog from login.microsoftonline.com and capture authorization codes, access tokens, and refresh tokens.
- MFA does not stop the attack because the user authenticates through the real Microsoft flow, and the attacker steals the returned tokens afterward.
- Developer Mode, or an enterprise sideloading policy, is the main prerequisite; without it, Add-AppxPackage -Register fails.
- The captured token carried broad Microsoft Office delegated Graph scopes, including mail, files, Teams, directory, calendar, and contacts access.
- Detection is strongest by monitoring MSAppHost/3.0 user-agent traffic to non-Microsoft destinations and by auditing sideloading activity.
MITRE Techniques
- [T1218 ] System Binary Proxy Execution – The attacker abuses a trusted Microsoft-signed binary, WWAHost.exe, to execute attacker-controlled web content (‘a Microsoft-signed binary already on every Windows box that will fetch remote code and run it’).
- [T1647 ] User Execution: Malicious File – The sideloaded AppX package depends on a user or policy enabling Developer Mode and registering the package (‘Add-AppxPackage -Register runs silently from PowerShell’).
- [T1133 ] External Remote Services – The attack leverages a legitimate remote Microsoft login flow and token issuance through login.microsoftonline.com (‘served from login.microsoftonline.com’).
- [T1528 ] Steal Application Access Token – The payload captures OAuth access and refresh tokens after the user completes sign-in (‘the access token and the refresh token were sitting in my listener’).
- [T1071.001 ] Application Layer Protocol: Web Protocols – Attacker JavaScript communicates over HTTP(S) to deliver the payload and receive the auth code (‘a page hosted on my Kali box’ and ‘POSTed to the Kali listener’).
- [T1105 ] Ingress Tool Transfer – The AppX package pulls remote JavaScript from an attacker-controlled URL and executes it inside the host (‘ContentUriRules point at the attacker’s server’).
- [T1219 ] Remote Access Software – The article describes persistence and remote reuse of refresh tokens to access Microsoft services from other machines (‘silently generate new access tokens from any location’).
Indicators of Compromise
- [Domains/Hosts ] Microsoft login and token infrastructure – login.microsoftonline.com, Microsoft Office client ID endpoint context
- [Domains/Hosts ] Attacker-controlled listener and payload host – Kali listener / attacker server hosting the AppX content
- [File names ] Proof-of-concept components – kali_listener.py, register_appx.ps1, exchange_token.py
- [File names ] AppX manifest artifact – AppxManifest.xml, with WindowsRuntimeAccess=”all” and external ContentUriRules
- [Process names ] AppX host process used in the attack – WWAHost.exe, Add-AppxPackage
- [User-agent strings ] Network-beaconing fingerprint – MSAppHost/3.0, MSAuthHost/1.0
- [Client IDs ] OAuth application identifier – d590ed36-52b3-4102-aeff-aad2292ab01c and d3590ed6-52b3-4102-aeff-aad2292ab01c
- [Registry keys/paths ] Developer Mode and sideloading control – HKLMSOFTWAREMicrosoftWindowsCurrentVersionAppModelUnlock, AllowDevelopmentWithoutDevLicense
- [Event IDs ] Defensive telemetry references – 400, 4104, 5156, 4688, 3, 7, and 613
Read more: https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door