- HOME
- More
- Cybersecurity awareness
- How attackers hijack trusted email threads to commit financial fraud
How attackers hijack trusted email threads to commit financial fraud
- Last Updated : October 9, 2026
- 73 Views
- 7 Min Read
Most phishing emails arrive cold. A name the recipient doesn’t recognize, a subject line that’s slightly off, a sender address that doesn’t quite match the domain it claims. Awareness training has long focused on these signals, and for good reason. They work but only as long as the attacker doesn’t use any of them.
Conversation hijacking is a category of business email compromise (BEC) in which the attacker doesn’t send a cold email at all. They insert themselves into an email thread that’s already in progress between two parties who know and trust each other. The reply arrives inside a real conversation, from a familiar name, referencing details only someone in that thread would know. The recipient has every reason to trust it.
What separates conversation hijacking from standard phishing isn’t just the delivery method. It’s the preparation required. The attacker must first gain access to a legitimate email account, read through active threads to identify the right opportunity, and then insert themselves at precisely the right moment. The effort is significant. But attackers put in the effort because the return is equally significant. A reply inside a trusted thread bypasses almost every heuristic that standard email security relies on.

Why conversation hijacking is harder to detect than traditional phishing
For most of its history, business email compromise operated at scale. Attackers sent high volumes of spoofed emails impersonating executives, hoping enough recipients would act without scrutinizing the sender address. The technique was effective but increasingly detectable, as email authentication standards improved and awareness training became more widespread.
Conversation hijacking has risen 70% since 2022, based on Barracuda Networks’ analysis of 69 million attacks across 4.5 million mailboxes. The shift reflects a change in attacker strategy. Rather than impersonating someone from outside a thread, attackers now compromise accounts to get inside existing conversations. Thread hijacking now accounts for 28.1% of all BEC attacks, surpassing traditional cold-email BEC for the first time.
Several factors have accelerated this shift. Phishing kits, infostealer malware, and credential marketplaces have made compromised business accounts widely accessible. Once inside, the attacker has access to the full conversation history. That context is what makes their insertion convincing.
Inside the thread: What happened on August 8, 2024
On August 8, 2024, Darktrace detected an unusual email received by a SaaS account on a customer’s network. The email appeared to be a reply within an active thread discussing tax and payment details between the customer and a business partner.
The reply had arrived from what appeared to be the partner’s email account. It referenced real details from the existing conversation. Nothing about the content raised an immediate flag.
What Darktrace detected wasn’t the content of the email. It was what happened next. A few hours after the suspicious email arrived, the same SaaS account created a new mailbox rule. The rule was named simply “.” It was a deliberate choice, designed to avoid standing out in a list of mailbox settings. It was configured to move all emails containing a specific keyword to the user’s Archives folder and to mark them as read, ensuring that the genuine account holder wouldn’t see any replies sent in response to the attacker’s messages.
Darktrace also identified that the account creating the rule had logged in from an unusual IP address. The IP was located in the same country as the customer, and the network provider was one the customer used, making the login appear superficially normal. The combination of the rare IP and the anomalous mailbox rule creation was enough to flag the activity as suspicious.
The incident occurred on a public holiday, when the customer’s security team was off-duty. This timing choice is deliberate to try and evade detection. Darktrace’s autonomous response capability acted without waiting for human intervention. It disabled the compromised SaaS account for 24 hours, halting the attack and giving the security team time to investigate when they returned. No financial loss was confirmed in the public record.
Why the attack was so difficult to spot
The reason conversation hijacking is effective is the same reason it’s hard to detect. The attacker’s email didn’t arrive from an unknown address. It didn’t arrive from a lookalike domain. It arrived from inside a conversation that was already in progress, from an account that the recipient had a genuine prior relationship with.
Standard email security checks sender reputation, scans for malicious links, and looks for known phishing patterns in the content. None of those checks produce a useful signal when the sending account is legitimate and the email content mirrors an ongoing business conversation. The email passed every conventional filter because there was nothing in the email itself to fail.
The malicious activity only became visible at the infrastructure layer. It was a login from an unusual IP address, combined with a mailbox rule designed specifically to hide evidence of the attack. Both of those signals were behavioral rather than content-based. They required something beyond a content filter to detect.
What conversation hijacking looks like from the inbox
The most consistent signal of a conversation hijacking attempt is a reply that requests a change to something previously agreed. A bank account number that needs to be updated. A payment that needs to be redirected. An invoice that has been reissued with new details. These requests are often accompanied by a plausible reason such as an accounting system change, a banking error, or a new payment processor.
The reply will reference real details from earlier in the thread. This isn’t a coincidence. The attacker has read the conversation and selected those details specifically to build credibility. The more specific the reference, the more convincing it appears.
A genuine reply from a known contact rarely asks for payment details to be changed mid-conversation. Any such request should be verified through a separate channel not initiated by the email itself. Calling the contact on a previously saved number is the most reliable test.
What individual employees can do
Treat mid-conversation payment change requests as high-risk
A request to update bank details, redirect a payment, or reissue an invoice is a recognized pattern in conversation hijacking attacks. The familiarity of the sender doesn’t reduce the risk. Any such request should require a separate, out-of-band confirmation before any action is taken.
Verify using a channel that wasn’t initiated by the email
Call the contact on a number you already have saved, not one provided in the message. If the request is genuine, the contact will be able to confirm it. If it’s not, the call will reveal the discrepancy before any money has moved.
Check the sender address, not just the sender name
In cases where the attacker is using a lookalike domain rather than a fully compromised account, the name may be correct while the domain contains a subtle change. This takes seconds to check and catches a significant proportion of thread hijacking attempts.
What organizations can do
Enforce MFA on all email and SaaS accounts
The attacker in this incident gained access to a business partner’s account as the starting point for the attack. MFA significantly raises the cost of initial account compromise and is the most direct control against the access phase of conversation hijacking.
Monitor for anomalous mailbox rule creation
Silent forwarding rules, rules that move emails to archive folders, and rules configured to mark emails as read without the user’s knowledge are all consistent with attacker-controlled accounts. Email security solutions and SaaS management tools should alert you to newly created rules that divert incoming mail away from the primary inbox.
Implement email authentication across all sending domains
SPF, DKIM, and DMARC in enforcement mode prevent spoofed domains from being used in follow-on attacks once an account is compromised. They don’t prevent a fully compromised account from being used, but they reduce the attacker’s ability to impersonate the account from outside it.
Establish a payment change verification policy
Any request to change bank details, payment methods, or invoice recipients should require confirmation through a second channel before the change is applied. This policy should apply regardless of the seniority of the requester or the familiarity of the sender.
Log and retain mailbox activity for audit purposes
When an account is compromised, the attacker’s timeline is only recoverable if mailbox activity is being logged. Retention of this data is essential for post-incident investigation and understanding the full scope of exposure.
The thread was real. The reply was not.
The Darktrace incident illustrates what makes conversation hijacking difficult to defend against through awareness alone. The email that arrived on August 8, 2024, wasn’t suspicious by any measure a human reviewer would apply. It came from a known contact, inside a known conversation, about a topic already being discussed. The attack only became detectable when the attacker moved to cover their tracks.
The signals indicating a compromised account are almost never in the email content itself. They’re in the login activity, the mailbox rule configuration, and the behavioral patterns surrounding the account. Detecting conversation hijacking requires visibility at a layer below the inbox and above what content filters can see.
Wrapping up
October is Cybersecurity Awareness Month 2026, and this is Case 02 of The Breach Files. In this series, we break down one real email attack each week. Next week, we’ll look at QR code phishing: how attackers embed a malicious URL inside an image, and why standard link scanners have no way to read it.
eProtect is a cloud-based email security and archiving solution built to defend against email threats that content filters alone cannot catch, including attacks that exploit trusted sender relationships and hijacked conversation threads. The solution offers advanced threat detection for on-premise and cloud email accounts, and is the security layer powering Zoho Mail, a platform trusted by millions of users.


