Three Live M365 Phish Ops Exposed by Open Server

How the attack worked

Researchers uncovered three separate Microsoft 365 phishing operations after finding a phishing operator's own server left publicly accessible with directory listing enabled. That exposure revealed the toolkit and logs behind the campaigns, letting analysts pivot from one misconfigured server to three distinct operations, each running a custom fork of the open-source Evilginx proxy pulled from public GitHub.

The campaigns used two mechanically different ways to defeat MFA. The first proxies the live Microsoft login page in an adversary-in-the-middle setup, capturing session cookies and tokens as the victim signs in normally. The second abuses Microsoft's OAuth device code flow: a fake Authenticator-themed page generates a real device code and instructs the victim to enter it at the genuine microsoft.com/devicelogin. Because the victim is completing sign-in and MFA on Microsoft's actual page, the flow feels legitimate even though it hands the attacker a valid session.

Why it succeeded

Both techniques succeed because they exploit trust in real Microsoft infrastructure rather than relying solely on a convincing fake page. In the device code scenario, the victim signs in on a real Microsoft page and clears MFA themselves, which removes the usual visual red flags associated with a spoofed login screen. The AiTM method similarly benefits from proxying the genuine login experience, making it harder for a typical user to distinguish from normal authentication.

What to watch for

• An unexpected prompt to re-authenticate when you already recently signed in
• Being asked to enter a device code you did not personally request for a known device or app
• An external page instructing you to complete a login flow you did not start
• Login pages reached through unusual links, subdomains, or unexpected certificate details

How to build resistance

Organizations should recognize that these two techniques do not share a fix. Phishing-resistant MFA options such as FIDO2 or passkeys shut down the AiTM proxy method, but they do not stop device code abuse, which requires separate controls and awareness. Employees, especially those in finance, executive, and IT/identity roles, should be trained to treat unsolicited device codes and unexpected sign-in prompts as suspicious. It's also worth reinforcing that intercepted sessions can outlast a password reset, since stolen tokens and cookies keep working independently of the account password. Combining technical controls with targeted awareness about both fake-login phishing and legitimate-flow abuse gives defenders coverage against the full range of tactics seen in these three campaigns.

How did researchers find these three phishing campaigns?

A phishing operator left a public Python web server with directory listing enabled, exposing its toolkit and logs, which let Lexfo pivot from that one server to identify three separate Microsoft 365 phishing campaigns using custom Evilginx forks.

How do these attacks bypass multi-factor authentication?

One method proxies the live Microsoft login to steal session cookies and tokens, defeating common MFA approaches, while a second abuses Microsoft's OAuth device code flow with an Authenticator-themed lure that directs victims to the real microsoft.com/devicelogin to complete sign-in and MFA themselves.

Does changing my password stop this kind of attack?

Not necessarily. Stolen session tokens and cookies can keep an account accessible even after a password reset, since the attacker already holds an authenticated session rather than just a password.

Does phishing-resistant MFA like FIDO2 or passkeys stop both techniques?

It stops the AiTM proxy technique but does not stop device code abuse, since the two techniques do not share a single fix and require different defenses.