The Fake Thread Where Your Own CEO Approved the Invoice

A shared accounts-payable mailbox at a regional convenience-retail group received a message with a one-line ask: an overdue invoice that had to be processed and completed that day. The subject read Re: Invoice #645221 - Request for Payment, which is unremarkable until you notice there was no prior message in the mailbox for it to be a reply to.

Underneath that single line sat a quoted email thread four layers deep. Inside it was a reply attributed to the group's own chief executive: "Hi [vendor contact], I have reviewed the details and will forward this for payment."

That is the attack. Nothing was attached and no clickable link was present. The attacker did not simply impersonate a vendor chasing money. It manufactured written evidence that the company's most senior officer had already signed off, then delivered that evidence to the one mailbox whose function is to act on approvals.

The Approval Was the Payload, Not the Corroboration

Accounts-payable training is built around one question: was this authorised, and by whom? A well-run team will not move funds on urgency alone; it looks for a name, a sign-off, a thread it can point to.

This message answered that question before it was asked. The fabricated thread supplied the sign-off in the recipient's own executive's name, complete with a signature line, so every control the AP clerk was trained to apply resolved to text the attacker had typed.

Around it, the thread was dressed for scrutiny rather than speed. A hand-built header block imitated a forwarded message, listing a sender, a send time, a recipient and a subject. An invoice panel rendered reference 645221 and Amount Due: £11,400.00 against a due date already months past, itemised against 72 hours of implementation work. The seams only show if you look for them: deeper thread layers carried timestamps roughly five months stale, and that top header block claimed a send time about half an hour before the message genuinely left.

Four Identities, None of Which Agreed

Strip the message to its identity signals and it makes four mutually exclusive claims at once.

The From display name was the recipient organisation's own chief executive, recorded by the platform as an exact display-name match against a known internal VIP in the executive department. Whether that was deliberate targeting or coincidence is not something the record settles, and the message's own signature argues against a straightforward executive impersonation.

The From address and Return-Path belonged to a small Dutch retailer, a business with no connection to the invoice, the consultancy named in the body, or the recipient.

The Reply-To was a third domain entirely: the same executive display name over admin@abpllty[.]cc. Any reply, and any payment correspondence that followed, would have left the conversation both companies thought they were having.

The body signature was a fourth identity, a vendor persona at accounts@lekconsultancy[.]com, a lookalike of the real management consultancy L.E.K. Consulting. That domain was registered roughly 21 hours and 35 minutes before the message was sent, on the previous calendar day. Notably, the Reply-To domain was about four months old, materially older than the vendor domain it pretended to bill from. Both were registered through the same registrar behind the same default privacy service and nameservers, which is what that registrar hands every customer and is not evidence of a shared registrant.

DMARC Passed Without a Single Signature

The authentication verdict is worth reading in full, with the compromised domain withheld:

spf=pass (sender IP 146[.]20[.]161[.]75) smtp.mailfrom=(withheld); dkim=none (message not signed) header.d=none; dmarc=pass action=none header.from=(withheld); compauth=pass reason=100

SCL was 1, and there was no gateway rewriting in the path. The relay hop recorded an authenticated sender, and the authentication ID was the Dutch retailer's own mailbox, so the message was sent by that mailbox as itself. Its credentials were in someone else's hands. How they got there is not in the record.

DKIM was absent entirely, so DMARC returned pass on SPF alignment alone. That is exactly what RFC 7489 specifies, and it is the part teams routinely over-read. Alignment between the envelope sender and the visible From domain says the mail left a server that domain authorises. It says nothing about the other three identities in the message, or about the person the display name claimed to be. A DMARC pass here was an accurate technical result and a useless identity signal.

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

Two Leftovers From a Recycled Kit

One anchor in the HTML still carried a leftover title attribute pointing at another company's accounts-payable address, while the visible link pointed at the attacker's own vendor persona. That address belongs to an unrelated multinational and appears nowhere else in the message. It is the fingerprint of an earlier target the same template was aimed at.

The signature block misspells accounting in its own job title, and prints a US area code, 920-810-9240, alongside a London address. At the bottom of the message sits a 1x1 tracking pixel whose host is a genuine QuickBooks notification endpoint, copied across with the stolen template. Intuit sent nothing here and nothing of theirs was compromised, and whether that beacon ever fired is not shown in the record.

Nothing to Scan, So the Identity Graph Did the Work

With no attachment and no URL, every payload-oriented control had nothing to inspect. Detection came from relationship context instead. Themis, our Adaptive AI returned 84% confidence with two labels: VIP impersonation and vendor email compromise. Its sender analysis was the decisive input, flagging that the displayed executive name is known from an internal address while this message came from an unrelated external domain. Content analysis added wording and structure patterns consistent with payment fraud.

The incident was automatically resolved as phishing. One mailbox was affected, and it was quarantined roughly four seconds after the message was received. The sender was not a first-time sender, and its risk level was already high.

What This Means for Payment Approval

The 2024 Verizon Data Breach Investigations Report puts the human element in 68% of breaches and names pretexting, largely BEC, as the leading social-engineering type, with a median transaction of roughly $50,000. The 2023 FBI IC3 report put reported BEC losses near $2.9 billion. This request sat well under that median, which is precisely what makes it dangerous: small enough to clear without escalation, wrapped in an approval that appeared to have already happened.

Three habits close this gap. Treat a visible approval as an unverified claim and confirm it in the system of record, or with the approver on a channel you already trust, never by replying. Compare the From domain, the Reply-To domain and the vendor named in the body; a genuine invoice rarely produces three different answers. And read a DMARC pass as a statement about a domain, not a person, which is the operating assumption behind business email compromise protection. CISA's phishing guidance and NIST frame it the same way: the deception targets a decision, not a device.

Indicators of Compromise

The compromised sending mailbox and its domain are withheld. That business is a victim in this incident, not an operator.

MITRE ATT&CK Mapping