IoT Security Assessment
Connected devices expand the attack surface of every organization that deploys them. GDF's certified analysts assess IoT devices, smart systems, and enterprise IoT deployments for vulnerabilities, firmware weaknesses, insecure communications, and exploitable flaws, producing findings that support both technical remediation and litigation or regulatory proceedings.
IoT Penetration Testing
IoT security assessments identify vulnerabilities in device configurations, network architecture, and cloud backend design. IoT penetration testing goes a step further: GDF's analysts actively attempt to exploit identified vulnerabilities to confirm exploitability, characterize the real-world impact, and test the controls that are supposed to prevent lateral movement from compromised devices into the rest of the network. The result is a finding set based on what an adversary can actually accomplish, not just what might theoretically be possible, giving organizations and their legal counsel a technically definitive basis for risk decisions and remediation prioritization.
Firmware Extraction and Analysis
Firmware is the foundation of IoT device security. The firmware running on a device determines its exposed services, default credentials, cryptographic implementations, update mechanisms, and the third-party components it includes. GDF's firmware extraction and analysis process begins with obtaining the firmware image: through download from the manufacturer's update infrastructure, interception of an over-the-air update, or physical extraction from the device using hardware interfaces.
Physical firmware extraction uses hardware debugging interfaces present on most IoT device circuit boards: UART console access, JTAG debugging interfaces, and SPI or NAND flash chip extraction. UART interfaces frequently expose bootloader access or a Linux shell with root privileges when security hardening has not been applied. JTAG interfaces provide low-level processor debugging access that allows firmware read-out even from devices that have disabled software-accessible debug modes. Chip-off extraction physically removes flash memory from the board for direct reading, applicable when other methods are not available.
Extracted firmware is analyzed using GDF's toolset including binwalk for filesystem extraction, Ghidra and IDA Pro for binary reverse engineering, and custom scripts for automated detection of known-vulnerable components, hardcoded credential patterns, and insecure cryptographic usage. Analysis identifies the exact firmware version and component manifest, hardcoded credentials and private keys, cryptographic weaknesses in authentication and update verification implementations, and backdoor functionality including undocumented administrative interfaces. For organizations involved in product liability or supply chain litigation, firmware analysis findings provide the technical evidence needed to establish whether a security defect was present at a specific point in time.
API Security Testing
IoT devices rely on APIs for communication with mobile applications, cloud management platforms, and peer devices. These APIs are frequently developed under significant time pressure, with security testing that does not extend beyond basic functionality verification. GDF's IoT API security testing examines these interfaces for the full range of application security vulnerabilities applicable to REST, GraphQL, MQTT, CoAP, and proprietary API protocols used in IoT ecosystems.
Authentication testing covers whether the API enforces proper credential requirements, whether default credentials used during device provisioning are required to be changed before the device becomes operational, and whether API tokens have appropriate expiration, revocation, and scope limitation. Authorization testing examines whether the API enforces that a user's credentials can only access that user's devices and data, testing for insecure direct object references and broken function-level authorization that could allow one customer to access another customer's device management interface or sensor data. GDF regularly identifies IoT APIs where the device identifier used in API calls is the only access control, allowing any authenticated user to access any device by substituting a different identifier in the request.
Data exposure testing examines what sensitive information is returned in API responses beyond what the requesting application requires, including device location data, user account information, and operational data that should not be accessible through the tested interface. Injection testing covers SQL injection, NoSQL injection, and command injection in API parameters that are processed by backend infrastructure. Rate limiting and resource exhaustion testing verifies that API endpoints apply controls to prevent abuse that could disrupt service for other users or generate significant cost.
Wireless Protocol Security Testing
IoT devices communicate over a wide range of wireless protocols, each with distinct security characteristics and vulnerability classes. GDF's wireless protocol testing covers the protocols most commonly found in enterprise and industrial IoT deployments.
Zigbee testing examines network join procedures for susceptibility to rogue coordinator attacks, tests whether the network uses link keys or only network keys (network-key-only configurations allow any joined device to decrypt all network traffic), and assesses whether the coordinator enforces device authentication before admitting nodes to the network. Zigbee relay attacks and traffic capture analysis are used to identify devices transmitting sensitive data without adequate encryption.
Bluetooth Low Energy (BLE) testing covers pairing security (verifying that Just Works pairing, which provides no authentication, is not used for security-sensitive device connections), advertisement data exposure (checking whether device advertisements include sensitive information such as serial numbers, MAC addresses not rotated, or operational status), and GATT service authorization (testing whether characteristics that control device function enforce appropriate access controls before responding to write commands). BLE man-in-the-middle testing is conducted where the pairing mechanism is susceptible to interception.
LoRaWAN testing examines network join procedures (OTAA vs ABP activation security), application session key handling, and whether devices implement replay protection. LoRaWAN networks using ABP (Activation By Personalization) with static session keys are particularly vulnerable to replay attacks and frame counter reset issues that can allow an adversary to inject commands or decrypt traffic.
MQTT protocol testing covers broker authentication requirements (whether brokers permit anonymous connections), topic-level authorization (whether clients can subscribe to topics belonging to other users or publish to topics they should not have access to), TLS implementation quality, and retained message security. MQTT brokers misconfigured to permit unauthenticated connections or broad topic subscriptions have been a source of significant data exposure incidents in enterprise IoT deployments.
Device-Level Exploitation
Device-level exploitation testing confirms whether identified vulnerabilities can be used by an adversary to gain unauthorized access to an IoT device and, from that position, move to other systems or extract sensitive data. GDF conducts device-level exploitation in a controlled manner: either against a test device provided by the client, or against production devices during a coordinated maintenance window with explicit approval from the device owner and network operations team.
Hardware interface exploitation tests whether exposed debug ports provide privileged access without authentication. A UART shell with automatic root login, a JTAG interface with an unprotected bootloader, or an accessible SPI flash chip can give an adversary complete control of the device. GDF documents the specific hardware access required, the tools needed, and the degree of physical access an attacker would need to exploit the finding, providing the context needed for risk assessment and physical security remediation.
Memory extraction techniques including cold boot attacks, bus probing, and debug interface memory reads are used to extract credentials, encryption keys, and sensitive configuration data from device RAM and non-volatile storage. Extracted credentials and keys are documented as exploitation evidence and support follow-on testing of connected cloud services and peer devices that use the same credentials.
Cloud Backend Security Testing
The cloud platforms that manage enterprise IoT deployments are as much a part of the attack surface as the devices themselves. A cloud backend with inadequate tenant isolation, weak API authentication, or insecure direct object references can expose data from an entire device fleet to an attacker who compromises a single user account. GDF's cloud backend testing examines IoT management platforms with the same rigor applied to enterprise web application security assessments.
Tenant isolation testing verifies that one customer's data, devices, and administrative capabilities are not accessible to another customer's credentials. This testing is particularly important for multi-tenant SaaS IoT platforms, where the data of thousands of organizations may be co-located in a shared infrastructure. GDF tests tenant isolation by attempting to access devices, data, and administrative functions belonging to a test tenant using credentials provisioned for a different test tenant. Failures in tenant isolation are among the most severe findings in IoT cloud assessments because they affect every customer of the platform simultaneously.
Device management API testing covers the full set of operations available through the cloud management interface: device provisioning and de-provisioning, firmware update initiation, configuration push, command execution, and data export. For each operation, GDF tests whether authorization is enforced at the device level (not just at the account level), whether operations can be performed against devices not belonging to the authenticated user, and whether the API validates that commands sent to devices are within the intended scope of the operation. For connected IoT platforms involved in litigation or regulatory proceedings, cloud backend findings document the specific technical mechanisms by which unauthorized access to device data or control was possible.
IoT Penetration Testing Coverage
- Firmware Extraction
- UART/JTAG Access Testing
- Chip-Off Extraction
- Binary Reverse Engineering
- REST/MQTT API Testing
- API Authorization Testing
- Zigbee Protocol Testing
- BLE Security Testing
- LoRaWAN Testing
- MQTT Broker Testing
- Device-Level Exploitation
- Memory Extraction
- Cloud Backend Testing
- Tenant Isolation Testing