Device Code Phishing Campaign Targets Microsoft 365 Accounts Without Stealing Passwords
ReversingLabs has uncovered an active Device Code phishing campaign that tricks Microsoft 365 users into authorizing attacker devices via legitimate OAuth flows, bypassing password theft entirely.
A new phishing campaign targeting Microsoft 365 users has been uncovered, and it takes a different approach than most attacks seen in the wild. Instead of trying to steal a victim's password directly, this campaign tricks users into completing a real Microsoft authentication process that quietly hands over control of their account to an attacker. It is a convincing technique that is becoming harder for everyday users to recognize.
The method at the center of this campaign is called Device Code phishing. In a normal, legitimate scenario, Microsoft's Device Code flow helps users authenticate on devices where typing a username and password is inconvenient, such as a smart TV or a command-line tool. The attacker here has turned that helpful feature into a trap, using it to authorize their own controlled device to access the victim's account without ever collecting a password.
Analysts at ReversingLabs identified and documented this active campaign, noting that it combines realistic business-themed lure emails, a polished phishing kit, and Microsoft's own Device Authorization Grant flow to carry out a near-invisible account takeover. ReversingLabs researchers said in a report, shared with Cyber Security News, reveals how threat actors have refined this technique to bypass standard defenses and make the attack appear as a routine Microsoft login.
The attack starts with an email that looks like an approval request from a vendor or a business contact. Attached is an image that, when clicked, redirects the victim to a fake landing page mimicking a genuine Microsoft design. From there, the victim is asked to copy a short code and enter it on the real Microsoft device login page. Most people have no reason to suspect anything unusual at this point.
Once the code is entered and the victim signs in, Microsoft's authentication system authorizes the attacker's device. The victim sees nothing out of the ordinary. The attacker now holds a valid access token for that Microsoft 365 account and can use it to read emails, access files, and move laterally inside a target organization.
The phishing kit behind this campaign is built to evade automated detection. The landing pages embed invisible Unicode characters, including Zero Width Space, Word Joiner, and Zero Width Non-Joiner, scattered throughout words that security tools flag as phishing indicators. This makes the pages difficult to catch through standard signature matching. The kit uses a URL hosted on Akamai's legitimate infrastructure as the device login entry point, adding to its appearance of legitimacy.
A POST request is sent from the kit's backend to the phishing host every four seconds, coordinating the OAuth flow between the attacker and the authentication session the victim is completing. This steady beacon is one of the few detectable signs of the attack. The network traffic produced by the kit can also help with detection. Two sequences of hostname resolutions tied to the phishing landing page and the Microsoft authentication flow form identifiable clusters. A third cluster is beacon activity sent every four seconds after the first authentication phase begins, giving security teams a reliable signal to hunt for in their network logs.
ReversingLabs has released a YARA rule to detect the landing pages used by this phishing kit. The rule identifies combinations of invisible Unicode characters alongside encoded authentication token artifacts in page source code. When paired with network-based hunting using the traffic patterns described in the report, defenders have a strong starting point. Organizations should train employees to question any prompt asking them to copy and paste a code into a Microsoft login page. Monitoring Entra ID sign-in logs for Device Code grant usage is recommended, especially where the sign-in originates from an endpoint that is not a known IoT or command-line device.