Threats

T0800

OT & ICS Threats

A comprehensive guide to operational technology (OT) and industrial control system (ICS) threats for SOC analysts — Stuxnet-style attacks, TRITON, Colonial Pipeline, PLC attacks, MODBUS protocol threats, and detection techniques for industrial environments.

View on Graph

What OT/ICS Threats Are and Why They Matter

  • Operational Technology (OT) controls physical processes — manufacturing lines, power grids, pipelines, water treatment, building automation — through industrial control systems (ICS) like PLCs, RTUs, SCADA, and DCS.
  • MITRE ATT&CK for ICS (T800 series) maps techniques specific to industrial environments, distinct from enterprise IT ATT&CK. Key categories include T838 (Modbus Function Code), T831 (Device Restart/Shutdown), and T844 (Program Download).
  • The stakes are higher than IT: OT attacks can cause physical damage, safety incidents (fires, explosions, toxic releases), environmental damage, and extended production outages.
  • The traditional “air gap” between IT and OT networks is eroding — modern ICS uses IT connectivity for remote monitoring, firmware updates, and data analytics, creating attack paths that did not exist before.

Historic OT/ICS Attacks — Lessons for Analysts

Stuxnet (2010) — The Game Changer

AspectDetail
TargetIranian uranium enrichment centrifuges (Natanz)
MethodWorm propagated via USB, exploited 4 Windows zero-days, targeted Siemens S7-300 PLCs
ImpactDestroyed ~1,000 centrifuges by spinning them at destructive speeds
Key techniquePLC rootkit — Stuxnet hid the attack from monitoring software while physically destroying hardware
Analyst lessonPLC compromise may be invisible to monitoring — always check PLC firmware integrity

TRITON/TRISIS (2017) — Safety System Attack

AspectDetail
TargetPetrochemical facility in Saudi Arabia
MethodMalware targeting Schneider Electric Triconex safety instrumented system (SIS)
ImpactAttacker modified safety controller firmware to cause a potential plant shutdown or hazardous release
Key techniqueSafety system compromise — attacker bypassed the failsafe mechanism designed to prevent physical harm
Analyst lessonSafety systems (SIS) are not invulnerable. Monitor safety controller logs for firmware changes

Colonial Pipeline (2021) — IT-to-OT Disruption (linked to ransomware and DDoS patterns)

AspectDetail
TargetColonial Pipeline — US East Coast fuel supply
MethodIT network breached via compromised VPN credentials (single inactive account), ransomware deployed on IT systems
ImpactPipeline shut down for 6 days — not because OT was compromised, but because billing/operational IT was crippled
Key techniqueIT ransomware causing OT operational impact — no PLC manipulation occurred
Analyst lessonIT-OT convergence means an IT breach can shut down industrial operations without touching a single PLC

PLC Attacks — Manipulating Industrial Controllers

Programmable Logic Controllers (PLCs) are the brains of industrial automation. They read sensors and control actuators based on a logic program (ladder logic, structured text, function block diagram).

Attack Vectors

VectorHow It WorksImpact (potential C2 channel)
Program downloadAttacker uploads malicious PLC program (logic change) without authenticationUnsafe process behavior
Firmware replacementReplace PLC firmware with malicious version (persistent — survives reboot)Long-term control over PLC behavior
Runtime manipulationModify register values in real time without changing the programProcess disruption without detection
Force-point overrideForce I/O points to specific values (safety override)Disable safety interlocks
Stop/StartStop or start the PLC or specific program blocksProcess halt or unsafe restart

Authentication Gaps in PLCs (a common insider threat vector)

Protocol/InterfaceAuthenticationNotes
Allen-Bradley CSPv4NonePassive discovery and data read possible
Siemens S7 (ISO-TSAP)None in older firmwareCan read/write PLC program without auth
Modbus TCPNoneRead/write coils and registers freely
Profinet DCPNoneDevice identification and configuration
DNP3Optional (Secure Authentication)Most deployments have auth disabled

Detection — PLC Program Change

index=ot sourcetype=plc_log
| search action="program_upload" OR action="firmware_update" OR action="config_change"
| stats count, values(action) as Actions by plc_name, source_ip
| where count > 0
| eval alert = "PLC configuration change on " . plc_name . " from " . source_ip . " — verify authorized"
| table _time, plc_name, source_ip, Actions, count, alert

MODBUS Protocol — The Insecure Standard

MODBUS is the most widely deployed industrial protocol. It was designed in 1979 and has no security built in. MODBUS TCP runs on port 502.

MODBUS Function Codes

