Study guide
8.4 IoT Hacking Concepts & Defense
EC-Council Certified Ethical Hacker CEH
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 CEH Exam Format, Cost & Eligibility 1.2 The Five Phases of Ethical Hacking 1.3 Information Security Fundamentals 1.4 Ethical Hacking Concepts, Scope & Legal Framework 1.5 The CEH Domains & Your Study Priority Map
2 Reconnaissance, Footprinting, Scanning & Enumeration
2.1 Footprinting & Reconnaissance Concepts 2.2 Footprinting Sources & Techniques 2.3 Network Scanning Concepts 2.4 Banner Grabbing, OS Fingerprinting & Scanning Beyond IDS/Firewall 2.5 Enumeration 2.6 Vulnerability Scanning & Countermeasures
3 Vulnerability Analysis & System Hacking Phases
3.1 Vulnerability Analysis Concepts 3.2 System Hacking Methodology Overview 3.3 Gaining Access: Password Attack Concepts 3.4 Privilege Escalation Concepts 3.5 Maintaining Access: Backdoors, Rootkits & Persistence 3.6 Covering Tracks, Anti-Forensics & Blue-Team Detection
4 Malware Threats, Sniffing & Social Engineering
4.1 Malware Concepts and Taxonomy 4.2 Malware Analysis and Detection 4.3 Sniffing Concepts and Layer 2 Attacks 4.4 Sniffing Countermeasures and Detection 4.5 Social Engineering Types and Human Psychology 4.6 Social Engineering and Insider Threat Defenses
5 Network & Perimeter Hacking
5.1 Denial of Service and DDoS Attacks 5.2 Session Hijacking 5.3 Evading IDS and IPS (Defensive Focus) 5.4 Evading Firewalls 5.5 Evading Honeypots and Defensive Deception 5.6 Network Security Controls and Architecture 5.7 Packet Analysis and Secure Protocols for Defenders
6 Web Server & Web Application Hacking
6.1 Web Server Attacks & Hardening 6.2 OWASP Top 10 Overview 6.3 Injection: SQL Injection & Command Injection 6.4 Cross-Site Scripting (XSS) & CSRF 6.5 Authentication, Session & Access-Control Flaws 6.6 API & Web App Security Testing Concepts
7 Wireless Network Hacking
7.1 Wireless Concepts and Standards 7.2 Wireless Encryption 7.3 Wireless Threats and Attack Concepts 7.4 Wireless Security Countermeasures
8 Mobile Platform, IoT & OT Hacking
8.1 Mobile Platform Threats & Security Models 8.2 Mobile Attack Vectors & Risks 8.3 Mobile Device Management & Enterprise Defense 8.4 IoT Hacking Concepts & Defense 8.5 OT, ICS & SCADA Security
9 Cloud Computing & Cryptography
9.1 Cloud Computing Concepts 9.2 Cloud Threats & Attack Surfaces 9.3 Cloud Security Controls 9.4 Cryptography Fundamentals 9.5 PKI & Cryptographic Applications 9.6 Cryptanalysis, Crypto Attacks & Best Practices
8.4 IoT Hacking Concepts & Defense
Key Takeaways Explain This Topic AI
IoT architecture is commonly modeled in layers: edge devices, communication/network, cloud/platform, and application/user
The OWASP IoT Top 10 (2018) leads with I1 Weak, Guessable, or Hardcoded Passwords and I2 Insecure Network Services
The Mirai botnet (2016) recruited ~150,000 IoT cameras and DVRs via 61 default Telnet credentials and powered ~1 Tbps DDoS attacks including the Dyn outage
Default credentials and weak or absent secure-update mechanisms are the most exam-relevant systemic IoT weaknesses
Network segmentation onto a dedicated IoT VLAN plus hardening (change defaults, signed firmware, disable unused services) are the core defenses
Last updated: June 2026
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.
- Layer What lives here Typical weakness
- Edge / device Sensors, actuators, microcontrollers Default/hardcoded credentials, no anti-tamper
Communication / network Wi-Fi, Bluetooth/BLE, Zigbee, Z-Wave, cellular, gateways Unencrypted transport, exposed services
- Cloud / platform Device management, data ingestion, APIs Weak API authentication, insecure data handling
- Application / user Mobile/web apps, dashboards Weak authentication, poor privacy controls
- 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:
- Weak, Guessable, or Hardcoded Passwords
- Insecure Network Services
- Insecure Ecosystem Interfaces (web, API, cloud, mobile)
- Lack of Secure Update Mechanism
- Use of Insecure or Outdated Components
- Insufficient Privacy Protection
- Insecure Data Transfer and Storage
- Lack of Device Management
- Insecure Default Settings
- 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
Defense What it does
Network segmentation Place IoT on a dedicated VLAN /isolated network with strict allow-list firewall rules so a compromised device cannot pivot to sensitive systems
- Change defaults Rotate every default credential at provisioning; disable Telnet and unused services
- Signed firmware updates Require cryptographically signed, verified updates; track end-of-support
- Encrypted transport Enforce TLS/encrypted protocols instead of cleartext
Inventory & monitoring Maintain an accurate device inventory; baseline normal traffic and alert on anomalies (a sensor suddenly scanning the network signals compromise)
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.