A single, well-crafted phishing email was all it took to give attackers a foothold inside a finance employee’s Microsoft 365 account, and from there, a working channel to redirect real vendor payments to accounts they controlled. Analysts at TrendAI, who documented the intrusion, say it illustrates how thoroughly criminals can defeat multi-factor authentication without ever installing malware or touching a physical device.

An HR-Themed Lure Built for Believability

The attack began with a message crafted to look like an internal HR notice, claiming the recipient’s paid-time-off request had been denied over “conflicting dates.” The email was personalized with the employee’s actual name, role, and organizational details, a level of tailoring that made it far more convincing than a generic mass-phishing attempt.

Clicking through led the victim across a chain of redirects, starting with a legitimate SendGrid tracking link and passing through several attacker-controlled domains, before landing on a convincing fake Microsoft 365 sign-in page.

Stealing the Session, Not the Password

That fake login page was not a simple credential harvester. It operated as an adversary-in-the-middle, or AiTM, relay, meaning it passed the victim’s real username, password, and MFA approval straight through to the legitimate Microsoft 365 service in real time. Once the login succeeded, the attackers captured the authenticated session cookie generated by that real login.

That cookie became the actual key to the intrusion. Rather than needing to repeatedly steal passwords or defeat MFA prompts, the attackers simply replayed the valid session from commercial VPN infrastructure, appearing to Microsoft 365 as the already-authenticated employee. Investigators later found sign-ins from Amsterdam and Los Angeles roughly a minute apart, a physically impossible travel pattern that gave away the replay, but by then Microsoft 365’s own telemetry showed MFA as previously satisfied, no new challenge issued, and no conditional-access controls triggered.

A Two-Phase Fraud Unfolding Over a Month

With access to Exchange Online, SharePoint, Microsoft 365 Search, and a shared accounts-payable mailbox, the attackers had visibility into real invoices, ongoing payment conversations, and legitimate vendor details, exactly the material needed to make a fraudulent payment request look routine. The actual payment-diversion scheme played out over roughly 30 days in two distinct phases.

• Phase one: The attackers impersonated a vendor’s accounts-payable contact from a free webmail address, referencing around 20 real outstanding invoices, requesting a switch from paper checks to ACH transfers, and supplying fraudulent authorization and tax paperwork. They kept the thread active for more than three weeks with steady follow-ups.
• Phase two: The attackers impersonated a senior accounts-payable colleague using a look-alike domain, sending internal-looking verification messages that pushed several vendor banking updates through the approval process, making the fraudulent request appear independently confirmed from two directions at once.

Covering Their Tracks From Inside the Mailbox

To avoid detection, the attackers created three malicious inbox rules that automatically archived and marked vendor collection notices as read, then blocked further rules from processing those same messages. They also deleted select emails outright, ensuring that overdue-payment notices from the real, legitimate vendor never surfaced where the finance team would see them.

Detection Signals Organizations Should Watch For

TrendAI’s investigation points to several telltale indicators that, taken together, should trigger an immediate response: impossible-travel alerts appearing alongside unexpected mailbox rule changes, unusual authentication token activity without a corresponding new MFA challenge, and email deletions that coincide with vendor payment discussions.

Recommended Defenses

• Enable token protection features where available to bind session tokens to a specific device and reduce the value of a stolen cookie.
• Revoke all active sessions immediately upon any suspected account compromise, rather than relying on a password reset alone.
• Require dual approval plus an out-of-band phone verification, using a previously known and trusted number, before processing any change to vendor payment or banking instructions.
• Adopt phishing-resistant authentication methods, such as hardware security keys, which are far more resistant to AiTM relay techniques than standard push or code-based MFA.
• Audit inbox rules regularly for unexpected auto-archive, auto-read, or auto-delete behavior targeting financial or vendor correspondence.

This incident underscores a shift that security teams need to internalize: multi-factor authentication remains valuable, but it is no longer sufficient on its own once attackers routinely target the authenticated session rather than the credentials that produce it. Business processes around payment changes, not just technical controls, need to assume that an internal-looking email or an already-logged-in account may not be what it appears to be.