A signed Windows binary can stand up a real Microsoft login and pocket the tokens

The chain works because every part of it is a Microsoft-signed binary doing what it was built to do. WWAHost.exe hosts web content inside AppX packages ^[2]. When the package manifest declares ContentUriRules with WindowsRuntimeAccess="all", the JavaScript that WWAHost renders inherits the full Windows Runtime API surface, including WebAuthenticationBroker, the system-level OAuth handler ^[3].

Huntress researcher wired up a proof of concept: a throwaway sideloaded package, a page hosted on a Kali box, and a WebAuthenticationBroker call using Microsoft Office's own client ID ^[4]. Running it opened a real Microsoft login dialog on the desktop, served from login.microsoftonline.com, rendered by a signed Microsoft process, with no address bar and no browser ^[5]. The researcher typed the password, completed MFA, and the access and refresh tokens landed in the listener a second later ^[6].

There is no phishing page and no lookalike domain, because the login flow is Microsoft's own ^[7]. The tokens survive MFA because the user authenticates legitimately and the attacker captures what comes back ^[8].

The constraint is Developer Mode. Without it, Add-AppxPackage -Register fails immediately with 0x80073CFF ^[9]. Enabling Developer Mode requires local administrator rights ^[10]. Once it is on, the rest of the chain runs as a standard user with no further admin, no UAC prompt, and no code signing ^[11].

That toggle is not on by default on standard end-user machines ^[12]. It is common on development machines, CI/CD runners, and cloud VMs, and it can be pushed across a fleet by GPO ^[13]. The researcher is precise about the real gate: Developer Mode or an enterprise sideloading policy, the AllowAllTrustedApps path, and the enterprise policy is the more likely way a managed fleet ends up vulnerable at scale ^[14]. The GPO mitigation closes both ^[15].

One detail bounds the technique's shelf life. This is the legacy WebAuthenticationBroker, which Microsoft has steered developers away from ^[16]. WWAHost itself does not appear in LOLBAS; the researcher found it by pulling a catalog of Microsoft-signed binaries that are not on that list and filtering for anything that could reach the network and execute what it got back ^[1]. Signature-based defenses have no obvious reason to flag any step, because every component is a trusted, signed Microsoft binary ^[17].

The test ran on Windows 11 24H2, build 26100, with Developer Mode enabled ^[18].