IoT Pentesting Basics

# IoT / embedded security - defender perspective

> Lab and authorised engagements only. We describe IoT weakness classes
> and defensive controls. Live device testing requires owner consent,
> RoE, and compliance with local laws and product warranties.

## Common weakness classes

- Default credentials shipped to production (admin/admin, root/root)
- Telnet/SSH on by default; unauthenticated APIs
- Firmware shipped without signature verification
- Hard-coded keys in firmware (extract via flash dump + binwalk)
- Mosquitto / MQTT without auth
- Update mechanism uses HTTP, not HTTPS, or skips signature check
- Bootloader unlocked; secure boot disabled
- Sensitive data over the LAN in cleartext (Modbus, BACnet)

## Controls defenders should require

- Unique per-device credentials at provisioning
- Mutual TLS for device-to-cloud
- Signed firmware updates; A/B partitions for safe rollback
- Secure boot with hardware root of trust (TPM, SE, OP-TEE)
- Disable all debug interfaces in production (JTAG, UART, recovery shells)
- Vendor-supported OTA pipeline; SBOM + CVE feed
- Device identity service (AWS IoT Core, Azure IoT Hub, GCP IoT Core successor)
- Segmented VLAN/subnet for IoT; deny by default to the corp LAN

## Detection signals

- Sudden firmware version downgrades (rollback attack)
- Devices reaching unexpected internet endpoints
- Spike in MQTT topics matching wildcards
- Credentials reused across many devices (provisioning leak)
- Power anomalies (side-channel attacks attempted)

## Engagement reporting

- Map findings to lifecycle stage (design, provisioning, runtime, decommissioning)
- Recommend SBOM + vulnerability management
- Network segmentation + zero-trust between devices and corp LAN
- Plan EOL: how do devices get decommissioned and keys revoked?

## Tools (defensive lens)

- binwalk, ghidra, radare2 - firmware analysis in a controlled lab
- BlinkDB / Foxglove for monitoring fleet behaviour
- AWS IoT Device Defender, Azure Defender for IoT
- Eclipse Hawkbit for OTA

# IoT engagements: get explicit authorisation, often physical too.
# Common findings: telnet open, default creds, unsigned firmware,
# secrets in firmware blobs (binwalk), weak TLS in companion apps.