One approved second factor handed attackers a live Microsoft 365 session and roughly thirty days of cloud-only payment fraud with no malware on the endpoint. According to the TrendAI Security Blog Vision One MDR write-up published 2026-08-14, a finance user followed a personalized HR-themed “PTO Request Denied” spear-phishing email that multi-hop redirected through SendGrid into an adversary-in-the-middle proxy posing as the Microsoft 365 login page. Password plus standard push or OTP-style MFA completed in real time through that proxy, the post-auth session cookie was stolen, and operators replayed it from commercial VPN infrastructure against mail, a shared AP mailbox, and SharePoint.
An adversary-in-the-middle attack is a reverse proxy that sits between the victim and the real identity provider, passing credentials and MFA responses live while copying the authenticated session the provider issues. Host forensics found no infostealer, RAT, or endpoint lateral movement. The intrusion stayed on the identity and email plane from first click through last observed action around day 30. Exact payment amounts and the victim organization were not disclosed.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how AiTM phishing captured a live Microsoft 365 session for multi-week cloud-only BEC.
Why standard MFA finished the AiTM login instead of stopping it
The opening failure was a credential-phase problem, not a mystery “after MFA” event. The user typed a password and completed a transferable second factor inside a page the proxy controlled. That proxy talked to the real Microsoft login flow in real time. MFA fired on the victim path. Authentication succeeded. The attacker copied the session the identity provider had just issued.
Push approvals and one-time codes are portable proofs. Anyone who can present them inside the live ceremony satisfies the check. Origin does not bind the factor to the legitimate site the way a hardware-held private key does. TrendAI’s attack overview is explicit: a single click set off the AiTM relay that captured not just the password but the authenticated Microsoft 365 session itself.
After that moment, the problem changed character. The stolen cookie was pure post-authentication theft. Sign-in telemetry showed single-factor behavior with MFA previously satisfied. Token Protection was unbound. Conditional Access was not applied in a way that blocked replay from commercial VPN IPs, including atypical jumps such as Amsterdam then Los Angeles about a minute apart. Exchange Online, the shared accounts payable mailbox, SharePoint, and Graph-equivalent access accepted the existing session. No fresh MFA prompt appeared for mailbox rule creation or sustained cloud use.
That is classic SSO blast radius. One cloud session becomes a skeleton key across every app that trusts the same identity plane. Mail, files, and shared mailboxes do not each demand a new hardware-bound proof when the browser already holds a trusted cookie. Zero-trust language says never trust and always verify at each access boundary. Classic SSO does the opposite: it auto-carries one post-login proof across the suite.
| Phase | What was abused | Did phishable MFA stop it? |
|---|---|---|
| Initial access | Password + push/OTP via AiTM proxy | No; factors were relayed live |
| Cloud access | Stolen unbound session cookie | No; auth already complete |
| Persistence / BEC | Same session + mailbox rules | No; actions rode the token |
Shorter session lifetimes would not have prevented the harvest. They only shrink how long a stolen cookie remains useful unless the attacker re-steals or plants lasting mailbox control. Here the operators planted three malicious inbox rules, ran on the order of eleven vendor-thread exchanges over roughly three weeks referencing about twenty genuine invoices, then continued internal look-alike corroboration. Fraud rode identity, not endpoint code.
What phishing-proof MFA changes before any session cookie exists
Stop the kit from completing a usable login and the session cookie never lands in attacker hands. That is prevention, not detection.
Device-bound MFA 2.0 uses public-key cryptography on the enrolled device. The private key never leaves hardware. The server stores only a public key. Each authentication is a fresh, origin-bound signature for the real enterprise identity provider the user is actually talking to. A lookalike proxy can display a convincing page, but it cannot obtain a signature bound to the legitimate origin, and it never receives a reusable secret it can relay. There is no OTP to type, no push to fatigue, and no central password database to empty.
Against this TrendAI MDR path, that matters at the exact second the finance user would have completed MFA through the proxy. The ceremony the AiTM kit depends on does not complete. No authenticated Microsoft 365 session is minted for the attacker to copy. The multi-week BEC that followed in the real case never gets its skeleton key from a phishable login.
Once a legitimate session already exists on a machine, local malware can still try to steal cookies from the endpoint. MFA 2.0 does not claim to scrub memory on a compromised host. What it removes is the easy remote path: fooling a human into finishing login on a proxied page. Planting malware is a harder problem than sending a PTO-themed lure. That contrast is the prevention claim. Revoke, short lifetimes, and continuous access evaluation remain hygiene for the harder path. They are not a substitute for stopping AiTM harvest at authentication.
When the cloud stack is Microsoft 365-class SSO, closing the login is still not the whole architecture story. A single shared federation cookie multiplies every later mistake across mail, chat, files, and finance workflows. Prefer per-app, device-bound proof so each integration gets its own fresh signature instead of one replayable suite token. Secure Explicit Sign-On keeps one-tap UX while eliminating the shared cookie that turned this intrusion into Exchange, SharePoint, and AP-mailbox access without another challenge. Entra ID token protection, which binds tokens to a device, addresses the post-auth replay problem the MDR team also flagged. That is token binding after a good login, not a second chance for a phishable factor. The prevention-first model keeps the priority straight: remove transferable secrets first, then harden what remains.
| Control | Against AiTM login relay | Against later unbound cookie replay |
|---|---|---|
| Password + push/OTP | Fails; factors relay | N/A; session already issued |
| Passkeys at login only | Stops origin-mismatched relay | Does not bind cloud cookies alone |
| Phishing-proof device-bound MFA | No transferable factor to complete | Does not undo a token already stolen elsewhere |
| Device-bound token protection | Not the login ceremony | Limits replay off the enrolled device |
| Classic SSO cookie | Amplifies any successful login | One token unlocks many apps |
Passkeys and FIDO2 against AiTM credential relay
Passkeys and FIDO2 put a key pair on the device and keep the private key inside hardware. The identity provider challenges the authenticator, and the device returns a signature scoped to the real origin of the login. Industry language calls that phishing-resistant authentication: the login act no longer depends on a code or approval a proxy can forward. On a generic enterprise IdP that only accepts those hardware-bound signatures, an AiTM page that is not the true origin cannot finish a usable ceremony even if the user is tricked into visiting it. That is the mechanical counter to the credential relay TrendAI documented.
Why login-only resistance still leaves an enrollment gap
FIDO2 and passkeys harden authentication. They do not automatically harden every lifecycle stage around it. If enrollment, device onboarding, or recovery still accepts email OTP, SMS, or push, an attacker who controls that channel can register their own authenticator and thereafter produce signatures that look legitimate. This MDR case did not turn on helpdesk re-enrollment; it turned on a live proxied login. The ladder still matters for program design. Phishing-resistant login is stronger than OTP. Phishing-proof MFA 2.0 goes further: no phishable factor at registration, onboarding, authorisation, authentication, or decommissioning. The enrolment path has to match the login cryptography, or the organization rebuilds a soft door beside a hard one.
Key Takeaways for Defenders
- Require origin-bound, device-bound authenticators for Microsoft 365 and every workforce app that can mint a suite-wide session; retire push and OTP as sufficient second factors on those paths.
- Enforce Entra ID token protection (or equivalent device-bound tokens) so a cookie stolen off-device fails replay from VPN infrastructure.
- Treat banking-detail and ACH changes as out-of-band business controls; mailbox access alone must not be enough to reroute payments.
- Prefer per-app explicit device-bound sign-on over one long-lived SSO cookie that unlocks mail, SharePoint, and shared AP mailboxes together.
- Alert on impossible travel and “MFA previously satisfied” single-factor patterns as containment signals, not as the primary control that should have stopped the harvest.
The industry keeps buying detection for sessions that should never have been issued to an attacker. Close the transferable factor at every lifecycle stage, bind what remains to hardware, and the PTO lure stops being a payment-fraud starter kit.
FAQ
Would phishing-proof MFA have stopped the TrendAI MDR AiTM Microsoft 365 intrusion at the start?
Yes, at initial access. In the TrendAI MDR AiTM Microsoft 365 BEC case the finance user completed password plus push or OTP-style MFA inside a proxy that relayed those factors to the real Microsoft login. Phishing-proof, device-bound authentication produces origin-bound signatures from a private key that never leaves hardware, so the proxy cannot complete a usable login or harvest a freshly minted session cookie the way it did with transferable MFA.
Would MFA 2.0 have blocked replay of the stolen Microsoft 365 session cookie?
No. In the TrendAI MDR Microsoft 365 BEC investigation the cookie was stolen after authentication had already succeeded. No MFA product undoes possession of an already-issued unbound session token. Device-bound token protection and session revocation address that residual replay path; they are not the same control as stopping the AiTM login ceremony.
Are passkeys enough to call the whole identity program phishing-proof?
No. Passkeys and FIDO2 are phishing-resistant at the login act because signatures are origin-bound and the private key stays on device. MFA 2.0 is phishing-proof across the identity lifecycle only when registration, device onboarding, recovery, and decommissioning also forbid phishable factors. Login-only passkeys with soft enrollment still allow an attacker who captures the enrollment channel to register their own device.
Why does MFA 2.0 avoid classic SSO for suites like Microsoft 365?
Classic SSO issues one session many apps trust, so a single stolen Microsoft 365 cookie becomes mail, SharePoint, and shared-mailbox access without a new proof, which is what TrendAI MDR observed after the AiTM theft. Secure Explicit Sign-On keeps one-tap user experience but authenticates each application with its own fresh, device-bound signature so no shared federation cookie exists to replay across the suite.
What should security teams deploy beyond stronger login for this BEC pattern?
Security teams responding to AiTM Microsoft 365 BEC patterns should pair phishing-proof device-bound login with Entra ID token protection, Conditional Access that rejects unbound replay from atypical infrastructure, monitoring for malicious inbox rules, and mandatory out-of-band verification before ACH or vendor banking changes. Stronger login stops the harvest; token binding and payment process controls limit damage if a session is ever obtained another way.
