8.4 IoT Hacking Concepts & Defense

Why IoT Is High-Yield Conceptually

The Internet of Things (IoT) adds huge numbers of low-cost, often unpatchable devices — cameras, sensors, thermostats, smart locks, routers — to networks. CEH focuses on systemic weakness classes and architectural defenses rather than firmware exploitation. Expect questions on default credentials, broken update mechanisms, exposed services, and segmentation. The defining real-world lesson is that constrained devices ship with weak defaults and rarely get patched, so the same flaw can be exploited at internet scale.

IoT Architecture (Layered Model)

A common way to reason about IoT is a layered model. Mapping a described problem to a layer helps select the right control.

Communication Models and the Attack Surface

IoT devices interact through patterns such as device-to-device, device-to-gateway, device-to-cloud, and back-end data-sharing. A constrained sensor frequently talks to a gateway that aggregates and forwards traffic to the cloud. The gateway is a high-value control point: it can enforce encryption, filtering, and segmentation that the constrained devices themselves cannot. , UART/JTAG), the wireless and network protocols, the cloud APIs, the companion mobile app, and the update channel. A weakness at any of these can compromise the whole ecosystem.

OWASP IoT Top 10 (2018) — Conceptual

OWASP's IoT Top 10 (2018 release) names the dominant systemic risks:

1. Weak, Guessable, or Hardcoded Passwords
2. Insecure Network Services
3. Insecure Ecosystem Interfaces (web, API, cloud, mobile)
4. Lack of Secure Update Mechanism
5. Use of Insecure or Outdated Components
6. Insufficient Privacy Protection
7. Insecure Data Transfer and Storage
8. Lack of Device Management
9. Insecure Default Settings
10. Lack of Physical Hardening

Exam emphasis: items 1, 2, 4, and 9 — credentials, exposed services, broken/missing updates, and insecure defaults — are the most frequently tested systemic flaws because together they enable large-scale botnet recruitment of IoT devices.

Case Study: The Mirai Botnet

Mirai (2016) is the canonical IoT attack CEH expects you to recognize. It scanned the internet for devices with open Telnet ports and attempted login using a built-in table of about 61 common default username/password pairs — exactly the OWASP I1 (weak/default passwords) plus I2 (insecure network services) combination. It enslaved roughly 150,000 IoT devices, predominantly IP cameras, CCTV systems, DVRs, and home routers, into a botnet. S. The lesson is systemic, not exotic: unchanged default credentials on internet-reachable services let a single weakness scale to a global-impact botnet.

The fix is forced credential rotation at provisioning, disabling Telnet/exposed services, and segmentation.

Common Weaknesses (Detection Lens)

• Default credentials: shipped admin/admin-style logins never changed. Detect via inventory and credential auditing; remediate with forced credential rotation at provisioning.
• Weak/absent secure update: firmware not signed, not verified, or never updated. Detect by tracking firmware versions and vendor end-of-support status.
• Exposed services: management ports, Telnet, or debug interfaces reachable from untrusted networks. Detect via network discovery and asset inventory.

Defenses: Segmentation and Hardening

Segmentation limits blast radius, hardening shrinks the attack surface, and monitoring catches what slips through — the same defense-in-depth logic as the mobile stack, applied to constrained devices.

IoT Communication Protocols and Their Risk

CEH expects you to recognize the short-range and low-power protocols that connect IoT devices, because each has its own pairing and encryption weaknesses. You are not asked to attack them — you are asked to know that they exist and that they widen the attack surface when left at defaults.

• Wi-Fi: ubiquitous but power-hungry; risk is rogue access points and weak/default credentials on the device's management interface.
• Bluetooth / Bluetooth Low Energy (BLE): short-range pairing; legacy pairing modes and always-on discoverability create proximity attack opportunities.
• Zigbee / Z-Wave: low-power mesh protocols common in home automation; weak key management in older deployments allows traffic capture.
• Cellular / LPWAN (LTE-M, NB-IoT, LoRaWAN): wide-area, low-power links; risk centers on the join/provisioning keys and back-end APIs.
• MQTT / CoAP: lightweight application-layer messaging protocols for constrained devices; insecure when brokers allow anonymous publish/subscribe or run without TLS.

The common thread is that these protocols favor low power and simplicity, so security is often optional and frequently disabled by default. The gateway is again the right enforcement point: it can require TLS, authenticate devices, and segment the constrained-device network from everything else.

Reasoning Through an IoT Scenario

Approach an IoT question the same disciplined way as a mobile one. First, place the weakness on a layer (device, network, cloud, or app). Second, name the OWASP IoT category — most exam scenarios collapse to weak/default credentials (I1), exposed services (I2), missing secure updates (I4), or insecure defaults (I9). Third, pick the architectural defense: segmentation for containment, hardening (rotate credentials, signed firmware, disable services) for the device, and monitoring for detection.

A scenario describing mass remote takeover almost always points to I1 + I2 and the Mirai pattern; a scenario describing one risky sensor on a flat network points to segmentation; a scenario describing tampered or un-updatable firmware points to I4 and signed updates. Anchoring to these patterns lets you answer reliably without device-level exploitation knowledge.