Target Discovery Differentials for 0-Knowledge Detection of ICS Malware James Halvorsen and Julian L. Rrushi Department of Computer Science Western Washington University 516 High Street, Bellingham, WA 98225 Email: {halvorj3, julian.rrushi}@wwu.edu Abstract—In this paper we present an unconventional anti ICS-malware approach. We leverage a factor that appears to be overlooked as of this writing, namely that ICS malware often infect machines which do not run any functions related to industrial process control. These may be, for example, business machines in the enterprise networks of power utility companies, or even random machines on the Internet. Because ICS environments use special-purpose communication protocols, it is highly unlikely that any application code on those machines will send or receive network traffic through an ICS communication protocol. On the other hand, ICS malware discover their targets via searches that initiate ICS communication protocol traffic. Our approach uses a kernel filter driver to analyze the network traffic that flows through a real NIC. The kernel filter driver works with a module that uses in-kernel ICS protocol signatures to recognize ICS protocol traffic embedded within the network traffic in question. Our approach can detect 0-day malware on machines that are unrelated to industrial process control, without any prior knowledge of their internal code and data. We performed extensive testing against malware samples involved in recent cyber attack campaigns, as well as safety and efficiency tests, and thus discuss the findings in the paper.

I. I NTRODUCTION The ultimate objective of industrial control system (ICS) malware is to cause physical destruction of digitally controlled physical systems such as the electrical power grid. Some of ICS malware do not initiate physical damage right away, but instead spy on physical processes in preparation for a future attack. The corpus of ICS malware that are publicly known as of this writing includes samples of Dragonfly [1], BlackEnergy [2], Stuxnet [3], and IronGate [4]. These ICS malware contain exploits, command and control code, and I/O interception and interposition code. They also have code that searches for target machines prior to going after them. Furthermore, these ICS malware commonly have rogue ICS client modules, which communicate with target ICS machines over the network through an industrial communication protocol similarly to their legitimate ICS software counterparts. The techniques used by these ICS malware to hack their initial targets include the following: • E-mail spear phishing, with attachments that can be malicious Portable Document Format (PDF) files containing embedded JavaScript code, or Microsoft Office files infected through the macro functionality. [Dragonfly and BlackEnergy] • Watering hole attacks injecting an HTML iframe into several websites related to energy, and running the LightsOut exploit kit. [Dragonfly]

• •

Trojanized ICS software that users download from compromised ICS provider websites, and install voluntarily on their machines. [Dragonfly] Direct vulnerability exploitation over the network to gain control over a target machine, and then locally to escalate the privileges on the compromised machine. [Stuxnet and IronGate]

The carriers of the ICS malware propagation were networks and removable flash drives. The initial targets of these ICS malware were Windows machines. We seek a 0-knowledge approach to detect any ICS malware on Windows machines in production on the first encounter with them. 0-knowledge detection refers to detecting ICS malware without any prior knowledge of their code, data, and exploitation and propagation techniques. Decoy network interface cards (DNICs) can attain 0-knowledge detection of malware, however they are only effective in cases where the malware transmits traffic over a DNIC [5]. If the malware communicates over a real NIC, it dodges detection as its network traffic is beyond the reach of DNICs. Because of safety concerns, a DNIC is not involved in the processing of network traffic that is done by a real NIC. Even if it were, it could not function, given that the malicious network traffic that travels over a real NIC is intertwined with legitimate traffic. Contribution. We present a 0-knowledge approach to effectively detect ICS malware that conduct their I/O over a real NIC. We leverage a factor that appears to be overlooked as of this writing, namely that ICS malware often infect machines which do not run any functions related to industrial process control. These may be, for example, business machines in the enterprise networks of power utility companies, or even random machines on the Internet. Because ICS environments use special-purpose communication protocols, it is highly unlikely that any application code on those machines will send or receive network traffic through an ICS communication protocol. On the other hand, ICS malware discover their targets via searches that initiate ICS communication protocol traffic. Our approach uses a kernel filter driver to analyze the I/O traffic that flows through a real NIC. The kernel filter driver works with a module that uses in-kernel ICS protocol signatures to recognize ICS protocol traffic embedded within the I/O traffic in question. We have developed in-kernel ICS protocol signatures for the Distributed Network Protocol (DNP3) [6], the S7comm protocol [7], the IEC 61850 protocol [8], and the Object Linking and Embedding (OLE) for Process Control (OPC) protocol [9]. Novelty. This work is the first to explore target discovery

