HackCert
Advanced 9 min read April 12, 2024

Advanced Tactics in Medical Device Security

Pacemakers, infusion pumps, MRI consoles, and HL7 networks — the security of devices that keep patients alive.

Rania Imran Qadri
Red Team Operator
share
Advanced Tactics in Medical Device Security
Overview

Medical devices sit at the intersection of life safety and cybersecurity. A vulnerable infusion pump can deliver a fatal insulin dose; a compromised pacemaker can be triggered to deliver an unwanted shock; an unpatched MRI workstation can hold an entire radiology department hostage to ransomware. The FDA, MHRA, and PMDA have responded with binding cybersecurity premarket guidance, but the installed base of devices — many over a decade old, many running unsupported Windows XP Embedded — remains an enormous attack surface.

Core Concepts

The Internet of Medical Things (IoMT) spans an extraordinary range:

  • Implantable devices — pacemakers, ICDs, insulin pumps, neurostimulators.
  • Wearable devices — continuous glucose monitors, ECG patches.
  • Bedside devices — infusion pumps, ventilators, anesthesia machines, patient monitors.
  • Imaging modalities — CT, MRI, X-ray, ultrasound, with operator consoles running standard Windows.
  • Lab analyzers, robotic surgery systems, clinical workstations.
  • Backend systems — Electronic Health Records (EHR), Picture Archiving and Communication Systems (PACS), HL7/FHIR interfaces.

Key protocols include HL7 v2 (TCP, port 2575, mostly cleartext), HL7 FHIR (REST/JSON), DICOM (medical imaging, port 11112), and proprietary device protocols often running over TCP/IP on flat hospital VLANs.

The security model is shaped by clinical risk: patches that might destabilize a Class III device require FDA-coordinated re-validation, which is why a vulnerable embedded OS may legitimately live for 15 years. This drives a compensating-controls strategy more than a patch-everything one.

The Hospital Attack Surface

Inside a typical hospital, a flat /16 network often hosts everything: workstations, EHR servers, infusion pumps, imaging consoles, and IoT building-management devices. From a single phishing-compromised laptop, an attacker can reach:

  • Hundreds of infusion pumps with telnet management ports.
  • PACS servers with un-authenticated DICOM listeners.
  • Patient-monitor central stations on default credentials.
  • Building HVAC controllers that share the same VLAN.

The Medjack research (TrapX, 2015) showed adversaries pivoting from imaging consoles — where patches are forbidden — to PHI-rich EHR backends, knowing the medical devices would not be reimaged or remediated.

Network-Level Attacks on Medical Protocols

HL7 v2 messages encode patient demographics, lab orders, results, and ADT (admit/discharge/transfer). Cleartext over TCP with no authentication means a Wireshark capture or ARP-spoof reveals every patient interaction. Injection attacks (modifying lab values mid-flight) have been demonstrated in lab environments.

DICOM servers historically accept stores from any AE Title that connects. Researchers have demonstrated:

  • Adding or removing nodules in CT scans (Mirsky et al., 2019) — a credible attack on diagnoses.
  • Embedding executable PE files inside DICOM preamble bytes, which display normally in viewers but execute when opened on legacy systems.
  • Mass exfiltration of patient images from internet-exposed PACS — Greenbone Networks found 24M+ records exposed globally.

Proprietary device APIs — many vendors run JSON REST or RPC interfaces on bedside devices with weak or no authentication. A 2019 ICS-CERT advisory (BD Alaris) disclosed that pump configurations could be modified over the network without credentials.

Wireless and Implantable Attacks

Implantable Cardiac Defibrillators (ICDs) and pacemakers communicate via short-range RF (Medtronic CareLink, Boston Scientific, Abbott Merlin@home). Researchers (Halperin et al., 2008; Marin et al., 2018; Rios/Butts ongoing) have demonstrated:

  • Eavesdropping on telemetry to recover device serial numbers and patient data.
  • Replay attacks to trigger device commands.
  • Battery-drain attacks via repeated wake-up signals.
  • Shock-delivery commands on legacy ICDs without authentication.

