One Extra Letter. $7.3 Million Gone.
The attack that defeated H2-Pharma didn’t come through a vulnerability. It came through a workflow nobody had ever questioned.
Introduction
In April 2025, Josh B., Vice President of Commercial Operations at H2-Pharma, emailed a trusted contact at Cheplapharm, a pharmaceutical partner his company had worked with for over a decade. He was considering a routine change: switching from wire transfers to ACH payments to save on banking fees. A sensible business decision. A normal email thread. A familiar name in his inbox.
He even ran a $0.44 test transfer first. He was being careful.
By the time he realized something was wrong, he had wired more than $7.3 million to a bank account controlled by criminals who had been quietly watching his inbox for months. The attack didn’t defeat his technology. It defeated his process.
There was no malware. No outage. No alert. The only technical fingerprint was a single extra letter in a domain name: cheplapharm.com had become cheplapharrm.com. One additional “r”, buried in an email address most people read once and never look at again.
That’s it. That was the entire attack surface.
The Attack Your Security Stack Cannot See
Business Email Compromise (BEC) is now one of the most financially destructive forms of cybercrime — not because it is technically sophisticated, but because it is designed to look exactly like a legitimate business.
The attacker doesn’t trigger your endpoint protection. They don’t show up in your SIEM. They don’t fire a single alert. They read emails, they wait, and they insert themselves into a conversation at precisely the right moment.
According to Microsoft’s Digital Crimes Unit, the infrastructure that powered the attack on H2-Pharma — a platform called RedVDS — was available to criminals for as little as $24 a month. The asymmetry is almost absurd: weeks of patient surveillance, $24 in running costs, $7.3 million in returns.
No tool you currently own would have caught this. That is not a criticism of your tools. It is a statement about the nature of the attack.
The Question That Changes Everything
I ask a version of the same question in almost every new client engagement. I ask about password resets, about payment changes, and about access requests. It goes like this: “How do you verify that the person making this request is actually who they claim to be?”
I have asked it in two separate organisations, in different industries, in different years. Both times, I got the same answer: “Good question. We don’t really check.”
Not because those companies were negligent. Not because the people running IT were incompetent. Because nobody had ever asked the question out loud before. The process worked — until someone decided to exploit the assumption buried within it.
This is the structural problem with insider knowledge: you cannot see the assumptions you live inside every day. Someone who has worked across dozens of organisations carries a different kind of awareness — not because they are smarter, but because they have seen the same gap in enough different places to recognise it on sight. The question that sounds obvious in retrospect is only obvious once someone from outside the building finally asks it.
Josh B. at H2-Pharma wasn’t negligent either. He ran a test transfer. He was checking. But nobody had ever defined what a legitimate payment account change process looked like — so there was no out-of-band verification requirement, no callback to a known number, no second pair of eyes. The workflow ran on assumed trust. And assumed trust is an open door.
The Fix Is Embarrassingly Simple
For the password reset issue, the solution my clients implemented was this: whenever an IT engineer receives a request to reset credentials, they call the requester back at a number already on file. Not the number provided in the request. A known number. Always.
Zero cost. Implementable in an afternoon. No new tools required.
For payment account changes, the equivalent is just as straightforward: any modification to banking details requires a callback to a verified contact, confirmed through a channel that exists independently of the email thread where the request arrived.
I know what you’re thinking: “That’s it?”
Yes. That’s it. The gap isn’t technical sophistication. It’s the absence of someone asking the uncomfortable question before the attacker does.
The Deepfake Problem Makes This Urgent
Here is where the stakes change.
The callback defence works today. But the Microsoft report on H2-Pharma notes that hundreds of attackers are already using AI voice cloning and deepfake video to impersonate trusted contacts. The “call to confirm” step — which is the right instinct — is being actively stress-tested by the next generation of these attacks.
This means the callback must occur through a pre-established, out-of-band channel. Not a number from the email. Not a video call initiated by the requester. A number you already have, in a system you already trust, confirmed before any request is ever made.
The organisations that will handle this well are the ones that define what “normal” looks like before they need to defend it.
This Is a Posture Problem, Not a Tool Problem
H2-Pharma likely had antivirus. Probably a firewall. Possibly even email security tooling. None of it mattered because the attack never touched any of it.
The gap was upstream. It was in the absence of a verified process for a routine business event: changing payment details with a long-term vendor.
This is the difference between having security and having a security posture. A certificate documents your controls. A vCISO engagement surfaces the workflows nobody has ever questioned.
The question “how do you verify the person making this request is who they claim to be?” costs nothing to ask. The answer, when it is “we don’t really check,” costs everything to ignore.
Source: Microsoft Digital Crimes Unit, RedVDS case report, February 2026.
Paolo Carner is the founder of BARE, a cybersecurity advisory firm based in the Netherlands.