differentials in the kernel for the purpose of ICS malware detection. To the best of our knowledge, as of this writing, no other works have explored the uniqueness of ICS communication protocol traffic on machines that are not involved in industrial process control. Paper organization. The remaining of this paper is organized as follows. In Section II we describe the main ideas of our approach, as well as its architecture and main techniques. In Section III we describe an evaluation of the performance of our approach in a testbed that resembles an electrical substation. In Section IV we discuss related work in the areas of anti-malware and cyber deception. In Section V we summarize our findings, and conclude the paper. Our work currently defends from ICS malware that operate in user space. Future work will extend our approach to counter ICS malware that operate also in kernel space. The research challenge there is to protect the kernel code and data of our tools from the malware. This is a concern that applies to all kernel-level anti-malware tools in general, including commercial anti-malware systems. Note that the operating system of reference of this work is Windows. II. A PPROACH A. Network Traffic Extraction All outgoing network traffic is extracted in flight. Most of the network traffic, which is sent or received by a NIC on a machine unrelated to ICS environments, will not be of interest to our approach. The situation is reversed when the machine is infected by ICS malware, and is subsequently used to search for other targets over the network. Due to the 0-knowledge nature of this work, we do not have any indicators of suspicious code executions. We do not know a priori a good time to start analyzing network traffic. Consequently, our approach extracts all outgoing network traffic by the means of a kernel filter driver, as depicted in Figure 1. Outgoing network traffic is intercepted right after being processed by the Internet protocol suite of drivers. Incoming network traffic is not extracted for reasons that we discuss later in this section. As most I/O devices on Windows, a NIC is operated by a stack of drivers. With reference to Figure 1, processes that are running in user space issue operations on sockets to send and receive data. Sockets are similar to file handles in that they refer to the top of the driver stack. In the kernel, the request is packaged into a data structure called I/O request packet [10], which is then processed by one more drivers of the stack. These drivers process Ethernet frames, and subsequently pass them down the stack for other drivers to process. One of those drivers is exactly the filter driver, which is now given direct access to the Ethernet frames. This is when our approach determines whether or not the Ethernet frames are related to an ICS protocol. All analyses need to be fast and hence simple, otherwise the timing of legitimate network traffic would be disrupted. The network traffic generated by real-time applications is the most sensitive to delays due to quality of service requirements. NDIS APIs and data structures are helpful. All drivers in a NIC’s stack do important processing, however the miniport driver depicted in Figure 1 has the most knowledge of the NIC and thus is able to handle tasks that are specific to it. We worked with a miniport driver that relies on the network driver interface specification (NDIS) library [11]. This allows us to use a filter driver that is coupled with the NDIS library

Fig. 1: Driver stack of a real NIC. as well. The NDIS library is implemented by Microsoft as part of the Windows Driver Model. Its APIs handle tasks that are common to all NICs supported by Windows. By doing most of the work through those APIs, we leave all ICS-unrelated Ethernet frames just like the NDIS port driver expects them to be, as if the packet filtering never took place. In other words, NDIS enables packet filtering to be compatible with, and safe to, the NDIS port driver. An important aspect of this work is the feasibility of the various packet extractions, ICS protocol signature matches, and possible ICS protocol emulations, that comprise our approach. Several of the data structures that pertain to Ethernet frames in flight to the NIC have opaque fields, which are not supposed to be accessed directly by kernel drivers. By calling APIs provided by the NDIS library, we can access the opaque fields to extract Ethernet frames. Most of those APIs are the same APIs that are called by the NDIS miniport driver to extract Ethernet frames for transmission over the NIC. There are no obstacles with regards to forwarding Ethernet frames to the NDIS miniport driver. The NDIS library enables the miniport driver to provide an interface to higher-level drivers. It is that specific interface that allows us to feed all network traffic to the miniport driver without any loss of Ethernet frames. Extracting incoming network traffic is approximately equivalent to a honeypot. We considered the extraction of incoming packets in addition to outgoing packets. There are two different defense scopes involved in this analysis, namely detecting ICS malware that run on the machine equipped with our approach, and detecting ICS malware that run elsewhere and that make network contact with the machine equipped with our approach to scan for ICS network services. In the former case, the outgoing network traffic generated by ICSunrelated applications suffices for our approach to reach to the conclusion that those applications are not ICS malware. Similarly, when ICS malware generate outgoing network traffic, our approach does not need any other data to detect them. The clues are all in the outgoing network traffic. It turns out that sometime outgoing network traffic, especially TCP traffic, may be too limited in size, which hinders the effectiveness of ICS protocol signatures. ICS protocol emulations can prolong the interaction with a target application and thus make it generate

