Phishing
Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass
Device code phishing abuses a legitimate authentication feature designed for devices with limited input capabilities. This article breaks down how the technique works, examines a recent observed case, and outlines the layered security measures organisations can implement.
Save to Folio
Key takeaways
- Device code phishing involves the abuse of the OAuth 2.0 device authorisation grant, a feature built for devices that cannot display a normal login page.
- The victim signs in and approves on the genuine Microsoft page, so no password is stolen, and MFA is satisfied for real. The session is simply issued to the attacker instead of to the user.
- When the attacker targets the Microsoft Authentication Broker, a single approval can be turned into registered rogue devices and long-lived refresh tokens, which means durable access rather than a one-off login.
- The best defences are heightening user awareness, blocking the device-code flow where it is not needed, and using a detection solution that catches the behaviour and keeps watch on the underlying events.
Introduction
For years, the advice to users was simple: turn on multi-factor authentication (MFA), and most account takeovers can be prevented. That advice still holds, and MFA still blocks most password-based attacks. The problem is that attackers adapt, and the more an organisation relies on a single control, the more attention that control attracts.
The first big shift was adversary-in-the-middle phishing, where a proxy site sits between the user and Microsoft and relays the login in real time to capture the session cookie. Device code phishing is the next step, and in some ways, it is cleaner for the attacker. There is no fake login site to build or to get blocked, and there is nothing visually wrong for the user to notice, because the page they enter their password on really is Microsoft. The only unusual thing is a short code and a plausible reason to enter it.
How device code authentication is meant to work
The device authorisation grant exists for a sensible reason. Some devices cannot show a normal sign-in page or do not have a keyboard: smart TVs and conference-room systems are common examples. Instead of typing a password on the device, you are given a short code and asked to finish signing in on a second screen.
In a normal flow, the device asks Microsoft for a code, shows it to you, and you open microsoft.com on your phone or laptop, type the code, and approve. Microsoft then issues the tokens back to the device that requested the code. The important detail is that the device asking for access and the person approving it are the same party, sitting in the same room.
How attackers abuse it
The attack works by breaking that assumption. The attacker plays the role of the input-limited device. They start a genuine device-code request, receive a real Microsoft code, and then trick a victim into approving it. The victim signs in, and the attacker collects the result.
- The attacker’s server starts a device-code sign-in with Microsoft and receives a valid, short-lived code.
- A lure delivers that code to the victim with a believable reason to use it, usually to view a shared document or to verify their account.
- The victim opens the real Microsoft sign-in page, enters the code, signs in, and completes MFA.
- Because the victim approved the attacker’s pending request, Microsoft issues the tokens to the attacker’s server after the MFA requirement has been satisfied.
- The attacker uses those tokens from their own systems, often registering devices, logging on to Microsoft 365 Outlook, and creating mailbox rules so the access survives and stays unnoticed.
Microsoft 365 account takeover case
A recent case shows how polished this has become. The intrusion started not with a single email but with a conversation. The attacker, posing as a partner from a law firm, opened with a friendly note about a possible collaboration and exchanged several messages before ever sending a link. By the time the link arrived, it felt like part of a normal thread.
The link itself was built to survive inspection. The text on screen showed a familiar-looking corporate address, but the real destination was a page hosted on Google Sites, a trusted service that carries a good reputation and is rarely blocked. From there, the victim was bounced through an open redirect on a compromised, legitimate website, with a harmless decoy address in plain sight and the real target tucked into a parameter. The final page sat behind a fake human-check prompt to keep automated scanners away.
The landing page looked like a document-sharing portal. It displayed a verification code and walked the user through entering it at the Microsoft sign-in.
In one of the cases we have investigated, a few hours after the user approved the request, the attacker signed in from abroad, registered a series of devices under the account, created a hidden inbox rule to bury replies and bounce messages, and used the mailbox to send the next wave of phishing to hundreds of external recipients. The endpoint itself was never touched. Everything happened in the cloud, off the victim’s machine, which is part of why this style of attack is hard to detect with endpoint tooling alone.
How to detect device code phishing
Because the attack occurs in the identity layer, that is where the relevant signals can be detected. Useful things to watch for:
- Device-code sign-ins: any sign-in that used the device-code authentication protocol, which should be rare and explainable in most environments.
- Authentication Broker activity: sign-ins to the Microsoft Authentication Broker from an unfamiliar country, network, or unmanaged device.
- Device registration spikes: new device registrations, especially several in a short window or from unfamiliar IP addresses.
- Mailbox rule changes: new inbox rules that move mail to obscure folders, mark it read, or delete it, which is the classic clean-up step after takeover.
- Impossible or atypical travel: successful sign-ins from outside the regions a user normally works in, correlated with the events above.
- How to defend against attacks
No single setting solves this. Treat it as a layered defence, starting with people and reinforced by policy.
- Awareness first. Teach users that an unexpected request to enter or read out a code is a red flag and give them an easy way to report it. An alert user stops the attack before any technical control is tested.
- Block the device-code flow. Disable the OAuth device-code authentication flow with a Conditional Access policy wherever it is not genuinely required. Most organisations can block it broadly and allow narrow exceptions.
- Restrict and monitor devices. Limit who can register devices, require managed and compliant devices for access to mail and data, and lower the per-user device limit so a fleet of rogue devices cannot accumulate unnoticed.
- Tighten identity controls. Enforce named-location policies, enable Continuous Access Evaluation and token protection, and revoke sessions automatically when risk rises.
Conclusion
Device code phishing is a reminder that attackers go after the seams between features, not just the features themselves. Nothing here is a software flaw. It is a legitimate flow, a trusted login page, and a believable story, combined into an attack that quietly sidesteps the one control most organisations lean on. The good news is that it is also very preventable. Blocking the flow where it is not needed, moving to phishing-resistant MFA, and teaching people to distrust unexpected codes will take most of the risk off the table.
Detection with TrendAI Vision One™
At the web layer, the phishing URLs used in this attack are detected by TrendAI Vicion One™ Web Reputation Services as dangerous URLs, with the credential-harvesting page flagged under the detection name HTML.Phish.Microsoft. Blocking these URLs stops the victim from ever reaching the code prompt, which is why web reputation and URL filtering are a useful backstop behind user awareness.
TrendAI Vision One™ Threat Intelligence Hub
TrendAI Vision One™ Threat Intelligence Hub provides the latest insights on emerging threats and threat actors, exclusive strategic reports from TrendAI™ Research, and TrendAI Vision One™ Threat Intelligence Feed in the TrendAI Vision One™ platform.
TrendAI Vision One™ XDR Data Explorer App
TrendAI Vision One™ customers can use the XDR Data Explorer App to match or hunt the malicious indicators mentioned in this blog post with data in their environment.
Where Microsoft Entra ID is integrated with TrendAI Vision One™, the following XDR Data Explorer App queries surface the two events that matter most in this attack. The first returns any successful device-code authorisation, which should be rare and explainable in most environments:
pname: "Microsoft Entra ID" AND authenticationProtocol: deviceCode AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0
The second returns newly registered devices, which is how the attacker turns a single approval into lasting access:
pname: "Microsoft Entra ID" AND eventName: IDENTITY_AAD_DIR_AUDIT AND eventCategory: Device AND actionName: Add device AND initiatedByAppDisplayName: Device Registration Service AND result: success
Although the above filter would detect device registration events, it is expected to have a high rate of legitimate activities. The authentication event on the Device Registration Service resource could be tracked to identify sessions with the original transfer method as device-code flow, which could alert about a device-code token being used to log in to the device registration service. Detection logic as below:
pname: "Microsoft Entra ID" AND eventName: IDENTITY_IAM_SIGN_INS AND status: 0 AND rawDataStr: "\"OriginalTransferMethod":"deviceCodeFlow"" AND targetResourceDisplayName: "Device Registration Service"
These same behaviours are also surfaced natively in TrendAI Vision One™ through Observed Attack Techniques and Workbench detection rules:
- Potential Device Code Token Generation
- Device Registration Resource Access via Device Code Token
MITRE ATT&CK techniques
| Tactic | Technique | ID |
|---|---|---|
| Resource Development | Acquire/Compromise Infrastructure (redirectors, hosting) |
T1583/ |
| Initial Access | Phishing: Spearphishing Link | T1566.002 |
| Credential Access | Multi-Factor Authentication Request Generation (device code) | T1621 |
| Credential Access | Steal Application Access Token | T1528 |
| Defence Evasion/Lateral Movement | Use Alternate Authentication Material: Application Access Token | T1550.001 |
| Persistence | Account Manipulation: Device Registration | T1098.005 |
| Persistence | Account Manipulation/Modify Authentication Process: Multi-Factor Authentication (additional MFA/security info) |
T1098/ |
| Collection | Email Collection; Email Hiding Rules | T1114/ |
| Defense Evasion | Impersonation | T1656 |
Indicators of compromise (IOCs)
Representative indicators from the activity described above. They are shown defanged. Some are shared or legitimate services that the attacker abused, so validate before blocking.
| Type | Indicator |
|---|---|
| Sender/impersonation domains | rlcounsel[.]com , cholaw-kr[.]co |
| Lure pages (trusted host) | sites.google[.]com ; /corporateprofiledetails ; /profileportfoliodetailsdata |
| Open redirectors (compromised) | eusei[.]com ; cineuropa[.]org ; zrdesignlabo[.]com |
| Phishing endpoints | up88qope1z[.]hlpadditives[.]com ; zr6dgshpvf[.]flosli[.]com ; profileupdate-collaboration[.]stefan-dufva[.]workers[.]dev |
| Attacker IP addresses | 104.219.238[.]253 ; 43.165.1[.]42 ; 40.124.130[.]50 ; 18.118.111[.]82 ; 83.136.210[.]246 |
This note is shared to help defenders recognise and stop an active technique. Validate all indicators in your own environment before acting.