Ransomware at Belgian healthcare labs: what a small organisation can do today

A Belgian lab refused to pay after a ransomware attack. Could you? Back-ups, segmentation, MFA and NIS2, seen through an attacker's eyes.

Every day, more than 5,000 blood samples arrive at a clinical lab in Waregem, Belgium. From GPs, hospitals and care homes. In late October, that lab suddenly lost access to its own computer data. Samples had to be sent to other labs. That's what VRT NWS and HLN reported on 5 November.

The lab is clinical laboratory Maenhout. According to the police, it was a ransomware attack by a known hacker group, which is also said to be behind three similar attacks in Belgium. The attackers demanded a ransom. The lab isn't paying. Whether patient data was stolen is unknown. The company declined further comment.

We don't know how the attackers got in, and we won't guess. But this story will sound familiar to every small healthcare organisation in Belgium. And the question every CEO should ask right now is simple: could we refuse?

Why this is bigger than one lab

A lab is a link in a chain. When it goes down, GPs wait for results, hospitals reroute work and neighbouring labs are suddenly flooded. A healthcare cyberattack never hits just one company. It hits a supply chain.

Then there's NIS2. Under Belgium's NIS2 law, many healthcare organisations, including mid-sized labs, now face stricter rules. Board members are personally accountable for cyber risk management, and serious incidents must be reported fast. Ransomware in Belgium is no longer an IT problem. It's a governance question.

Through the attacker's eyes

At XPOSE, we think like the other side. What follows are scenarios, not a reconstruction of this attack and certainly not a manual.

The back-up is the first target, not the last. A ransomware gang wants you to pay. Your biggest obstacle to that is your back-up. So experienced attackers go looking for it first: the back-up server, the management console, the cloud storage tied to the same admin account. Only once that's wiped or encrypted do they encrypt everything else. Many companies find out on the worst possible day that their "back-up" was just a second disk on the same network.

Refusing is a technical choice, not a moral one. Not paying sounds brave. In practice, it's about preparation. You can only refuse if you have a copy the attacker couldn't touch: offline, or immutable (storage that can't be deleted or overwritten until a set date, not even with admin rights). And if you know how long restoring takes. A back-up you've never tested is a hope, not a plan.

The lab device is the silent back door. Analysers, software-driven centrifuges, fridges with sensors: labs are full of networked devices that often run outdated Windows and can't simply be patched, because the vendor certified them as they are. For an attacker, those are perfect hiding places. Nobody installs antivirus on them, nobody reads their logs. We wrote earlier about how this went wrong with supermarket refrigeration systems. In a lab, the principle is the same.

The vendor's remote access. Those devices are often maintained remotely. A VPN account or a remote support tool that's always on, without MFA, with a password unchanged for years. For an attacker, that's not a break-in. That's a key under the doormat.

They've been there longer than you think. Ransomware is the end of an attack, not the start. Before it, the attacker has often been inside for days or weeks, looking around, collecting privileges and quietly copying data out. That's why "was data stolen?" is so hard to answer. Even if you don't pay, you can still be extorted with stolen patient data.

What a small organisation can do today

1. Make at least one back-up unreachable. Offline or immutable, with separate credentials that don't live in your normal Active Directory. Don't ask "do we have back-ups?" Ask "can someone with domain admin rights delete them?"
2. Test the restore. Pick one critical system, such as your laboratory information system, and measure how long a full recovery takes. That number belongs in the boardroom.
3. Segment your lab and OT devices. Put analysers and similar devices in a separate network zone. They should only talk to what they strictly need. If the office network falls, the lab stays up, and vice versa.
4. MFA on all remote access. VPN, remote desktop, webmail, cloud admin, and especially vendor accounts. Open vendor access only when it's needed. As in our blog on the Barracuda mail gateway: internet-facing systems come first.
5. Know now who you'll call. Decide who makes decisions, who communicates and who handles the technical side. Report the incident to the CCB, Belgium's Centre for Cybersecurity, and file a police complaint. Under NIS2, reporting is mandatory for many healthcare organisations, often with an early warning within 24 hours.
6. Have your environment tested by someone who thinks like an attacker. Have someone check what's visible from the outside, and whether an attacker could get from a laptop to your back-up.

Final thoughts

The Waregem lab refuses to pay. That's the right instinct. But you don't make that choice on the day of the attack. You make it months earlier, when you decide where your back-ups live, who can get in from outside and which devices are allowed to talk to each other.

XPOSE Security tests your environment the way real APT attackers would: from forgotten vendor access to the back-up server that turned out to be reachable after all. Better we find it than they do. Get in touch and strengthen your security posture structurally with our CISO as a Service.