Hackers Abuse Microsoft OAuth Device Code Flow to Take Over Microsoft 365 Accounts

An active campaign in which attackers are abusing Microsoft’s OAuth 2.0 Device Authorization Grant (device code) flow to take over Microsoft 365 accounts.

Rather than capturing credentials with a fake login page, the threat actors persuade victims to complete a genuine Microsoft authentication process that, unbeknownst to them, authorizes an attacker-controlled “device.” The result: fully authorized access to corporate Microsoft 365 resources without ever stealing a password.

The attack begins with a realistic email lure masquerading as an approval for an estimate from a vendor.

The message uses a two-part attachment technique: an HTML file that references an embedded image via a Content ID (cid) URL, and a JPG lure image that is overlaid with a clickable anchor so the entire image behaves like a link.

The Content ID values include algorithmically generated id-left/id-right components, which helps the campaign evade simple attachment-scanning heuristics.

When a recipient clicks the image, they are directed to a ClickFix-style phishing landing page. The page prompts the user to “Review Document” and then generates a verification code that the victim is instructed to copy.

When the victim clicks the landing page’s “Sign in with Microsoft” button, the site opens a genuine Microsoft device login flow (hxxps://aka[.]ms/devicelogin).

This triggers Microsoft’s real authentication UI: first a code-entry popup, then a prompt for the account username via the Microsoft Authentication Broker, which explicitly refers to “another device.” The UI itself is legitimate, which greatly increases the plausibility of the request.

At the heart of the kit is the device code value. Device codes are normally used to authenticate non-browser devices (for example, command-line apps, smart TVs, or IoT equipment) that cannot complete a standard web-based OAuth flow.

Reversing Lab has discovered an active Microsoft 365 device code phishing campaign that abuses Microsoft’s legitimate OAuth 2.0 Device Authorization Grant flow to obtain access to victim accounts.

Here, the phishing site displays the device code for the victim and coordinates with the attacker’s backend by POSTing the code in a four-second loop.

Microsoft OAuth Device Code Abused

When the victim enters the code into Microsoft’s dialog and proceeds, the attacker’s device receives an Microsoft OAuth token tied to the victim’s account effectively achieving account takeover without any password interception.

The phishing kit employs notable defense-evasion techniques in its landing page HTML. Authors insert invisible Unicode format characters (Zero Width Space, Word Joiner, Zero Width Non-Joiner) into words that would normally trigger detection for example, “Microsoft,” “account,” and “verify.”

The unusual density of these characters is a reliable indicator and is incorporated into YARA signatures used to hunt for this kit’s pages.

Another artifact is a bit-shifted Entra ID Security Token Service string embedded in the device code POST payload; left-shifting the bytes by six bits reveals the string.

The combination of URL-safe base64 and the bitshifted artifact yields a low-false-positive YARA detection string.

Network-level detection is also feasible. The campaign produces a distinctive three-cluster traffic pattern: the initial landing page visit and Microsoft auth popup, the second-phase authentication activity after code entry, and a persistent four-second beaconing POST from the phishing kit to the attacker’s host.

Two hostname resolution sequences characterize the attack’s first two phases, both involving aka.ms, login.microsoftonline.com, aadcdn.msftauth.net, login.live.com and browser.events.data.microsoft.com.

Observing Microsoft authentication activity from an endpoint concurrently with the four-second beaconing is a strong indicator of compromise and warrants immediate investigation.

Device code phishing is especially dangerous because it weaponizes a legitimate authentication mechanism, blurring the line between benign and malicious activity.

Defenders should deploy YARA rules targeting the invisible Unicode pattern and the Entra ID artifact, monitor for the described hostname sequences and periodic beaconing, and educate users to treat unsolicited device-code prompts as suspicious.

Additional technical mitigations include conditional access policies that restrict device code grants, logging and alerting on abnormal OAuth client approvals, and multifactor enforcement that reduces the value of an illicit token.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.