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.
- domainindex-j7k[.]dibafef289[.]workers[.]devFake DocuSign phishing page hosting the malicious verification code workflow.
- sha256A73B7CE334B0F346CF5161E65173DFF08B6BB313969A5F603A3344F9644C4DE6SHA256 hash of the malicious file/activity analyzed in the sandbox.
- urlhxxps://is[.]gd/4kZgryInitial malicious short URL leading to the OAuth phishing flow.
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
| Hypothesis | Telemetry | ATT&CK Stage | FP 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 Logs | Credential Access | Medium |
| 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 Logs | Initial Access | Low |
| Monitor decrypted network traffic for HTTP requests containing the 'X-Antibot-Token' header communicating with unknown or low-reputation domains. | Network Traffic Analysis | Command and Control | Low |
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 domaindibafef289[.]workers[.]dev- Phishing infrastructure domainab-monvoisinproduction-com-s-account[.]workers[.]dev- Phishing infrastructure domainsubzero908[.]workers[.]dev- Phishing infrastructure domainsandra-solorzano-duncanfamilyfarms-net-s-account[.]workers[.]dev- Phishing infrastructure domaintyler2miler-proton-me-s-account[.]workers[.]dev- Phishing infrastructure domainaarathe-ramraj-tipgroup-com-au-s-account[.]workers[.]dev- Phishing infrastructure domainandy-bardigans-com-s-account[.]workers[.]dev- Phishing infrastructure domaindennis-saltertrusss-com-s-account[.]workers[.]dev- Phishing infrastructure domainrockymountainhi[.]workers[.]dev- Phishing infrastructure domainworkspace1717-outlook-com-s-account[.]workers[.]dev- Phishing infrastructure domainaiinnovationsfly[.]com- Phishing infrastructure domainastrolinktech[.]com- Phishing infrastructure domainshark-app-5wkz2[.]ondigitalocean[.]app- Related campaign domain identified via TI Lookupauthsoftverifyappsoftcodeauths[.]powerappsportals[.]com- Related campaign domain identified via TI Lookupdynamic-entry[.]powerappsportals[.]com- Related campaign domain identified via TI Lookupemail-internals[.]powerappsportals[.]com- Related campaign domain identified via TI Lookupdocusign[.]powerappsportals[.]com- Related campaign domain identified via TI Lookupthedumpsterguard[.]com- Related campaign domain identified via TI Lookuparusha-archdiocese[.]or[.]tz- Related campaign domain identified via TI Lookupsmokeshopbuddy[.]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 sandboxC327777C099EDB4938847BD142CDBF1A4C9D9CEA(SHA1) - SHA1 hash of the malicious file/activity analyzed in the sandbox
- Other:
/api/device/status/- API request endpoint used by malicious JavaScript
