How to Secure Medical Imaging: Defending Against Exposed DICOM Servers

Healthcare organizations invest heavily in the physical security of their facilities. Clinical areas are badge-access only, pharmacies are locked down, and paper records are strictly governed. However, as recent research highlights, network visibility does not always receive the same level of scrutiny.

Rapid7 Labs recently identified more than 30 UK-based systems responding to Digital Imaging and Communications in Medicine (DICOM) requests over Port 104. These systems were fully reachable from the public internet. While the researchers used Project Sonar strictly to verify service responsiveness without accessing patient data, the implication is clear: sensitive medical imaging infrastructure is inadvertently exposed to global scanning.

For defenders, this serves as a critical reminder that the default configurations of medical devices often prioritize connectivity over security. When Port 104 is exposed to the public internet without a VPN or encryption, any attacker using routine internet scanning can identify these systems. This exposure opens the door to potential data exfiltration of patient health information (PHI) or ransomware attacks targeting critical hospital infrastructure.

Technical Analysis

The vulnerability lies not in a specific software bug, but in network architecture and configuration management.

• Protocol: DICOM (Port 104/tcp). This is the standard protocol for transmitting medical images (MRIs, CT scans, X-rays) between devices and storage systems.
• Affected Systems: Picture Archiving and Communication Systems (PACS), medical imaging modalities (scanners), and viewing workstations.
• The Issue: These systems are frequently connected directly to the hospital network without segmentation. If the perimeter firewall allows inbound traffic on Port 104, or if the device is connected via a misconfigured cloud interface, the DICOM service listens for connections from the entire internet.
• Severity: High. DICOM data often contains unencrypted PHI. Furthermore, older DICOM implementations (DICOM Standard 2014c or earlier) may lack integrity checks or support for secure transport, making data interception trivial if network access is gained.

Defensive Monitoring

Defenders must actively scan their internal environments to ensure sensitive medical protocols are not bleeding out to the internet. Below are scripts and queries to help identify listening DICOM services and detect potential exposure attempts.

1. Identify Listening DICOM Services (Linux/Bash)

Run this script on your Linux-based security gateways or imaging servers to check if Port 104 is listening on a non-loopback interface.

#!/bin/bash

# Check if port 104 is listening and accessible externally
echo "Checking for listening DICOM services on Port 104..."

# Using netstat to find listening on 0.0.0.0:104
if netstat -tuln | grep -q ':104 '; then
    echo "[WARNING] Port 104 is LISTENING."
    netstat -tuln | grep ':104 '
else
    echo "[OK] Port 104 is not listening."
fi

# Optional: Check process utilizing the port
lsof -i :104

2. Identify Listening DICOM Services (Windows/PowerShell)

Use this PowerShell snippet to audit Windows-based PACS servers or modalities.

# Check for processes listening on Port 104 (DICOM)
$port = 104
$dicomListeners = Get-NetTCPConnection -LocalPort $port -State Listen -ErrorAction SilentlyContinue

if ($dicomListeners) {
    Write-Host "[WARNING] DICOM Service (Port $port) is listening:" -ForegroundColor Red
    $dicomListeners | Format-Table LocalAddress, LocalPort, OwningProcess, State
    
    # Identify the executable
    foreach ($listener in $dicomListeners) {
        $process = Get-Process -Id $listener.OwningProcess
        Write-Host "Process Name: $($process.ProcessName)"
        Write-Host "Path: $($process.Path)"
    }
} else {
    Write-Host "[OK] No processes found listening on Port $port." -ForegroundColor Green
}

3. Microsoft Sentinel KQL for External Access Attempts

If you are forwarding firewall logs or network traffic logs to Sentinel, use this KQL query to detect if external IP addresses are attempting to probe or connect to your DICOM port (104).

// Detect inbound connection attempts to DICOM Port 104 from External IPs
let DICOMPort = 104;
let PrivateIPs = ipv4_is_private(""); // Helper context, adjust based on specific RFC1918 prefixes if needed
NetworkEvent
| where DestinationPort == DICOMPort
| where ipv4_is_private(SourceIP) == false // Source is External
| project TimeGenerated, SourceIP, DestinationIP, DeviceName, OriginalProtocol
| summarize count() by SourceIP, DestinationIP, bin(TimeGenerated, 1h)
| order by count_ desc

Remediation

To protect your organization against the risks associated with exposed DICOM servers, IT and Security teams should implement the following controls immediately:

1. Perimeter Firewall Hardening: Ensure your external firewalls block inbound traffic on Port 104 (and any non-standard DICOM ports) from the internet. DICOM traffic should never be directly accessible from public IP spaces.

2. Network Segmentation: Move medical imaging devices (PACS, modalities) into a strict, isolated VLAN. Access to this VLAN should be restricted to specific workstations within the radiology department.

3. VPN Enforcement: If remote access to medical images is required for teleradiology, enforce access strictly through a VPN with Multi-Factor Authentication (MFA). Do not rely on simple port forwarding.

4. Application Layer Filtering: Configure next-generation firewalls (NGFW) to specifically inspect DICOM traffic. This ensures that even if a port is mistakenly opened, only valid DICOM protocol exchanges are allowed, blocking generic web shells or lateral movement tools.

5. Inventory and Audit: Perform a comprehensive scan of your network to identify every device listening on Port 104. Many organizations discover "shadow" DICOM servers that were set up temporarily for testing but never decommissioned.

By treating medical devices with the same rigorous security posture as servers and workstations, healthcare providers can significantly reduce their attack surface and protect patient data.

Related Resources

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