Weaponizing DICOM Files: How Legacy Medical Devices Bypass Modern Defenses

TLDR: Medical devices often ship with insecure network configurations and legacy protocols that allow for trivial remote code execution. By embedding malicious payloads into the 128-byte preamble of DICOM files, attackers can bypass enterprise security controls that treat these files as benign images. This research demonstrates that the path to domain dominance in a hospital network often starts with a single, unpatched, and overly connected medical device.

Medical devices are the soft underbelly of modern hospital infrastructure. While security teams focus on hardening servers and workstations, they frequently overlook the legacy hardware sitting in radiology or surgical suites. These devices are often treated as black boxes, assumed to be secure because they are "medical grade" or sit behind a firewall. This assumption is dangerous. When you connect a device with a weak security posture to a network running Active Directory, you are not just introducing a single point of failure; you are providing an entry point for lateral movement that can lead to a full domain compromise.

The DICOM Attack Vector

The research presented at DEF CON 2024 highlights a specific, overlooked vulnerability in how medical imaging systems handle DICOM files. DICOM is the standard for medical imaging, and it is designed to be interoperable across different vendors. The file format includes a 128-byte preamble, which is technically reserved for legacy compatibility but is rarely validated by the software that parses these files.

Because many DICOM viewers and processing engines treat these files as simple images, they fail to perform deep packet inspection or file integrity checks. An attacker can embed a malicious payload directly into this preamble. When the target system processes the file, it executes the payload. Since these devices often run with elevated privileges to interact with hardware, the resulting code execution occurs in a high-privilege context.

To reproduce this, you do not need a complex exploit chain. The goal is to get the device to parse a crafted file. In a typical engagement, this might involve placing the file on a shared network drive or tricking a technician into importing it via a USB drive. Once the file is parsed, you gain a reverse shell.

# Example of payload injection into a DICOM file
# This is a conceptual representation of the preamble manipulation
cat malicious_payload.bin > header_preamble.dcm
cat original_image.dcm >> header_preamble.dcm

From Medical Device to Domain Admin

The real-world risk is not just the compromise of the medical device itself. It is the network environment where these devices reside. Many of these systems are joined to the hospital's Active Directory domain to facilitate file sharing and user authentication. Once you have code execution on the device, you can begin internal reconnaissance.

Tools like BloodHound are essential here. By analyzing the network traffic from the compromised device, you can identify reachable domain controllers, map out group memberships, and look for misconfigured service accounts. If the device has been configured with a service account that has excessive permissions, you can pivot directly to the domain controller.

Even if the device is not domain-joined, it is often a prime candidate for credential harvesting. Many of these systems store credentials in cleartext or use weak, hardcoded passwords for administrative access. By sniffing traffic or dumping memory, you can often find the credentials needed to move laterally to other, more sensitive systems within the hospital network.

Why Current Defenses Fail

The core issue is a lack of understanding regarding the threat model of medical devices. Manufacturers often prioritize uptime and interoperability over security. They ship devices with unnecessary services enabled, such as SMB or Telnet, and fail to implement basic OWASP A07:2021 – Identification and Authentication Failures controls.

Defenders need to stop treating these devices as isolated assets. If a device does not need to be on the network, it should be air-gapped. If it must be on the network, it should be placed in a strictly segmented VLAN with no access to the domain controller. Security teams should also implement egress filtering to prevent these devices from reaching out to the internet, which is a common requirement for many malware variants to establish a command-and-control channel.

Actionable Steps for Pentesters

When you are on an engagement, do not ignore the medical devices. They are often the easiest path to the objective. During your reconnaissance phase, look for devices that are running Windows IoT or other embedded operating systems. Use network scanning to identify open ports and services that should not be exposed. If you find a DICOM-capable device, test its handling of malformed files.

The goal of an adversary simulation is to show the client the reality of their security posture, not to provide a false sense of security with a clean report. If you find a vulnerability, document it clearly, explain the impact, and provide a path to remediation. If the client is resistant to fixing the issue, show them the impact by demonstrating how a simple DICOM file can lead to a full system compromise. The goal is to force the organization to prioritize the security of these devices, not just because it is the right thing to do, but because it is a critical component of their overall security strategy.