MITRE ATT&CK for ICS: Practical Applications, Part 5

Device Restart/Shutdown

Armis presents Mitre Attack for ICS: Practical Applications Part 4

Thank you for joining us for our final installment in our MITRE ATT&CK for ICS blog series. Our hope is that you’ll continue working with the remaining MITRE ATT&CK techniques, improving your defenses and creating a safe and reliable ICS environment.

In case you’ve missed the previous blogs, you can catch them here:

For this entry, we will cover Device Restart/Shutdown, one of the MITRE ATT&CK techniques listed under the Inhibit Response Function tactic as shown below:

Mitre Attack Matrix Device Restart Shutdown

Device Restart/Shutdown

What is this technique all about? Well, MITRE defines T816: Device Restart/Shutdown as follows:

Adversaries may forcibly restart or shutdown a device in the ICS environment to disrupt and potentially cause adverse effects on the physical processes it helps to control. Methods of device restart and shutdown exist as built-in, standard functionalities. This can include interactive device web interfaces, CLIs, and network protocol commands, among others. Device restart or shutdown may also occur as a consequence of changing a device into an alternative mode of operation for testing or firmware loading.

Unexpected restart or shutdown of control system devices may contribute to impact, by preventing expected response functions from activating and being received in critical states. This can also be a sign of malicious device modification, as many updates require a shutdown in order to take affect.

On home computers and on devices in the enterprise world, forced shutdowns or restarts have been used by the bad guys for a long time. The reason for this is typically for something other than the disruption it causes. Malware might need to use a forced restart to complete an installation. Adversaries may also employ this technique as part of running an exploit, such as if a service needs to be restarted and the adversary does not have sufficient permission to do so.

In the ICS realm the stakes can be higher. Device restarts can be used in much the same manner to complete malicious code installations and, if successfully installed, can cause malicious actions based on that code. Additionally, unlike other environments where a power button is not far away, shutting down remote ICS devices can have tremendous impact on safety, security, or finances due to the increased time it can take to bring it back online.

MITRE has provided a real-world example for this technique named Industroyer (aka CRASHOVERRIDE). Included in this malware is a module that exploits a vulnerability in Siemens SIPROTEC (CVE-2015-5374), to cause such a denial of service using a simple sequence of bytes.

Practical Defenses Strategies

Let’s look at some ways that we can secure against the MITRE ATT&CK technique Device Restart/Shutdown.

Defense #1: Be Proactive

So far in this blog series, we haven’t gone into depth about one of the finer defensive arts that security teams should practice: Threat intelligence. Threat intelligence is information about the latest adversaries, tactics and techniques, indicators of compromise (IOC), disclosed vulnerabilities, vector-specific targets, and really any data source that helps you focus on the newest threats (real or potential) observed.

You may ask how this relates to the Device Restart/Shutdown technique defensive posture. Let’s walk through this example from Industroyer and the 2016 attack on Ukraine’s critical infrastructure. In December of that year, the Industroyer malware was employed to disrupt power to the Ukrainian power grid. The modular malware used in this attack included an exploit for CVE-2015-5374 which, when successful, would cause a denial of service.

ICS-CERT issued an alert in July 2015 for this vulnerability — that was seventeen months before the attack on the Ukrainian power grid. If the operators of the Ukrainian power grid had been monitoring threat intelligence from ICS-CERT, they could have taken steps to mitigate the vulnerability in their ICS environment prior to the attack, thus neutering this exploit. Further, the intelligence from blogs written after the attack on the Ukrainian power grid can provide ‘lessons learned’ to help provide improved defensive measures against future attacks.

In a recent example, Cisco TALOS released a blog outlining several newly-disclosed, serious vulnerabilities in a vendor’s automation software and the vendor’s controllers themselves. Your threat intelligence efforts will have certainly picked that up, right?

Before we go too far into this topic, it’s good to make sure that you keep focus on the overarching point: Be proactive in looking for data on threats that may affect your environment. Not every option we go through may work with your current workflows, tools, or methodologies, but don’t lose sight that you should be active in gathering this data. Further, don’t assume that this process isn’t worth it, or that this information will just ‘bubble-up’ naturally.

Consider that SANS reported just under half of their cyber threat intelligence (CTI) 2020 survey respondents have a team dedicated to cyber threat intelligence. Thankfully, this number is up over previous surveys and shows a growing focus in gathering and using threat intelligence.

There are many sources of threat intelligence including vendor-supplied intelligence, peer-to-peer, and free public domain resources (OSINT)—which of course includes the MITRE ATT&CK techniques themselves. Let’s look at each of these:

Freely Available:

