Full Report
Sometimes you need to get in the way of a hardware device and its controller, and see what it has to say for itself. If you are lucky, the two parts are communicating using a serial port, and then it’s relatively simple to do. In this post, I will explain two scenarios where I had to do this, and the approach that I took in each. As a bonus, I’ll also show some hardware that I put together to make it easier.
Analysis Summary
# Tool/Technique: Serial Port Interception (Man-in-the-Middle)
## Overview
Techniques described focus on intercepting and analyzing serial (UART) communication between a hardware device (like an IoT dongle or controller) and its host system or other connected hardware, often by acting as a Man-in-the-Middle (MITM) proxy. The goal is to observe, understand, and potentially manipulate the data exchanged, which is often used for authorization or proprietary protocol communication.
## Technical Details
- Type: Technique / Tool (in context of application usage)
- Platform: Embedded systems, Controllers running various operating systems (e.g., Linux where FTDI devices are enumerated). The intercepts involve USB-to-Serial adapters (like FTDI devices) and custom hardware setups.
- Capabilities: Listening, logging, and relaying serial traffic between two endpoints. Can be extended to modify traffic. Custom hardware solutions (like using an ESP32 with ESPHome) can implement this logic.
- First Seen: Not explicitly stated, but the specific implementation described is from a February 2024 article.
## MITRE ATT&CK Mapping
This activity primarily targets hardware aspects and initial access/discovery related to specialized systems.
- **TA0003 - Persistence** (Less direct, but observation can lead to better implantation)
- T1047 - Windows Management Instrumentation (WMI)
- *Note: Direct mappings are weak as the focus is physical/protocol analysis, but it falls under general Discovery/Analysis.*
- **TA0007 - Discovery**
- T1082 - System Information Discovery (Discovery of device communication protocols)
- **TA0011 - Command and Control** (If the modified traffic is used for subsequent malicious control)
- T1071 - Application Layer Protocol
- T1071.001 - Web Protocols (If proprietary protocols are reversed)
## Functionality
### Core Capabilities
- **Traffic Eavesdropping:** Connecting USB-to-Serial adapters (e.g., FTDI) in a crossover configuration (TX to RX, RX to TX, common ground) to passively monitor communication using a serial terminal emulator (like `picocom`).
- **Baud Rate Discovery:** Iteratively testing and identifying the correct communication speed (e.g., 115200 or 9600 baud) used by the serial link.
- **MITM / Data Forwarding:** Using tools like `socat` on Linux to establish a link between two serial devices (`/dev/ttyUSBx`), logging the data exchange in hex format (`-x`), and forwarding bytes without echoing.
- **Device Spoofing (Hardware Emulation):** Modifying the Vendor ID (VID) and Product ID (PID) of a substitute device (e.g., FTDI adapter EEPROM via `ftdi_eeprom` utility) to appear identical to the expected hardware dongle, tricking the controller software into communicating with the substitute.
### Advanced Features
- **Protocol Reversal:** Capturing the serial exchange to reverse engineer proprietary or binary communication protocols (e.g., for authorization keys like PSK).
- **Traffic Tampering (Potential):** While initially used for observation, the technique described using custom firmware (like ESPHome on ESP32) or `socat` streams allows for modifying the relayed traffic before it reaches the destination.
- **Stream Redirection:** Implementing the UART MITM logic within an embedded framework (like ESPHome) to log all traffic internally or redirect serial lines to configurable TCP server ports instead of physical ports, enabling remote analysis using tools like Mallet.
## Indicators of Compromise
This technique involves intermediary tools and data capture rather than specific malware artifacts.
- File Hashes: N/A (Focus is on legitimate/repurposed tools or custom firmware)
- File Names: `socat`, `picocom`, `ftdi_eeprom` (used legitimately during analysis). Log files like `serial.log`.
- Registry Keys: N/A
- Network Indicators: N/A (Traffic is usually local/USB enumeration initially, though TCP redirection via `socat` is mentioned, e.g., `TCP:serial-pitm:2001`)
- Behavioral Indicators: Enumeration of a USB device that reports VID/PID matching known serial adapters (FTDI) when a specialized dongle is expected. High-frequency, non-standard data transfer over known serial devices.
## Associated Threat Actors
No specific threat actors are mentioned as the post describes general hardware penetration testing/analysis techniques. The methods are applicable to security researchers, hardware hackers, and potentially APTs targeting embedded systems.
## Detection Methods
Detection focuses on monitoring USB device enumeration events and identifying unusual communication activity on serial ports.
- Signature-based detection: Not applicable for the technique itself, but tools like `socat` or firmware binaries on embedded devices could be flagged.
- Behavioral detection: Detection of unauthorized VID/PID changes on known serial adapters. Monitoring unexpected serial traffic volume or baud rates on system serial ports.
- YARA rules: Not applicable.
## Mitigation Strategies
Mitigation focuses on hardware security and secure provisioning of embedded devices.
- Prevention Measures: Implementing secure boot or hardware attestation mechanisms to ensure only trusted firmware runs on the device.
- Hardening Recommendations: Physically securing hardware interfaces (UART ports) to prevent unauthorized physical access. Relying on cryptographic authentication rather than protocol analysis of serial link data for authorization. When using custom serial hardware (like FTDI), ensuring the EEPROM configuration cannot be trivially updated by non-administrative users.
## Related Tools/Techniques
- **Hardware Adapters:** FTDI USB-UART adapters, generic USB Serial cables.
- **Software Tools:** `picocom` (serial terminal), `socat` (forwarder/proxy), `ftdi_eeprom` (EEPROM configuration tool).
- **Concepts:** Hardware Man-in-the-Middle (MITM), UART sniffing.
- **Custom Logic:** ESPHome component for custom UART MITM implementation or stream forwarding.