Mir0Auth Device Code Phishing: Fake DocuSign PDF, Real Microsoft Sign-In

Mir0Auth sends PDF attachments to fake DocuSign pages, then into Microsoft's real device code sign-in, so the victim's own approval gives the attacker Microsoft 365 access tokens without a password.

Device code phishing is an attack in which the attacker requests a sign-in code from Microsoft and persuades the victim to enter it on Microsoft's genuine device login page, which issues the account's tokens to the attacker's waiting session.

ANY.RUN named Mir0Auth in its roundup of October 2026 attacks, published on 3 November, alongside two other kits built on the same sign-in flow: SkyW4lker, which Threat Watch took apart in October, and GeorgeGinx. Three kits in one monthly roundup is the story: device code phishing has moved from a technique to a product category, and each kit now competes on the lure. Mir0Auth's lure is the document that needs a signature.

How does the Mir0Auth attack work?

ANY.RUN's roundup describes the Mir0Auth chain in one line: a PDF attachment, a fake DocuSign page, then Microsoft's legitimate device code authentication. The steps below combine that description with how the device code flow itself works, as ANY.RUN documents it for earlier kits and as the OAuth device authorization standard defines it.

1. The attacker's server asks Microsoft for a device code, a short code meant for signing in on devices without a keyboard.
2. A phishing email arrives with a PDF attachment presented as a document that needs attention.
3. The PDF leads to a page styled like DocuSign, which shows the code and points the reader to Microsoft's device login page.
4. The victim enters the code on the genuine Microsoft page, signs in and completes MFA.
5. Microsoft issues access and refresh tokens to the session that requested the code, which belongs to the attacker.

Three disguised backend paths

ANY.RUN names three paths in Mir0Auth's traffic, /task_queue.cs, /context.go and /window.rs, and says they are used to request device codes and track sessions. The file extensions mimic source code files, a common way to make request logs look routine. ANY.RUN lists the paths as a group and does not assign a role to each, and it names no Mir0Auth domains.

How do I protect Microsoft 365 from device code phishing?

Block the device code flow for everyone who does not need it. Microsoft Entra Conditional Access has an authentication flows condition that can block device code sign-ins, and Microsoft documents the policy step by step. Most office staff never use it; it exists for devices such as conference room systems and command line tools, which can be listed as exceptions.

Then watch for the ones that still happen. ANY.RUN advises monitoring Microsoft Entra ID logs for unexpected device code authentication, particularly after suspicious emails or document-sharing requests, and correlating those sign-ins with phishing indicators.

What this means for a security team

This section is AegisAI's analysis. For a company on Microsoft 365, the risk is a full mailbox and its files in the hands of someone who never knew the password. From there the usual next steps are invoice fraud and phishing sent from the compromised account to colleagues and partners, which arrives from a trusted sender.

Three questions settle the exposure: is the device code flow blocked for staff who do not need it, would a device code sign-in after an emailed signing request raise an alert, and does the incident playbook revoke sessions and tokens rather than only reset the password.

Why standard controls miss it

This section is AegisAI's analysis. Controls built around stolen passwords look for a fake sign-in page; Mir0Auth sends the victim to a real one. The MFA prompt is genuine and is answered by the genuine user. The attacker's own infrastructure sits behind the fake DocuSign page and three ordinary-looking paths, and ANY.RUN published no domains to block. What remains to judge is the email: a signing request whose real purpose is to put a Microsoft sign-in code in front of the reader.

How AegisAI protects against it

AegisAI has not observed this campaign. The approach below is how it treats a lure of this shape when it arrives by email.

Aegis does not classify infrastructure. It classifies intent. A lure with no attacker-owned infrastructure still has to ask the recipient to do something on the attacker's behalf, and that request is what gets classified, independent of how clean the destination URL is.

When a lure or a compromised session is caught, the response compounds: the message is withheld at classification, copies already delivered are retracted, rewritten links refuse a late visit, the account's outbound and internal mail gets rescanned, and lateral phishing attempts to colleagues are blocked at the same bar rather than treated as a fresh, unrelated message.

See a lure like this investigated How inbound protection works

How AegisAI stops credential phishing, 48 seconds

Recommendations for defenders

• Create a Conditional Access policy that blocks the device code flow for all users, with named exceptions for the devices and accounts that need it.
• Alert on device code sign-ins in Microsoft Entra ID logs, and treat one that follows an emailed signing or document-sharing request as a likely compromise.
• In the incident playbook, revoke sessions and refresh tokens, then review mailbox rules and app consents; a password reset alone does not end token-based access.
• Tell staff that no real document workflow asks them to type a code into a Microsoft sign-in page, and give them one way to report it.
• Hunt proxy and web logs for requests to /task_queue.cs, /context.go and /window.rs on unfamiliar domains, keeping in mind the paths may change.

FAQ