One click on a fake “PTO Request Denied” notice was enough. According to the TrendAI Security Blog Vision One MDR write-up published 2026-08-14, a finance user followed a personalized HR-themed 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 were completed in real time through that proxy, the post-auth session cookie was stolen, and attackers replayed it from commercial VPN infrastructure for roughly 30 days of cloud-only BEC against mail, a shared AP mailbox, and SharePoint, with no malware on the endpoint.
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.
How a PTO lure finished a real Microsoft 365 login
The lure looked like internal HR work, not a random invoice scam. Display-name spoofing and a legitimate SendGrid sending path got the message into the workflow a finance user already trusted. The click did not land on a static fake form that only harvested a password. It bounced through multi-hop redirects into a live proxy aimed at Microsoft 365.
From the user’s point of view the login ceremony looked normal. Username, password, then the second factor they always approve. The proxy completed that ceremony against the real Microsoft flow and captured what mattered next: the authenticated session cookie issued after MFA had already been satisfied.
That is the mechanical failure of phishable MFA in this incident. Push approvals and OTP codes are transferable proofs. They can be typed or tapped inside an attacker-controlled page that is silently talking to the real IdP. The factor fires. The victim path authenticates. The attacker holds the session the IdP just minted.
TrendAI’s reporting is blunt on the outcome of that single click: it set off the AiTM relay that captured not just the password but the authenticated Microsoft 365 session itself. Host forensics later found no infostealer, no RAT, and no endpoint lateral movement. The entire intrusion stayed on the identity and email plane.
| Control | What happened here | Why it failed |
|---|---|---|
| Password | Entered on proxied login | Relayable secret |
| Push / OTP MFA | Completed through AiTM proxy | Transferable factor, not origin-bound |
| Session cookie | Stolen post-auth and replayed | Unbound token, no new challenge |
| Conditional Access / Token Protection | Not applied / unbound | Replay from VPN IPs still worked |
What unbound session replay unlocked without another login
Once the cookie left the proxy, authentication was already in the past. The attacker replayed the Microsoft 365 session from commercial VPN infrastructure. Telemetry showed atypical and impossible-travel patterns, including jumps such as Amsterdam then Los Angeles about a minute apart. Sign-in views reflected single-factor behavior with MFA previously satisfied. Token Protection was unbound. Conditional Access was not applied in a way that stopped the replay.
No second MFA prompt appeared for Exchange Online, the shared accounts payable mailbox, SharePoint, or Graph-equivalent access the stolen session already authorized. That is normal SSO blast radius, not a clever extra exploit. One cloud session is a skeleton key across the apps federated to the same identity plane. Mail, files, and shared mailboxes do not each demand a fresh hardware-bound proof when the browser already holds a trusted cookie.
That design collides with zero-trust language. “Never trust, always verify” at each access boundary is the opposite of auto-carrying one post-login cookie across the productivity suite. Here the verify step had already happened on the proxied path. Everything after that rode a reusable token.
Stopping the AiTM kit is an authentication problem. Stopping an already-issued unbound cookie is a token-binding and session-hygiene problem. Shorter token lifetimes would not have prevented the theft. They only shrink the window unless the attacker re-steals or registers lasting access. In this case the operators did not need malware to stay useful. They needed the session and mailbox control.
Three inbox rules and roughly thirty days of payment diversion
With mailbox access established, the operators planted three malicious inbox rules. Those rules auto-archived and marked messages as read around vendor collection and related internal threads, and investigators also saw MoveToDeletedItems, SoftDelete, and HardDelete activity. Concealment lived inside Exchange, not on a compromised laptop.
The first fraud wave used vendor impersonation from free webmail into the shared AP mailbox. On the order of eleven email exchanges over roughly three weeks referenced about twenty genuine outstanding invoice numbers. The thread pushed ACH conversion and attacker-controlled banking details. A second wave moved into internal and organization look-alike-domain impersonation to corroborate the banking-detail change. Public detail on that second wave is truncated in the available write-up, so the precise domain craft is not fully spelled out. What is clear is the business goal: divert ACH and vendor payments to accounts the attackers controlled.
The operation ran on the order of thirty days from the phishing click through the last observed adversary action. Exact payment amounts diverted and the full count of affected parties were not disclosed. The victim organization is unnamed in the public MDR case. What TrendAI did document is enough for defenders: cloud-only BEC, multi-week dwell on a stolen session, shared AP mailbox and SharePoint touchpoints, and fraud that never required endpoint code execution.
Source recommendations in the same write-up call out Entra ID token protection for device-bound tokens and out-of-band verification for banking-detail changes. Those are residual controls for the post-auth problem. They do not rewrite the opening failure: a phishable login ceremony that an AiTM proxy can complete.
For the authentication-side fix that stops this class of relay before a session is ever issued, and the token-binding work still required afterward, see where phishing-resistant MFA stops AiTM credential relay and why token protection still matters.
FAQ
Did MFA actually fail in the TrendAI MDR Microsoft 365 BEC case?
Yes, for the initial access path. In the TrendAI MDR AiTM Microsoft 365 BEC case the finance user completed password plus standard push or OTP-style MFA inside an adversary-in-the-middle proxy that relayed those factors to the real Microsoft login in real time. MFA was satisfied on the victim path, and the proxy copied the authenticated session cookie. That is a credential-phase failure of phishable MFA, not a claim that every later cloud action needed a fresh login challenge.
Was there malware or an infostealer on the finance user’s PC?
No. According to TrendAI Vision One MDR, host forensics found no infostealers, RATs, or endpoint lateral movement in this Microsoft 365 BEC investigation. Every stage from initial access through fraud ran against the Microsoft 365 identity and email plane using a stolen session cookie replayed from commercial VPN infrastructure.
Why didn’t Microsoft 365 ask for MFA again when the cookie was replayed?
Because authentication had already completed. In this AiTM Microsoft 365 case the stolen post-auth session showed MFA previously satisfied, Token Protection unbound, and Conditional Access not applied to block the VPN replay. Exchange Online, the shared AP mailbox, and SharePoint accepted the existing session. No MFA product re-challenges every mailbox rule or Graph-equivalent call when the cloud already trusts the cookie.
How long did the attackers keep access, and what did they do with mail?
Attackers remained active on the order of thirty days from the spear-phishing click through the last observed action, per the TrendAI MDR write-up. They created three malicious inbox rules to hide vendor and payment-related threads, accessed a shared accounts payable mailbox and SharePoint, and ran multi-week vendor plus internal impersonation to push ACH and banking-detail changes. Exact diverted amounts were not disclosed.
Would detecting impossible travel alone have fixed this?
Detection of Amsterdam-to-Los Angeles style jumps is useful containment telemetry, not prevention of the harvest. In the TrendAI AiTM Microsoft 365 BEC case those signals appeared because the session was already stolen and replayed from commercial VPNs. Killing cookies after the fact is cleanup. The opening failure was a login the proxy could complete because the second factor was still something a human could approve on a lookalike path.
