Unsecured DICOM Servers Exposing PHI: Hardening Guide and Detection for PACS Misconfigurations

Recent intelligence from the HIPAA Journal confirms what many of us in the IR community have feared: a massive, ongoing exposure of Protected Health Information (PHI) via poorly secured Digital Imaging and Communications in Medicine (DICOM) servers. It is estimated that tens of thousands of medical imaging studies, containing X-rays, MRIs, and CT scans along with patient PII, are currently accessible via the public internet.

This is not a sophisticated zero-day exploit; it is a fundamental failure of asset management and network segmentation. Threat actors are actively scanning for open DICOM ports (specifically TCP 11112 and 104) to harvest data for extortion or simply to exploit the storage for malicious purposes. For defenders, the urgency is immediate: if you operate a Picture Archiving and Communication System (PACS), you must assume it is being targeted.

Technical Analysis

Affected Products & Platforms The exposure affects any organization utilizing DICOM-compliant PACS. While this is a protocol issue rather than a specific CVE in a single vendor, the most common platforms observed in these exposures include:

dcm4chee: A popular open-source DICOM archive.
Orthanc: A lightweight, standalone DICOM server.
PacsOne: A common DICOM/PACS server.
Web Viewers: Many vendors provide web-based interfaces (often on ports 8080 or 443) that proxy DICOM data (WADO-RS/STOW-RS) without authentication.

Vulnerability Mechanics The vulnerability stems from two primary misconfigurations:

Lack of Network Segmentation: DICOM services (often running on TCP port 11112, 104, or 2761) are exposed directly to the public internet.
Lack of Authentication: Many legacy or default PACS configurations rely on "security by obscurity" or IP whitelisting that is no longer maintained. They accept Association requests (C-ECHO, C-MOVE, C-FIND) from any source IP without verifying credentials.

Exploitation Status There is no theoretical risk here. Active exploitation is confirmed via Shodan search engine results, which index thousands of open ports. Attackers do not need to bypass a firewall; they simply initiate a standard DICOM Association to download patient studies.

Detection & Response

Because this behavior relies on standard protocol usage rather than malicious code, detection focuses on network visibility and asset discovery. We need to identify when internal medical devices are communicating with unexpected external entities or when known DICOM ports are exposed to the internet.

SIGMA Rules

YAML

---
title: Potential DICOM Server Exposure to Public Internet
id: a8f4c2d1-9e3f-4a7b-8c1d-2e5f6a7b8c9d
status: experimental
description: Detects inbound network connections to standard DICOM ports from non-private IP ranges, indicating potential exposure of PACS servers.
references:
  - https://www.hipaajournal.com/healthcare-organizations-exposing-patient-data-dicom-servers/
author: Security Arsenal
date: 2024/05/21
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort|contains:
      - '11112'
      - '104'
      - '2761'
    SourceIp|notcontains:
      - '10.'
      - '192.168.'
      - '172.16.'
      - '127.'
  condition: selection
falsepositives:
  - Authorized remote access from business partners (VPN)
  - Misclassified internal traffic
level: high
---
title: Suspicious DICOM Web Viewer Access
id: b1e3d5f7-8a9c-4d2e-b1f3-5a7b9c1d2e3f
status: experimental
description: Detects HTTP requests to known DICOM web service paths (WADO/STOW) which may be unauthenticated.
references:
  - https://www.hipaajournal.com/healthcare-organizations-exposing-patient-data-dicom-servers/
author: Security Arsenal
date: 2024/05/21
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: apache
detection:
  selection:
    c-uri|contains:
      - '/wado'
      - '/stow-rs'
      - '/wado-rs'
      - '/dcm4chee'
  filter:
    c-ip|contains:
      - '10.'
      - '192.168.'
  condition: selection and not filter
falsepositives:
  - Authorized external radiologists accessing the portal
level: medium

KQL (Microsoft Sentinel)

This hunt query helps identify if your internal servers are receiving traffic on DICOM ports from external sources. It assumes you are ingesting firewall logs or network traffic data into DeviceNetworkEvents or CommonSecurityLog.

KQL — Microsoft Sentinel / Defender