more network traffic. In the latter case, we could emulate ICS network services in the kernel by responding to network requests for ICS data. If any of the ICS protocol signatures matches the incoming network traffic, we can log the Internet Protocol (IP) address of the machine that was used to send the network traffic. Nevertheless, this capability would be functionally similar to honeypots. We could simply extend Honeyd, BitSaucer, or Shark, to communicate through ICS protocols, and obtain the same level of defense. The main limitation of honeypots is that they are easy to detect. A honeypot does not send or receive network traffic, which is an observation that malware could be able to make based on sniffed network traffic. The line of work that we discussed in [5] can emulate the passage of network traffic through a NIC without crossing the boundaries of the kernel on the machine. Let us assume for a moment that our approach runs on machine A, where all outgoing network traffic is analyzed against ICS protocol signatures. If we wanted to analyze incoming network traffic as well, and also do better than honeypots, we could emulate ICS protocol packets on a machine B to make it appear as if an application on machine B were accessing an ICS network service on machine A. The deceptive emulation aims at redirecting possible ICS malware on machine B into contacting machine A. If the redirection on machine B is successful, the incoming network traffic on machine A will match ICS protocol signatures, leading to detection of the ICS malware running on machine B. Nevertheless, if the redirection on machine B is successful, we can run ICS protocol signatures against the same network traffic on machine B anyway. The results would be the same, except for the fact that the scrutinized network traffic would be outgoing on machine B rather than incoming on machine A. To protect machine B, we only need to run our approach along with the redirection by deception capability on machine B. Running our approach on machine A only serves the purpose of protecting machine A itself and hence not at all machine B. B. Payload Analysis Packets live in NDIS data structures. When it is the filter driver’s turn to process the network traffic in flight, each network packet resides in a data structure called NET_BUFFER. The entire traffic flow is stored in a linked list of NET_BUFFER structures called NET_BUFFER_LIST. The filter driver accesses a member of the NET_BUFFER structure called NET_BUFFER_HEADER structure to retrieve a network packet. More specifically, the network packet is formatted as a NET_BUFFER_DATA structure, which contains memory descriptor lists (MDLs) that map a virtual memory buffer to physical memory. That buffer is where the network data are read from by the filter driver. The reader is referred to [11] for a detailed description of these nested data structures. Once an Ethernet packet is extracted from its buffer, we can read through the packet headers to identify the transport protocol, namely TCP or UDP, the destination port number, as well as the payload if present. Existing versus emulated ICS machines. When targeted by ICS malware, existing ICS machines respond to queries for themselves, whereas protocol emulation responds on behalf of non-existing ICS machines. A follow-up to the initial discovery packets sent by ICS malware is, in most cases, paramount to enabling the application of ICS protocol signatures. For

instance, ICS malware that initiates a three-way handshake with a machine over the network to discover whether or not that target is a DNP3 station, will receive a FIN packet right away if the target does not support the DNP3 protocol. Without any exchanges of data, the ICS protocol signatures will have no payloads at all to analyze. In the case of other ICS malware, such as OPC malware, the three-way-handshake may complete, however the absence of OPC data from the replies will cause the malware to tear down the connection at some point during the network interaction. After discovering a server over the network, OPC malware send queries to determine whether or not the target machine hosts Component Object Model (COM) objects and interfaces. These network requests per se are not usable to the application of ICS protocol signatures, as many legitimate applications may send queries over the network to discover COM objects on a machine. If COM is present on a target machine, OPC malware send other queries to determine if any of the COM objects on the target machine are OPC server objects. These are the queries that the ICS protocol signatures can match. However, OPC malware will not go as far as issuing those queries if the target machine does not host COM objects. This is where ICS protocol emulation can intervene. It makes ICS protocol signatures applicable by sustaining interaction with ICS malware long enough to make them generate ICS specific network traffic. When running our approach on a machine that is not related to an ICS environment, we do not exclude the possibility that other machines on the same local area network, as well as any other machines that are reachable over the network by the machine at hand, are directly involved in industrial process control. For example, the business network of a power utility company may have several machines that do not participate in the monitoring and control of the electrical power grid, but still are quite useful due to their auxiliary computations. If any those machines are infected by ICS malware, then the network requests sent by those malware towards ICS-related machines will most likely get valid replies. With reference to Figure 1, the ICS protocol emulation is not invoked, since the target machine will take care of the interaction with the ICS malware on its own. Our approach simply calls the ICS protocol signatures on outgoing network traffic to search for a match. We wrote earlier in this paper that analyzing incoming network traffic would be redundant in this work. Any TCP flow initiated by another machine towards the machine at hand, or any UDP packet sent by another machine and that is not a direct response to a UDP packet sent by the machine at hand, will not be extracted and analyzed. This principle extends to network traffic that another machine sends to the machine at hand as a response to network traffic generated by the latter. Nevertheless, there is an exception. One of the first actions taken by our approach is to inspect the destination port of outgoing network traffic. As all networking protocols, ICS communication protocols have default ports. When our approach sees the machine at hand initiating a network communication with another machine on a port that is known to be the default port of an ICS protocol, it needs to know if the other machine will be supporting the ICS protocol interaction, which will open the way to the application of our ICS protocol signatures. Replies contained in incoming network traffic are

