Defeat Magic with Magic: A Novel Ransomware Attack Method to Dynamically Generate Malicious Payloads Based on PLC Control Logic

Abstract

The Industrial Control System (ICS) is a public facility that provides services to lots of users; thus, its security has always been a critical factor in measuring its availability. Recently, a new type of attack on ICS has occurred frequently, which realizes the extortion of users by invading the information domain and destroying the physical domain. However, due to the diversity and unavailability of an ICS control logic, the targets of such attacks are usually limited to PCs and servers, leaving more disruptive attack methods unexplored. To contribute more possible attack methods to strengthen the immunity of ICS, in this paper, we propose a novel ransomware attack method named Industrial Control System Automatic Ransomware Constructor (ICS-ARC). Compared to existing ICS ransomware, ICS-ARC can automatically generate an International Electrotechnical Commission (IEC) compliant payload to compromise the Programmable Logic Controller (PLC) without a pre-known control logic, dramatically reducing adversary requirements and leaving room for error. To evaluate the attack capability of ICS-ARC, we built a tap water treatment system as the simulation experiment target for verification. The experimental results determine that ICS-ARC can automatically generate malicious code without the control logic and complete the attack against target PLCs. In addition, to assist the related research on future attacks and defenses, we present the statistical results and corresponding analysis of PLC based on Shodan.

1. Introduction

The Industrial Control System (ICS) is widely used in power, water, oil, and natural gas industries, making our modern life possible. Much of what we commonly perceive as material goods have remained largely unaffected by malware, even as more and more security incidents often make headlines. Some high-profile ICS attacks, such as the Stuxnet [1], Black-Energy [2], Duqu [3], and Havex [4], have been targeted attacks to sabotage rather than for financial profit. However, most criminals on the Internet do not have a state-sponsored background but are encouraged by economic motives. The ransomware attack, which encrypts files and disrupts system operations for monetary extortion, has become one of the most popular monetization methods in cybercrime.

So far, ICS networks have avoided being the target of such cybercrimes but not because they are inherently immune to such attacks or more secure. In fact, compared with the traditional Information Technology (IT) system, the ICS is less secure and seems no more improved over the past few decades. The only reason for this fragile peace is that the attacker has not found a profitable model for the specific industrial environment. In the traditional IT system, data are the most critical asset. The significant increase in ransom payouts from enterprises [5] also proves the expansive success of ransomware. In most ICS areas, such as water treatment, electricity, natural gas, and oil, the most critical is not data but rather the continued availability and safe operation of their facilities [6]. A malfunction threat or attack as shown in Figure 1 [7,8] may cause substantive damages with economic and even life losses in the real world.

More and more attackers have recognized the value of targeting organizations with little tolerance for downtime [9]. With higher financial profits in mind, it is foreseeable that the ICS will be the next target for ransomware. However, existing ICS ransomware mainly focuses on Personal Computers (PC) and servers (IT-focused), which has disruptive impacts on operations with limited effect [10]. Although some ICS ransomware research (ICS-focused) [6,11] can compromise ICS equipment, the control logic is always taken as prior knowledge. The control logic runs in ICS controllers, such as the Programmable Logic Controller (PLC), which dictates how the ICS operates and interacts with the physical world. With control logic, the adversary can construct sophisticated attack payloads and achieve a precise strike on the target. However, due to the peculiarities of the ICS environment, the control logic is usually unavailable. In most cases, only the most potent adversaries, e.g., insiders or nation states, can have the control logic in advance. The “last mile”, how to implement ransomware attacks without a pre-known control logic, is still under struggle.

To address such a challenge, we present ICS-ARC (Industrial Control System Automatic Ransomware Constructor), which is a novel ransomware attack method that targets PLCs. In contrast to existing ransomware, ICS-ARC can automatically construct malicious payloads and launch attacks without a pre-known control logic, dramatically reducing adversary requirements and leaving room for error. ICS-ARC proceeds with a ransomware attack in four steps. The first step is to download the control logic bytecode from the target PLC and decompile it into a logical model. Next, find the correct mapping between specific ICS devices and variables by model checking. Again, instantiate the ransomware attack payload for the target PLC with the correct mapping. The malicious payload can be triggered at a specified time on the specified device. Finally, upload the malicious code to the target PLC. As long as the adversary is familiar with the PLC architectures and communication protocols, ICS-ARC can automatically complete the subsequent vital steps and compromise the PLC in most real-world ICSs. Furthermore, compared with other ICS malware, such as the Stuxnet [12], a precompiled payload is also unnecessary.

We make the following contributions:

• The first general ransomware attack method can automatically generate malicious payloads and compromise most ICSs.
• A general-concept method to find a satisfactory mapping between PLC variables and extension equipment can be extended further to implementing ICS malware.
• A survey of PLCs about this kind of attack is currently discoverable on Shodan.
• Recommendations for ICS ransomware attacks are provided to aid future research and defenses.

In our previous work [11], we demonstrated ICS-BROCK, the first full-fledged ICS ransomware that can compromise ICSs in the real world. ICS-BROCK has a complete set of attack flow, such as breaking through physical restrictions with BadUSB, uploading malicious code through protocol reverse, and infecting and encrypting ICS equipment. However, the primary purpose of ICS-BROCK is to demonstrate that ICS ransomware attacks are actual in the real world by compromising a specific PLC. A precompiled malicious code is required, and some specific characteristics of the target PLC are utilized during the attack process of ICS-BROCK. ICS-ARC is an extension and improvement based on ICS-BROCK. Different from ICS-BROCK targeting specific devices, ICS-ARC tries to explore a general ransomware attack method.

