How Lexfo uncovered dual MFA-bypass phishing for Microsoft 365

The French company Lexfo discovered three active phishing campaigns against Microsoft 365 after taking advantage of one operator’s mistake: they had left a Python web server with open directory listing on the attack server. The campaigns used two fundamentally different methods of bypassing multi-factor authentication — session proxying via Evilginx and abuse of the legitimate OAuth device code flow. Critically, these two vectors require different defensive measures: FIDO2 keys block the first, but are powerless against the second. Organizations using Microsoft 365 need to review their Conditional Access policies to ensure the device code flow is blocked.

How the infrastructure was uncovered

According to Lexfo researchers, at the end of April 2026, a server at 185.163.204[.]7 (Budapest) was found during routine internet scanning. It was running a Python web server started with the command python3 -m http.server 8080 — the same command was preserved in the .bash_history file. The open directory listing contained phishing configurations, logs of intercepted credentials, installers for remote management tools (RMM), combined password lists, backup archives and the operator’s Telegram session files. On the same host, an Evilginx adversary-in-the-middle proxy and a SimpleHelp remote access console were also running.

Building on this discovery, the researchers identified three separate campaigns, each using its own Evilginx modification cloned from public GitHub repositories. According to Lexfo, the largest of these had been active for more than a year, and about 94% of the compromised accounts belonged to corporate mailboxes.

Two MFA bypass methods

Adversary-in-the-middle via Evilginx

The first method is classic proxying: a modified Evilginx instance intercepts the authentication session between the victim and Microsoft, obtaining session cookies after the user completes MFA themselves. One of the discovered modifications (researchers call it “red-queen”) contained several technical enhancements: renaming of the HTML attributes crossorigin and integrity to evade Subresource Integrity checks, a URL rewrite engine in http_proxy.go to evade path-based detection, as well as pre-filling of the victim’s email address to reduce the abandonment rate.

Particularly notable is that the TTL of the intercepted Microsoft session cookies was set to 31,536,000 seconds (one year). Lexfo estimates that this means an intercepted session can outlive even a password reset and remain active for months — if there is no Continuous Access Evaluation (CAE) policy in place. In the repository, a captured Microsoft 365 cookie was found with an expiration date of June 30, 2027. The same repository contained a precompiled evilginx2.exe binary, allowing the buyer to launch an attack without any build step.

Abusing OAuth device code flow

The second method is fundamentally different and poses a greater threat to organizations that have deployed FIDO2 or passkeys. The third modification (“black-queen”) does not intercept passwords at all. Instead, it exploits a legitimate Microsoft mechanism — the OAuth device code flow, intended for devices without a full input interface.

The attack works as follows: the backend generates a genuine device code, wraps it in a phishing page styled to look like Microsoft Authenticator, and directs the victim to the legitimate microsoft.com/devicelogin page. The victim enters the code, completes real MFA on the genuine Microsoft site and thereby authorizes the attacker’s session. The backend polls the token endpoint and retrieves the token at the moment authentication is completed.

The key point: a FIDO2 key or passkey does not help here, because the victim is authenticating against Microsoft’s real infrastructure. Origin binding, which stops Evilginx, works correctly — since the origin truly belongs to Microsoft. Microsoft documented this technique in February 2025 in the context of the Storm-2372 campaign, which they linked to Russia with moderate confidence. Since then, the technique has spread far beyond state-sponsored operations.

According to Lexfo, the Telegram bot logs for this campaign recorded 218 compromised accounts across about a dozen countries between June 2025 and July 2026. In the git repository history, they found a file with 97 active Microsoft tokens tied to three victims — all with the autoRefresh flag, some refreshed up to 25 times. The framework automatically kept the sessions alive.

Context: ecosystem and scale

All three operators used modifications of the publicly available Evilginx project rather than in-house developments. The researchers found signs of AI being used to develop auxiliary code: two commits by one operator list Claude models as co-authors, while another operator left an instructions.txt file in the repository — a verbatim log of a session with an AI assistant documenting the creation of a URL rewrite function. Microsoft separately documented the use of AI in similar device code phishing campaigns in April 2026.

In June 2026, SOCRadar described a “phishing-as-a-service” ecosystem called The Quarry, which they estimated served around 200 operators. The tools discovered in this investigation appeared in channels associated with this ecosystem, indicating supplier ties, although direct membership cannot be conclusively confirmed.

Practical recommendations

The two attack vectors require two different lines of defense:

• Against Evilginx (AiTM proxying): implement phishing-resistant MFA — FIDO2 keys or passkeys. Binding authentication to the domain renders proxying useless.
• Against device code phishing: block the device code flow via Conditional Access policies everywhere this flow is not needed. Exceptions include Teams Rooms devices and certain CLI tools. Test the policy in report-only mode before enforcing it.
• IP restrictions and CAE: configure location-based Conditional Access policies and enable Continuous Access Evaluation so that a token used from an unapproved IP is re-evaluated instead of remaining valid for its full lifetime.

For detection:

• In Entra ID sign-in logs, monitor issuance of refresh tokens for the Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c, especially if this desktop client is not used in your organization. Correlate with atypical source IP addresses.
• Use the Original transfer method field in sign-in logs: a session initiated via the device code flow retains this label during subsequent token refreshes, even if the current authentication protocol does not display it.
• On endpoints, look for the XEOX agent at C:\Program Files (x86)\XEOX\xeox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog* — this RMM tool was used for persistence.

Indicators of compromise from the report: IP address 185.163.204[.]7, domains picis[.]net and romnor[.]ca. The infrastructure is rotated, so treat these IOCs as scoping aids rather than long-term protection.

The main takeaway from this investigation is not about specific operators but about a systemic issue: an organization fully protected against AiTM phishing through passkeys remains vulnerable to device code phishing if the corresponding authentication flow is not blocked. Verify that you have a Conditional Access policy in place that blocks the device code flow for all users except those who genuinely need it — this one policy closes a vector that not even FIDO2 can stop.