Open Server Exposes M365 Phishing Playbooks

What Researchers Found

An open, misconfigured server left the operational tooling of multiple active phishing operators exposed to anyone who found it. The exposed data included phishing configurations, stolen credentials and tokens, remote management installers, and even the operators' own Telegram session files. This gave defenders an unusually clear window into how corporate Microsoft 365 accounts were being targeted at scale.

How the Attacks Worked

Two distinct techniques stood out among the exposed tooling:

• One operator ran an Evilginx-based adversary-in-the-middle (AiTM) platform, proxying real Microsoft 365 sign-in pages to capture credentials and session cookies, effectively bypassing MFA by stealing an already-authenticated session.
• A separate operation abused Microsoft's OAuth Device Code Flow. In this scheme, the victim completes a legitimate sign-in on a real Microsoft page using a device code, while the attacker's backend silently claims the resulting access token. This campaign ran for over a year and collected 218 confirmed victims across 12 countries, with tokens set to refresh automatically to maintain long-term access.

Researchers also noted signs that generative AI may have been used to help build parts of the phishing tooling and code.

Why It Succeeded

Both techniques succeeded because they exploit trust in legitimate Microsoft infrastructure rather than obviously fake login pages. A device code prompt looks like a normal Microsoft authentication step, and an AiTM proxy presents a real-looking sign-in flow. Victims have little reason to suspect anything is wrong because the page they interact with is genuinely Microsoft's, even though the session or token is being intercepted behind the scenes. This is why MFA alone did not prevent account compromise: attackers were not guessing passwords, they were hijacking sessions and tokens after authentication occurred.

What to Watch For

Employees, executives, finance, HR, and IT teams should treat these signals as red flags:

• An unexpected request to enter a device code to complete a Microsoft sign-in
• Pressure to complete an authentication step you did not initiate
• Sign-in links that arrive unexpectedly, asking you to "re-authenticate" without a clear reason
• Any login flow that feels off, such as repeated prompts or unusual timing, even if the page looks legitimate

Building Resistance

Organizations can reduce exposure by disabling Device Code authentication where it isn't operationally needed and limiting how long tokens and sessions persist without re-verification. Just as important is training staff to recognize that a legitimate-looking Microsoft page does not guarantee a legitimate request behind it. Encourage employees to report unsolicited sign-in or re-authentication prompts immediately rather than completing them, and reinforce that MFA is one layer of defense, not a guarantee against session hijacking or Device Code Flow abuse.

What is OAuth Device Code Flow phishing?

It abuses a legitimate Microsoft feature where the victim signs in on a real Microsoft page using a device code, while the attacker's backend claims the resulting access token in the background.

Can MFA stop this type of attack?

Not on its own. Because attackers capture session tokens or use AiTM proxies, they can bypass MFA entirely by hijacking an already-authenticated session.

How many victims were affected by the Device Code campaign?

The campaign ran for over a year and collected 218 confirmed victims across 12 countries, with roughly 94% of them corporate accounts.

What should organizations do to reduce this risk?

Disable Device Code authentication where it is not needed, limit token and session persistence, and train employees to treat unexpected sign-in or re-authentication requests as suspicious.