Teaching Operational Technologies

ATT&CK for ICS is a knowledge base — not a standard, not a piece of software, and not something an organization certifies against. It catalogs the tactics (the "why") and techniques (the "how") that adversaries have actually used against industrial control systems, with every entry traced back to a documented incident, vendor advisory, or research report. It is the ICS-specific sibling of MITRE's flagship Enterprise ATT&CK matrix.

Enterprise ATT&CK, released in 2015, modeled adversary behavior on IT networks — but it had no vocabulary for a technique like reprogramming a safety controller's logic or spoofing a sensor reading back to an HMI. MITRE released ATT&CK for ICS as its own matrix in 2020 specifically to capture behaviors unique to control systems: manipulating physical processes, disabling safety functions, and interacting with industrial protocols that IT-focused security tooling doesn't parse.

Threat intelligence analysts writing and reading incident reports, SOC and detection engineers scoping alert coverage, red/blue/purple teams designing exercises, and asset owners doing gap analysis. Unlike IEC 62443 or NIST SP 800-82, nobody "implements" ATT&CK for ICS directly — it's a reference lens applied to something else you're already doing.

This is the single most important distinction to establish before teaching any other content on this page. IEC 62443 and NIST SP 800-82 tell you what to build. NERC CIP-008 tells you what you're legally required to do. ATT&CK for ICS does neither — it only documents what has actually happened. It answers "what has been done to systems like this, and how would you detect it," not "what should you do."

How the adversary first gets a foothold in the ICS environment.

• Exploit Public-Facing Application — an internet-exposed HMI or engineering portal
• Remote Services — VPN or remote-access paths originally set up for vendors or engineers
• Supply Chain Compromise — tainted vendor software or hardware
• Transient Cyber Asset — a laptop or USB device temporarily connected to the control network

Running adversary-controlled code once inside.

• Command-Line Interface and Graphical User Interface — using the system's own native tools
• Scripting — automating actions across multiple devices
• User Execution — tricking an operator or engineer into running something

Staying present across restarts and maintenance cycles.

• Modify Program — altering PLC/controller logic itself
• Module Firmware — reflashing a device's firmware
• Project File Infection — embedding malicious logic in an engineering project file so it reinfects the target the next time it's deployed
• Valid Accounts — using legitimate, often shared or default, credentials

Gaining a higher level of control than the initial foothold provided.

• Exploitation for Privilege Escalation — using a software flaw to gain elevated rights
• Hooking — intercepting and altering how a legitimate process behaves to gain its level of access

Avoiding detection while doing all of the above.

• Change Operating Mode — flipping a controller into program/maintenance mode to make changes without triggering run-time alarms
• Indicator Removal on Host and Masquerading — hiding evidence and disguising activity as legitimate
• Spoof Reporting Message — feeding operators falsified "everything is normal" readings

Mapping the environment before acting further.

• Network Connection Enumeration and Remote System Discovery — finding other reachable devices
• Network Sniffing and Wireless Sniffing — passively capturing traffic to learn protocols and addressing in use

Moving from the initial foothold toward systems that actually control the process.

• Default Credentials — vendor-set passwords that were never changed
• Exploitation of Remote Services and Remote Services — riding legitimate access paths deeper into the network
• Valid Accounts — reusing credentials harvested earlier

Gathering the process information needed to act on the target effectively.

• Point & Tag Identification — learning which tag or point in the control logic corresponds to which physical device
• Monitor Process State and Detect Operating Mode — watching how the process actually behaves before touching it
• Screen Capture and I/O Image — capturing HMI displays or the controller's current input/output state

Maintaining a remote channel to direct the intrusion.

• Commonly Used Port and Standard Application Layer Protocol — blending C2 traffic in with normal-looking network activity
• Connection Proxy — routing commands through an intermediate hop to obscure the true source

Blocking the operator or the safety system from responding while the real attack happens.

• Alarm Suppression and Modify Alarm Settings — silencing the warnings that would trigger a response
• Block Command Message / Block Reporting Message — preventing control commands or status reports from arriving
• Denial of Service and Device Restart/Shutdown — disabling protection relays or field devices outright

Directly manipulating the process itself.

• Modify Parameter — changing a setpoint, threshold, or control variable
• Unauthorized Command Message — sending a command the legitimate operator never issued
• Brute Force I/O and Spoof Reporting Message — forcing outputs directly or masking the resulting readings

The consequence the entire chain was built toward.

• Loss of Control / Loss of View / Denial of View — the operator can no longer act on, or even see, the true process state
• Manipulation of Control / Manipulation of View — the operator acts on falsified information
• Loss of Safety — a safety system is disabled or defeated (the technique TRITON/TRISIS essentially defines — see Section 05)
• Damage to Property and Loss of Productivity and Revenue — the physical and financial consequences

Malware spread via removable media and network shares, then specifically reprogrammed Siemens S7-300 PLC logic controlling centrifuge speeds — while feeding falsified "normal" readings back to operators. It is the canonical teaching example of Project File Infection, Modify Program, Spoof Reporting Message, and ultimately Impair Process Control leading to physical Damage to Property.

Spearphishing gave IT access; the adversary then rode existing remote-access paths into the OT network and used the SCADA HMI to open breakers directly, cutting power. A KillDisk wiper and a firmware attack on serial-to-Ethernet converters slowed the utilities' ability to restore service — a direct demonstration of Inhibit Response Function layered on top of Impair Process Control.

The first malware built with modular payloads that speak substation automation protocols (IEC 101, IEC 104, IEC 61850, OPC) directly — letting it open breakers programmatically rather than through a hijacked HMI. It also included a denial-of-service module targeting a known flaw in Siemens SIPROTEC protection relays. A strong example of Standard Application Layer Protocol C2 combined with protocol-native Unauthorized Command Message techniques.

The adversary reached the engineering workstation for a Schneider Electric Triconex Safety Instrumented System (SIS) and reprogrammed its logic — the first publicly documented malware built to specifically target a safety system rather than just the process it protects. A bug in the malware likely caused some controllers to fail safely, which is probably what prevented a larger physical incident. This is the case study that most concretely defines Loss of Safety as a technique.

A modular ICS attack toolkit found and analyzed before it was used against a live target — built to scan for and manipulate specific PLCs and industrial software from multiple vendors (including Schneider Electric and Omron) across several protocols. It's the broadest, most automated ICS attack tool publicly documented to date, and a good teaching example of how attack tooling is trending toward reusable, protocol-aware modules rather than one-off custom malware like Stuxnet.