Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic

Daniel Beard

DEF CON 32 Creator Stage · Day 1 · Creator Stage

Overview

Daniel Beard's DEF CON 32 talk, "Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic," challenges long-held assumptions about physical access security in medical device environments. Beard, a software engineer with extensive experience in medical device development, demonstrates how a low-cost, off-the-shelf microcontroller can be weaponized to gain remote shell access to supposedly air-gapped medical devices. The core premise of the talk is to dismantle the belief that "physical access for an extended period of time" or "an internet connection for persistence" are prerequisites for exploiting medical devices via USB.

Watch on YouTube

Visual summary for Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic by Daniel Beard
Visual summary for Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic by Daniel Beard

Key moments

  1. 0:00 Talk introduction and medical device context
  2. 1:40 What is Bad USB? A quick explanation
  3. 2:30 Exposing flawed industry assumptions about Bad USB
  4. 3:30 Challenging assumptions: The requirements for a new attack
  5. 4:00 Introducing the $10 LilyGo T-Dongle S3 hardware
  6. 6:00 Unveiling RadioJack: The open-source Bad USB software

Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic

Speakers: Daniel Beard

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=zqGB07UaI6A

Overview

Daniel Beard's DEF CON 32 talk, "Breaking Boundaries: Popping Shells in the Airgap w $10 & Arduino Magic," challenges long-held assumptions about physical access security in medical device environments. Beard, a software engineer with extensive experience in medical device development, demonstrates how a low-cost, off-the-shelf microcontroller can be weaponized to gain remote shell access to supposedly air-gapped medical devices. The core premise of the talk is to dismantle the belief that "physical access for an extended period of time" or "an internet connection for persistence" are prerequisites for exploiting medical devices via USB.

The presentation focuses primarily on in vitro diagnostic (IVD) and therapeutic medical devices, which commonly feature a user interface running conventional operating systems like Windows or Linux, connected to a more critical embedded board. Beard introduces Radio Jack, an open-source tool running on a $10 USB dongle, capable of emulating a human interface device (HID) like a keyboard or mouse, establishing its own Wi-Fi network, and delivering payloads remotely. This research is particularly relevant for healthcare providers, medical device manufacturers, and security professionals, as it exposes a significant, yet often overlooked, attack vector that could lead to unauthorized control over critical medical equipment.

Background

▶ Watch: Talk introduction and medical device context (0:00)

For decades, the concept of BadUSB has been a known threat in cybersecurity. First publicly demonstrated in 2014, BadUSB exploits a fundamental trust model in operating systems: when a USB device announces itself as a legitimate peripheral (like a keyboard, mouse, or COM port), the operating system typically accepts this declaration without signature checks or validation. This allows a malicious USB device to inject keystrokes, mouse movements, or other commands as if a legitimate user were present. Examples of commercially available BadUSB tools include Hack 5's Rubber Ducky and OMG's Elite cable.

Despite the well-established nature of BadUSB, the medical device industry, according to Beard, has historically underestimated its threat in specific contexts. Common assumptions articulated in threat models and often heard in discussions include:

  1. Extended Physical Access: Exploiting BadUSB requires an attacker to maintain physical access to the device for an "extended period of time."
  2. Internet Connection for Persistence: An internet connection is necessary for the payload to achieve persistence or exfiltrate data, which is often absent in air-gapped or highly restricted medical networks.
  3. Logged-in Session: The attack can only be effective if a user is actively logged into the system, and frequent log-ins/outs mitigate this risk.

Beard's motivation for this research stemmed from his frustration with these persistent, flawed assumptions within the industry. Having personally coded on at least ten medical devices and collaborated on many more, he recognized that these presumptions did not hold up under scrutiny. His goal was to demonstrate that an attacker could achieve remote, persistent access to medical devices with minimal physical interaction, without relying on the target device's network connectivity, and by patiently waiting for a logged-in session. This redefinition of "physical access" highlights a critical blind spot in medical device security, particularly for devices with user interfaces running general-purpose operating systems.

Key Findings

▶ Watch: Exposing flawed industry assumptions about Bad USB (2:30)

