| name | SCADA Vulnerabilities |
| description | Industrial control system security — Modbus, DNP3, IEC 104, Ethernet/IP, PLC exploitation, control logic manipulation, sensor/actuator attacks, ICS protocol analysis |
| tags | ["scada","ics","industrial","control-system","modbus","dnp3","plcs","security","critical-infrastructure","OT","operatortechnology","hmi","plc","rtu"] |
| author | Spectra Security Research |
| version | 1 |
SCADA Vulnerability Analysis
Overview
This skill analyzes industrial control systems (ICS) and SCADA environments for vulnerabilities in protocols, PLC logic, sensor/actuator controls, and critical infrastructure components.
⚠️ Authorized Use Only
Permitted Contexts:
- Authorized ICS security assessments
- CTF competitions (ICS-themed)
- Educational research in isolated environments
- Red team exercises with explicit permission
Prohibited:
- Unauthorized access to critical infrastructure
- Production ICS system testing without permission
- Any testing that could affect safety systems
Analysis Phases
Phase 1: Protocol Analysis
1.1 Modbus TCP/RTU
nmap -p 502 --script modbus-discover <target>
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('target')
client.connect()
result = client.read_holding_registers(0, 10)
print(result.registers)
Vulnerability Indicators:
- No authentication (default)
- Plain TCP (no encryption)
- Write operations enabled
- Critical registers writable
1.2 DNP3 (DNP3.0)
nmap -p 20000 --script dnp3 <target>
Vulnerability Indicators:
- No link-layer authentication
- Secure Authentication (SA) not enabled
- Write operations allowed
- Master station impersonation possible
1.3 IEC 60870-5-104 (IEC 104)
nmap -p 2404 <target>
1.4 Ethernet/IP (CIP)
nmap -p 44818 --script enip-enumerate <target>
Phase 2: PLC Memory Exploitation
2.1 Memory Layout Analysis
2.2 Logic Injection
Phase 3: Control Logic Manipulation
3.1 HMI/SCADA Server Vulnerabilities
curl -k https://scada-server/hmi
curl -X POST https://scada-server/api/tags -d '{"action":"read","tag":"System.Status"}'
3.2 Historian Database Exploitation
Phase 4: Sensor/Actuator Attacks
4.1 Sensor Spoofing
4.2 Actuator Manipulation
Phase 5: Protocol-Specific Vulnerabilities
5.1 Modbus Variants
Modbus TCP:
Modbus RTU over TCP:
5.2 DNP3 Secure Authentication
5.3 IEC 104 Vulnerabilities
Novelty Indicators (PURSUE)
✓ Recent ICS CVEs (2023-2024):
- CVE-2024-23631: DNP3 out-of-bounds
- CVE-2023-4680: CODESYS buffer overflow
- CVE-2024-23620: OPC UA UaBinary
✓ Custom protocol implementations:
- Non-standard Modbus variants
- Custom IEC 104 extensions
- Proprietary SCADA protocols
✓ Integration bugs:
- Gateway/RTU boundary issues
- Protocol translation vulnerabilities
- Multi-protocol gateway flaws
✓ Safety system interaction:
- Safety instrumented systems (SIS) integration
- Emergency shutdown (ESD) bypass
- Fire/gas system manipulation
Known Patterns (AVOID)
✗ Default Modbus write (no auth by design)
✗ Unauthenticated DNP3 (known issue)
✗ IEC 104 replay (well-documented)
✗ Standard PLC logic upload (documented procedure)
Analysis Checklist
Protocol Analysis
Memory/Logic Analysis
Sensor/Actuator Analysis
Safety Considerations
⚠️ CRITICAL: Never test on live production systems
- Use isolated test environments
- Never manipulate safety-critical systems
- Always document potential physical effects
- Follow responsible disclosure for critical infrastructure
Quick Reference
| Protocol | Port | Novelty Focus |
|---|
| Modbus TCP | 502 | Custom auth, encryption |
| Modbus RTU | Varies | CRC bypass, timing |
| DNP3 | 20000 | SA bypass, custom extensions |
| IEC 104 | 2404 | CA attacks, IOA manipulation |
| Ethernet/IP | 44818 | CIP tag injection |
| OPC UA | 4840 | Certificate bypass, encryption flaws |
| PROFINET | Varies | Real-time latency abuse |
Notes
- Focus on novel vectors: Custom protocols, recent CVEs, integration bugs
- Physical consequences: ICS vulns can have real-world impact
- Legacy systems: Older protocols have no security by design
- Verification: Document protocol, exploit, safety considerations
- Responsible disclosure: Critical infrastructure requires coordination