Insulin pumps (Medtronic MiniMed 508/715, more recent models) have been shown vulnerable to remote-dosage modification — the FDA issued recalls in 2019.

Bluetooth Low Energy is the new short-range standard for CGMs and wearables. Pairing flaws, replay weaknesses, and lack of payload encryption have all been disclosed.

Imaging Console and Workstation Attacks

Imaging consoles often run a slim Windows OS configured by the OEM and locked from IT updates. The result:

  • Windows 7 / XP Embedded long past EOL.
  • Default OEM administrator passwords shared across thousands of devices.
  • Network shares for image transfer with weak ACLs.
  • Anti-virus exclusions covering critical executable paths.

Ransomware affiliates — WannaCry (2017, NHS hit hardest), Ryuk, Conti, BlackCat — have repeatedly devastated imaging operations because a single ransomed CT or MRI console halts entire scanning workflows.

Real-world Examples

WannaCry (2017) halted 80+ NHS Trusts in the UK, forcing patient diversions and surgery cancellations. Many imaging modalities running Windows 7 went down for days.

Hollywood Presbyterian (2016) paid $17,000 ransom in early ransomware-vs-hospital event.

Universal Health Services (2020) — Ryuk attack disrupted 250+ hospitals across the US, requiring paper charting for weeks.

Düsseldorf University Hospital (2020) — a ransomware attack that forced a patient transfer was investigated as contributing to a fatality, the first death credibly linked to a cyber incident on a hospital.

Ireland HSE (2021) — Conti ransomware crippled the national health service for months; recovery costs exceeded €100M.

Change Healthcare (2024) — ALPHV ransomware against a US health-data clearinghouse delayed insurance claims and prescription processing nationwide.

Best Practices & Mitigation

Regulatory landscape — FDA Premarket Cybersecurity Guidance (2023), EU MDR cybersecurity requirements, PRE-CERT programs, and the PATCH Act / Omnibus Section 524B require SBOMs, coordinated vulnerability disclosure plans, and lifecycle security plans.

For manufacturers:

  1. Secure-by-design — threat model per IEC 62443 and AAMI TIR57, document security risks in the design history file.
  2. Provide and maintain an SBOM for the lifetime of the device.
  3. Sign firmware and verify with hardware root of trust; support OTA updates without breaking validation.
  4. Authenticated, encrypted communications for all interfaces, including implantable telemetry (BLE LE Secure Connections, dedicated programmer authentication).
  5. Per-device unique credentials at provisioning; never ship with default passwords.
  6. Coordinated Vulnerability Disclosure program with clear contact and SLA.
  7. Customer security documentation (MDS2, manufacturer disclosure statement for medical device security) accurate and updated.

For hospital security teams (HDOs):

  1. Inventory IoMT with passive discovery tools (Medigate, Claroty xDome, Armis, CyberMDX).
  2. Network segmentation — isolate medical devices into purpose-built VLANs, deny lateral traffic, allowlist only required protocols.
  3. Patch governance — coordinate with biomedical engineering, follow vendor-approved patches, and apply compensating controls where patches are forbidden.
  4. 24/7 monitoring with clinical-context-aware detection (a CT scanner suddenly making outbound HTTPS to Eastern Europe is an incident).
  5. Tabletop exercises that include downtime procedures, paper charting, and patient diversion plans.
  6. Vendor risk management — require SBOMs and security attestations during procurement; reject devices that cannot be patched or that ship with shared default credentials.
  7. Backup, test restores, and segment backups off the production network.
Key Takeaways

Medical device security demands a balance unique to the field: the conservatism required when software changes can kill patients, against the urgency required when those same patients can be killed by software left unchanged. The technical attack surface — HL7, DICOM, BLE telemetry, embedded Windows consoles — is broad and well-documented. The path forward combines regulator-enforced manufacturer accountability, hospital-side network segmentation, and a culture in clinical engineering that treats cybersecurity as a patient-safety issue first and an IT issue second.

Ready to test your knowledge? Take the Medical Device Security MCQ Quiz on HackCert today!

Related articles

back to all articles