CodeFunctionRead/WriteRisk
01Read CoilsReadLow — enumeration
02Read Discrete InputsReadLow — enumeration
03Read Holding RegistersReadMedium — process variable enumeration
04Read Input RegistersReadMedium — process variable enumeration
05Write Single CoilWriteHigh — can start/stop equipment
06Write Single RegisterWriteHigh — can change setpoints
15Write Multiple CoilsWriteHigh — mass override
16Write Multiple RegistersWriteHigh — mass setpoint change
22Mask Write RegisterWriteHigh — bit-level manipulation
24FIFO QueueWriteMedium — custom firmware or data load

MODBUS Anomaly Detection

SPL — detect unauthorized MODBUS writes:

index=ot sourcetype=modbus
| search function_code IN (05, 06, 15, 16, 22)
| lookup modbus_device_acl.csv plc_ip, src_ip OUTPUT authorized
| where authorized != "yes"
| eval alert = "UNAUTHORIZED MODBUS WRITE — " . function_name . " (function " . function_code . ") from " . src_ip . " to PLC " . plc_ip . " at register " . register_address
| table _time, src_ip, plc_ip, function_code, function_name, register_address, value, alert

Suricata rule — detect MODBUS scanning (and other API-level protocol attacks):

alert tcp any any -> any 502 (msg:"MODBUS — Holding Register Read Scan"; 
  content:"|00 03 00 00 00 06 01|"; offset:0; depth:7; 
  content:"|03|"; within:1; distance:5; 
  threshold: type both, track by_src, count 10, seconds 60;
  sid:1000001; rev:1;)

The Purdue Model — Understanding OT Network Segmentation

The Purdue Enterprise Reference Architecture (PERA) defines levels of industrial network hierarchy:

Purdue LevelNameDevicesSecurity Focus
Level 4-5Enterprise ITERP, databases, email, DNSStandard IT security
Level 3Operations ManagementMES, historian, domain controllers, AV serversOT-IT boundary — DMZ, jump hosts
Level 2Supervisory ControlHMI, SCADA servers, engineering workstationsSession monitoring, application whitelisting
Level 1ControllersPLCs, RTUs, DCSRead-only access where possible, firmware integrity checks
Level 0Physical ProcessSensors, actuators, motors, valves, pumpsPhysical security, tamper detection

Where Attacks Happen

Most OT attacks cross levels:

  • IT-to-L3: Ransomware enters through IT, reaches Level 3 via shared domain or jump box
  • L3-to-L1: Compromised engineering workstation downloads malicious PLC program
  • Direct L0: Physical access to sensors or actuators (tampering)

Detection for OT Environments

OT-Specific Detection Rules

DetectionWhat It CatchesData Source
Unexpected PLC program changeAttacker downloads malicious logicPLC firmware hash comparison, log review
New MODBUS function codesUnusual write operations to coils or registersMODBUS transaction logs
PLC restartsAttacker stopping/restarting controllersSyslog from PLC, network connectivity loss
HMI connections from unknown IPsAttacker accessing HMI without authorizationHMI access logs, network flow
OT-IT traffic spikeData exfiltration from OT to ITNetflow across OT-IT boundary
Engineering tool running on production networkUnauthorized configuration changeProcess creation logs on engineering workstations
Device firmware hash mismatchMalicious firmware deployedFirmware verification script

SPL — OT-IT Boundary Monitoring

index=ot sourcetype=netflow
| search src_ip=10.0.* OR dst_ip=10.0.*
| search src_ip=172.16.* OR dst_ip=172.16.*
| stats sum(bytes) as total_bytes, count by src_ip, dst_ip, dest_port
| where total_bytes > 1000000
| eval alert = "Large data transfer across OT-IT boundary: " . src_ip . " → " . dst_ip . ":" . dest_port . " — " . round(total_bytes/1024/1024, 2) . " MB"
| table _time, src_ip, dst_ip, dest_port, total_bytes, alert
| sort - total_bytes

Defensive Controls

ControlWhat It PreventsImplementation
OT-IT DMZDirect IT-to-OT accessJump hosts, unidirectional gateways, data diodes
Application allowlistingUnauthorized engineering tools on OT networkWindows AppLocker, Linux fapolicyd
Firmware integrity verificationMalicious PLC/RTU firmwareHash comparison at boot, scheduled verification
Network segmentation (Purdue)Lateral movement between OT levelsFirewalls at each Purdue level boundary
Read-only network accessUnauthorized MODBUS/DNP3 writesNetwork ACLs block write function codes from non-engineering hosts
HMI session recordingRetrospective investigationVideo recording or keystroke logging of HMI sessions
Physical access controlDirect tampering with controllersLocked cabinets, tamper seals, CCTV
Incident response for OTCoordinated response without dangerous actionsPre-defined OT incident response plan with engineering input

Sources