useful. To make that determination, our approach needs to extract the initial replies generated by the other machine. With reference to the examples that we gave previously in this section, analyzing those packets reveals whether or not the other machine completes the three-way-handshake, and subsequently provides a valid DNP3 reply or provides a list of COM objects and interfaces for DNP3 and OPC malware, respectively. If the other machine rejects the communication on the default port of an ICS protocol, our approach drops its teardown packets and instead invokes the ICS protocol emulator, as shown in Figure 1. The ICS protocol emulator takes over the communication, and starts mimicking a valid ICS target machine. This produces the same effect as a real ICS machine being contacted by ICS malware, namely sustains interaction long enough for the ICS protocol signatures to do their work. We considered engaging an ICS protocol emulator not only when ICS malware send network traffic to the default port of an ICS protocol, but also when such traffic is sent to any port on which the other machine declines to communicate. Nevertheless, this possible extension could interfere with legitimate network communications. Legitimate applications occasionally make connections to other machines on ports that may result to be closed. Consider for example a system administrator, who runs the netcat tool to find out whether or not another machine on the network accepts requests on a given port. If that machine does not, then the ICS protocol emulator would take over the connection and respond. This would be misleading to the system administrator. For reasons like these, we decided to keep the scope of ICS protocol emulation within the default ports of ICS protocols only. C. In-kernel ICS Protocol Signatures Built as decision trees with modest effort. ICS protocol signatures are implemented in the kernel as decision trees, and are built manually based on ICS protocol specifications. Decision trees can be trained to recognize an ICS protocol by observing network traffic, however a specification-based approach can obtain higher accuracy. The amount of effort needed to develop ICS protocol signatures manually is a determining factor with regards to the scalability of our approach, and was a great unknown at the beginning of this work. Nevertheless, related work on specification-based intrusion detection found that an approach of that kind can be developed with modest efforts [12]. While our approach is different than specification-based intrusion detection, its ICS protocol signatures are built similarly to the rules of a specification-based network detector. Furthermore, our decision trees only need to be able to recognize an ICS protocol, whereas a specificationbased network detector needs to perform extensive checks to detect violations of a network protocol. Overall, our decision trees can be built with a reasonable amount of effort. As an aside, none of the ICS malware samples that are publicly available for analysis violated the specification of any ICS protocols as they carried out their attacks. Some of the distinguishing features are mapped. We need to encode into a decision tree the unique features of an ICS protocol, so that we can recognize its network traffic without errors. Some ICS protocols have fields that act as explicit magic numbers, while others have function codes located at static offsets relative to the beginning of a packet payload. Function codes are fields that indicate a specific operation to be performed. Byte counts or length fields are also

a distinguishing feature. If their value matches the length of a defined portion of data in the packet payload, the probability that the match happened purely by chance is very low. ICS protocols typically use an error-detecting algorithm to detect accidental changes to data in transit. At the time of analysis by our approach, outgoing network packets have not left the sender yet, and hence have not started their travel over physical media. Consequently, the probability that accidental data changes have occurred until that time is again very low. A cyclic redundancy code (CRC) field in the packet payload, which matches the CRC of a portion of data as defined in the ICS protocol specification, is yet another guarantee that the ICS protocol is indeed the one identified. Some fields have well defined semantics, which can be checked for consistency. Machine addresses within the payload are also useful. Some ICS protocols use static byte sequences as identifiers, which are easy to check. For example, OPC uses specific 128bit values to refer to Distributed Component Object Model (DCOM) classes and interfaces. The unique features of an ICS protocol may be numerous, however we do not encode all of them in a decision tree. Because the analysis of a packet payload needs to be fast, we seek to obtain the highest probability of recognition with the lowest number of checks possible. We used extensive testing on network traffic that was known a priori to belong to a given ICS protocol, in order to determine the optimal size of a decision tree. Several rounds of tests are typically needed to calibrate the feature composition of a decision tree. An example helps. We now discuss the decision tree that functions as an ICS protocol signature for DNP3. A part of it is depicted in Figure 2. Upon observation of an outgoing TCP syn packet bound for port 20000, i.e., the default port for DNP3, our approach awaits the reply. If the reply is a TCP syn/ack packet, it means that the target machine has a network service accepting connections on port 20000. Recall that the underlying assumption is that the possibly compromised machine is not involved in industrial process control, but other machines on the same network or on other networks may very well be. Once the three-way handshake is complete, our approach analyzes the first outgoing network packet with a payload by running the decision tree checks. If otherwise the reply is a TCP rst/ack packet, or an ICMP packet indicating destination unreachable or communication administratively filtered, our approach drops the packet at hand and subsequently engages the DNP3 emulator to take over the connection as the target machine. The top node of the decision tree checks on the first two bytes, which are called start bytes. They are always 0x0564. If the start bytes match, the flow reaches a length verification node. There is a one-byte length field in the DNP3 link layer, whose value should be equal to a count of the remaining bytes, not including the bytes of all CRC fields present in the network packet. If the length verification passes, we enter a node that pertains to verifying the correctness of DNP3 source and destination addresses. The generalization in the middle of Figure 2 refers to other checks that may or may not be included, depending on the calibration of the decision tree. An example is the validation of the semantics of the control field. Checks include direction going from master to outstation, and data flow control indicating that the receive buffer is available. A master typically resides in the control center, whereas outstations are located on the field. In the last

