Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass
Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass
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.
Emerging Threats: Device Code Phishing Bypasses MFA Protections
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 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 behaviors 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
About Author
