IoT Penetration Testing Methodology India

Why IoT Pentest Is a Distinct Discipline

An IoT product is not a single application. It is a stack: physical hardware, a microcontroller or SoC running firmware, one or more radio protocols (WiFi, BLE, Zigbee, LoRa, cellular), an outbound connection to a cloud backend, and almost always a mobile companion app driving the user experience. A defect in any layer can compromise the device or its data.

Indian enterprises now deploy IoT across smart metering, CCTV and NVR systems, connected medical devices, manufacturing sensors, fleet telematics, building management, and retail point-of-sale. The 2024 and 2025 advisories from CERT-In and global vendors made it clear: untested IoT is the single largest growing entry point into corporate networks.

Standard web app or network pentests miss most IoT risk because the device firmware, radio protocols, and hardware debug ports never appear in scope. A proper IoT engagement budgets time for hardware teardown, firmware extraction and offline analysis, alongside the usual network and cloud testing.

Methodology Overview: OWASP IoT Top 10 + PTES Adapted

Our IoT methodology blends the OWASP IoT Top 10 (2018, current revision in draft) with the Penetration Testing Execution Standard (PTES) and the OWASP Firmware Security Testing Methodology (FSTM). The combined flow is: reconnaissance, hardware teardown, firmware acquisition, firmware analysis, dynamic testing, protocol analysis, cloud backend testing, and reporting.

Reconnaissance starts with vendor datasheets, FCC filings, teardown photographs, GitHub repositories and CVE history for the specific SoC and firmware framework (FreeRTOS, Zephyr, Linux, OpenWrt, Mongoose OS, ESP-IDF, etc.). Documentation work before the lab session shortens the engagement materially.

• Reconnaissance: vendor docs, FCC filings, GitHub, CVE history, prior research
• Hardware teardown: photograph PCB, identify SoC, flash chip, debug headers
• Firmware acquisition: OTA capture, SPI flash dump, vendor portal scrape, UART boot logs
• Firmware analysis: binwalk, firmwalker, ghidra/IDA, hardcoded secrets, weak crypto
• Dynamic testing: emulation under QEMU, fuzz services, abuse exposed daemons
• Protocol analysis: MQTT, CoAP, Zigbee, BLE, custom RF
• Cloud backend: device registration, OTA channel, MQTT broker, BOLA, IDOR

Firmware Analysis: Where Most Findings Surface

Firmware is the operating system and application code that runs on the device. Acquiring it is step one. Common acquisition paths include downloading the OTA update from a vendor cloud, dumping the SPI flash chip with a CH341A or Bus Pirate programmer, dumping internal flash through JTAG or SWD, or pulling the firmware over UART from a debug shell exposed at boot.

Static Analysis

Once the firmware image is extracted, binwalk identifies embedded filesystems (squashfs, jffs2, cramfs, ubifs) and bootloaders. Tools like firmwalker, trufflehog and gitleaks then sweep the extracted filesystem for hardcoded API keys, private SSH keys, vendor-default credentials, TLS private keys, and signed-URL secrets. Binary review in Ghidra or IDA Pro surfaces backdoor accounts, weak hashing (MD5, unsalted SHA1), insecure random number generation, and stack canary or ASLR misconfiguration.

Dynamic Emulation

Where the firmware uses common architectures (ARM, MIPS), we emulate the extracted root filesystem under QEMU or firmadyne. This lets us start the device daemons (web admin, telnet, custom proprietary services) in a sandbox and fuzz them with afl++, boofuzz, or curl-based scripts. Findings surface fast: command injection in cgi-bin, authentication bypass in admin endpoints, buffer overflows in custom services, and exposed debug ports left enabled in production builds.

Hardware Interfaces: JTAG, SWD, UART, SPI Flash

Physical access drops the cost of compromise to near zero on most commodity devices. We start every IoT engagement with a board teardown, high-resolution photographs, and component identification. Test points, headers and unpopulated pads on the PCB are almost always debug interfaces left over from manufacturing.

UART is the fastest win. A logic analyser or Bus Pirate identifies the baud rate, and a USB-to-TTL adapter gives a serial console. Roughly half of consumer-grade Indian IoT devices we have tested expose a boot log, a U-Boot prompt, or an interactive root shell on UART with no authentication. JTAG and SWD then provide full halt and step debug access to the SoC, including memory read, register inspection and firmware extraction. SPI flash chips can be desoldered or read in-circuit with a chip clip and a CH341A programmer, giving us the firmware without ever touching the running device.

Protocol Testing: MQTT, CoAP, Zigbee, BLE

Once the device is talking to its network, the wire protocols become the test surface. We instrument with Wireshark, sniff with hcitool or Ubertooth for BLE, kill MAC randomisation, and capture all device chatter for inspection. The headline issues are surprisingly consistent across vendors.

MQTT and CoAP

MQTT brokers are commonly deployed with anonymous access, shared topic namespaces (where one tenant can subscribe to another tenant's device topic), and unencrypted plaintext on port 1883 instead of TLS on 8883. We test with mosquitto_sub/pub, MQTT-PWN and custom Python clients. CoAP, used heavily in low-power smart-meter and sensor networks, suffers from message tampering when DTLS is not enforced, plus reflection-amplification risk when servers respond to spoofed source addresses.

Zigbee and BLE

Zigbee key extraction is performed with KillerBee, Ubertooth and Atmel RZRAVEN-class sniffers. Devices that use the default Zigbee link key (5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39) or that never rotate trust-centre keys are trivially impersonated. For Bluetooth Low Energy, we attack pairing (Just Works versus Numeric Comparison), capture and replay GATT writes, and abuse undocumented GATT characteristics that expose configuration or root commands. Tools used include nRF Connect, gatttool, btlejack and bettercap.

Cloud Backend Testing: Often the Weakest Link

Every connected device is paired to a backend that handles registration, OTA updates, telemetry ingestion and mobile-app sync. This backend is a regular REST or MQTT API, and it tends to be where the most serious findings sit. Device IDs are typically guessable or sequential, OTA channels often lack signed firmware verification, and provisioning flows frequently allow one customer to register a device into another customer's tenancy.

Our backend testing follows the OWASP API Security Top 10 with IoT-specific additions: BOLA on device IDs and serial numbers, broken authentication on device-side certificates and JWTs, mass assignment on device-configuration endpoints, MQTT topic-level authorisation gaps, and missing signature verification on OTA payloads. A weak backend means a fully patched device can still be cloned, hijacked or bricked through the cloud.

Reporting, Re-Test and Compliance Mapping

Our IoT reports map each finding to OWASP IoT Top 10, CVSS v3.1 base and temporal score, and where relevant to MITRE ATT&CK for ICS or Enterprise. Sector-specific clients receive additional mapping: ETSI EN 303 645 for consumer IoT, IEC 62443 for industrial deployments, IS 17428 for Indian privacy assurance, and DPDP Act Section 8 (reasonable security safeguards) where personal data is involved.

Each finding includes step-by-step proof-of-concept, recorded video where appropriate, hex dumps, network captures, and engineer-grade remediation guidance the device team can act on. Free re-test within 90 days is part of every Codesecure engagement, so the vendor can ship a fix and validate it without a separate purchase order.