In fact, based on recent ICS malware campaigns, it is common for ICS malware to infect machines that are unrelated to ICS environments before they reach their intended targets. To scan or not to scan. ICS-unrelated machines that are not of immediate interest to an ICS attack are easy to discover too. For example, a banking server is relatively easy to profile based on the financial transactions that it computes and carries out. Nevertheless, a banking server is unlikely to provide immediate network access to pertinent machines, therefore the ICS malware may avoid scanning local machines for ICS protocol support. Conversely, a compromised banking server may be used as a trampoline into the machines of contractors that work also for power utility companies. After all, information technology consulting firms serve multiple clients, often in a diverse array of industry sectors. In any case, ICS malware may leverage a machine of no immediate interest, such as a banking server in our previous example, to scan and attack other machines from a long range on the Internet. Can interoperate with deception and fake deception. An assessment of the attack value of a compromised machine by ICS malware can be blurred by deception techniques that operate in the operating system. We can create decoy processes that appear to be ICS applications running on the machine. While those decoy processes were designed to work with a DNIC, they can be adapted to work with a real NIC due to their being safe and hence non-intrusive. By deploying those decoy processes on a machine unrelated to ICS environments, we make that machine appear as if it were ICS-related. Furthermore, decoy processes can be created to appear as nonICS-related, such as those found on a banking server. If we deploy those decoy processes on a machine that is related to an ICS environment, we make that machine appear as if if were not. This creates confusion for the ICS malware, which may result in uninformed decisions as to how to leverage the compromised machine to access digitally controlled physical systems.

Fig. 2: Excerpt from the decision tree data structure of a DNP3 protocol signature. part of the decision tree, we are validating the function code, which can only have specific values as defined in the DNP3 specification. D. Discussion Infected machines are easy to profile. Once ICS malware infects a machine that is unrelated to ICS environments, it can analyze various clues to determine what kind of computations are performed on that machine and hence what its primary use is. It becomes obvious that the compromised machine is not involved in direct process control as soon as processes, installed software, and data files, are inspected. Nevertheless, a finding of that kind would not lead ICS malware to abandon the compromised machine. Business machines in the enterprise networks of power utility companies are of high interest to attackers, since they typically provide immediate network access to the machines that monitor and control the power grid. The laptop computers of power utility contractors are another example of machines where ICS malware would want to stay.

III. VALIDATION We now discuss the evaluation of this work in terms of both effectiveness and safety, as well as the testbed in which the experiments were performed. Real-world ICS machines. We created a testbed that recreates the computer environment of a real-world electrical substation. All machines in the testbed were connected on a local area network. There were no connections to the outside world. The ICS machines in the testbed were all real, and are of the kind that are widely deployed in electrical substations in North America. Their main characteristics are summarized in Table I. More specifically, the SEL-487E-3 is an ICS that can monitor and protect a power transformer from electrical faults. It runs intelligent algorithms to detect various types of faults, and can take action in a timely manner by operating electrical circuit breakers and disconnect switches. The SEL421-4 can perform industrial automation functions. It includes 32 programmable elements for local control, remote control, automation latching, and protection latching. A SEL-421-4 can also conduct various functions to protect overhead electrical transmission lines and underground cables. The SEL-3355 conducts multiple substation functions too. It has an integrated human-machine interface (HMI), with a local display port. In this work, the SEL-3355 was used as a real-time automation

