T0851: Rootkit
Adversaries may deploy rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting and modifying operating-system API calls that supply system information. Rootkits or rootkit-enabling functionality may reside at the user or kernel level in the operating system, or lower. [1]
Firmware rootkits that affect the operating system yield nearly full control of the system. While firmware rootkits are normally developed for the main processing board, they can also be developed for the I/O that is attached to an asset. Compromise of this firmware allows the modification of all of the process variables and functions the module engages in. This may result in commands being disregarded and false information being fed to the main device. By tampering with device processes, an adversary may inhibit its expected response functions and possibly enable Impact.
Analyst context for executives and security teams
Rootkits matter in ICS because they can make compromised systems look normal while hiding programs, files, services, drivers, network connections, or even firmware-level changes. For operational environments, the concern is not only stealth on a workstation or server; the ATT&CK description notes that firmware compromise can alter process variables, disregard commands, or feed false information to a main device, which can undermine operator trust and response decisions.
Executive priority
Treat this as a high-priority resilience and assurance issue for critical ICS assets. Leaders should ask whether the organization can prove the integrity of workstations, HMIs, controllers, historians, gateways, remote access systems, firewalls, and embedded field devices after reboots, program downloads, restarts, or incidents. Budget and control decisions should prioritize trusted code execution, firmware/software integrity baselines, and audit evidence that can support incident response and compliance claims.
Technical view
ATT&CK provides no official detection text and no technique-level platform list, but relationships show broad ICS asset relevance across Windows, Linux, Embedded, and Network-class assets. SOC and IR teams should validate coverage around the related Detection of Rootkit strategy, then map it to the specific assets in scope: operator workstations and HMIs, PLCs, IEDs, safety controllers, DCS/PAC devices, data historians, control/application servers, gateways, VPN servers, jump hosts, switches, and firewalls. Detection validation should focus on whether reported system state can be independently corroborated, especially for files, services, drivers, network connections, firmware/software versions, configurations, process variables, and command/response behavior.
Likely telemetry
- Endpoint and server inventory for programs, files, services, drivers, and network connections on Windows/Linux ICS hosts where available
- Firmware, software, program, and configuration integrity records, including hashes or digital signatures from known-valid states
- Audit or scan results for systems, permissions, insecure software, and insecure configurations
- Controller, I/O, and device configuration records, especially after reboots, program downloads, or program restarts
- Operational process telemetry showing process variables, commands issued, commands accepted or disregarded, alarms, and device responses
Detection direction
- Do not rely only on the potentially compromised operating system view; rootkits are explicitly described as intercepting and modifying OS API calls that supply system information.
- Validate integrity checks against known-valid firmware, software, programs, and configurations, especially after reboot, program download, or program restart events.
- Tune investigations around mismatches: hidden or unaccounted services, drivers, files, connections, firmware versions, process values, or command outcomes.
- For embedded and field devices, prioritize comparison of expected device logic/configuration and observed process behavior, because traditional endpoint telemetry may be limited or unavailable.
- Account for false positives from authorized maintenance, firmware updates, engineering changes, and planned program downloads by tying alerts to change records and maintenance windows.
Mitigation priorities
- Enforce code signing and digital signature verification where supported to prevent untrusted binaries or applications from executing.
- Maintain known-valid baselines for firmware, software, programs, and configurations on critical ICS assets.
- Perform periodic audits and integrity checks of systems, permissions, insecure software, insecure configurations, and device state.
- Prioritize integrity validation for assets that bridge trust boundaries or operator decision-making, including HMIs, historians, control servers, gateways, VPN servers, jump hosts, and firewalls.
- Build incident response playbooks that include out-of-band validation of device state and process behavior when rootkit-like hiding or false reporting is suspected.
Analyst notes and limits
The Stuxnet relationship shows this technique has historical relevance to ICS malware tradecraft, including a sophisticated Windows rootkit, but this take does not infer current activity or attribution. The relationship set is broad across many ICS asset types, so local asset criticality and telemetry availability should drive prioritization.
MITRE does not provide official detection guidance, tactics, or technique-level platforms for T0851 in the supplied fields. Asset platform details come only from relationship context. Practical detection and mitigation depend heavily on vendor capabilities, firmware access, engineering change control, and whether trustworthy baselines already exist.
Rootkit
Adversaries may deploy rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting and modifying operating-system API calls that supply system information. Rootkits or rootkit-enabling functionality may reside at the user or kernel level in the operating system, or lower. [1]
Firmware rootkits that affect the operating system yield nearly full control of the system. While firmware rootkits are normally developed for the main processing board, they can also be developed for the I/O that is attached to an asset. Compromise of this firmware allows the modification of all of the process variables and functions the module engages in. This may result in commands being disregarded and false information being fed to the main device. By tampering with device processes, an adversary may inhibit its expected response functions and possibly enable Impact.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 88f41808647d… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Enterprise ATT&CK January 2018
Enterprise ATT&CK 2018, January 11 Rootkit Retrieved. 2018/05/16
Open source URL -
[2]
mitre-attack T0851Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.