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 organizations can implement. By: Ahmed Elsayed, Ahmed Hussein, Ahmed Kamal, Mahmoud Soheem Jul 22, 2026 Read time: ( words) Save to Folio Key takeaways Device code phishing involves the abuse of the OAuth 2.0 device authorization 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 defenses are heightening user awareness, blocking the device-code flow where it is not needed, and using a detection solution that catches the behavior 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 organization 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 authorization 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. Figure 1. Device-code flow as designed. The device that requests the code is the device that receives the tokens. download 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. Figure 2. The same flow, abused. The attacker requests the code and receives the tokens, while the victim performs the sign-in. download 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. Figure 3. Initial email sent to victim download 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. Figure 4. The delivery chain we observed. Each hop uses a trusted or throwaway service to stay ahead of email and URL filtering. download 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. Figure 5. The lure: a familiar shared-document page on a trusted domain. Nothing downloads, and no warning appears. Figure 6. The hand-off. The page shows a verification code and tells the user to enter it at the real Microsoft sign-in. download 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 defense, 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 organizations 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 organizations 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 Vision 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 authorization, 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 eventCatego