|Tactic||Evasion, Inhibit Response Function|
|Data Sources||Controller program|
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 I/O that can be attached to the 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.
- One of Stuxnet's rootkits is contained entirely in the fake s7otbxdx.dll. In order to continue existing undetected on the PLC it needs to account for at least the following situations: read requests for its own malicious code blocks, read requests for infected blocks (OB1, OB35, DP_RECV), and write requests that could overwrite Stuxnet’s own code. Stuxnet contains code to monitor and intercept these types of requests. The rootkit modifies these requests so that Stuxnet’s PLC code is not discovered or damaged.2
- When the peripheral output is written to, sequence C of Stuxnet intercepts the output and ensures it is not written to the process image output. The output is the instructions the PLC sends to a device to change its operating behavior. By intercepting the peripheral output, Stuxnet prevents an operator from noticing unauthorized commands sent to the peripheral.3
- Restrict access to control room(s), portable devices, and removable media, which should be locked down and physically secured. Unauthorized and suspicious media should be avoided and kept away from systems and the network.4
- Ensure ICS and IT network cables are kept separate and that devices are locked up when possible, to reduce the likelihood they can be tampered with.4
- Hold new acquisitions to strict security requirements; be sure they are properly secured and haven’t been tampered with.4
- In environments with a high risk of interception or intrusion, organizations should consider supplementing password authentication with other forms of authentication such as multi-factor authentication using biometric or physical tokens.4
- Make use of antivirus and malware detection tools to further secure the environment.4
- Identify potentially malicious software that may contain rootkit functionality, and audit and/or block it by using whitelisting5 tools, like AppLocker,67 or Software Restriction Policies8 where appropriate.9
- Enterprise ATT&CK. (2018, January 11). Rootkit. Retrieved May 16, 2018.
- Ralph Langner. (2013, November). To Kill a Centrifuge: A Technical Analysis of What Stuxnet's Creators Tried to Achieve. Retrieved March 27, 2018.
- Nicolas Falliere, Liam O Murchu, Eric Chien. (2011, February). W32.Stuxnet Dossier (Version 1.4). Retrieved September 22, 2017.
- Keith Stouffer. (2015, May). Guide to Industrial Control Systems (ICS) Security. Retrieved March 28, 2018.
- Beechey, J. (2010, December). Application Whitelisting: Panacea or Propaganda?. Retrieved November 18, 2014.
- Tomonaga, S. (2016, January 26). Windows Commands Abused by Attackers. Retrieved February 2, 2016.
- NSA Information Assurance Directorate. (2014, August). Application Whitelisting Using Microsoft AppLocker. Retrieved March 31, 2016.
- Corio, C., & Sayana, D. P. (2008, June). Application Lockdown with Software Restriction Policies. Retrieved November 18, 2014.
- Microsoft. (2012, June 27). Using Software Restriction Policies and AppLocker Policies. Retrieved April 7, 2016.