The OT Threat Landscape: Actors, Motives, and Attack Patterns
- ICS cyber security, ics security assurance, ics security vulnerabilities, ot threat landscape, risk assessment, threat landscape
OT Cybersecurity Fundamentals — Estimated reading time: 12–14 minutes
Introduction
So far, the series of our previous articles has focused largely on how OT systems are structured, how cybersecurity frameworks can be applied, and how risks can be translated into requirements.
But risk cannot be understood only from architecture and controls.
We also need to understand the other side of the equation:
Who might attack an OT environment?
Why would they do it?
How might they get in?
And what are they actually trying to achieve?
The OT threat landscape is different from conventional IT not necessarily because every attacker uses exotic industrial malware, but because the consequences can be different.
An attacker may begin with:
- A stolen password
- A compromised laptop
- An exposed remote-access service
- Malware on an enterprise workstation
- A compromised supplier
- An infected removable device
None of these is uniquely “OT.”
What makes the situation different is where the attacker may eventually reach.
In an OT environment, digital compromise may affect systems that:
- Open and close valves
- Start and stop motors
- Control pressure, temperature, flow, or level
- Operate electrical switching equipment
- Manage rotating machinery
- Coordinate production
- Provide operator visibility
- Perform protective or safety functions
The cyber event therefore matters partly because of the physical process behind the digital system.
Threat Actors Are Not All Trying to Achieve the Same Thing
It is useful to understand several broad categories of threat actor.
These categories overlap, and attribution can be uncertain. The purpose is not to place every incident into a perfect box, but to understand how different motives affect behavior.
Nation-State and State-Linked Actors
State-linked actors may pursue objectives such as:
- Strategic disruption
- Intelligence collection
- Military preparation
- Pre-positioning for future conflict
- Economic or political coercion
- Development of access that may be used later
These actors can be particularly concerning in critical infrastructure because they may have the resources and patience to understand the target environment before taking disruptive action.
The objective may not be immediate destruction.
Long-term access and detailed knowledge of the target may be valuable by themselves.
Cybercriminal and Ransomware Operators
Financially motivated attackers generally seek profit.
Ransomware remains an obvious example.
The important lesson for OT is that a criminal actor does not need to understand PLC programming to disrupt industrial operations.
An attack against enterprise IT can still affect OT because industrial organizations depend on business systems for functions such as:
- Identity management
- Engineering support
- Communications
- Maintenance purpose
- Remote access and support
- IT and OT interconnection with certain perimeter in place
The Colonial Pipeline incident demonstrates this distinction particularly well.
In May 2021, ransomware affected Colonial Pipeline’s business systems. The attack was not publicly demonstrated to have directly manipulated pipeline controlled by OT. Nevertheless, the company disconnected certain systems associated with monitoring and controlling physical pipeline functions and temporarily halted pipeline operations while containing the incident.
That makes Colonial Pipeline useful precisely because it is not the same type of incident as Stuxnet or TRITON.
It demonstrates that:
IT compromise can create operational consequences even without direct process manipulation.
Hacktivists
Hacktivists may be motivated by:
- Political causes
- Ideological objectives
- Publicity
- Protest
- Retaliation
- Attempts to embarrass an organization or government
Their technical sophistication varies considerably.
Some activity may amount to web defacement or denial-of-service attacks.
Other actors may attempt access to internet-facing industrial devices or remote-access infrastructure.
Organizations should therefore assess capability independently from motivation.
An actor may have strong motivation but limited technical capability.
Another may have both.
Insiders
Insider risk deserves particular attention in OT because authorized users may already understand:
- Process behavior
- Operating procedures
- Engineering tools
- Controller configurations
- Maintenance routines
- Safety systems
- Physical access arrangements
Not every insider incident is malicious.
Insider risk can include:
Malicious insiders — intentionally abusing legitimate access.
Negligent insiders — unintentionally creating exposure through unsafe actions.
Compromised insiders — legitimate accounts or devices taken over by an external attacker.
A contractor’s engineering laptop with valid access can therefore become just as relevant as an intentionally malicious employee.
The Attack Path Matters More Than the Label
Knowing that an organization faces “ransomware” or “nation-state threats” is not enough.
OT defenders need to understand the path through which an attacker could move from initial access toward a meaningful operational consequence.
Several paths repeatedly deserve attention.
1. Enterprise IT to OT Pivot
Many organizations maintain connections between enterprise and industrial environments because business operations require them.
Examples include:
- Historian replication
- Production reporting
- Asset-management systems
- Remote engineering
- Patch infrastructure
- Identity services
- File transfer
- Backup systems
- Vendor connectivity
Every legitimate connection represents a dependency that must be understood.
A compromise beginning in enterprise IT does not automatically reach OT.
But poor segmentation, shared credentials, inappropriate trust relationships, or unmanaged communication paths may provide opportunities for lateral movement.
2. Remote Access and VPN Abuse
Remote access is operationally valuable.
It is also one of the most important trust boundaries in many industrial environments.
Vendors and engineers may legitimately require remote capability to:
- Diagnose equipment
- Review logs
- Perform maintenance
- Access engineering workstations
- Modify configuration
- Update software
The security question is therefore not just:
“Should remote access exist?”
But, the better questions are:
- Who needs access?
- To what system?
- For what purpose?
- For how long?
- From which device?
- Through which controlled path?
- With which privileges?
- Who approves the session?
- How is activity monitored?
- Can access be disabled immediately?
MITRE ATT&CK for ICS includes external remote services and remote services among techniques relevant to ICS environments, reflecting the importance of these access paths.
3. Supply-Chain and Trusted-Party Compromise
OT environments depend heavily on:
- OEMs
- Integrators
- Maintenance contractors
- Software suppliers
- Engineering consultants
- Managed-service providers
A supplier may have:
- Trusted credentials
- Remote access
- Software distribution capability
- Knowledge of architecture
- Physical access
- Engineering tools
The organization therefore inherits part of the security posture of its suppliers.
Third-party access should be treated as a controlled business capability rather than an informal technical convenience.
4. Removable Media
Some industrial networks are intentionally isolated from general-purpose networks.
That does not mean information never enters them.
USB drives and other removable media may be used for:
- PLC project files
- Firmware
- Antivirus updates
- Configuration backup
- Data collection
- Vendor diagnostics
Stuxnet demonstrated why removable media and engineering workflows matter. CISA’s archived Stuxnet advisory documented propagation mechanisms that included infected USB devices, network shares, STEP 7 project files, and other pathways.
The lesson is broader than:
“USB is dangerous.”
The real lesson is:
Every mechanism used to move information across a trust boundary must be understood and controlled.
From Kill Chain to ATT&CK for ICS
Two analytical tools are particularly useful for understanding adversary behavior.
They serve different purposes.
The ICS Cyber Kill Chain
Michael Assante and Robert Lee introduced the Industrial Control System Cyber Kill Chain in 2015 as a model for understanding campaigns against industrial control environments.
Their model describes an ICS campaign in stages rather than treating the final disruptive action as an isolated event.
The key insight is important:
Meaningful OT attacks often require more than initial compromise.
An adversary may need to:
- Establish access
- Understand the environment
- Learn the process
- Identify control systems
- Develop or select capabilities
- Reach the operational target
- Execute an action with the intended physical effect
This creates opportunities for defenders.
The earlier an adversary is detected in that chain, the less likely the attacker is to reach the process.
MITRE ATT&CK for ICS
MITRE ATT&CK for ICS provides a more granular knowledge base of adversary tactics and techniques.
The current ICS matrix includes twelve tactics, ranging from Initial Access and Discovery through Lateral Movement, Command and Control, Inhibit Response Function, Impair Process Control, and Impact.
The final three are particularly important for understanding OT consequences.
Inhibit Response Function
The adversary attempts to prevent safety, protection, quality, or operator-response functions from reacting properly to an abnormal or unsafe condition.
Impair Process Control
The adversary attempts to manipulate, disable, or damage control of the physical process.
Impact
The adversary attempts to disrupt or damage systems, data, operations, or the surrounding physical environment.
ATT&CK therefore helps defenders ask:
What behaviors would we expect to observe if someone were progressing toward process manipulation?
Four Incidents, Four Different Lessons
Several well-known incidents help illustrate the range of OT attack patterns.
The objective here is not to retell each incident in detail.
It is to identify the pattern-level lessons.
Stuxnet — Manipulating the Process Requires Process Knowledge
Stuxnet remains an important example because the malware went beyond compromising Windows systems.
It ultimately targeted a specific industrial control environment.
The enduring lesson is:
Access alone is not the same as operational impact.
Producing a specific physical outcome may require detailed knowledge of:
- Engineering software
- Controllers
- Process configuration
- Operating conditions
- The expected behavior operators will observe
For defenders, this reinforces the value of protecting engineering systems and detecting unauthorized changes.
Industroyer and Industroyer2 — Industrial Protocols Can Become Attack Tools
Industroyer demonstrated malware designed to interact with electric-power control environments.
In 2022, ESET and CERT-UA identified Industroyer2 in an attempted attack against high-voltage electrical substations in Ukraine. The malware was designed to communicate using IEC 60870-5-104, an industrial protocol used in electrical environments.
The lesson is not:
“Industrial protocols are insecure.”
The stronger lesson is:
An attacker who understands the process and protocol can potentially use legitimate operational functionality maliciously.
That distinction matters.
A firewall may permit a command because the protocol is expected.
The process may still need to determine whether the command itself makes operational sense.
TRITON/TRISIS — Safety Systems Can Be Targets
TRITON changed the cybersecurity discussion because the target included Triconex safety controllers.
CISA describes the 2017 incident as an operation in which actors gained access to and manipulated safety devices at a Middle East energy-sector organization. TRITON was capable of directly interacting with the safety systems whose purpose was to prevent hazardous process conditions.
This introduces an uncomfortable possibility:
The attacker may not only manipulate the process.
The attacker may attempt to interfere with the protection intended to keep the process safe.
Colonial Pipeline — The Process Does Not Need to Be Hacked to Be Disrupted
Colonial Pipeline provides a different lesson.
The publicly documented ransomware incident affected business systems rather than directly manipulating the pipeline’s OT network. Yet the resulting uncertainty and dependencies contributed to a decision to halt pipeline operations.
The lesson is critical:
Cyber-physical consequence does not always require cyber-physical malware.
Business-system compromise, loss of visibility, inability to bill customers, or uncertainty about the integrity of supporting systems may be enough to interrupt industrial operations.
What These Incidents Have in Common
Stuxnet, Industroyer, TRITON, and Colonial Pipeline are not the same kind of event.
Treating them as identical “ICS attacks” would hide the most useful lessons.
But together they demonstrate several principles.
1. Initial compromise and physical consequence are different stages.
Getting into a network does not automatically provide control of a process.
2. Architecture determines possible attack paths.
Trust relationships, remote access, engineering workstations, and communication pathways matter.
3. Process knowledge increases adversary capability.
An attacker who understands how the physical system works can make more precise decisions.
4. Operational disruption can occur without direct PLC manipulation.
IT and OT dependencies matter.
5. Protection systems may themselves become targets.
Cybersecurity therefore has to consider not only the BPCS, but also alarms, protective functions, and SIS where applicable.
From Cyber Threat to Physical Consequence
This is where cybersecurity practitioners need another discipline.
Knowing:
who attacks + how they attack
still does not tell us:
what happens to the process when they succeed.
To answer that question, we need to understand:
- Hazards
- Process deviations
- Loss of containment
- Protection layers
- SIS
- SIFs
- SIL
- BPCS independence
- Functional-safety lifecycle
Those concepts belong to process safety and functional safety.
Key Takeaway
OT threat analysis should not stop with malware names, threat actors, or network indicators.
The useful question is:
What path could an adversary follow from initial access to an unacceptable operational consequence?
MITRE ATT&CK, the ICS Cyber Kill Chain, incident history, architecture, and threat intelligence help us understand the cyber side of that path.
But understanding the consequence requires something else.
It requires understanding the process.
