TL;DR An accounts-payable team received an invoice demanding a same-day $97,500 wire, styled as a reply to an already-approved item. The message passed DKIM and DMARC cleanly, signed by a real federal institution's own mail stream through SendGrid, and Microsoft scored the composite authentication a perfect 100. Nothing cryptographic was ever broken. The fraud lived entirely in a mismatched Reply-To header pointing at an unrelated, freshly provisioned domain, so any reply and payment confirmation would flow to the attacker. A SendGrid open-tracking pixel confirmed the target was live, and a same-day discount deadline supplied the pressure. Authentication proved the domain was controlled, not that the request was legitimate.
Severity: High Bec Impersonation MITRE: T1566 MITRE: T1656 MITRE: T1036.005

An invoice landed in an accounts-payable inbox demanding a same-day payment of $97,500 by ACH or wire. The subject was framed as a reply to something already blessed, the kind of thread a busy finance team scrolls past on its way to acting. And here is the part that should stop you cold: the message passed DKIM. It passed DMARC. Microsoft scored the composite authentication a perfect 100. The cryptographic signature verified against a real federal cultural and research institution's own domain. Nothing in the authentication stack was ever broken, anywhere in the message.

It was still fraud. The entire attack lived in a single header.

The One Header Doing All the Work

The From address belonged to a real staff member at a legitimate institution, and the display name matched. So did the Reply-To display name, character for character. But the Reply-To email address did not point back to the institution. It pointed to mahalaxmitraders@waareepartners[.]com, an unrelated domain that has nothing to do with the sender the message claimed to be.

That is the whole mechanism. A finance clerk who hit reply to ask about the bank details, or to confirm the payment went out, would not be talking to the institution. They would be talking to the attacker, under a display name that still read as the trusted contact. WHOIS on the remittance domain shows a thin, freshly provisioned registration through a mass-market registrar, with no authoritative business records tying it to any real vendor. It exists to catch a reply and nothing else.

This is textbook business email compromise: no malicious link to scan, no attachment to detonate, no credential page. Just an authenticated envelope, a plausible invoice, and a quiet redirect of the conversation.

Authentication Validated the Domain, Not the Request

It is worth being precise about what those passing checks actually proved, because this is where finance teams and tuned mail filters get fooled.

DKIM confirms a message was cryptographically signed by a domain and not altered in transit. DMARC checks that the signing aligns with the domain in the visible From address. When both pass, you know one thing with confidence: the message genuinely came from the domain it claims. In this case they passed because the mail really was signed by the institution's own mail stream, sent through the SendGrid delivery service the institution uses, with DKIM keyed to the institution's domain. SPF returned none only because the envelope sender was SendGrid's outbound host rather than a server listed in the institution's SPF record, which is normal for third-party delivery and exactly why DKIM and DMARC carry the weight.

So this was not a spoof. It was authenticated infrastructure being driven to send a fraudulent message. An attacker who can send through a real domain's authorized mail path inherits that domain's clean authentication posture for free. The signature is valid. The request underneath it is a lie. Treating a passing authentication result as a verdict on legitimacy is precisely how a message like this reaches a person who can move six figures.

The Pixel Was Doing Reconnaissance

The message carried no clickable payload, but it was not silent. Embedded in the body was a SendGrid open-tracking pixel, a one-by-one image that fires a request the moment the email is rendered. For a marketer that is an open rate. For this attacker it was live-target confirmation: proof the mailbox is active, monitored, and worth a follow-up. Paired with a first-time sender that the organization had no prior correspondence with, the pixel turns a cold send into a warm target list. It is reconnaissance disguised as a rendering artifact.

Real Bank Numbers, Fake Urgency, Forged Origin

The rest of the message was built to remove friction. The invoice listed a real bank routing number and SWIFT identifier that resolve to a major US bank, borrowed legitimacy that survives a casual glance, while the beneficiary account itself was unverifiable. The Message-ID was forged to look as if it had originated inside the recipient's own domain, reinforcing the sense that this was an internal, already-handled thread. And the pressure lever was a same-day discount: pay today to lock in a fifty percent reduction. Legitimate vendors rarely tie a five-figure discount to a same-day wire. Attackers reach for that deadline constantly, because it collapses the window in which someone might pick up a phone and verify.

