A sideloaded AppX package turns a Microsoft-signed web host into an OAuth token thief: the login dialog is genuine, the MFA is genuine, and the tokens go to the attacker

Huntress researcher Andrew Schwartz went looking for a Microsoft-signed binary already present on every Windows machine that would fetch remote code and run it, and found the AppX web-host family (Huntress, 2026-09-23). WWAHost.exe, the Windows Web App Host, renders whatever web content an AppX package points it at. The manifest flag is what turns that into an attack: when a package's ContentUriRules entry carries WindowsRuntimeAccess="all", the remote JavaScript loaded from that origin "doesn't just run, it inherits the full Windows Runtime API surface, including the API that drives OAuth sign-in" (Huntress, 2026-09-23). The API in question is the legacy WebAuthenticationBroker, which Microsoft has steered developers away from in favour of the Web Account Manager but which remains present and reachable from inside the AppX host.

The chain is short. A standard user registers a minimal sideloaded package with Add-AppxPackage -Register; attacker JavaScript then calls WebAuthenticationBroker.authenticateAsync() with Microsoft Office's own first-party client ID and the urn:ietf:wg:oauth:2.0:oob redirect URI, which is the part that matters, because an out-of-band redirect returns the authorization code to the calling application rather than to a browser. The user sees a real Microsoft sign-in dialog served from login.microsoftonline.com, rendered by a signed Microsoft process with no address bar and no browser chrome, completes the password and the MFA prompt, and the code lands in the attacker's listener to be exchanged for an access token and a refresh token. Huntress's summary of the victim's position is the whole point of the technique: "The user does everything right and it changes nothing" (Huntress, 2026-09-23).

The prerequisite is the constraint. Registration fails with 0x80073CFF unless Developer Mode is enabled or an enterprise sideloading policy is in force, and enabling Developer Mode itself requires local administrator rights. Huntress is explicit that the enterprise AllowAllTrustedApps path is the more likely way a managed fleet ends up in the vulnerable state at scale, and notes Developer Mode is common on development machines, CI/CD runners and cloud VMs. Past that one toggle, the remaining steps run as a standard user with no further admin, no UAC prompt, no SmartScreen check and no code-signing requirement. The technique is therefore post-compromise or post-social-engineering, not an initial-access vector on its own.

What the tokens carry is what makes it worth the effort. The captured token arrived with the delegated scope set attached to Microsoft Office's client ID, spanning mail read, write and send, files across OneDrive and SharePoint, the Teams surface including channels, chats, messages and membership, directory and group read and write, and calendar and contacts, plus AuditLog.Create, which Huntress singles out as an unexpected capability with obvious value for muddying an investigation. Because these are delegated scopes, the effective power is the intersection of the scope and what the signed-in user could already do, so the blast radius scales with the victim's own privilege rather than granting tenant administration automatically. Huntress states the consequence plainly: "It is, in effect, the victim's entire Microsoft 365 working life in one token, and unlike the session it was stolen from, it keeps working from anywhere until the refresh token is revoked." New access tokens were obtained hours later from a different machine on a different network with no re-authentication and no MFA prompt; the refresh token survives password changes until an administrator revokes it, a revocation event fires, or Continuous Access Evaluation intervenes.

The defensive framing Huntress argues for is a class, not a binary. WWAHost.exe is the one host proven end to end, but the reachable surface lives in the shared Windows Runtime activation layer that every AppX host loads, and the set of hosts varies by Windows build, with at least one shipping from the packaged store rather than a system directory so that an inventory searching only system directories under-counts. "That is why patching individual binaries won't fix the problem, and why an EDR rule for WWAHost.exe alone is futile" (Huntress, 2026-09-23). The researcher deliberately publishes neither the working manifest nor an enumeration of the other hosts, and separates what was proven end to end (token theft via the OAuth broker, on Windows 11 24H2 build 26100) from what was only shown to be reachable: a native credential dialog returning plaintext credentials, DPAPI operations in the user's own key context, and protocol-handler launching, all demonstrated on an earlier build and not re-confirmed. A silent, no-interaction variant of the broker call is described as documented and expected behaviour that the author did not confirm, and should be read as an open avenue rather than a result.

Triage: MSAppHost/3.0 reaching Microsoft-owned infrastructure is ordinary AppX behaviour and not a finding; the same user agent reaching an origin outside Microsoft is what has no benign explanation. Likewise, an Office sign-in from a managed device is unremarkable on its own, so the discriminator is the pairing: a successful Office-client-ID sign-in on a host that also produced outbound EdgeHTML-engine traffic to a non-Microsoft origin in the same window.