Phishing-proof MFA 2.0 stops TrendAI AiTM before the cookie

One approved second factor on a fake "PTO Request Denied" page. Roughly thirty days of Microsoft 365 payment fraud. No malware on the laptop.

According to the TrendAI Security Blog Vision One MDR write-up published 2026-08-14, a finance user followed a personalized HR-themed spear-phish that multi-hop redirected through SendGrid into an adversary-in-the-middle proxy posing as the Microsoft 365 login. Password plus standard push or OTP-style MFA completed in real time through that proxy. Operators stole the post-auth session cookie and replayed it from commercial VPN infrastructure against mail, a shared AP mailbox, and SharePoint.

TTL and revoke clean up after the fact. They are not a substitute for refusing the transferable login in the first place.

Why push and OTP finished the PTO login for the wrong party

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.

An adversary-in-the-middle attack is a real-time reverse proxy between the victim and the real identity provider. It captures credentials and one-time factors as they complete, and it receives the authenticated session the identity provider issues. 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.

Push approvals and one-time codes are transferable proofs. They do not bind to the legitimate origin or to a hardware-held private key. They bind to whatever channel can display a code or tap Approve. The finance user proved identity to the page the proxy presented. The proxy forwarded a completed authentication to Microsoft. Microsoft issued a normal cloud session. The attacker copied the cookie. There is no second gate. The login is over.

After that moment, the problem changed character. 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 AP mailbox, SharePoint, and Graph-equivalent access accepted the existing session. No fresh MFA prompt appeared for mailbox rule creation or sustained cloud use.

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.

Shortening session lifetime does not prevent that harvest. It only shrinks how long a stolen cookie remains useful unless the attacker re-steals or plants lasting mailbox control. If the operator registers their own authenticator while the session is live, lifetime limits stop mattering entirely.

For the attack-side walkthrough, see the related post on legacymfa.sucks: how AiTM phishing captured a live Microsoft 365 session for multi-week cloud-only BEC.

How phishing-proof MFA 2.0 keeps the session from issuing at all

Stop the kit at the login it tried to complete. Device-bound credentials use public-key cryptography on enrolled hardware. The private key never leaves the device, never crosses the network, and never appears in a proxy transcript. Each authentication produces a fresh signature origin-bound to the real enterprise identity provider. A lookalike PTO page cannot obtain a valid signature for the legitimate origin. There is no OTP to relay and no push prompt to approve for the wrong client.

Against this TrendAI MDR path, that means the AiTM ceremony dies before a Microsoft 365 session is minted for the attacker. No transferable factor. No replayable cloud cookie from that path. The multi-week BEC never gets its skeleton key from a phishable login. That is prevention of the exact failure TrendAI documented, not another detection rule on sessions that should never have been issued.

Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. That hardens the ceremony this MDR case abused. Phishing-proof MFA 2.0 goes further across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. This case turned on a live proxied login, not helpdesk re-enrolment. The next operator who switches to recovery is why the full lifecycle still matters.

It is not a claim about malware reading memory after a good login already happened. Phishing-proof sign-in ends this path at the door. Session theft by malware on an already signed-in device is a different attack that takes far more effort. Tricking a finance user into a PTO lure scales cheaply, while malware on a machine with a live session takes far more work.

Classic SSO turned one stolen cookie into an AP skeleton key

SSO multiplies damage when the first proof is stolen. Classic federation issues one session many integrated apps trust. Mail, files, and shared AP mailboxes ride the same earlier success. Zero-trust language says never trust, always verify at each access boundary. Classic SSO does the opposite. It auto-signs the user into many workloads from one earlier proof. When that proof was captured through a proxied Microsoft login, the blast radius is the federated surface, not a single inbox.

Bolting more detection onto broken SSO is not the answer. Secure Explicit Sign-On keeps one-tap UX while authenticating each application independently with its own fresh, device-bound signature. No shared reusable federation cookie exists to steal once and replay everywhere. For a Microsoft 365 estate hit by this TrendAI-style harvest, that shrinks blast radius even if some other path later appears.

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. Remove transferable secrets first. Then harden what remains.

Residual risk after the login path is closed is different. A phishing kit then has no usable session to harvest. The remaining way to steal a live token is malware or an infostealer on an endpoint that already holds a legitimate session. Revoke, short lifetimes, continuous access evaluation, inbox-rule hunting, and out-of-band checks before ACH or vendor banking changes remain hygiene for that harder path. They are not equivalent controls to stopping the kit at authentication.

The industry keeps buying better detection for sessions that should never have been issued to a proxy. Stop minting those sessions. Private key on the device. Signature bound to the real origin. The PTO lure becomes an expensive way to capture nothing useful.

If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.

FAQ

Would phishing-proof MFA 2.0 have stopped the TrendAI MDR AiTM Microsoft 365 intrusion at the start?

Yes, at initial access. Private keys never leave enrolled hardware and signatures are origin-bound, so a PTO-themed proxy cannot complete authentication or receive a replayable Microsoft 365 session. Cookie replay after a session is already stolen by malware is a separate residual problem. Prevention keeps that residual path from opening via an AiTM lure.

Would MFA 2.0 have blocked replay of the stolen Microsoft 365 session cookie?

No. In the TrendAI MDR 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 when signatures are origin-bound and the private key stays on device. That would have hardened the Microsoft 365 login this case abused. MFA 2.0 is phishing-proof across the identity lifecycle only when registration, device onboarding, recovery, and decommissioning also forbid phishable factors. This MDR case hit the login wire, not helpdesk recovery. Login-only passkeys with soft enrollment still leave a lifecycle gap.

How does Secure Explicit Sign-On differ from classic SSO here?

SES authenticates each application with its own fresh, device-bound signature instead of issuing one shared session many apps trust. In this case, a single stolen Microsoft 365 cookie became mail, SharePoint, and shared AP-mailbox access without another proof. Classic SSO conflicts with zero-trust verify-at-each-boundary design. SES keeps one-tap UX while removing the reusable federation cookie that became a skeleton key after the AiTM harvest.

What should change first after this PTO AiTM BEC pattern?

Retire transferable push and OTP from interactive Microsoft 365 authentication so a proxy cannot finish MFA and receive the session. Reduce reliance on a single cloud SSO cookie across mail, SharePoint, and shared AP mailboxes by moving toward per-app device-bound proof. Keep Entra ID token protection, Conditional Access against unbound VPN replay, inbox-rule monitoring, and out-of-band ACH verification as containment for residual malware-grade theft, not as the primary answer to a phishable front door.