In December, 2014 the German Federal Office for Information Security notified about a malicious attack on a steel mill operated by a German based company. The attack was initiated using spear phishing. Attackers gained access to the corporate network and moved into the plant network. According to the report, the adversary, showing extensive knowledge of ICS networks, was able to bring down multiple components including a furnace resulting in substantial physical damage to the plant. The original article is available here, and a useful assessment by SANS can be found in this report.
The Attack 
The attack started as a “traditional” APT attack on the IT network and evolved into an attack on the ICS network.

Initially, the attackers infiltrated the IT network by sending a phishing email. Most likely, the email contained a document attachment such as a PDF file that when opened executed malicious code on the attacked computer.  This code opened a remote connection between the perpetrators and the enterprise network. The connection was used to traverse the network, locate vulnerable touchpoints between the trusted IT network and the OT network and find information that will lead the attackers to the entry point into the sensitive OT (ICS) network.

Once gaining control of the ICS network the attackers were potentially able to compromise programmable logic controllers (PLCs) and alarm systems, and eventually compromise a furnace, preventing it from being turned off. The result was described as “an accumulation of breakdowns of individual components of the control system, or of entire facilities.” Suggesting potential loss of control and massive physical destruction.

The way the furnace was compromised is not described and we believe that it was either reconfigured by the attackers to remain in “ON” status, or was continuously sent “ON” commands. 
Where Did Security Fail?
The organizational security operation failed in several points. Implementing and managing security best-practices, and implementing best-of-breed security products would have prevented this breach:

1. Security Best Practices – had employees avoided opening non-trusted email attachments, this breach may have been prevented at an early stage. However, attackers may have emulated trusted sources, making it very difficult for employees to identify the attack. In addition, better implementation of software update procedures may have patched the vulnerability that allowed the attackers to open the file and execute the malware in the first place.
2. IT Network Protection – lack of an effective endpoint detection and response system, allowed attackers to successfully execute the malware, open a communication channel and work, uninterrupted, to find the way into the OT network.
3. ICS Network Configuration – the organization allowed bi-directional communication between IT and OT networks. As a result, the infiltrator was able to control OT components through the IT network.
4. ICS Network Protection – the facility lacked a solution to detect and alert on the increase in abnormal activity, both in terms of non-standard network communication, as well abnormal behavior of system components.

How the Attack Could Have Been Prevented
This form of attack is unique and targeted, and therefore unlikely to be detected and eliminated using traditional best practices and signature-based security products.

The following measures could have prevented the attack:

1. Implementing advanced endpoint detection and response (EDR)
   The attack used advanced, targeted malware, and originated in the IT network. A next-generation endpoint detection product, based on behavioral analytics rather than on signatures, would have identified the malware once executed and can detect advanced and targeted threats that bypass signature-based products, in merely seconds.
2. Integrate products that increase ICS network visibility
   Visibility is a key challenge when protecting ICS networks. IT and OT managers often do not have a full grasp on all network components, and most important, are not aware of all IT and OT network touchpoints and misconfigurations. In this case the plant’s network was wrongly configured to allow 2-way communication between the IT and OT networks, which allowed the attackers to open a connection and continuously communicate with the malware, while infiltrating the OT network.
   An OT security solution, which provides a clear visual mapping of the organizational network, including all sensitive OT/IT touchpoints, would have alerted about the bi-directional communications between the OT and IT networks, enabling the IT/OT manager to reconfigure and address the problem before the attack took place.
3. Implement ICS network monitoring – an ICS network monitoring system would have identified and alerted in real-time about non-standard activities that took place during the breach. Some of these are:
   a. IT Network components communicating in OT protocols: during the event, IT network components used SCADA protocols to communicate with the OT network. A monitoring system would detect IT or OT elements, which use unauthorized protocols. In our case, an IT network component “speaking in SCADA” would be immediately flagged.
   b. Unexpected reconfiguration – ICS attackers often disable system alerts to cover for malicious activity. In our case they had to disable the furnace’s high temperature alert. A monitoring solution would detect such reconfiguration.
   c. Abnormal movement and reconnaissance – an ICS monitoring solution would have immediately identified the attackers’ movement inside the ICS network, as well as attackers scanning to perform network reconnaissance. These movements will manifest in the use of abnormal protocols and commands in network devices, exposing the malicious activity.

Summary
This event could have been prevented by employing several essential measures:

1. Improving security best practices.
2. Deploying IT Network Protection such as EDR.
3. Eliminating bi-directional IT/OT communications.
4. Using ICS network monitoring and security.

For input or questions on my assessment please feel free to contact me anytime at alexey.potekhin@cyberbitsolutions.com

Alexey Potekhin is SCADA Security Product Lead at CYBERBIT