The Email That Needed No Introduction: Anatomy of a Payroll Thread Hijack

There's a particular kind of spam that doesn't look like spam at all, and it's the one giving UK finance teams the most grief in 2026. It arrives as a reply. It carries the right subject line, the right quoted history, the right sign-off. It comes from an address you've emailed a dozen times before. Nothing about it is novel, and that is precisely the point.

Conversation hijacking — sometimes called thread hijacking or email account takeover fraud — works on a simple asymmetry. Most filtering is built to spot newness: a domain nobody's seen, a link nobody's clicked, a sender with no history. Hijacked threads have none of those tells. The domain is genuine. The link (if there is one) often isn't a link at all. The history is real because it happened.

Why a reply beats a cold approach

Think about how your mail gateway scores a message. Fresh domain, no sending reputation, mismatched display name, URL with a young registration date — all of that nudges the score toward "quarantine". Now imagine the opposite: an established domain that passes SPF, has a long DMARC alignment record, and sits in a thread you started two weeks ago.

There's nothing to demote. Authentication is genuinely passing because the mail is genuinely from that mailbox. The attacker isn't spoofing anyone; they're sitting inside a real account, using it as a puppet. SPF, DKIM and DMARC answer the question "did this come from the domain it claims?" and the answer is yes. They've never claimed to answer "was the human at the keyboard the right one?"

That gap is where payroll fraud lives.

The turnaround, step by step

Picture a mid-sized UK firm — say forty staff, a finance manager, an outsourced payroll provider. Here's the pattern we keep hearing described in almost identical terms:

1. A member of staff clicks something they shouldn't on a personal-ish login, or reuses a password that surfaced in an old breach. No drama, no alarm.
2. The attacker doesn't blast out emails. They read. They sit quietly for days, mapping who talks to whom, who approves what, when payroll runs.
3. They set a mailbox rule — often a subtle one, like moving anything from the payroll provider or from the finance manager into an "Archive" or "RSS" folder. The human never sees a bounce, never sees a warning.
4. When the real payroll thread appears, they reply in-thread: a short, plausible note about updated bank details, a new account, an apologetic line about the old one being closed. Sometimes there's a PDF on a file-sharing link, sometimes just text.
5. The reply lands in the finance manager's inbox looking like a continuation of a conversation they were already having. Payment goes out by Faster Payments. It's gone in seconds.

The reason this stings so much is that every individual step is small. There's no dramatic hook. The scam is essentially “the thread continued, but with a different person typing”.

The checks that actually break the chain

You can't filter your way out of this one, so the useful controls are operational. Four of them do most of the work.

1. Audit the mailbox rules you didn't write

Forwarding rules and folder rules are the attacker's favourite persistence mechanism, and they're frequently invisible until someone looks. If your platform supports it, review rule changes centrally, alert on rules that auto-forward externally or auto-delete, and check the list monthly. A rule that quietly redirects anything from your bank or your payroll provider is a red flag the size of a house.

2. Make MFA boring and phishing-resistant

Password-only logins are the front door. Push-based MFA helps, but is vulnerable to prompt-bombing and real-time relay kits. Where you can, move finance and payroll accounts to passkeys or hardware keys. Where you can't, at minimum alert on logins from new countries and unfamiliar devices — the attacker needs a session, and sessions leave fingerprints.

3. Call back, on a number you already had

Bank-detail changes should never be confirmed by email. Never. The rule is: any change to payment details triggers a callback to a number already on file — not one supplied in the message. It's slow, it's mildly annoying, and it's the single highest-value control in this whole article. Make it a written policy and make it apply to the boss too, especially to the boss.

4. Give people a one-click way to say "this feels off"

Your staff are the only sensors inside the thread. If reporting a suspicious email takes three forwards and a phone call to IT, they'll just delete it and move on. If it takes one button, you get telemetry — and you get a chance to check whether anyone else in that thread received the same reply. Reporting workflows are a detection tool, not a courtesy.

The first hour after a hit

If a payment has already gone, speed matters more than elegance. Call the bank's fraud line immediately — Faster Payments can sometimes be recalled if flagged fast enough. Reset the compromised account's password, revoke active sessions, and audit its rules and forwarding. Check whether the same mailbox sent anything else in the preceding days. Report it to Action Fraud and, if personal data was exposed, consider your UK GDPR notification obligations. Then tell the payroll provider, because the attacker may have been in that relationship for longer than you think.

The uncomfortable takeaway

Thread hijacking works because it exploits something we're right to rely on: context. The message really is part of a conversation. The sender really does work there. The trust isn't misplaced — it's been borrowed without permission.

The fix isn't to distrust your colleagues' emails. It's to stop treating email as an authorisation channel for money, and to build a small, stubborn set of rituals — the callback, the rule audit, the report button — that hold up even when the thread looks perfect.