Skip to main content
Emerging ThreatsMalware & Ransomware

Evilginx Phishing Ops Expose Microsoft 365 MFA Weaknesses

Cramped server room with laptop and cables in ordinary indoor lighting.

"python3 -m http.server 8080" — a simple command left in a readable .bash_history was the thread Lexfo pulled to untangle three live Microsoft 365 phishing operations.

The exposed server and codemado's toolkit

In late April 2026, a public directory listing on a live attack server at 185.163.204[.]7 in Budapest revealed the full toolkit for an active Microsoft 365 phishing campaign, French security firm Lexfo reported. The listing exposed phishing configurations, credential-harvesting logs, remote management installers, combolists, backup archives and Telegram session files. Behind the host ran an Evilginx adversary-in-the-middle proxy and a SimpleHelp remote console; the server command that enabled directory listing — the one in .bash_history — was the Python one-liner above.

Lexfo attributes that server to an Egyptian actor it tracks as codemado. His platform, running on picis[.]net and monetized via a bulk mailer called MaDoO Blaster, went live April 20, 2026 and remained active after the directory was discovered. Codemado’s bot logged captures against two corporate Microsoft 365 accounts — one French, one North American — and the activity pattern suggests the operator refreshed stolen tokens as they aged out.

Three Evilginx forks, three operators, two technical paths

From the compromised host Lexfo recovered four Evilginx variants cloned from public GitHub. The firm traced three distinct operators and campaigns: codemado himself, plus two other fork authors whose handles the report calls mail-argenta and saroula01. Each ran a custom fork of Evilginx; together they represent three campaigns that use two mechanically different ways to defeat Microsoft 365 protections.

mail-argenta (the report ties this handle to a Nigerian operator) ran a polished fork — labeled red-queen in Lexfo’s analysis — that modifies HTML attributes to defeat Subresource Integrity checks, adds URL-rewriting to evade detections, pre-fills victim email addresses to reduce abandonment, and commits a pre-compiled evilginx2.exe so buyers need not build. That fork also sets a one-year TTL (31,536,000 seconds) on captured Microsoft session cookies; one cookie in the repo carried an expiration date of June 30, 2027.

OAuth device-code abuse: saroula01’s quiet, long-running campaign

By contrast, the black-queen fork (attributed to handle saroula01) never touches passwords. It weaponizes Microsoft’s OAuth device code flow: the attack issues a real device code, presents an Authenticator-themed lure instructing the victim to enter it at the genuine microsoft.com/devicelogin page, and polls the token endpoint until the victim completes sign-in — including any MFA the user must satisfy. The victim signs into a real Microsoft page and clears MFA themselves; the attacker takes the token the moment it is issued.

Lexfo counted 218 distinct captured accounts in saroula01’s Telegram bot logs between June 2025 and July 2026, roughly 94 percent of them corporate mailboxes. A token file briefly committed then removed from the repo remained readable in git history and held 97 live Microsoft tokens set to autoRefresh, some refreshed up to 25 times. Microsoft documented this device-code abuse in February 2025 and assessed a campaign at the time with medium confidence as Russia-aligned; Lexfo shows the technique has spread beyond state-backed actors.

Microsoft 365 defenses: Conditional Access, Continuous Access Evaluation, and FIDO2

The two technical paths require different mitigations. Phishing-resistant MFA (FIDO2, passkeys) prevents reverse-proxy Evilginx attacks by binding sign-ins to the legitimate domain, but it does not block device-code abuse, because the victim completes authentication on Microsoft infrastructure. For device-code threats, Lexfo and Microsoft guidance point to a Conditional Access control: inventory uses of the device code flow, block it where unnecessary, and test in report-only mode before enforcing.

Lexfo recommends layering IP-based Conditional Access location policies and Continuous Access Evaluation so that, on supported Microsoft 365 workloads, a stolen token seen from outside allowed ranges is reevaluated rather than riding out its lifetime. For detection, the report flags monitoring refresh-token grants from the Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c in Entra sign-in logs where that desktop client is not normally used, and hunting on the sign-in’s Original transfer method field rather than only the live authentication protocol.

On endpoints, defenders should hunt for RMM tooling dropped by these operators — Lexfo found codemado’s kit reaches for XEOX, noting the agent at C:\Program Files (x86)\XEOX\xeox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog*.

What this means for technologists, enterprises, and end users

  • Technologists and security teams: treat the device code flow as a distinct attack surface. Implement inventory and Conditional Access controls, monitor Entra logs for the Office client ID activity described, and hunt for XEOX and similar RMM artifacts.
  • Affected enterprises and procurement leaders: expect off‑the‑shelf kits and third‑party marketplaces to supply ready-made phishing frameworks and add-ons; Lexfo found prebuilt binaries and a mailing tool (MaDoO Blaster) promoted in a wider ecosystem called The Quarry, which third-party writeups describe as available to many operators.
  • End users and helpdesk teams: a genuine Microsoft sign-in page can be part of an attack. Users told to enter codes at microsoft.com/devicelogin may still be authorizing an attacker’s session; education and lock-down of device-code use are necessary complements to passkey rollouts.

The core fact is simple and stark: three operators running forks cloned from public repos, aided in places by AI-generated glue code, set up working campaigns with modest effort and low cost. Lexfo concludes the barrier to running this class of attack has fallen near zero and expects these campaigns to become significantly more common in the months ahead. Which organizations will move to block the device-code path — and how quickly — is the near-term question the facts here leave squarely on the table.

Original story — The Hacker News