It is our hope that you are enjoying reading our MITRE ATT&CK for ICS blog series as much as we are enjoying writing them. Last week we attended the annual RSA security conference, and we heard quite a few references to the MITRE ATT&CK framework and the need for better security in ICS environments. We were happy to see all the excitement about the MITRE ATT&CK for ICS matrix and the guidance that it provides to defensive teams.
Each blog in our series stands on it’s own, but If you haven’t seen the previous blogs, they are available here and here.
With that, let’s dive into it…
For part three, we’ll cover MITRE ATT&CK for ICS technique T839: Module Firmware. It is located under two different MITRE ATT&CK tactics: Persistence and Impair Process Control.
MTIRE describes this technique as follows:
“Adversaries may install malicious or vulnerable firmware onto modular hardware devices. Control system devices often contain modular hardware devices. These devices may have their own set of firmware that is separate from the firmware of the main control system equipment.
MITRE uses the term “module” to refer to firmware that exists in components that support ICS devices, such as ethernet cards. The module firmware is independent of the system firmware that is a part of the ICS device. Module firmware can be a prime target because it typically does not have the validation and protection in place that normal ICS system firmware has.
Attacks against module firmware represent a level of sophistication not typically seen, but they are out there. One such firmware attack detected in-the-wild is called LoJax. This malware modified the UEFI/BIOS firmware used by LoJack’s anti-theft application. Once this was accomplished, the attacker was able to drop malware onto the host operating system and maintain persistence.
The elevated privileges that firmware enjoys is something to consider when pondering the impact a successful attack could provide. Unlike malware that typically receives only the privileges of the affected user, firmware has elevated privileges and therefore is potentially more impactful than your run-of-the-mill infection.
Once module firmware has been modified, it can be very difficult to fix. Worse, due to the nature of ICS devices, onboard security agents are not an option. It is important to make sure that layered security and careful, constant monitoring is employed in the ICS environment.
What are some ways, then, that we can secure devices against the MITRE ATT&CK technique of Module Firmware?
The fact of life is…vulnerabilities happen. It doesn’t appear likely we’ll ever reach 100% safe code, and as such, we need to prepare the best we can. Consider that Cisco’s 2020 CISO Benchmark Report details that 46% of respondents had an incident as a result of an unpatched vulnerability. This was up from 30% for the previous year.
Be sure that not only firmware, but all software (on all devices) within your network remain up to date. Remember that adversaries may use vulnerabilities on other devices to gain a foothold and move laterally into your ICS environment (pivoting from these links). The key here is to employ strong vulnerability management. Keep your entire environment updated as quickly and completely as possible.
Also note that change control processes may delay patching, or patches may not yet be available at the time of disclosure. Be sure you have processes and procedures in place ahead of time to protect these devices via other mitigating controls. This is especially important when a critical vulnerability is uncovered. This may include employing or reconfiguring current or additional controls such as network segregation/segmentation to help mitigate until you can patch.
One of the tell-tale signs of a firmware attack would be communication back to the adversary in order to direct the attack, or exfiltrate data from the environment. This communication could be directly to a command and control (CNC) server, or it may be ‘bounced’ through the network via other compromised devices. Be sure you are looking for these signs, using techniques such as the ones we recommend in the first blog of our series. Monitor and control all connections, and contemplate worst-case scenarios.
Some questions you may ask yourself about these connections include:
After you’ve double-checked the communication paths, you’ll want to regularly monitor those connections for changes. Enlist threat intelligence to compare against known-bad indicators of compromise (IOC). Be sure that you are using the latest data available, because Command and Control (CNC) servers are typically very short-lived (on average one month). Segregate communication as much as feasibly possible using VLAN or firewalling techniques. Ensure strong authentication methods are in place using complex passwords or multi factor authentication when possible. Lastly, employ a network traffic monitoring system that sees ingress and egress traffic from all your ICS devices and knows what good and bad traffic looks like. This can be especially important should your network infrastructure itself be compromised, and when that happens, there goes your segmentation.
As an example, Armis can understand when a threat appears such as CNC communication, as seen below:
Adversaries may also use a man-in-the-middle (MiTM) attack that redirects firmware updates to servers within their control in order to upload their malicious firmware version. If possible, upgrade components to those that support firmware validation techniques on the device (or perform these validations manually), and protect those update channels to assure that updates are received from legitimate sources.
In part two of our series, we introduced the concept of watching the wire for PLC commands. For Module Firmware modifications, you want to engage a network-based monitoring tool that can parse those commands. This can include IPS devices looking for attack signatures but should also include the ability to parse any command so that you can also audit for legitimate, yet unexpected, events. For example, you should be able to audit a PLC reset that is being performed out-of-band of planned upgrades or outages windows. Similarly, you may want to audit these commands:
As an example, Armis allows a policy to be enabled that will look for commands like PLC firmware changes as seen below:
In addition to understanding what commands are occurring in your ICS environment, you should leverage tools that understand when ICS devices are deviating from standard behavior. Anomalous behavior may be indicative that something is amiss and could include behaviors such as increased network traffic or communications with devices it doesn’t normally communicate with. This behavioral analysis should include a baseline against the device itself, a baseline against similar devices in the environment, and a baseline of typical devices of that type.
An example alert of how this could be accomplished using Armis is shown below:
If you have read Parts 1 and 2 of this blog series you may have noticed that several of the defensive tools and approaches are the same across multiple MITRE ATT&CK techniques. For this, we can be thankful. If security practitioners needed to use a different approach for each of the 81 ATT&CK techniques, their jobs would be much more difficult. As much as possible, the methods and tools you choose today should be nimble enough to modify for tomorrow’s threats.
Take this light-hearted analogy: Screwdrivers have been around for a long time. Why? because they are effective at what they do. But, that doesn’t mean that they are only useful to drive screws.
If you want to learn more about how Armis maps to the MITRE ATT&CK for ICS matrix, check out our white paper.
Our next blog in this series will cover MITRE ATT&CK technique T858: Utilize/Change Operating Mode. Until then, keep safe.
Sign up to receive the latest news