It seems there is an endless number of freely available threat streams, as a quick Google search will reveal. Beyond these feeds, think of vendors that provide blogs like the one you’re reading now for the latest threat information. Likewise, a site like ICS-CERT will provide you with data on the latest ICS-related issues, and can be delivered automatically via email. Lastly, tools like MISP can help organize the data for you. Be assured, there are many, many more feeds and tools available in this arena that you can start your threat intelligence program with.

Peer-to-Peer:

Join and engage in security groups, especially those that have members associated with the same business sectors as your own. These can be indispensable for vector-specific threats and may have data on adversaries or threats that are not public, especially as close relationships are developed.

Vendor-Supplied:

Although there is much overlap in this type of threat intelligence (shared with OSINT), there are also several distinctions. Typically, these threat intelligence providers have a presence in the deep/dark web that most fledgling threat intelligence teams do not have. These providers also present their data in an organized manner that is tailored to their customers. Lastly, threat intelligence vendors can provide intelligence against things that you are not immediately associated with your ICS environment, such as threats against executives.

Lastly, wherever possible, leverage these feeds within your tools and/or utilize tools that incorporate threat intelligence natively. As an example, Armis can tell you when communication occurs with potentially malicious domains, as shown below:

Armis detects risky communication in ICS environment

Defense #2: Noise, Noise, Noise

Skilled adversaries, in the course of their activities, make every attempt to disguise their presence. They use tools like wipers to erase their tracks. They use applications that are native on devices in unintended ways to avoid suspicion. They rename their tools to applications that might be expected. They use expected services in unintended manners, or expected services in traditional manners, to exfiltrate their data. The list goes on and on.

You might think, therefore, that adversaries will be unimpeded every time they set their sights on a target…but have hope! As we saw with the Triton Malware in our previous blog, and again with the Ukrainian power grid attack of 2016, there were signs left by the attackers that indicated their presence as they moved within the environment. Think about it this way: in almost every scene where a burglar robs a house with people sleeping, what happens? A noise thwarts their attempts. So then, we just need to listen carefully.

Some of the ways we can listen for this noise are as follows:

Watch the wire: Using network IPS, as part of a layered approach, may allow detection of known attack signatures that cross it. One good thing about network IPS is the fact that, compared to a host-based control, it is less likely that this control will be maliciously modified. But a major limitation of network IPS is the fact that it is primarily reactive. It often misses attack fingerprints that have not been previously observed.

Host-Based: Employ tools such as application whitelisting, anti-malware, security analytics, or EDR agents to listen for application changes, malware installations, or other anomalous activities. Of course, be cognizant of the fact that many devices in ICS environments do not have the ability to host security agents.

Anomalous Behavior: Use a Network-based Anomaly Detection tool that will detect patterns in traffic, application usage, or other behaviors that are outside of normal behavior. The best behavior anomaly tools are those that compare device behavior to multiple baselines: the device’s previous behavior, the behavior of other similar devices within your environment, and the behavior of other similar devices in other environments.

Below is an example of an Armis alert after detecting anomalous behavior similar to what might have occurred during the attack on the Ukrainian power grid:

Armis detects anomalous behavior in ICS environment

Defense #3: Layers

Throughout our series, we’ve presented suggestions for defensive techniques that allow you to detect MITRE ATT&CK techniques by using layers of security. We think layered security is important, and most defenders seem to agree, as exemplified in how they have architected their environments.

Study methodologies like the MITRE ATT&CK framework, and map controls to each of the layers. Once implemented, be sure you test your control layers regularly through simulated attacks in which each layer is challenged. Remember that adversaries can sometimes attack your specific security controls, rendering them impotent. Multiple security layers can help with this.

As an example, you can map Armis to the following steps in the cyber kill chain:

  • Exploitation (Pre and Post): Vulnerability Identification, Anomalous Behavior, Threat Detection
  • Installation: Anomalous Behavior, Threat Detection
  • Command and Control: Anomalous Behavior, Threat Detection, Malicious Domains (Threat Intelligence)
  • Actions on Objectives: Anomalous Behavior, Threat Detection

Finally, administration or funding limitations may at times lead teams to reconsider the security controls in use within your environment. Remember to compare all features of controls if you are looking to reduce your stack, being sure that you are not erroneously leaving holes without also accepting that risk.

Conclusion

With that, we’ll conclude our series. We hope that MITRE’s ATT&CK for ICS matrix provides a positive impact in your ICS environment, and that our blogs have provided some insight and sparked thought around ways you can defend against the threats you may face.

Stay safe out there.

If you want to learn more about how Armis maps to the MITRE ATT&CK techniques, check out our white paper.

Have our blog posts sent to your inbox.