Practical and Theoretical Attacks in the Industrial Landscape (Part 2)

In part one of this series, we constructed a virtual factory using a simulation and training platform called factory.io. We included all the components needed to build a real-world assembly line in a virtual setting. To conclude this series, we’ll come to our factory from an attacker’s perspective and explain the attacks and techniques at their disposal to disrupt automation processes.

We assume in our scenario started in part one that the attackers have already figured out a way to gain access to the OT network and are able to communicate with SCADA devices. Their main objective is to cause harm and disrupt the industrial process happening in our factory.

Defending against potential attackers in the industrial landscape requires understanding an adversary’s incentives and methodologies. First, let's enumerate the different incentives that may motivate an attacker to go after an automation environment:

1. Financial Gain: Automation is critical to many industries and is at the core of companies’ profit and the delivery of indispensable services worldwide. An attacker seeking financial gain may disrupt a facility with little effort and, oftentimes extort victims with extravagant ransom demands. The attacker benefits from the fact that time plays against the victim because it loses revenue and profits with each passing minute without production or services up and running.

2. Physical Process Disruption: An attacker may also seek to disrupt operations of industrial facilities from a competitive standpoint. For example, a rival factory trying to push other facilities out of business.

3. Espionage: An attacker may try to steal secrets for political or financial gain. Nation states may seek intellectual property to further their own geopolitical motives, or rival businesses may seek to put competitors at a disadvantage by stealing trade secrets. 

Those three motivations cover the “why” attackers may target factories and other automated environments. The “how” is what we’ll cover in the remainder of this blog as we attempt to simulate an adversary’s actions and the different factory components that may be targeted in such an attack. 

MITRE ATT&CK as a Baseline

We are tracking different attacks using the MITRE ATT&CK ICS framework. This matrix is an effective tool security pros can use to identify, assess, and mitigate cyberattacks against industrial networks. For example, here are the relevant attack techniques and tactics used by the infamous Triton ICS malware.

With the MITRE ATT&CK ICS framework as a reference guide, we’re going to explore a number of possible attacks and consequences that can be modeled out within our virtual factory environment. The attacks we’ll cover target different components in our factory, such as the HMI, engineering workstation, and PLCs, using a number of techniques after initial access has been established. These attacks threaten physical processes with disruption or manipulation, and can include a number of techniques explained in the framework, especially “Impair Process Control” and “Impact.”

Here’s a rundown of our attacks and the tactics, techniques and procedures at the disposal of an attacker targeting our factory:

Attacking The HMI

• Memory Intervention and Modification: Changing memory of the HMI process while it is running

• DLL Hijacking (T0874): Replacing DLLs used by the HMI executable

• Front End Manipulation: Changing UI artifacts presented on the HMI panel

• Project File Injection (T0873): Changing the Project files consisting of HMI event scripts

Attacking The EWS

• Memory Intervening: Changing memory of the PLC programming process while it is running to change the programs downloaded to the PLC

• DLL Hijacking (T0874): Replacing DLLs used by the Programming software executable

• Project File Injection (T0873): Changing the Project files consisting of PLC programs

• Network Interception (MiTM) (T0830): Changning the PLC programs bytecode when they are being downloaded

Attacking the PLC

• Remote Code Execution (T0851): Remotely executing code natively on the PLC will enable attackers to modify the business logic while staying fully hidden in memory.

• Logic Download (T0843): Modifying the logic on the controller using the commercial tools.

• Code Hiding (T0821, T0849): Decoupling and hiding different bytecodes on the PLC while having the original source code

• Tag Manipulation (T0871): Remotely manipulating PLC tags

Attacking the HMI

The HMI as presented in part one is utilized by industrial engineers to monitor and control the industrial operations in a facility. Attacking this component is beneficial when an attacker needs to masquerade active interference with the facility's physical operation or disrupt its operation over long time periods.

This scenario is very problematic because without proper monitoring and maintenance issues in the factory accumulate over time without any given attention or proper treatment. The infamous Stuxnet malware was one such incident where the malware misled operators monitoring centrifuges. The operators believed the HMI, which told them the centrifuges inside the Natanz plant in Iran were operating as expected, while in fact they were spinning out of control and being irreparably damaged.

In many cases, the first step for an attacker will be to achieve full control over the HMI. Meaning an attacker would need to find a vulnerability allowing remote control over the HMI. For example, at Pwn2Own Miami 2020, Team82 and other researchers found, demonstrated and disclosed such exploits against Inductive Automation’s Ignition, the vendor’s HMI product. 

In the following section we assume the attacker already gained access to the HMI operating system. The following attacks could be used to disrupt the proper operation of an HMI, such as the one in our virtual factory.

