One Invoice Email, Four Different Identities

An invoice payment request arrived at a single billing mailbox inside a residential home-services provider carrying four separate identities, and only one of them was genuine. The visible signature belonged to a colleague at the same company. The envelope sender belonged to a small European automotive dealership with no relationship to that company or to the invoice. The Reply-To pointed at a third domain that had existed for nine days. Quoted underneath the request sat a forwarded message from a billing manager at a fourth company, a company named nowhere else in the message. There was no malicious link, no macro and no executable anywhere in it.

The Request That Only Needed A Reply

The visible body ran two sentences. It opened with the recipient's first name, asked whether they could coordinate payment that day, told them to code the amount to professional fees under an advisory line, and signed off with a colleague's first name. Nothing pointed at a URL, so nothing had to be clicked. The entire transaction was designed to complete over a reply.

The To header carried the recipient's real mailbox address paired with a display name belonging to a different employee, the same colleague the message was signed as. That mismatch is an artifact of how the message was assembled, and it is the first place the four identities collide: one mailbox, addressed under a second person's name, with a third address waiting in the reply path.

Authentication Was Not Bypassed, It Was Absent

The sending domain published no SPF record, no DKIM key and no DMARC policy. The authentication results read spf=none dkim=none dmarc=none, and Received-SPF came back as None rather than a pass or a fail. Microsoft's composite authentication then returned compauth=pass reason=105, an implicit pass, which is the receiver recording that there was no policy to evaluate rather than confirming a sender.

That distinction matters operationally. A rule that promotes mail on a composite pass treats a domain with nothing published exactly like a domain under an enforced reject policy. RFC 7489 defines the policy and reporting mechanism, but it only helps a receiver when the sending domain actually uses it, and a large share of small-business domains still do not.

An Authenticated Login, Not A Spoofed Envelope

The Received chain is the most important line in this message. It records an ESMTPSA submission handed to the sending domain's own mail host, which is to say the message was submitted using working mailbox credentials on that domain rather than injected with a forged envelope from somewhere else. The dealership was not impersonated. Its mailbox was used.

That single detail rewrites the response. There is no attacker-owned sending domain to block here, only a bystander small business whose account needs recovery, which is why account takeover protection and inbound filtering have to be treated as one problem rather than two. A blocklist entry aimed at the sending domain would only punish the other victim in this story.

Two Domains Registered Days Apart

The Reply-To address sat on a domain registered through a mainstream domain retailer with its registrant details privacy-redacted, nine days before the message was sent. The address quoted inside the forwarded block sat on a second domain, registered through the same retailer with the same redaction, the day after the first, eight days before the send. Nothing on paper connects the two, and their listed registrant states differ.

Read together, they are one purchase. This is MITRE ATT&CK T1583.001 in its plainest form: infrastructure acquired for a single message, split across two names so that a reader who checks one address never learns that both were bought within a day of each other.

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

The Forwarded Thread That Was Never Forwarded

Below the two-line request, the body quoted what looked like a relayed vendor email: a from line, a date a few days earlier, a subject carrying the target company's own brand alongside an invoice number, and a recipient line naming the colleague whose signature appeared above. It closed with a signature block giving a billing-manager title, a company name and a California street address.

None of it was relayed. A quoted forwarded block is body text, typed by whoever composed the message, and it carries none of the routing evidence an actually forwarded message would. What it does carry is context: a vendor identity, a reference number and an implied history, all of which make the payment request read as the last step in a process the reader simply does not remember starting. That is the same trust-transfer mechanism described in CISA's phishing guidance, applied without a single link.

Two Clean PDFs Doing Social Engineering

Two PDFs came attached, an invoice and a form. Both returned clean platform verdicts. One was independently sandboxed: a valid PDF, generated by a PDF library rather than exported from an accounting package, with no embedded JavaScript, no form fields, no open-action or additional-action triggers, no embedded files and no URLs. It is a document with nothing to detonate, which is exactly why it survived every content check. The other attachment's filename repeated the target company's own brand, a detail that costs an attacker nothing and buys a great deal of familiarity in a preview pane. Under T1566.001 the attachment is the lure, not the payload.

Why Automated Triage Read It As Bulk Mail

The platform's automated triage initially bucketed this message as bulk mail, at 89 percent confidence. The content signals cited promotional and attention-grabbing language. The sender-analysis signals cited patterns consistent with mass mailing. Community signals pointed the same way, drawn from similar previously resolved reports.

The reasoning is legible even where the label lands wrong. Urgency vocabulary is shared property between marketing and fraud, and a message sent to exactly one recipient offers no volume footprint to weigh against it. What kept the case moving was that the same record's body analysis independently described the message as consistent with invoice fraud, and a human reviewer marked the incident approved manually rather than letting a top-line label settle it. That gap between a content score and a relationship read is where Themis and our Adaptive AI are pointed, and where business email compromise protection has to operate, because no payload will ever arrive to tip the scale.

The stakes are well documented. The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and names pretexting, largely BEC, as the leading social-engineering type, with a median transaction of roughly 50,000 dollars. The 2023 FBI IC3 Internet Crime Report records about 2.9 billion dollars in reported BEC losses. Neither figure depends on an attachment anyone opened.

Strip out the payload question and the signals that remain are all relational: first contact from a domain unrelated to the invoice it discusses, a reply path that leaves the sending domain entirely, reply infrastructure registered nine days before use, a display name that does not match the mailbox it was addressed to, and a vendor identity with no history anywhere in the tenant. Individually each one is weak. Stacked, they describe a message no real supplier would ever send.

Indicators of Compromise

MITRE ATT&CK Mapping