11 minhigh
Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass
Device code phishing abuses the OAuth 2.0 device authorization grant to bypass MFA. The attacker initiates a genuine device-code request with Microsoft, delivers the code to a victim via a convincing phishing lure, and the victim authenticates on the real Microsoft sign-in page — satisfying MFA legitimately. Microsoft then issues tokens to the attacker's server rather than the victim. The attacker uses these tokens to register rogue devices, create hidden inbox rules, and send further phishing from the compromised mailbox, all without touching the victim's endpoint.
Sens:■ ImmediateConf:
Showing defanged values
- domaincholaw-kr[.]coImpersonation/sender domain used in phishing campaign for device-code phishing lures
- domainprofileupdate-collaboration[.]stefan-dufva[.]workers[.]devAttacker-controlled phishing endpoint hosted on Cloudflare Workers used in the device-code phishing chain
- domainrlcounsel[.]comImpersonation/sender domain used in phishing email posing as a law firm partner to build rapport before delivering the device-code phishing lure
- domainup88qope1z[.]hlpadditives[.]comAttacker-controlled phishing endpoint used in the device-code phishing chain
- domainzr6dgshpvf[.]flosli[.]comAttacker-controlled phishing endpoint used in the device-code phishing chain
- ip104[.]219[.]238[.]253Attacker IP address used to access compromised Microsoft 365 account after device-code phishing succeeded
- ip18[.]118[.]111[.]82Attacker IP address associated with device-code phishing campaign activity
- ip40[.]124[.]130[.]50Attacker IP address associated with device-code phishing campaign activity
- ip43[.]165[.]1[.]42Attacker IP address associated with device-code phishing campaign activity
- ip83[.]136[.]210[.]246Attacker IP address associated with device-code phishing campaign activity
Detection / Hunteropenrouter
What Happened
Attackers are abusing a legitimate Microsoft login feature designed for devices like smart TVs that cannot show a normal login page. The attacker requests a short verification code from Microsoft, then tricks a victim into entering that code on the real Microsoft sign-in page. When the victim approves the login (including multi-factor authentication), Microsoft hands the login tokens to the attacker instead of to the victim. The attacker can then register fake devices under the stolen account, hide their activity with inbox rules, and send more phishing emails from the victim's mailbox — all without ever touching the victim's computer. Organizations should consider disabling this login method where it is not needed, training users to distrust unexpected codes, and monitoring for unusual device registrations or sign-ins from new locations.
Key Takeaways
- Attackers abuse the OAuth 2.0 device authorization grant to bypass MFA — the victim authenticates on a genuine Microsoft page, but tokens are issued to the attacker's server instead.
- A single device-code approval can be leveraged to register rogue devices and obtain long-lived refresh tokens, converting a one-off login into durable persistence.
- The attack operates entirely in the identity/cloud layer — the victim's endpoint is never touched, making endpoint-only detection insufficient.
- Phishing infrastructure abuses trusted services (Google Sites) and compromised legitimate websites as open redirectors to evade URL reputation checks.
- Disabling the OAuth device-code flow via Conditional Access policy where not needed is the most effective preventive control.
Affected Systems
- Microsoft 365 / Microsoft Entra ID (Azure AD)
- Microsoft Authentication Broker
- Microsoft 365 Outlook (mailbox rules and email sending)
- Any environment using OAuth 2.0 device authorization grant
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker sends phishing email impersonating a law firm partner, builds rapport over multiple messages, then delivers a link to a Google Sites lure page
- Redirection: Victim clicks link to Google Sites page, which bounces through a compromised open redirector to the final phishing page behind a fake human-check prompt
- Credential Access: Phishing page displays a device code and instructs victim to enter it at the real Microsoft sign-in page; victim authenticates and completes MFA, satisfying the attacker's pending device-code request
- Persistence: Attacker uses issued tokens to register rogue devices under the compromised account and create hidden inbox rules to bury replies and bounce messages
- Lateral Movement: Attacker uses the compromised mailbox to send further phishing emails to hundreds of external recipients, expanding the campaign from the stolen account
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: Trend Micro Vision One XDR Data Explorer App, Trend Micro Vision One Observed Attack Techniques, Trend Micro Vision One Workbench
The article provides Trend Micro Vision One XDR Data Explorer App queries for detecting device-code sign-ins, device registration events, and device-code tokens used to access the Device Registration Service. Observed Attack Techniques and Workbench detection rules are also available for 'Potential Device Code Token Generation' and 'Device Registration Resource Access via Device Code Token'. Web Reputation Services detect phishing URLs under the name HTML.Phish.Microsoft.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The attack occurs entirely in the identity and cloud layer — the victim's endpoint is never compromised. EDR will not see token issuance, device registration, or mailbox rule creation unless enriched with identity telemetry from Microsoft Entra ID. |
| Network Visibility | Medium | Network monitoring may catch connections to phishing endpoints and attacker IPs, but the use of Google Sites and compromised legitimate domains as redirectors reduces the likelihood of URL reputation hits. The actual token exchange happens between the attacker's server and Microsoft, outside the victim's network. |
| Detection Difficulty | Hard | Device-code sign-ins are rare but legitimate in some environments, requiring baselining and exception management. Device registration and inbox rule creation are common administrative activities with high false positive rates. Correlating device-code authentication with subsequent device registration and mailbox rule changes is necessary to reduce noise but requires cross-platform log integration. |
Required Log Sources
- Microsoft Entra ID sign-in logs (authenticationProtocol field)
- Microsoft Entra ID directory audit logs (device registration events)
- Microsoft 365 audit logs (inbox rule creation/modification)
- Microsoft Entra ID risk detections (atypical travel, unfamiliar sign-in properties)
- Email gateway logs (sender domain reputation, URL rewriting)
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for successful sign-ins that used the device-code authentication protocol, as these should be rare and explainable in most environments. Any unexplained device-code sign-in may indicate a phishing victim who approved an attacker's request. | Microsoft Entra ID sign-in logs with authenticationProtocol = deviceCode and status = success | Credential Access | Medium — legitimate device-code sign-ins occur for smart TVs, conference-room systems, and CLI tools; requires baselining per user and service account. |
| Consider hunting for device registration events that occur shortly after a device-code authentication, as attackers use stolen tokens to register rogue devices for persistence. | Microsoft Entra ID directory audit logs for 'Add device' actions correlated with preceding device-code sign-ins for the same user | Persistence | High — device registration is a common activity; correlation with device-code flow significantly narrows the scope but may still produce false positives for legitimate device enrollment scenarios. |
| Consider hunting for new inbox rules that move email to obscure folders, mark messages as read, or delete items, particularly when created shortly after a device-code sign-in or from an unfamiliar IP address. | Microsoft 365 audit logs for inbox rule creation/modification events correlated with Entra ID sign-in logs | Defense Evasion / Persistence | Medium — users do create legitimate inbox rules, but rules that move all incoming mail to an obscure folder or delete items are suspicious and worth investigating. |
| Consider hunting for successful sign-ins to the Microsoft Authentication Broker from unfamiliar countries, networks, or unmanaged devices, especially when correlated with device-code authentication. | Microsoft Entra ID sign-in logs filtered by client app = Microsoft Authentication Broker, cross-referenced with device compliance state and named location policies | Initial Access / Persistence | Medium — traveling users and new device enrollments can generate similar patterns; correlation with device-code flow and atypical travel improves accuracy. |
| Consider hunting for outbound phishing emails originating from internal mailboxes, as attackers use compromised accounts to send the next wave of phishing to external recipients. | Email gateway logs for high-volume outbound mail from a single internal account to external recipients, especially shortly after a device-code sign-in | Lateral Movement | Low to Medium — bulk outbound email from a user account to external recipients is unusual and typically warrants investigation regardless of context. |
Control Gaps
- Endpoint detection and response (EDR) provides no visibility into this attack as the victim's device is never compromised
- Traditional URL reputation may not flag Google Sites or compromised legitimate domains used as redirectors
- MFA is satisfied legitimately by the victim, so MFA challenge failures will not trigger
- Conditional Access policies that do not restrict device-code flow leave this attack path open
- Device registration limits that are too permissive allow rogue devices to accumulate unnoticed
Key Behavioral Indicators
- Successful sign-in events where authenticationProtocol = deviceCode
- Device registration events (Add device) initiated by Device Registration Service shortly after a device-code sign-in
- OriginalTransferMethod = deviceCodeFlow in sign-in logs targeting Device Registration Service
- New inbox rules that move all incoming mail to obscure folders or mark as read/delete
- Sign-ins from unfamiliar geolocations or IP addresses correlated with device-code authentication
- Outbound email volume spikes from a single internal account to external recipients
False Positive Assessment
Medium — device-code sign-ins, device registrations, and inbox rule creation are all legitimate activities in many environments. Effective detection requires correlating these events with each other and with contextual signals such as unfamiliar locations, unmanaged devices, and timing relationships rather than alerting on any single event type in isolation.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider reviewing recent Microsoft Entra ID sign-in logs for any successful authentications using the device-code protocol and investigate any that cannot be explained by legitimate business use.
- Consider disabling the OAuth device-code authentication flow via Conditional Access policy for all users except those with a documented business need (e.g., smart TV or conference-room system users).
- If your identity platform supports it, consider reviewing and revoking active sessions and refresh tokens for any accounts that show signs of compromise (device-code sign-in from unfamiliar location followed by device registration or inbox rule changes).
- Consider auditing recently created inbox rules across Microsoft 365 mailboxes for rules that move email to obscure folders, mark as read, or delete items, especially if created after a device-code sign-in event.
Infrastructure Hardening
- Consider enforcing named-location policies in Microsoft Entra ID to restrict sign-ins to expected geographic regions and flag atypical travel.
- Evaluate whether enabling Continuous Access Evaluation and token protection is feasible for your environment to reduce the lifetime and portability of stolen tokens.
- Consider lowering the per-user device registration limit in Entra ID so that a fleet of rogue devices cannot accumulate under a single account unnoticed.
- If supported by your email security gateway, consider adding the impersonation domains and phishing endpoints identified in this report to block lists, and evaluate whether your URL filtering covers Google Sites pages with suspicious paths.
User Protection
- Consider rolling out phishing-resistant MFA methods (e.g., FIDO2 hardware keys) where supported, as these are not vulnerable to device-code phishing or adversary-in-the-middle attacks.
- Consider requiring managed and compliant devices for access to email and corporate data via Conditional Access policy to prevent token use from unmanaged or attacker-controlled systems.
- If applicable, consider restricting who can register devices in Entra ID to reduce the risk of rogue device enrollment following a successful token theft.
Security Awareness
- Consider adding device-code phishing to existing security awareness training, emphasizing that an unexpected request to enter or read out a code is a red flag regardless of the apparent source.
- Consider providing users with a simple, well-known reporting mechanism (e.g., a 'Report Phishing' button) so they can flag suspicious code requests quickly.
- Consider briefing users on the social engineering pattern observed in this campaign — extended email conversations to build rapport before delivering a malicious link — as this is increasingly common and harder to recognize than unsolicited phishing.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping10 techniques
Tactic
Resource Development
Tactic
Initial Access
Tactic
Execution
Tactic
Persistence
Tactic
Stealth
Tactic
Credential Access
Tactic
Lateral Movement
Additional IOCs
- Urls:
sites.google.com/view/businessprofileoverview- Google Sites lure page used as initial landing page for device-code phishing, abusing a trusted host to evade URL reputation blockingsites.google.com/view/corporateprofiledetails- Google Sites lure page displaying fake document-sharing portal with device code for victim to enter at Microsoft sign-insites.google.com/view/profileportfoliodetailsdata- Google Sites lure page used in device-code phishing campaign, displaying fake document-sharing notificationeusei.com/dir/redirects.php- Compromised legitimate website used as open redirector to bounce victim from Google Sites to final phishing page while hiding the real destinationcineuropa.org/nll.aspx- Compromised legitimate website used as open redirector in the device-code phishing redirect chainzrdesignlabo.com/st-manager/click/track- Compromised legitimate website used as open redirector in the device-code phishing redirect chain
Related
Stay currentSubscribe via RSS
