Device Code Phishing Real Threat in Microsoft 365 without Fake Home Pages

Between late June and the first days of July 2026, ZeroBEC researchers described an active phishing campaign that takes advantage of the legitimate flow of Microsoft 365 device authentication to kidnap accounts, using collaborative lures (messages, invitations to shared folders, payment notices) that encourage the victim to introduce a device code provided by the attacker. The threat does not depend on traditional false income pages: it exploits real and reliable functionality, which makes it more difficult to detect by distracted users and controls looking for false login forms.

The technique, known as device code phishing, abuses the standard OAuth 2.0 Device Authorization Grant mechanism, designed for devices with limited interfaces. In practice, an attacker begins the generation of a device code, deceives the victim to enter it on microsoft.com / devilaluation and so authorizes, without knowing, the session controlled by the attacker. Microsoft documents the flow and its properties in its technical guide, which should be read to understand why the process is legitimate and what logs are left after its use: https: / / learn.microsoft.com / en-us / azure / active-directory / develop / v2-oauth2-device-code.

The worrying thing about the findings is the industrialization of the attack. ZeroBEC and other equipment have identified a reusable layer of tools called DEBULL and physical-as-a-service (PhaaS) platforms such as EvilTokens, ARToken or Tycoon that pack from code orchestration to post-engagement panels to maintain persistence, exfilter emails and files, and automate business email compromise (BEC) campaigns through AI. This turns what was before a complex tactic into an accessible service for operators with different skill levels, multiplying the risk and speed of spread.

The implications are severe: overcoming MFA, getting valid tokens without stealing passwords, persistence in Microsoft 365 environments, access to Exchange, OneDrive / SharePoint, and side movement supported by Microsoft Graphh APIs. In addition, the use of accounts already committed to distributing legitimate links makes the messages seem reliable for recipients who trust the sender, facilitating the multiplier effect of the campaigns.

For individual users the most immediate recommendation is simple but critical: never enter device codes that reach you in a mail, chat or call If they're not showing up on the device screen where you try to authenticate. Treat them as a sensitive OTP: if you have not initiated a conscious action on a control device, do not authorize anything and communicate through verified channels with the person who allegedly requests the action.

At the organizational level, priority should be given to mitigating the abuse window and promoting phishing-resistant authentication methods: implementing phishing-resistant authenticators (FIDO2, Windows Hello for Business), requiring devices managed or compliant by Conditional Access, monitoring and investigating session start with the grant type "device _ code" in Azure AD sign-in records and setting up alerts for abnormal patterns (tokens issued from foreign locations or concurrent sessions). It is also recommended to review the exposure of the function if it is not used and to evaluate the blocking or restriction of the Device Authorization Grant to controlled environments. For general guidance on phishing prevention and good practices, CISA offers useful public resources: https: / / www.cisa.gov / publication / phishing.

Detecting and responding requires combining technical signals and processes: correlate authentication records that indicate use of device codes with mail activity and access to SharePoint / OneDrive, block known PhaaS-associated domains and infrastructure, rotate high credentials and apply just-in-time access and minimum privileges. In addition, continuous employee training should include specific examples of this vector and clear verification procedures for access requests or payments that arrive by mail or chat.

Finally, the evolution towards complete BEC panels operated by affiliates and with IA-driven functions stresses that the defense must be proactive and adaptive. Traditional MFA is not enough; phishing-resistant controls, visibility in authentication loops, and detection and response processes that assume that any account can be the starting point of a campaign. The combination of education, tightening of identity policies and operational visibility is the most practical way to reduce the impact of these campaigns.