Microsoft 365 AiTM Phishing: Why One Open Directory Exposed Three MFA-Bypass Campaigns

Microsoft 365 AiTM phishing became a more urgent story on July 13, 2026, when Lexfo published a report showing how a single publicly exposed Python HTTP server gave researchers a direct view into three active MFA-bypass campaigns. This was not a vague threat-intelligence summary. It was an operational snapshot with phishing configs, logs, Telegram session files, remote-management tools, and infrastructure links that tied the activity to multiple live operators.

That matters now because the real target was not just a password. It was the authenticated Microsoft 365 session that comes after login. If your team still treats phishing as a problem solved by "we have MFA," you are defending the wrong layer of the workflow.

Key Takeaway: The July 13 Lexfo disclosure matters because it shows how Microsoft 365 phishing has matured into reusable session-theft infrastructure that can bypass ordinary MFA without needing exotic malware.

Why Microsoft 365 AiTM phishing matters now

The freshness gate is clear. The main hook source is Lexfo, published on July 13, 2026. Same-day follow-up reporting from The Hacker News helps with narrative detail, but the reason this story clears the bar today is the public Lexfo disclosure.

What makes the report stronger than a routine phishing write-up is the combination of signals it exposes at once:

• three distinct operators tied together through one exposed entry point
• both AiTM proxying and device-code abuse in active use
• evidence of long-running campaigns, not one disposable kit
• operator tooling built for session theft, token refresh, and post-compromise control

If you run Microsoft 365, that should reset your assumptions a bit. You are not only dealing with fake login pages anymore. You are dealing with operator workflows built to capture the session, preserve access, and keep monetizing the result after the initial click.

This is why the topic belongs beside Hexon's earlier posts on Azure CLI password spray, OAuth app security, help desk identity checks, and account recovery security. The repeated lesson is simple: identity attacks now succeed by finding the easiest trust path around the control you expected to matter most.

Common Mistake: Treating MFA as the finish line. In an AiTM or device-code campaign, the attacker does not need to "break MFA" in the classic sense. They just need to capture or mint a usable session after the user completes it.

What the exposed server actually revealed

Lexfo's report is worth reading because it is unusually concrete. According to the public write-up, one open directory on a Budapest VPS exposed a live phishing operator's stack, including:

• phishing configurations and harvesting logs
• backup archives and combolists
• Telegram session files
• remote-management tooling
• custom Evilginx forks cloned from public GitHub repositories

From that one server, Lexfo pivoted to three separate operators: codemado, mail-argenta, and saroula01. The technical details are interesting, but the operational lesson matters more. Three different attackers were able to run mature Microsoft 365 phishing programs by borrowing the same public framework and customizing just enough around it.

That lowers the barrier sharply.

You should picture this less like a lone expert building a perfect kit from scratch and more like a small ecosystem of operators remixing the same proven infrastructure. One actor used a classic Evilginx adversary-in-the-middle path. Another leaned on device-code flow abuse. Both routes still end at the same business problem: a valid Microsoft 365 session in the wrong hands.

The scale signal defenders should not ignore

One of Lexfo's strongest findings is that one device-code campaign reportedly ran for more than a year and produced 218 confirmed victims across 12 countries. That is not the profile of a sloppy throwaway attack.

The report also describes tokens being refreshed silently in the background. That is the part many teams underweight. The phishing event is only the front door. The lasting damage comes from what the operator can keep doing after the victim thinks the login moment is over.

Key Stat: Lexfo says one observed device-code campaign accumulated 218 confirmed victims across 12 countries, which is a useful reminder that session theft can stay productive long after the original lure disappears.

Why AiTM and device-code abuse are worse than ordinary phishing

You already know what ordinary credential phishing looks like. A user lands on a fake login page, enters a password, maybe types an MFA code, and the attacker reuses those details later.

AiTM phishing changes that flow by sitting between the user and the legitimate service in real time. Microsoft has described this pattern in its own security guidance: the attacker proxies the live authentication process, harvests the resulting session material, and then replays it without needing the victim to keep helping.

AiTM attacks steal the session, not just the secret

That distinction matters because it shifts the defensive priority.

When a password is stolen, you can think in terms of rotation and reset.

When a session token or authenticated cookie is stolen, the attacker may already hold what your systems treat as proof that the login succeeded. That is why Microsoft 365 AiTM phishing often feels like an MFA bypass even when the MFA challenge itself worked exactly as designed.

This is also where token protection in Microsoft Entra becomes strategically important. Microsoft's guidance is explicit that device-bound session controls are meant to reduce token replay, not just improve sign-in hygiene on paper.

Device-code phishing turns a legitimate Microsoft screen into the lure

The device-code branch is especially uncomfortable because the victim may interact with a real Microsoft sign-in surface. The trick is that the code authorizes an attacker-controlled session.

That is a harder behavior problem for users to detect. The page may look normal because it is normal. The fraud sits in why the victim is being asked to enter the code in the first place.

This is why phishing training that focuses only on "spot the fake login page" is too narrow now. Some of the most dangerous Microsoft 365 phishing flows succeed by abusing real infrastructure and legitimate protocols in the wrong context.

