Detecting thread hijacking without reading anyone's mail
Header and graph signals that identify an injected reply, without content inspection or the privacy problems it brings.
- Detection
- BEC
Thread hijacking defeats most phishing controls for a simple structural reason: the message is genuinely from the address it claims, genuinely inside a thread the recipient started, and genuinely a reply to a message they actually sent. Every heuristic built on 'is this sender unexpected' returns false.
The signals that do survive are structural rather than semantic. An injected reply frequently shows a discontinuity in the References and In-Reply-To chain, because the operator reconstructs the thread from what is visible in the compromised mailbox rather than from the original message store.
Transport path is the second signal. A reply that suddenly traverses different infrastructure to every prior message in the same thread is worth scoring, even when SPF, DKIM and DMARC all pass — because on a genuinely compromised mailbox they will all pass.
Neither signal is conclusive alone, and both produce false positives around legitimate mail-client migrations and mergers. Used together, and scored rather than blocked outright, they surface the small number of threads worth a human look — which is the realistic goal.
See what an attacker sees
We map your external attack surface the way an adversary does — exposed assets, leaked credentials, impersonation domains. No agent, no access, no cost.
30 min
A scoping call, with an engineer rather than a sales rep.
What it costs
Nothing, and there is no sequence afterwards. If we are not the right fit we will say so and suggest who is.
Under attack now?
Do not use this form. The hotline is answered around the clock and reaches a duty analyst directly.