What is email thread hijacking, and how do you spot it?

Thread hijacking is the most convincing kind of phishing because it doesn't look like phishing. The message comes from someone you know, in a conversation you started, from their real mailbox. This guide explains how the attack works, why your email authentication can't flag it, and the verification habits that stop the payment or the password from leaving.

What is email thread hijacking?

Thread hijacking, also called a reply-chain attack or conversation hijacking, is when an attacker inserts a malicious message into an existing email conversation. CISA's Emotet advisory describes the technique as "stealing an existing email chain from an infected host to reply to the chain", adding a malicious attachment "to trick recipients into opening the file."

It comes in two forms:

The first form is the harder one, and it's the focus of this guide. The second is defeated by checking the full address, which our guide to how to spot a phishing email covers.

How does a thread hijacking attack work?

Microsoft has documented several real campaigns that follow the same pattern. In a 2023 case, "the attack started with a phishing email from one of the target organizations' trusted vendors" whose mailbox had already been compromised (Microsoft Threat Intelligence). The typical sequence:

1. Get into a mailbox. Usually by phishing the password, often with an adversary-in-the-middle kit that also captures the MFA session.
2. Read. The attacker searches for conversations about invoices, payments, contracts or shared files.
3. Hide. They create inbox rules that move or delete replies so the real owner doesn't notice. In one campaign the rule moved mail to the Archive folder and marked it as read.
4. Reply. They answer inside a live thread, or revive an old one, with new bank details, a link to a "shared document", or an attachment.
5. Spread. They mail the victim's contacts. Microsoft counted "more than 16,000 emails sent to the target's contacts" in the 2023 case and "more than 600 emails" in a January 2026 campaign against energy-sector organizations (Microsoft).

The speed can be startling. In Microsoft's 2022 investigation, "it took as little time as five minutes after credential and session theft for an attacker to launch their follow-on payment fraud."

Why do SPF, DKIM and DMARC pass?

Email authentication answers one question: did this message come from a server the domain owner authorizes? In a hijacked thread, it did. The attacker is signed in to the supplier's genuine Microsoft 365 or Google Workspace account, so the message leaves through the supplier's own servers and carries the supplier's DKIM signature.

The reply also threads perfectly. Mail clients group messages using the In-Reply-To and References header fields defined in RFC 5322, section 3.6.4. A reply sent from inside the mailbox sets them correctly, so the malicious message sits in the conversation as if it belonged there.

That doesn't make authentication useless. It still stops the cheaper attacks: strangers forging your supplier's exact domain. See SPF vs DKIM vs DMARC for what each one covers. It just can't tell you that a real account is in the wrong hands.

What are the red flags of a hijacked thread?

Because the address and authentication are clean, the clues are in what the message asks you to do:

• New payment details. A changed bank account, a "new remittance address", or a request to pay an invoice early. This is the classic goal; see vendor invoice fraud.
• A sign-in to view a document. A link to a shared file, e-signature or voicemail that asks for your Microsoft 365 or Google password. In Microsoft's 2026 case, the lure was a SharePoint link that required sign-in, dressed up as an ordinary document share.
• An unexpected attachment. Especially a password-protected archive, which filters can't open. The password in the email body is a warning sign. Our guide to dangerous attachment types lists the risky ones.
• A revived old thread. A reply to a conversation that ended months ago.
• A change in tone. Shorter sentences, different sign-off, odd phrasing, or a writing style that doesn't match earlier messages.
• Pressure and secrecy. "Please handle this today", "I'm in meetings, don't call."
• A different Reply-To. Replies quietly go to another address. Check it before you hit send.
• Recipients dropped or added. People who were copied on every earlier message are suddenly missing.

The FBI's IC3 also advises you to "verify the email address used to send emails, especially when using a mobile or handheld device" (IC3, 2024). That catches the second variant, where the thread is real but the sender is not.

How do you verify a request in a hijacked thread?

The rule is simple: the channel that made the request can't confirm it. If the mailbox is compromised, replying "is this real?" goes straight to the attacker.

1. Don't reply or click. Leave the message where it is.
2. Call a known number. Use the phone number in your supplier file, contract or a previous invoice, never one from the email or its signature.
3. Ask a specific question. "Did you send new bank details on Tuesday?" rather than "Is everything OK?"
4. Inspect the headers. Paste them into the Email Header Analyzer to see the real sending server, the Reply-To and the authentication results. A pass means "from their real system", which is exactly what you'd see in a hijack.
5. Require a second approver for any payment change, as the FBI recommends using "secondary channels and/or two-factor authentication to verify requests for changes in account information."
6. Report it. Forward it to IT or use your phishing report button so others in your organization are warned.

What should you do if a supplier's mailbox was compromised?

Once a supplier confirms the compromise, treat everything from that account during the attack window as suspect.

1. Tell the supplier by phone what you received and when. They may not know yet.
2. Hold payments to that supplier until bank details are confirmed through your normal verification process.
3. Temporarily block or quarantine mail from the affected address. Our guide to blocking a sender in Microsoft 365 shows how.
4. Search your mail for every message from the account in the window, and remove any still sitting in inboxes.
5. Find out who clicked. Anyone who opened a link or entered a password should follow what to do after clicking a phishing link, and an admin should check their account for new rules and sign-ins.
6. Report losses. If money moved, call your bank immediately and file at ic3.gov in the US.
7. Re-trust slowly. Ask the supplier what they did. Microsoft warns that in session-theft attacks "password reset is not an effective solution"; they also need to revoke sessions and remove MFA methods the attacker added.

How do you stop your own mailboxes being used this way?

Your customers face the same risk from your accounts. The controls that matter most:

• Phishing-resistant MFA for finance, executives and admins, so a stolen password and session cookie aren't enough. See AiTM phishing and MFA bypass.
• Block external auto-forwarding and watch for new inbox rules. See malicious inbox rules and forwarding.
• Restrict which apps users can approve, so a malicious app can't read mail without a password. See OAuth consent phishing.
• Filter inbound phishing before it reaches the mailbox that gets compromised in the first place.
• Tell customers how you work. For example: "We never change bank details by email."

Next steps

1. Write down your payment-change procedure, with the callback step, and share it with accounts payable today.
2. Add a line to supplier onboarding that records a verified phone contact for each one.
3. Check your own mailboxes for unexpected forwarding and inbox rules. It takes minutes.
4. Reduce the phishing that leads to compromised mailboxes. iBlockSpam filters phishing, spoofing and malware at the MX before mail reaches Microsoft 365, Google Workspace or cPanel; see how it works.

Browse our other phishing and threat guides.