Pro Tip: Teach users that an unexpected device-code or verification-code prompt is a security event in its own right, even if the page is genuinely hosted by Microsoft.

What these campaigns reveal about phishing economics in 2026

The bigger story is not only technical. It is economic.

The Lexfo and same-day media reporting show an operator environment where phishing is bundled like a service business:

• lure creation
• delivery infrastructure
• evasion logic
• token capture
• post-compromise management
• remote-management follow-on tooling

That should sound familiar because the same industrialization has already happened in malware, ransomware, and infostealer markets. The difference here is that the product being packaged is identity access.

This is also why the report's references to GitHub-hosted forks matter. Public code, light customization, and a working operator workflow are enough to run attacks that can still beat ordinary Microsoft 365 defenses if the surrounding controls are weak.

For smaller teams, the practical takeaway is uncomfortable but useful: you do not need to be a marquee target to get hit by a campaign like this. Subscription-style phishing infrastructure exists precisely so lower-skill operators can go broader, faster, and cheaper.

The AiTM pattern also overlaps with broader admin and SaaS risk. If an attacker lands in the right mailbox, shared inbox, or admin account, the damage can quickly expand into forwarding rules, invoice fraud, OAuth consent abuse, and downstream account recovery manipulation. That is why this story connects directly to admin access at work and shadow SaaS, not just phishing awareness alone.

What Microsoft 365 admins should do this week

You do not need to solve every token-theft problem today. You do need to tighten the parts of your environment that let a stolen session stay useful.

1. Reframe the threat model around session theft

Start by assuming that a successful phish may hand the attacker an already-authenticated foothold.

That means your response plan should explicitly cover:

• session revocation
• suspicious mailbox-rule review
• OAuth app review
• device-code abuse investigation
• shared mailbox and delegated access review

If your incident checklist still starts and ends with "reset the password," it is incomplete.

2. Prioritize Entra controls that reduce replay value

Microsoft's continuous access evaluation guidance matters here because it improves how quickly access can be reevaluated after a critical event. It is not magic, but it reduces the value of stale sessions compared with static token-lifetime thinking.

At the same time, review whether token protection, Conditional Access, and stronger device trust requirements are available for the roles that matter most in your tenant.

The goal is not only to make sign-in harder. It is to make captured session material less portable.

3. Treat device-code prompts as high-risk workflows

If your users legitimately rely on device-code flows for some apps or devices, define where that is normal and where it is not.

Useful controls include:

• user guidance that unexpected device-code prompts should be reported
• sign-in monitoring for unusual device-code activity
• tighter review of authentication-broker and consent events
• stronger guardrails for privileged accounts that should rarely, if ever, use device-code flows casually

You want the help desk, security lead, or admin owner to recognize when "I was asked to enter a code into Microsoft" is a threat indicator, not a harmless detail.

4. Hunt for post-compromise persistence

After a suspected Microsoft 365 AiTM phishing event, review more than the initial login.

Check for:

• new mailbox rules or hidden forwarding behavior
• suspicious OAuth grants or app consents
• access from unusual browsers or locations
• delegated mailbox changes
• password or MFA resets that follow quickly after sign-in
• admin-role assignments or token-related alerts

Microsoft's token theft playbook is useful supporting context here because it treats session misuse as an investigation problem, not just a sign-in failure.

Key Takeaway: The attacker goal is persistence inside the identity workflow. If you only review the first login event, you may miss the actions that actually monetize the compromise.

The larger lesson: trust now lives in the session

For years, security teams treated the password as the main secret and MFA as the corrective layer. That model is no longer wrong, but it is incomplete.

In modern Microsoft 365 attacks, the more valuable prize is often the validated session. Once the system believes the user is already there, many downstream actions become easier:

• reading or exporting mailbox contents
• setting persistence through forwarding or delegation
• approving connected apps
• browsing sensitive SharePoint or OneDrive material
• staging finance or vendor fraud from a trusted context

That is why the July 13 Lexfo disclosure matters beyond the headline itself. One open directory exposed three active campaigns, but the deeper lesson is about architecture, not operator sloppiness. Phishing has become an identity-access supply chain. Public kits, legitimate authentication flows, and session replay logic now combine into a repeatable business model.

If you are responsible for Microsoft 365, the practical response is straightforward. Stop measuring phishing maturity only by whether MFA is enabled. Start measuring whether your tenant can limit the value, lifetime, and portability of a stolen session once a user inevitably makes one bad click.

Final takeaway

The Microsoft 365 AiTM phishing story on July 13, 2026 is publishable because Lexfo's same-day report gave defenders an unusually clear look at how live MFA-bypass operations actually run.

The most important lesson is not that attackers are creative. It is that the workflow is getting more reusable. One operator mistake exposed three campaigns built on public kits, mixed techniques, and durable session-theft logic. That is exactly the kind of pattern smaller teams cannot afford to dismiss as elite or rare.

If you want a useful response this week, focus on session replay defenses, device-code monitoring, token-aware incident response, and the post-login changes attackers make after they land. The next Microsoft 365 compromise in your environment may not look like a broken password policy at all. It may look like a perfectly valid session being trusted for far too long.