This chapter covers the unique security challenges and penetration testing techniques for IoT (Internet of Things) devices and SCADA/ICS (Supervisory Control and Data Acquisition / Industrial Control Systems) environments. These systems are increasingly targeted by attackers, and the PT0-002 exam includes specific objectives (3.5) related to assessing their security. While only about 5-8% of exam questions directly address this topic, understanding the fundamental differences from traditional IT pentesting is critical for passing. This chapter will equip you with the knowledge to identify vulnerabilities in embedded devices, industrial protocols, and control networks, and to execute safe, effective tests that respect safety and operational constraints.
Jump to a section
Imagine a large factory complex where the main control room is the brain. The control room has operators who monitor and send commands to machines on the factory floor. Each machine has a simple, rugged controller that can only understand a few basic commands like 'start', 'stop', 'set speed 50'. These controllers are not designed for security; they trust any command that comes from the control room. Now, the factory has a separate IT network for email and internet access, but the control room is connected to the factory floor via a dedicated cable. An attacker who gains access to the IT network might try to cross over into the control network. To prevent this, a firewall is placed between the IT network and the control network, but it's set to allow only specific protocols (like Modbus TCP) from the control room to the machines. However, the firewall does not inspect the contents of those commands. So, if an attacker compromises a workstation in the control room, they can send a malicious 'set speed 9999' command that the machine will blindly execute, causing physical damage. This is exactly how SCADA/ICS attacks work: once inside the control network, attackers exploit the lack of authentication and integrity checks in industrial protocols like Modbus, DNP3, or CIP. The factory floor is a fortress where the walls are strong (air-gap), but the doors are wide open (trusted protocols).
What are IoT and SCADA/ICS?
IoT (Internet of Things) refers to a network of physical devices—from smart thermostats to industrial sensors—that are embedded with electronics, software, and connectivity to collect and exchange data. SCADA (Supervisory Control and Data Acquisition) and ICS (Industrial Control Systems) are the hardware and software systems used to monitor and control industrial processes like power generation, water treatment, and manufacturing. While IoT is consumer- and enterprise-focused, SCADA/ICS is mission-critical for national infrastructure.
Key Differences from IT Systems
Availability vs. Confidentiality: In IT, data confidentiality is often top priority; in ICS, availability and safety are paramount. A system crash in IT means lost data; in ICS, it could mean a power outage or explosion.
Patching: IT systems can be patched frequently; ICS systems often run for years without updates because patches may disrupt operations or require costly downtime.
Protocols: IT uses HTTP, SSH, TLS; ICS uses Modbus, DNP3, Profinet, CIP, BACnet, which often lack encryption and authentication.
Architecture: ICS networks are typically segmented into zones (e.g., corporate IT, control center, field devices) with strict firewalls (often using the Purdue Model).
Purdue Model for ICS Security
The Purdue Enterprise Reference Architecture (PERA) divides ICS into levels: - Level 0: Physical processes (sensors, actuators) - Level 1: Basic control (PLCs, RTUs) - Level 2: Supervisory control (HMI, SCADA servers) - Level 3: Operations management (MES, historian) - Level 4: Enterprise IT (ERP, email) - Level 5: External networks (internet)
Security controls are placed between levels, especially between Level 3 and 4, to prevent attacks from the corporate network from reaching the control network.
Common IoT Vulnerabilities
Hardcoded credentials: Many IoT devices come with default usernames/passwords (e.g., admin/admin) that users never change.
Unencrypted communication: Devices often use HTTP, Telnet, or MQTT without TLS.
Insecure firmware updates: Updates may not be signed, allowing attackers to push malicious firmware.
Lack of input validation: Command injection, buffer overflows in web interfaces.
Weak authentication: No multi-factor, weak password hashing (e.g., MD5).
Common SCADA/ICS Vulnerabilities
Unsecured protocols: Modbus TCP, DNP3, and IEC 60870-5-104 lack authentication and integrity checks. An attacker who can send packets to a PLC can read/write registers without credentials.
Outdated software: Windows XP/7 still common on HMIs, with unpatched vulnerabilities.
Weak network segmentation: Firewall rules often allow any traffic from the corporate network to the control network.
Physical access risks: USB ports on HMIs can be used to introduce malware (e.g., Stuxnet).
Lack of logging and monitoring: ICS networks often have minimal security monitoring.
Penetration Testing Methodology for IoT/SCADA
Reconnaissance: Identify devices using Shodan, Censys, or passive scanning. For ICS, look for default banners (e.g., Modbus on port 502).
Scanning: Use tools like Nmap with scripts for Modbus (nmap -sV --script modbus-discover -p 502 <target>). Be careful with active scanning on production ICS—use passive techniques first.
Vulnerability Assessment: Use Metasploit modules (e.g., modbusdetect, modbusslave_read), search for CVEs for specific firmware versions.
Exploitation: For IoT, common attacks include credential brute-forcing, command injection, and firmware dumping. For SCADA, attacks might include sending malicious Modbus commands to change setpoints, perform a denial-of-service (DOS), or exploit known vulnerabilities in HMI software.
Post-Exploitation: Extract data (e.g., process values, configuration files), pivot to other devices, or demonstrate impact (e.g., causing a simulated pump failure).
Tools and Commands
Nmap: nmap -p 502 --script modbus-discover <target>
Metasploit: use auxiliary/scanner/scada/modbusdetect, use auxiliary/scanner/scada/modbusslave_read
Wireshark: Capture Modbus traffic; filter modbus to see function codes (e.g., 0x03 for read holding registers, 0x06 for write single register).
PLCscan: Python script to scan for PLCs.
Firmware analysis tools: binwalk, firmwalker, firmware-mod-kit.
MQTT tools: mqtt-pwn, mosquitto_sub/pub for testing IoT message brokers.
Safety Considerations
Never perform active exploitation on live production ICS without written authorization and a safe test environment.
Use a test lab or simulation (e.g., virtualization with OpenPLC, or hardware testbed).
Understand the potential physical impact: changing a register could cause a valve to open, a motor to start, or a safety system to fail.
Always have a kill switch or emergency stop procedure.
Example: Modbus Protocol Deep Dive
Modbus is a serial master-slave protocol, but most modern implementations use Modbus TCP. The protocol frame: - Transaction ID (2 bytes) - Protocol ID (2 bytes, 0 for Modbus) - Length (2 bytes) - Unit ID (1 byte, slave address) - Function code (1 byte): 0x01 Read Coils, 0x03 Read Holding Registers, 0x06 Write Single Register, 0x10 Write Multiple Registers - Data (variable)
No authentication, no encryption. An attacker can craft a packet with function code 0x06 to modify a holding register that controls a motor speed. This is a simple yet devastating attack.
Example: MQTT for IoT
MQTT is a publish-subscribe protocol often used in IoT. It uses a broker that mediates messages. Common security issues:
No encryption by default (port 1883 vs 8883 for TLS)
No authentication (anonymous clients can publish/subscribe)
Weak authentication (username/password in clear)
Unauthorized topic access (any client can subscribe to all topics)
Pentesting MQTT involves connecting to the broker, subscribing to # (all topics), and publishing messages to control actuators.
Defense in Depth for IoT/SCADA
Network segmentation: Use firewalls, VLANs, and one-way diodes (data diodes) to isolate ICS networks.
Application whitelisting: Only allow approved executables on HMIs.
Secure remote access: Use VPNs with MFA, not direct RDP.
Firmware signing: Ensure updates are cryptographically signed.
Protocol security: Use Modbus/TCP over TLS, or migrate to secure protocols like OPC UA.
Regular testing: Include IoT/SCADA in penetration testing scope, but with extreme caution.
Passive Reconnaissance of ICS Network
Begin by listening to network traffic without sending any packets. Use Wireshark or tcpdump on a SPAN port or a tap. Capture traffic for several minutes to identify protocols like Modbus (port 502), DNP3 (port 20000), or EtherNet/IP (port 44818). Look for broadcast messages, device IPs, and function codes. Note any plaintext credentials or unencrypted HMI traffic. This step is critical because active scanning may disrupt sensitive devices.
Active Scanning with Nmap Scripts
Once passive recon is complete, perform targeted active scanning using Nmap's SCADA scripts. Use commands like `nmap -sV --script modbus-discover -p 502 192.168.1.0/24`. The `modbus-discover` script sends a read device identification request to each host on port 502 and parses the response. This identifies PLCs, RTUs, and their vendor/model. Be aware that some PLCs may crash if flooded with packets; use `--max-rate 10` to be gentle.
Vulnerability Scanning of HMI/SCADA Servers
Use tools like Nessus or OpenVAS with SCADA-specific plugins to scan for known vulnerabilities in HMI software (e.g., Wonderware, Citect, Rockwell Automation). These scanners check for default credentials, missing patches, and misconfigurations. For example, a common finding is 'Schneider Electric Modicon PLC Default Password' or 'GE Proficy HMI Unauthenticated Access'. Document all findings with CVSS scores.
Exploiting Modbus Protocol Weakness
Using Metasploit's `modbus_slave_read` or a custom Python script with `pymodbus`, connect to a PLC and read holding registers (function code 0x03). Then attempt to write to a register (function code 0x06) to change a setpoint. For example, connect to a PLC at 192.168.1.100:502, write to register 0x0001 with value 0. This could stop a motor. Always get explicit permission and have a rollback plan.
Post-Exploitation and Impact Demonstration
After gaining control of a device, extract configuration files, ladder logic, or process data. For IoT devices, dump firmware via UART or JTAG if physical access is possible. Document the impact: 'Attacker changed pump speed register from 50 to 0, causing flow to stop.' This demonstrates the risk to operations. Finally, restore any changed values to original state and ensure no persistent modifications remain.
In a real-world water treatment facility, the SCADA system controls pumps, valves, and chemical dosing. The corporate network (Level 4) connects to the control network (Level 2) via a firewall that allows only Modbus TCP from an HMI server to the PLCs. During a penetration test, we discovered that the firewall rule was overly permissive—any host on the corporate network could initiate Modbus connections to the PLCs. An attacker who compromises a workstation in IT can directly send malicious Modbus commands. We demonstrated this by writing to a holding register that controlled chlorine dosing, causing a simulated overdose in our test environment. The remediation was to restrict the firewall to only allow the specific HMI server's IP and to implement deep packet inspection for Modbus function codes.
In another engagement for a smart building system, IoT sensors (temperature, humidity) communicated via MQTT to a central broker. The broker was configured without authentication, and any device on the network could publish to any topic. We connected a laptop to the building's Wi-Fi, subscribed to the '#' topic, and observed all sensor data. Then we published a message to the 'actuators/valve' topic, commanding a valve to close. The building's HVAC system responded, and the temperature in a zone began to rise. The client was shocked that a simple Python script could cause physical discomfort. We recommended enabling TLS and authentication on the broker, and restricting topic access with ACLs.
A common mistake in production is assuming that because a network is 'air-gapped' (physically isolated from the internet), it is secure. We have seen cases where an air-gapped ICS network was still infected with malware via a USB drive used by a contractor. The malware spread to HMIs and caused periodic disruptions. The lesson is that air-gap is not a complete defense; physical security, removable media controls, and host-based security are equally important. For pentesters, always test physical security aspects: check for unlocked panels, exposed serial ports, and USB autorun vulnerabilities.
The PT0-002 exam objective 3.5 specifically covers 'Exploit IoT and SCADA/ICS vulnerabilities.' Expect 2-3 questions that test your understanding of the unique characteristics of these environments.
Common Wrong Answers: - 'SCADA systems prioritize confidentiality over availability.' This is backwards; availability is #1, then integrity, then confidentiality. - 'Modbus uses strong encryption and authentication.' Reality: Modbus has no security by design. - 'You can use standard vulnerability scanners like Nessus without modification on ICS networks.' Wrong—active scanning can disrupt PLCs; you must use specialized modules and low rates. - 'All IoT devices support TLS out of the box.' Many low-cost devices do not; they use plain MQTT or HTTP.
Exam-Specific Facts: - Default Modbus port: 502 (TCP). - DNP3 default port: 20000 (TCP). - MQTT default port: 1883 (no TLS), 8883 (with TLS). - The Purdue model has 5 levels (0-4, sometimes 5). - The most critical vulnerability in SCADA is the lack of authentication and encryption in legacy protocols.
Edge Cases: - The exam may ask about 'safety' as a primary concern—different from IT security's CIA triad. In ICS, safety (S) is added: AIC-S (availability, integrity, confidentiality, safety). - Questions about patch management: In ICS, patches are often delayed due to vendor certification and uptime requirements. - Tools: Remember that Shodan can be used for IoT reconnaissance (search for 'default password' or 'Modbus').
Eliminating Wrong Answers: If an answer suggests that ICS devices can be patched like Windows servers, it's wrong because of operational constraints. If an answer says Modbus is secure, it's wrong. If an answer says to run nmap with aggressive timing on a live PLC, it's wrong because it could crash the device. Always think about availability and safety first.
SCADA/ICS prioritizes availability and safety over confidentiality.
Modbus TCP uses port 502 and has no built-in security.
DNP3 uses port 20000 and supports optional authentication.
MQTT default ports: 1883 (no TLS), 8883 (TLS).
The Purdue model segments ICS into levels 0-5.
Passive reconnaissance is preferred over active scanning in live ICS environments.
Common IoT vulnerabilities include hardcoded credentials and unencrypted communication.
Always have a rollback plan and emergency stop when testing ICS.
Tools: Nmap, Metasploit, Wireshark, PLCscan, binwalk for firmware.
Shodan can identify exposed SCADA and IoT devices.
These come up on the exam all the time. Here's how to tell them apart.
Modbus TCP
Default port 502 TCP
No authentication or encryption
Simple request-response model
Function codes: read/write coils, registers
Widely used in water, oil & gas
DNP3
Default port 20000 TCP
Supports optional authentication (Secure DNP3)
Supports unsolicited responses (event-driven)
More complex with time stamps and quality flags
Common in electric utilities
Mistake
SCADA systems are always air-gapped and therefore secure from remote attacks.
Correct
Many SCADA networks are connected to corporate networks for remote monitoring, and air-gaps can be bypassed via USB drives, laptops, or contractor connections. Stuxnet proved that air-gap is not absolute.
Mistake
IoT devices are too simple to be exploited.
Correct
IoT devices often run full operating systems (Linux, RTOS) with network stacks. They have vulnerabilities like default credentials, command injection, and insecure firmware updates. The Mirai botnet exploited default passwords in IoT cameras.
Mistake
Modbus is secure because it is a simple protocol.
Correct
Modbus has no authentication, encryption, or integrity checks. Any attacker who can send packets to port 502 can read/write registers. It is inherently insecure.
Mistake
Penetration testing on ICS can be done with the same tools and aggressiveness as IT pentesting.
Correct
ICS devices are often fragile; active scanning can cause crashes or unpredictable behavior. Pentesters must use passive techniques first and use low-intensity scans with explicit permission.
Mistake
All ICS protocols are proprietary and require specialized knowledge.
Correct
Many ICS protocols are open standards (Modbus, DNP3, IEC 61850) and are well documented. Tools like Nmap, Wireshark, and Metasploit have modules for these protocols.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IoT generally refers to consumer or enterprise devices like smart thermostats, wearables, and sensors that connect to the internet. SCADA/ICS are industrial control systems used to manage critical infrastructure such as power plants, water treatment, and manufacturing. The key difference is scale and impact: SCADA controls physical processes where failure can cause loss of life or environmental damage. On the exam, you need to know that SCADA systems are often legacy, use proprietary protocols, and prioritize availability over confidentiality.
Modbus TCP uses port 502. The security risk is that Modbus has no authentication, encryption, or integrity checks. Any device that can send TCP packets to port 502 on a PLC can read or write registers, potentially causing physical damage. Attackers often scan for port 502 to find vulnerable industrial devices. In a pentest, you would use Nmap scripts like `modbus-discover` to identify such devices.
First, obtain explicit written authorization that includes the scope and safety constraints. Use passive reconnaissance (e.g., Wireshark captures) before any active scanning. If active scanning is allowed, use low-rate, targeted scans with tools like Nmap's `-T2` timing and SCADA-specific scripts. Never run aggressive scans or exploitation that could disrupt operations. Have a kill switch and rollback plan. Simulate attacks in a test lab whenever possible.
The Purdue model is a reference architecture that divides ICS into levels: Level 0 (physical process), Level 1 (basic control), Level 2 (supervisory), Level 3 (operations management), Level 4 (enterprise IT), and Level 5 (external). Security controls are placed between levels to segment networks and limit the spread of attacks. For example, a firewall between Level 3 and 4 prevents an attacker in the corporate network from directly accessing PLCs. The exam may ask about the levels and where to place firewalls.
Nmap (with SCADA scripts), Metasploit (modules like modbusdetect, modbusslave_read), Wireshark (protocol analysis), PLCscan, binwalk (firmware extraction), and Shodan (internet-wide scanning). For MQTT, tools like mqtt-pwn and mosquitto_sub/pub are used. Always verify that the tools are safe for the target environment.
The lack of security in legacy protocols like Modbus and DNP3 is the biggest vulnerability. These protocols were designed decades ago for reliability, not security. They lack authentication, encryption, and integrity checks, making them susceptible to spoofing, replay, and command injection attacks. Additionally, many SCADA systems run outdated operating systems (e.g., Windows XP) that are no longer patched.
Many IoT devices have limited update mechanisms. Some require manual firmware updates via USB, others support OTA (over-the-air) updates but may not sign them, allowing attackers to push malicious firmware. On the exam, know that IoT devices often have insecure update processes and that vendors may not provide long-term support.
You've just covered IoT and SCADA/ICS Pentesting Concepts — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?