The findings below come from ORDR's observation of three device groups inside hospital networks: a patient monitoring system, a CT scanner, and operational technology (OT) controllers. Each finding is traffic that a properly configured firewall should have blocked or flagged. Taken together, they show medical and building devices reaching out to the open internet, and the internet reaching back in.
Three insights stand out:
- Devices are talking to places they should never go. Patient monitors reached Russian analytics services and social media sites, and industrial controllers connected to TOR exit nodes and prohibited IPs in eight countries.
- The internet is reaching in. An outside IP opened a plaintext Telnet session into a CT scanner, and five blocklisted Chinese IPs swept 44 controllers on SSH and Telnet in one automated event.
- Firewalls are not enforcing basic rules. Telnet, VNC, FTP, unencrypted HTTP, and peer-to-peer traffic all crossed the perimeter. None of these require new technology to stop; they require existing firewalls to be configured and maintained.
Table A1. Sample observations on hospital devices reaching out to the internet
Device | Finding (severity) | What ORDR observed |
Patient monitoring system | Russia traffic detected (Critical) | Communication with a Russian search engine and its app-analytics service. Patient monitors have no reason to contact these services. |
Patient monitoring system | Social media on clinical devices (High) | Traffic to major video-sharing and social media platforms from patient monitors. |
Patient monitoring system | STUN / P2P traffic (Medium) | A public STUN server (Singapore) on UDP 3478/3479. Peer-to-peer NAT traversal is unexpected on patient monitors. |
Patient monitoring system | Unencrypted HTTP traffic (Medium) | 139 flows on port 80, including operating-system updates, web font services, and crash-reporting endpoints. |
Patient monitoring system | IPSec-NAT-T tunnel detected (Medium) | Flows to a cellular carrier's VPN gateway on UDP 4500. VPN tunnel activity from a patient monitor warrants investigation. |
CT scanner | Inbound Telnet, port 23 (Immediate action) | External IP <IP-1> opened a Telnet session into the scanner; credentials and commands travel in plaintext. |
CT scanner | Same IP on SSH and Telnet (Review required) | The same IP, <IP-1>, used both SSH (22) and Telnet (23): a legacy script, misconfiguration, or unauthorized access via the manufacturer's IP range. |
CT scanner | Unrestricted inbound SSH (Review required) | SSH sessions from <IP-2> and <IP-1>. Compromised vendor credentials would grant direct shell access. |
CT scanner | Low-reputation flow (Monitor) | HTTPS to <IP-3> (Japan) with a reputation score of 40, likely a manufacturer front-office endpoint. |
OT devices (PLCs) | SSH/Telnet sweep from China (Critical) | 5 blocklisted Chinese IPs swept 44 PLCs on SSH (22) and Telnet (23) in one coordinated, automated event. Risk score 8.0. |
OT devices (PLCs) | Prohibited IP outreach (High) | PLCs contacted 49 prohibited IPs in 8 countries on high ephemeral ports, consistent with botnet command-and-control beaconing. 52 alarms. |
OT devices (PLCs) | PLCs reaching TOR exit nodes (High) | 26 PLCs connected outbound to 20 TOR exit nodes, which can mask command-and-control or data theft. The IPs are also on the Log4j blocklist. |
OT devices (PLCs) | Inbound VNC and FTP (Medium) | VNC (5900) and FTP (21) sessions from prohibited IPs, a remote-desktop pathway into active industrial controllers. |
Not every flow was a problem. The patient monitors had no contact with threat-intel-flagged IPs, 95% of their traffic was encrypted, and their manufacturer cloud and telemetry connections were legitimate. That is the point: hospitals need to see device traffic clearly enough to tell expected telemetry from risk, and firewalls configured to block the rest.