LOGistICS is a novel monitoring framework for investigating the security of industrial PLC systems. Diverse processing components and probes with diferent tasks are included in the architecture. Reconstructing the process of cyber-attacks against industrial devices in its entirety, and also identifying the actors, is the topic of this study. Our solution is suitable for research and production environments, allowing for more interaction with an attacker while remaining undetectable as we will see from the behaviour of the actors. To achieve this aim, we exposed LOGistICS to the Internet with a module that we developed to examine suspicious activities, sequencing the operations carried out by the same attacker over time and therefore identifying its pattern. We found that the Cyber Kill Chain model is not always respected. We discuss these anomalies and provide our insights.
ware used for this purpose was Industroyer2, which targets the controller hardware that manages
the flow of water, use of cleaning agents and other embedded machines that keep water systems
running eficiently [
Honeypots [
Honeypot CryPLH HoneyPLC
Gaspot
HoneyVP S7CommTrace
Conpot
LOGistICS
and honeypot detection tools. Detection systems likely use unique characteristics of specific
honeypots in order to identify them, such as the property-value pairs of default honeypot
conifgurations. The majority of the honeypots discussed in Section 2 have a low level of interactivity.
Quantitative trafic analysis can benefit from this level of involvement. However, to analyze the
state of the art of attacks we cannot rely on this approach. According to Shodan,5 the most common
mistake of researchers deploying honeypots is to use a default configuration without applying
changes [
Some initial results have been presented in [
Gaspot is a project conducted in the Trend Micro research center,8 and was later presented at the
Blackhat 2015 conference [
6The complete guide to Shodan: ia800705.us.archive.org/17/items/shodan-book-extras/shodan/shodan.pdf. 7Conpot: conpot.org. 8Trend Micro: https://www.trendmicro.com. 9Black Hat: https://blackhat.com.
Stack is simulated via the Linux kernel [
In this section we introduce the necessary background notions about Modbus and S7Comm, which are the two protocols monitored by LOGistICS. We mostly focus on the functions that can be invoked on a PLC, which will be exploited during attacks (see Section 5 and Section 6).
Modbus is a protocol developed by Modicon [
According to Schneider Electric documentation, the data field has a variable length depending on the type of function invoked. Function code represents the core meaning of the message, whose encoding denotes the action performed. Function codes are of three types: public, user-defined and reserved. Public function codes are documented and tested. This case also includes codes that are reserved for future developments. User-defined function codes are those codes not supported by the protocol specification, and which the user can implement from scratch. Reserved function codes are implemented by companies and are not available for public use. Modbus protocol provides one byte of code-mapped field capable of representing 255 possible functions: value “0" is not valid, values from 1 to 127 are efectively used, and values between 128 and 255 are used for exception function code in response messages. Table 2 shows a list of Modbus function codes. 3.2. S7Comm S7Comm is a proprietary protocol developed by Siemens. In the industry it is used for diagnostic and PLC programming purposes. S7Comm works via TCP on port 102 and relies on the ConnectionOriented Transport (COTP) protocol and the Transport Packet (TPKT ) service [20]. The packet is encapsulated with the COTP header in order to be ISO-on-TCP compliant (RFC1006) [21].
The S7 PDU consists of three core components: header, parameters and data, where the latter component is optional. S7Comm is a command oriented protocol, in the sense that each transmission contains a command or a response to it. Protocol documentation is not publicly available. For this reason projects such as the open-source communication library Snap7 [22] and Libnodave [23] have come to light. It is possible to transfer user programs or individual portions to a PLC. To interface data with programs like Siemens Step7,10 PLCs use distinct parts, called blocks [24]. As introduced before, S7Comm is the payload of a COTP packet, and it is distinguished by the identifier 0x32 (as known as Magic Byte). Then we find Message Type, Data Unit, Reserved, Parameter and Data length, and finally error classes and codes. The Message Type, often identified as ROSCTR, can be interpreted in four ways. Job request is the request sent by the master. Ack signal is the acknowledgment sent by the slave, omitting the data field. Ack data is the acknowledgment sent by the slave with the optional data field, containing the Job. User data is the extension of the original protocol containing ID requests/responses. In the case of parameters like Job and Ack data, the optional parameter that follows is the function code. The remaining fields may vary depending 10Step7: cache.industry.siemens.com/dl/files/056/18652056/att_70831/v1/S7prv54_i.pdf. on this parameter, which decides the purpose of the communication. The Setup Communication function is used to establish the first S7Comm connection, and provides information on Ack queues (i.e. number of parallel jobs without Ack) and the maximum length of the PDU. The Read and Write functions are self-explanatory, and are used to read and write more variables on the PLC. Functions such as Request Download, Download Block, Download End, Start Upload, Upload and Upload End are used to perform block download and upload operations. The PLC Stop function stops the execution of the program running on the PLC, and Program Invocation (PI) manages the execution of such a program in a wider way (it also include the PLC Stop functionality). The CPU service is used to access fields such as the protection levels of the CPU and the SZL partial lists.
In this section we describe the components of LOGistICS framework. In Section 4.1 we
describe the overall experimental setup in its entirety. In Section 4.2 we describe the snifer we
implemented. We mainly focus on its versatility, and on its ability to listen only to the trafic of
interest. In Section 4.3 we describe the implementation of the Modbus service based on Pymodbus,
by also explaining how we enriched the functionality of the emulated service. Compared to the
honeypots seen in Section 2, we guarantee the user the ability to customize the PLC template
while still ensuring considerable camouflage capabilities [
The framework, whose architecture is represented in Figure 1, can be summarized by four main
components logically and physically separated: honeypot node, snifing node, assessment node
and monitoring node [
The assessment node is equipped with Kali Linux. The purpose of this node is to evaluate in
depth the interaction with the honeypot node with respect to the state of the art of ICS Red Team
tools available in the Kali Linux distribution. The honeypot node exposes Modbus and S7Comm
services. In order to isolate and to ensure portability, we distribute these services via container
technology. For clarity, the only node actually exposed is the honeypot as we can see in the figure,
and the ICS activities that we report in Section 5 and in Section 6 are external and real. The snifing
node is on the same site of the honeypot, on which we launched an instance of our snifer. This
sniffer perpetually and exclusively listens to the exposed services, and generates files in pcap format.
We use an intrusion detection system that we have passively configured in such a way as to
generate, starting from the captured packets, industrial events in human readable format [
LOGistICS supports three types of Siemens PLCs: S7-300, S7-400 and S7-1200. To allow a user-friendly selection of the honeypot, we implemented a GUI as shown in Figure 2 capable of containerizing the selected class of PLC to be emulated, and quickly start it.
In the aforementioned Siemens PLCs, by default data-blocks are not protected and can accessed or written by users [25]. To test the degree of interaction before the exposure phase to the Internet (see Section 5), we implemented a C++ master that executed requests to the considered PLCs. Snap7 provides a sample master that is able to query a physical PLC: for example, by retrieving the PLC version and list of data-blocks. We enhanced the master with the purpose to enable the interaction with the password-protection mode of a PLC. We implemented a module in our Snap7 master, which returns three values concerning the CPU protection level, defined as Byte in the firmware. The array of Byte SZL W_16_0232 index W_16_0004 contains the protection levels and position of the operating mode selectors. By exchanging messages between our own honeypot and the master, we were able to evaluate the security of the PLC, and thus modify the honeypot answer in order to make it authentic, i.e., more similar to a real PLC.
This module is implemented on the snifing node, reconstruct a sequence of industrial commands invoked by the attacker in chronological order, whose is identified through IP address and autonomous system number (ASN) fields. The researcher is able to choose his time window, reducing or increasing depending on the type of analysis to conduct. In addition to attack patterns, the module can be well suited for analyzing sequence similarities [26].
In order to evaluate LOGistICS, we deployed it towards the Internet for almost two months. The
most frequent Modbus event we recorded was Read Device Identification invoked using function
code 43. This encapsulation mechanism allows to transfer predefined and reserved fields: reserved
function codes are implemented by companies and are not available for public use. In addition to
being a field that is commonly read by search engines, it also corresponds to the first stage (i.e.,
reconnaissance) of the ICS killchain [27]. This stage is usually conducted both actively using
reconnaissance tools, and passively through search engines such as Shodan or other services that allow for
investigating the targeted resource without interacting directly with it. We were able to detect the
stealth scans exception. In fact, using Wireshark we identified this kind of activity by following the
SYN → SYN/ACK → RST pattern [
During the classification of industrial trafic, we found that there were many more potentially harmful Modbus events (274) than S7Comm (6), excluding TCP SYN scans as described in Remark 1. By referring to the Modbus service, we categorized the requests such as “Report Slave ID”, “Device ID” and “Half-Open Scan” as benign. However, we consider read requests other than those listed above to be disruptive, such as read coils and registers, which may contain confidential information. Concerning S7comm, we considered read requests to the S7Comm protocol as not malicious, since they are mostly performed by periodic scanners, with the exception of those that concern the CPU protection level. Any S7Comm write request, including exceptions, was clearly treated as malicious, regardless of the service. The high number of Modbus requests classified as malicious can be explained by the fact that i) the interaction with a Modbus PLC, by design, can involve multiple coils and registers, and ii) Modbus is now an open standard (unlike S7Comm), which makes it easier to write a script that brute-forces against all the registers.
In order to characterize the actors we outline its sequence of commands (i.e., the host behavior) grouped by IP address. For each host, the sequence of commands executed was captured only once, and there were no recurring activities from the same IP during the high-intensity periods. We discovered this by grouping events initially by a certain time slot, and subsequently by 13The lack of synchronization could be due to malicious intent, such as the TCP SYN Flood attack.
ASN 55536 9009 29073 10439 10439
Organization
Pacswitch
M247 IP Volume CARI.net CARI.net day, noting that the sequence of commands remained unchanged. We believe this is due to the duration of the experiment, as in general the port scanners repeat the same activities on a monthly basis. We represented the encoded sequence of commands for hosts related to Modbus requests. We consider 5 of these command patterns as relevant, and we show them in Table 3, where the superscript on each command represents how many times it has been invoked. Each of these patterns (P) was logged on a diferent day, as reported by Table 3.
We can clearly distinguish the recurring scanners with the harassing actors during the initial phase of communication. The actors belonging to the CARI.net and IP Volume organization have an almost identical behavior, and start their activity by making Report Slave ID and Read Device Identification requests. We could remove the first two commands, as typically a couple of read requests (slave and device information) are needed to know how to compromise the device. But as we can see in Table 3, this can be argued. In fact, M247 and Pacswitch hosts execute Read Device Identification request only after making an illegal reading of the registers (note that M247 performed 160 TCP SYN requests, which may indicate a suspicious behavior). For what concerns the activities towards the S7Comm protocol, we identified in a similar way the most interesting patterns during the periods of greatest intensity. Diferently to what emerged with Modbus activities, very similar S7Comm patterns were recorded belonging to hosts of the same organization. Moreover, some actors performed the exact same sequence during the period of intense activity. In order to simplify the representation, we assume with regard to the S7Comm activities, that the hosts of an Autonomous System have the same behavior.
In Table 4 we represent the sequence of commands performed by Organization hosts, grouped by high-intensity activity period. Regarding the S7Comm service, we were able to reconstruct the complete communication between the actors and the honeypot, reporting in chronological order the response to each request made. As the results show, DigitalOcean hosts that make two Read SZL requests followed by the Setup Communication request are recurring scanners. The behavior of the Pacswitch host difers from the aforementioned host, which instead of running a port-scan tries to write directly to our honeypot. The unrecognized pattern of the host belonging to IP Volume inc. is explained in Remark 1.
With the goal of analyzing attacker behavior, we presented LOGistICS, a multi-component system for safeguarding critical infrastructures. The system core is a new medium-interaction honeypot that simulates Modbus and S7Comm, respectively. These are some of the most commonly used protocols in industrial PLCs. This paper discusses the behavior of ICS actors when interacting with the honeypot, which is found to be less detectable by attackers than similar proposals, and indistinguishable from real PLCs when using automated attack tools. We tested how LOGistICS works by exposing it to the Internet and found that most of the requests made are not malicious. However, the people who make such requests do not always have the same behavior, which difers depending on the type of information they read. As for web crawlers, we figured out that the majority of them have the same behavior towards ICS devices; they essentially difer in the frequency of reading the fields that identify the device. Moreover, we found that besides periodic scanners (e.g. Shodan and Censys) who conclude their activity once the reconnaissance stage has been completed, there exist attacks trying to write data and control the PLC without knowing the victim, as if they already knew the necessary information. Our intuition is that these actors obtained them by looking for them indirectly from search engines, activity that would be classified by the intrusion detection systems as not suspicious (in the case of web crawlers are whitelisted). We collected several ideas about possible extensions as future work. For instance, we would like to leverage LOGistICS with SIEM-based technologies such as one based on the Elastic Stack.14 The aim is to leave the honeypot running also in production environments (e.g. nuclear power plants), comparing it with that already obtained towards research environments. In this way, we can enhance our framework providing a more focused real-time alerting module. In addition, besides improving the extensibility and configurability of the honeypot, in the future we would like to add deception-technology modules and protocols such as i) BACnet (Building Automation and Control), which finds its application in ventilating, heating, access control, lightning, air-conditioning and fire detection systems; and ii) DNP3 (Distributed Network Protocol), which is is widely adopted in the USA and Canada, and it is used by electric and water companies.
This work has been partially supported by: project “RACRA”- funded by Ricerca di Base 2018-2019, Univeristy of Perugia Project BLOCKCHAIN4FOODCHAIN: funded by Ricerca di Base 2020, Univeristy of Perugia Project DopUP - REGIONE UMBRIA PSR 2014-2020. 14Elastic SIEM: https://www.elastic.co/siem/. [20] A. Kleinman, A. 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 (2014) 37. [21] M. Rose, D. Cass, ISO Transport Service on top of the TCP-Version 3, Technical Report,
RFC 1006, Northrop Research and Technology Center, 1987. [22] D. Nardella, Snap7, 2018. [23] A. Sentcha, Libnodave–exchange data with siemens plc, 2015. [24] Siemens, Siemens block description, http://siemens-plc-programming.blogspot.com/p /load-memory-work-memory-blocks-in-user.html, 2010. [25] E. Biham, S. Bitan, A. Carmel, A. Dankner, U. Malin, A. Wool, Rogue7: Rogue engineering-station attacks on s7 simatic plcs, Mandalay Bay/Las Vegas (2019). [26] A. Kashtalian, T. Sochor, K-means clustering of honeynet data with unsupervised representation learning., in: IntelITSIS, 2021, pp. 439–449. [27] M. J. Assante, R. M. Lee, The industrial control system cyber kill chain, SANS Institute InfoSec Reading Room 1 (2015).