Oauth-Theft - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/oauth-theft/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 23 Sep 2026 14:04:11 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgOAuth Token Theft via Sideloaded AppX and WWAHost.exehttps://feed.craftedsignal.io/briefs/2026-09-oauth-token-theft/Wed, 23 Sep 2026 14:04:11 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-oauth-token-theft/Attackers can abuse sideloaded AppX packages and the legitimate WWAHost.exe binary to trigger a genuine Microsoft OAuth login flow, capturing valid authentication tokens without traditional phishing indicators.This threat involves the exploitation of the Windows Web App Host (WWAHost.exe) to facilitate OAuth token theft. By sideloading a maliciously crafted, unsigned AppX package onto a Windows machine with 'Developer Mode' or enterprise sideloading policies enabled, an attacker can manipulate WWAHost.exe to render remote JavaScript that interacts with the WebAuthenticationBroker API. Because the process is a signed Microsoft binary and the authentication dialog is served directly from login.microsoftonline.com, the flow is entirely authentic. The victim completes a legitimate MFA process, providing the attacker with valid access and refresh tokens that bypass typical phishing defenses. This technique is highly effective as it avoids malicious domains, spoofed UIs, and certificate warnings, relying instead on the trust established by Microsoft's own signed binaries.

Attack Chain

  1. Attacker ensures the target host has 'Developer Mode' enabled via registry modification (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock) or system settings.
  2. Attacker deploys a malicious, unsigned AppX package to the target endpoint using Add-AppxPackage -Register.
  3. AppX package is configured with a manifest declaring WindowsRuntimeAccess="all" to gain access to the Windows Runtime API.
  4. WWAHost.exe executes the package, rendering remote content provided by the attacker's infrastructure.
  5. The rendered content invokes the WebAuthenticationBroker API, passing a legitimate client ID (e.g., for Microsoft Office).
  6. WWAHost.exe launches a genuine Microsoft login dialog, authenticating the user against Microsoft servers without browser artifacts.
  7. Upon successful MFA, the attacker's listener captures the issued access and refresh tokens for subsequent unauthorized M365 data access.

Impact

Successful exploitation results in the exfiltration of durable refresh tokens, granting persistent access to the victim's Microsoft 365 environment. The scope of impact scales with the privileges assigned to the compromised user, potentially allowing for business email compromise, data exfiltration, or further lateral movement within the cloud identity environment.

Recommendation

Prioritize the identification and restriction of developer settings on endpoint devices.

  • Audit the 'Developer Mode' setting across the enterprise fleet and disable it on all workstations where it is not strictly required for development workflows.
  • Monitor for the registration of new, unsigned AppX packages via event logs (e.g., AppxPackaging/Operational logs).
  • Implement network monitoring to detect the 'MSAppHost/3.0' user agent when it initiates connections to non-Microsoft domains or suspicious external infrastructure.
  • Configure SIEM alerts for the modification of the AppModelUnlock registry key, which is a prerequisite for this attack chain.
]]>highadvisoryoauth-theftliving-off-the-landwindowssideloading