The remainder of this paper is organized as follows. Related work in ICS ransomware and security is presented in Section 2. Section 3 introduces the background of industrial control systems, and Section 4 provides the system model. The attack assumptions and implementation details are explained in Section 5. To evaluate the effectiveness of ICS-ARC, we built a tap water system testbed in Section 6. Finally, defenses against such attacks are suggested in Section 7, and conclusions are summarized in Section 8.

2. Related Work

Ransomware is not a new cyberattack method, but it has evolved significantly over the years as related technologies have become more focused and sophisticated. The first known ransomware was observed in 1989, which the AIDS Trojan distributes. Despite the novelty of such an attack method, it was unsuccessful for various reasons [13]. Since then, ransomware attacks have grown increasingly ambitious and have mounted several high-profile, highly destructive attacks. The attack against Colonial Pipeline caused significant disruption and prompted concerns about the ICS security [14,15]. Shortly after this, Ireland’s national health service, the Health Service Executive, was hit with a ransomware attack that forced it to cancel thousands of appointments [16]. The ransomware attack is becoming a significant threat to enterprises and large organizations.

Although there have not been any known ransomware attacks on PLCs in the real world, researchers have developed proof-of-concept attacks. The first known example of ICS ransomware against PLCs was LogicLocker [6], which can lock the PLC and replace programs with a logic bomb. Despite the novelty of Logic Locker, it has not explained more implementation details and depends on weak authentication vulnerabilities of specific PLC types. The first known full-fledged ICS ransomware, ICS-BROCK [11], presents some possible solutions to the physical isolation challenge and reduces reliance on vulnerabilities. However, ICS-BROCK required a precompiled payload based on the control logic, which is not typical for most ICS environments.

On the PLC exploit side, Stuxnet is the first known example to target PLCs, which has destroyed Iranian centrifuges by tampering with the rotation speeds [17]. The PLC-Blaster [18] can inject malicious code into PLC but focuses on destruction rather than extortion. McLaughlin first described the requirements for extending automated exploit frameworks to perform attacks against PLCs in [19]. The SABOT can dynamically generate attack payloads with little or no prior knowledge [20]. Valentine et al. researched PLC code layer vulnerabilities and proposed the PLC Security Framework (PLC-SF) [21]. Beresford [22] found vulnerabilities in Siemens S7Comm protocol for a replay attack, which is also a reference of our research. Klick [23] proved that PLC could act as a proxy or scanner and be used by attackers to attack devices in a local network. There are also some DDoS attacks against common industry protocols [24] (e.g., insecure checksum validation during the update process [25]), which can cause an interruption on PLCs. Many automated exploit frameworks such as Metasploit [26] and Canvas [27] have been extended to attacks against PLCs. Alsabbagh [28] targets the S7-300 PLC by injecting a Time-of-Day (TOD) interrupt code, which interrupts the PLC at a specific time the attacker wishes. Langendörfer [29] launched a stealth program injection attack on PLC with only a tiny modification. Castellanos et al. [30] proposed a set of tools to symbolically analyze the software of PLC guided by an information flow analysis.

All these above works are somewhat relevant to ours. However, this work is the first evaluation of these techniques.

3. Background

The ICS bridges the virtual and natural worlds with many physical components [31], such as sensors and controllers, making ICS interact with the physical system and information system [32]. The physical apparatus in which the ICS resides is called the plant. Control systems can be decomposed into three elements within the plant: control inputs, control outputs, and control logic. Control inputs are used to communicate the status with the plant. For example, temperature, level, or pressure sensors can detect and transmit physical states. Others are human-driven, such as switches, dials, and buttons. ICS usually sends control output signals to some external devices affecting the physical world. For example, turn on/off a light, open/close valves, or raise/lower temperature. Control logic is essentially a broad virtual concept that drives physical machinery and determines the overall operation process of ICS. To describe accurately, in this paper, we assume the control logic is the software control logic that works in the PLC, which can repeatedly receive, compute and send the control signals.

The control logic for a sequential process is codified as a Boolean circuit set and then compiled into the PLC’s native instruction set architecture (ISA). An ISA defines a family of implementations, such as the supported instructions, data types, registers, fundamental features, and the input/output model. All PLC control logic programs must be compiled into ISA-ruled machine language before being executed. Although the ISA of PLC varies between manufacturers, most are equivalent to the International Electrotechnical Commission (IEC) 61131-3 standard for the Instruction List (IL) programming language [33]. IEC 61131 is an open international standard for PLCs, and the third part (IEC61131-3) deals with basic software architecture and programming languages of the control program within PLC.

PLC is the primary operating carrier of control logic which can be modularized by internal CPU, instruction and data memory, input and output unit, power supply module, and digital-analog [34]. The input/output module receives (input)/sends (output) multiple electrical or electronic signals and controls or supervises almost any mechanical and electrical system. There are three layers of the PLC: the programming layer, the firmware layer, and the hardware layer. The programming layer is the primary interaction model between the operator and the PLC. The firmware layer is the connection between the programming and hardware layers, which is often referred to as the operating system of an embedded device. The hardware layer of PLC, as with the personal computer, includes the microprocessor, memory (volatile and nonvolatile), and bus. The PLC microprocessor can receive the input from the operator and collect the status data from filed equipment simultaneously. Extension loads are connected to PLC input/output modules. Most modern PLCs have the function of network communication and use BUS cables, RS-232 interfaces, USB interfaces, and Ethernet ports for communication links.

