Skip to content
.ca
6 minhigh

OAuth Device Code Phishing: A New Microsoft 365 Account Breach Vector

Threat actors are increasingly utilizing OAuth Device Code phishing to compromise Microsoft 365 accounts. By tricking victims into entering a verification code on the legitimate Microsoft device login page, attackers can obtain OAuth access and refresh tokens without ever harvesting the user's credentials. This technique bypasses traditional phishing defenses by operating over encrypted channels and legitimate Microsoft infrastructure.

Sens:ImmediateConf:highAnalyzed:2026-03-10reports

Authors: ANY.RUN

Actorsoauth-ms-phish

Source:ANY.RUN

IOCs · 3

Key Takeaways

  • OAuth Device Code phishing is rapidly increasing, bypassing traditional credential theft by stealing authentication tokens instead.
  • Attackers abuse the legitimate Microsoft Device Authorization Grant flow, tricking victims into approving access via microsoft.com/devicelogin.
  • Because the attack uses legitimate Microsoft infrastructure and encrypted HTTPS traffic, traditional phishing indicators often fail to detect it.
  • Account takeover occurs without the victim ever entering their password on a fake or malicious page.
  • SSL decryption is critical for SOC teams to reveal hidden scripts, API requests, and attacker infrastructure orchestrating the phishing flow.

Affected Systems

  • Microsoft 365
  • Windows

Attack Chain

The attack begins with a phishing link directing the victim to a fake document verification page, often impersonating DocuSign. This page displays a 'user_code' and instructs the victim to copy it and click a link to the legitimate Microsoft device login portal (microsoft.com/devicelogin). Once the victim authenticates on the real Microsoft page and enters the code, they unknowingly approve an OAuth device authorization request initiated by the attacker. The attacker, holding the corresponding 'device_code', then receives OAuth access and refresh tokens, granting them persistent access to the victim's Microsoft 365 account without ever stealing their password.

Detection Availability

  • YARA Rules: No
  • Sigma Rules: No
  • Snort/Suricata Rules: Yes
  • KQL Queries: No
  • Splunk SPL Queries: No
  • EQL Queries: No
  • Other Detection Logic: No
  • Platforms: Suricata

Suricata IDS rules are available to detect the malicious encrypted traffic associated with this Microsoft OAuth device code phishing campaign, provided the traffic is decrypted for inspection.

Detection Engineering Assessment

EDR Visibility: Low — The attack occurs entirely within the web browser interacting with legitimate Microsoft web services, leaving minimal traditional endpoint artifacts or malicious processes. Network Visibility: Medium — While initial connections go to suspicious domains (e.g., workers.dev), the actual credential compromise happens over encrypted connections to legitimate Microsoft domains. Full visibility requires SSL decryption. Detection Difficulty: Hard — The reliance on legitimate Microsoft infrastructure and encrypted HTTPS traffic makes distinguishing malicious device code flows from legitimate ones difficult without deep packet inspection or advanced behavioral analytics in Azure AD.

Required Log Sources

  • Web Proxy Logs
  • Azure AD Sign-in Logs
  • Network Traffic Analysis (with SSL Decryption)

Hunting Hypotheses

HypothesisTelemetryATT&CK StageFP Risk
Look for unusual device authorization grants in Azure AD logs, especially from unexpected locations, unmanaged devices, or external IP addresses.Azure AD Sign-in LogsCredential AccessMedium
Search web proxy logs for connections to suspicious subdomains (e.g., *.workers.dev, *.powerappsportals.com) immediately followed by connections to login.microsoftonline.com/common/oauth2/deviceauth.Web Proxy LogsInitial AccessLow
Monitor decrypted network traffic for HTTP requests containing the 'X-Antibot-Token' header communicating with unknown or low-reputation domains.Network Traffic AnalysisCommand and ControlLow

Control Gaps

  • Lack of SSL decryption on web proxies
  • Over-reliance on traditional credential phishing indicators
  • Insufficient monitoring of OAuth device code grants in Azure AD

