IoT Pentest Checklist

IoT penetration testing is a security assessment that targets the entire ecosystem of a device—from its physical components to the radio frequency signals it emits—in addition to the web/API, mobile application, and network service tests performed in traditional IT penetration testing.

Each device is evaluated individually to identify its attack surfaces, and penetration testing activities are conducted accordingly. The IoT Pentest Checklist discussed in this article is designed to target components commonly found in most devices. Devices may not always use well-known or standard protocols.

IoT penetration testing can be grouped into five main phases: preparation and information gathering, hardware analysis, firmware analysis, network and protocol analysis, and application layer analysis.

Each phase is presented as a checklist by phrasing the required tasks as questions—like a task or a step.

Preparation and Information Gathering

Has asset inventory identification been performed?
Has a comprehensive list of all components in the device ecosystem been created?
Have the device model and software versions been documented?
Has the mobile application used to manage the device been identified?
Have cloud services and API infrastructure been identified?
Has the physical inspection been completed?
Have labels and markings on the device been inspected?
Have accessible ports on the device been identified?
Has OSINT been performed?
Have PCB photos and RF modules been identified by querying the FCC ID database?
Are manufacturer documents available online?
Have the datasheet and technical documentation been reviewed?
Have known vulnerabilities of the device been researched?

Hardware Analysis

Has PCB analysis been performed?
Has a connection been established via debug ports?
Has the UART port been tested?
Is UART access possible?
Have TX, RX, and GND pins been identified?
Has the baud rate been determined?
Can boot logs be captured?
Has privileged shell access been obtained?
Is the obtained shell running with root privileges?
Have privilege escalation attacks been attempted?
Does shell access require a username and password?
Has brute-force testing been performed?
Are credentials stored within the firmware?
Has shell access been obtained by bypassing the bootloader?
Is JTAG access possible?
Have JTAG pins been identified using tools such as JTAGulator?
Is register inspection and live debugging possible?
Is memory read access available?
Has the device firmware been extracted?
Has the communication bus been identified?
Can SPI traffic be monitored?
Can I2C traffic be monitored?
Can a memory dump be obtained?
Can a memory dump be obtained via JTAG/SWD?
Can a memory dump be obtained via shell access?
Are advanced hardware attacks feasible?
Can glitching attacks be performed?
Can side-channel attacks be performed?

Firmware Analysis

Can the firmware be obtained?
Can firmware be extracted by attaching to the chip using an SOIC clip?
Can firmware be obtained via OTA update packages?
Can firmware be obtained from publicly available manufacturer resources?
Can firmware be extracted via the mobile application?
Can firmware be obtained via debug interfaces?
Can firmware be extracted by desoldering the flash chip?
Can the firmware package be unpacked?
Can the firmware be extracted using automated tools?
Has automated extraction been performed using Binwalk?
Has recursive scanning been performed with Binwalk?
Has raw data analysis been performed on extracted firmware components?
Has data been extracted using the `strings` tool?
Have extracted files been analyzed using `hexdump`?
Can the firmware be extracted using manual methods?
Has the firmware been manually extracted using the `dd` tool?
Has filesystem-specific extraction been performed?
Can firmware be extracted using SquashFS tools?
Can firmware be extracted using Sasquatch?
Can firmware be extracted using YAFFS2 tools?
Can binary firmware be converted to ELF format for reverse engineering?
Is the bare-metal firmware composed solely of raw executable code?
Has the firmware binary been converted to ELF format?
Have appropriate tools (e.g., `esp-bin2elf`) been used for Binary → ELF conversion?
Has the converted ELF been analyzed with reverse engineering tools?
Has the ELF been analyzed using Ghidra or IDA Pro?
Have function boundaries and call flows been analyzed?
Has entropy analysis been performed on the firmware?
Is high and uniform entropy observed? (If yes, firmware is likely encrypted)
Can the firmware encryption key be obtained?
Has the encryption key been extracted via hardware debug interfaces (JTAG/SWD)?
Has bootloader analysis revealed encryption keys or related information?
Has reverse engineering of the mobile application revealed encryption keys?
Has static analysis been performed?
Has sensitive information and secret scanning been performed on the firmware?
Has `strings` analysis been performed?
Have hardcoded passwords been identified?
Have API keys and access tokens been extracted?
Have URLs, IP addresses, and endpoints been identified?
Have embedded certificates been identified?
Have automated secret scanning tools been used?
Has Firmwalker been executed?
Has ByteSweep been executed?
Has regex-based secret scanning been performed?
Have JWT tokens been identified using regex?
Have AWS keys been identified using regex?
Have password hashes (MD5, SHA variants) been identified using regex?
Has sensitive file analysis been performed?
Have web server configuration files been reviewed?
Have `/etc/passwd`, `/etc/shadow`, and similar files been reviewed?
Have startup scripts been reviewed?
Have network and service configuration files been reviewed?
Has binary analysis and reverse engineering been performed?
Have binary files been inspected?
Have executables and shared libraries been identified?
Have CPU architecture and endianness been identified?
Have binaries been analyzed using Ghidra and IDA Pro?
Have authentication and logic mechanisms been analyzed?
Have authentication and authorization mechanisms been reviewed?
Has firmware update logic been analyzed?
Have cryptographic implementations been reviewed?
Has dangerous function analysis been performed?
Are unsafe functions (`strcpy`, `strcat`, `sprintf`) used?
Are `system()` calls present?
Are there command execution primitives?
Are there code paths leading to buffer overflows?
Have logical flows been identified?
Has the presence of hardcoded backdoors been checked?
Has the presence of hidden debug functions been checked?
Have authorization bypass conditions been identified?
Has third-party component and CVE analysis been performed?
Have third-party components been identified?
Have known CVEs for the used versions been checked?
Has dynamic analysis been performed?
Has the firmware been emulated using QEMU or Firmadyne?
Have runtime behavior, running services, logs, and debug output been analyzed?

