SecurityMatters is now part of Forescout
SecurityMatters is now part of 
Forescout

Stay up to date, subscribe to our blog.

published on February 1, 2018

Malware Keynotes: 4 ICS Cyber Security Lessons Learned from 2017

It’s amazing that 2017 has come and gone so quickly. While 2018 is still fresh, I took some time to reflect on a few critical pieces of malware that impacted industrial organizations in 2017. I feel that these attacks were really significant from the perspective of an ICS Security Engineer, each one reminding us of something relevant.

ICS cyber security lessons learnedWannaCry

Also known as WannaCrypt, this malware affected more than 200,000 systems across the globe last May. The goal of this malware was to search for and encrypt different file types for a ransom of US$300 in bitcoins. Their stipulations were that if payment was not received after several days, the decryption key would be deleted. This crippled banks, law enforcement agencies, and industrial environments, exploiting communication links between corporate and control system networks. It was the first strain of malware to use MS17-010, aka EternalBlue, a remote code execution that exploits a vulnerability in Microsoft’s Server Message Block (SMB) protocol released in the Shadow Brokers dump in early 2017. The malware used a Tor service executable with all the necessary dependencies to access Tor for command and control.

NotPetya

Another malware known as NotPetya began to spread rapidly in June of 2017. The infection mainly focused in Ukraine but also appeared in Europe and beyond. NotPetya was original in its methods for lateral movement. It had the ability to use EternalBlue and another correlated exploit, EternalRomance, to cripple the Microsoft SMB protocol. It also took advantage of the Mimikatz post-exploitation tool to find network administrator credentials in the affected machine’s memory and get a stronger foothold on the machine. It then utilized SysInternal PsExec and WMIC tools built by Microsoft to move laterally throughout the network. It had all the appearances of a ransomware: it encrypted file systems and victim’s files and requested a payment to release the decryption key, but even if the payment was made, no decryption key was provided. This better classifies the malware as a wiper, having the sole intent of disrupting the victim’s work.

CrashOverride (a.k.a. Industroyer)

This malware was built to target different critical infrastructure environments. It had capabilities of performing attacks for multiple ICS protocols such as IEC 101 and 104, IEC 61850, and OPC. While these protocols are mainly used in electric power, they are also leveraged in other ICS industries.  Once on a system, CrashOverride looks for configuration files necessary for instrumenting remote terminal units (RTUs) and intelligent electronic devices (IEDs). The purpose is to learn about the actual memory addresses to target the most critical control points. CrashOverride had the interesting ability to operate independently of the initial Command and Control (C2). This means that after the initial incident, CrashOverride could maintain activity on the network without the need to speak to the C2, bypassing the most common behavioral checks. The malware has directly affected the civilian population, causing a blackout in Ukraine.

TRITON

This was the most recent malware tailored to attack an Operation Technology (OT) environment, and more specifically, safety instrumented system (SIS) controllers from Schneider Electric (Triconex 3008 processor modules). Until TRITON, there had been only four publicly known malwares specifically designed for OT environments: Stuxnet, Havex/Dragonfly, Blackenergy2 and Industroyer. The attackers reverse engineered the proprietary TriStation protocol and embedded specific functions necessary for the malware to disrupt the SIS controllers, such as halting the device or writing to memory.

Key Takeaways

The analysis of these 2017 malware teaches us four important lessons to be learned again and that I like to discuss with partners and customers. These lessons are key for the construction of a sound cyber security strategy and a balanced cybersecurity program focused on active defense, incident response, and disaster recovery:

  1. Conduct table top and/or controlled red team exercises to assess your current security posture and ability to respond to cyber threats. Simulate different attack scenarios (in non-production environments) to understand how you can (or cannot) detect, analyze, and recover from these threats. Testing your knowledge and repeatedly practicing various threat scenarios will improve your awareness and ability to respond to real incidents.

  2. Observe and baseline your normal network communication and ICS protocol communications to identify anomalous behavior worth investigating. Network whitelisting and protocol deep packet inspection, in conjunction with host-based application whitelisting, can assist in this respect. NotPetya and CrashOverride were a sign that future malware will perform lateral movement utilizing approved software functions.  CrashOverride and TRITON showcased how in-depth ICS protocol knowledge can be built into malware frameworks to execute valid operational functions in an undesired manner, in order to disrupt operational processes. Smart behavioral monitoring will become more and more important in detecting advanced threats and zero-day attacks, as demonstrated during the recent S4 ICS Anomaly Detection challenge.

  3. A defense-in-depth strategy and proper network segmentation will help to mitigate the risk of IT malware spreading into control system networks. Apply recognized design strategies (e.g. IEC 62443/ISA99) with secure remote access to separate control layer from the engineering layers. Malware such as WannaCry and NotPetya was not targeted at OT environments, but exploited existing communication links to spread, causing significant collateral damage.

  4. Whenever possible, apply patch management processes across your ICS environments to reduce the risks from known vulnerabilities. Although it’s difficult to patch controllers and field devices, servers and workstations should be recurrently assessed and patched to protect them from the last discovered vulnerabilities. Ideally, patch management should include an automated data feed of the latest patches available for your endpoints, as well as a process to test, schedule and roll out the patch.  

There’s no rest for the weary when it comes to defending your infrastructure and network. We will see what 2018 will bring, but applying these four lessons will definitely help you be better prepared!

 

Need for Monitoring

Join the conversation