A rootkit in an industrial system does more than hide malware: it can make the engineering software and the controller report that everything is normal while the logic underneath has changed. MITRE ATT&CK for ICS tracks this as T0851 Rootkit under two tactics, Evasion (TA0103) and Inhibit Response Function (TA0107). The Enterprise counterpart is T1014; what the ICS entry adds is firmware rootkits on controllers and I/O modules, and Stuxnet's rootkit that hid modified PLC code blocks from engineers. This guide is for OT security engineers and control system owners: what to verify independently, how to detect a lying host or device, and how to recover safely. For rootkit mechanics on general operating systems see the Rootkits and Bootkits Guide.
Key takeaways
- The core problem is trusting what the system reports about itself. Detection depends on an independent view: offline logic comparison, firmware hashes from a vendor tool, or network data compared with host data.
- Stuxnet is the defining case. ATT&CK states its rootkit lived in a fake s7otbxdx.dll and intercepted reads of infected blocks (OB1, OB35, DP_RECV) and writes that could overwrite its code.
- Firmware rootkits reach the I/O. ATT&CK notes they can be built for attached I/O modules, letting commands be disregarded and false values be fed to the main device.
- Two mitigations are listed. Audit (M0947) of PLC system and application code integrity, and Code Signing (M0945) for DLLs.
- Recovery means rebuild from known good. A host or controller that may have lied cannot be cleaned by trusting its own tools.
What T0851 covers in OT
ATT&CK describes rootkits as programs that hide programs, files, network connections, services and drivers by intercepting and modifying operating system API calls, at user or kernel level or lower. The ICS entry adds that firmware rootkits affecting the operating system yield nearly full control, and that they can also target attached I/O, allowing modification of process variables and functions. By tampering with device processes an adversary may inhibit expected response functions and enable Impact, which is why the technique also sits under Inhibit Response Function. Platforms listed are Embedded, Windows, Linux and Network Devices.
| Layer | Where it hides in OT | Independent check |
|---|---|---|
| Engineering software layer (user mode) | Replaced vendor communication library on the engineering workstation, as with Stuxnet | Compare controller logic uploaded from a clean host with the offline master project; verify vendor DLL signatures and hashes |
| Operating system kernel | Drivers on HMIs, SCADA servers and historians | Compare process lists from different sources; driver load monitoring against a signed baseline |
| Controller firmware | PLC, RTU or safety controller main processor | Firmware hash from a vendor integrity tool or physical inspection, compared with the released version |
| I/O module firmware | Input and output modules attached to the controller | Field measurements compared with values reported through the controller |
See the Firmware and Boot Security Guide for firmware integrity in general and the PLC Security Guide for controller hardening.
The Stuxnet case
ATT&CK lists Stuxnet (S0603) as the procedure example. One of its rootkits was contained entirely in the fake s7otbxdx.dll. To stay hidden on the PLC it had to handle read requests for its own malicious code blocks, read requests for infected blocks (OB1, OB35 and DP_RECV), and write requests that could overwrite its code. The same library replacement is listed under Masquerading (T0849). The lesson: if an engineer's view of the controller passes through a component the attacker controls, reading the logic from that workstation proves nothing. ATT&CK's Audit mitigation (M0947) points at exactly this, auditing the integrity of PLC system and application code, including manipulation of standard function blocks such as Organization Blocks that manage execution of the logic.
Detection: ATT&CK's analytics for rootkits
ATT&CK v20 attaches detection strategy DET0780 to T0851. Each analytic carries the OT operational fidelity gate: alert only on violations of an approved signer, hash, path, parent or tool allowlist tied to an OT asset, and suppress vendor-signed software, approved engineering utilities, diagnostics, patching, backup and documented maintenance.
| Analytic | Platform | Signal | Log source named by ATT&CK |
|---|---|---|---|
| AN1912 | Embedded | Device-reported firmware hash or version differs from a value verified through a vendor integrity tool or physical inspection | Asset inventory firmware hash |
| AN2146 | Linux | Differences between auditd process activity and /proc; kernel modules loaded from paths or hashes outside the host baseline | auditd init_module and finit_module records |
| AN2167 | Windows | Process lists differing between WMI and direct enumeration; kernel drivers loaded from unexpected paths or unsigned by trusted signers | EDR telemetry comparison; Sysmon Event ID 6 (driver loaded) |
| AN2185 | Network Devices | SNMP polling returning inconsistent results, or syslog sequence gaps | SNMP and syslog |
Metrics that show it is working
- Logic verification cadence: share of critical controllers whose running logic was compared with the offline master in the last quarter.
- Firmware verification: share of controllers and I/O modules with an independently verified firmware hash on record.
- Driver baseline coverage: share of Windows OT hosts with driver load monitoring against a signed baseline.
- Unexplained discrepancies: count and age of open mismatches between reported and independently measured state.
Prevention
- Keep offline masters. Store signed or hashed copies of every controller project and firmware image off the engineering network, under change control.
- Verify from a clean host. Compare running logic with the master using a dedicated, hardened workstation, not the everyday engineering host.
- Require signed code (M0945). Allow only vendor-signed DLLs and drivers on engineering workstations and HMIs; enable driver signature enforcement and block known vulnerable drivers. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
- Protect the controller. Use the controller's own protections, such as key switches in run position and write protection, so firmware and logic cannot be changed outside a change window.
- Audit integrity on a schedule (M0947). Include standard function blocks and organisation blocks, not just application logic.
- Plan rollback. Know how long it takes to reload firmware and logic from master, and test it on a spare.
Where identity fits
Loading a driver or writing firmware needs privilege. Remove standing local administrator rights from engineering and HMI hosts, separate the accounts that can download to controllers, and log every use. Shared vendor accounts make it impossible to say who changed what.
Safe response
- Assume the host view is false: gather evidence from network captures, offline memory images and independent field measurements.
- Coordinate with operations: a controller suspected of hiding logic may still be running the process; agree a safe state before any reload.
- Rebuild, do not clean: reimage hosts from trusted media and reload controller firmware and logic from offline masters.
- Check safety functions: because T0851 sits under Inhibit Response Function, test that safety and protection functions respond correctly after recovery. See the ATT&CK for ICS Inhibit Response Function Tactic Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for ICS mitigations | M0947 Audit; M0945 Code Signing | The two mitigations ATT&CK lists for T0851 |
| ATT&CK Enterprise | T1014 Rootkit | Enterprise counterpart for IT hosts |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity; CM-14 Signed Components; SI-4 System Monitoring; SI-3 Malicious Code Protection | Integrity checking, signed drivers and firmware, monitoring |
| NIST CSF 2.0 | DE.CM-09; PR.PS-02 | Monitoring hardware, software and runtime; maintaining software |
Common failure patterns
- Verifying controller logic from the same workstation that might be compromised.
- No offline master copy, so there is nothing trustworthy to compare with.
- Firmware versions taken from the device's own report rather than an independent check.
- Ignoring I/O modules when inventorying firmware.
- Cleaning a suspected host instead of rebuilding it.
Practitioner checklist
- Hold offline, hashed masters of all controller projects and firmware.
- Compare running logic with masters from a dedicated clean host each quarter.
- Record independently verified firmware hashes for controllers and I/O modules.
- Monitor driver and kernel module loads against a signed baseline.
- Remove standing local admin from engineering and HMI hosts.
- Test reload of firmware and logic on a spare controller.
- After any recovery, prove safety functions respond.
Standards and references
- MITRE ATT&CK: Rootkit (T0851)
- MITRE ATT&CK: Rootkit (T1014)
- MITRE ATT&CK: Stuxnet (S0603)
- MITRE ATT&CK: Audit (M0947)
- MITRE ATT&CK: Code Signing (M0945)
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Rootkits and Bootkits Guide · Firmware and Boot Security Guide · PLC Security Guide · Engineering Workstation Security Guide