On the last three IoT security testing projects, I opened the device body, connected to UART – and in two cases out of three received a root-hull without a single password request. The third device at least requested a login, but a pair admin:admin went straight. According to the industry, in the vast majority of IoT-assassements, at least one debugging interface (UART or JTAG) remains fully open in the production version of the device. It's not a bug, it's the industry.
Recorded from the words of our colleague. The first person story.
The IoT-devices pentest differs from web application testing in that the attacking surface simultaneously covers iron, firmware, radio channels, cloud APIs and mobile applications. Standard network pentest methodologies cover a third of that space. Below is the reproducible process that I use on real-world projects, with reference to OWASP IoT Security Testing Guide (ISTG) and MITRE ATT&CK.
UART (Universal Asynchronous Receiver-Transmitter) is a basic dual-wire hardware protocol used on the Internet of Things for sequential communication.
JTAG (Join Test Action Group) is an industry standard for hardware interface used in many IoT devices to debugg, test, and program microcontrollers or systems on a chip.
IoT device and OWASP ISTG coping model
According to ITG, any IoT device is divided into two categories of elements:
Internal elements: processor (ARM, AVR, x86), memory (EEPROM, flash chips), firmware (installed + update mechanism) and data exchange services (network demons, debugging services).
Interfaces: internal (UART, JTAG, SPI, I2C - are available after opening the case), physical (USB, Ethernet - available from the outside), wireless (Wi-Fi, BLE, Zigbee, Z-Wave) and custom (web panel, display, camera).
For the accumulation of a pentest, the ISTG uses the attacker model with two axles:
Note: Simplified author's adaptation of the OWASP ITG model is given.
At the intersection of these axes, it is determined which components fall into the slaughterhouse. IP camera on the wall of the building - Level 2/AA-1: testing wireless interfaces, network services, web panel. A smart device that an attacker can buy and disassemble houses is a 4/AA-3 level: test everything, including memory chips and debugging interfaces on board.
This stage is not a formality. Without a clear scooping punchere IoT becomes a chaotic pumping nmap-hoi in the device with the subsequent "vulnerabilities not found" in the report. I saw such reports - on the device then found an open UART with a rute.
Intelligence and fingerprinting IoT infrastructure
IoT device reconnaissance begins long before physical contact. The first step is to determine what we have before us.
Foreign Intelligence (PA-1). For devices sticking out on the Internet, Shodan and Censys are standard entry points. Request http.title:"Camera" country:"RU" Shodan gives thousands of results with open web interfaces. According to MITRE ATT&CK, it is Search Open Technical Databases (T1596, Reconnaissance; also relevant T1595.002 - Vulnerability Scanning) But Shodan is just the beginning. It is more useful to watch the FCC ID device: each radio emitting device sold in the US is certified by the FCC, and photos of the intestines - PCB, chips, antennas are publicly available. This is Gather Victim Host Information: Hardware (T1592.001) / Firmware (T1592.003) - not yet opening the body, you know which processor is inside and where on the board to look for UART.
Local Intelligence (PA-2). In the segment of the local network scanning nmap -sV -O --script=banner <target> reveals open ports and service banners. IoT devices often give themselves to characteristic fingerprints: lighttpd, uhttpd, GoAhead-Webs, Boa HTTPd as a web server. Open ports 1883 (MQTT without TLS), 5683 (CoAP) or non-standard ports in the range of 8000-9000 - typical markers.
Zigbee and Z-Wave devices require an SDR receiver or a specialized adapter (CC2531 for Zigbee, RTL-SDR for frequency range reconnaissance). Wireshark has a built-in Zigbee Dissector. To capture traffic - KillerBee (zbdump) with adapter CC2531. Well-known Trust Center Link Key ZigBeeAlliance09 allows you to decrypt the balance procedure and pull out the network key for subsequent decryption of traffic. Yes, the key lies right in the specification - and yes, it works.
What to collect. At this stage, the device model, the firmware version (often visible in the web interface or banner), open ports and services used by the protocols, the availability of standard accounting data. All this determines the further vector.
JTAG and Flash Memory Dam
JTAG gives deeper access - up to the turn-based debugging of the processor. JTAGulator connects to all suspicious contact areas and through BYPASS/IDCODE scan defines the TDI/TDO/TCK/TMS ped enough to. OpenOCD connects to the found interface and allows you to read/write memory, stop the processor and dig in registers.
For devices where UART is locked and JTAG is disconnected through fuse bits, there is a direct dump flash chip. The CH341A or Dedpprogramtor is removed the full content of SPI/NOR-flash. Team flashrom -p ch341a_spi -r dump.bin Creates a post-byte copy. Next is the styling analysis.
Analysis of IoT device firmware
The firmware is the central element of IoT security testing. According to the ISTG classification, it is an ISTG-FW component, and it is divided into two parts: the firmware (ISTG-FW[INST]) and the update mechanism (ISTG-FW[UPDT]).
The first step is to retrieve the file system. If you already have a dump (with UART, via web update interface or through CH341A), binwalk finds and unpack everything automatically:
What to look for inside:
• Hardware Accounting Data (T1552.001, Credential Access): strings firmware.bin | grep -i -E 'pass|pwd|key|secret|token'- First team, not the last one. Firmwalker automates this process by checking shadow, passwd, configuration files, SSL certificates and private keys.
• Outdated Components (OWASP IoT I5): checking versions of BusyBox, OpenSSL, Linux kernels via Linux stringsand grep. Devices with BusyBox 1.19 and OpenSSL 1.0.1 - regular find in 2025. No exception, but the norm.
• Debugging features in bunging: Ghidra helps to find hidden backdoor accounts and debug endings that are not visible through a web interface. On one project so found a hidden CGI endpoint with command injection - it was not in the documentation, nor in the web interface.
• Update mechanism (OWASP IoT I4): does the firmware download over HTTP or HTTPS? Is the digital signature checked before installation? Is downgrade possible to a vulnerable version?
For dynamic analysis, firmware can be emulated. FirmAE and Firmadine unfold the firmware image in QEMU, allowing you to interact with the web interface and network services of the device without physical access to iron. But the applicability is limited: firmware with non-standard drivers or proprietary hardware abstractions often do not rise in the emulator. Approximately one in three firmware requires manual finishing QEMU-configuration.
Network Level: Interception and Attacks on IoT Protocols
Network analysis - OWASP IoT I7 (Insecure Data Transfer and Storage) and I2 (Insecure Network Services). By MITRE ATT&CK - Network Sniffing (T1040, Discovery/Credential Access)
MQTT without authentication
MQTT is a de facto standard of messaging between IoT devices. Problem: In the tested IoT installations, brokers often work without authentication and without TLS. Connection to such a broker is trivial:
In my practice, through an open MQTT broker, it was possible to obtain: GPS tracker coordinates, readings of medical sensors, manual commands of industrial controllers. Once - full credentials for cloud APIs directly in the MQTT message. Open text. In 2024.
CoAP and proprietary protocols
CoAP (port 5683/UDP) is an easy-to-weight alternative to HTTP for constrained devices. Wireshark decodes CoAP against it. Zeek with plugins allows you to write rules for detecting anomalies in IoT traffic. Proprietary binary protocols on non-standard ports require reverse: recording traffic in pcap, analysis of packet structure, identification of patterns. Patience is more important than the tools.
What to pay attention to
Exploitation of web interfaces and API
Most IoT devices provide a web interface for management – and it’s one of the most leaky components. MITRE AT&CK - Exploit Public-Facting ApplicationT1190, Initial Access) and Password Guessing (T1110.001, Credential Access)
Built-in web servers (GoAhead, uhttpd, lighttpd, Boa) often contain vulnerabilities that have long been closed in the “big” web, but live for decades in firmware: command injection through the parameters of diagnostic utilities (ping, traceroute), directory traversal, SSRF through the update functions.
A specific chain that I have reproduced repeatedly:
1. Selection of standard accounting data (OWASP IoT I9 - Insecure Default Settings). Lists of default passwords for IoT devices are collected in SecLists/Passwords/Default-Credentials.
2. If the web interface contains a diagnostic form (ping, DNS lookup) - command injection check: ; id, | cat /etc/shadow,
Recorded from the words of our colleague. The first person story.
The IoT-devices pentest differs from web application testing in that the attacking surface simultaneously covers iron, firmware, radio channels, cloud APIs and mobile applications. Standard network pentest methodologies cover a third of that space. Below is the reproducible process that I use on real-world projects, with reference to OWASP IoT Security Testing Guide (ISTG) and MITRE ATT&CK.
UART (Universal Asynchronous Receiver-Transmitter) is a basic dual-wire hardware protocol used on the Internet of Things for sequential communication.
JTAG (Join Test Action Group) is an industry standard for hardware interface used in many IoT devices to debugg, test, and program microcontrollers or systems on a chip.
IoT device and OWASP ISTG coping model
According to ITG, any IoT device is divided into two categories of elements:
Internal elements: processor (ARM, AVR, x86), memory (EEPROM, flash chips), firmware (installed + update mechanism) and data exchange services (network demons, debugging services).
Interfaces: internal (UART, JTAG, SPI, I2C - are available after opening the case), physical (USB, Ethernet - available from the outside), wireless (Wi-Fi, BLE, Zigbee, Z-Wave) and custom (web panel, display, camera).
For the accumulation of a pentest, the ISTG uses the attacker model with two axles:
Note: Simplified author's adaptation of the OWASP ITG model is given.
At the intersection of these axes, it is determined which components fall into the slaughterhouse. IP camera on the wall of the building - Level 2/AA-1: testing wireless interfaces, network services, web panel. A smart device that an attacker can buy and disassemble houses is a 4/AA-3 level: test everything, including memory chips and debugging interfaces on board.
This stage is not a formality. Without a clear scooping punchere IoT becomes a chaotic pumping nmap-hoi in the device with the subsequent "vulnerabilities not found" in the report. I saw such reports - on the device then found an open UART with a rute.
Intelligence and fingerprinting IoT infrastructure
IoT device reconnaissance begins long before physical contact. The first step is to determine what we have before us.
Foreign Intelligence (PA-1). For devices sticking out on the Internet, Shodan and Censys are standard entry points. Request http.title:"Camera" country:"RU" Shodan gives thousands of results with open web interfaces. According to MITRE ATT&CK, it is Search Open Technical Databases (T1596, Reconnaissance; also relevant T1595.002 - Vulnerability Scanning) But Shodan is just the beginning. It is more useful to watch the FCC ID device: each radio emitting device sold in the US is certified by the FCC, and photos of the intestines - PCB, chips, antennas are publicly available. This is Gather Victim Host Information: Hardware (T1592.001) / Firmware (T1592.003) - not yet opening the body, you know which processor is inside and where on the board to look for UART.
Local Intelligence (PA-2). In the segment of the local network scanning nmap -sV -O --script=banner <target> reveals open ports and service banners. IoT devices often give themselves to characteristic fingerprints: lighttpd, uhttpd, GoAhead-Webs, Boa HTTPd as a web server. Open ports 1883 (MQTT without TLS), 5683 (CoAP) or non-standard ports in the range of 8000-9000 - typical markers.
Zigbee and Z-Wave devices require an SDR receiver or a specialized adapter (CC2531 for Zigbee, RTL-SDR for frequency range reconnaissance). Wireshark has a built-in Zigbee Dissector. To capture traffic - KillerBee (zbdump) with adapter CC2531. Well-known Trust Center Link Key ZigBeeAlliance09 allows you to decrypt the balance procedure and pull out the network key for subsequent decryption of traffic. Yes, the key lies right in the specification - and yes, it works.
What to collect. At this stage, the device model, the firmware version (often visible in the web interface or banner), open ports and services used by the protocols, the availability of standard accounting data. All this determines the further vector.
JTAG and Flash Memory Dam
JTAG gives deeper access - up to the turn-based debugging of the processor. JTAGulator connects to all suspicious contact areas and through BYPASS/IDCODE scan defines the TDI/TDO/TCK/TMS ped enough to. OpenOCD connects to the found interface and allows you to read/write memory, stop the processor and dig in registers.
For devices where UART is locked and JTAG is disconnected through fuse bits, there is a direct dump flash chip. The CH341A or Dedpprogramtor is removed the full content of SPI/NOR-flash. Team flashrom -p ch341a_spi -r dump.bin Creates a post-byte copy. Next is the styling analysis.
Analysis of IoT device firmware
The firmware is the central element of IoT security testing. According to the ISTG classification, it is an ISTG-FW component, and it is divided into two parts: the firmware (ISTG-FW[INST]) and the update mechanism (ISTG-FW[UPDT]).
The first step is to retrieve the file system. If you already have a dump (with UART, via web update interface or through CH341A), binwalk finds and unpack everything automatically:
What to look for inside:
• Hardware Accounting Data (T1552.001, Credential Access): strings firmware.bin | grep -i -E 'pass|pwd|key|secret|token'- First team, not the last one. Firmwalker automates this process by checking shadow, passwd, configuration files, SSL certificates and private keys.
• Outdated Components (OWASP IoT I5): checking versions of BusyBox, OpenSSL, Linux kernels via Linux stringsand grep. Devices with BusyBox 1.19 and OpenSSL 1.0.1 - regular find in 2025. No exception, but the norm.
• Debugging features in bunging: Ghidra helps to find hidden backdoor accounts and debug endings that are not visible through a web interface. On one project so found a hidden CGI endpoint with command injection - it was not in the documentation, nor in the web interface.
• Update mechanism (OWASP IoT I4): does the firmware download over HTTP or HTTPS? Is the digital signature checked before installation? Is downgrade possible to a vulnerable version?
For dynamic analysis, firmware can be emulated. FirmAE and Firmadine unfold the firmware image in QEMU, allowing you to interact with the web interface and network services of the device without physical access to iron. But the applicability is limited: firmware with non-standard drivers or proprietary hardware abstractions often do not rise in the emulator. Approximately one in three firmware requires manual finishing QEMU-configuration.
Network Level: Interception and Attacks on IoT Protocols
Network analysis - OWASP IoT I7 (Insecure Data Transfer and Storage) and I2 (Insecure Network Services). By MITRE ATT&CK - Network Sniffing (T1040, Discovery/Credential Access)
MQTT without authentication
MQTT is a de facto standard of messaging between IoT devices. Problem: In the tested IoT installations, brokers often work without authentication and without TLS. Connection to such a broker is trivial:
In my practice, through an open MQTT broker, it was possible to obtain: GPS tracker coordinates, readings of medical sensors, manual commands of industrial controllers. Once - full credentials for cloud APIs directly in the MQTT message. Open text. In 2024.
CoAP and proprietary protocols
CoAP (port 5683/UDP) is an easy-to-weight alternative to HTTP for constrained devices. Wireshark decodes CoAP against it. Zeek with plugins allows you to write rules for detecting anomalies in IoT traffic. Proprietary binary protocols on non-standard ports require reverse: recording traffic in pcap, analysis of packet structure, identification of patterns. Patience is more important than the tools.
What to pay attention to
Exploitation of web interfaces and API
Most IoT devices provide a web interface for management – and it’s one of the most leaky components. MITRE AT&CK - Exploit Public-Facting ApplicationT1190, Initial Access) and Password Guessing (T1110.001, Credential Access)
Built-in web servers (GoAhead, uhttpd, lighttpd, Boa) often contain vulnerabilities that have long been closed in the “big” web, but live for decades in firmware: command injection through the parameters of diagnostic utilities (ping, traceroute), directory traversal, SSRF through the update functions.
A specific chain that I have reproduced repeatedly:
1. Selection of standard accounting data (OWASP IoT I9 - Insecure Default Settings). Lists of default passwords for IoT devices are collected in SecLists/Passwords/Default-Credentials.
2. If the web interface contains a diagnostic form (ping, DNS lookup) - command injection check: ; id, | cat /etc/shadow,
, whoami.
3. Analysis of API queries via Burp Suite: there is often no authorization on API engrades - IDOR, mass assignment, access to other people's devices through the search of serial numbers.
4. Checking the firmware update mechanism: If the device downloads an HTTP update without a signature verification (OWASP IoT I4), it is possible to change the firmware through MITM.
5. For devices whose web interfaces are available from the Internet, Metasploit contains modules for a number of popular IoT platforms. In msfconsole team search type:exploit iotwill show the available exploits; search type:exploit routerand search type:exploit camera- additional modules for specific classes of devices. Application Context: decision tree selection vector
The choice of attack vector on the IoT device depends on the terms of the project. Below is the diagram that I use to prioritize:
[ATTACH type="full"]5480[/ATTACH]
The principle is simple: if there is physical access - start with iron. UART-wheel in 15 minutes gives more information than three days of the phase-over interface. If there is no physical access - firmware from the manufacturer's website + network analysis closes most of the scough.
Restrictions and where the methodology breaks down
Not every IoT device is amenable to the process described. Restrictions that I face regularly:
• Proprietary RTOS. Devices on FreeRTOS, Zephyr or fully custom firmware without Linux kernels are not unpacked by binwalk. You need a full reverse in Ghidra from scratch - these are days of work, not hours. On one project, we spent four days only to understand the file system format.
• Protected chips. Processors with Secure Boot, TrustZone and burnt fuse bits block firmware reading and turn off JTAG. Bypasses required llitching-attacks (voltage fault injection) - specialized equipment (ChipWhisperer, ~$250-350) and expertise. It is not “connected and removed the dump”, but the research work.
• Encrypted firmware. If the firmware is encrypted and the key is not extracted from the bootloader - static analysis is not possible without hardware attacks on cryptography.
• Emulation. FirmAE and Firmadyne work with ~70% firmware based on GNU/Linux. The remaining 30% require manual QEMU or not emulated at all due to the tie-in on proprietary hardware modules.
These limitations do not mean that a punch no is possible – they mean that the scump and budget should take into account the actual complexity of the device. Two-day IoT-pentest covers the network layer and superficial firmware analysis. Full-fledged testing with a hardware level and reverse is at least a week per device.
Conclusion
In the seven years of working with embedded systems, I came to the conclusion that the main problem of IoT security is not the complexity of attacks, but the elementary nature of most finds. Hang-shaped passwords, open UART with root-coul, MQTT without authentication, HTTP updates - all this OWASP IoT Top 10 2018 Category I1 and I9, and they cover the vast majority of real vulnerabilities. Manufacturers of embedded devices in their mass have not yet passed the path that web development took ten years ago.