controller. The SEL-3355 polls the SEL-487E-3 and SEL421-4 to collect substation data from them. The S7-1500 is a programmable logic controller (PLC) from Siemens. It has I/O modules that can be directly attached to sensors and physical equipment, respectively. Substation testbed used DNP3, OPC, IEC 61850, MMS, and S7comm. The network communications between the SEL machines take place over the DNP3 and IEC 61850 protocols. IEC 61850 is a virtual protocol and thus cannot be used alone for concrete network communications. It needs an actual carrier protocol. Consequently, IEC 61850 is typically mapped to a protocol stack comprised of the Manufacturing Messaging Specification (MMS) [13], TCP/IP, and Ethernet. MMS was designed specifically for transferring in real time industrial process data and supervisory commands. MMS has object models and services that can easily accommodate those of the IEC 61850 standard. We integrated an engineering server into the testbed. The engineering server hosted an OPC server, which in turn ran an IEC 61850 protocol driver to get substation data from the ICSs. Tests ran on an ICS-unrelated machine. We added two ICS-unrelated machines to the testbed. One of them is a physical machine, while the other one is a virtual machine that runs on the physical machine at hand. The virtual machine had direct access to the physical network. Both of the ICSunrelated machines are typically used for general-purpose computing and thus have nothing to do with any aspect of industrial process control. They run no ICS software, and speak no ICS protocols. The physical ICS-unrelated machine ran our approach in its kernel. All ICS malware samples and other test code and commands were run on that machine as well. Before starting the actual testing, we let the ICS malware samples discover and attack a real target in the testbed. We did so to validate their effectiveness. After all, we needed to avoid testing this work against ineffective malware. Effectiveness. Firstly, we validated this work against malware samples involved in the Dragonfly cyber espionage campaign. There are many versions of those malware. We obtained those malware samples from public research malware repositories, and thus used those versions in our experiments. The various versions of the Havex ICS plugin are of particular interest to this work, since they all use OPC. We ran the malware samples one at a time, and observed whether or not our approach would report positive detection of each sample. All malware samples that we ran managed to discover the real target, namely the engineering server. Those samples triggered a match with the OPC protocol signature when attempting to connect to the OPC server and collect over OPC the substation data that originated in the protective relays over IEC 61850. Similar results were obtained when the ICS malware samples targeted the virtual ICS-unrelated machine. Secondly, we emulated test exploits against the physical ICS-unrelated machine. Those tests were preceded by a scanning with the nmap tool of a range of internet protocol (IP) addresses and their services in the lab. We also emulated the malware installation phase, in which the test exploit injected and ran a dropper on the physical ICS-unrelated machine. As in traditional malware, the dropper is responsible for installing malware modules on the compromised machine. A test malware module ran the executable version of a Ruby script on the physical ICS-unrelated machine. If allowed, the Ruby script in question could connect to DNP3 machines,

Fig. 3: Amounts of DNP3 payloads detected by the approach. request all of the objects on that machine, and also write to various fields. It then could read the data back to ensure the writes are persistent. All of this test code was detected when connecting to DNP3-capable machines in the testbed. An occurrence of DNP3 arrivals on the NDIS filter driver is depicted in Figure 3. Detection happens on the first packet. The Ruby script was also launched against the virtual ICS-unrelated machine. To implement the DNP3 emulator, we extended an NDIS driver to incorporate a barebones DNP3 server. This server can respond to read and write requests on two different types of DNP3 objects, namely a single bit binary input and a 32-bit analog input without flag, as well as requests for all data of some priority class, which should return all of the objects on the server. As this is still a prototype, most DNP3 operations are still unsupported. However, the program should nonetheless serve valid responses indicating that the operation is not supported, so as to appear as a valid DNP3 server to prospective malware. From this, it can be deduced that our DNP3 emulator reproduces some DNP3 behavior to a potential attacker, rather than simply providing a valid response to all requests. A more thorough emulator might simulate the entire DNP3 protocol, despite not actually interacting with real hardware, to provide a more convincing trap for malware to target. Thirdly, we downloaded S7comm sample captures from a Wireshark public repository [14]. We also used an S7comm packet capture provided by a student in our group, who was working in the lab on an unrelated project. We replayed the packets of the S7comm sample captures towards the S7-1500, and towards the virtual ICS-unrelated machine, triggering the S7comm signature in both cases. In addition, we dowloaded an MMS sample capture from the Wireshark repository as well. We replayed the MMS sample capture against both the IEC 61850-capable machines and the virtual ICS-unrelated machine. Detection was obtained in both cases. An example of S7comm arrivals on the NDIS filter driver is depicted in Figure 4. As before, detection happens upon analyzing the first packet. Safety. This part of the validation consisted of testing for false positives. Firstly, we used the physical ICS-unrelated machine for a full day to do real work. Some of the work re-

TABLE I: Testbed machines and their main ICS protocols. Machine SEL-3555 SEL-487E-3 SEL-421-4 General-purpose Windows machine General-purpose Windows machine General-purpose Windows machine (Virtual) SIMATIC S7-1500

ICS function Automation controller Transformer protection relay Protection, automation, and control OPC server, PG None None Programmable logic controller

