## TL;DR
Hijacked threads borrow trust: the early messages are genuine, and the malicious reply comes from a compromised participant account or a lookalike that joins the chain. Anomaly detection misses it when the account behaviour looks normal or the model weighs thread history too heavily. Focus triage on the specific hostile message: its reply-to, its sending infrastructure and its request, then tune detection toward mid-thread anomalies.

```text
conversation hijacking phish failed to trigger anomaly detection
```

## Use this when
- A malicious message appears inside a legitimate multi-party thread.
- Recipients acted because the message continued a real conversation.

## Not for this skill when
- The whole thread is fabricated with a similar subject. That is themed phishing, not hijacking.
- The hostile message came from your own user account. That is an internal compromise incident.

## Steps
1. Isolate the hostile message and compare its full headers with earlier genuine messages in the thread. Verify: differences in origin, reply-to or client are documented.
2. Determine whether the sender account is compromised or impersonated: check sign-in and sending logs for the real owner. Verify: compromise versus lookalike is decided with evidence.
3. If compromised, secure the account, revoke sessions and sweep for rules and other hijack replies it sent. Verify: the account is contained and its sent items are reviewed.
4. Tune anomaly inputs: alert on reply-to changes mid-thread, new payment or attachment content in dormant threads, and first-time external participants joining internal threads. Verify: at least one new signal is live.
5. Warn the thread participants directly that one message in the chain is hostile, naming it by time and sender. Verify: every participant is notified, since the thread itself is the attack surface.

## Variant phrasings
### conversation hijacking thread phish anomaly missed
The hijack detection variant.
### reply to change mid thread phishing indicator
The reply-to signal variant.

Compatibility: Defender anomaly and mailbox intelligence signals, gateway thread analysis features.

## Why it happens
Anomaly engines score senders and accounts; hijacking keeps both looking ordinary and moves the anomaly into the conversation semantics, a layer most models sample weakly. The thread legitimacy that reassures users also reassures the model.

## Edge cases / pitfalls
- Dormant thread resurrection is a strong signal: a months-old chain reviving with a payment request deserves review.
- Preserve the full thread for investigation; participants deleting copies destroys the timeline.
- Brief staff that a familiar thread is not proof. Verify the request, not the conversation.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z6xtax9E_wZC2ppuAksApA