An EY Forum Invoice With Someone Else's Bank Details

An accounts payable alias at a mid-size private-sector services company received what presented itself as a reply. The message carried In-Reply-To and References headers, positioning itself as the next turn in an existing thread, under a subject line about EY's Strategic Growth Forum. Two PDFs were attached. The first was an invoice for the forum. The second was a bank confirmation letter, presented under the Ernst & Young LLP name, supplying a full ACH account number and routing number for payment.

Neither attachment contained malware. Both scanned clean. There was exactly one URL in the entire message, and it resolved to the recipient's own corporate website. The whole attack was two documents and a domain that was fifteen days old.

The Lookalike Domain Was Doing All the Work

The sending domain was eystrategicgrowthforum[.]com, registered through a privacy-protection service barely two weeks before the message arrived. It has no relationship to the brand's real apex domain, and nothing belonging to Ernst & Young was compromised, touched, or abused at any point in this case. This is straightforward acquisition of attacker-controlled infrastructure, mapped by MITRE as Acquire Infrastructure: Domains, paired with Phishing: Spearphishing Attachment.

What makes the choice of name effective is that the event is real. EY's Strategic Growth Forum is a genuine, long-running annual program tied to the firm's Entrepreneur Of The Year franchise. An accounts payable clerk who does the responsible thing, pauses on an unfamiliar invoice and searches the event name, finds a legitimate conference with years of history, press coverage, and published speaker lists. The verification step returns a green light for the event while saying nothing at all about the domain that sent the invoice. That gap is the entire design.

The domain also handed the attacker a matching second address. The message went to the AP alias with a copy to an "Accounts Receivable" mailbox on the same lookalike domain, which manufactures the appearance of a billing department without requiring access to one. The threading headers work the same way. They are trivially set by the sender, nothing in the record indicates the attacker ever saw a real conversation, and treating them as evidence of prior contact is a mistake the message is built to invite.

What the Authentication Result Actually Certified

The header block is worth reading closely, because at a glance it looks like a pass.

The sending domain published no SPF record at all, so SPF evaluated to none. It published no DMARC policy either, so DMARC returned none with no action taken. DKIM, however, passed, signed by a cloud-provider selector scoped to the attacker's own domain. The relay chain confirmed the mail genuinely originated from that provider's outbound infrastructure, ARC passed for the handoff into the recipient's tenant, and the composite authentication check passed as well.

Every one of those results is technically correct, and none of them says what a reviewer wants it to say. DKIM proves that a message was signed by whoever controls the sending domain's mail configuration. The attacker registered that domain and stood it up on a mainstream cloud mail platform, so the signature is authentically theirs. A DKIM pass on a lookalike domain is a tautology, not an endorsement. DMARC exists precisely to bind the visible From address to an authenticated identity, and as RFC 7489 sets out, a domain publishing no policy gives receivers no instruction whatsoever. The attacker did not need to defeat alignment. There was nothing to align against.

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

The Second Attachment Was the Payload

The invoice PDF was almost boring by design. Clean scan, no bank details on it at all, and a remittance contact that pointed back to the lookalike domain's accounts mailbox instead of a genuine brand address. Its only job was to establish that money was owed.

The bank confirmation letter did the actual work. Attachment analysis rated it low risk for malware and high risk for payment redirection, which is exactly right: it carried explicit ACH and wire account and routing numbers under a beneficiary name claiming to be the global firm. Its document metadata was the tell. The file had been produced with a generic office drawing tool, the kind of provenance that does not appear on a genuine bank-issued confirmation letter, and no scanner flags a shape and a text box.

Splitting the fraud across two documents is deliberate. The invoice survives scrutiny because it contains nothing suspicious. The letter survives scrutiny because it arrives as supporting documentation for an invoice the reader has already accepted. This is the pretexting pattern the 2024 Verizon Data Breach Investigations Report identifies as the leading social-engineering type, with a median transaction of roughly fifty thousand dollars, and it is the same category the 2023 FBI IC3 Internet Crime Report puts near 2.9 billion dollars in annual reported losses. No malware, no credential harvest, no landing page. Just an instruction about where to send a wire.

The Signals That Were Actually Loud

Themis scored the message at 89% confidence, and the sender-side insight named the reason directly: the return-path domain was newly registered, a pattern with almost no innocent explanation when the domain also carries a global brand's event name. Content and community signals flagged the language pattern independently. The message was resolved automatically and quarantined for the single affected mailbox, and the accounts payable specialist who reported it never had to adjudicate the payment request.

The automated triage bucketed it as spam. The outcome was correct and the label undersold it. Nothing in the word "spam" tells a reviewer that an attachment in the message contains bank routing instructions, and if a rule or a release action had ever moved that message back into the inbox, the recipient would have been reading a payment change request with a clean security verdict attached to it.

What to Change Before the Next Invoice Arrives

Treat any new or altered bank detail as unverified until it is confirmed on a voice call to a number taken from an existing signed contract, never from the document making the request. Score first-time sending domains for known brands on domain age and published sender policy rather than on signature results, because both of the cheap signals in this case were unambiguous while the cryptographic one was misleading. And write the workflow down: CISA's phishing guidance is explicit that procedural controls, not detection alone, are what stop payment fraud, and business email compromise protection has to assume the message will look authenticated, because increasingly it will.

Indicators of Compromise

MITRE ATT&CK Mapping