X-Rays Behaving Badly: Devices Give Malware Foothold on Hospital Networks

A report by the security firm TrapX warns that medical devices - including radiologic systems - are stepping stones for malicious attackers.
A report by the security firm TrapX warns that medical devices – including radiologic systems – are stepping stones for malicious attackers.

In-brief: serious breaches of hospital networks are almost certainly more common than has been reported, as compromised medical devices often hide the telltale signs of malware infection and data theft, according to a report from the security firm TrapX. 

A report from the security firm TrapX.  claims that attackers are using unprotected medical devices, including radiologic systems, to maintain a foothold on healthcare networks, avoiding detection by security software and IT staff.


Trusted Computing Group has how-to and demos with Microsoft, GE, Infineon, OnBoard Security, Wibu-Systems at IoT Solutions World Congress. Get your free expo pass code 111B9B47 or discount conference pass code 526E24AF

The report, which will be released this week, combines details from TrapX customer engagements with health care firms and company-sponsored analysis of common medical devices, including the Nova Critical Care Express (CCX), a blood gas analyzer. According to the report, medical devices – in particular so-called picture archive and communications systems (PACS) radiologic imaging systems – are all but invisible to security monitoring systems and provide a ready platform for malware infections to lurk on hospital networks, and for malicious actors to launch attacks on other, high value IT assets.

Among the revelations contained in the report:

  • A malware infection at a TrapX customer site spread from a unmonitored PACS system to a key nurse’s workstation. The result: confidential hospital data was secreted off the network to a server hosted in Guiyang, China. Communications went out encrypted using port 443 (SSL) and were not detected by existing cyber defense
    software, so TrapX said it is unsure how many records may have been stolen.
  • A healthcare institution at which installed its technology was found to have the Zeus and Citadel malware operating from infected blood gas analyzers in the hospital’s laboratory, which were infected and provided a “backdoor” into the hospital’s network and were being used to harvest credentials from other systems on the network.

“The medical devices themselves create far broader exposure to the healthcare institutions than standard information technology assets,” the report concludes.

Radiologic and medical imaging systems such as the PACS were particularly useful because they are heavily used and critical to the operation of almost every department. Of the three systems that TrapX found infected at customer sites, one was a PACS, the second was a medical x-ray scanner and the third was a collection of blood gas analyzers in a healthcare institution’s laboratory
department used by critical care and emergency services.

To help validate  its findings, TrapX acquired and tested a NOVA CCX blood gas analyzer of the type it encountered in the customer environments. As with the deployed devices, TrapX chose the version of the CCX for Windows 2000, which was the model  used in customer settings. And, in fact, Windows 2000 is the choice for “many medical devices.” The version that TrapX obtained “did not seem to have been updated or patched in a long time,” the company writes.

“Based upon our experience and understanding of MEDJACK, our scientists believe that a large majority of hospitals are currently infected with malware that has remained undetected for months and in many cases years. We expect additional data to support these assertions over time.” — TrapX Security

The TrapX team analyzed the CCX device, using an attack scenario based on what the company had observed in customer settings. Namely: malware infection and lateral movement by human attackers and automated malware.

[Read more Security Ledger coverage of medical device security here.]

No surprise: the device proved an easy target. TrapX’s team was able to use an exploit for a known weakness in the Windows 2000 operating system to establish what TrapX refers to as a “pivot” – or point of control- on their test network from which they could attack other systems. After creating a backdoor into the device, TrapX researchers added a new user to the system and decrypted the local user password. The company was then able to extract the database files that would contain medical information.

TrapX said the problem of insecurity with these devices is manifold. For one: there are no true “security products” designed to run on medical devices. Beyond that, hospitals may worry that software updates to these systems may jeopardize their FDA certifications – a belief that TrapX and others have noted is false.

The research is just the latest to raise serious concerns about the safety of software running critical medical devices and management systems within hospitals and other clinical settings. In May, for example, independent researcher Jeremy Richards wrote a detailed analysis of the Hospira LifeCare PCA 3 drug infusion pump, calling it the “least secure IP  enabled device” he had ever worked with.

Among other things, Richards noted that the device was listening on Telnet port 23. Connecting to the device, he was brought immediately to a root shell account that gave him total, administrator level access to the pump. “The only thing I needed to get in was an interest in the pump,” he said.

The TrapX research echoes some of Richards’ findings. In addition to running on unpatched Windows 2000 systems, the NOVA CCX devices use default SQL database administrator (DBA) permissions to protect access to the device’s back-end database, which holds patient data. Additionally, the device backed up its database to the local drive of the Windows system it was connected to – providing a wealth of data to anyone who compromised that system.

