Multi-factor authentication is meant to stop stolen-password attacks. A newly documented phishing technique instead persuades users to approve a real Microsoft sign-in, allowing attackers to take over the resulting Microsoft 365 session without directly stealing credentials.
The campaign abuses the OAuth device-code flow, a feature intended for devices such as smart TVs and meeting-room systems that cannot easily display a normal login page.
Attackers send a code through a convincing document-sharing or account-verification lure, then wait for the victim to enter it on Microsoft’s genuine sign-in page.
Trend Micro said in a report shared with Cyber Security News (CSN) that the technique turns a legitimate convenience feature into an MFA bypass.
Researchers found that victims can complete their password and MFA checks correctly, but the approved session tokens are delivered to the attacker’s system instead of a trusted device.
The impact can extend well beyond one login. After gaining access, operators may register rogue devices, create inbox rules that hide messages, and use the compromised mailbox to reach hundreds of additional recipients, making the incident difficult to spot with endpoint-focused tools alone.
Readers can also review how a Microsoft 365 device code campaign uses similar approval-based deception.
Hackers Let Victims Complete MFA
In a normal device-code sign-in, a device requests a short code and the user enters it on another screen to approve access.
Microsoft then gives the session tokens to the same device that initiated the request, keeping the user and device connected in one legitimate process.
The attackers break that connection by acting as the device. Their server requests a valid, short-lived code, while a phishing message tells the victim to use it to open a shared document or verify an account.
The victim visits Microsoft, enters the code, signs in, and completes MFA without seeing a fake password page.
Once approval is complete, Microsoft issues access and refresh tokens to the attacker’s pending request.
Those tokens can open Outlook and other Microsoft 365 resources, while the longer-lived refresh token can preserve access after the victim has closed the browser.
This differs from OAuth device code abuse that focuses solely on password theft, because the attacker is stealing an authenticated session.
The observed operation began with rapport building rather than a single unsolicited email.
An attacker posing as a law-firm partner exchanged friendly messages before sending a link, making the request appear to be part of an existing business conversation.
The visible link text looked familiar, but the route passed through a Google Sites page, compromised open redirectors, and a fake human-check prompt designed to delay automated analysis.
The final page resembled a document portal and instructed the target to enter a displayed verification code at the real Microsoft sign-in page.
Cloud Activity Reveals Intrusion
Investigators said that, in one case, an attacker signed in from abroad within hours of the victim approving the request.
The operator registered several devices, created a hidden mailbox rule to bury replies and bounce messages, then used the mailbox to send further phishing emails to external contacts.
Administrators should treat device-code sign-ins as events requiring explanation, especially where the workflow is not needed.
Authentication Broker activity from an unfamiliar country or unmanaged device, rapid device registrations, unexpected mailbox-rule changes, and impossible-travel alerts can together expose a takeover in progress.
The risk of concealed mail manipulation is also illustrated by hidden mailbox rules.
The most effective preventive step is to disable the OAuth device-code flow wherever the organization does not genuinely require it, while allowing narrow, documented exceptions where necessary.
Organizations should also limit device registration, require managed devices for sensitive data access, apply location-aware controls, and revoke sessions when sign-in risk rises.
User awareness remains essential because the victim is interacting with a genuine Microsoft page.
Staff should regard an unexpected request to enter or read out a code as suspicious and report it immediately, while organizations move toward phishing-resistant MFA methods where possible.
Recent reporting on MFA-protected session theft shows why an approved login should not automatically be treated as a safe login.
Indicators of Compromise (IoCs):-
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