Key Behavioral Indicators

  • Connections to microsoft.com/devicelogin originating from suspicious referrers
  • Presence of /api/device/start or /api/device/status/ in decrypted web traffic to non-Microsoft hosts
  • X-Antibot-Token header in HTTP requests

False Positive Assessment

  • Medium. Legitimate use of the device code flow exists for smart TVs, CLI tools, and older devices without native browsers, which could trigger behavioral alerts if detection logic is not properly tuned.

Recommendations

Immediate Mitigation

  • Block known malicious domains and URLs associated with this campaign.
  • Review recent Azure AD sign-in logs for suspicious device code authorizations and revoke unrecognized sessions and tokens.

Infrastructure Hardening

  • Implement SSL decryption on web proxies to inspect HTTPS traffic for hidden scripts and API requests.
  • Restrict or disable the OAuth Device Code flow in Azure AD if it is not required for business operations using Conditional Access policies.

User Protection

  • Deploy advanced web filtering to block newly registered or low-reputation domains, particularly abused subdomains on services like workers.dev or powerappsportals.com.

Security Awareness

  • Train users to recognize the signs of device code phishing, emphasizing that they should never enter a verification code provided by an untrusted source into a Microsoft login page.

MITRE ATT&CK Mapping

  • T1566.002 - Phishing: Spearphishing Link
  • T1528 - Steal Application Access Token
  • T1550.001 - Use Alternate Authentication Material: Application Access Token

Additional IOCs

  • Domains:
    • singer-bodners-bau-at-s-account[.]workers[.]dev - Phishing infrastructure domain
    • dibafef289[.]workers[.]dev - Phishing infrastructure domain
    • ab-monvoisinproduction-com-s-account[.]workers[.]dev - Phishing infrastructure domain
    • subzero908[.]workers[.]dev - Phishing infrastructure domain
    • sandra-solorzano-duncanfamilyfarms-net-s-account[.]workers[.]dev - Phishing infrastructure domain
    • tyler2miler-proton-me-s-account[.]workers[.]dev - Phishing infrastructure domain
    • aarathe-ramraj-tipgroup-com-au-s-account[.]workers[.]dev - Phishing infrastructure domain
    • andy-bardigans-com-s-account[.]workers[.]dev - Phishing infrastructure domain
    • dennis-saltertrusss-com-s-account[.]workers[.]dev - Phishing infrastructure domain
    • rockymountainhi[.]workers[.]dev - Phishing infrastructure domain
    • workspace1717-outlook-com-s-account[.]workers[.]dev - Phishing infrastructure domain
    • aiinnovationsfly[.]com - Phishing infrastructure domain
    • astrolinktech[.]com - Phishing infrastructure domain
    • shark-app-5wkz2[.]ondigitalocean[.]app - Related campaign domain identified via TI Lookup
    • authsoftverifyappsoftcodeauths[.]powerappsportals[.]com - Related campaign domain identified via TI Lookup
    • dynamic-entry[.]powerappsportals[.]com - Related campaign domain identified via TI Lookup
    • email-internals[.]powerappsportals[.]com - Related campaign domain identified via TI Lookup
    • docusign[.]powerappsportals[.]com - Related campaign domain identified via TI Lookup
    • thedumpsterguard[.]com - Related campaign domain identified via TI Lookup
    • arusha-archdiocese[.]or[.]tz - Related campaign domain identified via TI Lookup
    • smokeshopbuddy[.]com - Related campaign domain identified via TI Lookup
  • Urls:
    • hxxps://arusha-archdiocese[.]or[.]tz/magatx/texas1st.html - Malicious URL associated with the oauth-ms-phish campaign
  • File Hashes:
    • B31EDE2C7210F4AF270497932312EC7E (MD5) - MD5 hash of the malicious file/activity analyzed in the sandbox
    • C327777C099EDB4938847BD142CDBF1A4C9D9CEA (SHA1) - SHA1 hash of the malicious file/activity analyzed in the sandbox
  • Other:
    • /api/device/status/ - API request endpoint used by malicious JavaScript