Detecting thread hijacking in trusted conversations.
OpenEFA® Signals Series | March 24, 2026
Some of the most dangerous email attacks don't arrive as new messages. They arrive inside conversations you already trust.
Reply chain attacks — also called thread hijacking or conversation hijacking — exploit the fact that humans inherently trust ongoing threads. When a message appears inside an existing conversation, the recipient's guard drops. The context feels familiar. The participants are known. The subject line is expected.
That's exactly what attackers count on.
Email clients reinforce thread trust in several ways:
In-Reply-To and References link the new message to the original conversationThis inherited trust is powerful. It also makes reply chains one of the highest-value targets for attackers.
There are several variations, but most follow a similar pattern:
An attacker gains access to a real mailbox — through credential theft, session hijacking, or phishing — and replies to existing conversations. Because the reply comes from a legitimate account within an active thread, traditional authentication checks (SPF, DKIM, DMARC) all pass. The message looks entirely normal.
An attacker crafts a new message with forged In-Reply-To and References headers that match an existing conversation. The email client threads the malicious message into the original conversation, even though the sender isn't who they appear to be.
An attacker monitors a compromised mailbox for weeks, waiting for the right conversation. When a high-value thread appears — a vendor invoice, a wire transfer request, a contract negotiation — they inject themselves at the perfect moment with a targeted request.
Most email security systems evaluate messages individually. They check:
For reply chain attacks, the answer to all three is often no.
The message is authenticated. The content is clean. There are no links or attachments — just a polite request to update payment details, confirm a wire, or share a document.
Without understanding the conversation as a whole, the attack is invisible.
OpenEFA doesn't just evaluate the message. It evaluates the message in the context of the conversation.
When a reply arrives, OpenEFA examines several dimensions:
Has a new sender appeared in the thread who wasn't part of the original conversation? Has the sending infrastructure changed mid-thread? Is the reply-to address different from the original sender?
Does the tone, structure, and writing style of this reply match the sender's previous messages in the thread? A sudden shift in formality, sentence length, or vocabulary is a signal — even when the email address is correct.
Has the conversation suddenly introduced a financial request, an urgent deadline, or a sensitive action that wasn't part of the original thread? Attackers inject urgency because it works — but that escalation is detectable when measured against the conversation's baseline.
Do the threading headers (In-Reply-To, References, Message-ID) form a consistent chain? Are there gaps, duplications, or references to messages that don't exist in the conversation history?
Did the reply arrive at an unusual time for this sender? Was there an unexplained gap followed by sudden urgency? Timing patterns within a thread provide context that single-message analysis cannot.
Reply chain integrity is not just another detection rule. It represents a fundamental shift in how email security must work.
Traditional systems ask: "Is this message dangerous?"
OpenEFA asks: "Does this message belong in this conversation?"
That distinction matters because:
Consider this situation:
Thread: "RE: Q1 Vendor Payment Schedule"
Participants: CFO, Accounts Payable, Vendor contact
5 messages over 2 weeks — routine back-and-forth about payment timing.
Message 6: From vendor contact's email address.
"Hi — quick update. We've changed our banking details. Please use the attached form for the next payment. Need this processed by end of day."
Everything looks normal. The sender is real. The thread is real. Authentication passes.
But OpenEFA detects:
No single signal is conclusive. Together, they tell a clear story: this reply doesn't belong in this conversation.
Reply Chain Integrity is part of the OpenEFA Signals framework — a set of behavioral and contextual patterns that reveal risk before it becomes an incident.
The core principle: trust is not static. It must be continuously validated, especially inside conversations where trust is assumed.
Every reply is an opportunity to verify — or an opportunity for an attacker to exploit inherited trust.
OpenEFA treats it as both.