Summary: A weakness in the DICOM image format enables malware to infect patient data by directly inserting itself into medical imaging files. These hybrid files are both fully-executable malware binaries and fully-functioning, standards-compliant DICOM images that preserve the original patient data and can be used by clinicians without arousing suspicion. By mixing in with protected health information malware can effectively exploit the data’s clinical and regulatory implications to evade detection and derail remediation attempts while creating a host of new concerns for security teams, healthcare organizations, and antivirus companies in the process. This vulnerability stands apart as one whose technical potency is derived from not just a software design flaw, but from the clinical and regulatory environment as well.
Cylera’s core technology is based on a deep understanding of clinical workflows and the healthcare-centric protocols that enable device interoperability. Researchers at Cylera Labs spend time investigating, reverse engineering, and decoding protocols found in clinical networks while carefully assessing related specifications and implementations for weaknesses. In this article we discuss a fundamental flaw in the design of DICOM, discovered by Markel Picado Ortiz (d00rt) of Cylera Labs, that enables attackers to effectively turn patient information into malware by embedding fully-functioning executable code into image files used by medical devices such as CT and MRI machines.
DICOM is a globally-recognized standard for the exchange and storage of medical images that is ubiquitous within the healthcare industry. The DICOM standard, drafted by National Electrical Manufacturers Association (NEMA), defines a file format for the representation and storage of medical imagery and a communication protocol for the transmission of imagery over a network. The DICOM standard is used by systems ranging from medical devices that produce imagery, such as CT and MRI machines, to specialized workstations for analyzing scan results, to phones and tablets used to view diagnostic information.
The flaw discovered in the DICOM file format specification allows attackers to embed executable code within DICOM files to create a hybrid file that is both a fully-functioning Windows executable as well as a specification-compliant DICOM image that can be opened and viewed with any traditional DICOM viewer. Such files can function as a typical Windows PE file while maintaining adherence to the DICOM standard and preserving the integrity of the patient information contained within. We’ve dubbed such files, which intertwine executable malware with patient information, PE/DICOM files.
By exploiting this design flaw attackers can take advantage of the abundance and centralization of DICOM imagery within healthcare organizations to increase stealth and more easily distribute their malware, setting the stage for potential evasion techniques and multi-stage attacks. Perhaps more interestingly, the fusion of fully-functioning executable malware with HIPAA-protected patient information adds regulatory complexities and clinical implications to automated malware protection and typical incident response processes in ways that did not previously need to be considered. Common incident response procedures could now delete or incidentally leak the ePHI the malware is hiding in.
Throughout the remainder of this article we will briefly discuss the technical flaw enabling the creation of these polyglot files, which is outlined in further detail in a paper authored by Markel Picado Ortiz, consider potential implications from cybersecurity and clinical perspectives, explore Proof of Concept and hypothetical attack scenarios, and discuss what healthcare systems can do to protect themselves.
DICOM Design Flaw
The DICOM file format standard defines a header that consists of a 128-byte section at the beginning of the file, called the Preamble, that can be used to facilitate access to the images and metadata within the DICOM image. A third party can use the Preamble to enable compatibility with DICOM-unaware applications that expect common image formats. From the DICOM specification:
If the File Preamble is not used by an Application Profile or a specific implementation, all 128 bytes shall be set to 00H. This is intended to facilitate the recognition that the Preamble is used when all 128 bytes are not set as specified above.The File Preamble may for example contain information enabling a multi-media application to randomly access images stored in a DICOM Data Set. The same file can be accessed in two ways: by a multi-media application using the preamble and by a DICOM Application that ignores the preamble.
While the DICOM standard intends for the field to be used to enable compatibility with non-DICOM image viewers, such as JPG and TIFF images, the standard does not impose any structural requirements on the data inserted into the Preamble. Any arbitrary sequence of 128 or fewer bytes can be inserted without jeopardizing the image file’s conformance with the DICOM standard.
While the ability to control the initial sequence of bytes within a DICOM file was meant to allow third parties to trick image viewers into believing a DICOM file was of another image format, this same “feature” can be abused by attackers to masquerade DICOM files as unrelated file formats. In fact, as the header of a PE file can be crafted to fit within 128 bytes, attackers can insert full PE headers and make the DICOM file appear to be an executable.
Taking things a step further, it is not only possible to make a DICOM image appear to be an executable file, but to fully embed a functioning executable into a DICOM image while preserving the ability of the file to both be executed by the operating system, as any other executable would, as well as act as a standards-compliant DICOM image file. This allows an attacker to masquerade an executable file as a DICOM image, as opposed to the standard’s intention for this field to be used to masquerade DICOM files as other formats.
The following image outlines the general mixed file structure containing portions of both DICOM and Windows PE formats:
Backdrop: Healthcare Under Attack
The increased attention the healthcare industry has drawn from cybercriminals over the past year is a clear symptom of a long-term trend that has been well-publicized by industry groups, regulatory bodies, and the general media. The confluence of healthcare’s relatively poor cyber defenses, the lucrative nature of medical records, and the criticality of clinical system uptime has created a powder keg ignited largely by profit-seeking malicious actors who view healthcare organizations as prime targets for data theft and ransomware campaigns.
As this trend continues to progress in a concerning direction the industry will inevitably begin to see increasingly sophisticated financially-motivated cybercrime campaigns in addition to attacks driven by actors whose motives diverge from pure financial gain. As a consequence of heightened attention from more sophisticated threat actors the industry should expect to encounter attacks that are increasingly targeted to the specific insecurities and vulnerabilities unique to healthcare.
PE/DICOM is an example of such a flaw. It is present in a healthcare-specific protocol that can be found within virtually every healthcare delivery organization. Its properties allow attackers to increase stealth, spread, and overall effectiveness of malware campaigns by exploiting not only a technical flaw, but the nature of the clinical and regulatory context of the ePHI it infects.
The PE/DICOM vulnerability enables attackers to hide malware within DICOM images while preserving both the ability to execute the malware and the validity of the DICOM file and associated patient data. While the clinical and regulatory implications are most interesting the issue does have cybersecurity-related impact as well. It enables new and existing malware to evolve into more potent variants, optimized for successful compromise of healthcare organizations, by using the infected patient data to hide, protect, and spread itself – three of the primary functions that determine the effectiveness of a malware campaign.
Evasion: The most obvious use of this flaw is to embed malware inside DICOM images to increase stealth and evade detection. There will not be any artifact “.exe” files, as PE/DICOM images can maintain their “.dcm” file extension and still be executed, which makes detection more difficult for analysts and response teams; further, when an analyst inspects the file, it will open the original DICOM image and display the clinical information as it was pre-infection, giving the initial impression that the file is innocent. The malware is essentially cloaking itself in DICOM data.
The flaw also enables evasion of A/V software in addition to human analysts and system administrators. Medical device manufacturers and healthcare organizations often configure anti-malware EDR software to ignore medical imagery and files containing protected health information. As PE/DICOM files can be executed without changing the “.dcm” file extension and preserve the integrity of the DICOM format they could evade automated detection mechanisms in such configurations. Some weaker A/V software may choose to not scan DICOM files altogether as they do not appear to be executable.
Spread: Better evasion implies better overall spread. Another interesting possibility is an attempt to propagate malware as part of a multi-stage attack by “piggybacking” on clinical workflows that entail the transfer of DICOM imagery. Central repositories of DICOM files, such as the PACS, could provide a single infection point that could proliferate the malware-infected image to a large number of clinical devices as patient information is pulled and stored during the course of patient diagnosis and treatment. These infected PE/DICOM images would then be activated by a second-stage attack that would need to execute the PE/DICOM malware files, a task which is much more likely to evade detection on the newly-infected hosts and therefore maximizes spread potential.
Imaging results are not only shared within a single organization but between organizations with overlap in patients treated. Patients will sometimes seek specialists who are experts in particular domains that are not handled by their local healthcare organization. Infected records could be transferred to the new organization as part of a consultation, thereby spreading infected DICOM files not only between departments within an organization, but across organizational boundaries and into completely unrelated healthcare organizations. The malware effectively “follows” the patient from organization to organization.
Persistence: Malware that exploits the PE/DICOM flaw effectively fuses patient data and malware. Once this occurs incident response teams and A/V software cannot delete the malware file as it contains protected patient health information. Response teams and A/V software that are unaware the file contains patient information could potentially destroy patient information in the mitigation process. Response teams and A/V software that are aware the file contains patient information are left in a difficult situation where they must balance cybersecurity, clinical, and regulatory risk as they respond to malware that is effectively using patient data as a shield.
The transition from purely cybersecurity-related concerns to regulatory consequences and clinical complications are an aspect of PE/DICOM that makes it so unique. Its effectiveness stems not just from an issue in the DICOM file format, but from the clinical and regulatory implications of the data it infected. When viewed from this perspective an entirely new set of impacts become clear.
The fusion of malware and patient information brings about second- and third-order impacts that extend beyond the typical cybersecurity-related harms brought about by malware infections. These impacts create concerns for security teams, healthcare organizations, patients, and A/V companies that were not typically considered previously.
From the perspective of healthcare system administrators and security teams, PE/DICOM malware introduces new challenges to incident response processes. Teams cannot upload the suspected malware to common cloud-based malware analysis solutions, such as VirusTotal, without sacrificing the confidentiality of the patient data contained within the image. Teams cannot delete the malware files without the risk that they will delete HIPAA-protected patient information. Teams cannot deny access to the retrieval and viewing of the file in order to contain the malware without the risk that they will impede clinical operations that require access to the patient’s imaging data for treatment.
If a team is unaware that the malware is in fact a PE/DICOM file then they can unintentionally cause these harms by following typical incident response playbooks. If a team is aware that the file is a PE/DICOM file but does not know how to properly handle it they can find themselves in a deadlock as they balance patient confidentiality, availability of medical information, and containment of active malware. Should they allow the image to be shared among various systems and clinicians during clinical care despite the fact that it contains malware?
From the perspective of antivirus companies the concerns and stakes are largely analogous. Products that automatically upload suspicious files to the cloud will begin uploading DICOM data containing protected health information from affected organizations, similar to the accusations against Kaspersky that resulted their ban in the United States. If the software detects PE/DICOM malware and chooses to delete the file it can inadvertently delete patient information; if the software decides to quarantine the file it can compromise the availability of the clinical information.
A/V software that is unaware of this flaw could inadvertently compromise patient confidentiality, delete patient information, or disrupt clinical workflows through typical automated response and remediation processes. While user-configurable policies may provide a rough means of allowing organizations to deal with this issue, A/V software should ideally recognize the situation and perform a remediation process tailored to PE/DICOM files.
The common thread through these scenarios is that the patient is, in some form, the collateral damage. Whether it is patient information being leaked due to improper incident response or a patient’s care being delayed due to automated deletion or quarantining of their infected scan results, part of the flaw’s utility to an attacker relies on the assumption that organizations will prioritize protecting patients.
These issues and dynamics are part of the PE/DICOM vulnerability itself: they are the reasons why the flaw enables malware to operate more effectively. The fact that they derail the incident response and forensic analysis processes is the intended purpose of the malicious actor’s use of the vulnerability. However, there are additional ancillary impacts that emerge due to the context of the data being infected.
For example, if a DICOM file has been modified by a malicious actor, should it still be used for patient care to begin with? Would an organization have any assurance that the patient data was not incidentally or intentionally modified by the infection process?
As another example, consider malware where the PE/DICOM flaw is one of multiple spread techniques. If malware with automated propagation mechanisms is now infused with patient information in order to aid evasion or replication efforts, then patient information will now spread with the malware and incidentally leak ePHI in the process. An organization would not be able to consider a PE/DICOM-related malware incident resolved when their internal network is cleaned as the malware may have propagated past the perimeter of their network, along with the DICOM imagery it had infected. It would be increasingly difficult to quantify the extent of such a leak, much less contain it, as the worm continued to replicate itself on external systems.
First of its Kind
As cyber attacks on healthcare networks and medical devices have begun to receive increased exposure there is another sentiment that is particularly unanimous: this is different. Ransomware disabling a system takes on an entirely new meaning when the infected host is a life-sustaining medical device or a clinical information system containing data needed for patient treatment. As medical devices gain network connectivity and assume roles as interfaces that connect patients to the network, and as clinical workflows begin to depend on applications and networked information systems, the direct harm to computer systems caused by cyber attacks now begin to cascade to real-world patient harm in a very tangible way. This tight coupling of network-connected systems and the ability to provide patient care has enabled the impact and implications of a cyber attack to jump the gap from virtual to physical.
One of the most interesting aspects of a PE/DICOM file is how well it serves as a concrete, literal representation of how clinical context transforms risk posed by cybersecurity threats: it is a file that literally contains both active malware and clinical information side-by-side in the same space on disk. This fusion of malware and HIPAA-protected patient data creates new clinical and regulatory risks to affected organizations that extend beyond the pure cybersecurity-related risk posed by the increased effectiveness of malware that exploits this flaw. This is as direct an example to illustrate how clinical context morphs cybersecurity risk as one could hope to find.
An insight we find even more interesting is that the clinical and regulatory risks posed by the PE/DICOM flaw are not side effects; they are the reasons why the PE/DICOM vulnerability is so potent. PE/DICOM files are not only exploiting a vulnerability in a file format, but an unfixable vulnerability in healthcare data regulation as well. If this flaw was instead in a file format for images that were not protected by HIPAA it would not be as technically effective. This is the first vulnerability whose technical potency is derived from a regulatory environment in addition to a software design flaw.
Proof of Concepts
PoC 1: PE/DICOM File Creation
As an initial Proof of Concept we crafted a PE/DICOM file using a publicly-available anonymized DICOM image and a simple example program that displays a message box.
These files can be found here.
In the following images you can see the contents of the files “cylera.dcm” and “cylera.exe” in their real representation.
The “pedicom-cylera.dcm” file is a PE/DICOM file containing both the raw DICOM image and the executable shown above. As it has the typical “.dcm” DICOM file extension it is opened with the default DICOM image viewer installed in our test environment (MicroDicom viewer.) We can see that it is exactly the same image as contained in the original “cylera.dcm” file.
Opening the “cylera.dcm” file with a hexadecimal editor shows the following raw DICOM data:
Opening the “pedicom-cylera.dcm” file with a hexadecimal editor shows both formats mixed together, starting with the headers of the Windows PE format followed by data in the DICOM format.
In the following image you can see exactly which part corresponds to which file format.
The execution of the executable embedded in a PE/DICOM file does not require renaming the file extension from the standard “.dcm” DICOM extension to “.exe”, even if a DICOM viewer is present on the system and registered as the default application handler for “.dcm” files. This significantly reduces the complexity of successful exploitation of this flaw.
Trivial methods to execute PE/DICOM files include:
- “Running” the image from the Windows Command Prompt as you would run any other executable, as shown above. This works as Command Prompt internally uses the CreateProcess function from Windows API, which loads a PE file into memory and executes it.
- Creating a one-line batch script that simply calls the PE/DICOM file, similar in concept to the previous approach. When the batch script is double-clicked it will execute the PEDICOM image as a PE.
- From another program, call the CreateProcess API function and provide the PE/DICOM image as the application to be run. The PE/DICOM image location may be passed as a parameter to this second-stage executable. This approach is further discussed in the paper.
- Naturally, changing the file extension from “.dcm” to “.exe” would allow a user to run the executable from double-clicking it. This, however, largely defeats the purpose and removes the elements of stealth and evasion; the file is now an executable binary containing DICOM data instead of a DICOM file containing an executable binary.
PoC 2: Local File Infector
As a Proof of Concept to explore how the PE/DICOM flaw could be used by an application to replicate itself among files on a single host we created a binary we named “PeDi2” that locates all DICOM imagery on the local system and auto-replicates itself using the flaw.
The PeDi2 program structure is very simple, limits the field of action to the current directory, and contains a benign demo. In the following diagram you can see the execution flow:
Two important stages can be highlighted: PAYLOAD and INFECTION.
- PAYLOAD: There are two unique payloads used in this stage: one for the initial binary (“patient zero”) and the other for infected DICOM images. These payloads simply open two (non-malicious) URLs in the browser.
- INFECTION: In this stage the binary attempts to locate and infect a DICOM image (limited to the current directory in this example.)
Once it finds a DICOM image that has not been infected before, it infects it. After infecting the image, PeDi2 executes the image as if it were a PE file, sparking a chain where this image will find, infect, and execute another DICOM image in the directory, which will find, infect, and execute another, etc. This process is repeated until all DICOM images in the current directory are infected.
PoC 3: Hypothetical Worm Attack
We next considered a hypothetical worm that used PE/DICOM as a means . The worm, created and run in our controlled internal lab environment, locates shared resources via SMB as an initial means to propagate itself.
The overall structure is similar to the previous example but with an additional component capable of propagating over shared SMB resources. Once the malware infects a host it copies the infected DICOM image into the directory “\\TargetHost\C$\Users\Default\PEDICOM” if an existing file does not already exist at the location.
Once the infected image has been placed on the remote host it is executed via WMIC, which then spawns the replicated instance of the worm on the newly-infected host.
To execute commands on remote hosts in the manner above it is necessary to have valid Active Directory credentials or permissions. In many networks, however, it is common to have shared credentials for devices, a weakness that has been exploited in cases such as the Kwampirs campaigns by the Orangeworm Group that targeted healthcare organizations. There are of course other mechanisms for remote command execution, such as usage of the Eternal Blue exploit in the case of the Wannacry outbreak in 2017, but they are well beyond the scope of this example.
As healthcare continues to become a favored target among cyber criminals and threat actors we must expect attacks to become increasingly sophisticated and tailored to the insecurities specific to healthcare protocols, networks, and systems, as observed in the industrials space. It is therefore critical to bring awareness to healthcare-specific issues and catalyze shifts towards secure practices and proactive protection while this trend is still far from cresting.
The root cause of this issue was the decision to allow freedom to insert arbitrary data into a large preamble area, a dangerous practice in file format design. In the long-term, a modification to the DICOM file format specification to prevent control of a large preamble and the associated potential for abuse seems necessary. However, creating such a modification to the format specification while preserving the functionality the preamble was originally intended to support may be non-trivial, if possible.
Further, practical concerns are likely to pose a greater challenge. DICOM has become ubiquitous within healthcare since the standard was first drafted thirty years ago, and the number of systems supporting DICOM is innumerably large. There is no single vendor that can provide a patch and no single action that can be taken to fix the root cause of the issue across all systems using DICOM. Any change to the specification must be carefully considered to preserve interoperability between systems that may be designed to different versions of the specification before software vendors even begin to upgrade their own implementations.
Given the level to which DICOM is ingrained into the devices and data that serve as the foundation for clinical care, coupled with the typically slow rate-of-change of technology systems within healthcare, the best path forward is to fortify existing systems by implementing mechanisms to detect abuse, creating processes for appropriately responding to and mitigating attacks exploiting this flaw, and course-correcting future implementations through increased awareness.
PE/DICOM files can be detected via direct analysis of a DICOM image’s Preamble. A straightforward detection method is to inspect a DICOM image’s Premable for the contents of a PE header, which would be a direct indicator of an infected file. As there may be additional techniques for DICOM Preamble abuse, a more robust detection method involves the creation of an enumeration of acceptable DICOM Preambles for an organization and the detection of files whose Premables are not contained within the whitelist. Analysis of the full contents of a DICOM file for the presence of portions of executable binaries can provide further verification of the nature of the file. Anomaly detection-based approaches can provide a more robust generalization of the above techniques for preamble and full-file analysis, but require the training of machine learning models over large datasets for production-level effectiveness.
PE/DICOM detection can be performed at the host level or the network level. Host-level detection involves the enumeration of all DICOM files stored on the local system and the invocation of the chosen detection method on each file. Host-level techniques are feasible for workstations and servers managed by a healthcare organization but are generally not possible for medical devices due to system constraints and contractual obligations that prohibit device modification. Network-level approaches are therefore necessary as the primary layer of detection for medical devices and an additional layer of detection for managed workstations and servers. Network-level detection involves the monitoring of network communication, the reassembly of relevant TCP streams, the parsing of the relevant protocols to locate DICOM data, and the reconstruction of the DICOM files themselves. Once the files are extracted the chosen detection method is invoked on each.
Detected PE/DICOM files containing malware should not be directly deleted from the source host in order to avoid incidentally losing the image data and clinical information as a side effect. Instead, security teams and automated EDR software must determine if a malware executable is a PE/DICOM file and, if so, neutralize it by clearing the initial 128 bytes of the file to effectively wipe the Preamble. This requires that security teams as well as EDR software vendors make their processes and products PE/DICOM-aware.
In addition to the neutralization of PE/DICOM files, both security teams and EDR software vendors will often want to upload the malware to external cloud services for more detailed analysis. In order to avoid sending clinical information and patient data to third-party cloud services security teams and EDR software vendors must modify their processes and products to first separate the DICOM image file from the malware executable file and only process and upload the raw executable.
The technical issue discussed in this article is caused by an excessively lax preamble in the DICOM image format. The true vulnerability, however, was only partially defined by the technical weakness itself; an equally-important component of the PE/DICOM flaw’s identity is the clinical context in which the files are used and the regulatory implications of the data they contain.
This is generally descriptive, in some way or another, of most cybersecurity threats posed to healthcare organizations and medical systems. The growing dependency of clinical care on network-connected systems should reframe how we consider and understand cyber risks and guide how we protect clinical networks and the patients connected to them. Risks and associated impacts must be viewed in a multi-dimensional way, with a focus on potential impacts that reside near the boundary of virtual and physical.
As attacks on healthcare inevitably continue to increase in both volume and sophistication it is imperative we proactively act to harden our networks and systems, implement robust monitoring and detection mechanisms, and optimize response procedures. Implementing security controls to protect from both current and future threats is our best option to close the capability gap between attackers and defenders. This is why considering and preparing for vulnerabilities such as PE/DICOM is critical.
The PE/DICOM flaw is not a vulnerability that can be promptly resolved by a single software patch or a revision to the DICOM standard. The clearest path forward is for healthcare organizations to implement basic mechanisms for detection of PE/DICOM files at the network and host levels and augment their tooling and processes to properly inoculate detected files without side effects. Antivirus solutions should similarly work to make their products PE/DICOM-aware, with custom detection and containment mechanisms that don’t leak or delete ePHI.
Healthcare organizations interested in implementing PE/DICOM detection mechanisms and patching their incident response procedures to handle such files can contact Cylera at email@example.com for access to our free toolkit for detecting PE/DICOM files, safely inoculating them, and separating the malware executable and original DICOM file.