When Your Vendor's Email Account Sends You Malware

The attachment cleared every check that email security is supposed to run. SPF passed. DKIM passed. ARC passed. The message came through Microsoft 365, from a vendor this healthcare system had worked with for years, signed by the account that always sends the invoices.

The PDF was flagged malicious anyway.

This is what vendor email compromise looks like when it works. No spoofed domain, no lookalike display name, no forged header for a filter to catch. The attacker did not imitate a trusted sender. The attacker was sending from one. When a large U.S. healthcare system reported the message, the person who found it added the detail that reframes the whole case: they had already called the vendor, and the vendor believed one of their own employees had been hacked.

Authentication Vouched for the Attack

Every signal a gateway leans on to judge a sender said this mail was trustworthy.

SPF passed, because the message really did leave the vendor's authorized Microsoft 365 infrastructure. DKIM passed, because it was cryptographically signed by the vendor's own tenant. ARC passed across the relay chain. Microsoft's composite authentication returned a pass. The sending domain was old, registered more than two decades earlier, with a clean history and a real business behind it.

Here is the distinction that matters. Authentication protocols confirm that a message genuinely came from the domain it claims. They say nothing about whether the contents are safe. SPF, DKIM, and DMARC (Domain-based Message Authentication, Reporting and Conformance) were built to stop forgery, and they are good at it. They were never designed to catch a real account sending a real payload. When the account itself is the weapon, authentication is not a defense. It is a character reference the attacker gets to borrow.

That is the mechanic behind vendor email compromise. It is a specific, nastier branch of the same tree as account takeover: once a criminal controls a legitimate mailbox, everything that mailbox sends inherits its reputation.

The One-Line Body and the Flagged Payload

The email itself was almost nothing. The subject referenced a proposal and a date. The body was a single sentence: a request to see the attached file. Below it sat a complete, accurate signature block, the vendor's real accounts-receivable contact, real address, real phone number, real website. The one link in the message pointed to the vendor's actual homepage and scanned clean.

Everything visible was legitimate, which is precisely why the message read as routine. There was no urgency, no payment demand, no credential lure in the text. Content analysis rated the body as low-risk. A short note with a proposal attached from a known vendor is not suspicious. It is a Tuesday.

The risk lived entirely in the 131 KB PDF. The file carried a malicious verdict from detection, tied to a specific file hash. Its danger was not in what the email said. It was in what the recipient was being asked to open, from someone they had no reason to distrust.

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

Why the Reputation Model Broke Here

Most email security is a trust ledger. Known-good senders get a fast pass. Authenticated domains with clean histories move to the front of the line. It is efficient, and for the volume of legitimate mail organizations receive, it has to be.

Vendor email compromise turns that efficiency into an attack surface. The 2026 Verizon Data Breach Investigations Report found that phishing remains the initial access vector in 16 percent of breaches, and its email gateway telemetry shows that roughly 10 percent of the attacks reaching gateways carry a malware-laden payload rather than a plain phishing link. When that payload rides in on a trusted, fully authenticated sender, the reputation model does not just fail to help. It actively clears the path.

The scale problem is real. The FBI Internet Crime Complaint Center has tracked billions of dollars in losses from business and vendor email compromise, and the reason those attacks pay is that they exploit relationships, not software flaws. The Microsoft Digital Defense Report describes the same shift toward identity-based intrusion, where valid accounts do the work that malware used to. There is no domain to blocklist when the domain is your supplier's.

Detection has to move from "who sent this" to "is this consistent with how they normally behave." This sender was a first-time correspondent to the recipient inside a domain the organization otherwise trusted. The attachment was out of pattern. The behavioral picture did not match the account's history. Themis, the Adaptive AI analyst in the IRONSCALES platform, scored those signals together instead of stopping at the green authentication result, flagged the message with high confidence, and quarantined it across every affected mailbox rather than the single inbox that reported it.

Indicators of Compromise

Values are defanged. The malicious file hash is the durable indicator here; the sending identity belonged to a real, compromised vendor and is described generically.

Mapping the Attack

Two techniques carry this case. The delivery is Spearphishing Attachment (T1566.001): a malicious file sent to a targeted recipient. The reason it worked is Valid Accounts (T1078): the attacker operated a legitimate, authorized mailbox rather than infrastructure of their own. That pairing is what makes VEC so effective. The technique is ordinary. The identity is borrowed and real.

Closing the Vendor Trust Gap

Trusted-sender status should be conditional, not permanent. A vendor you have emailed for years can be compromised tomorrow, and the first sign is usually a message that is slightly off in behavior while being perfectly correct in authentication.

Practical steps for security teams:

• Score behavior, not just authentication. Treat a passing SPF, DKIM, and DMARC result as necessary, never sufficient. Weight first-time-sender anomalies, unusual attachments, and out-of-pattern activity from established contacts.
• Quarantine across the blast radius, not one inbox. One user reported this message. Several others received it. Remediation has to reach every affected mailbox automatically, because the recipients who do not report are the exposure.
• Verify vendor changes out of band. When a trusted account starts sending unexpected files or new payment details, confirm through a phone number or contact you already have, not a reply to the suspect thread. The CISA phishing guidance for network defenders makes the same point about independent verification.
• Block the artifact everywhere. Push the malicious file hash to email and endpoint controls so the same payload cannot arrive through a second door.

The uncomfortable takeaway is that this attack did not beat the defenses. It used them. Authentication confirmed the sender, reputation cleared the domain, and both were technically correct. The only thing that separated a routine proposal from a malware delivery was whether something in the environment was watching how a trusted sender actually behaved, and acting when the answer changed.