> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # OAuth Token Theft Through Microsoft's Front Door | Huntress - URL: https://f4n6.co.uk/security-feed/oauth-token-theft-through-microsofts-front-door-huntress/ - Published: 2026-09-23T20:11:36.000Z - Updated: 2026-09-23T20:11:36.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Huntress published a proof-of-concept on 23 September 2026 showing that a sideloaded AppX package can turn WWAHost.exe, a Microsoft-signed Windows binary, into an OAuth token stealer. The package points the host at attacker-controlled JavaScript that calls WebAuthenticationBroker using Microsoft Office's own client ID, so the user sees a real login.microsoftonline.com dialog, completes MFA normally, and the resulting access and refresh tokens are delivered to the attacker's listener. The technique requires Developer Mode or an enterprise sideloading policy (AllowAllTrustedApps) on the endpoint; without one of them, package registration fails with 0x80073CFF. No verified reference data resolved for this item, so no CVSS score, severity rating or CISA KEV state is available and none is asserted here. For EMEA financial services the exposure is conditional: developer workstations, CI/CD runners and cloud VMs are the likely places the prerequisite is already met, and where it is, MFA does not stop the theft. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. The item is a vendor proof-of-concept disclosure, not an incident affecting a named entity. The facts that would engage DORA Art. 17 to Art. 19 (an actual ICT-related incident and its classification and reporting) or NIS2 Art. 23 (an actual incident with significant impact) are not present in the source. The one configuration fact worth acting on, Developer Mode or AllowAllTrustedApps enabled on managed endpoints, is a hardening decision rather than a reporting trigger, and mapping it to a regulatory article would be compliance-checkbox padding. ## 3\. Technical analysis & attack chain The chain below is the sequence Huntress describes and demonstrates. It is a proof-of-concept, not an observed intrusion. 1. The endpoint has Developer Mode enabled, or an enterprise sideloading policy (AllowAllTrustedApps) in force. This is the gate. Without one of the two, `Add-AppxPackage -Register` fails immediately with `0x80073CFF`, and the error text names both paths. 2. The attacker builds a sideloaded AppX package whose manifest declares `WindowsRuntimeAccess="all"`. 3. The package points WWAHost.exe (the Windows Web App Host) at web content the attacker controls. In the demonstration this was a page hosted on the researcher's Kali box. 4. Because of the manifest flag, the remote JavaScript does not merely run: it inherits the full Windows Runtime API surface, including the API that drives OAuth sign-in. 5. The script calls `WebAuthenticationBroker` using Microsoft Office's own client ID. The source does not give the client ID value. 6. A real Microsoft login dialog opens on the desktop. It is served from login.microsoftonline.com and rendered by the signed WWAHost.exe process, with no address bar and no browser. 7. The user enters credentials and completes MFA. 8. The access token and the refresh token are returned to the attacker's listener. Two properties of this chain matter more than the individual steps. First, nothing in it is fake. There is no phishing domain, no lookalike UI, no certificate warning and no browser, so the user has nothing to inspect and no reason to hesitate. Second, every component after the Developer Mode toggle is a trusted, signed Microsoft binary doing what it was built to do, which leaves signature-based defences with no obvious reason to flag the activity. The tokens survive MFA because the authentication is legitimate; the attacker captures what the legitimate flow hands back. The prerequisite is the constraint on the attack. Enabling Developer Mode requires local administrator rights by any method. Via Settings it is Settings > For developers > Developer mode > ON, which is UAC-gated. Via registry, with admin: ``` reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" ` /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f ``` Once the toggle is set, the rest of the chain runs as a standard user, with no further admin, no UAC prompt and no code signing. Huntress tested on Windows 11 24H2 (build 26100). Developer Mode is not on by default on standard end-user machines, but it is common on development machines, CI/CD runners and cloud VMs, and it can be enabled across a fleet by GPO. The source states that the enterprise sideloading policy is the more likely way a managed fleet ends up in the vulnerable state at scale, and that a GPO mitigation closes both paths. The supplied extract does not include that policy path, so it is not reproduced here. Confidence caveat. This is a single-sourced vendor proof-of-concept. The supplied extract ends before the post's own detection guidance, so the detection material in §6 is derived from the described behaviour rather than taken from the vendor. No in-the-wild use of this specific chain is reported in the material provided. Two related techniques appear in the accompanying sources and should not be conflated with this one. ESET describes EvilTokens, a phishing kit that subverts Microsoft's legitimate authentication flow to reach accounts without stealing passwords or standing up fake login pages. The Hacker News describes OAuth client ID spoofing, used by at least two threat actors to enumerate accounts and validate stolen Microsoft Entra ID credentials without generating a successful sign-in event. Both are single-sourced, both are distinct mechanisms from the sideloaded AppX chain above, and neither is corroborated by a second source in this set. ## 4\. Mitigation & containment ### P1 (within 24 hours) - Inventory Developer Mode and the AllowAllTrustedApps sideloading policy across managed Windows endpoints. The value to check is `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense`; a value of 1 means Developer Mode is on. Confirm the GPO path for both controls in your own baseline before enforcing, since the source names a GPO mitigation but the supplied extract does not give the policy path. - Where Developer Mode is not required, turn it off. The inverse of the documented enable command is: `reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 0 /f` - Hunt for `Add-AppxPackage -Register` in PowerShell script block logging (Event ID 4104) and process creation (4688, or Sysmon Event ID 1), and for WWAHost.exe resolving or connecting to login.microsoftonline.com. - If either is observed, treat the endpoint as compromised. Revoke the user's refresh tokens in Entra ID, force re-authentication, and review sign-in and audit logs for subsequent use of the token. A stolen refresh token survives MFA and password reset, so password change alone is not containment. ### P2 (within 72 hours) - Restrict sideloading on managed fleets. The source identifies the enterprise AllowAllTrustedApps policy as the more likely route to fleet-wide exposure at scale. - Apply Conditional Access token protection and continuous access evaluation where licensed. The control that matters here is binding the token to the device, because the theft defeats the authentication step itself. - Alert on WWAHost.exe spawned by powershell.exe or any non-standard parent, and on WWAHost.exe outbound traffic from endpoints that do not run AppX web-host applications. ### P3 (within 7 days) - Review developer workstation, CI/CD runner and cloud VM images for Developer Mode enabled by default or baked into the build. - Deploy the §6 detections to production SIEM and tune against your own AppX web-host inventory. - Brief the service desk on what users cannot be expected to catch: a genuine login.microsoftonline.com dialog, rendered by a signed Microsoft process, with no address bar, can be attacker-initiated. User inspection is not a control for this technique. ## 5\. Indicators of compromise No atomic indicators of compromise available in the source material. The source gives no hashes, domains, IP addresses or file paths for the malicious package; the only network endpoint named is login.microsoftonline.com, which is legitimate Microsoft infrastructure and is not an indicator. The source does describe observable behaviours. These are single-sourced from the Huntress proof-of-concept and should be validated against your own telemetry before enforcement. ### Behavioural indicators | behaviour | where to observe | confidence | | ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------ | | AppX package registered from a non-Store path via Add-AppxPackage -Register | PowerShell script block logging (4104), process creation (4688 / Sysmon 1) | medium | | WWAHost.exe resolving or connecting to login.microsoftonline.com | DNS query telemetry (Sysmon 22), proxy or egress logs | medium | | WWAHost.exe spawned by powershell.exe or another non-standard parent | process creation (4688 / Sysmon 1) | medium | | Registry value HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\AppModelUnlock\\AllowDevelopmentWithoutDevLicense set to 1 | registry telemetry (Sysmon 12/13) | high, this is the documented prerequisite | | Package registration failing with 0x80073CFF | AppXDeployment operational log | low, indicates an attempt on a host without the prerequisite | | WebAuthenticationBroker invoked from a sideloaded package | Windows Runtime / ETW telemetry, limited visibility in most estates | low | ## 6\. Detection The YARA rule targets the sideloaded package content rather than a binary, because the binaries in the chain are legitimate Microsoft components. It has meaningful false-positive potential: legitimate developer packages can declare full Windows Runtime access. Triage every hit. ```yara rule Suspicious_AppX_OAuth_Token_Theft_Package { meta: author = "Adverse Trace" date = "2026-09-23" reference = "https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door" description = "Hunting rule for sideloaded AppX packages that declare full Windows Runtime access and drive the WebAuthenticationBroker OAuth flow. High false-positive potential; triage any hit." strings: $manifest = "WindowsRuntimeAccess" ascii wide $broker = "WebAuthenticationBroker" ascii wide condition: all of them } ``` ```yaml title: Windows Developer Mode Enabled via AppModelUnlock Registry Value status: experimental description: Detects creation or modification of the AppModelUnlock AllowDevelopmentWithoutDevLicense value, which enables Windows Developer Mode and is the documented prerequisite for the sideloaded AppX OAuth token theft technique described by Huntress. references: - https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door author: Adverse Trace date: 2026/09/23 logsource: category: registry_set product: windows detection: selection_key: TargetObject|endswith: '\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense' selection_value: Details|contains: '0x00000001' condition: selection_key and selection_value falsepositives: - Developer workstations, CI/CD build agents and cloud VM images where Developer Mode is enabled by design level: medium tags: - attack.t1112 ``` ```yaml title: WWAHost.exe Resolving Microsoft Online Authentication Endpoint status: experimental description: Detects the Windows Web App Host resolving login.microsoftonline.com. In the Huntress proof-of-concept a sideloaded AppX package drives WWAHost.exe to render attacker-controlled JavaScript that calls WebAuthenticationBroker against this endpoint and captures the returned OAuth tokens. references: - https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door author: Adverse Trace date: 2026/09/23 logsource: category: dns_query product: windows detection: selection: Image|endswith: '\WWAHost.exe' QueryName|endswith: 'login.microsoftonline.com' condition: selection falsepositives: - Legitimate AppX web-host applications that authenticate users against Microsoft Entra ID level: medium ``` ## 7\. Sources - Huntress, "OAuth Token Theft Through Microsoft's Front Door", https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door, 2026-09-23 - ESET WeLiveSecurity, "EvilTokens: A phishing attack that doesn't steal your password", https://www.welivesecurity.com/en/cybercrime/eviltokens-phishing-doesnt-steal-password/, date not stated in the supplied material - The Hacker News, "OAuth Client ID Spoofing Lets Attackers Validate Stolen Microsoft Entra Credentials", https://thehackernews.com/2026/07/oauth-client-id-spoofing-lets-attackers.html, July 2026 ## 8\. Adverse Trace position No verified reference data resolved for this item, so we assign no CVSS score, no severity rating and no CISA KEV exploitation state, and clients should not treat the absence as a low rating. Our assessment is that the technique is real and demonstrated, and that its reach is bounded by a single configuration: Developer Mode or an enterprise sideloading policy. Estates that keep Developer Mode off standard endpoints carry little exposure from this chain; estates with developer workstations, CI/CD runners or cloud VM images where the toggle is on carry a control gap that MFA does not close. The whole chain rests on one vendor's proof-of-concept and no in-the-wild use is reported in the material we hold, so we are treating it as a detection-engineering priority rather than an incident-response one. We will add the AppModelUnlock registry value and WWAHost.exe authentication-endpoint queries to client hunts this week, and we will reissue this advisory with a severity rating if a campaign using this chain is reported or if the vendor publishes the detection guidance that was outside the extract we received. --- [Read the original source →](https://www.huntress.com/blog/stealing-oauth-tokens-through-microsofts-front-door?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*