IoT Protocol Analysis

Has discovery and service enumeration been performed?
Have open ports and exposed services been identified?
Have common IoT ports and services been identified?
Are MQTT ports (1883 / 8883) open?
Are CoAP ports (5683 / 5684) open?
Are custom TCP/UDP services present?
Has protocol-specific detection been performed?
Has CoAP been identified?
Is the `/.well-known/core` endpoint accessible?
Can exposed CoAP resources and methods be enumerated?
Has Bluetooth Low Energy (BLE) been identified?
Can BLE services and characteristics be enumerated?
Can UUIDs and access permissions be identified?
Have BLE analysis tools been used?
Bettercap
nRF Connect
Has MQTT been identified?
Has topic discovery been performed using wildcards?
`#`
`+`
Have publish/subscribe permissions been identified?
Has traffic monitoring been performed?
Is network traffic capture possible?
Can traffic be captured using Wireshark or tcpdump?
Can MITM attacks be performed?
Has ARP poisoning been attempted?
Has transparent proxying been tested?
Have encryption mechanisms been analyzed?
Is Bluetooth traffic monitoring possible?
Has Bluetooth traffic been captured?
Has Android Bluetooth HCI Snoop Log been used?
Has pre-encryption BLE traffic been captured?
Has protocol reverse engineering–suitable data been obtained?
Is RF traffic monitoring possible?
Have over-the-air RF signals been captured?
Have KillerBee framework or RTL-SDR been used?
Has unencrypted or weakly protected RF traffic been analyzed?
Have authentication and authorization tests been performed?
Have weak pairing mechanisms been tested?
Has BLE pairing been analyzed?
Is “Just Works” pairing used?
Is MITM protection present?
Is key extraction possible?
Crackle (TK / LTK recovery)
Have brute-force attacks been performed?
Have weak password brute-force attacks been performed for MQTT?
Have default credential brute-force attacks been performed for MQTT?
Have authorization bypass tests been performed?
Can authentication flags be manipulated?
Is direct access to restricted endpoints possible?
Is privilege escalation possible via protocol misuse?
Have packet manipulation and replay attacks been performed?
Have replay attacks been performed?
Can valid control commands be captured?
Unlock
Power on/off
Are rolling-code or nonce protections present?
Is packet manipulation possible?
Can packet fields and hex values be modified? (`0x01 / 0x00`)
Is unexpected device behavior observed?
Has input manipulation been tested?
Have malformed packets with invalid lengths or characters been sent?
Have crash, reset, or memory corruption scenarios been tested?
Have denial-of-service tests been performed?
Can MQTT brokers be DoS attack via CONNECT flooding?
Have CPU and memory exhaustion scenarios been tested?
Has RF jamming been tested?
Has signal interference on RF / ZigBee frequencies been tested?
Has device fail-safe behavior been observed?
Have resilience and recovery mechanisms been tested?

Application Layer Penetration Testing

Have web application penetration tests been performed?
Have embedded web services running on the device been identified?
Have penetration tests been performed on the embedded web application?
Have mobile application penetration tests been performed?
Have static tests been performed for the mobile application?
Have plaintext API keys, access tokens, etc. been identified?
Has automated scanning been performed using MobSF?
Have dynamic tests been performed for the mobile application?
Can API requests originating from the mobile app be intercepted?
Have penetration tests been performed for the APIs used by the mobile application?

The mindmap version of this checklist is shown below. You can also access the high-resolution version via this link and the PDF file via this link.

Published by

0 responses to “IoT Pentest Checklist”

Leave a Reply

Your email address will not be published. Required fields are marked *