Evilginx Microsoft 365 Phishing Exposes Device Code Risk

Lexfo has published a detailed investigation into three active Microsoft 365 phishing operations built around Evilginx forks, exposed after one operator left a Python directory listing open on a live attack server. The July 13 report matters because it shows two different ways attackers are still getting around ordinary MFA expectations: adversary-in-the-middle token capture and Microsoft OAuth device code flow abuse.^[1]

The first operator, tracked by Lexfo as codemado, exposed phishing configurations, harvesting logs, remote management installers, combo lists, Telegram session files, and cloned Evilginx variants from a server at 185.163.204[.]7. Lexfo says the campaign used picis[.]net, Microsoft 365 lures, a custom anti-bot gateway, and post-compromise tooling including SimpleHelp, ScreenConnect-style installers, SuperOps, GetScreen.me, and XEOX RMM scripts.^[1]

The more durable lesson is not the open directory itself. It is that public phishing frameworks, cheap operator tooling, and AI-assisted glue code have lowered the barrier for working token-theft campaigns. That fits the pattern HowToFix covered in Microsoft’s earlier AiTM phishing warning: a victim can complete what looks like a normal sign-in while the attacker walks away with a usable session.

What Microsoft 365 admins should check now

Lexfo found that the operators were not all using the same method. One Evilginx fork proxied live Microsoft 365 authentication and captured session cookies. Another, called black-queen in the report, abused OAuth device code flow through lures hosted on romnor[.]ca. In that second pattern, the victim enters a real code on the real Microsoft device login page, satisfies MFA on Microsoft infrastructure, and unknowingly authorizes the attacker’s session.^[1]

That distinction matters. FIDO2 keys and passkeys are strong protection against classic reverse-proxy phishing because the sign-in origin is wrong. They do not automatically stop device code flow abuse, because the user is authenticating on the legitimate Microsoft origin. Microsoft’s own Entra guidance calls device code flow a high-risk authentication method and recommends blocking it wherever possible with Conditional Access, allowing it only for documented cases such as specific Teams room or shared-device accounts.^[2]

The practical first step is to inventory whether your tenant actually needs device code flow. Microsoft says administrators can review Entra sign-in logs for Authentication protocol = Device code flow and also check Original transfer method = Device code flow, because protocol tracking can persist into later token refreshes even when the current event no longer looks like a fresh device-code sign-in.^[2] If the flow is not required, create a report-only Conditional Access policy first, validate exceptions, then enforce a block.^[3]

For tenants that do need device code flow, keep exceptions narrow and monitored. A broad exception for users or administrators can become an attacker’s route around stronger MFA. Microsoft recommends scoping exceptions to known device resource accounts, excluding emergency access accounts from lockout-prone policies, and auditing exception membership.^[3] This is similar to the lesson from the recent Azure CLI password-spray campaign: Conditional Access coverage is only as good as the authentication paths it actually governs.

Detection should focus on token behavior, not just suspicious passwords. Lexfo reported 218 confirmed victims in the saroula01 device-code campaign across 12 countries, with about 94% of captured accounts tied to corporate domains, plus deleted-but-recoverable token files in public git history containing Microsoft OAuth tokens configured for automatic refresh.^[1] Microsoft has separately warned that device code phishing can lead to valid access and refresh tokens without password theft, followed by mailbox access, Graph reconnaissance, malicious inbox rules, and data exfiltration.^[4]

Useful checks include unexpected device-code sign-ins, refresh-token activity from unfamiliar IP ranges, Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c where that desktop flow is not normal, new inbox rules, unusual Graph API activity, and remote management tools that appeared after a suspicious login. Lexfo specifically called out XEOX traces such as C:Program Files (x86)OXox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog* for the codemado tooling.^[1]

If a user entered a device code or an account shows suspicious token refreshes, password reset alone is not enough. Revoke refresh tokens and active sessions, review OAuth grants and enterprise applications, remove malicious inbox rules, check mailbox and SharePoint access, and hunt endpoints for RMM persistence. The same token-governance thinking applies to other SaaS incidents, including the Klue Salesforce OAuth breach, where trusted application access became the real blast radius.

There is no single patch for this story. The fix is policy discipline: phishing-resistant MFA for reverse-proxy AiTM, device code flow restrictions for OAuth device-code abuse, Continuous Access Evaluation where supported, and log review that treats refreshed tokens as first-class evidence.

References

1. Lexfo CTI team, “One Misconfigured Server, Three Active Campaigns: Full exposure of three AiTM Phishing Operators,” July 13, 2026. https://blog.lexfo.fr/opendir-to-phishing-operator.html
2. Microsoft Learn, “Conditional Access: Authentication flows,” updated 2026. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
3. Microsoft Learn, “Block authentication flows with Conditional Access policy,” updated April 7, 2026. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows
4. Microsoft Defender Security Research Team, “Inside an AI-enabled device code phishing campaign,” April 6, 2026. https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/
5. The Hacker News, “Misconfigured Server Reveals Three Evilginx Phishing Operations Targeting Microsoft 365,” July 13, 2026. https://thehackernews.com/2026/07/misconfigured-server-reveals-three.html