Healthcare’s Anatomy:
Exposing DICOM and critical vulnerabilities in healthcare systems

Before diving into this article, and for better understanding, it is strongly recommended to read the previous article on DICOM, which covers its description and usage. In previous publications on HL7 and DICOM, it was observed that traffic encryption was not consistently implemented when these services were set up. Several risks were discussed in the HL7 article, but it was decided not to delve deeply into this topic when describing DICOM. As a result, this section will focus on the risks posed by open DICOM traffic and the various malicious actions possible on these interfaces without any authentication.

The replication of any or all of the elements demonstrated in this article is punishable and could have extremely severe consequences. Never perform these actions on an unauthorized or uncontrolled network.

During the research for this article, it was found that approximately 5,300 DICOM servers have an interface exposed on the web, according to Shodan. The majority of these servers are located in the United States, with 1,400 in that country and 118 in France.

The risks associated with the exposure of these machines may seem abstract. Each of these servers could potentially contain personal patient information stored on these exposed systems. To better understand the implications of these potential attacks, it is necessary to recreate a similar infrastructure.

To do this, there’s no need to purchase acquisition hardware; a PACS can be replicated along with its image viewer.

Creating a test instance

There are several GitHub repositories allowing for the quick installation of a PACS server and its DICOM image viewer. The most interesting for this test is the OHIF with Orthanc project, as it allows for a quick setup of a containerized infrastructure without requiring too many resources.

As the project name suggests, the chosen PACS server is Orthanc. Developed and maintained by the University of Medicine in Louvain, Orthanc is widely used around the world. The image visualization is handled by the OHIF application, created by Massachusetts General Hospital.

To populate the exam database, anonymized open-source DICOM images were used.

Here’s what can now be viewed in the OHIF WebUI:

Radiographic visuals are available as follows:

Concerning the Orthanc part, here is a visual of the DICOM image search interface on the PACS:

Extraction Attack  

In the default configuration available on GitHub, the Orthanc server cannot exchange information with entities other than the viewer. As explained in the previous article, DICOM modalities must necessarily exchange with the server to perform their role.

To recreate a compromise scenario that is as close to reality as possible, the following steps will be taken:

• Initial discovery phase of DICOM interfaces
• Brute-forcing AE Titles. An AE Title (Application Entity Title) is a string identifier used in DICOM communications to uniquely identify an application or device (such as a scanner, workstation, or PACS server) on a network. This step will allow for more discreet enumeration.
• Enumeration of data and extraction of DICOM objects (X-rays) from the PACS

This demonstration will culminate in an attack on DICOM files and an assessment of the associated risks.

Before detailing the various phases of the operational scenario, some reminders are necessary. The attacks will not be carried out by exploiting vulnerabilities in the Orthanc or OHIF applications.

Previously, to access the different panels shown in the screenshots, credentials were used, which will not be the case during the attack. The goal of this demonstration is to replicate malicious actions that a third party could perform online to access and/or modify data with the intent to harm a patient or sell their data. A related goal of this demonstration is to allow for the creation of network detection rules.

Brute-forcing AE Titles

Pre-brute-force reconnaissance  

In this phase of testing, the goal is to gather as much information as possible about the open service to identify the necessary means for the subsequent attack. To do this, the NSE DICOM-ping script is used to query the interface. For this phase, modifications to the NSE library were necessary to handle certain errors in DICOM packets.

The NSE command returns the following:

In this first capture, the script output confirms that the attacked server does indeed have a DICOM port. Additionally, thanks to the “Called AET check enabled” indication, the attacker can deduce that AE Title enumeration is possible.

With Wireshark, it is possible to analyze traffic and examine the request sent and received by our machines:

In this second Wireshark capture, the presence of the term “reject” identifies an important element. Not just any AE Title will be accepted to initiate an exchange with the PACS server. This information is significant because it allows for several logical deductions corroborated by the network capture and the NSE command return.

First, in order to communicate with the PACS server, it will be necessary to find the name (AE Title) of a device authorized to exchange data with the PACS server. Device name verification is not installed/configured by default on all PACS servers. When this identification is in place, it indicates that the operators are familiar with their DICOM network. However, this does not constitute a security measure since everything is transmitted in clear text, and it is very easy to spoof an AE Title. On the other hand, it may slow down the attacker or force them to change their strategy.

AE Title Brute-forcing 

The next step is to enumerate the AE Titles that can be used to initiate a connection with the PACS server. To do this, a predefined list of machine names, based on a study of open-source servers on the market, was established. Some common names were also added to this list.

Despite the elements in the Nmap screenshot, an AE Title matching the one expected by the Orthanc server has been identified. For very specific protocols, using Wireshark is recommended to ensure the accuracy of results obtained by automated tools.