The primary finding of Daniel Beard's talk is a stark refutation of conventional wisdom regarding BadUSB attacks on medical devices. He conclusively demonstrates that exploiting medical devices through USB does not require extended physical access, nor does it necessitate an active internet connection on the target device for persistence. Instead, an attacker can achieve remote, persistent shell access with a low-cost, easily concealable device and a brief, almost unnoticeable physical interaction.

Specifically, the key findings include:

  1. Redefining Physical Access: A momentary act of plugging in a small USB device is sufficient. The device can then operate wirelessly, allowing the attacker to retreat and control it remotely, eliminating the need for a prolonged physical presence that might raise suspicion. Beard contends that medical staff are unlikely to notice a small, innocuous-looking USB stick among the myriad of cables and peripherals often connected to medical equipment.
  1. Bringing Your Own Internet Connection: The exploit circumvents the air-gapped or restricted network challenge by having the attack device itself host a Wi-Fi access point. This allows the attacker to connect directly to the implant, deploy payloads, and maintain communication without the target device ever needing to connect to an external network or the internet.
  1. Delayed Payload Deployment: Unlike traditional BadUSB attacks that often execute payloads immediately upon insertion, Beard's solution allows the attacker to wait for opportune moments. This means payloads can be deployed when a user is logged in, during off-hours, or when specific conditions are met, significantly increasing the likelihood of success and stealth.
  1. Cost-Effective and Accessible Hardware: The entire attack infrastructure can be built using readily available, inexpensive hardware, specifically the LilyGo T-Dongle S3 (around $10) or the LilyGo LoRa S3 (around $15-$20). This low cost means attackers can afford to leave devices behind without significant financial loss, making the attack more practical for real-world scenarios.
  1. Practical Remote Shell Capabilities: The developed tool, Radio Jack, successfully emulates a keyboard and mouse, drops a PowerShell payload on Windows-based medical device frontends, and establishes a virtual COM port for persistent, interactive remote shell access via Telnet over Wi-Fi, or even LoRa for extended range. This provides an attacker with significant control over the user interface board, which, in turn, can manipulate the core medical functions.

These findings collectively highlight a critical vulnerability in the design and security posture of many medical devices, urging a re-evaluation of current threat models and defensive strategies.

Technical Deep Dive

▶ Watch: Challenging assumptions: The requirements for a new attack (3:30)

The attack vector targets the user interface boards of in vitro diagnostic (IVD) and therapeutic medical devices. These devices typically consist of an embedded board running a real-time operating system (RTOS) or bare-metal code with custom FPGAs for time-critical medical functions, and a separate main or user interface board. The UI board commonly runs general-purpose operating systems like Windows or Linux (Beard emphasizes, "Windows is everywhere in medical"), connected to the embedded board via standard interfaces such as CANbus, Cat6 Ethernet, or RS232. Owning the UI board effectively grants significant control over the medical device's functions, albeit potentially within safety bounds.

The core of Beard's solution, named Radio Jack, is an open-source software project (available at radiojack.io) designed to run on specific, low-cost microcontrollers. The primary hardware components discussed are:

  1. LilyGo T-Dongle S3: This device costs approximately $10-15 and resembles a standard USB stick. It features a color screen, Wi-Fi and Bluetooth capabilities, and is programmable using C++, MicroPython, or Arduino, leveraging the versatile ESP32 microcontroller. Its key attributes for this attack are its ability to emulate a USB HID (keyboard and mouse) and host its own Wi-Fi server.
  1. LilyGo LoRa S3: Introduced as an enhancement, this device costs $15-20 and offers similar features to the T-Dongle S3 (screen, Wi-Fi, Bluetooth, ESP32 programmability) but crucially includes LoRa (Long Range) radio capabilities. LoRa is a long-distance radio technology operating on consumer bands, not requiring a ham license, and boasting a theoretical range of "three plus miles" (Beard tested it up to 1.5 miles before line-of-sight issues). The integration of LoRa significantly extends the operational range of the attack, allowing the attacker to be miles away from the target device.

