Compromised Vendor M365 Account Issues Fraudulent Banking-Change Instructions Across Four Mailboxes

There was no lookalike domain. No attacker-registered infrastructure. No malicious link. No suspicious attachment. The email came from a California-based industrial supplier the recipient organization had a real, established vendor relationship with. The sender passed SPF, DKIM, and DMARC on Microsoft's outbound infrastructure.

The attacker did not need any of those things. They already owned the vendor's M365 account.

Three Days, Four Mailboxes, One Ask: Update the Banking Information

The campaign ran across three days in May 2025. The opening message had the subject line "Payment Update." Follow-ups arrived under "Payment Status" and then "Ach/wire." Each message came from the same legitimate vendor email address, signed by a real contact name associated with the account.

The content was consistent across the thread: the vendor was requesting confirmation of "updated banking information" and was asking the recipient to arrange payment "asap." No sense of emergency or pressure language that would trip a phishing awareness training rule. Just a normal accounts payable request phrased in the way vendors actually write.

Four mailboxes at the target organization received some version of this campaign. The target organization is a specialty ingredients manufacturer with a high-volume AP operation. The vendor is an industrial supplies company with a long-established relationship with that organization. From the AP clerk's perspective, this was indistinguishable from a legitimate payment-update request from a vendor they regularly pay.

Why Account Takeover Makes This Harder Than Impersonation

Vendor email compromise via account takeover is a harder detection problem than vendor impersonation. In an impersonation scenario, an attacker registers a lookalike domain and spoofs the sender. That domain is new, has no sending history, and can be flagged by age, registration pattern, or header analysis. In an ATO scenario, none of that applies.

The sending domain in this case was registered in 1999 through GoDaddy. It had decades of authenticated sending history. Microsoft's outbound protection signed the messages. The relationship between this vendor and the target manufacturer was real. A gateway checking sender reputation, domain age, and authentication status would pass this message on every dimension.

MITRE ATT&CK T1078 (Valid Accounts) describes this exact scenario: an adversary using compromised credentials to leverage the legitimate access and trusted identity of a real account. The compromise of the vendor's M365 credentials is the initial access event. The banking-change emails are the monetization attempt.

The Behavioral Pattern That Surfaces Without a Technical Artifact

IRONSCALES Adaptive AI detected this campaign and resolved it automatically as phishing with an 83% Themis confidence score. The detection mechanism was not a link scan or attachment hash. There was nothing to scan.

The behavioral signal was the context: a known vendor contact suddenly initiating a payment-detail change request across multiple AP mailboxes in a short window, with follow-up messages under variant subject lines escalating the urgency of confirmation. That pattern (multi-mailbox, payment-change topic, unusual request type for this sender's communication history) is anomalous against the organization's baseline even when every technical indicator is clean.

See Your Risk: Calculate how many threats your SEG is missing

The FBI IC3 2024 report puts BEC losses above $2.9 billion. Payment-diversion BEC, where attackers intercept or redirect legitimate AP payment processes, accounts for a significant share of that total. The attack in this case was structurally identical to the scenarios the FBI documents as highest-volume loss events.

What Was at Stake and What Stopped It

The target was an AP operation at a specialty manufacturer. The vendor in question was a legitimate, established supplier, meaning real invoices from this account would be paid on normal AP cycles. An attacker who successfully updated the banking information would receive the next payment run made to this vendor account.

There was no external attacker domain to blocklist after the fact. The vendor's M365 account was compromised; the vendor is the victim. Remediation required notifying the vendor that their account had been seized and working with their IT team to revoke attacker sessions and reset credentials, in addition to quarantining the fraudulent messages on the recipient side.

This case illustrates a critical distinction for security teams: the organization that received the fraudulent emails was protected. The vendor whose account was weaponized was the actual breach victim. That vendor's M365 environment needed incident response, not the recipient's.

The Verizon 2026 Data Breach Investigations Report identifies 16% of breaches beginning with phishing as the initial access vector, with a substantial share of those ultimately resulting in account takeover that then enables secondary fraud. This case is that chain in action.

IRONSCALES business email compromise protection and account takeover detection together cover the two sides of this event: protecting the recipient organization from acting on fraudulent payment instructions, and surfacing the ATO-based delivery as a behavioral anomaly even when every authentication signal is clean.

The IBM Cost of a Data Breach 2024 report puts the average cost of a breach at $4.88 million. Payment-diversion fraud that succeeds before detection adds direct financial loss on top of that baseline.

What AP Teams and Security Teams Should Do Differently

Any banking-change request from a vendor, regardless of how trusted that vendor is, should require out-of-band confirmation before action is taken. Call the vendor on a phone number from your existing records, not a number provided in the email. Check whether the request came from a single message or a coordinated multi-mailbox campaign, which is unusual for legitimate vendor communications.

Security teams should also consider their vendor-side exposure: if a vendor account that regularly sends your organization invoices is compromised, the attacker now has a trusted delivery channel into your AP team. Threat intelligence sharing with key vendors and monitoring for unusual payment-context messages from long-established sender relationships are both warranted.

Indicators From the Compromised Vendor Account

---

Sources: FBI IC3 2024 Report | Verizon DBIR 2026 | IBM Cost of a Data Breach 2024 | MITRE ATT&CK T1566.001 | CISA Phishing Guidance