A Real Zoom Alert With Fraud Text Grafted Into It

The email was not a forgery. That is the whole story.

It arrived as a Zoom account notification with the subject Your Zoom meeting host key has been changed, sent from Zoom's no-reply address and handed off by Zoom's own outbound mail infrastructure. SPF passed. DKIM passed for the Zoom sending domain. DMARC passed against a policy set to reject, with no percentage carve-out. By every mechanical test a mail system can run, this was a legitimate service message from a vendor the recipients use daily.

Sitting in the visible body, above Zoom's own text, was a paragraph telling the reader that their PayPal account was about to be automatically debited $974.76, and that if this was not them, they should call a number immediately.

Four mailboxes at a single employer got it.

Authentication Was Not the Weak Point Here

The instinct here is to assume something must have failed. Nothing did. At the final hop the message carried an SPF pass, a DMARC pass under a reject policy at full enforcement for the header-from domain, two valid DKIM signatures (one for zoom[.]us, one for a Microsoft 365 default domain that touched the message in transit), an ARC pass, and a composite authentication result of pass with the top reason code.

That is the outcome every organization is told to work toward. DMARC exists to make it meaningful, and the standard it implements, described in RFC 7489, is explicit about its scope: it authenticates domain identifiers. It was never designed to evaluate whether the sentences inside a message are true. NIST's definition of phishing turns on deception of the recipient, not on the provenance of the envelope, and those two things came apart completely here.

A Graft, Not an Impersonation

Underneath the fraudulent paragraph, the genuine Zoom copy ran on unmodified: the standard explanation that a meeting host key, which can be used to claim host for a meeting, had been changed, followed by the usual footer and social links. Both blocks sit in the same body, under the same signature.

The sequencing matters more than the content. DKIM signs a message as it leaves the signing domain. Since the signature for the Zoom domain still verified at the final hop, the fraudulent text was already inside the message when it was signed. This was not a lookalike template dressed up to resemble a notification. It was the real notification with a foreign paragraph carried inside it.

How the attacker got that paragraph into a validly signed automated message could not be determined from the incident record. The most plausible reading is abuse of a recipient-facing field in an account under attacker control that gets echoed back into the notification body, but that mechanism is inference, not a confirmed finding, and there is no evidence that Zoom itself was compromised. What is confirmed is the effect: a trusted vendor's notification pipeline delivered text the vendor never wrote.

The Relay Chain That Laundered It

The delivery path is the second half of the trick. From Zoom's outbound mail server the message went to a mailbox on mail[.]arnilserver[.]com, a Postfix host that resent it using Resent-From and Resent-To headers with sender-rewriting-scheme envelope changes. That domain has no WHOIS record available at all. Its connecting mail server sat at 158[.]69[.]211[.]133.

From there the message was resent to new_batch1@rssethiopia[.]onmicrosoft[.]com, a default Microsoft 365 tenant address, and only then did it cross tenants into the target organization's mailboxes. The recipient name is the interesting artifact: a mailbox called new_batch1 on what appears to be a small, legitimate tenant reads like a mass-list batching operation running on borrowed infrastructure rather than anything an attacker stood up.

Nothing in that chain lands on the blocklist side of the ledger. The originating brand is one no business can afford to reject, one relay hop has no registration data to reputation-score, and the other is a Microsoft-owned namespace shared with every tenant in it. The links in the body were all benign: Zoom's real social profiles, Zoom's blog, and Microsoft's generic sender-verification help pages. No credential-harvesting URL, no attachment, nothing to detonate.

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

The Payload Was a Phone Number

Strip the infrastructure away and this is vishing delivered by email, the pattern usually called telephone-oriented attack delivery. The dollar figure is specific enough to feel like a real transaction and large enough to provoke a reaction. The instruction is to call, not to click, which moves the rest of the attack onto a channel with no logging, no URL to sandbox, and no attachment to scan. Everything a gateway inspects was deliberately left out.

It works because it borrows a real relationship. The 2024 Verizon Data Breach Investigations Report put the human element in 68% of breaches, and CISA's phishing guidance makes the same point from the defender's side: the decisive moment is a person acting on a message, which is why artifact-only controls leave the real attack surface untouched.

Themis, the IRONSCALES agentic AI SOC analyst, scored the message as a credential-theft attempt at 57% confidence. The signal was not the sender, which was impeccable, but the contradiction: a Zoom infrastructure notification whose body raised an unrelated payment dispute and supplied an unfamiliar callback number. Adaptive AI that models what a given sender normally says to a given recipient can score that mismatch while every authentication check stays green.

The response beat is worth flagging too. Of the four affected mailboxes, only one mitigation completed cleanly as a quarantine. The other three returned an error status, so the message stayed reachable in most of the mailboxes it reached. A partial cleanup on a callback lure is a live risk for as long as the phone number keeps ringing.

Indicators of Compromise

MITRE ATT&CK Mapping

The delivery maps to Phishing (T1566), and the callback mechanic to Spearphishing Voice (T1566.004), since the email exists only to move the victim onto a phone call. Riding a genuine vendor notification also fits Impersonation (T1656), with the twist that no impersonation artifact was manufactured. The attacker used the brand's own authenticated voice.

What This Changes for Defenders

Stop treating an authentication pass as a trust verdict. Keep enforcing SPF, DKIM, and DMARC, because they close off spoofing, and spoofing is exactly what this attacker did not need. A clean pass answers only "did this leave the domain it claims," which here is yes, and irrelevant.

Inspect the body of trusted notifications, not just their headers. Automated service mail is the least-read and most-trusted content in most inboxes. A notification that mixes two unrelated topics, one of them a payment dispute, is anomalous on its face, but spotting that requires a model of what the sender normally sends.

Treat any inbound phone number as an indicator. Callback lures leave almost no technical residue, so the number is often the only durable artifact worth blocking, sharing, and hunting for across the rest of the mail flow.

Verify that mitigation actually finished. A quarantine that errors out silently is the same as no quarantine, and when the payload is a live phone line, the exposure window is whoever calls first.

The sending infrastructure offered nothing to act on. No forged domain, no fresh registration at the origin, no malicious URL, no attachment. The only thing wrong with this email was what it said, which makes content and context, not provenance, the entire detection surface.