What are the signs that a business email compromise attack is being built around a hijacked conversation rather than a fresh spoofed message?

Common signs include a sudden change in payment instructions, lookalike domains replacing known counterparties, unusual urgency around an existing invoice, and new attachment formats such as wire instructions or spreadsheets. If the thread references prior discussion but introduces a new bank account, the message should be treated as a likely compromise until independently verified.

How to tell a hijacked-thread BEC from a fresh spoofed email

A hijacked conversation usually preserves thread history, sender-recipient relationships, and the subject line, then introduces a payment change, new bank details, or a subtle instruction shift. A fresh spoofed message more often starts cold, lacks credible prior context, and tries to create the whole story at once. The distinction matters because thread hijacking exploits existing trust.

In practice, the thread structure is one of the best clues. If the message appears inside a known exchange and mirrors earlier wording, it is more likely to be a compromised conversation than a brand-new impersonation. That is especially true when the attacker responds to a live invoice, a pending transfer, or an active vendor discussion.

Look for continuity that feels almost right but not quite. Attackers often reuse prior attachments, quote earlier messages, or reference real names and open work items, then insert one high-impact change such as a revised beneficiary account or “updated” wire instructions. That blend of familiarity and deviation is a common marker of thread compromise.

What the attacker is exploiting in a hijacked conversation

Thread hijacking works because recipients trust continuity more than authenticity checks. Once the attacker gains access to an inbox, mailbox rule, or forwarded copy of the exchange, they can wait for the right moment, then insert a convincing message that appears to belong to the original discussion. The message may not need polished phishing language because the context does most of the work.

Fresh spoofing is different. It must manufacture credibility from scratch, so it is more likely to contain weak context, odd grammar, mismatched timing, or a generic request that does not align with an existing business process. A hijacked thread, by contrast, inherits the legitimate cadence of the discussion and can therefore survive a quick glance.

This is why payment workflows are a common target. The attacker wants the recipient to act before verifying a bank change against a trusted channel. In a hijacked conversation, the malicious instruction is often positioned as a correction, a follow-up, or an urgent operational update rather than an obvious fraud attempt.

Signals that should trigger verification before action

The strongest warning signs are changes that create financial or process drift inside an otherwise normal thread. A new account number, altered payment destination, unexpected attachment format, or sudden request to bypass standard approval steps should be treated as suspicious even if the conversation history looks genuine. Look especially for pressure to keep the change confidential or to act immediately.

A second clue is inconsistency with the established business context. If the thread is about one invoice but the reply introduces a different bank, a new intermediary, or an unusual file type such as a spreadsheet with payment data, the attacker is likely trying to steer the workflow without breaking the thread illusion. The content is often subtle enough to pass casual review but not close verification.

For a useful external reference on the attack pattern and broader threat context, see CISA cyber threat advisories. For attack-chain perspective, MITRE ATT&CK’s Enterprise Matrix is also useful for mapping credential access and follow-on abuse.

Risk and Threat Considerations

Hijacked conversations are dangerous because they defeat the natural skepticism people apply to unknown messages. The threat is not just spoofing, it is trust reuse. Once an attacker controls or mirrors a real thread, they can blend into routine business activity and convert an ordinary invoice or payment discussion into fraud without obvious indicators.

Failure mechanism: The attacker uses access to an existing mailbox, forwarded thread, or reply chain to preserve context, then inserts a small but material change, usually payment destination or approval path, that is easy to miss.

Impact: The organisation can lose funds, expose sensitive transaction data, and delay detection because the message looks like a legitimate continuation of prior work rather than a new intrusion.

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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1589 — Gather Victim Identity Information	Hijacked-thread BEC relies on prior context and trust relationships in the victim's exchange.
Recommendation — Map thread context abuse to victim intelligence gathering and monitor for account compromise.
CIS Controls v8	CIS-14 — Security Awareness and Skills Training	Users must recognise thread hijacking, payment drift, and verification triggers.
Recommendation — Train staff to verify payment changes out-of-band before acting on email requests.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Thread hijacking often follows mailbox compromise or abused access to existing communications.
	DE.CM-03 — Personnel activity is monitored to detect potential cybersecurity events	Suspicious account behaviour and unusual email activity can indicate conversation hijack.
Recommendation — Tighten mailbox access controls and require strong authentication for email accounts. Monitor for anomalous mailbox activity, forwarding rules, and reply-chain abuse.

Practitioner Guidance

What to verify: Treat any payment change inside a live thread as untrusted until it is confirmed through a separate channel already known to belong to the counterparty. Verify the bank account, beneficiary name, and invoice reference independently, not by replying in-thread.

Common mistake: Teams often overfocus on whether the email “looks spoofed” and undercheck whether the conversation itself has been compromised. If the thread history is real but the latest instruction is new, the safer assumption is that the attacker is exploiting continuity, not impersonating from outside.

Practitioner takeaway: The deciding question is not whether the message appears authentic in isolation, but whether the new instruction matches a trusted business process when the thread is stripped of its history and examined through a second, trusted channel.