Memory Intervening

• Likelihood: Low

• Complexity: High

• Impact: High

An attacker infects the host machine running the HMI process, then the attacker provides an implant that manipulates memory in the RAM of the HMI process, and misleads operators into thinking the process is running as expected. 

The implant the attacker brings can attach to the running HMI process and change memory content or inject a maliciously crafted DLL. This implant can utilize mechanisms used by other utilities such as Cheat-Engine, which can be used to modify raw memory, and DLL injectors.

DLL Hijacking

• Likelihood: High

• Complexity: Medium

• Impact: High

An attacker infects the host machine running the HMI process, then the attacker injects an implant that replaces the DLL used by the HMI process to manipulate monitored values by operators.

The DLL most likely to get replaced will probably be related to handling of OPC UA communication or even to HMI event script handling.

Front End Manipulation

• Likelihood: High

• Complexity: Low-to-Medium

• Impact: High

Another method an attacker might employ is to intercept WebSocket responses from the Ignition HMI’s web server. The websocket is used to update the state of the gauge presented to the operator’s browser. An attacker might then manipulate the values transmitted to the client on the fly.

As a demonstration, we could launch our panel browser and proxy the web traffic through burpsuite in order to intercept WebSocket packets and manipulate the value presented in the operator panel.

Now we intercept the responses from the WebSocket server and manipulate the value indicating the amount of pallets handled.

Project File Injection

• Likelihood: High

• Complexity: Low-Medium

• Impact: High

Another method that might be used by attackers is to change the configuration of the project file behind the scenes, altering the logic implemented, and disrupt the HMI.

In our case, the project file consists of several elements, the most important being the config.idb which contains the event scripts for our gauge artifact.

The sqlite3 db is located at:

C:\Program Files\Inductive Automation\Ignition\data\db\config.idb

Network Interception (MiTM)

• Likelihood: Low

• Complexity: High

• Impact: High

Another method that might be used by attackers would be to Man-In-The-Middle network traffic, which means to intercept network communication between devices on the network and actively alter transferred data. For instance, an attacker targeting our simulated factory may want to intercept transmitted traffic over the OPC UA protocol on the local network and alter the transferred information. Attacking OPC UA has also been extensively researched by Team82 and our group found and disclosed numerous vulnerabilities against this component.

Attacking the EWS

The engineering workstation is a valuable target. Having control over this system allows the attacker to manipulate the PLC and change in a drastic manner its operational procedures. We observed three potential methods to influence the EWS and attack an industrial process in our virtual factory.

An attacker wanting to have a firm grip over any industrial operation will mostly target this component because it is where PLCs are programmed and the operation of a facility is developed, implemented and maintained. As such this component is crucial for an attacker to gain a foothold into industrial business logic.

To carry out these attacks, the attacker would need to have some remote access to the workstation, mainly using a vulnerability that allows for remote control over a standard computer system, Attackers then need to elevate their privileges and gain access to the actual engineering workstation programming software, which in most cases runs as an elevated process on the computer system. Team82 has previously disclosed multiple exploits against various EWS applications.

Memory Intervention and Modification

• Likelihood: Low

• Complexity: High

• Impact: High
  

An attacker creates a malware that infects the EWS and manipulates memory belonging to the programming process of the PLC.

This method can be executed by executing code on the engineering workstation that attaches to the PLC programming software process and in memory editing its content to manipulate the program that will be downloaded to the PLC or even blocking and locking the software.

DLL Hijacking

• Likelihood: High

• Complexity: Medium

• Impact: High

An attacker infects the host machine running the PLC programming process, then provides an implant that replaces the DLL used by the PLC programming process to meddle with the program logic that is going to be downloaded into the PLC.

This attack was also implemented in the famously known attack by Stuxnet malware. When Stuxnet targeted the Siemens programming software called STEP7 it replaced the s7otbxdx.dll. and by doing so managed to meddle with the programming of the PLC.

Project File Injection 

• Likelihood: High

• Complexity: Medium

• Impact: High

A simpler way to introduce malicious code that can be effective is the manipulation of the project file bundled with the PLC program logic. An attacker can achieve this by implementing a malware that overwrites the project file consisting of the PLC program before it is downloaded to the controller.

This method is mitigated by some vendors using signature-based mechanisms that validate the project file and prevent malicious altering of the project.

Network Interception (MiTM)

• Likelihood: High

• Complexity: Medium

• Impact: High 

Similar to project file injection, attackers can intercept the download of new programs to the PLC and manipulate their content before it reaches the target controller on the factory. This method requires the attacker to thoroughly know the protocol used to program the PLC. For instance, in our case this protocol is CIP.