The unique characteristics of PLCs determine that it is an operational technology system (OT system), not an Information Technology system (IT system) similar to PCs and servers. An IT system is necessary for monitoring, managing, and securing enterprise functions, while OT is for connecting, monitoring, managing, and securing industrial operations. IT is centered on front-end informational activities, while OT is focused on back-end production (machines). IT is responsible for the informational infrastructure, while OT is responsible for the equipment on industrial sites. These significant differences are challenges of ICS-focused ransomware attacks, which is also one of our focuses in this paper. Subsequently, we will continue to discuss ICS-ARC by providing the system model in the next section.

4. The System Model and Control System

Sequential control systems are the most classic control systems which drive the plant with several discrete processes. In this paper, we construct the system model based on the sequential control system as shown in Figure 2. The plant is an example physical apparatus with several sensors and actuators. Actuators are extension devices such as valve, motor, mixer, and cam, which are controlled by the output values $y_1,y_2,y_3,\dots ,y_n$. A device is ON/OFF, while the corresponding value is set to ⊤ (True)/⊥ (False). Sensors can detect plant status such as temperature, water level, pressure, and rotating speed. The input values $u_2,u_3,u_4,\dots ,u_n$ are specific state switches of the plant if the current status of the plant is at $u_i$ or includes it, then $u_i=\top$. A start signal is sent to the PLC via $u_1$, and all variables are OFF before $u_1$ is ON ($u_1=\top$).

When the entry process completes ($u_1=\top$), some actuators will be set to ON ($y_i=\top$), triggering new state switches and processes further. For example, we assume an example control system for a simplified temperature regulator consisting of a heater, a cooler, and a temperature sensor. The heater and cooler are controlled by the out variables $y_1$ and $y_2$, respectively. The temperature sensor can detect the temperature at low, high, or expected levels (corresponding to input variables $u_2,u_3,$ and $u_4$, respectively). A start button corresponds to the input variable $u_1$. The temperature regulator system follows a simple process: the heater is ON at the low-temperature level, and the cooler is ON at the high. The example system’s process and control logic (abstraction level) is shown in Figure 3.

Then, a unified description of the ransomware attack model is carried out: the PLC will operate normally until the delay time, which the adversary sets, leading to disruption. For example, in the temperature regulator system, disruption can cause actuators (heater and cooler) to go out of control ($y_i=\perp$), that is,

