I came across a recent fraud case in the Town of Plymouth that left me genuinely impressed by the level of sophistication — and how cleanly it bypassed every defence layer.

The recipe was straightforward:

  1. Break in quietly. Scammers compromised internal systems and harvested information about an ongoing project — vendor, contract, payment schedule.
  2. Build a convincing fake. They generated an invoice that looked completely legitimate — right amount, right project references, payment instructions formatted in the actual vendor’s style.
  3. Let trust do the rest. Finance saw what looked like a valid invoice for a real project and processed it. No alarms. No second-guessing.

A hefty sum left the organisation before anyone noticed.

Why this kind of attack works

The technical defences weren’t really the point. The scammers didn’t need to break encryption or escalate privileges in the moment of the fraud — they did that earlier, when nobody was looking, just to gather context.

The actual attack was a trust impersonation. They didn’t pretend to be a stranger asking for money. They pretended to be someone the organisation was already paying.

That changes everything about how you defend against it:

  • Email filters don’t catch it — the email looks normal
  • Anti-phishing training doesn’t help — there’s no obvious phishing signal
  • Approval workflows don’t catch it — the invoice matches a real project
  • The vendor doesn’t catch it — they have no idea their identity is being used

What it tells us

Two things stick with me from this one:

Data breaches are rarely the end of the attack. They’re often the reconnaissance phase. By the time you’re worrying about the leaked data itself, the scammers may already have used it to set up the next move.

Vendor identity is the soft underbelly of most finance workflows. Internal identity governance gets attention. Vendor identity verification — confirming that the entity sending an invoice is actually the entity you contracted with — usually doesn’t.

The harder question isn’t “how do we stop the breach” — it’s “what do we assume an attacker has already learned about us, and how would we notice if they used it?”