Exploitation for Evasion (T0820) is the use of a software flaw to switch off or slip past a security feature, and in OT the feature under attack is often a controller's own integrity check. MITRE ATT&CK for ICS lists it under the Evasion tactic on Embedded, Windows, Linux and Network Devices platforms. Its one procedure example is Triton, which disabled a firmware RAM/ROM consistency check on a safety controller after injecting a payload. This is a short, focused page: the Windows and Linux side mirrors the Enterprise technique covered in the MITRE ATT&CK T1211 Exploitation for Stealth guide, so this guide concentrates on what is different for controllers, safety systems and OT hosts. It is for OT security engineers, safety engineers and SOC analysts.
Key takeaways
- The target is the defence, not the data. T0820 exploits a bug to disable or bypass a security or integrity feature so later actions go unnoticed.
- Controllers have their own defences. Firmware and program checksums, memory integrity checks and secure update features are the OT equivalent of endpoint security, and Triton went after exactly that.
- Detection is about the crash and the anomaly around it. ATT&CK's analytics look for malformed protocol traffic before a device change, unexpected restarts, and memory access into ICS processes followed by a crash.
- Physical and procedural controls matter more than in IT. A safety controller key switch kept out of program mode and a controlled engineering workstation stop many exploit paths before the bug is reached.
- Patching is slow, so plan interim controls. ATT&CK lists four mitigations (M0948, M0950, M0919, M0951); in OT, isolation and threat intelligence carry the load until firmware can be updated.
What T0820 covers in OT
ATT&CK for ICS describes adversaries exploiting a programming error in a program, service, operating system or kernel to evade detection, and notes that vulnerabilities may exist in software that can be used to disable or circumvent security features. It adds that adversaries may already know, through Remote System Information Discovery (T0888), which security features a control device has, and that firmware RAM/ROM consistency checks on control devices have been targeted to enable the installation of malicious firmware. ATT&CK v20 now tracks firmware changes under T1693 Modify Firmware.
| Platform | Security feature that may be targeted | What evasion enables |
|---|---|---|
| Embedded controllers and safety systems | Firmware and program integrity checks, memory protection, secure update | Running unauthorised code or logic without the controller faulting |
| Windows engineering workstations, HMIs, historians | Endpoint protection, exploit mitigations, application allowlisting | Running tools that would otherwise be blocked or logged |
| Linux ICS servers and gateways | Audit and integrity tooling, process isolation | Tampering with ICS service processes unseen |
| Network devices | Management plane protections, logging | Changing or hiding device behaviour |
For the Windows and Linux mechanics (exploit protection, kernel driver controls, EDR tamper protection) read the Enterprise page; the controls there apply unchanged to OT hosts once the ICS vendor has approved them.
The Triton case
ATT&CK records that Triton (S1009) disabled a firmware RAM/ROM consistency check after injecting a payload into the firmware memory region, and notes that Triconex systems include continuous detection means such as checksums for firmware and program integrity, memory integrity and configuration. Mandiant's original analysis adds the context defenders need:
- Access path: the attacker reached a Windows SIS engineering workstation remotely and ran a tool disguised as the legitimate Triconex Trilog application, which talked to the controllers over the TriStation protocol.
- How it was noticed: some controllers entered a failed safe state and shut the process down when application code in the redundant processing units failed a validation check, producing an MP diagnostic failure. The integrity feature did its job and the investigation followed the shutdown.
- Precondition: Triconex controllers have a physical key switch that controls programming, and Mandiant advised that it should not be left in PROGRAM mode except during scheduled programming.
The lesson is that integrity features on safety controllers are both a target and a sensor: an unexplained safety trip or diagnostic fault may be the only sign of an attempt. See the Safety Instrumented Systems Security Guide and the ICS Malware History Guide.
Detection: ATT&CK's analytics
ATT&CK v20 attaches a detection strategy with four analytics to T0820. Each carries the OT operational fidelity gate: alert only when execution violates an approved signer, hash, path, parent, process or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset or follow-on OT action; suppress vendor-signed software, approved engineering utilities, diagnostics, patching, backup and documented maintenance.
| Platform | What it looks for | Log source named by ATT&CK |
|---|---|---|
| Embedded | Malformed or out-of-spec ICS protocol exchanges to a device from a source outside the approved baseline | Network content inspection: anomalous exchange before a device change such as a reboot or altered configuration |
| Windows | An ICS vendor process crashing just after unusual cross-process memory access from outside the security and diagnostic tool allowlist | Sysmon EventCode 10, followed by unexpected termination |
| Linux | ptrace or process memory access into ICS service processes from something other than an approved debugger or vendor tool | auditd SYSCALL records for ptrace and process_vm_readv |
| Network devices | Unexpected restarts or crashes coinciding with anomalous traffic on management interfaces | Network device syslog |
OT signals to add
- Safety and controller diagnostics: forward controller diagnostic faults and unexplained safety trips to the OT SOC, and investigate them as possible security events until shown otherwise.
- Key switch and mode state: record the key position or operating mode of safety and process controllers, and alert on changes outside scheduled work. This overlaps with T0858 Change Operating Mode.
- Engineering protocol use: alert when programming or engineering protocol sessions to safety controllers come from any host other than the designated engineering workstation.
See the OT Network Security Monitoring Guide.
Mitigations
| ATT&CK mitigation | What ATT&CK says | How to apply it in OT |
|---|---|---|
| M0948 Application Isolation and Sandboxing | Sandboxing, virtualisation and microsegmentation make unpatched flaws harder to use | Isolate safety networks from process control and IT; keep SIS engineering workstations single-homed |
| M0950 Exploit Protection | Tools that look for exploitation behaviour and control flow integrity checks can stop some exploits; compatibility varies by application | Use on Windows and Linux OT hosts after vendor approval, in audit mode first |
| M0919 Threat Intelligence Program | Understand which threats may use exploits and zero-days against the organisation | Track ICS advisories for the controllers you own and rank compensating controls by them |
| M0951 Update Software | Patch regularly | Update controller firmware in planned outages, tested on a bench unit, with rollback firmware kept |
Mandiant's Triton recommendations add the controls that sit before the exploit: segregate safety system networks, use physical control of programming through the key switch with change management and regular audits of key state, prefer unidirectional gateways for applications that only need safety system data, apply strict access control and application allowlisting on endpoints that can reach the safety system, and monitor ICS traffic for unexpected flows. For patch planning see the OT Patch Management Guide and ICS Advisory Triage and OT Vulnerability Management Guide.
Safety-aware response
- Treat an unexplained safety trip as a possible attack: preserve controller diagnostics and logic before resetting, where the safety engineer agrees it is safe.
- Put the process in a safe state first: operations and safety engineering decide; security supports.
- Isolate the engineering path: disconnect the engineering workstation and any host that spoke the programming protocol to the affected controller.
- Verify controller integrity with the vendor: compare firmware and logic against known-good copies using vendor-supported methods.
- Restore and return to service carefully: reload known-good firmware and logic, confirm key switch position, and re-validate safety functions before restart.
See the OT Incident Response Guide.
Metrics that show it is working
- Safety controllers in program mode outside work windows: target zero, checked by audit.
- Unexplained diagnostic faults investigated: share reviewed by security and safety together.
- Single-homed engineering workstations: share of safety engineering workstations with no other network attachment.
- Firmware currency: share of controllers on vendor-supported firmware, with known-good copies held offline.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Firmware and program integrity | SI-7 Software, Firmware, and Information Integrity | DE.CM-09 |
| Exploit mitigations | SI-16 Memory Protection | PR.PS-02 |
| Isolation of safety networks | SC-7 Boundary Protection | PR.IR-01 |
| Firmware updates | SI-2 Flaw Remediation | PR.PS-02 |
| Fail-safe behaviour | SC-24 Fail in Known State | PR.IR-03 |
| Monitoring | SI-4 System Monitoring | DE.CM-01 |
Common failure patterns
- Safety key left in program mode: it removes a physical barrier that stands in front of many exploit paths.
- Dual-homed safety engineering workstations: they give a remote attacker a direct route to the safety controllers.
- Treating diagnostic faults as nuisance trips: the integrity check that caught Triton is only useful if someone investigates.
- Exploit protection enforced without vendor testing: it can break HMI or engineering software and gets removed for good.
Practitioner checklist
- Keep safety controller keys out of program mode except during scheduled work, with change records.
- Segregate safety networks and keep their engineering workstations single-homed.
- Forward controller diagnostics and safety trips to the OT SOC for joint review.
- Deploy ATT&CK's T0820 analytics with allowlists and maintenance suppression.
- Hold known-good firmware and logic copies offline for every controller.
- Track ICS advisories for owned controllers and record interim controls for each.
- Pilot exploit protection on OT hosts in audit mode with vendor agreement.
Standards and references
- MITRE ATT&CK for ICS: Exploitation for Evasion (T0820)
- MITRE ATT&CK: Triton (S1009)
- Mandiant: Attackers Deploy New ICS Attack Framework TRITON
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- MITRE ATT&CK: Exploitation for Stealth (T1211)
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · MITRE ATT&CK T1211 Exploitation for Stealth · Engineering Workstation Security Guide · PLC Security Guide