$$y_1\left(t\right)=\left\{\begin{array}{c}(u_1\vee y_1)\wedge \neg u_3,t\notin {\mathcal{T}}_{\alpha },\hfill \\ \perp ,t\in {\mathcal{T}}_{\alpha }\hfill \end{array}\right.$$

(1)

$$y_2\left(t\right)=\left\{\begin{array}{c}(u_1\vee y_2)\wedge u_4,t\notin {\mathcal{T}}_{\alpha },\hfill \\ \perp ,t\in {\mathcal{T}}_{\alpha }\hfill \end{array}\right.$$

(2)

${\mathcal{T}}_{\alpha }=[t_s,t_e]$ is the duration time of ransomware attack, where $t_s$ represents the start time, $t_e$ represents the end time and $y_i\left(t\right)$ presents the output signal at time t.

Not shown in this example, a timer is a variable that presets delay time between the input and output variables, which may cause an inversion of the value. Sensors can be replaced with timers under certain conditions, such as the ransomware attack payload construction. The following section will discuss the sense of timer in attack implementation.

5. Attack Assumptions and Implementation

The specific process of ICS-ARC is depicted in Figure 4. ICS-ARC first downloads the control logic bytecode from the suspect PLC and converts it to a set of constraints on variables, such as local, input, and output variables. Next, ICS-ARC translates constraints to a logic model with a NuSMV model checker and attempts to find a correct mapping from variable to device. Once the correct mapping is found, ICS-ARC can construct the payload and upload it to the PLC.

5.1. Problem Formulation

Consider that an adversary may wish to disrupt the plant when the delivery time exceeds, such as stopping the PLC or making a crash on extension devices. Unfortunately, the adversary does not know how to specify to the PLC which variable is meant by “Stop Button” or “Actuator X”. Most PLCs do not necessarily label their I/O devices with semantically meaningful names such as “Heater”, “Cooler”, “Valve”, etc. Instead, PLC uses memory addresses to read/write values from/to sensors and physical devices. We refer to this set of address names as ${\mathcal{V}}_{\mathcal{M}}$. Since the adversary does not know the semantics of the names in ${\mathcal{V}}_{\mathcal{M}}$, we prefer to use the set of input variables ${\mathcal{V}}_{\mathcal{A}}=\{StartButton,Actuator1,Actuator2,\dots \}$ as an alternative.

Here raises the challenge, how can the adversary find a correct mapping between ${\mathcal{V}}_{\mathcal{M}}$ and ${\mathcal{V}}_{\mathcal{A}}$ to construct the malicious payload? To find a correct mapping from ${\mathcal{V}}_{\mathcal{A}}$ to ${\mathcal{V}}_{\mathcal{M}}$, ICS-ARC requires a piece of common-sense facts about most plants, such as “When the Start Button is pressed, some actuators start” and “All actuators are OFF until the Start Button is ON”. These statements are encoded into a behavioral specification of the target plant. When the PLC control logic is available, ICS-ARC will attempt to locate the device addresses that behave the same as such behavioral specifications under the rule of the PLC control logic.

For the PLC control logic implementation, we construct a model $\mathcal{M}$ from the control logic $\mathrm{Var}\left(\mathcal{M}\right)={\mathcal{V}}_{\mathcal{M}}$, and we perform a checking analysis to find the mapping $\mu :{\mathcal{V}}_{\mathcal{A}}\to {\mathcal{V}}_{\mathcal{M}}$. We assume the $\mu$ has a correct mapping, and all properties can be mapped under the control logic. For example, the above property, “When the Start Button is pressed, some actuators start” will be checked as “When $u_1=\top$, then $y_1=\top ,y_2=\top ,\dots ,y_n=\top$”, under the mapping

$$\mu =\{\mathrm{Start}\mathrm{Button}\mapsto u_1,\mathrm{Actuators}\mapsto \begin{array}{c}{y}_1\hfill \\ y_2\hfill \\ ⋮\hfill \\ y_n\hfill \end{array}\}$$

(3)

Thus, for every temporal logic formula $\mathcal{A}(\mathrm{Var}\left(\mathcal{A}\right)\subseteq {\mathcal{V}}_{\mathcal{A}})$, if $\mathcal{A}$ mapped by $\mu$ holds over the $\mathcal{M}$, we would obtain,

$$\mathcal{M}\vDash \mu /\mathcal{A}$$

(4)

which means the ${\mathcal{V}}_{\mathcal{A}}$ can map the ${\mathcal{V}}_{\mathcal{M}}$.

5.2. Theoretical Feasibility Verification

Correct mapping from PLC code variables to extension devices is necessary for the ransomware attack, which is related to a piece of common-sense specifications. We assume a specification is an order list of properties including the following properties: input list, output list, and a Computational Tree Logic (CTL) formula $\mathcal{A}$.

The CTL formula $\mathcal{A}$ is defined over names given after the input and output list, where

$$\{input-list\}\cup \{output-list\}\subseteq {\mathcal{V}}_{\mathcal{A}}$$

(5)

For example, the specification, “When the start button is pressed, the actuator X starts”, as the following CTL $\mathcal{A}$:

$$StartButton\Rightarrow \mathtt{AX}Actuato{r}_x$$

(6)

Since the state in the output-list is always derived from the input-list, that is,

$$\{input-list\}\Rightarrow \mathtt{EF}\{output-list\}$$

(7)

Thus, we can obtain at least one mapping that satisfies the condition in most cases. Despite one or more mappings always meaning some logical conflicts, ransomware attacks vary from other malware attacks. For ransomware attacks, every mapping is correct, which can disrupt the ICS while the delivery time exceeds.

However, for a precise or stealthy attack such as the Stuxnet, more intelligence about the target plant is required, such as “The plant includes one valve and one motor”, “When the Start Button is pressed, the valve opens”, and “The motor starts after the valve opens”. The more target behavior specifications, the more complete the mapping. Although ICS-ARC can complete such an attack with more information, common sense facts are sufficient for a ransomware attack.

5.3. PLC Variables Decompilation

To construct the model $\mathcal{M}$, we need to decompile the bytecode-level control logic of PLC into variables. We perform this decompilation in two steps: (1) Convert the bytecode-level control logic to an intermediate set of constraints $\mathcal{C}$ on input, local, output, and timer variables. (2) Translate $\mathcal{C}$ to $\mathcal{M}$ with the NuSMV model checker [35].

For step 1, the PLC code conforms to the IEC 61131-3, which defines the standard of PLC language [36]. According to the PLC code’s control flow graph (CFG), we can obtain the constraints $\mathcal{C}$ via the symbolic execution of the bytecode. For example, in the temperature regulator system, we assume the symbolic accumulator as $\alpha$, and the symbolic accumulation of the refrigeration is shown in

Table 1. Example accumulation of a constraint.

Desc.	Bytecode	Accumulator $\mathit{\alpha }$	Stack
-	-	⊤	-
And $u_4$	A $u_4$	$u_4$	-
Nested And	A (	⊤	$u_4:\wedge$
And $u_1$	A $u_1$	$u_1$	$u_4:\wedge$
Or $y_2$	O $y_2$	$u_1\vee y_2$	$u_4:\wedge$
Pop stack	)	$u_4\wedge (u_1\vee y_2)$	-
Store $\alpha$ to $y_2$	=$y_2$	⊤	-

.

$$\mathcal{C}\leftarrow \mathcal{C}\cup \{y_2\leftarrow u_4\wedge (u_1\vee y_2)\}$$

(8)

For step 2, we will translate the set of constraints from step 1 into a control logic model, which the NuSMV model checker can evaluate. NuSMV takes definitions of labeled transition systems with states consisting of state variables. We declare state variables in $\mathcal{M}$ with the $\mathtt{Var}·:\mathtt{boolean}$ expression. Variables are initialized with $\mathtt{init}(·)$ expression and updated with $\mathtt{next}(·)$ expression. A boolean variable can be translated to ⊤, ⊥, another expression or a nondeterministic assignment $\{\top ,\perp \}$ by the model checker.

To construct the NuSMV model $\mathcal{M}$ from the constraints $\mathcal{C}$, we have defined three translation rules as shown in

Table 2. Constructing $\mathcal{M}$ from constraints $\mathcal{C}$.

Constraint	NuSMV Model $\mathcal{M}$
$\mathtt{input}u$	$\mathtt{VAR}$ $u:\mathtt{boolean};$ $\mathtt{ASSIGN}$ $\mathtt{init}\left(u\right):=\perp ;$ $\mathtt{next}\left(u\right):=\{\perp ,\top \};$
$\mathtt{output}\mathtt{or}\mathtt{local}y$	$\mathtt{VAR}$ $y:\mathtt{boolean};$ $\mathtt{ASSIGN}$ $\mathtt{init}\left(y\right):=\perp ;$ $\mathtt{next}\left(y\right):=\alpha ;$
$\mathtt{timer}t$	$\mathtt{VAR}$ $t:\mathtt{boolean};$ $t_e:\mathtt{boolean};$ $\mathtt{ASSIGN}$ $\mathtt{init}\left(t_s\right):=\perp ;$ $\mathtt{next}\left(t_s\right):=\alpha \wedge (t_e\vee t_s)?\top :\perp ;$ $\mathtt{init}\left(t_e\right):=\perp ;$ $\mathtt{next}\left(t_e\right):=\perp$

. Input variables are initialized to ⊥ and updated to nondeterministic assignment $\{\top ,\perp \}$. Output and local variables are initialized to ⊥ and updated according to the input control logic expression $\alpha$. Timer variables are different from others, which require an extra bit of states. A PLC timer has a starting state $t_s$ and an expiration state $t_e$, both of which are initialized to ⊥. The starting state $t_s$ is updated to ⊤ when the input expression $\alpha =\top$ continuously in the timer’s preset time duration. Furthermore, the process includes several other steps, including preprocessing bytecode to rewrite vendor-specific instructions. Full details can be found in [37].

5.4. Variable to Device Mapping and Payload Construction

ICS-ARC attempts to find a correct mapping $\mu$ from every specification $\mathcal{A}$ to the control logic model $\mathcal{M}$, that is,

$$\mathcal{M}\vDash \mu /\mathcal{A}$$

(9)

The search algorithm will attempt to find the satisfying mapping of the specification item by item. If there is no satisfying mapping for the current specification, the previous mapping will search again for another. If no more satisfying mappings are found, the algorithm will exit. The basic search process for a satisfying mapping ${\mu }_{\mathcal{S}}$ is shown in Algorithm 1.

Algorithm 1: SearchMapping

Payload construction is another main task of ICS-ARC when a ${\mu }_{\mathcal{S}}$ has been found. ICS-ARC will instantiate a ransomware attack payload with timer variables and use ${\mu }_{\mathcal{S}}$ to map names in the payload into the PLC control logic. The ransomware attack payload predefines common-sense specifications such as “After the Start Button is pressed, some actuators will OFF after a specific time”, and “Some actuators will not be ON after a specific time”. Once a correct mapping ${\mu }_{\mathcal{S}}$ is found, the payload is generated automatically under ${\mu }_{\mathcal{S}}$ and over names in ${\mathcal{V}}_{\mathcal{M}}$. We assume these over-name variables in ${\mathcal{V}}_{\mathcal{M}}$ as $\mathcal{Y}$. For each $y_i$ in $\mathcal{Y}$, ICS-ARC adds a timer t for $y_i$, that is,

$$y_i\leftarrow y_i\wedge t$$

(10)

The timer t is the ransom delivery time. Before the timer expires, the state variables will not be affected. However, once it expires, the values of all state variables will change to constant and cannot be altered. After that, the payload will be recompiled into bytecode and uploaded to the target PLC.

5.5. Simulation and Verification

To prove the validity of this novel method, we build a house temperature control system with an Arduino controller to witness this attack method’s impact in the real world. The Arduino is open-source hardware for building digital devices and has installed the OpenPLC software to emulate an actual PLC device. The OpenPLC project was created following the IEC 61131-3 standard, which defines PLCs’ basic software architecture and programming languages. Figure 5 has shown the simulation device.

The house temperature control system will adjust the temperature based on the indoor average and expected temperatures. The average indoor temperature is affected by both the outdoor temperature and the temperature control system. This simulation will set the expected temperature constant (23 to 25 deg C). The knob emulates the outdoor temperature and will be changed in real time. The Arduino emulates the PLC (the controller) and LED lights to emulate the status of control signals. We assume the light is on with 1 and off with 0. All states of lights are shown in

Table 3. States of lights.

	LED 1	LED 2	LED 3	State
Value	1	1	1	Initial State
Value	0	1	1	Heater is ON
Value	1	0	1	Heater is OFF
Value	1	1	0	Cooler is ON

.

A typical operating temperature control system is shown in Figure 6a, and the control signal is shown in Figure 7a. Normally, the indoor temperature fluctuates synchronously with the outdoor temperature change. When the indoor temperature is lower than expected, the heater will be turned on, and the LED light state is shown in Figure 8a.

Then, we deploy the ransomware attack into the system and set the delivery time to 60,000 s. Figure 6b shows the indoor temperature under attack, and the control signal under attack is shown in Figure 7b.

Before delivery time, the system operated as usual, but everything changed when the delivery time was exceeded. The indoor temperature no longer remains in a constant range close to the expected temperature. However, it drops rapidly, eventually approaching the outdoor temperature and synchronizing with it. The control signal no longer changes periodically but remains at zero, which means the controller has stopped working. To the Arduino, the knob can control LED lights as usual after injecting the malicious code before the delivery time expires. However, all LED lights will be turned on after delivery, and the knob can never control them again. The result has shown that our attack can work well in this evaluation, and the result is shown in Figure 8b.

In this section, we have simulated the PLC by Arduino. The result shows that the novel method can compromise the target without physical knowledge. The next step is to evaluate a natural ICS environment and deploy the ICS-focused ransomware in a real PLC.

6. Evaluation in the Real World

We have built a complete tap water treatment system based on the natural ICS environment to evaluate the actual effect of the ICS-focused ICS ransomware.

6.1. Introduction of the Tap Water Treatment System

Public drinking water systems use various water treatment methods to provide safe drinking water for their communities. The most common steps in water treatment used by community water systems (mainly surface water treatment) include:

• Coagulation and Flocculation. The first step in tap water treatment is to add chemicals to neutralize the negative charge of dirt and other dissolved particles in the water.
• Sedimentation. The particles bound with the chemicals will settle to the bottom of the water due to their weight, which is called sedimentation.
• Filtration. This step will filter the water on top to remove dissolved particles, such as dust, parasites, bacteria, viruses, and chemicals.
• Disinfection. After the water has been filtered, a disinfectant may be added to kill any remaining parasites, bacteria, and viruses.
• Storage. This step will store the clear water in the pumping station and transport the water to homes and businesses.

All the above steps are implemented in the tap water treatment scene we built and can generally run under the control of PLCs. The detail of this system is shown in Figure 9 and Figure 10a,b. In addition, this work uses SIEMENS S7-300 PLC, one of the most widely used devices in ICSs [25], as the controller and target.

We choose the water storage stage as the testbed based on practical demonstration effect, efficiency, repeatability, and potential danger (chemicals). It is worth mentioning that the principles and processes are similar no matter which stage of the water treatment process is. The water storage stage is mainly used to store clear water and pipe it into houses and businesses. Under normal circumstances, the operator can adjust the storage tank’s water level according to the situation. The water storage process is shown in Figure 11, which is controlled by the Proportional-Integral-Derivative (PID) controller. The PID controller is a control loop mechanism employing feedback that is widely used in industrial control systems and a variety of other applications requiring continuously modulated control [38]. In practical terms, PID automatically applies an accurate and responsive correction to a control function. The overall control function of PID is

$${\displaystyle u\left(t\right)=K_{\mathrm{p}}e\left(t\right)+K_{\mathrm{i}}{\int }_0^{t}e\left(\tau \right)\mathrm{d}\tau +K_{\mathrm{d}}\frac{\mathrm{d}e\left(t\right)}{\mathrm{d}t},}$$

(11)

where $K_{\mathrm{p}},K_{\mathrm{i}}$, and $K_{\mathrm{d}}$, all non-negative, denote the coefficients for the proportional, integral, and derivative terms, respectively (sometimes denoted P, I, and D). The specific parameter values of the PID controller are shown in

Table 4. Parameter Values of the PID Controller.

Parameter	${\displaystyle {\mathit{K}}_{\mathbf{p}}}$	${\displaystyle {\mathit{K}}_{\mathbf{i}}}$	${\displaystyle {\mathit{K}}_{\mathbf{d}}}$
Value	1.2	22	0.02

.

In the case of the regular operation of the system, we make random adjustments to the expected water level every 3 min, as shown in Figure 12. The measured water level will eventually reach the expected level and remain stable after a short fluctuation, as shown in Figure 13a. The error value shown in Figure 14a is the difference between the measured and expected water levels, which will eventually be 0 as the water level is adjusted.

Then, we try to deploy ICS-ARC to compromise the PLC. We set the delivery time to 15 min and adjusted the expected water level as shown in Figure 12. The measured water level and error value are shown in Figure 13b and Figure 14b. For the first 15 min, the system works normally. However, when the malicious payload is triggered, the measured water level will not change anymore, and the error value will change with the expected water level.

The results empirically demonstrate the feasibility of our method. In addition, out of control is the not only choice to a specific target, which can also tamper with the control signal to cause a life-threatening accident such as overflow.

6.2. Other Additional Technical Issues

We present a novel method that can automatically generate malicious code against the PLC in this work. However, there are still some additional technical issues we have not mentioned. Two of most essential are: (1) how to download/upload the PLC program, and (2) how to prevent the malicious code from being cleaned. Issue 1 is that normal functions come with the PLC, and issue 2 is always realized through the PLC locking function. However, all of the issues vary between PLC vendors. Different PLC types may achieve download/upload/locking functions with different ICS protocols, and most are private. For example, Schneider PLCs implement these functions with the Modbus protocol, while SIEMENS PLCs utilize the S7comm protocol. Nevertheless, the specific process is very similar, as shown below.

• Run the specific PLC type in local.
• Operate the PLC with original software (e.g., Download/Upload/Lock).
• Sniff the traffic to reverse the protocol.
• Implement the process by programing language.

In our previous work [11], we have reversed the PLC locking mechanism in the S7 protocol and implemented the attack. Usually, the operator will not choose to re-flash the PLC because it will cause a shutdown. A shutdown always means significant economic losses. These operations are based on regular protocol traffic and require multiple traffic interactions [39].

6.3. Statistics of Vulnerable Devices on Shodan

With the development of technology, more and more PLCs have been exposed to the Internet. Network discovery engines such as Shodan can find them easily [40]. Different PLCs’ communication protocols are different, meaning different ports. For example, the default port of the Modbus/TCP protocol is TCP port 502, while the S7comm protocol is TCP port 102.

Table 5. Default ports and communication protocols of PLCs.

Protocols	Default Port No.	TCP/UDP	Private/Public	Manufacturers
S7Comm	102	TCP	Private	SIEMENS
S7Comm Plus	102	TCP	Private	SIEMENS
CIP	TCP 44818 UDP 2222	TCP&UDP	Public	Rockwell Allen Bradley
Ethernet/IP	TCP 44818 UDP 2222	TCP&UDP	Public	Rockwell Allen Bradley
OMRON	9600	TCP	Private	Omron
MELSEC-Q	4999 5001 5002	TCP	Private	MITSUBISHI
GE-SRTP	18245 18246 57176	TCP	Private	GE
Modbus	502	TCP	Public	Schnider (Core functions are private.)

shows the mainstream PLC’s communication protocol and corresponding default port.

Moreover, we make statistics on PLCs with Shodan. There are nearly 520,000 devices (some are honeypots) on the Internet, and

Table 6. The top 5 countries of ICS devices.

Order of List	Countries	Numbers
1	United States	224,816
2	Germany	50,352
3	China	46,313
4	Korea	16,246
5	Canada	16,212

has shown the top 5 countries.

The United States accounts for about 40% of the total, most of which are ICS devices. According to our estimates, more ICS devices will be connected to the Internet in the future. In addition, attack methods are becoming increasingly diverse, and the hacker can even start an attack from the cable. Assuming these PLCs do not have access control, a large-scale automated ransomware attack can be carried out by the method proposed in this paper only by performing a reverse analysis of specific protocols for different PLCs.

7. Defenses

For ICS-ARC-like attacks in ICS, we try to explore defense countermeasures from the specific attack flow of ICS-ARC. In this work, we provide corresponding defense methods for different stages of the attack process, that is, border security, access security, and PLC security, as shown in Figure 15.

For border security, although some ICS malware such as Stuxnet has shown how to break through the border, physical isolation is still the most straightforward way to defend against ransomware attacks. In the age of Industry 4.0, more and more PLCs are connected to the Internet, and it is foreseeable that this is also one of the future development trends of ICSs. To detect the adversary outside the border with protection techniques such as a honeypot network would be an effective defense method.

Industrial Honeypots and Honeynets. The concept of a honeypot has been used in general-purpose intrusion detection systems for a long time with well-recognized contributions in revealing and analyzing cyber attacks [41]. An industrial honeypot is used with the purpose of being attacked and possibly compromised, which can attract attackers and deceive them into thinking they gained access to the real ICS [42]. Two or more honeypots implemented on a system form a honeynet [43]. Many traditional security mechanisms such as Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), firewalls, antivirus, and anti-malware can be utilized. However, all these solutions cannot transparently allow security researchers to observe and analyze how attackers perform attacks and discover their behaviors. Honeypots can be integrated with firewalls and IDSs to form an IPS to capture all the information about attackers, study all of their actions, and develop ways to improve system security and prevent attacks in the future [44]. Through industrial honeypots, unknown attacks such as ICS-ARC can be captured while “hiding” the real target, further enhancing the ICS security based on the captured attack details.

For access security, communication with the PLC is a prerequisite for all ICS-ARC-like attacks, which means the access manager can be an effective defense method once the border has been compromised. Access security is currently the most widely used industrial security solution and is suitable for protecting against ICS-ARC-like attacks. Among the existing access security solutions, some are PLC’s functions, such as PLC Access Control Lists (ACL), and some are commercial products such as industrial gateways and firewalls.

PLC Access Control List. The ACL is a cost-effective defense method available in almost all PLCs which can prevent attackers from communicating with PLCs and further thwart ICS-ARC attacks. For example, ICS-ARC-like attacks always start from a third-party device, which may not be in the ACL. In that case, ACL can effectively prevent further attacks by ICS-ARC. Even though the ACL can restrict access sources by a safelist, it is not suitable for a dynamic ICS environment, and the safelist also needs to be updated frequently. Commercial products such as industrial gateway and access manager would be a better choice to overcome these shortcomings.

Industrial Gateway and Access Manager. An industrial gateway is used to interface between networks that support different protocols, which makes communication possible between the many resident architectures and protocols in both the IT and OT domains. On the other hand, the industrial gateway is another defense method of border security. An industrial gateway contains functionality such as an access manager, field device collection, parameter data monitoring, protocol converters, impedance matching devices, fault isolators, or signal translators necessary to provide system interoperability and access security. ICS-ARC-like attacks presuppose access to the ICS network, which industrial gateways can also prevent. Moreover, the industrial gateway can also monitor the parameter data of PLC instructions, such as uploading and downloading the PLC control logic. Once sensitive parameters are detected at the traffic level, attacks can be blocked immediately.

There are many commercial gateways, such as ABB and B&B, which can provide more comprehensive access security protection and a more friendly interface. Moreover, there are also some academic types of industrial gateway architectures, such as SDN-based industrial security gateway [45], software-defined industrial gateway [46], and hardware-based industrial gateway [47].

Industrial Firewall. The industrial firewall is designed to monitor incoming and outgoing network traffic and decide whether to allow or block specific traffic based on a set of security rules. A firewall can either be software or hardware classified into different categories, such as packet filter firewalls, stateful firewalls, application proxy firewalls, and deep packet inspection firewalls [48]. Commercial firewalls such as CISCO ASA operate on specialized hardware that has attempted to use their firewall in SCADA networks by developing a Netfilter module that uses Modbus protocol header fields together with Iptables [49]. Compared with industrial gateways, industrial firewalls are more professional in monitoring traffic. For example, in this work, we select the Siemens PLC as the target, communicating with the S7Comm protocol. In the S7Comm protocol, the upload and download functions are realized through 0x1A-0x1F function codes, as shown in

Table 7. Upload and Download Function Codes of the S7Comm Protocol.

Function Codes	Des.
0x1A	Request Download
0x1B	Download Blocks
0x1C	Download Ended
0x1D	Start Upload
0x1E	Upload Blocks
0x1F	Upload Ended

, which can be set as crucial monitoring parameters.

Although the industrial firewall can effectively prevent malicious attacks, it requires a comprehensive and in-depth understanding of industrial control protocols. However, most industrial control protocols are private, so avoiding false negatives and positives is always tricky.

Machine Learning Technologies. Intrusion detection is a crucial component of ICSs to detect malicious network packets. Machine learning could distinguish regular packets from abnormal packets, and this distinction could serve as an intrusion detection system. Automating this form of intrusion detection can help monitor significant network traffic based on intrusive signatures or intrusive patterns [50]. At the same time, machine learning techniques can also be combined with other defense methods to achieve better detection results.

On the PLC security side, some defense methods exist, such as control logic obfuscation and PLC architectural developments. Compared with other defense measures, this type of defense method is mainly based on PLC, which needs to improve the PLC structure or occupy the operating resources of PLC.

Control Logic Obfuscation. Much of the existing research on PLC control logic program obfuscation has been attempted in many fields, such as evading malware signature matching [51] and preventing code injection into address spaces [52]. Another way against ICS-ARC-like attacks is to add some noise variables in the control logic program. Noise variables can confuse the search process for a correct mapping and disrupt the payload construction. However, more noise variables may affect the PLC scan cycle, which must be fully considered.

PLC Architectural Developments. Despite any architectural developments of PLCs facing a long path to deployment in the real world, it can mitigate PLC malicious payload attacks. In addition to some existing solutions for architectural development [53,54,55,56], another effective method is to attest to PLCs’ control logic to a trusted third party before being allowed to send control signals to devices. Thus, any malicious control logic could be uncovered. ICS-ARC attacks are based on the current PLC architecture. This attack can be prevented if the PLC architecture is changed, such as by adding a third-party trust mechanism. Because by nature, this type of attack is not to be trusted.

8. Conclusions

Traditional ransomware such as WannaCry shows massive negative impacts and causes tremendous data and financial losses to victims. The ICS ransomware attack, in particular, can be even more threatening as many ICSs are related to real-world safety. Thus, researchers and practitioners must proactively study the potential attack methods of ICS ransomware in order to protect ICS from future invasions. We present ICS-BROCK in our previous work to demonstrate that ICS ransomware attacks are actual in the real world by compromising a specific PLC. However, ICS-BROCK still has some limitations, such as a precompiled payload and the utilization of specific PLC characteristics. Although ICS-BROCK demonstrates that the ICS ransomware attack is actual, how to complete ransomware attacks against ICSs in a general method is still under struggle.

This paper presents ICS-ARC, which is a novel ransomware attack method that can automatically generate payloads based on target control logic. ICS-ARC proceeds with a ransomware attack in four steps. First, ICS-BROCK downloads the control logic bytecode from the target PLC and decompiles it into a logical model. Second, it finds a correct mapping between specific ICS devices and variables by model checking. Third, it instantiates the ransomware attack payload with the correct mapping. Finally, it uploads the malicious code to the target PLC. To evaluate the attack capability of ICS-ARC, we built an Arduino with OpenPLC installed and a tap water treatment system for verification separately. The attack results show that ICS-ARC significantly improves the fault tolerance of the attack while reducing the attack cost.

With the development of Industrial 4.0, more and more PLCs have been connected to the Internet. Thus, we make statistics on PLCs that may potentially be attacked with Shodan. As a result, it is foreseeable that the number of PLCs connected to the Internet will increase and grow faster and faster. Even though ICS-ARC is a novel attack method, almost all attack methods can be defended. In the last section, we have provided some defense methods, such as improved border security, industrial honeypots and honeynets, industrial gateways, industrial firewalls, control logic obfuscation, and ACL. Some of these methods are commercial products, some are academic research, but all help improve the security of ICS and resist attacks, including the ICS-ARC we proposed in this paper.