The Invoice Was Older Than the Domain It Told You to Pay

A vendor invoice for $19,900.00 arrived in the mailbox of an accounting executive at a US commercial insurance provider. Terms were net zero, due upon receipt, and the body said the payment had to be processed that day.

Every authentication check passed. SPF, DKIM and DMARC all returned a pass under an enforced quarantine policy. Nothing was forged, because the message genuinely left the authorized sending stream of a real, long established business that was neither the vendor on the invoice nor the insurance provider, and had nothing to do with the transaction.

The invoice carried a different problem. The issue date printed on it, and the date it claimed a complimentary onboarding trial had concluded, were both earlier than the day the billing domain printed beside them came into existence.

Authentication Passed Because Nothing Was Spoofed

One external hop, no disagreement anywhere in it. The sending host was an outbound relay at a large email service provider, authorized for the envelope domain: a sending subdomain the third party had properly delegated to it. The signature validated against that company's apex domain, and DMARC returned a pass against a published quarantine policy. This was not a policy gap. The third party had done the work, and all three protocols correctly answered the only question RFC 7489 exists to answer: is this message authorized to use the domain in its From header.

How the attacker gained the ability to send through that stream is not in the record. Stolen credentials, a leaked API key, an abused subaccount and an insider all fit the evidence equally. It barely matters: once mail leaves an authorized stream, authentication validates the stream, not the story riding inside it.

The forgery lived in two places no protocol inspects. The From display name exactly matched a real employee in the recipient's own organization, a manager on its partnerships team, while the address beside it stayed on the third party's domain. The Reply-To pointed elsewhere again, at a throwaway domain registered roughly five months earlier, under that same borrowed display name.

An Invoice Older Than Its Own Billing Domain

The invoice was HTML rendered inline in the body, styled as vendor letterhead: an invoice number, a client ID naming the recipient organization, a five line scope of work adding cleanly to $19,900.00, and two dates. An issue date roughly nine months before the email was sent, and a notice that a three month complimentary onboarding trial had concluded roughly six months before it. Both read as unremarkable aging invoice detail, the sort of thing Accounts Payable takes as corroboration.

The billing domain on that same invoice, the one the payment instructions told the recipient to contact, was registered about a month before the message was sent. Four weeks is long enough to look settled to anything that only asks whether a domain is brand new. Both invoice dates still predate it by months.

No legitimate billing process produces that ordering. A vendor cannot issue an invoice from a billing domain that will not exist for another eight months, and cannot conclude a trial on it. The invoice also cited a master services agreement the record corroborates no better than it corroborates the trial or the balance.

The Kit Shipped With Its Build Notes Still In It

Three values in this message were never substituted before it went out.

The first is the vendor logo. The invoice header carries a comment telling whoever assembled it to paste the original base64 encoded image data into place, and below that an image element whose source is the literal string PASTE_ORIGINAL_LOGO_BASE64_HERE, its alternative text naming the impersonated vendor. On a document asking for twenty thousand dollars, the recipient saw a broken image captioned with the attacker's build note.

The second is the greeting on the fabricated thread beneath the invoice, which opens with Hello , and an empty merge field where a first name belongs.

The third is the subject line, which ends in a random five character token appended with no separator, so the last word of an otherwise clean subject reads as a typo. The quoted reply blocks in the same body print that subject cleanly, so the token exists only on the outer send, to break subject string clustering.

Nothing to Detonate, Nothing to Compare

The body says the invoice is attached again and offers another copy of the invoice PDF. The record's attachments array is empty. There was never an attachment, and the links array is empty too. The only fetchable resource is a one pixel open tracking image belonging to the sending platform, withheld here because its numeric host prefix identifies the third party's own subaccount. Nothing for a sandbox to open, no URL to follow, no reputation to look up.

The payment instructions are just as thin, deliberately. No account number, no routing number, no payee change, only an instruction to contact a billing address on the attacker registered domain for payment details, by ACH or wire only. Nothing ships that a bank detail check can grade or a reviewer can compare against the vendor record on file. Business email compromise at this stage is a request for a conversation, not a payload.

Consent is manufactured instead. Beneath the invoice sits a fabricated two message thread: a reply from a purported vendor executive at the attacker registered domain, and above it a reply attributed to the impersonated internal employee, confirming the invoice was received and that payment would go out within a day. The recipient is not asked to approve a payment, but shown a colleague who already did.

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

The Signals That Caught It

No technical control failed here, so no technical control fired. What caught this message was identity, twice, and then a person.

A suspicion banner was injected into the delivered message, reading, with the employee name removed: IRONSCALES finds this email suspicious, we know this person by name, but the email was sent from an unfamiliar address. That correlation comes from the organization's own fingerprint of its employees, not from the authentication stack. Our Adaptive AI also tagged the message as an exact display name impersonation and raised the sender risk level to high.

Then the accounting executive reported it as an unknown sender. Roughly eight minutes after delivery the message was quarantined, one mailbox affected, and an analyst confirmed the incident manually rather than reverting it.

Three Changes Worth Making

The 2024 Verizon Data Breach Investigations Report puts the human element in 68% of breaches and names pretexting, mostly business email compromise, as the top social engineering type, with a median transaction near $50,000. This invoice asked for less than half that median, sized to be approved rather than escalated.

Three practices follow. Compare the dates printed on any inbound financial document against the registration age of every domain printed on it, a check that needs no threat intelligence feed and was dispositive here. Score a display name against your own directory of internal identities, not against the From domain. And treat a request to ask for payment details as the indicator, rather than reading absent bank details as absent fraud.

The NIST definition of phishing turns on deception and objective, both supplied here while every protocol built to establish who sent the message returned a pass. CISA's phishing guidance makes the same point: controls that stop at the authentication result keep delivering mail that is technically authentic and substantively invented.

Indicators of Compromise

MITRE ATT&CK Mapping