Once a valid AE Title has been identified, it remains to create the code to perform the enumeration. The Pynetdicom library is used for this purpose.

To demonstrate the attacker’s ability to retrieve sensitive elements, data will be selected directly from the PACS server. Several radiographs will be used to measure the enumeration’s exhaustiveness.

Enumerating the PACS Server Database

For clarity and to avoid a series of screenshots, only the generic names of the first radiographs will be presented:

Here is a portion of the data retrieved by the script developed to perform the enumeration:

To be more agnostic about the type of command and service class used to retrieve the above data, the following capture shows the entire sequence of this exchange:

Here, only a portion of the data is displayed. The information present is similar to that shown in the Orthanc screenshot.

Once the enumeration is completed, the attacker has all the necessary information to manipulate the DICOM files. From this point, it becomes easy for them to extract the files. This extraction is made possible by retrieving a unique identifier for each enumerated DICOM object. Once these identifiers are in hand, the attacker will be able to query the PACS server to retrieve (C-Get) and store (C-Store) the images.

Here is an example of data extraction performed in the test lab:

To summarize the different attack phases described in this article, here is a diagram outlining the exchanges/process:

Real-World Attack

The actions described in this article raise pertinent questions about the likelihood of such an attack.

In recent years, a new modus operandi has emerged among ransomware actors. Indeed, some attackers are moving away from data encryption to focus solely on data theft and extortion. In other words, attackers extract data and threaten to publish it if a ransom is not paid.

It is also possible to sell the medical data associated with DICOM objects stored on PACS servers.

This demonstration highlights all the phases related to this type of attack. In a world where malicious cyber activities are multiplying and diversifying, it would not be surprising to see this type of attack making headlines in the coming years.

In this section, a proof of concept will demonstrate how to modify DICOM files to make them executable in a Windows environment using polyglot files.

It is important to note that the architecture deployed in the lab environment does not allow for the manipulations described in the Git of this proof of concept (POC).

To summarize, the attack on the files consists of injecting a Windows executable file into a DICOM file using polyglot files. Polyglot files are interpretable in multiple languages. Here, the goal is to create a file following this model:

In this capture from the article related to this proof of concept, it is easy to understand how the DICOM file was modified. It should be noted that this type of action is performed for Windows systems but could also be adapted for Linux/OSX platforms. Despite the complexity of this POC, this technique could enable supply chain attacks. For instance, if an X-ray is taken in a radiology clinic and then sent to a hospital, the corrupted file could become a virus propagation vector. The most complex part of this scenario remains the remote execution of the file. Indeed, the file would need to be modified to make it executable on the target system.

After describing attacks using DICOM files and network exchanges, it is important to explore how to effectively detect these attacks.

When discussing network detection, we refer to the monitoring of exchanges between a PACS server and a workstation or acquisition device. Several methods can be used for this purpose.

The main one involves the use of behavioral detection techniques. Concrete examples include:

• A machine that never emits DICOM traffic suddenly starts communicating using this protocol;
• A significant number of unsuccessful pairing attempts;
• Other unusual behaviors differing from the network’s normal daily operation.

These signs can indicate an intrusion attempt.

Concerning DICOM files, several detection techniques can also be implemented at the network level. One of these methods involves reconstructing the file and analyzing it. A polyglot file may not be executed during download, but it will be when opened by the user. This could give time for an EDR (Endpoint Detection and Response) or an NDR (Network Detection and Response) system to analyze the element and detect an anomaly in the file, which would contain both an executable file and a DICOM image.

In this series of articles on the healthcare sector, several topics have been addressed. From the overview of threats to specific attacks, this spotlight on the healthcare domain has demonstrated that this world, where humans and machines sometimes operate in symbiosis, is complex to secure. Beyond the cyber risk, it is crucial to consider the potential impact on human lives from an attack on a biomedical device or the overall system of healthcare facilities.

The dual expertise once required to carry out complex attacks using IT/OT networks is no longer entirely relevant. In the healthcare sector, the convergence of IT and OT technologies presents a major challenge. The connected medical systems mentioned in this article, such as imaging devices, patient monitoring systems, and medical data management systems, are now interconnected with traditional IT networks. This interconnection inherently increases vulnerabilities and exposes healthcare infrastructures to cyberattacks, endangering both patient data confidentiality and the safety of care. Indeed, the rise of AI allows less experienced attackers to carry out malicious actions against critical systems by exploiting outdated protocols that lack security features. This trend will inevitably lead to an increase in malicious activities and expand the attack surface. Knowledge once considered too complex to acquire is now more easily accessible and usable, for better or for worse.

Authors: Purple Team and 0xSeeker