TrapX said the implications of its research were dispiriting. Simply put: the presence of medical devices on healthcare networks may make them more vulnerable to attack, especially now that sophisticated actors have set their sites on healthcare data. Echoing a statement that has now become a mantra in the information security field, the TrapX reports suggests that the healthcare field is divided into hospitals that have been hacked and those that haven’t yet discovered that they’ve been hacked.

“Based upon our experience and understanding of MEDJACK, our scientists believe that a large majority of hospitals are currently infected with malware that has remained undetected for months and in many cases years. We expect additional data to support these assertions over time,” the report reads.


  1. So they let people surf the web on Windows-running blood gas analysers?

    What happened
    to running hospital systems
    on Digital equipment,
    like in yesteryear?

    Or maybe locking down this equipment in the first place?

    TrapX, you seem FUDdy.

  2. Pingback: Four short links: 9 June 2015 - O'Reilly Radar

  3. Pingback: Security and Technology Briefs: Augmentation Sec, OPM, Hospitals, Kaspersky | Neurovagrant

  4. Pingback: The World is Already Leaving Microsoft Windows Behind, in Favour of ODF, Free Software, and GNU/Linux (Usually in Turn) | Techrights

  5. Pingback: ‘Medjacking’ on the rise | SensorHound Inc.

  6. Ted Mittelstaedt

    The issue isn’t allowing people to surf the web on blood gas analyzers.

    The issue is these devices generally use Windows as an operating system. The blood gas analyzer company puts all of it’s software development time into writing the app that runs on top of Windows, and it ignores any security implications of the operating system itself.
    Then it releases an “embedded” version of Windows which is basically a raw Windows load right on a hard disk inside the tool.

    These tools are generally designed to connect to the network either permanently or temporarily and upload data. The problem is if some other device – like a PC that IS surfing the web on the same network – gets infected, the virus will scan the local network and insert itself into the blood gas analyzer. And then even if the PC is later caught and cleaned, the analyzer remains an infection source on the network.

    You do understand, don’t you, that writers of identity theft software generally try hard to make their software unobtrusive, and they spend a lot of time debugging to make sure it doesn’t cause systems it infects to run slow or be otherwise noticed.

    • Hey there. No relation to the original poster, but I’ve been wondering — would something like DeepFreeze or some sort of liveboot scenario (which is to say, the distro and its software resets itself each boot) help to mitigate this sort of thing? I know the data itself can carry bugs (and obviously the analysis data gets stored somewhere), but at that stage someone would have to really be targeting things (and repeatedly). Why aren’t more IoT devices more or less ‘memoryless’ (which is to say, burnt-in and reset each time), requiring something like a very specific bootkit if there was an actual desire to target such a thing? It wouldn’t solve all of the problems, but wouldn’t it solve the biggest ones (especially when it comes to persistence)?

      • Hey Harry – I think that is an option for certain kinds of endpoints and scenarios. Obviously, virtual container companies are trying something like that as a replacement for single-tenanted endpoints in the enterprise market. With IoT, its an option, for sure. The problems are – as you say: in-memory threats. Also, in the context of IoT, many of these endpoints may be “up” for days, weeks, months – even years between reboot/reset. It’s not like a windows laptop or desktop where you shut it down at the end of the work day. So even in-memory malware can provide long-term access for attackers, right?

        • Quite true. Maybe the best mitigator is just to go back to how things used to be — which is to say, go the obscurity route — pick a different networking stack, pick a different OS (not (a) Windows, (b) Linux)? Plus, boot times now are getting obscenely quick, so I don’t really see a good excuse for not rebooting devices more often anyway, and that can be automated.

          Is there anything preventing (at least) hospital equipment from just flushing/flashing daily automatically at a time they’re not likely to be used (with manual stopgap available)? If we’re talking about malware transiting, I honestly believe going back to an obscure operating system (QNX, OpenBSD, even hardened Gentoo with its toolchain removed after build) is the key to preventing threat overlap, at least from typical profit-making or mayhem-intending generalized malware.

          Yeah, I know that’d create a hiring and compatibility headache and its own niche attack vectors, but it wasn’t so long ago that hospital systems were running unix-based OSes in a world that mostly knew mainframes and PCs — that was far more complex; most embedded stuff never gets poked at other than reboots, anyway, so it’d be more of a supplier-end choice I’d like to see.

          While I can see your point about virtual containers, I find them more likely to exacerbate the problem, not solve it. Security generally favors heterogeneity; few attackers have the skills, time or tenacity to deal with several stacks at once. Like the old safe-cracking rating system: make it harder to get in, and rate it based on how long it takes; assume it’s breakable, but make it HAVE to be targeted.

  7. Pingback: Epidemic: Researchers Find Thousands of Medical Systems Exposed to Hackers | The Security Ledger