Nobody clicked anything. That is the part that unsettles the IT lead when a supply chain attack finally surfaces. There was no dodgy email opened on a night shift, no nurse who fell for a fake login page. The records system simply pulled down its scheduled update, the way it had every month for two years, and that update carried the attacker in. By the time the encryption started, the malware had arrived through the one channel the hospital had been told to trust. This post is about that channel. Not how to vet a vendor, that is a separate job, but how the attack itself actually travels: the five routes a compromise takes to reach a hospital, and why each one survives the defences you already have.
A supply chain attack does not break down the front door. It walks in behind something you already let through: a signed update, an allow-listed support session, a device you bought from a reputable maker.
The logic is simple and that is what makes it dangerous. Instead of attacking one hospital, the attacker compromises something many hospitals depend on, then lets the normal flow of business do the delivery. One breach, many downstream victims. You may never have been the target. You were just connected to the thing that was.
// 01 Five paths a compromise takes to reach a hospital
Path one: the tainted update. The attacker breaks into the vendor's build pipeline, the machinery that compiles and signs the software, and slips malicious code in before the release is packaged. The hospital receives a properly signed update from the right server and installs it without a second thought. This is the SolarWinds pattern from 2020, and it is the cleanest of the five because every check passes. The signature is valid. The source is genuine. The code is poisoned. For a hospital running a vended EMR or laboratory information system that updates on a schedule, this is the path with the fewest warning signs.
Path two: dependency poisoning. Modern software is assembled, not written from scratch. Your EMR vendor pulls in open-source libraries, which pull in their own libraries, several layers deep. An attacker who plants malicious code in one popular package, or registers a name close to a real one so a careless build grabs the wrong thing, rides that package into every product built on top of it. The hospital never deals with that library directly. It arrived inside software you bought from someone you trust, and your vendor may not have noticed it either.
Path three: stolen vendor remote-support credentials. This is the one that lands most often in Nigerian facilities, and it has nothing to do with code. Your EMR support is handled remotely. The vendor's engineers hold a standing account on your systems, often with broad rights, and their support IP is allow-listed through the firewall so sessions are not blocked at odd hours. An attacker who phishes or buys those engineers' credentials inherits all of it: a trusted login, an open path through the firewall, and a reason for nobody to ask questions. They are not breaking in. They are signing in.
Path four: the managed service provider pivot. Plenty of Nigerian hospitals do not run their own IT at all. They hand it to a managed service provider, and that provider runs the same remote-management agent on every client it serves, all driven from one console. So the attacker does not need your hospital. They need the provider. One compromised console pushes to fifty hospitals at once, each one receiving the payload the way it receives a routine patch, because to the agent that is exactly what a routine patch looks like. The blast radius is not your facility. It is the provider's entire book of business, and you are simply on the list.
Path five: medical-device firmware. Infusion pumps, patient monitors, imaging machines and lab analysers run embedded software that is updated rarely, supported for years, and frequently sits on the same flat network as everything else. Tampered firmware, or a device shipped with a known weakness that never gets patched, turns a clinical machine into a quiet foothold inside the ward. This is the path people find hardest to picture, and the one that most directly touches a patient at the bedside.
// 02 Why you trusted it: the kill chain in plain terms
Every one of those paths works for the same reason. The thing carrying the attack was already on your trust list. A signed update passes because the signature proves it came from the vendor, and it did, the vendor was just compromised first. An allow-listed support session passes because you decided long ago that this vendor's traffic should not be questioned. A managed service provider's push passes because that is literally its function. The kill chain does not begin with a break-in. It begins with a decision you made for good operational reasons, then borrows the access that decision granted.
This is why "we have a firewall and antivirus" misses the point. Those controls are built to keep out what does not belong. A supply chain attack arrives as something that does belong, riding a trusted signature, a trusted IP, a trusted account. The defence is not a thicker wall at the perimeter. It is the assumption that even trusted channels can turn, and the monitoring, segmentation and access limits that let you catch one when it does.
// 03 Why a hospital is an attractive downstream target
Two structural features make hospitals worth reaching this way. The first is the flat network. In many Nigerian facilities the EMR, the billing system, the lab machines and the infusion pumps share one address space with no real separation, so a foothold on any of them is a foothold on all of them. The second is multi-tenant SaaS: a single cloud EMR serving many hospitals from one platform means an attacker who reaches the platform reaches every tenant behind it. Add the obvious motive, sensitive patient data on systems where downtime threatens care and therefore raises the pressure to pay, and the maths favours the attacker.
Detection is harder here than for ordinary intrusions, but not impossible, and the signals are specific. A trusted vendor account logging in at an hour it never normally does. A support session that opens, then starts touching systems outside the support remit. An update that lands and is followed by a service reaching out to an address it has never contacted before. East-west traffic on a flat network, one clinical machine quietly talking to another it has no reason to. None of these requires exotic tooling. They require that someone is watching the trusted channels with the same suspicion they apply to the untrusted ones.
The question that separates a supply chain attack from plain negligence is whether the failure was yours to prevent. If a signed update from a compromised vendor encrypted your records, you were attacked. If you ran an unsupported EMR for three years and left default passwords on the lab server, that is a different conversation.
That distinction matters for more than pride. Under the Nigeria Data Protection Act, a hospital is the data controller for its patients' records, and a supply chain attack does not erase that duty: a breach reaching you through a vendor is still a breach you may have to notify the NDPC about. So the line is real but narrow. You are not expected to out-engineer a vendor's build pipeline. You are expected to know which vendors can reach your systems, to limit what each one can touch, and to notice when a trusted channel starts behaving in a way it never has before.
- Five paths, one logic. Tainted update, dependency poisoning, stolen vendor support credentials, MSP pivot and medical-device firmware all deliver the attack through something you already trust.
- The signature is not the safeguard. A valid signature proves the vendor sent it, not that the vendor was clean when they did.
- Flat networks and shared SaaS make hospitals worth reaching. One foothold spreads because nothing inside is separated, and one platform serves many tenants.
- Watch the trusted channels. A vendor account logging in at an odd hour, a support session straying off remit, or a service phoning a new address after an update are the signals that matter.
- Attacked is not the same as negligent, but under the NDPA you remain the controller, and a vendor-routed breach is still yours to notice and report.
Which of these five paths can reach your hospital?
Our senior penetration testers map the vendors, support sessions and connected devices that can touch your network, then test whether a compromise on any of them would spread. Start with a conversation about what is actually connected to your records.
Contact Us