This form of attack has also been mitigated by implementing a better, more secure form of communication between the EWS and PLC. 

For example, Rockwell Automation and ODVA developed CIP Security which is a method to secure the old CIP protocol. In essence it’s a communication form that enables three security measures: 

• Integrity by allowing the rejection of altered data.

• Authenticity by allowing the rejection of data sent from untrusted sources.

• Authorization by making some requests invalid and rejected upon request.

To deploy this specific solution in an OT environment, one would need to use Rockwell’s Factorytalk Policy Manager and configure the policy for the network. For example, PLC from Zone X will be able to communicate with an HMI and an EWS from Zone Y only. During the configuration, a set of certificates will be generated and sent to each party so they could communicate over a secured channel.

Attacking the PLC

The PLC is the heart of the factory. This is where business logic is translated to physical actions orchestrated by the PLC using an engineer’s code. As a component that often consists of proprietary systems, this system is both difficult to monitor for odd activity and has fine control over an industrial operation. An attacker with the ability to infect PLCs gains the advantage of being stealthy and also controlling granular aspects of a specific industrial process.

The PLC is the central component controlling the process and bundles its logic. Successful attacks against the PLC can range in sophistication from remotely manipulating tags, to methods of code hiding, and download manipulations.

Remote Code Execution

• Likelihood: Low

• Complexity: High

• Impact: High

Attackers might find zero-day vulnerabilities allowing them to execute code remotely on the PLC. Another potential approach to execute code remotely is the installing of patched firmware on the PLC, which allows the attacker to execute arbitrary code on the PLC. 

This attack is sophisticated because it requires an attacker to have deep understanding of the specific controller being targeted and gives the attacker firm control over the industrial process managed by the victim PLC. We’ve demonstrated this many times before, for example with CVE-2021-34566 on WAGO PFC PLCs.

Logic Download

• Likelihood: High

• Complexity: Low

• Impact: High

In many cases, attackers can easily use commercial engineering workstation software to perform a download procedure on the device and essentially modify the logic on the PLC to alter the physical process it controls. 

Modern PLCs have password protection and other security features, but from our experience, sometimes they are not enforced or can be bypassed, for example as we demonstrated in our research on Schneider M221 PLCs.

Code Hiding

• Likelihood: Low

• Complexity: High

• Impact: High

With this kind of attack method, attackers may undermine the PLC’s logic by switching the program logic (bytecode) bundled inside the PLC and decoupling it from the real source code programmed by an industrial engineer. This technique is also showcased in a different blog post called The Old Switcheroo by our team in a much more elaborate manner. From a high level point of view, this method could be carried out in two ways:

• EWS Compiler Intervening: Meddling with the compiling stage of the PLC program source code

• Download Process “DIY”: Build “your own'' download process by implementing the entire protocol stack. In Team82’s Evil PLC Attack, we implemented such protocol schemes for PLCs from various vendors to demonstrate a scenario in which a PLC attacks an engineering workstation.

Tag Manipulation 

• Likelihood: High

• Complexity: Low

• Impact: High  

A "tag" refers to a label or identifier associated with a specific data point or variable within a PLC. Tags are used to uniquely identify and represent various process variables, equipment statuses, or other data points that are monitored or controlled by a SCADA system. 

This enables engineers and operators to control a certain physical process just by modifying these parameters without changing the entire logic. When we read or write to tags, we usually refer to the process of Data Acquisition by which we exchange information with the SCADA system.

Remotely controlling tag values on the PLC while running is a feature dedicated for control over the industrial process from remote hosts. Attackers can leverage this feature to their advantage in intervening and capturing control over an industrial process. 

In our factory we use the ControlLogix5000 PLC. These controllers communicate and exchange data over CIP protocol.

This kind of attack requires a CIP client able to communicate with remote CIP servers. We will in this case make use of a helpful, simple to use, python library called pylogix. With this library we created a simple script representing what might attackers use to harm an industrial process.

As can be seen our simple script created massive disorder in our factory and disrupted our assembly line.

Key Takeaways

We started this two-part blog series by building our own virtual factory with an assembly line. We presented the different components of an industrial setting and explained their importance in an industrial process. To complete this series we shifted our focus to the security aspect of OT and automation, and surveyed multiple attack scenarios against industrial processes. These attacks range in sophistication and probability, and help us get a better understanding about this highly important realm in the aspect of cyber security.

This information should be especially useful for IT cybersecurity staff who are new to OT. Using this type of modeling and scenario helps visualize where risk may need to be managed and how actual exploits can interrupt or disrupt processes managed by OT equipment and impact the bottom line.