Device-Code Phishing Turns Legitimate Microsoft Sign-In Into an MFA Bypass

Jul 22, 2026 · Original article ↗

Summary

Attackers trick victims into approving genuine Microsoft device-code sign-ins, giving attackers the resulting tokens. A reported account takeover used the access to register devices, hide mailbox activity, and send more phishing.

Key points

Attackers request a valid Microsoft device code and persuade victims to enter it on the genuine sign-in page, completing MFA while issuing the resulting tokens to the attackers.
In an investigated case, a law-firm impersonation and a document-sharing lure led the victim through trusted hosting and redirect services to a code prompt.
After approval, the attacker signed in from abroad, registered multiple devices, created a hidden inbox rule, and used the compromised mailbox to phish hundreds of external recipients.
The activity took place in the cloud and did not touch the victim’s endpoint, making identity-layer monitoring important.
Suggested signals include device-code sign-ins, unusual Authentication Broker activity, bursts of device registrations, suspicious mailbox rules, and atypical travel.
Recommended defenses include blocking device-code authentication where unnecessary, restricting device registration, using phishing-resistant MFA, and teaching users to distrust unexpected code requests.
The article describes abuse of a legitimate authentication flow, not a software vulnerability.

Article Details

Attack Vectors: Device-code phishing abuses the OAuth 2.0 device authorization grant: an attacker requests a genuine code, persuades a victim to approve it at the real Microsoft sign-in page, and receives the resulting tokens.
The observed campaign used conversational email impersonation and a shared-document lure, then redirected victims through Google Sites pages and open redirects on compromised websites to a credential-harvesting page.
After token acquisition, the attacker registered devices, accessed Microsoft 365 Outlook, created hidden inbox rules, and used a compromised mailbox to send further phishing messages.
Defensive Notes: Block the OAuth device-code flow with Conditional Access where it is not required, using narrow exceptions where necessary.
Train users to treat unexpected requests to enter or read out authentication codes as suspicious and provide a way to report them.
Restrict device registration; require managed and compliant devices for mail and data access; and reduce per-user device limits.
Monitor device-code sign-ins, unfamiliar Authentication Broker activity, unusual device-registration spikes, suspicious mailbox-rule changes, and atypical travel or sign-in locations.
Use named-location policies, Continuous Access Evaluation, token protection, and automatic session revocation when risk rises.
Use phishing-resistant MFA and web-reputation or URL-filtering controls; the article reports TrendAI Vision One detected the phishing URLs under HTML.Phish.Microsoft.

Indicators of compromise

Type	Indicator	Context
DOMAIN	`cholaw-kr[.]co`	Sender/impersonation domain identified in the phishing activity.
DOMAIN	`rlcounsel[.]com`	Sender/impersonation domain identified in the phishing activity.
DOMAIN	`up88qope1z[.]hlpadditives[.]com`	Phishing endpoint identified in the attack.
DOMAIN	`zr6dgshpvf[.]flosli[.]com`	Phishing endpoint identified in the attack.
HOSTNAME	`profileupdate-collaboration[.]stefan-dufva[.]workers[.]dev`	Phishing endpoint identified in the attack.
IPV4	`104[.]219[.]238[.]253`	Attacker IP address listed among indicators for the activity.
IPV4	`18[.]118[.]111[.]82`	Attacker IP address listed among indicators for the activity.
IPV4	`40[.]124[.]130[.]50`	Attacker IP address listed among indicators for the activity.
IPV4	`43[.]165[.]1[.]42`	Attacker IP address listed among indicators for the activity.
IPV4	`83[.]136[.]210[.]246`	Attacker IP address listed among indicators for the activity.