InfoSecBulletin Cybersecurity for mankind
Attackers are using Microsoft’s OAuth 2.0 Device Authorization Grant (device code) flow in a campaign to take control of Microsoft 365 accounts. The attack starts with a fake email that looks like it’s approving a quote from a supplier.
The message has two parts: an HTML file that shows an image using a Content ID (cid) URL, and a JPG image that has a clickable area on top, making the whole image work like a link.
Thousands of MCP Servers Exposed to File Access and Injection Attacks
CERT/CC Alerts to Hidden Admin Backdoor in Tenda Router Firmware
Daily Cyber security update for 6. 07. 2026
“Bad Epoll” 0-Day Vulnerability Allows Root Access on Linux Servers, Android Devices
An AI performed a cyber attack without any human help for the first time
Singapore major data centres, cloud providers could incur fine up to $1m
IBM-managed instance breach exposes personal data of 70,000 in Singapore
Alibaba Reportedly Bans Claude Code for Suspected AI Tool Backdoor
CISA KEV Adds SharePoint RCE CVE-2026-45659 After Active Exploits
Nepal Unveils First “Hall of Fame” for Ethical Hackers
The Content ID values include algorithmically generated id-left/id-right components, which helps the campaign evade simple attachment-scanning heuristics.
When someone clicks the image, they go to a phishing page like ClickFix. The page asks the user to “Review Document” and then creates a code for them 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.
The main part of the kit is the device code value. Device codes are usually used to verify non-browser devices, like command-line apps, smart TVs, or IoT devices, that cannot finish a normal web-based OAuth process.
Reversing Lab found a Microsoft 365 phishing campaign that tricks users. It misuses Microsoft’s real OAuth 2.0 Device Authorization Grant to get into victim accounts.
Microsoft OAuth Device Code Abused
When the victim enters the code into Microsoft’s dialog and proceeds, the attacker’s device gets a Microsoft OAuth token linked to the victim’s account, allowing the attacker to take over the account without getting the password.
The phishing kit uses clever tricks to avoid detection on its landing page. The creators hide invisible characters in words like “Microsoft,” “account,” and “verify” to prevent them from being flagged.
The strange density of these characters helps us identify and is used in YARA signatures to find this kit’s pages.
Another item is a modified Entra ID Security Token Service string found in the device code POST message; shifting the bytes to the left by six bits shows the string.
The mix of URL-safe base64 and the bitshifted artifact gives a YARA detection string with few false positives.
Network-level detection can work too. The campaign shows a unique traffic pattern with three parts: first, visiting the landing page and the Microsoft auth popup, second, the authentication step after entering the code, and third, a steady four-second signal POST from the phishing kit to the attacker’s host.
Two steps for finding hostnames show the attack’s first two parts. Both steps include aka.ms, login.microsoftonline.com, aadcdn.msftauth.net, login.live.com, and browser.events.data.microsoft.com.
Seeing Microsoft login activity from a device at the same time as the four-second signals suggests a security problem and needs quick checking.
Device code phishing is very risky because it misuses a real login method, making it hard to tell good actions from bad ones. Defenders should use YARA rules to find hidden Unicode patterns and the Entra ID piece, watch for the mentioned hostname sequences and regular signals, and teach users to see unexpected device-code requests as suspicious.
Additional technical fixes include rules that limit device code grants, tracking and notifying on unusual OAuth client approvals, and using multi-step verification to lower the worth of a fake token.