Radio Jack software functionality:

  • HID Emulation: It emulates both a keyboard and a mouse, allowing it to inject keystrokes and commands into the target system.
  • Wi-Fi Server: The device hosts its own Wi-Fi access point, enabling an attacker to connect to it wirelessly from a nearby location (e.g., another room). Each device uses its serial number to generate a unique SSID, preventing confusion when multiple devices are deployed. The default password is "thepassword" (all lowercase).
  • Telnet Interface: Once connected via Wi-Fi, the attacker can Telnet to the device's IP address and interact with a command-line interface.
  • Payload Delivery: The software includes pre-programmed payloads. For Windows targets, a PowerShell prompt payload is available. While currently Windows-centric, Beard notes that Linux payloads are also feasible.
  • Re-flashable: The device firmware can be easily updated, allowing for custom payloads or feature modifications.
  • Aesthetic Feature: A "laughing skull animation" is included, as Beard humorously notes, "What hacker tool would be complete without a laughing skull animation?"

Beard also briefly acknowledges a similar, more polished commercial product: the OMG Stealthlink cable over HIDX. This cable, released shortly after Beard's initial GitHub commit, also provides a backdoor over HID packets, offering similar remote access capabilities but at a higher price point and with more refined marketing. Beard's work, particularly the integration of LoRa, serves as a "one-up" to such commercial offerings by providing extreme range at a hobbyist budget.

The communication mechanism for the remote shell is clever: after the payload is dropped, it opens a PowerShell prompt and quickly types out a script. This script then waits for a connection on a virtual COM port (established by the USB device) and pipes all text between the COM port and the PowerShell session. This effectively creates an interactive shell, allowing the attacker to send commands and receive output over the wireless connection (Wi-Fi or LoRa) via the Telnet interface.

Demo / Proof of Concept

▶ Watch: Introducing the $10 LilyGo T-Dongle S3 hardware (4:00)

The demonstration of Radio Jack illustrates a straightforward yet potent attack workflow, designed for minimal physical interaction and maximum stealth. The process begins with the physical implantation of the device and proceeds to remote control:

  1. Physical Implantation: The first, "step zero," is to physically plug the LilyGo T-Dongle S3 or LoRa S3 into an available USB port on the target medical device. Beard highlights that this is a quick action, easily performed by simply "knocking it in" as one walks by. He dismisses the notion that this brief interaction would be noticed by medical staff, given the common presence of various cables and peripherals.
  1. Wireless Connection: Once plugged in, the device powers on and immediately hosts its own Wi-Fi access point. The device's small screen displays a unique SSID (derived from its serial number) and the default password, "thepassword" (all lowercase). The attacker, from a safe distance (e.g., an adjacent room or even miles away if using LoRa), connects their laptop or smartphone to this Wi-Fi network.
  1. Telnet Interface and Command Line: After connecting to the Wi-Fi, the attacker uses a Telnet client to connect to the IP address displayed on the device's screen. This establishes a command-line interface (CLI) with the Radio Jack software.
  1. Payload Deployment: Within the CLI, the attacker has several options:
  • drop the payload: This command initiates the core attack. The Radio Jack device, acting as a keyboard, rapidly types a PowerShell script into the target Windows machine. This script then minimizes itself and sets up a persistent communication channel.
  • open a remote power shell prompt: This is the result of dropping the payload. The PowerShell script on the target machine establishes a connection through a virtual COM port provided by the USB device. It then pipes all input from the COM port to the PowerShell session and all output back to the COM port. This effectively grants the attacker an interactive remote shell.
  • type as a keyboard: This allows the attacker to manually type any sequence of keys, useful for navigating login prompts or performing specific actions before dropping the main payload. For instance, if the target Windows machine requires authentication, the attacker can wait until they observe a legitimate user log in, then use this feature to type credentials or execute commands within the authenticated session. Beard explicitly states there is no authentication bypass; rather, the attack leverages the ability to wait for a logged-in session.
  • com port: This command manages the communication channel for the remote shell.

The entire process allows the attacker to gain an interactive PowerShell prompt on the medical device's Windows frontend, enabling them to execute arbitrary commands, potentially manipulate device settings, or exfiltrate data, all while appearing innocuous and being physically remote. Beard demonstrated this live, with a device actively plugged into a medical device in the Biohacking Village at DEF CON. He confirmed testing on "a couple of different Windows devices, mostly PCs."