Fig. 4: Amounts of S7comm payloads detected by the approach. sulted in generation of network traffic over the NIC. Secondly, we downloaded sample captures for all applicable non-ICS protocols from the Wireshark repository referenced in [14]. We then replayed those packet captures over the NIC, one at a time. None of the network packets flying through the NIC triggered any of the ICS protocol signatures. Efficiency. The use for a full day of the physical ICSunrelated machine did not show visible network delays. We ran Skype on the machine and had multiple test conversations. No video or audio delays were observed. The time overhead is in the order of nanoseconds. An example is given in Figure 5. IV. R ELATED W ORK A. Anti-Malware The typical techniques used for protecting against malware on ICS machines vary substantially from those used in general purpose anti-malware systems. Zimmer et al. note the impracticality of applying general purpose protection methods to real-time systems [15]. Among their reasons include the use of non-standard input routines beyond POSIX library routines that may be exploitable. They also note that signature-based methods are easily defeated with spoofing, as the low powered hardware typically used with embedded devices cannot accommodate strong public/private key pair signatures. It can further be argued that signature-based approaches are not suitable for protecting ICS systems, as they are unable to handle zero day attacks, which are common in ICS [16]. Yoon et al. make similar points about the difficulties imposed by the more limited resources, but note that because these systems are predictable by design, an anomaly-based approach will be effective [17]. Both Zimmer and Yoon propose methods for detecting attacks on these systems by using

ICS protocol DNP3, IEC 61850 DNP3, IEC 61850 DNP3, IEC 61850 DNP3, OPC, IEC 61850 None None S7comm

Fig. 5: An example of time overhead. anomaly-based detection methods, with Zimmer focusing on the worst case execution time (WCET) of programs on the realtime system, and Yoon focusing on abnormalities in memory access. Both Zimmer and Yoon’s approaches are focused on performing anomaly detection on real time systems themselves. Within an ICS, however, there are multiple types of threats to be addressed. In a paper on Challenges and opportunities in securing industrial control systems, Hadziosmanovic et. al classify the threats to ICS into two main categories: systemrelated threats and process-related threats [18]. They consider system-related threats to be those that target low level software vulnerabilities, and mostly affect the PLCs that control the industrial process, and the servers that they communicate with. Process-related threats, however, exploit weak process controls (such as inputting a wrong ratio of chemical components to cause a process failure), and imply the attacker has gained control over a client machine. Absent from their analysis of these threats, however, are machines that may be on the same network as the client machines, but which are not directly involved in ICS activities. Malware such as Dragonfly have attacked business machines in order to collect information on ICS activities. Although Dragonfly did not cause any damage to property, it suggests that ICS machines are not wholly self-contained, and are vulnerable to attack from the outside via other computers on the network. Our approach is able to serve as a first line of defense, detecting these types of threats before they can affect ICS machines. B. Cyber Deception One of the more important developments in cyber deception is the concept of the honeypot. There are a number of

works in this field, including variants for industrial process control networks. One notable example, implemented by Buza et al. is a PLC honeypot known as CryPLH [19]. CryPLH implements several PLC services that are integrated into a Linux-based VM, which forms the honeypot. Another PLC honeypot is CONPOT, which was implemented by Rist et al. [20]. CONPOT relies on Python scripts to emulate a range of common industrial communication protocols. CryPLH, CONPOT, and other industrial honeypots along the same line, focus on presenting a convincing PLC interface once an attacker has actively connected to the honeypot. They do not, however, provide a means to get the attacker to pursue the honeypot in the first place, nor can they sustain interactions with the attacker after an initial exchange of network packets. By comparison, our work seeks to create a more convincing target by simulating a greater feature set, which can sustain long term communications with the attacker. CryPLH, CONPOT, and other industrial honeypots are characterized by an absence of system and network activity. By contrast, however, ICS machines, such as protective relays in electrical substations, are constantly in action. They read from sensors, analyze data, submit reports to human operators, and send commands to actuators. Industrial process control is a highly dynamic operation full of system and network activities. Industrial honeypots cannot operate on ICS machines in production, and thus need dedicated computers to run on. Furthermore, the substation data that are stored on flash drives in ICS machines, or that are transmitted over the network, obey the physics laws of the diverse physical processes and equipment operations that take place in an electrical substation. Industrial honeypots do not have the capability to reproduce and expose control system dynamics for the purpose of defensive deception against ICS malware. Other research has been done on cyber deception outside of the honeypot concept. Rowe designed two taxonomies for cyber deception based on military principles of deception, as well as on case theory in linguistics [21]. Rowe enumerates over the syntactic cases in a language, and then associates them with a possibility for cyber deception, if such a possibility exists. He then provides a score from 1 to 10 on the suitability of this deception for defense or offense. Future anti-malware systems, honeypots included, may have to make use of many of Rowe’s deception techniques to protect ICS machines from advanced malware in the future.