Two Verdicts on One Message

The receiving stack did not agree with itself, and that disagreement is the lesson. The authentication layer, asked only whether the domain was real and aligned, said yes. Our Adaptive AI analyst, Themis, asked a different question, weighing the first-time sender, the Reply-To mismatch, the urgent large-dollar ask, and community reputation signals from similar reports, and flagged the message as phishing. IRONSCALES quarantined it across all four affected mailboxes and auto-resolved the incident. One set of signals reported a spotless pass while another caught the fraud. In a tenant tuned to trust authenticated senders, that clean DKIM and DMARC result is exactly what would have carried this invoice to the inbox unquestioned.

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

What Defenders Should Take From This

Map it to MITRE ATT&CK and it reads as Phishing, T1566 for delivery, Impersonation, T1656 for the method, and Masquerading: Match Legitimate Name or Location, T1036/005 for the display-name reuse in both the From and the Reply-To. The 2026 Verizon Data Breach Investigations Report puts BEC at roughly 3 percent of the gateway attack mix, small in volume and enormous in per-incident cost, and the FBI IC3 2024 Annual Report continues to rank BEC among the costliest categories of cybercrime it tracks. CISA's phishing guidance makes the same point our telemetry does: authentication controls are necessary and insufficient on their own.

Two takeaways. First, stop reading a passing authentication result as a clean bill of health, and build detection that weighs behavioral signals, first-time senders, Reply-To mismatches, tracking pixels, and freshly registered remittance domains alongside the auth verdict rather than deferring to it. That behavioral layer is the core of effective business email compromise protection. Our own platform data underscores the gap: legacy gateways miss roughly 67.5 phishing emails per 100 mailboxes each month. Second, put an out-of-band rule around money. No new or changed bank detail, and no same-day wire, leaves the building on the strength of an email, no matter how cleanly it authenticates or how authoritative the name on it looks. Verify through a known channel, every time. The header is the easiest thing in the message to point somewhere else.

Indicators of Compromise

TypeIndicatorContext
Reply-To addressmahalaxmitraders@waareepartners[.]comUnrelated remittance address; reused the trusted display name to catch replies
Attacker domainwaareepartners[.]comWHOIS-thin, newly provisioned via mass-market registrar; no verifiable business records
Tracking pixelSendGrid open-tracking pixelLive-target confirmation on message render (reconnaissance)
Payment demandSame-day $97,500 ACH/wireFive-figure invoice fraud with a same-day 50 percent discount deadline
Bank detailsReal major-bank routing and SWIFT, unverifiable beneficiary accountBorrowed legitimacy; the payee account itself could not be validated
Auth stateDKIM pass, DMARC pass, SPF none, compauth 100Domain genuinely signed via authorized mail stream; request never validated
Message-IDForged to the recipient's own domainReinforced the appearance of an internal, already-approved thread

There was no malicious link and no attachment. The danger was an authenticated envelope, a real invoice format, a redirected Reply-To, and a deadline built to stop anyone from picking up the phone.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The CEO's Name Was Real. The Mailjet Account Behind It Wasn't.An attacker impersonated the CEO of an email security company using a legitimate Mailjet ESP account with full SPF/DKIM pass.
SPF Passed. DMARC Passed. DKIM Didn't. What That Combination Actually Means.A BEC email requesting ACH routing and a signed W-9 passed SPF and DMARC but failed DKIM body-hash verification.
It Passed SPF, DKIM, and DMARC. It Was Still a W-2 Heist.A payroll team got a same-day request to send every employee's W-2.
Perfect Authentication, Zero Payload: The Yahoo Free-Mail BEC That Microsoft Flagged but Didn't BlockA Yahoo free-mail account with perfect SPF, DKIM, and DMARC authentication sent a zero-payload account change request to a state government health agency.
The One-Letter Typosquat That Passed Every Authentication CheckA single missing letter in a vendor domain turned a legitimate invoice thread into a six-figure payment diversion.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.