Defensive Implications

▶ Watch: Unveiling RadioJack: The open-source Bad USB software (6:00)

The findings presented in "Breaking Boundaries" underscore critical vulnerabilities in the security posture of many medical devices, necessitating a re-evaluation of defensive strategies, particularly concerning physical access and USB security. Daniel Beard outlines straightforward, yet often overlooked, mitigations that manufacturers and healthcare providers should implement:

  1. Cover Unused USB Ports: The most immediate and fundamental mitigation is to physically cover or block any USB ports that are not actively required for device operation or authorized service. If a USB port is not essential for normal functionality, it should be inaccessible. Beard humorously suggests that if an attacker needs to use a dremel tool to access a port, it significantly increases the "physical access" requirement and the likelihood of detection, thereby deterring opportunistic attacks. This simple step can prevent the initial physical implantation of a malicious device.
  1. Disable the USB Stack by Default: For USB ports that are necessary for occasional use (e.g., for exporting reports, flashing firmware, or service technician access), the USB stack should be disabled by default. Access to USB functionality should only be enabled explicitly by the user or an authorized service technician, after a specific action or authentication. Examples include:
  • User-initiated actions: Enabling the USB port only when a user selects an "Export Report" function.
  • Service technician login: Requiring a service technician to log in with special credentials before the USB port becomes active for firmware updates or diagnostics.
  • Explicit consent: A clear on-screen prompt asking the user to confirm the activation of USB functionality.

By implementing this "least privilege" approach for USB access, the attack surface is dramatically reduced. An attacker can no longer simply plug in a BadUSB device and expect it to be recognized and functional immediately. This forces them to either wait for a legitimate user to perform an enabling action or to find a more sophisticated exploit, significantly increasing the complexity and risk of the attack.

These mitigations aim to address the core assumptions Beard debunked: they increase the required physical access (by making it more noticeable or requiring tools), prevent immediate payload deployment, and reduce the window of opportunity for an attacker to leverage a logged-in session. Implementing these changes requires cooperation between medical device manufacturers (in design and firmware), and healthcare organizations (in procurement, deployment, and policy enforcement).

Key Takeaways

  • Traditional BadUSB assumptions are outdated for medical devices: The belief that BadUSB attacks require "extended physical access" or "an internet connection for persistence" on air-gapped medical devices is false.
  • Low-cost hardware enables sophisticated attacks: Devices like the LilyGo T-Dongle S3 ($10-$15) and LilyGo LoRa S3 ($15-$20) provide the necessary HID emulation, Wi-Fi, and even LoRa capabilities for remote exploitation.
  • Radio Jack offers remote shell access: The open-source Radio Jack software allows an attacker to drop PowerShell payloads on Windows-based medical device frontends and gain interactive remote shell access via Telnet over Wi-Fi or LoRa.
  • Minimal physical interaction, maximum stealth: An attacker only needs a brief moment to plug in the device; subsequent command and control can be performed wirelessly from a distance, even miles away with LoRa.
  • Crucial mitigations are often overlooked: Manufacturers and healthcare providers must physically cover unused USB ports and disable the USB stack by default, requiring explicit user or authenticated service technician action to enable USB functionality.
  • Windows is a prevalent attack surface: The widespread use of Windows on medical device user interfaces makes them prime targets for such BadUSB attacks, granting control over critical medical functions.

About the Speaker(s)

Daniel Beard is a seasoned software engineer currently working at Medcrypt. His career has been deeply entrenched in the medical device industry, having previously served as a director at Medisao and as CTO of Promenade Software. In these roles, he worked as a contractor with numerous companies, personally contributing code to at least 10 different medical devices and collaborating on many more. His extensive experience spans various types of medical equipment, including in vitro diagnostic (IVD) instruments (lab equipment), implantable devices, therapeutic devices, and infusion pumps. This background provides him with a unique and intimate understanding of the design, architecture, and inherent security challenges within medical device development, which he leveraged to expose the vulnerabilities discussed in his talk. Beard conducted this research in his own time, and all views expressed are his own, not reflecting those of his current or past employers.

All talks from DEF CON 32 Creator Stage