Image source: Honeybe, Shutterstock
Researchers at Microsoft have documented a clever Phishing-as-a-Service operation that abuses the OAuth 2.0 device code authorization flow to harvest valid session tokens.
Hundreds of organizations have fallen victim to an ongoing phishing campaign exploiting one of Microsoft’s own authentication tools.
The phishing campaign doesn’t rely on stealing passwords or tricking people into handing over verification codes in the traditional sense. Instead, it exploits a sign-in method called device code authentication that is used for logging users into hardware devices, like printers and smart TVs, that don’t have a keyboard or browser for a normal login.
Using Device Codes to Authenticate Attacker Sessions
In a nutshell, the attacker’s use their server to initiate a device authorization request with Microsoft using the victim’s email as a hint. When Microsoft issues a device code in response, the attacker then tricks the victim into pasting the code into Microsoft’s legitimate device login page and unknowingly authenticating their session in the process. Because the victim is authenticating on Microsoft’s own legitimate sign-in page by entering their real password and approving a genuine MFA prompt, none of the standard security measures flag anything as wrong.
Behind the campaign is EvilToken, a phishing-as-a-service platform that essentially packages the attack and makes it available to anyone on a subscription basis.
The Attack Flow
Image source: Microsoft
As Microsoft explained in a report this week, the attack chain begins with targeted victims receiving highly convincing AI-crafted phishing lures that mimic legitimate business workflows such as document sharing or collaboration requests. Users who interact with the payload are routed to a convincing attacker-controlled page that prompts them to continue or verify their identity.
In the background the page triggers a request to the attacker’s back end servers which act as a proxy to Microsoft’s legitimate device authorization service. The attacker’s infrastructure requests a valid device code and associated session identifier in real time using the victim’s email address to pre-populate the sign-in request. The resulting device authentication code pops up on the user’s screen along with a button that directs them to the legitimate microsoft.com/devicelogin page. In some instances, Microsoft observed the attacker’s script automatically copying the code to the victim’s clipboard.
Because the destination is a legitimate Microsoft domain, the flow appears trustworthy. When the user pastes the code and completes the prompt, they unknowingly end up authorizing the authentication request initiated by the attacker. If the user is not already logged in, they might need to enter their credentials and complete MFA to confirm the login request.
Financially Motivated
Microsoft found that once inside, the attackers are selective. They sift through compromised accounts looking specifically for people with financial authority, for instance anyone that manages approves payments, manages vendor relationships, or functions in an executive role. For those targets, they conduct deep searches through email archives hunting for pending wire transfers, outstanding invoices, and sensitive financial correspondence. Hidden inbox rules are quietly installed to intercept and redirect communications, laying the groundwork for fraudulent payment diversions.
Microsoft is urging organizations to disable device code authentication wherever it isn’t strictly necessary, and to replace phone-based multi-factor authentication with hardware security keys or passkeys, which are resistant to this style of attack.
What makes the already clever attack even more dangerous, according to Microsoft, is threat actor’s use of Dynamic Device Code Generation, to bypass the typical 15-minute validity period of any generates OAuth 2.0 device code. In the attacks that Microsoft observed, the attacker’s infrastructure initiated the device code request only after the victim had already clicked on the phishing link.
“In older, static phishing attempts, the threat actor would include a pre-generated code within the email itself,” Microsoft said. “This created a narrow window for success: the targeted user had to be phished, open the email, navigate through various redirects, and complete a multi-step authentication process all before the 15-minute timer lapsed.” Shifting code generation to the final stage of the redirect chain, gives the attackers a substantially greater chance that the code will still be valid when the user pastes it into Microsoft’s device login page.