ACKNOWLEDGEMENTS This work was supported in part by the Defence R&D Canada, and in part by the U.S. Office of Naval Research through a DURIP grant with contract number N00014-15-12891. All views are those of the authors only. [1] [2] [3]

[4]

[5]

[6] [7]

[8] [9] [10] [11] [12] [13] [14] [15]

[16]

[17]

V. C ONCLUSIONS There are many ways in which anti ICS-malware systems will have to improve to address future attacks on cyberphysical systems. ICS malware does not always begin its existence within machines performing ICS operations. A successful defense will have to incorporate detection mechanisms such as ours on every type of machine where malware may appear. Because legitimate ICS software is special-purpose, it should not be affected by the introduction of new ICS-specific approaches, particularly on those machines not involved with ICS to begin with. Since ICS malware must search for its targets over the network, it may be discovered quickly as it interacts with devices that no legitimate software should interact with. From this early detection, threats may be stopped before they have any chance to cause damage, or even obtain information on legitimate ICS machines.

[18]

[19]

[20]

[21]

R EFERENCES Symantec, ”Dragonfly: Cyberespionage Attacks Against Energy Suppliers”, July 2014, Available online. R. M. Lee, M. J. Assante, and T. Conway, ”Analysis of the Cyber Attack on the Ukrainian Power Grid”, Available online. N. Falliere, L. O. Murchu, and E. Chien, ”W32.Stuxnet Dossier”, Symantec Security Response, version 1.4, February 2011, Available online. J. Homan, S. McBride, and R. Caldwell, ”IronGate ICS malware: Nothing to see here... Masking malicious activity on SCADA systems”, FireEye threat research blog, June 2016, Available online. J. Rrushi, ”NIC Displays to Thwart Malware Attacks Mounted from within the OS”, Journal of Computers & Security, vol. 61, issue C, pp. 59–71, August 2016. DNP Technical Committee, ”Distributed Network Protocol”, Available online. Siemens, ”What properties, advantages and special features does the S7 protocol offer?”, Available online at https://support.industry.siemens.com/cs/document/26483647/ what-properties-advantages-and-special-features-does-the-s7-protocol-offer-? dti=0&lc=en-WW International Electrotechnical Commission, ”IEC 61850: Communication Networks and Systems in Substations”, part 1 through 9, 2004. J. Lange, F. Iwanitz, and T. Burke, ”OPC - From Data Access to Unified Architecture”, 4th edition, VDE VERLAG GMBH, 2010. M. E. Russinovich, D. A. Solomon, and A. Ionescu, ”Windows Internals, Part 2”, 6th edition, Microsoft Press, September 2012. Microsoft, ”Network Driver Interface Specification (NDIS)”, MSDN, Available online. P. Uppuluri, and R. Sekar, ”Experiences with Specification-based Intrusion Detection”, RAID, Davis, CA, USA, October, 2001. International Organization for Standardization, Technical Committee 184, ”Manufacturing Message Specification”, Available online. Wireshark Sample Captures, Available online. C. Zimmer, B. Bhat, F. Mueller, and S. Mohan. 2010, ”Time-based intrusion detection in cyber-physical systems”, 1st ACM/IEEE International Conference on Cyber-Physical Systems, Stockholm, Sweden, April 2010. M.-K. Yoon and G. Ciocarlie, ”Communication pattern monitoring: Improving the utility of anomaly detection for industrial control systems”, NDSS Workshop on Security of Emerging Networking Technologies, 2014. M.-K. Yoon, S. Mohan, J. Choi, and L. Sha. 2015, ”Memory heat map: anomaly detection in real-time embedded systems using memory behavior”, Annual Design Automation Conference, San Francisco, CA, USA, June 2015. D. Hadziosmanovic, D. Bolzoni, S. Etalle, and P. Hartel, ”Challenges and opportunities in securing industrial control systems”, IEEE Workshop on Complexity in Engineering, Aachen, Germany, June 2012. D. I. Buza, F. Juhasz, G. Miru, M. Felegyhazi, and T. Holczer, ”CryPLH: Protecting Smart Energy Systems from Targeted Attacks with a PLC Honeypot”, Smart Grid Security, vol. 8448, pp. 181–192, August 2014. L. Rist, J. Vestergaard, D. Haslinger, A. De Pasquale, and J. Smith, ”CONPOT ICS/SCADA Honeypot”, Available online at http://conpot. org N. Rowe, ”Two Taxonomies of Deception for Attacks on Information Systems”, Journal of Information Warfare, vol. 3, issue 2, pp. 27–39, July 2004.