Misconfigured Server Reveals Three Evilginx M365 Phishing Operations

Why it matters

A single misconfigured Python web server (python3 -m http.server 8080 left in .bash_history) exposed three separate Microsoft 365 phishing operations to French security firm Lexfo. The leak matters because it shows how cheaply attackers can stand up MFA-defeating campaigns: two distinct techniques - Evilginx adversary-in-the-middle (AiTM) proxies and abuse of Microsoft’s legitimate OAuth device-code flow - were run by operators who cloned public kits rather than building their own. One operator’s logs recorded 218 captured corporate accounts across a dozen countries over more than a year, and a committed token file held 97 live Microsoft tokens set to auto-refresh.

What happened

Lexfo found an attack server with directory listing enabled, revealing phishing configs, credential-harvesting logs, RMM installers, combolists, and the operator’s own Telegram session files. The bash history and public GitHub repos tied the server to an Egyptian actor tracked as codemado, running an M365 AiTM platform on picis[.]net and a bulk mailer called MaDoO Blaster. Pivoting through the toolkit, Lexfo identified two more operators: mail-argenta (Nigerian, fork “red-queen”) and saroula01 (fork “black-queen”). saroula01’s campaign ran quietly for over a year, logging 218 distinct captured accounts - about 94% corporate mailboxes - between June 2025 and July 2026.

Technical details

The three kits bypass MFA through mechanically different paths. codemado and mail-argenta used Evilginx AiTM proxies that proxy the live Microsoft login and set a one-year TTL (31,536,000 seconds) on stolen session cookies, letting a captured session outlast a password reset unless a CAE-capable Conditional Access policy is enforced. mail-argenta’s fork also rewrites HTML attributes to defeat Subresource Integrity checks and adds URL-rewriting to dodge path-based detection. saroula01’s black-queen instead abuses the legitimate Microsoft device-code OAuth flow: it generates a real device code, wraps it in an Authenticator-themed lure, and has the victim complete sign-in on genuine microsoft.com/devicelogin infrastructure - so MFA is satisfied on real Microsoft pages and even passkeys/FIDO2 do not help. Signs of AI-assisted development appeared across all three, including git commits co-authored by Claude models. The phishing domains picis[.]net and romnor[.]ca were offline when THN checked; 185.163.204[.]7 (Budapest) hosted the Evilginx proxy and a SimpleHelp console.

Defender actions

The two techniques need different fixes. Phishing-resistant MFA (FIDO2/passkeys) still defeats Evilginx by binding sign-in to the real domain, but does NOT stop device-code abuse - for that, the lever is Conditional Access. Block the device-code flow wherever possible (allow only input-constrained hardware like Teams room devices), inventory current use via sign-in logs, and test the policy in report-only mode before enforcing. Layer IP-based location policies and Continuous Access Evaluation so stolen tokens seen from outside allowed ranges are reevaluated. For detection, watch for refresh-token grants from the Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c in Entra sign-in logs, and hunt the Original transfer method field (not just the live auth protocol) since device-code sessions stay tagged on later refreshes. On endpoints, hunt the XEOX RMM agent at C:\Program Files (x86)\XEOX\xeox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog*.