# PCaaD: Towards Automated Determination and Exploitation of Industrial
Processes

*Benjamin Green, *William Knowles, **Marina Krotofil , *Richard Derbyshire, *Daniel Prince
*Neeraj Suri
{b.green2, w.knowles, r.derbyshire1, d.prince<EMAIL_ADDRESS>
<EMAIL_ADDRESS>
*School of Computing and Communications, Lancaster University, Lancaster, United Kingdom
**Hamburg University of Technology, Hamburg, Germany

###### Abstract

Over the last decade, Programmable Logic Controllers (PLCs) have been
increasingly targeted by attackers to obtain control over industrial processes
that support critical services. Such targeted attacks typically require
detailed knowledge of system-specific attributes, including hardware
configurations, adopted protocols, and PLC control-logic, i.e. process
comprehension. The consensus from both academics and practitioners suggests
stealthy process comprehension obtained from a PLC alone, to conduct targeted
attacks, is impractical. In contrast, we assert that current PLC programming
practices open the door to a new vulnerability class based on control-logic
constructs. To support this, we propose the concept of Process Comprehension
at a Distance (PCaaD), as a novel methodological and automatable approach for
system-agnostic exploitation of PLC library functions, leading to the targeted
exfiltration of operational data, manipulation of control-logic behavior, and
establishment of covert command and control channels through unused memory. We
validate PCaaD on widely used PLCs, by identification of practical attacks.

##  1 Introduction

Acting as the bridge between physical industrial processes and enterprise
systems, Industrial Control Systems (ICSs) deliver wide-spread monitoring,
control, and automation capabilities to a broad spectrum of end-users. The
Purdue Enterprise Reference Architecture model (PERA) [54] provides an
approach to compartmentalize the complexity of ICSs into hierarchical layers.
Each layer affords system users with access to industrial processes and the
data they generate. The lower the layer, the closer associated devices are to
the processes they oversee, with Programmable Logic Controllers (PLCs)
providing a primary interface to operational components (e.g. pumps and
valves) via sensors and actuators.

A number of historical attacks have demonstrated the willingness of attackers
to target ICSs [15], with initial access obtained via malicious USBs, project
files, software updates, the supply chain, public facing systems, etc. [29,
37, 51, 21] However, there still exists a primary challenge, once access is
obtained, how can a cyber-physical attack be undertaken i.e., an attack in
which industrial operational process manipulation is achieved. A comprehensive
body of existing work details the challenge attackers face in the development
of cyber-physical attacks, captured under the umbrella term of "process
comprehension". This is defined as "the understanding of system
characteristics and components responsible for the safe delivery of service"
[27]. The described challenges align to a lack of a single resource by which
attackers can obtain sufficient process comprehension to conduct a cyber-
physical attack. We see this not only in the understanding of physical
operational processes, but also the interconnectivity and broader
configuration parameters of devices an attacker may choose to target.

While there exist a number of tools and techniques one can use to develop a
level of process comprehension through the targeting of PLCs alone, they are
limited by functionality, scope, and detectability [40, 5, 13]. The holy grail
would be to stealthily (avoiding detection) obtain complete Process
Comprehension at a Distance (PCaaD) targeting only PLCs, while simultaneously
preventing any disruption to their operation. We assert that current PLC
programming practices provide a segway into capability of this kind, and
provide validation through the exploration of widely used control-logic (PLC
code) library functions, developed by device vendors for use by programmers.
This leads to the following five exploitation capabilities: (1) the remote
enumeration of control-logic library functions, (2) the exfiltration of
operational process data and configuration parameters, (3) the targeted
manipulation of control-logic behavior, impacting operational processes and
configuration parameters, (4) the establishment of covert command and control
(C2) channels through unused memory, and (5) the end-to-end system-agnostic
automation of 1-4.

This paper serves as an significant step in developing PCaaD capability,
forming a greater understanding of the role PLC programming practices play in
process comprehension techniques, using library functions as an explorative
base. Through this, we begin to develop capability aligned to automated
environment-agnostic cyber-physical attacks, and build upon an emerging
vulnerability class based on control-logic constructs. Therefore, the novel
contributions of this work are:

  * •

A stealthy method to enumerate library functions based on memory allocation.

  * •

A targeted approach to data exfiltration and operational process/configuration
manipulation.

  * •

A method allowing for the establishment of a covert C2 channel via unused
memory.

  * •

An automated process to enact remote enumeration, exfiltration, exploitation,
and covert C2 channel creation.

The remainder of this paper is structured as follows. Section 2 covers related
work. Section 3 details a threat model/set of attack vectors. Section 4
provides a background on PLC program structures. Section 5 develops our main
contribution of PCaaD, which is subsequently validated in Section 6. Section 7
provides a set of lessons learnt, including a process flow for automated PCaaD
and attack execution. Section 8 concludes the paper and offers areas for
future work.

##  2 Related Work

Over the last decade, there has been an increasing volume of research
targeting the exploitability of embedded systems used in industrial settings.
This reflects both the large number of "low-hanging fruit" vulnerabilities,
and an increased interest from attackers towards the disruption of industrial
processes. To date, research efforts have predominately focused on real-time
operating systems, firmware vulnerabilities, industrial protocols, and
bypassing traditional security controls [3, 41, 17, 53, 6].

Only a small subset of existing work focuses on controller programming
security implications. Kottler et al., [32] explore the formal verification of
ladder logic (a control-logic programming language). Eckhart et al., [18]
consider security implications within the wider system development lifecycle.
While Serhane et al [44, 45] examine coding practices that could cause unsafe
conditions, in the majority of discussed practices, an attacker is required to
push new control-logic to target systems. In a similar vein, the development
of malicious control-logic to cause denial-of-service conditions has also been
explored [26]. More recently, Fluchs [22] describes an initiative backed by
the International Society of Automation to define "The Top 20 Secure PLC
Programming Practices", with a community driven approach to identify
additional practices moving forwards. Finally, the work of Ljungkrantz and
Akesson [35] provides an empirical exploration of PLC programming practices
using library components. This work showcases the wide spread adoption of
libraries and the potential impact of homogeneity in control-logic design.
However, it does not consider the cyber security implications of such
practices.

Few works have addressed the need for process comprehension from an attackers
perspective; a critical pre-condition when seeking to achieve operational
impact beyond simple denial-of-service [27, 24]. Research here has focused on
the exploitation of configurational practices [53], or wider attack scenarios
and taxonomies [17].

Research exploring physics-aware attack payloads for industrial processes are
also limited [36, 23]. While some elements of control-logic analysis in these
works is done automatically, payload design still relies on a "human-in-the-
loop". In the closest work to ours [16], the authors created an approach to
automate the analysis of control-logic and Human Machine Interface (HMI)
project files, before building an attack payload. However, the prerequisite in
obtaining such files presents an obstacle.

Currently, Stuxnet and Industroyer form the most sophisticated ICS-focused
attacks to date [21, 10]. Stuxnet applied a novel approach to target
identification using known characteristics within system data blocks (SDBs), a
component of Siemens PLC control-logic. However, this was highly targeted as
SDBs are unique to each implementation only providing PLC hardware parameters.
While Stuxnet embodied precision, Industroyer manipulated every identified
variable on the Remote Terminal/Telemetry Unit (RTU) (set all states to 0),
without understanding the targets associated operational processes.

To summarize, the security implications of PLC programming has received
limited attention, a critical gap noted by others [19]. Where it exists, there
has been no examination of how deployed control-logic could be stealthily
enumerated to support process comprehension. We assert current programming
practices play a key role in a PLCs exploitability, providing PCaaD without a
priori target system knowledge. The following sections describe a threat model
and PLC programming structures, prior to the identification of PLC-centric
artifacts that are used to build sufficient process comprehension to execute a
targeted attack.

##  3 Threat Model

To support discussions throughout the remainder of this paper, the following
system under consideration and set of example attack vectors are presented.
This offers insight into how PLCs can be targeted by multiple threat actor
categories, with varying capabilities and resources [14].

###  3.1 System Under Consideration

Figure 1 provides an overview of infrastructure architecture frequently found
in distributed ICS applications, such as water and energy [52]. Within the
Field Site (e.g. a water pumping station) there is a Windows-based HMI [48],
used by trusted operators to monitor and control physical operational
processes via the PLCs [47]. There are two PLCs which are used to monitor,
control, and automate operational processes. There is also an additional PLC,
the PLC/RTU, which performs a similar process automation role but also
communicates with a remote Top End System (TES), the Supervisory Control and
Data Acquisition (SCADA) Server [12]. Historically, PLCs only communicated
with devices inside the Field Site, with dedicated RTUs forwarding operational
data to TESs. However, due to the increased computational resource and
connectivity available in modern PLCs, they now act in a dual-purpose
capacity, providing RTU capability/interconnectivity with TESs [25]. There is
a network switch, and WiFi router, providing the Field Site with local and
remote communications. The remote SCADA Server communicates with the PLC/RTU
via its boundary router (in a real-world setting there would be multiple Field
Sites communicating with a TES for infrastructure-wide visibility). Finally,
the Windows-based Alarm Management Workstation accesses operational
data/systems via the SCADA Server.

###  3.2 Attack Vectors

Overlaid onto Figure 1 we have four example attack vectors (AV1-4), each with
a set of threat actor and defence profiles.

####  3.2.1 Attack Vector 1

Despite growing awareness of cyber security threats to ICSs, ICS devices are
being exposed to the Internet without suitable security measures [46, 37].

For this attack vector, we assume the PLC/RTU has been configured on a public
IP address for remote SCADA Server access. This allows the threat actor to
directly access the PLC/RTU and execute malicious commands with no defensive
controls to circumvent. This could be enacted by a low-skilled threat actors.

####  3.2.2 Attack Vector 2

For added convenience, the use of wireless technologies is becoming more
prevalent in ICSs. Conventional WiFi (802.11) for example, can be used to
established connectivity between engineering laptops, mobile HMIs, PLCs, etc
[50]. However if incorrectly configured (i.e. security and transmission
range), they can induce additional risk outside of a Field Site’s physical
perimeter [51].

For this attack vector, we assume the WiFi access provided by the router is
open and insecure. This allows the threat actor to directly access the
internal Field Site network and execute malicious commands with no defensive
controls to circumvent. This could be enacted by a low-skilled threat actor.

####  3.2.3 Attack Vector 3

While Field Sites can be isolated using network-based controls, access can
still be obtained through physical means [21]. For example, trusted system
operators, engineers, via the supply chain (e.g. 3rd party service providers
and pre-infected device introduction), etc. [29, 1, 51]

For this attack vector, we assume the connection between the Field Site and
Data-Centre is secured based on the use of a VPN and an associated IP
address/port rule-set. The rule-set permits the remote SCADA Server to
communicate with the PLC/RTU, all other traffic is blocked. In addition, the
WiFi access has also been secured with a strong WPA2 key. Here a trusted HMI
operator inserts a USB stick containing malicious code into the HMI, which
then executes malicious commands autonomously against all devices within the
Field Site network via the switch. This could be enacted through the use of a
malicious insider, or alternatively a high-skilled threat actor who is able to
infect a trusted users USB stick (e.g. via the supply chain).

####  3.2.4 Attack Vector 4

Direct access to Field Site devices via networked communications may only be
possible through existing trusted systems. Through the initial compromise of
trusted systems, and subsequent lateral movement, the desired level of access
can be achieved. Furthermore, social engineering is often viewed as a primary
initial access technique, and impacts ICS environments in the same way as
conventional IT systems. [33, 34]

For this attack vector, we assume the connection between the Field Site and
Data-Centre is secured based on the use of a VPN and an associated IP
address/port rule-set. The rule-set permits the remote SCADA Server to
communicate with the PLC/RTU, all other traffic is blocked. In addition, the
WiFi access has also been secured with a strong WPA2 key. Here the threat
actor compromises the Internet connected Alarm Management Workstation via a
malicious email. From this initial access, the threat actor then compromises
the SCADA Server, which is used to execute malicious commands against the
PLC/RTU.

Figure 1: Threat Model

##  4 PLC Program Structures

PLCs are available from a range of vendors, with varying deployments in
multiple industrial settings dependent upon operational requirements [52].
They sequentially execute a series of instructions, referred to as a
"Program". However, this paper uses the term control-logic to provide a clear
distinction during discussion. At a fundamental level, control-logic
interfaces with Input/Output (I/O) channels, and based on input states,
adjusts output states. Control-logic can provide additional, more complex
functionality. This includes establishing configuration parameters for
specific network protocols, emailing system’s users in the event of an
operational incident, and connect to remote engineer workstations in the event
of a system failure.

The BSI/IEC standard 61131-3:2013 [7] outlines five PLC programming languages.
These are split into two categories, Graphical (Ladder Diagram, Function Block
Diagram, and Sequential Function Chart), and Text Based (Instruction List,
Structured Text). These languages are vendor and application agnostic,
although vendor specific language subsets are often provided.

BSI/IEC 61131-3:2013 [7] also defines the concept of Program Organization
Units (POUs). The following definitions use, and expand, the terminology of
BSI/IEC 61131-3 to provide a generalized model, abstracting away from vendor
specific terminology, to support subsequent discussions:

  * •

Programs: Are the highest level of organizational unit. They control program
execution enabling responses to cyclic, time-based, or interrupt-driven events
during program execution. They are composed of specific instructions but also
Function Blocks and Functions.

  * •

Function Blocks (FB): Contain code that store their values permanently in
memory, remaining available post Function Block execution.

  * •

Functions: Provide discrete common functionality, for example, ADD or SQRT.
Function POUs can use global variables to permanently store data, but do not
have their own dedicated memory (i.e. local variables).

  * •

Variable Blocks (VB): Store program data and can be global (gVB), or local
(fVB). The latter of which are associated with Function Blocks to provide long
term data storage. The VB is an addition to the POU model as defined by IEC
61131-3. This standard describes the use of variables in a general sense, with
limited ties to their storage.

Control-logic can be written in Program, FB, and Function POUs. Typically,
there are additional specialist elements for accessing and addressing other
system’s components, including peripherals and timers. However, comprehension
of these is not necessary for the current discussion, and are therefore
omitted.

A further noteworthy control-logic attribute is the use of pointers in, and
between, VBs. This is useful for common information, such as configuration
data, or for central recording of operational parameters. For example,
consider two FBs. The first processes a water level, translating an I/O
channels raw analogue reading into a total water volume. The second is
required to access the total water volume for an additional calculation.
Instead of writing the total water volume value to the second FBs fVB
(copying/duplicating the value), the fVB would contain a pointer to a memory
location where the value has been stored by the first FB.

The use of Functions and FBs support code reuse patterns within an
organization across multiple deployments [30]. However, vendors often supply a
library of Functions and FBs spanning commonly required functionality, aiding
the development of control-logic. These libraries are also referred to as
"instruction sets". The results of a study into two automotive assembly
facilities, identified the repetitive use of libraries across their controller
base [35]. This process allows for the managed development/deployment of
control-logic, ensuring suitability in one operational zone prior to
widespread replication across the remaining estate.

It is worth noting a key difference compared to library Functions in
conventional IT software. On the surface, these POUs appear similar to their
IT equivalents, providing code reuse. However, they execute sequentially in
the control-logic, rather than undertaking complicated execution stack
management and sub-routine calls. The implication here is that when a Function
or FB is used multiple times, it must be copied into the control-logic
multiple times. With FBs a repeated fVB is allocated each time. In this way
library Functions are more like tested and verified code snipets, cut and
pasted into the control-logic to save time. Their deployment in any given
infrastructure (e.g. real-world environments such as water and energy, or a
testbed) is identical. This represents a key concept we exploit with our PCaaD
approach.

##  5 The PCaaD Approach

Given the previously described generic operating and programming model applied
to PLCs, there exists the possibility of enumerating control-logic by
observing VB memory. Where a PLC permits remote access to its memory across
the network (e.g. HMI and TES interactions to monitor and control operational
processes are done in this way), an avenue is provided for remote extraction
of its content. Furthermore, PLCs often include additional network functions
allowing for remote interrogation, these have been used in Nmap fingerprinting
scripts [40].

The memory layout of fVBs is consistent across implementations. Through the
identification of patterns in the memory layout of a fVB, it becomes possible
to identify (enumerate) them and their associated FBs. Once a FB is known, use
of the data contained within its fVB can then be interpreted and exploited.
Our advocated PCaaD process consists of a two phased approach to enumeration,
Data Retrieval and VB Determination, the completion of which allows for
targeted Exploitation.

###  5.1 Enumeration Phase 1: Data Retrieval

Data Retrieval is the first phase of PCaaD, and focuses on retrieving only the
necessary information required for subsequent VB Determination. This can be
applied to each of the four attack vectors described in Section 3, where we
state "execute malicious commands".

The data retrieval phase is common in many attack approaches and is often
found in wider reconnaissance activities [4]. Typical reconnaissance
techniques focus on identifying services running on a given system, and any
additional freely available information which may be useful to the attacker.
Current PLC reconnaissance tooling is limited, identifying basic parameters
such as manufacturer, model, and firmware version [40, 20].

Through the exploration of a range of PLCs, this work identifies the following
three common data retrieval methods which may be used during this stage. Each
has implementation specific pros and cons, which are highly dependent on the
attackers objectives and modus operandi (See Section 6).

  * •

Metadata: The majority of vendors provide network functions to query control-
logic meta information. These functions do not provide information regarding
the current operation of control-logic, but rather information about how it
(and the wider PLC) is configured. Within a traditional IT context, this is
comparable to querying the manifest of a shared code object (e.g. DLL on
Windows or Shared Objects in Linux).

  * •

Bulk Transfer: A PLC operating system will often provide a bulk transfer
operation, allowing engineers to extract the current state of POUs (gVBs,
fVBs, Program, FB, and Functions), supporting diagnostic fault finding,
scheduled backups, etc. Within a traditional IT context, this is comparable to
a web-server with direct file store access.

  * •

Memory Address Interrogation: PLCs provide the ability to remotely interrogate
internal memory locations for their current state. This functionality is used
to provide operational monitoring and control capability, supporting the
retrieval of one or more data items through the specification of memory
locations. Within a traditional IT context, this is comparable to SNMP Object
requests using a known Management Information Base.

###  5.2 Enumeration Phase 2: VB Determination

VB Determination, is the process of identifying which fVBs and associated FBs,
have been included within a PLCs control-logic, through the analysis of
retrieved data from Phase 1. Note that Functions do not have associated VBs
and so cannot be identified in this way.

A simple first order approach can be derived from the use of _Metadata_
retrieval approaches. As with interrogating shared code object manifests, a
fVBs _Metadata_ contains attributes one can use in the determination of its
associated FB.

Through the use of a _Bulk Transfer_ , or a byte wise download, we can obtain
fVBs in their entirety. Once obtained, a search for unique attributes (similar
to those in _Metadata_), can be conducted to determine its associated FB.

As previously discussed, each fVB has a static memory layout. This contains
variables used by the associated FB, and is consistent across all operational
and deployment contexts (e.g. water, energy, a testbed). A consistent static
memory layout allows for the identification of distinct characteristics
forming signatures, to identify fVBs and their corresponding FB using _Memory
Address Interrogation_. This concept can be considered similar to rainbow
tables, providing a set of pre-computed signatures ready for use during an
attack. The following characteristics have been initially selected for fVB
signatures:

  * •

fVB Size: The fVB size (quantity of allocated bytes) is fixed for all
instantiations of the FB across the control-logic base, and is dependent on
the number and type of variables used.

  * •

Known Values: Some FBs are pre-set with default (and thus known) values for
variables in the associated fVB. Here it would be possible to map these known
defaults and use them as an indicator of potential fVB match.

  * •

Variable Usage: Examination through memory interrogation, to reveal potential
data types. For example, if a memory location was only ever set to 0x00 or
0x01, it would indicate a potential boolean data type. Once the data type and
memory offset is determined for enough data types, it is possible to map this
to a known fVB layout.

  * •

Data Type Features: In some PLC hardware architectures it is known that
variable allocation is based on defined bit boundaries. Consider an
architecture allocation applying a 16 bit boundary. A boolean data type would
occupy more than a single bit. The use of numerous boolean variables in the
fVB would create a signature of null space which can be used to identify the
fVB.

It is worth noting, that for in-house developed FBs (not publicly available
library FBs), an attacker would not have an established signature for their
associated fVB ahead of an attack - except with the use of other intelligence
(i.e. precursory attacks to obtain PLC source code from either the target
facility, or a subcontractor where PLC programming is outsourced). However,
given the identification of an unmatched VB, it is then possible to generate a
signature. When applying PCaaD to other devices within the target
infrastructure, this new signature can then be used to identify where the
unknown FB is reused.

###  5.3 Exploitation based on PCaaD

Using the aforementioned techniques, an attacker is able to identify which
library FBs are included within the broader control-logic base. With this
newly acquired information, an attacker is now presented with a range of
options to launch an attack. We present three attacks which can be executed,
one of which is a storage-based covert C2 channel.

####  5.3.1 Attack 1: Exfiltrate FB Variables

This attack extracts data tied to operational process state, and/or PLC
configuration, dependant upon the FBs in use. It can be applied to each of the
four attack vectors described in Section 3, where we state "execute malicious
commands".

It has been asserted that library FBs require well defined fVBs, containing
characteristics one can use to develop signatures. Once a FB is known, the
associated fVB can be targeted to extract variable states, using a small
number of Memory Address Interrogation requests.

As discussed in Section 4, VBs may contain pointers to alternate memory
locations. Pointers typically have well defined static structures, which can
be decoded. Therefore, if a FB is using pointers in its associated fVB,
pointing to variables in a gVB, their state can also be retrieved, albeit with
an additional Memory Address Interrogation. Furthermore, the use of pointers
supports process comprehension, as it allows an attacker to identify gVBs that
are used by FBs.

####  5.3.2 Attack 2: Targeted Manipulation of FB Operation

This attack gains fine grained control of FBs, to subvert PLC or operational
process behaviors. It can be applied to each of the four attack vectors
described in Section 3, where we state "execute malicious commands".

Previously demonstrated attacks either required a priori information on the
target PLC [21], adopt brute-force techniques [43], or focus on denial of
service (DoS) impact [5]. For example, in the case of Stuxnet [21] it was
widely reported the only way in which this attack was achievable, was through
a complete attacker implementation of the target infrastructure based on
significant intelligence.

The approach discussed thus far enables PCaaD against an unknown system (no
requirement for a priori intelligence or replication of the target
infrastructure). An attacker knows how the FB variables are being used,
therefore has a greater level of understanding on how they can be manipulated.
For example, consider a FB responsible for counting how many litres of water
have been treated. To set this value back to 0, the attacker has two options,
overwrite the integer representing the total value, or toggle the count reset
bit to 1 and then 0.

####  5.3.3 Attack 3: A Novel Storage Based Covert Channel

This attack utilizes unused PLC memory (null space), to create a covert
channel. It can be applied as a combination of attack vectors 3 and 4
described in Section 3, where we state "execute malicious commands", to create
a covert channel between the SCADA Server and the HMI

As previously discussed, the presence of null space acts as a key
characteristic in the identification of fVBs and their corresponding FBs.
However, this null space can also be used to establish a covert communications
channel. Null space is allocated due to alignment with bit boundaries, and is
often not considered when processing data in the memory location. For example,
an 8 bit value allocated in a 16 bit boundary system, would result 8 bits of
unused space. This is a concept similar to the use of file slack space for
hiding data, and is used in tools such as bmap [39].

This approach to covert channel creation, exploits the observation that a PLC
is in a trusted position within an operational network. As shown in our
scenario (Figure 1), the PLC/RTU is required to communicate within its local
Field Site network (i.e. with the HMI and other PLCs), as well as the data-
centre network (i.e. SCADA Server). This means an external party could pivot
via the PLC/RTU from the Data-Centre network to the Field Site network. A
covert channel of this nature could be used for two primary purposes: C2 and
Data Exfiltration.

For the C2 channel, an attacker uses the PLC/RTUs null space to issue commands
from the C2 server (SCADA Server) to the C2 client (HMI). The C2 client
periodically checks the null space for these commands and execute them
accordingly. A channel built on this approach needs to consider the following:

  * •

How the C2 Sever (SCADA Server) and Client (HMI) synchronize on a subset of
the null space.

  * •

What periodicity for checking and writing to null space should be used, as
this may be dynamic dependant on network conditions (e.g. round trip times
between systems).

  * •

How reliable does the channel scheme need to be, verses the communications
overhead of introducing increased robustness. An increased communication
overhead could lead to increased detectability.

  * •

The possible commands, how they are encoded, and how results are relayed.

The final point listed here leads onto our second covert channel use: a data
exfiltration channel. Once a C2 channel is established it also becomes
possible to transfer more than simplistic commands and responses. In much the
same way as FTP applications have a control and data channel, a separate
channel could be used to bulk transfer larger volumes of data. Adopting the
same approach as the C2 channel (null space), this secondary channel can be
used to send and receive data. As with the C2 channel there are similar
challenges on reliability, resiliency, and speed of communications, verses
usability and detectability.

The concept of using null space and a PLC as a covert channel for attack,
gives rise to PLCs being used as a means for attack, not just the target of an
attack. This opens up a new class of security challenge which must be
considered when deploying PLCs. Section 6 demonstrates how this approach, and
the two prior attacks, can be practically achieved.

###  5.4 Summarizing PCaaD

This section has introduced the key PLC concepts required to understand the
general security problem class of PCaaD. It has also demonstrated the
feasibility of PCaaD by exploiting the code reuse patterns of common PLC
software libraries. These software libraries provide a commonality across PLC
implementations, regardless of operational or deployment context (e.g. water,
energy, a testbed).

It is argued that this commonality provides a mechanism to identify FB
signatures, which gives rise to a higher level of process comprehension.
Memory features are shown to provide an approach by which FB signatures can be
identified in a stable and repeatable way.

It is anticipated that machine learning approaches could be used for more
advanced fVB identification, with mapping based on the features identified
here. In addition, it would be expected that other features of fVB will be
identified and used to provide robust signatures. However, using the
techniques outlined here, it is possible to perform enumeration of all FBs
available from vendor libraries.

Given the level of process comprehension which can be obtained through PCaaD,
more sophisticated attacks can be performed. This includes configuration and
operational data exfiltration, as well as fine grained variable manipulation.
This section also introduced the concept of a storage based covert channel,
via a PLCs unused memory (null space). This covert channel opens a new class
of security challenge for PLCs, such that they are now not only the target of
attack, but also the means by which an attack occurs.

Whilst this section outlined key, high-level concepts, the following section
provides details on PCaaD’s practical implementation using the widely deployed
Siemens 300 Series PLC platform.

##  6 PCaaD Proof of Concept

To facilitate practical proof-of-concept exploration, we used a Siemens 300
series PLC 111Selected based on global adoption, making it a representative
use-case [47]., and the Siemens TIA v13 platform as a programming agent [49].
The library functions discussed herein are inbuilt into TIA v13
(Professional). We summarize this section with a note to the described
techniques applicability to a broader PLC base, beyond the directly described
Siemens 300 Series (e.g. Siemens 400, ET200, 1200, and 1500 Series, and ABB
Drive Functions).

###  6.1 Siemens PLC Ecosystem

Siemens 300 series PLCs support Ladder Diagrams, Statement List (Instruction
List), Function Block Diagram, Graph, and Structured Text programming
languages. When programming these devices four primary blocks are used to
build control-logic: Organization Blocks (OB) (i.e. Program POUs), Function
Blocks (FB), Functions (FC), and Data Blocks (DB) (i.e. Variable Block POUs).
These are aligned to the previously described BSI/IEC 61131-3:2013 [7].

Within OBs, FBs, and FCs, one is able to write control-logic. DBs are used to
store data, more specifically, variables called by OBs, FCs, and FBs. There
exist a number of additional symbol types where data can be generated,
outputted, and stored. These can be summarized as I/O Signals (I, Q, etc.),
Marker Memory (M, MB, etc.), Peripheral I/O (PIW, PQB, etc.), and Timers and
Counters (T & C) [42].

Figure 2 depicts the library FB Modbus_Comm_Load residing on a Ladder Diagram
rung. This FB is provided by Siemens as part of their TIA Communications
library, and is responsible for establishing the configuration of a port, from
which the PLC can communicate over serial using the Modbus protocol. To the
left of the Modbus_Comm_Load FB are a set of inputs, these are configuration
parameters (port, baud, parity, etc.). To the right of the Modbus_Comm_Load FB
are a set of outputs generated by the function (done, error, and status). By
default, some of the inputs are pre-issued and can be seen in grey. These can
be left unchanged if their states match the required configuration.
Alternatively, inputs can be replaced directly within the rung, as can be seen
with the blue RTS_ON_DLY input (0), or with variables stored in global DBs
(gVBs), as can be seen with DB1.DBW0 (the address for global variable
wRST_OFF_DLY) applied to the RST_OFF_DLY input.

Figure 3 depicts the local DB (fVB) of library FB Modbus_Comm_Load. This DB
stores all local variables (including inputs) used by the FB. Where global
variables are defined as inputs, FBs have two options. The first is to copy a
global variables current state into the local DB counterpart during every
control-logic cycle. The second is to configure a pointer targeting the global
variables location (DB address), in this instance the pointer will be stored
as a local variable within the FBs DB. The latter option is typically used
where larger data inputs are required (for storage and performance
efficiencies).

Figure 2: Modbus Library Function Figure 3: Modbus Library Function Data Block

###  6.2 The Application of PCaaD

The following subsections describe how control-logic can be leveraged by
attackers to achieve PCaaD via library DB/FB enumeration, leading to our three
attack cases: (1) Exfiltrate Function Block Variables, (2) Targeted
Manipulation of Function Block Operations, and (3) A Storage Based Covert
Channel. To establish communications with our PLC, the Python SNAP7 library
was used [38]. This library allows for the crafting of Siemens S7 packets, the
primary network protocol used by the PLC, and affords us with the ability to
issue requests (e.g. Read, Write, and Upload) as per vendor specifications
[31].

####  6.2.1 Enumeration Phases 1 and 2

As described in Section 4, PLCs provide network access to VBs for use by HMIs,
TESs, etc. For our PLC this means direct access to DBs (local and global). For
example, in Figure 2, we provided the input wRST_OFF_DLY at address DB1.DBW0,
this address would be used during the configuration of HMIs, allowing
operators to read and depict its current state on a graphical display.

The following three data retrieval techniques discussed in Section 4
(Metadata, Bulk Transfer, and Memory Address Interrogation) exploit access
granted to FB DBs over the network in order to enumerate their associated FBs,
this can be considered an information leakage vulnerability. To recap, these
techniques can be applied to each of the four attack vectors described in
Section 3, where we state "execute malicious commands".

Metadata (Get Block Info) - The first technique one can apply towards the
enumeration of a FBs DB, makes use of the inbuilt PLC feature Get Block Info,
allowing for the extraction of metadata parameters, as can be seen in Figure
4. The family and header fields are of greatest importance, allowing us to
ascertain which FB is using the DB to store its local variables. In the
example provided here, this DB is used by a MODBUS family FB, so has an
affiliation with Modbus communications. The header MBCOMLOA is a shortened
tile for the related FB Modbus Comms Load, previously described in Figure 2.
Therefore, it can be established that this DB is being used by the Modbus
Comms Load FB.

Figure 4: Get Block Info Example

While this technique allows for the enumeration of a DBs associated FB, its
reliance on the built in network function Get Block Info impacts its
detectability. In monitoring a Get Block Info request as it traverses the
network, Wireshark’s [55] in-build protocol recognition is able to clearly
identify its purpose. This is also true of nextgen security products [9, 11].
As this request is not commonly used within live industrial networks, it would
raise a red flag, and could be blocked as part of an environments default
security configuration profile.

Bulk Transfer (Block Upload) - The second technique we have identified makes
use of the inbuilt feature Upload. This is a network function constructed to
extract POUs in their entirety from the PLC. With PLCs, it is important to
note that in certain situations we talk from the device’s perspective. This is
industry derived terminology consistent between vendors. Therefore, when using
the term upload, we are referring to the PLC uploading data to the user, not
the user uploading data to the PLC.

In sending a DB Upload request to the PLC, the entire byte-code of that DB
will be returned. We examined this byte-code, and found the previously
discussed family and header parameters stored in clear text (see Figure 5).
Running a parser over the byte-code allows us to clearly identify the DBs
related FB.

Figure 5: Block Upload Example

As with Get Block Info, the Upload function has challenges aligned to
detectability. While this request is more common, it only occurs when an
engineer requires a copy of PLC control-logic. Therefore, where an engineer is
not present, its identification on the network would raise a red flag. It too
could form part of an environment’s default security configuration profile,
requiring an engineer to connect directly with each PLC, rather than from a
remote location.

Memory Address Interrogation (Read Requests) - To avoid detection challenges
identified with the two former enumeration techniques, we have developed an
approach based on Read requests. This is a specific network function applied
to the extraction of variable data from the PLC. HMIs, for example, will
execute Read requests to PLCs in order to extract data for use by operators.
This makes it extremely common, and thus if observed on the network would be
considered normal operational behavior (i.e. normal network traffic).

Siemens allocate static memory structures for our PLCs FBs in a minimum of
16bit blocks, even where only a single bit is required. This form of memory
allocation can be observed in Figure 3, where the REQ variable (boolean)
resides at address 0.0 (byte 0, bit 0), and the next variable, PORT (word),
starts at address 2.0, i.e. byte 0 bit 1 to byte 1 bit 7 are all unused and
populated with null space.

The size of some library FB DBs raises challenges in mapping all possible
variable data combinations, without first conducting a tedious manual review
of all possible state combinations (i.e. the more variables, the more valid
variable state combinations). While machine learning approaches, on initial
inspection, appear to be a feasible solution, they would rely on the ability
to capture all variable state combinations. Dependent upon the FB, some
variables are set once and do not change (e.g. BAUD in Figure 3). Therefore,
static variables such as these would require manual updating to allow for a
complete picture of all possible variable state combinations to be captured.
As such, mapping all unused null spaced memory offers a viable alternative,
with an increased level of performance due to the focused comparison of unused
memory alone.

Through the development of a comprehensive signature set (rainbow table) based
on an offline analysis of all library FB DBs (examining their structure within
the Siemens TIA programming agent, as seen in example Figures 3, 8, and 9),
focusing on their overall size and the location of any unused memory, we are
now able to enumerate any Siemens library FB aligned to a DB using only Read
requests. The ability to achieve DB and associated FB enumeration through the
use of Read requests alone, offers a stealthy and effective technique when
compared to the aforementioned approaches.

Our approach begins by Reading every DB byte into an array. This allows us to
ascertain DB size, from which we have a view of possible associated FBs based
on our signature set (i.e. we have narrowed the scope of possible FBs due to
their static DB size). We then check values at defined offsets (indexes within
the array), where we expect to see null states (again, based on our signature
set) e.g. unused offset/byte 1 as previously noted in Figure 3. Dependent upon
the requirements and construct of a FB and its DB, there can be in excess of
10 complete bytes of unused memory, in addition to multiple instances of
partially used bytes (i.e. up to 7 bits of unused memory within a byte).

Given current programming practices, we have demonstrated how remote control-
logic enumeration can be achieved using only Read requests, thus achieving
stealthy PCaaD. This is significant, with Siemens providing library FBs
spanning a number of critical areas (see Table 2 for a small selection of
example FBs), including Communications, PID (Proportional, Integral and
Derivative) Control, Safety, Remote Administration, and Alerting. The
following subsections explore ways in which this information can be built upon
by an attacker, to further develop their level of process comprehension, and
execution of targeted attacks.

####  6.2.2 Attack 1: Exfiltrate Function Block Variables

Having successfully enumerated a local DB based on its association to a given
library FB, it becomes possible to exfiltrate the data it contains. There are
two distinct techniques (Direct and Pointer Decoding) that can be applied to
the exfiltration of a FBs data. These techniques are based on how the FB
obtains/creates data stored within its local DB. To recap, these techniques
can be applied to each of the four attack vectors described in Section 3,
where we state "execute malicious commands".

Direct Read Requests - Taking the Modbus Comm Load function from Figure 2, and
its associated DB in Figure 3, there are a number of local variables that may
be of interest to an attacker. For example, at offset 4 there exists a double
integer storing the baud rate setting. Knowing that this DB is aligned to the
Modbus Comm Load function, and having analyzed the structure of the DB offline
in TIA portal to understand its contents, we can construct a Read request
specifically targeted at this offset to obtain the current baud rate.

If the variable in question is being stored in its entirety within the FBs
local DB, a Read request targeted directly at the variable location can be
used to extract its current state. For example, to extract the baud rate
variable from the Modbus Comm Load DB in Figure 3, we would construct our
request to Read 32 bits (double integer) from DB 1, starting at a byte offset
of 4. This information develops the attackers level of process comprehension
and build a picture of device-to-device data flows [28], of value when
constructing a targeted attack.

Pointer Decoding - As previously described, should a function’s input variable
require a large block of memory, a pointer will be applied. Therefore, should
we wish to exfiltrate data from a pointer input, we must first obtain the
pointer address. This is achieved by constructing an initial Read request
targeting the pointers location within the FBs local DB. We must then decode
the pointer address, prior to the formulation of an additional Read request
targeting the newly decoded address.

The construct of pointers within the Siemens ecosystem is unique, more
specifically, they contain an address based on the Siemens addressing scheme.
Taking the variable sUsername from Figure 6 as an example, this has an address
of DB1.DBX40.0, it is this address (the variables starting bit) that would be
placed inside a pointer. Note the P# before the address, this denote the use
of a pointer.

Figure 7 provides an example pointer structure, highlighting the address
location of DB 1 with an offset of 40. With this information we can begin
constructing a new Read request. To complete our request, we must also
ascertain the target variable size. An offline analysis of the FB input will
provide this information. For example, Figure 6 is a library FB taking email
username and password details, these must be strings. Strings have a
standardized size of 256 bytes, as can be see in Figure 8 (the location of
this pointer). Therefore, Reading 256 bytes from DB 1 at a byte offset of 40,
will provide us with the username<EMAIL_ADDRESS>Likewise, Reading 256 bytes
from DB 1 at a byte offset of 296, will provide us with the password
mypassword. Both the username and password are stored in clear text. The use
of this information to an attacker could prove highly valuable, especially
where the exfiltrated credential set is applicable across multiple systems
within the target environment.

The two exfiltration techniques described here cover all variables stored
within a FBs local DB. While the exfiltration of baud rate and credentials
demonstrate a clear benefit to attackers, they represent just two examples
from a much larger set (i.e. thousands) of FB variables across the Siemens
library. With Siemens library FBs spanning an array of capabilities as noted
in Section 6.2.1, and examples provided in Table 2, the wider ramifications of
data exfiltration, particularly with regards to the development of process
comprehension, is significant.

Figure 6: Email Library Function Figure 7: Pointer Structure Figure 8:
Username and Password Global DB

####  6.2.3 Attack 2: Targeted Manipulation of FB Operations

The use of Write requests are required to manipulate FB behavior through the
targeting of local DB variables. These requests are typically seen where
operators modify operational process behavior via a HMI (e.g. start/stop a
pump). They are, therefore, common permissable commands on an industrial
network. To recap, this technique can be applied to each of the four attack
vectors described in Section 3, where we state "execute malicious commands".

While Read requests have no limitations in their ability to execute as
expected, the ability to successfully manipulate FB behavior has one: cycle
time. Where variable states are updated during every control-logic cycle,
overwriting them with a 100% success rate becomes a challenge [43]. This is
the case for Siemens FBs inputs, with input states moved into a FBs local DB
during every cycle. Using Figure 2 as an example, Section 6.1 discussed the
following three techniques to provide FB inputs: directly, from a global DB,
and through the use of default values. Should a PLC programmer apply the first
or second technique, input states will be written to the FBs local DB during
every cycle of control-logic. Where default values are used, this limitation
does not exist, and a singe Write request will overwrite their state.

The cycle time limitation can be circumvented under certain conditions. For
example, the IEC_CU FB (see Figure 9 for this FBs local DB structure) takes a
boolean input (byte 0, bit 0) as a trigger, and provides an integer count
output (byte offset 6). Upon a state change of this boolean trigger, the
integer count output increases by one. There is a second input responsible for
resetting the current count value back to 0 (byte 0, bit 1). Should a PLC
programmer allocate a global variable to this input, an attacker would not be
confidently able to target the local DB address with a single Write request to
reset the current count. However, variables used within the FB and the FBs
outputs can provide an alternative target. Writing a single 0 to the current
count integer (byte offset 6), would reset the count without any limitations.
This is a vulnerability induced through the way in which the FB code has been
written, something only the vendor can address.

Figure 9: IEC Count Up DB

The ability to execute Write requests to a FBs local DB, opens the door to
wide-ranging impact. Using the Modbus_Comm_Load function discussed in Section
6.2.2 as an additional reference point, an attacker could target the BAUD
variable, placing the Modbus communication channel into a defective state.
Dependent upon what the channel is being used for, this could impact the PLCs
ability to communicate with other PLCs for critical operational data
exchanges, or even prevent operators from receiving alarms. As with data
exfiltration, the quantity and functionality offered within the Siemens FB
library brings with it a significant operational risk due to the described
manipulation (e.g. the manipulation of Safety Functions, of paramount
importance in protecting human life).

####  6.2.4 Attack 3: A Storage Based Covert Channel

In developing our enumeration technique based on Read requests, we focused on
the identification of local FB DBs through unused memory. In the previous
section on manipulating FB operations, we have demonstrated an attackers
ability to execute Write requests targeting a FBs local DB. The remainder of
this section takes attack vectors 3 and 4 from Section 3, where security
zoning has been established, and presents a method by which it can be violated
through the combination of these two concepts.

Scenario - Unlike Attacks 1 and 2, that require the attacker to obtain access
to a PLC alone, a broader set of pre-requisites are required for this attack.
As described in attack vectors 3 and 4 (See Section 3), the Field Site PLC/RTU
is permitted to communicate with all other Field Site devices and also the
SCADA Server. All other Field Site devices are not permitter to communicate
outside of the Field Site network (managed by perimeter firewalls, a baseline
recognized practice to defend zone boundaries [52, 8]).

Should an attacker compromise the SCADA Server (attack vector 4), allowing for
direct interaction with it, and the devices it connects to, only one Field
Site device would be accessible, the PLC/RTU. In contrast, should an attacker
compromise the HMI (attack vector 3), all Field Site devices would be
accessible. However, as the HMI is isolated within the Field Site network
zone, remote interaction would not be possible. The ideal attack vector, would
involve a method by which the functionality of both the SCADA Server (remote
connectivity into the Field Site Network network) and HMI (access to all Field
Site devices) could be leveraged. This is where their common resource, the
RTU/PLC comes in, providing an ideal pivot point between the two devices. For
additional clarity, the compromised SCADA Server acts as the C2-Server, and
the HMI acts as the C2-Client.

Channel Operations - In order to establish a covert C2 channel between the
C2-Client and the C2-Server via a FBs unused memory, each must first enumerate
all library FB DBs using the Memory Address Interrogation technique defined in
Section 5. This technique should be adopted as it stealthy in nature, thus
avoids raising an alert through alternate approaches (i.e. Metadata or Bulk
Transfer). Once enumerated, both parties must select the same DB and unused
memory offsets to begin communicating. Our approach to the selection of a DB
is defined by the quantity of available unused bytes of memory i.e., both
parities will use the DB that contains the most unused bytes of memory. Where
two or more DBs meet this requirement with an equal quantity of unused bytes,
the first DB will be selected (e.g. should DB3, DB5, and DB6 all contain 10
unused bytes, DB3 would be selected). Once selected, the first two unused
bytes of that DB will be aligned to synchronization and data exchange,
respectively.

Table 1 provides an overview of the binary synchronization states written to,
and read from, the first unused byte of memory. Each party must adhere to this
scheme in the establishment and continuation of communication exchanges. To
reiterate, in our scenario the HMI adopts the role of C2-Client, and the SCADA
Server adopts the role of CS-Server.

Function | C2-Server | C2-Client
---|---|---
Hello |  | 00000001
Hello Ack | 00000011 | 00000000
Write | 01000000 | 11100000
Reading | 11110000 | 01100000
Read | 00000000 | 00000000
Final Write | 11111111 | 11111110
On Hold | 00011000 | 00011000
Table 1: Synchronization Byte

A "what goes in goes out" approach has been applied in our current covert C2
channel. The C2-Server’s operator (the attacker) will construct a terminal
request it wishes the C2-Client to execute (e.g. ping 192.168.0.1). This
request will be cut into individual characters, each of which are sent over
the data exchange byte. To achieve this, each character is converted into its
decimal counterpart (ASCII character encoding). Each character is
reconstructed by the C2-Client, and once the entire request has been received,
it is executed in the C2-Client’s terminal. The terminal’s response is then
cut into individual characters, sent back to the CS-Server, reconstructed, and
displayed.

While the design of this covert C2 channel data exchange appears simplistic,
it is effective, and acts as a demonstrable tool in the use of unused FB
memory as a pivot point to violate security zoning. Its application across
Siemens library FB DBs is widely applicable, however, in order to ensure it
does not impact a FBs operation, a series of tests were undertaken. Through
this testing, we identified that in some instances where only one bit within a
two byte block is allocated, the FB would look for state changes across all
sixteen bits. Therefore, the use of unused memory would have an undesirable
impact on FB operation, creating issues with the stable and expected execution
of control-logic, and increase the chance of detectability. Fortunately, we
have found few instances that impact ones ability to establish a covert C2
channel through the use of this technique. Furthermore, in monitoring the
status of the primary bit in use, if it is set to 1, the use of unused memory
will have no impact on FB operation.

###  6.3 Cross Vendor Generalization

The PoC running example described throughout this section has been aligned to
the Siemens 300 series PLCs. Considering alternative Siemens PLC series, 400
series PLCs act as a mirror to the 300 series, making the techniques described
here holistically applicable. ET200 series PLCs act as a bridge between the
300/400 series and the newer 1200/1500 series. Testing with an ET200S resulted
in the direct applicability of our techniques. Finally, for 1200 and 1500
series PLCs, where library functions (e.g. TMAIL_C) apply direct addressing by
default, the described techniques are also applicable.

In the consideration of PLCs from other vendors, we conducted some initial
experimentation, and although the ecosystem of the devices tested differs
somewhat to Siemens, our fundamental concept (see Section 4) holds true to
ascertain similar attacks. In addition, we identified vendors providing
library functions for one another’s devices. ABB, for example, provide library
functions supporting drive integration with Siemens PLCs. These library
functions allow a Siemens PLC to control an ABB drive [2]. The FBs and
associated DBs provided by ABB, harbour the same deficiencies as discussed in
Section 6.2. Therefore, ABB devices become exploitable through this
integration.

The previous subsections have described how current PLC programming practices
can be exploited by attackers to achieve PCaaD and develop targeted attacks.
Furthermore, each technique can be fully automated, and is applicable to any
environment (e.g. water, energy, a testbed). The following section provides a
broader discussion around the defined problem space, including mitigation
techniques, a process for fully automated system exploitation, and vendor
response.

##  7 Lessons Learnt

We now overview salient points on PLC exploitability via the PCaaD process,
highlight issues in PLC programming practices, offer potential mitigations,
provide a response from Siemens, and detail a process for automation PCaaD and
attack execution.

###  7.1 The Impact of PCaaD

This work demonstrates the theoretical and practical application of PCaaD,
targeting only the PLC. Existing approaches to develop a high level of process
comprehension can be lengthy and involve data aggregated from multiple sources
[27]. This aggregation of data is largely applied toward an attackers
understanding of PLC control-logic. With a high level of process
comprehension, targeted operational process manipulation is made possible.
Without it, attackers are limited to primitive DoS attacks. The capabilities
described in this paper provide increased process comprehension, and therefore
the ability to strategically attack a PLC. While this does not provide full
process comprehension, it demonstrates an approach which supports enhanced
attack complexity (e.g. data exfiltration, targeted manipulation of FB
variables, and covert channel creation). The described techniques can be
adopted in parallel to existing approaches [27], enhancing an attackers
understanding of PLC functionality.

This can be exemplified when comparing targeted manipulation of FB operation
attacks, to attacks demonstrated in previous work [43], reducing the
requirement for priori knowledge of a system to identify target variables, and
also the need for rapid remote overwriting of PLC memory locations to maintain
the desired effect (i.e. the cycle time limitation).

In addition to the increased level of enumeration/attack sophistication
available through the use of PCaaD, this paper practically demonstrates the
use of a PLC in a covert channel. It was through the identification of null
space signatures during the PCaaD process, that gave rise to the possibility
of a storage based covert channel. As such, the PLC can be used as a pivot
point between protected Field Site networks and external networks. The
exploitation of a PLC in facilitating an attack, rather than being the target
of an attack, along with the mechanics of this storage based covert channel,
are both novel. Importantly, this adds a previously seldom considered class of
security challenge for PLC implementation, suggesting a reconsideration in the
understanding of ICS security zoning, a primary defensive measure [8].
Applying the described approach highlights challenges in conventional
segregation techniques to adequately prevent attackers from accessing
"isolated" zones. This work practically demonstrates channel feasibility, and
as such forces the ICS community to think differently about the role of PLCs
in cyber attacks.

###  7.2 Mitigations

This work continues to open the door of a new vulnerability class, one derived
through the creation of insecure control-logic. Using popular FB libraries as
an example, we have been able to articulate a set of independent and unique
attacks, which have been collectively applied to support an end-to-end
autonomous exploitation process flow (see Section 7.4). The exploitability of
FB libraries is, in part, tied to their static and accessible memory
structures, but also in how they have been written by vendors, and implemented
by PLC programmers. Furthermore, should PLC programmers develop their own
custom FBs (similar to those provided by ABB), they too could offer a target
for attackers through the adoption of our approach.

During the development of our PCaaD approach, and each exploitation technique,
mitigations were actively sought. Here a number of approaches are presented
that would aid in the reduction of PCaaD and associated exploitation
susceptibility. Some examples are aligned to the Siemens eco system to support
discussion, but provide a valid viewpoint for other vendors.

Network Access Restrictions form a well explored starting point towards
appropriate mitigation [52, 8]. If network-level access to fVBs can not be
natively restricted, ensuring PLCs are isolated from widely accessible
networks forms a baseline requirement. In addition to this, deploying next
generation IDS/IPS with industrial protocol recognition [9, 11], allows for
granular access control between trusted connections. Limiting fVB access could
therefore be applied within a baseline rule-set.

Stack Canary usage within conventional applications is common practice. Acting
as a flag for the identification of unexpected data within a defined memory
structure. A similar concept could be applied as part of a PLCs control-logic,
through the creation of a custom FB to monitor critical data points within
library fVBs. For example, in monitoring the BAUD variable in Figures 2 and 3,
should its state remain static at 9600, a single rung of validation logic
would be required. This rung would check the current value during every cycle,
if the value did not equal 9600, it would set a bit, thus raising an alert on
local HMIs. This concept could also be applied to all null spaced memory,
raising an alert if it becomes populated with data.

Setting All FB Inputs even where default values are applicable, will induce
the cycle time limitation discussed in section 6.2.3. While this will not
mitigate all attacks, it presents an additional challenge for attackers to
overcome.

Filling Unused Memory with random data would make enumeration via read
requests more challenging.

Additional Checks for Neighboring PLCs could be applied to validate received
data. For example, considering the count function attack in section 6.2.3, an
additional check to identify state changes on the reset bit, before accepting
a reset of the count value, would provide an additional validation.

Read/Write Protection features within 300, 400, and ET200 series devices would
prevent enumeration using the Upload technique. However, the applicability of
alternate options discussed in section 6.2.1 would remain unaffected.

Vendor Centric changes could be applied to the development and inclusion of
library FBs. For example, FBs could be written in such a way as to allow for
all data generated to be made available as defined outputs, fed into gVBs,
meaning no local or remote access to a FBs fVB would be required. In addition,
Siemens implement know-how protection on FB code, preventing programmers for
viewing pre-compiled logic. This principle could be applied to a FBs
associated fVB, making it harder to map memory usage and generate signature
sets.

Memory allocation within fVBs could be constructed in a more efficient way,
reducing unused capacity, and thus advancing the technical requirements for
successful enumeration using read requests alone, and limiting attackers
ability to create covert channels.

A blanket rejection of all network-based requests targeting fVBs would offer
holistic mitigation. This feature can be manually enabled (disabled by
default) on gVBs used by 1200 and 1500 series devices, but is not yet
available for fVBs.

Enable Block Optimization on Siemens 1200 and 1500 series PLC where possible
(not currently available across all library FBs). This feature removes static
addressing schemes, with variables referenced based on name as opposed to
address. It may still be possible to enumerate and attack these functions
based on the use of standardized variable names, however this is outside of
our current scope. The only drawback of this feature is that third-party
devices (e.g. HMIs) requiring access to PLC data must support S7 Comm Plus.
Where support is not available, a blanket disabling of block optimization may
be adopted by PLC programmers, thus re-introducing static addressing schemes.

###  7.3 Vendor Response

Following responsible disclosure practices, we contacted Siemens and ABB to
make them aware of the issues identified in this paper. Siemens response was
as follows:

"The flat addressing in PLCs like S7-300 and ET200S CPU is a design decision
from the 90s and cannot be easily changed without breaking existing
installations. Siemens recommends customers to restrict network access to the
affected devices, to apply Defense-in-Depth measures that can be found in the
Operational Guidelines for Industrial Security, and to follow the
recommendations in the product manuals. Siemens improved this behavior in the
new PLC generation (S7-1200 and S7-1500) by creating the optimized Data Blocks
and additional levels of protection to these PLCs."

It is worth noting, Siemens have committed to offering 300 series devices
until 2023, with an additional ten years of support beyond this point [47].

###  7.4 Automated Evaluation of Control-Logic

The PCaaD capabilities presented here represent a first step towards the
ability to automate targeted exploitation of operational processes and PLC
configuration parameters. The endpoint of this research is to provide an
integrated exploitation platform. Such a platform would enumerate using the
identified, and expanded upon PCaaD approaches, and further integrate
exploitation components extending beyond those already identified. Embedding
this functionality into a single platform forms a linear attack offering,
heightening each component/techniques collective value. This has been seen in
IT penetration testing (e.g. Metaspolit). Figure 10 provides a high-level
process flow, depicting the functionality offered through the integration of
each component described within in this paper. A PoC tool operating as
outlined in Figure 10 has been developed in Python by the research team.

Figure 10: Automated PCaaD & Attack Execution Process

The process incorporates manual and automated target selection (the latter is
achieved through use of PLC Scan [20]). Once a suitable target PLC is
identified, the PCaaD process is initiated to enumerate control-logic and
identify possible target memory locations for our three exploit categories.
Additional flexibility is included to add signatures beyond the known vendor
provided library FBs. Custom, in-house signatures can be added to the
repository, supporting the enumeration and exploitation of in-house developed
FBs/fVBs. As a whole, this platform will aid an organizations efforts to
better understand the scale of exploitable control-logic within their estate,
and to evaluate security zoning.

##  8 Conclusion and Future Work

This work has demonstrated the feasibility of stealthy, sophisticated,
targeted attacks on industrial processes with no prior knowledge of the target
PLCs configuration or control-logic. An attack of this nature was previously
considered to be impractical. However, this paper demonstrates that through
the exploitation of current PLC programming practices, and code reuse
patterns, such attacks are possible. As a result, several security challenges
are presented. These challenges align to successful PCaaD giving rise to
sophisticated targeted attacks against previously unseen industrial processes,
and the use of a PLC in the facilitation of attacks via a storage based covert
channel.

A further benefit of the PCaaD approach described in this paper is the ability
to fingerprint custom FBs. These FBs, written in-house by PLC engineers for
deployment across an organizations operational estate, can now be identified
using the our signature techniques. Given the wide-spread use of identical
custom FB libraries within an organization [35], identifying custom control-
logic offers added value, increasing the breadth of FB detection beyond
publicly accessible/vendor provided libraries.

While our practical proof of concept focused on demonstrating the identified
security challenges on Siemens PLCs, an initial exploration of two other
prominent vendors highlights key parallels. The functional similarities
between vendors, suggests other vendors’ devices to be equally exploitable.

A selection of appropriate mitigation techniques have been discussed. This
included points raised by Siemens, aligned to capability embedded within their
latest product range. However, we believe features within these products could
be circumvented, offering an additional direction for future work.

The research agenda for future work in this space will focus on two primary
themes: Improvements in PCaaD techniques, and exploring further possibilities
to utilise PLCs as an attack platform.

For PCaaD techniques, our first phase of work will be to widen the empirical
exploration to a broader range of vendors. The aim of which is to develop a
comprehensive tool, able to target and enumerate fVBs across a range of PLCs.
To achieve this, further developments in identifying memory features to
provide more sophisticated signatures may be required. This includes the
exploration of machine learning approaches.

The use of PLCs as a tool during an attack will be further developed. This
will focus on establishing a range of mechanisms to enhance our existing
covert channel. More specifically, we will explore the trade off between
channel features, detectability, robustness, and control overhead.

## References

  * [1] Havex Hunts For ICS/SCADA Systems.  https://www.f-secure.com/weblog/archives/00002718.html, 2014.
  * [2] ABB.  Drive Manager for SIMATIC.  https://new.abb.com/drives/software-tools/drive-manager-for-simatic, 2020\.
  * [3] Ali Abbasi, Majid Hashemi, Emmanuele Zambon, and Sandro Etalle.  Stealth low-level manipulation of programmable logic controllers i/o by pin control exploitation.  In International Conference on Critical Information Infrastructures Security, pages 1–12. Springer, 2016.
  * [4] Michael J Assante and Robert M Lee.  The Industrial Control System Cyber Kill Chain.  https://www.sans.org/reading-room/whitepapers/ICS/paper/36297, 2015\.
  * [5] Dillon Beresford.  Exploiting siemens simatic s7 plcs.  Black Hat USA, 16(2):723–733, 2011.
  * [6] Eli Biham, Sara Bitan, Aviad Carmel, Alon Dankner, Uriel Malin, and Avishai Woo.  Rogue7: Rogue Engineering-Station Attacks on S7Simatic PLCs.  Technical report, 2019.
  * [7] British Standards Institute.  61132-3:2013 - Programmable Controllers - Part 3: Programming Languages.  Technical report, 2013.
  * [8] British Standards Institute.  Industrial Communication Networks – Network and System Security Part 3-3: System Security Requirements and Secruity Levels (IEC 62443-3-3).  2013\.
  * [9] Checkpoint.  Industrial Control Systems Security Gateway.  https://www.checkpoint.com/products/industrial-control-systems-appliances/, 2021\.
  * [10] Anton Cherepanov.  WIN32/INDUSTROYER: A new threat for industrial control systems.  Technical report, ESET, 2017.
  * [11] Claroty.  Continuous Threat Detection.  https://www.claroty.com/continuous-threat-detection/, 2021.
  * [12] COPADATA.  What is SCADA?  https://www.copadata.com/en/product/zenon-software-platform-for-industrial
-automation-energy-automation/visualization-control/what-is-scada/, 2020\.
  * [13] dark lbp.  ICSSploit: Industrial Control System Exploitation Framework.  https://github.com/dark-lbp/isf, 2020.
  * [14] Richard Derbyshire, Benjamin Green, and David Hutchison.  “Talking a different Language”: Anticipating adversary attack cost for cyber risk assessment.  Computers & Security, 2020.
  * [15] Richard Derbyshire, Benjamin Green, Daniel Prince, Andreas Mauthe, and David Hutchison.  An Analysis of Cyber Security Attack Taxonomies.  In Security and Privacy Workshops (EuroS&PW), 2018 IEEE European Symposium on. IEEE, 2018.
  * [16] Matan Dobrushin and Yoav Flint.  Project RunAway.  https://cs3sthlm.se/program/presentations/matan-yoav/, 2019.
  * [17] Zakarya Drias, Ahmed Serhrouchni, and Olivier Vogel.  Taxonomy of attacks on industrial control protocols.  In 2015 International Conference on Protocol Engineering (ICPE) and International Conference on New Technologies of Distributed Systems (NTDS), pages 1–6. IEEE, 2015.
  * [18] Matthias Eckhart, Andreas Ekelhart, Arndt Lüder, Stefan Biffl, and Edgar Weippl.  Security development lifecycle for cyber-physical production systems.  In IECON 2019-45th Annual Conference of the IEEE Industrial Electronics Society, volume 1, pages 3004–3011. IEEE, 2019.
  * [19] Matthias Eckhart, Andreas Ekelhart, Arndt Lüder, Stefan Biffl, and Edgar Weippl.  Security development lifecycle for cyber-physical production systems.  In IECON 2019-45th Annual Conference of the IEEE Industrial Electronics Society, volume 1, pages 3004–3011. IEEE, 2019.
  * [20] Dmitry Efanov.  PLCScan the Internet.  http://scadastrangelove.blogspot.com/2012/11/plcscan.html, 2017\.
  * [21] Nicolas Falliere, Liam O Murchu, and Eric Chien.  W32.Stuxnet Dossier.  Technical report, 2011.
  * [22] Sarah Fluchs.  The Top 20 Secure PLC Coding Practices Project.  https://bit.ly/34DqoHi, 2020.
  * [23] Luis Garcia, Ferdinand Brasser, Mehmet Cintuglu, Ahmad-Reza Sadeghi, Osama Mohammed, and Saman Zonouz.  Hey, my malware knows physics! attacking plcs with physical model aware rootkit.  In Network and Distributed System Security (NDSS) Symposium, pages 1–15, 01 2017.
  * [24] Dieter Gollmann, Pavel Gurikov, Alexander Isakov, Marina Krotofil, Jason Larsen, and Alexander Winnicki.  Cyber-physical systems security: Experimental analysis of a vinyl acetate monomer plant.  In Proceedings of the 1st ACM Workshop on Cyber-Physical System Security, pages 1–12, 2015.
  * [25] Antonios Gouglidis, Sandra Konig, Benjamin Green, Karl Rossegger, and David Hutchison.  Protecting Water Utility Networks from Advanced Persistent Threats: A Case Study.  In Game Theory for Security Management - From Theory to Practice. Springer Birkhäuser, Boston, 2018.
  * [26] Naman Govil, Anand Agrawal, and Nils Ole Tippenhauer.  On ladder logic bombs in industrial control systems.  In Computer Security, pages 110–126. Springer, 2017.
  * [27] Benjamin Green, Marina Krotofil, and Ali Abbasi.  On the Significance of Process Comprehension for Conducting Targeted ICS Attacks.  In Proceedings of the 3nd ACM Workshop on Cyber-Physical Systems Security and Privacy. ACM, 2017.
  * [28] Benjamin Green, Marina Krotofil, and David Hutchison.  Achieving ics resilience and security through granular data flow management.  In Proceedings of the 2nd ACM Workshop on Cyber-Physical Systems Security and Privacy, pages 93–101, 2016.
  * [29] ICS-CERT.  ICS Focused Malware, 2014.
  * [30] Joan Jacinto.  Siemens Open Library Can Speed Project Development.  https://bit.ly/2QUy96a, 2017.
  * [31] Amit Kleinman and Avishai Wool.  Accurate modeling of the siemens s7 scada protocol for intrusion detection and digital forensics.  The Journal of Digital Forensics, Security and Law: JDFSL, 9(2):37, 2014.
  * [32] Sam Kottler, Mehdy Khayamy, Syed Rafay Hasan, and Omar Elkeelany.  Formal verification of ladder logic programs using nusmv.  In SoutheastCon 2017, pages 1–5. IEEE, 2017.
  * [33] Robert M Lee, Michael J Assante, and Tim Conway.  German Steel Mill Cyber Attack.  Technical report, SANS, 2014.  Retrieved 02/02/2015.
  * [34] Gaoqi Liang, Steven R Weller, Junhua Zhao, Fengji Luo, and Zhao Yang Dong.  The 2015 ukraine blackout: Implications for false data injection attacks.  IEEE Transactions on Power Systems, 32(4):3317–3318, 2017.
  * [35] Oscar Ljungkrantz and Knut Akesson.  A study of industrial logic control programming using library components.  In 2007 IEEE International Conference on Automation Science and Engineering, pages 117–122. IEEE, 2007.
  * [36] Stephen McLaughlin and Patrick McDaniel.  Sabot: Specification-based payload generation for programmable logic controllers.  In Proceedings of the 2012 ACM Conference on Computer and Communications Security, CCS-12, pages 439–449, 2012.
  * [37] Ariana Mirian, Zane Ma, D. Adrian, Matthew Tischer, Thasphon Chuenchujit, Timothy M. Yardley, R. Berthier, J. Mason, Zakir Durumeric, J. A. Halderman, and M. Bailey.  An Internet-wide view of ICS devices.  In 2016 14th Annual Conference on Privacy, Security and Trust (PST), pages 96–103, 2016.
  * [38] Gijs Molenaar and Stephen Preeker.  Welcome to python-snap7’s documentation!  https://python-snap7.readthedocs.io/en/latest/, 2013.
  * [39] Martin Mulazzani, Sebastian Neuner, Peter Kieseberg, Markus Huber, Sebastian Schrittwieser, and Edgar Weippl.  Quantifying windows file slack size and stability.  In IFIP International Conference on Digital Forensics, pages 183–193. Springer, 2013.
  * [40] Nmap.  s7-info.  https://nmap.org/nsedoc/scripts/s7-info.html, 2020.
  * [41] Alexander Nochvay.  CODESYS Runtime, a PLC control framework.  Technical report, 2019.
  * [42] PLCDev.  Symbol Table Allowed Addresses and Data Types.  http://www.plcdev.com/symbol_table_allowed_addresses_and_data_types, 2020\.
  * [43] Andres Robles-Durazno, Naghmeh Moradpoor, James McWhinnie, Gordon Russell, and Inaki Maneru-Marin.  PLC memory attack detection and response in a clean water supply system.  International Journal of Critical Infrastructure Protection, 26:100300, 2019.
  * [44] Abraham Serhane, Mohamad Raad, Raad Raad, and Willy Susilo.  Plc code-level vulnerabilities.  In 2018 International Conference on Computer and Applications (ICCA), pages 348–352. IEEE, 2018.
  * [45] Abraham Serhane, Mohamad Raad, Raad Raad, and Willy Susilo.  Programmable logic controllers based systems (plc-bs): vulnerabilities and threats.  SN Applied Sciences, 1(8):924, 2019.
  * [46] Shodan.  Industrial Control Systems.  https://www.shodan.io/explore/category/industrial-control-systems, 2020\.
  * [47] Siemens.  SIMATIC S7-300 - Proven Multiple Times!  https://new.siemens.com/global/en/products/automation/systems/industrial/plc/simatic-s7-300.html, 2020\.
  * [48] Siemens.  SIMATIC WinCC V7.  https://new.siemens.com/global/en/products/automation/industry-software/automation-software/scada/simatic-wincc-v7.html, 2020\.
  * [49] Siemens.  Totally Integrated Automation Portal.  https://new.siemens.com/global/en/products/automation/industry-software/automation-software/tia-portal.html, 2020\.
  * [50] Siemens.  IWLAN – the WLAN for challenging industrial applications.  https://new.siemens.com/global/en/products/automation/industrial-communication/industrial-wireless-lan.html, 2021\.
  * [51] Jill Slay and Michael Miller.  Lessons learned from the maroochy water breach.  In International Conference on Critical Infrastructure Protection, pages 73–82. Springer, 2007.
  * [52] Keith Stouffer, Victoria Pillitteri, Suzanne Lightman, Marshall Abrams, and Adam Hahn.  Guide to Industrial Control Systems (ICS) Security.  Technical report, 2014.
  * [53] Haroon Wardak, Sami Zhioua, and Ahmad Almulhem.  Plc access control: a security analysis.  In 2016 World Congress on Industrial Control Systems Security (WCICSS), pages 1–6. IEEE, 2016.
  * [54] Theodore J Williams.  The Purdue enterprise reference architecture.  Computers in industry, 24(2-3):141–158, 1994.
  * [55] Wireshark.  S7 Communication (S7comm).  https://wiki.wireshark.org/S7comm, 2020.

## Appendix

FB Category | Example FB | Description
---|---|---
Basic Instructions | TON | Delays the setting of the Q parameter for the programmed duration PT
| CTU | Increments the value at the CV parameter
| SMC | Compares the signal state of up to 16 programmed input bits
|  | (IN_BIT0 to IN_BIT15) with the corresponding bits of the comparison
|  | masks for each step
| ACK_GL (Safety) | Creates an acknowledgment for the simultaneous reintegration of all
|  | F-I/O or channels of the F-I/O of an F-runtime group after communication
|  | errors, F-I/O errors, or channel faults
| SFDOOR (Safety) | Safety door monitoring
Extended Instructions | SET_SW | Supports the switch from daylight-saving time to standard time in CPUs
|  | that are not equipped with time-of-day status
| TIMESTMP | Transmits messages with a time stamp of an IM153-2 to its instance DB
| RDREC | Reads the data record with the number INDEX from the component
|  | addressed using the ID
| SETIO | Consistently transfers the data from the source area spanned by
|  | OUTPUTS to the addressed DP standard PROFINET IO device, and, if
|  | necessary, to the process image
| PACK | Transfers data located between any addresses and a table
Technology | CONT_C (PID) | Controls technical processes with continuous input and output variables
| PULSEGEN (PID) | Implements a fixed setpoint controller with a switching output for
|  | proportional actuators
| MC_MoveAbsolute | Starts an axis positioning motion to move it to an absolute position
| EncoderSINAMICS | Integrates a SINAMICS drive in Easy Motion Control
| OVERRIDE (PID) | Implements an override control
Communication | PUT | Writes data to a remote CPU if the connection does not take place via a CP
|  | PG_DIAL (Remote
---
Administation)
| Transfers a telephone number and an event ID to a TS Adapter. Using the
---
specified telephone number, the TS Adapter establishes a remote
connection to a programming device/PC
| MODBUSPN | Enables communication between a CPU with integrated PN interface and a
|  | partner which supports the Modbus/TCP protocol
|  | AS_MAIL
---
(Alerting)
| Uses the Simple Mail Transfer Protocol (SMTP) to transfer an e-mail from
---
a CPU to a mail server
|  | SMS_SEND
---
(Alerting)
| Transfers a telephone number, a service center number and an SMS
---
message to a TS Adapter
Table 2: Example Library Functions (Siemens TIA v13) [49]