What happens when attackers use BCC, lookalike domains, and thread hijacking in payment fraud campaigns?

Those tactics hide the recipient list, preserve the appearance of continuity, and make the message seem like a normal continuation of an existing conversation. The target is more likely to trust the request and less likely to notice that the domain, reply path, or participant set changed. That is why invoice fraud demands thread and identity verification, not just content inspection.

Why BCC, lookalike domains, and thread hijacking work together

BCC hides the recipient list, lookalike domains preserve a familiar brand signal, and thread hijacking keeps the message anchored to an existing conversation. In combination, they reduce the friction that usually makes payment fraud stand out: the request looks expected, the sender appears plausible, and the path of the reply seems normal enough that a busy recipient may act before verifying the change.

The real trick is not any single tactic on its own. Attackers are stacking trust cues so the target focuses on the continuity of the conversation instead of the fact that the participant set, domain, or reply path has changed. That is why these campaigns often succeed even when the payment request itself is not especially sophisticated.

What the attacker is trying to manipulate in invoice fraud

Invoice fraud is usually a trust problem before it is a content problem. By entering an existing thread, the attacker inherits context: prior invoices, names, timing, and a believable business process. A lookalike domain can then mimic the expected sender while quietly moving the communication to infrastructure the victim does not control, and BCC can reduce the chance that other recipients notice the fraud early.

This combination also exploits workflow habits. Finance and procurement teams are trained to look for amounts, due dates, and approval language, but not always to re-check whether the thread origin, sender identity, or domain has shifted. The attack succeeds when the recipient validates the request against the story in the email, rather than against the underlying counterparty and payment instructions.

What defenders should verify before releasing payment

The right control is not only message scanning. Teams need an independent verification step for any payment instruction change, especially if the request arrives in an existing thread or comes from a domain that is close to, but not exactly, the normal sender. That means checking the full address, the reply path, and any change in beneficiary details against a trusted channel already on file.

Confirm the sender and reply-to address out of band when payment details change.
Compare the current domain with the known supplier domain, including subtle character swaps.
Require a second approval path for bank-detail changes, even if the email thread looks legitimate.
Train staff to treat thread continuity as weak evidence, not proof of authenticity.

Once a recipient has accepted the thread as genuine, the attacker has effectively lowered the cost of the next fraudulent ask. That is why verification must happen before payment release, not after a suspicious invoice is already in the accounting queue.

Risk and Threat Considerations

These tactics increase the probability of business email compromise, payment redirection, and delayed detection because they exploit ordinary trust signals rather than obvious malware behaviour. The most dangerous outcome is not just one fraudulent transfer, but a repeatable process that blends into normal vendor communication and bypasses casual review.

Failure mechanism: The victim validates the request based on familiar thread context and a visually similar sender instead of independently confirming the payee, domain, and reply path.

Impact: Funds can be redirected, disputes become harder to resolve, and the same social path can be reused for additional invoices or approval requests.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1566 — Phishing	Thread hijacking and lookalike domains are phishing delivery and social-engineering patterns.
	T1583 — Acquire Infrastructure	Lookalike domains are attacker-controlled infrastructure used to support the fraud campaign.
	T1204 — User Execution	The attack depends on a user acting on a deceptive payment request and approving the transfer.
Recommendation — Map invoice-fraud emails to T1566 and train detection on reply-chain abuse and domain spoofing. Track lookalike domain registration and flag newly acquired domains that mimic suppliers. Harden approval workflows so user action alone cannot finalise payment changes.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Payment approval depends on verifying who is requesting a change, not just reading the message.
	AU-2 — Audit Events	Thread hijacking and payment changes need traceable logging across message and approval workflows.
Recommendation — Require strong authentication before accepting vendor or payment-detail changes. Log sender, reply-path, and payment-change events for fraud investigation.
CIS Controls v8	CIS-8 — Audit Log Management	Detecting fraudulent thread reuse and domain changes depends on useful logs and reviewable events.
Recommendation — Centralise logs for mail flow, payment changes, and approval actions.
OWASP ASVS	V10 — OAuth and OIDC	Strong authentication patterns are relevant where payment workflows depend on identity assurance.
Recommendation — Use phishing-resistant authentication for sensitive approval and payout workflows.
NIST SP 800-63	IAL — Identity Assurance Level	Payment fraud mitigation depends on assurance that the requester is the expected party.
Recommendation — Raise assurance requirements for payment changes and beneficiary updates.

Practitioner Guidance

What to prioritise: Treat any change to payment instructions as a higher-risk event than a routine invoice, even when the email sits inside an existing thread. The trigger is not only suspicion of fraud, but any change in domain, participant set, or beneficiary details.

What to verify: Ask whether the person authorising payment can independently prove they are speaking to the expected counterparty through a known channel. If the answer depends only on the email thread itself, the control is too weak.

Common mistake: Over-relying on brand logos, prior conversation history, or quoted message content. Those cues can all be replicated or preserved while the underlying sender identity has changed.

Practitioner takeaway: Thread continuity is a convenience signal, not an authenticity signal, so the decisive control is independent verification of who is asking for the payment change.