MFA is no longer enough.
The Microsoft 365 phishing of 2026.

If your security posture rests on "we have MFA everywhere," this article is for you. Over the past year, the defining Microsoft 365 threat has shifted from stealing passwords to stealing the session token Microsoft issues after you have successfully authenticated. The attacker never needs your password or your MFA code — because you complete the MFA challenge yourself, on their behalf.

What actually changed

Two techniques went from research curiosity to commodity crime in 2026. In adversary-in-the-middle (AiTM) phishing, the victim is lured to a proxy that sits invisibly between them and the real Microsoft login. Everything looks genuine — the real Microsoft page, the real MFA prompt — but the proxy captures the session token as it passes through. In one concentrated three-day window in April 2026, a single AiTM campaign harvested credentials and session tokens from more than 35,000 users across 13,000 organisations in 26 countries. Every one of those victims was using MFA.

The second, device-code phishing, abuses a legitimate Microsoft feature (the OAuth device authorisation flow). The victim is socially engineered into entering a short code — from what looks like an IT request, a shared document, or a voicemail alert — that silently authorises the attacker's device. By early 2026 this had been packaged into phishing-as-a-service kits and had already reached 340+ Microsoft 365 organisations, with nonprofits, legal services and local government among the most-hit sectors.

Why this matters more in International Geneva

The organisations that make this city particular — NGOs, UN-system bodies, diplomatic missions, foundations — are disproportionately attractive targets. A compromised NGO mailbox is not just an inbox; it is a trusted sender that can phish a partner, a donor, or a government contact. Threat actors know this, and the sector-targeting data bears it out: nonprofits sit near the top of the victim lists for both techniques. The reused-password problem that feeds these campaigns is also amplified by the staff rotation and shared-mailbox culture common to the sector.

What genuinely defends against it

The good news: token-theft phishing is defeatable, but not with the controls most organisations think they already have. The measures that actually work:

• Phishing-resistant MFA (FIDO2 security keys, Windows Hello, or passkeys) for administrators at minimum, ideally all staff. These bind authentication to the real domain, so an AiTM proxy cannot relay it.
• Conditional Access that requires a compliant or managed device, restricts sign-ins by location, and blocks the legacy and device-code flows you don't actually use.
• Token protection and short session lifetimes, so a stolen token expires quickly and can be revoked.
• Sign-in log monitoring by a SOC that watches at 3 a.m. — the behavioural anomalies (impossible travel, a device-code grant, a token used from new infrastructure) are detectable, but only if someone is actually looking.
• Fast revocation and a tested response: when a token is stolen, revoking sessions and forcing re-authentication in minutes is the difference between a near-miss and a breach.

The uncomfortable takeaway

If your last security review concluded "MFA is enabled, we're covered," it is out of date. The question for 2026 is not whether you have MFA, but whether you have phishing-resistant MFA, conditional access, and someone watching the sign-in logs when the attack actually happens — overnight, on a weekend, in a language your staff trust. That is precisely the gap our Geneva SOC exists to close.