// Hunt for external connections to known DICOM ports
let DicomsPorts = dynamic([104, 11112, 2761, 8080]);
DeviceNetworkEvents
| where InitiatingProcessFileName !in ("svchost.exe", "system") // Or adjust based on your PACS software binaries
| where RemotePort in (DicomsPorts)
| where ipv4_is_private(RemoteIP) == false
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, RemoteUrl
| summarize count() by DeviceName, RemoteIP, RemotePort
| order by count_ desc

Velociraptor VQL

Use this artifact on endpoints suspected of hosting PACS software (e.g., Radiology Workstations or dedicated Server OS) to identify processes listening on high-risk DICOM ports.

VQL — Velociraptor

-- Identify processes listening on common DICOM ports
SELECT Pid, Name, Exe, CommandLine, UserName, LocalAddress, LocalPort
FROM listen_sockets()
WHERE LocalPort IN (104, 11112, 2761)
  AND NOT LocalAddress IN ("127.0.0.1", "::1")

Remediation Script (Bash)

The following Bash script is intended for Linux-based DICOM servers (common for dcm4chee/Orthanc). It checks if the high-risk ports are listening and verifies if the service is bound to all interfaces (0.0.0.0) rather than localhost.

Bash / Shell

#!/bin/bash

# Remediation/Harden Script for DICOM Server Exposure
# Check for listening sockets on common DICOM ports

HIGH_RISK_PORTS=(11112 104 2761 8080)
VULNERABLE_FOUND=false

echo "[*] Auditing network listeners for DICOM exposure..."

for port in "${HIGH_RISK_PORTS[@]}"; do
  # Check if port is listening on 0.0.0.0 (All Interfaces)
  if netstat -tlnp 2>/dev/null | grep -E ":$port " | grep "0.0.0.0" > /dev/null; then
    echo "[!] ALERT: Port $port is exposed to all interfaces (0.0.0.0)."
    # Attempt to identify the process
    PID=$(netstat -tlnp 2>/dev/null | grep -E ":$port " | grep "0.0.0.0" | awk '{print $7}' | cut -d'/' -f1)
    echo "    Process ID: $PID"
    ps -p "$PID" -o command=
    VULNERABLE_FOUND=true
  fi
done

if [ "$VULNERABLE_FOUND" = false ]; then
  echo "[+] No high-risk DICOM ports found exposed to 0.0.0.0."
else
  echo ""
  echo "[!] ACTION REQUIRED:"
  echo "1. Configure the application (e.g., dcm4chee, Orthanc) to bind to 127.0.0.1 or a specific internal LAN IP only."
  echo "2. Restrict access via firewall (iptables/ufw/firewalld) immediately."
  echo "   Example: ufw deny in from any to any port 11112"
fi

Remediation

To eliminate this exposure, healthcare organizations must move beyond simple "awareness" and implement strict technical controls:

Network Segmentation (Immediate):
- Block inbound internet traffic to TCP ports 104, 11112, 2761, and 8080 (if used for web viewers) at the perimeter firewall. These services should never be directly accessible from the public internet.
Configure Firewall ACLs:
- Use internal firewalls (or host-based firewalls like iptables or Windows Firewall) to ensure the DICOM service only accepts connections from known IP addresses (e.g., Radiology Workstations, Viewing Stations, and authorized external partner VPNs).
Enforce Application-Level Authentication:
- Disable Anonymous Bind: Review your PACS configuration (e.g., dcm4chee-arc configuration files). Ensure that AE (Application Entity) titles require a called/calling AE title check and that user authentication is enabled for web viewers.
- TLS Encryption: Enable TLS for DICOM associations (DICOM TLS) to prevent eavesdropping on internal traffic.
Vendor Patching:
- While this is largely a configuration issue, ensure your PACS software is up to date. Refer to your specific vendor's security bulletin for PACS hardening guides (e.g., GE Healthcare, Siemens Healthineers, Philips).
Audit Logging:
- Enable audit logging for all C-MOVE and C-STORE operations. You must be able to track who accessed which study and when. Forward these logs to your SIEM for anomaly detection.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub