A Real Zoom Alert, Resent by the Attacker Who Asked for It

The email that reached four mailboxes at a large beverage manufacturer was a real Zoom email. Not a counterfeit, not a lookalike domain, not a display name pasted over a throwaway sending address. Zoom generated it, sent it from Zoom's own transactional infrastructure, and signed it with Zoom's own key under a DMARC policy set to reject. Every authentication check a mail gateway can run on this message came back clean, and every result was correct. The attack was living in the gap between where that alert was created and where it was delivered.

A director of information security at the company reported it as suspicious. By that point all four copies had already been auto-quarantined, within seconds of arrival, and the case closed as phishing.

The Authentication Trail Was Telling the Truth

The subject line was the most ordinary thing imaginable: a code for signing in to Zoom. The sender was no-reply@zoom[.]us with a Zoom display name. The body carried the standard unusual-sign-in notice, a six-digit code, and a metadata table showing the browser as Edge, the operating system as Windows, and the sign-in location as a state in the American west.

The header results read like a textbook pass. SPF passed. DKIM passed with header[.]d=zoom[.]us, signed with the sg selector that belongs to Zoom's SendGrid-based transactional stack, which is the genuine signature Zoom applies to its own notifications. DMARC passed with header[.]from=zoom[.]us against a published policy of p=reject, sp=reject, pct=100, the strictest posture a domain owner can take. Microsoft's composite authentication returned compauth=pass reason=100, its strongest verdict. And ARC passed across four chained seals, i=1 through i=4.

Two details in that trail do not belong to Zoom. Alongside the zoom[.]us signature sat two additional DKIM signatures, one for lo11elodz[.]onmicrosoft[.]com and one for boucheschule[.]onmicrosoft[.]com. Zoom does not sign its transactional mail with Microsoft tenant keys. Those extra signatures are the receipt for a journey nobody was supposed to notice.

A Hop Where No Hop Belongs

The Received chain starts where it should. The first hop is o16[.]sg[.]zoom[.]us at 149[.]72[.]122[.]209, Zoom's own sending infrastructure. The second hop is where the case turns. It is not the target's gateway. It is mail[.]eaeldelicious[.]review at 37[.]60[.]241[.]55, a Postfix instance running on a rented Contabo virtual private server whose reverse DNS resolves to vmi2994063[.]contaboserver[.]net.

That domain was registered roughly two months before this message went out, through a low-cost registrar, sitting on Cloudflare nameservers behind a privacy-redacted registrant record. It is a disposable, purpose-built piece of infrastructure, which maps to MITRE ATT&CK T1583/001, acquire infrastructure by registering domains.

The message was received at that server as mail addressed to info@eaeldelicious[.]review. From there, Resent-From and Resent-To headers push it onward to new_batch32@boucheschule[.]onmicrosoft[.]com, and from that Microsoft 365 tenant it relays through further hops before landing in four mailboxes at the manufacturer. The local part of that forwarding address says out loud what the stage is for. This is a bulk resend queue, and it explains the extra tenant DKIM signatures: each relay signed its own leg, while ARC preserved the original upstream verdicts across the whole chain, which is exactly what ARC was designed to do. Zoom's signature survived, and the injected text rode ahead of the preserved original.

One Paragraph That Zoom Did Not Write

Before the genuine sign-in block, the body opened with a short paragraph in broken English claiming Your authorized USD $985.84 to Zoom using Paypal. If you believe this wasn't you, Call Paypal 1(805) 500-3499. Then the real Zoom notice ran underneath it, untouched.

PayPal never sent anything. No such charge existed. There was no malicious URL anywhere in the message, and the only action link in the body, the genuine unusual-login help page on a Zoom web domain, scanned clean because it really is a Zoom page. No attachment. No QR code. The entire offensive payload was ten digits, which makes this a telephone-oriented attack, the pattern MITRE tracks as T1566/004, spearphishing voice and defenders usually shorthand as vishing.

What makes the construction effective is that the fake content and the real content prop each other up. A recipient reads a payment they never authorized, and directly beneath it, in Zoom's own words and formatting, evidence that someone signed into an account from an unfamiliar browser in an unfamiliar state. The legitimate half lends the fabricated half its credibility, and the fabricated half gives the legitimate half a reason to panic. Presenting yourself as a trusted party this convincingly is T1656, impersonation, and the 2024 Verizon Data Breach Investigations Report puts pretexting of this kind at the top of the social-engineering list, with the human element a component of 68% of breaches.

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

Where the Compromise Actually Sits

The honest answer is that nothing was compromised in any of the places an incident responder would look first. Zoom was not breached. The manufacturer's tenant was not breached. No mailbox rule was altered, no forwarding rule was planted, no credential was harvested, and no account at the target was taken over.

The alert was addressed to and received at info@eaeldelicious[.]review, a mailbox the attacker owns on a domain the attacker registered, which is T1585/002, establishing email accounts as operational infrastructure. The alert was generated for and delivered to a mailbox under the attacker's control, and from there it was rewritten at the top and resent to strangers. That is why the authentication was flawless: there was no forgery to detect. The compromise sits in the relay, in a rented server and a borrowed tenant, entirely outside both organizations, so there is nothing to revoke and nothing to reset at the identity layer. The only attacker-owned artifacts are a two-month-old domain, a VPS address, a forwarding mailbox, and a phone number, and not one of them appears in the From header a recipient reads.

Why Header Reading Was Not Enough

Detection had to come from behavior, because every verdict was green. IRONSCALES Adaptive AI weighed what a suspicious analyst would notice. A per-user sign-in code that arrives simultaneously in four mailboxes at one company is not a per-user sign-in code. A transactional alert from a major platform does not reach a corporate tenant by way of a freshly registered domain on a rented server. A single body does not normally staple together two unrelated pretexts, a disputed payment and a login anomaly. And a notification whose only actionable instruction is to call a number is behaving like a callback scam regardless of how well it authenticates. Themis surfaced it on that pattern, flagging a high-value recipient, and all four copies were quarantined before anyone could dial.

The broader lesson is uncomfortable for any stack that treats authentication as a verdict on safety rather than a statement about provenance. SPF, DKIM, and DMARC answer one question: did this domain authorize this message. Here the answer was an emphatic yes, it was true, and it was irrelevant. CISA guidance on interrupting the phishing attack cycle is blunt about the limits of technical controls when the final step is a human conversation, and the 2023 FBI Internet Crime Report counted roughly $2.9 billion in reported business email compromise losses driven largely by that dynamic. When the payload is a phone call, the mail path is the only forensic surface you get, which is why behavioral analysis has to sit alongside the gateway rather than behind it, and why SEG augmentation exists as a category.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566/004, Phishing: Spearphishing Voice. The fabricated charge existed only to produce a phone call.
• T1656, Impersonation. A genuine Zoom notice repurposed so the attacker inherited both brands' credibility.
• T1583/001, Acquire Infrastructure: Domains. A disposable domain registered behind registrar privacy.
• T1585/002, Establish Accounts: Email Accounts. The attacker-owned mailbox that received the alert before resending it.