Three Domains, One Invoice: The Payment Diversion That Authenticated Itself Through the Wrong Organization

The subject line was "Past due invoice." The display name matched a known contact at a clinical research firm. SPF passed. DKIM passed. DMARC passed. Everything about the authentication looked legitimate.

But the sending domain, the reply domain, and the payment domain were three completely different organizations. The email came from stan@berteloot[.]org. Replies would go to mail@ilyff[.]com. And the payment instructions directed to invoice@billingsdepts[.]info. Three domains, three purposes, zero overlap.

Authentication Passed for the Wrong Organization

The email authenticated cleanly for berteloot[.]org because the attacker controlled that domain's DNS records. SPF included the SendGrid infrastructure that delivered the message. DKIM signed correctly under the sending domain. DMARC aligned. From an authentication standpoint, the email was authorized.

But authentication answers a narrow question: is this infrastructure authorized to send on behalf of this domain? It does not answer whether the person behind the domain is who they claim to be. The display name spoofing impersonated a contact at a clinical research firm, a completely different organization from the authenticated sending domain. The recipient's email client would show the familiar name. The actual sending address, buried in headers, would require deliberate inspection.

A Throwaway Reply, a Mail-Only Payment Address

The Reply-To header diverted any responses to mail@ilyff[.]com, a domain registered February 5, 2026. No website. No established email history. No WHOIS data beyond the registration date. If the recipient replied to the invoice, the response would never reach the impersonated vendor. It would arrive in the attacker's inbox at a domain that existed solely for this campaign.

The payment instructions in the email body directed the recipient to send payment details to invoice@billingsdepts[.]info, another domain with no web presence. It functions as a mail-only address, a destination for payment that cannot be verified by visiting a website, checking a company directory, or looking up a business registration. The naming convention ("billingsdepts") was designed to look plausible at a glance without corresponding to any real organization.

The email also instructed the recipient to forward the invoice to a legitimate third-party address, attempting to insert the attacker's fabricated payment workflow into a real vendor relationship. This forwarding instruction adds a layer of social credibility: the target sees a familiar name, familiar process, and what appears to be a routine request to loop in accounts payable.

Three Domains, Zero Overlap, One Detection Signal

Themis flagged the three-domain mismatch as the primary signal: a sender domain with no relationship to the impersonated vendor, a Reply-To on a domain registered weeks earlier, and payment instructions pointing to a third, mail-only domain. The invoice fraud pattern, combined with display name impersonation of a known contact, triggered classification before any user interacted with the message.

No links to scan. No attachments to detonate. A SendGrid tracking pixel confirmed the attacker was monitoring delivery. The entire payload was a conversation designed to end with a wire transfer to the wrong account.

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

Indicators of Compromise

MITRE ATT&CK Mapping