The Forged Reply That Explained Why the Invoice Arrived

An invoice reached the accounts-payable controller at a national senior-care and skilled-nursing operator. It billed for executive leadership coaching delivered to the organization's own chief executive, carried the reference INV-49341425, attached a 512KB PDF, and offered a 20 percent discount if the balance was settled before a stated deadline, with priority headers set to highest.

Underneath the ask sat a quoted thread two levels deep. Its inner layer was attributed to the chief executive of the recipient organization: if this has not been paid, forward it directly to this address, because submitting it there will expedite processing and payment will be initiated as soon as it is received.

The address named in that forged reply was the exact mailbox the message had just been delivered to.

The Reply Answered a Question Nobody Had Asked Yet

A finance team confronted with an unexpected invoice asks two things: is this ours, and who authorized it? The second gets the discussion. The first is the one that usually kills the fraud, because an invoice for the chief executive's coaching has no natural reason to land in one named controller's inbox rather than a shared payables alias. That oddity is what prompts a phone call.

This message removed the oddity in advance. The forged reply supplied, in the executive's own apparent words, a reason the invoice was sitting where it was, so the strangeness of the routing became evidence of its legitimacy. The message never presented itself as awaiting approval; it read as the tail end of a process already in motion.

The outer layer of the thread was a dunning notice from a coach persona, timestamped earlier in the preceding week, with the forged executive reply two days after it. Neither message existed in the mailbox. One detail betrayed the construction: the quoted address for the chief executive carried a trailing dot at the end of its local part, a malformed address no mail system would have produced.

Four Domains, Four Different Owners

One message, four identities, one attacker registration.

The envelope sender and Return-Path were an Amazon SES token address in a US West region. The From header was an alias on a marketing subdomain inside the DNS zone of a Brazilian internet service provider whose apex domain has been registered for more than two decades. The Reply-To pointed at a mailbox on a Hong Kong consumer ISP's mail service. The signature block directed all invoice questions to a role address on a .org domain that inserts a single word into the real domain of a leadership-development nonprofit.

Only that last domain was registered by the attacker. The Reply-To mailbox was attacker-controlled, but the domain behind it is a public consumer service, no more attacker-owned than a free webmail account. The platform address and the Brazilian subdomain belong to uninvolved real parties.

Which of the four carried the attack? The Reply-To. There was no malicious link, and the only link in the body pointed at the recipient organization's own website. The attachment came back clean. The entire operational payload of this business email compromise was one header field, steering every reply to a mailbox that appears nowhere in the story the email tells.

It Authenticated Where It Counted

At the recipient's own inbound gateway, before the message had been relayed or rewritten, the results were unambiguous. SPF passed for the sending host at 23[.]251[.]242[.]4. DKIM passed for the Brazilian subdomain. DMARC passed, with the policy recorded as reject at both the apex and the subdomain level, and header-sender alignment confirmed.

That is an enforced policy working as designed. Two DKIM signatures were present, and the signing selector was of the form a bulk sending platform issues, meaning the subdomain was an established sending identity inside an account the sender could use. Whether that account belonged to the provider or was stood up by someone with access to the zone is not something the message settles.

The lesson sits in the gap between two true statements. DMARC, specified in RFC 7489, proved the message was authorized to use the domain in the From line. It could not say whether that domain was the invoicing party, and it was not.

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

Two Verdicts on One Signature, One Hop Apart

The gateway then relayed the message onward, wrapping a link with its own protection as it went. Microsoft, one hop later, recorded something very different: SPF failed because the sending IP was now the gateway's relay, DKIM failed with no key for the signature on the same domain the gateway had just validated, a second DKIM signature failed on body hash, DMARC failed with an override to reject, and composite authentication returned nothing usable.

Microsoft delivered anyway, because the relaying gateway is a trusted inbound connector. It applied its spoof safety marker but scored the message at the lowest spam confidence level, and the invoice landed in the inbox.

Leave that conflict recorded rather than reconciled. A body rewritten after signing accounts for the body-hash failure. What matters is the direction of the error: an analyst triaging from the final authentication header alone would call this a triple authentication failure that got delivered regardless. That reading is backwards, and it sends the investigation hunting a spoof that never happened instead of the abused sending identity that did.

A Real Address Under an Invented Letterhead

The lookalike was registered roughly eight and a half months before the send, through a reseller registrar, with registrant details fully redacted and nameservers pointing at a Microsoft 365 tenant. Prepared infrastructure, not a burner registered the week of the campaign, and its age alone would clear most reputation checks.

The signature block went further. It reproduced the impersonated nonprofit's real published mailing address, character for character, alongside a tagline that nonprofit has never used. A recipient who searched that address would have found a genuine organization there and confirmed the wrong fact. A verifiable street address is a copy-and-paste, not a legitimacy signal.

What Caught It

The gateway's content heuristics were not fooled. Phishing and spear-phishing rules fired, four separate weight rules tripped, multiple suspicious-mail warnings were appended, and its machine-learning scorer landed mid-range. The gateway then classified the mail as valid and delivered it, because the authentication evidence outranked the content evidence.

The platform's impersonation matching had nothing to work with either. The display name was an invented vendor persona, not a known internal contact, so there was no established identity to match. What resolved the case was behavior: a first-time sender, a reply path unrelated to every other identity in the message, and a payment instruction manufactured inside the email requesting the payment. Themis, our Adaptive AI classified the message as phishing and quarantined the single affected mailbox roughly five seconds after it arrived.

The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names pretexting, largely BEC, as the leading social-engineering type with a median transaction around $50,000, and the 2023 FBI IC3 Internet Crime Report recorded roughly $2.9 billion in reported BEC losses. CISA's phishing guidance and the NIST definition of phishing land on the same control: verify the request through a path it did not arrive on. For accounts payable, that means a vendor record or a call to a known number, and reading the Reply-To before the invoice.

Indicators of Compromise

MITRE ATT&CK Mapping