“From medical imaging to data breach, here’s how attackers exploit DICOM systems to access sensitive patient data and critical healthcare systems.”
Introduction
Healthcare networks were built for speed and interoperability, not security. Early architects prioritized rapid clinical data exchange, treating security as something that could be added later. The assumption has now become a liability.
This post walks through a realistic attack chain that starts at a single medical imaging device and ends with full access to electronic health records (EHR) containing highly sensitive patient data. The attack requires no zero-day exploits or advanced tooling. It simply exploits the trust assumptions baked into protocols and architectures that hospitals have relied on for decades, using those systems exactly as they were designed to operate.
The Protocol at the Center: Understanding DICOM
DICOM (Digital Imaging and Communications in Medicine) is the universal standard for transmitting and storing medical images like CT scans, MRIs, and X-rays across hospital networks. Developed in the 1980s by the American College of Radiology and NEMA, it remains the backbone of clinical imaging workflows worldwide. The protocol works reliably for its intended purpose, but it carries critical security shortcomings that were acceptable in isolated 1990s hospital networks and are now deeply problematic in today’s connected environments.
No encryption by default: DICOM traffic travels in plaintext, meaning anyone on the same network segment can observe full transmission contents, including patient names, medical record numbers, and image data.
No strong authentication: Devices identify themselves using Application Entity Titles (AE Titles), which are simple text strings like “CT-SCAN-01” or “PACS-MAIN.” If a device presents a recognized AE Title, access is granted with no password, certificate, or cryptographic verification required.
Implicit trust between devices: The protocol assumes any device presenting a valid AE Title is a legitimate clinical participant. An attacker who learns a valid AE Title can impersonate a trusted medical device without triggering any alarms.
These design choices reflected a time when hospital networks were physically isolated, and the priority was ensuring surgeons could access scans within seconds. The threat landscape has since changed dramatically, but many of these foundational protocols have not.
The Starting Point: Gaining a Foothold Inside the Network
Hospital networks present a broad attack surface through medical devices, IoT sensors, guest Wi-Fi, and third-party vendor connections. We assume the attacker has already gained internal access through phishing, a compromised VPN credential, or a vulnerable service.
Reconnaissance with standard scanning tools reveals a PACS (Picture Archiving and Communication System) server, the central hub that receives images from every scanner, stores them in a searchable archive, and distributes them to clinical workstations. Its connections span multiple departments and network zones, making it an ideal pivot point.
From Guessing to Listening: Capturing a Trusted Identity
The attacker tries brute-forcing AE Titles with common defaults, but the PACS server’s whitelist rejects every attempt. Instead of persisting, they switch to passive interception using packet capture tools on the same network segment. Because DICOM traffic is unencrypted, legitimate device associations are visible in plaintext. Within minutes, the attacker captures a valid AE Title from a real CT scanner communicating with the PACS server, leaving zero trace on the target system.
Impersonation and Data Access
Using the stolen AE Title, the attacker connects to the PACS server and is immediately accepted as a trusted clinical device. There is no IP binding, MAC validation, mutual TLS, or behavioral analysis to flag the impersonation. This vulnerability has been demonstrated by researchers and acknowledged by both HHS and CISA, yet many organizations still lack additional authentication controls due to the cost and disruption of upgrading legacy devices.
With trusted access, the attacker queries the system using standard C-FIND and C-MOVE operations, retrieving patient names, medical record numbers, dates of birth, and clinical indications, all classified as protected health information under HIPAA. They then pull complete DICOM image files, which embed hundreds of metadata fields including diagnoses, facility details, and clinical notes alongside the pixel data.
Weaponization: From Data Theft to System Compromise
The attack escalates when the adversary crafts a malicious DICOM file with payloads embedded in metadata fields and uploads it via the standard C-STORE operation. The PACS server processes it like any routine image, but because it fails to sanitize metadata contents, the malicious input achieves command execution on the underlying system. Since PACS servers often run with elevated privileges, the attacker now has full administrative control of a critical clinical server.
Lateral Movement to EHR Access
From the compromised PACS server, the attacker discovers connections to a healthcare integration engine, a middleware platform that uses HL7 and FHIR to route data between imaging, lab, pharmacy, billing, and EHR systems. These engines sit in broadly connected network zones and frequently store credentials and API keys in their configuration files.
The attacker pivots to the integration engine by exploiting a known but unpatched vulnerability, enabled by weak network segmentation between the imaging and integration layers. Inside the engine’s configuration, they find plaintext credentials for the EHR database, stored without encryption or secrets management protections.
These credentials grant unrestricted access to the complete health records of every patient the hospital has treated: names, Social Security numbers, insurance details, lab results, diagnoses, treatment plans, and medication histories. Stolen health records are among the most valuable assets on the black market because they enable medical identity theft, insurance fraud, and targeted extortion that is far harder to detect than traditional financial fraud.
Root Cause Analysis: Why the Entire Chain Was Possible
This breach was not caused by a single dramatic failure. It was the result of multiple smaller weaknesses that individually might have been considered low-priority or acceptable risk but collectively created an unobstructed path from initial network access to total data compromise.
Legacy protocols operating without encryption allowed the attacker to passively intercept device identities. If DICOM traffic had been encrypted using TLS, the AE Title would not have been visible to a network observer, and the impersonation attack would have been significantly more difficult to execute.
Identity verification based on trust rather than cryptographic proof meant that knowing a device’s name was equivalent to being that device. If mutual authentication had been required, the attacker would have needed a valid certificate or credential that could not be obtained simply by watching network traffic.
Insufficient input validation on the PACS server allowed a crafted DICOM file to achieve remote code execution. If the application had sanitized all metadata fields before processing them, the weaponized file would have been rendered harmless.
Unpatched vulnerabilities on the integration engine provided the attacker with a reliable method for lateral movement. If the organization had maintained a rigorous patch management program, this pivot point would not have been available.
Credentials stored in plaintext gave the attacker direct access to the EHR database without any additional exploitation. If those credentials had been encrypted, rotated regularly, and managed through a dedicated secrets vault, the final stage of the attack would have been blocked.
Weak network segmentation allowed the attacker to move freely between network zones that should have been isolated from each other. If strict segmentation and micro-segmentation policies had been enforced, each hop in the attack chain would have been an additional barrier requiring a separate exploit.
Absence of monitoring and detection meant that the entire attack chain, from initial reconnaissance through data exfiltration, proceeded without generating a single alert. If network anomaly detection, DICOM-specific monitoring, or behavioral analytics had been in place, the attack could have been detected and interrupted at multiple stages.
The Broader Lesson: Security Cannot Be an Afterthought
This attack chain is not any single technical vulnerability but an architectural lesson that security cannot be effectively retrofitted onto systems that were designed without it.
The DICOM protocol was designed for isolated hospital networks where every device on the wire was physically controlled by the organization. The integration engine was designed inherently trustworthy internal system. The credential storage approach was designed so that the middleware layer would never be compromised. Each of these assumptions was reasonable at the time it was made, and each of them has been thoroughly invalidated by the modern threat landscape.
Healthcare organizations must maintain continuous clinical operations while simultaneously modernizing decades of legacy infrastructure. A hospital cannot simply take its PACS server offline for a month while it upgrades to encrypted DICOM communication, because patients will continue to arrive with conditions that require immediate imaging and diagnosis.
This operational reality does not excuse inaction, but it does explain why progress has been slower than the threat environment demands. The solution lies not in any single technology or product but in a fundamental shift toward zero-trust architecture, where no device, user, or system is trusted by default regardless of its position within the network, and where every access request is authenticated, authorized, and continuously validated.
Conclusion
This attack chain explains an ordinary attacker following a logical path through an environment where decades of trust assumptions created an unobstructed corridor from a medical imaging protocol to the most sensitive records in the entire organization.
The attacker used the system as it was designed. They listened to unencrypted traffic, borrowed a device identity, accessed patient data through standard query mechanisms, exploited a processing flaw to gain system-level access, moved laterally through poorly segmented networks, and found plaintext credentials that led directly to the final prize.
Every step in this chain was preventable. Encryption, strong authentication, input validation, patch management, secrets management, network segmentation, and continuous monitoring would have empowered to break the attack chain.
As healthcare continues its rapid digital transformation, the question every organization must confront is not whether their systems are secure today. The question is whether they are still relying on architectural assumptions that were made in a fundamentally different era, and whether they have the courage and commitment to replace those assumptions with controls that reflect the reality of today’s threat landscape.
If your healthcare environment as well relies on legacy trust assumptions, now is the time to reassess them.
| Connect with our experts and start by identifying where implicit trust exists and replace it with verifiable control. |
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
