HoneyPLC: Honeypots for Industrial Control System

 

ICS are ubiquitous in the infrastructure of many utilities we use on a daily basis, from electricity to transportation. Any disruption to these systems would result in massive socioeconomic damage. This scenario is no longer a thing of the future, it is a reality. The number of attacks targeted towards ICS has regularly increased.

One of the most important components of ICS networks are Programmable Logic Controllers also known as PLCs. They control key hardware such as pumps or centrifuges. Honeypots are an excellent tool that helps us understand cyberattacks against ICS, including PLCs. Several honeypots implementations have been proposed. Researchers utilize ICS honeypots to obtain valuable data about new attacker tactics and malware behaviour. However, current ICS honeypot implementations fail to provide the necessary features to capture data on the latest and most sophisticated attack techniques. HoneyPLC is designed as a medium-interaction honeypot and its architecture consists of the following components:

Honeyd Framework:

The function of Honeyd is twofold. First, Honeyd’s personality engine allows HoneyPLC to provide a highly sophisticated TCP/IP Stack simulation that fools reconnaissance tools like Nmap. When Nmap tries to fingerprint our HoneyPLC host, Honeyd will respond with the appropriate fingerprint information. Keeping a covert operation is important to keep attackers engaged. Second, Honeyd’s Subsystem virtualization enables HoneyPLC to provide extensibility of network services by redirecting network traffic to the correct service simulation. The Subsystem Virtualization communicates with the Network Services component to forward TCP and UDP requests.

Network Services:

 HoneyPLC provides three network services: s7comm server, SNMP agent, and HTTP server. When an attacker tries to read or write information to Honey PLC, the s7comm server replies to the requests. This server provides a level of interaction not present in low-interaction ICS honeypots. Additionally, s7comm server includes the Ladder Logic capture feature that writes any ladder logic program that an attacker uploads to HoneyPLC. This feature provides malware collection.

The next sub-component is the SNMP agent. SNMP agent uses an advanced simulation of the SNMP protocol along with believable MIB data to reply to any SNMP server query. Real PLCs do implement real SNMP agents and having this sub-component adds to the deception capabilities of HoneyPLC. Finally, the HTTP server provides an advanced simulation of the HTTP server of the Real PLCs and serves websites found in real PLCs. 27 All three of Network Services communicate with the Interaction Data component of HoneyPLC to feed their specific log files. This component is key to addressing the problem found in low-interaction ICS honeypots by providing higher interaction features.

 

                                        Fig 1: HoneyPLC Architecture

 

Interaction Data:

 This component holds all of the interaction data gathered by HoneyPLC. It maintains two kinds of data. First, it contains all logs produced by s7comm servers, the SNMP agent and the HTTP server. Second, it contains all the ladder logic programs that get injected via the s7comm server. This component communicates directly with the Network Services component. It is very important as it holds the much valued data gathered by HoneyPLC.

PLC Profile:

The PLC Profile component was designed with the purpose of improving extensibility. It is a collection of PLC Profiles that hold all the required data to simulate a given PLC. The PLC Profile communicates with the Honeyd Framework and Network Services components to customize the PLC that HoneyPLC is simulating at any given time. This component also includes the Profiler tool. This tool is implemented to automate the collection of PLC Profiles from real PLCs.

 

First, the following network services are implemented: s7comm, HTTP and SNMP. The integration of all these elements is made possible by the Honeyd framework. The Honeyd framework allows  easy integration of new network services and new HoneyPLC profiles. Additionally, Honeyd’s personality engine is leveraged in order to provide a sophisticated TCP/IP Stack simulation.  HoneyPLC Profiles are structured, generated, and used. Although, the list of supported PLC devices might seem limited, the Profiler feature of HoneyPLC makes it possible to extend the number of supported PLCs. In order to build HoneyPLC and integrate sophisticated service simulations, various of Honeyd’s capabilities are leveraged including its personality engine, configuration files and subsystem virtualization.

 

  Honeyd Configuration files

The first thing that Honeyd requires before running is a configuration file. The configuration file is a simple text file, the language of the file should follow a context free grammar that specifies command options and the correct syntax. Some of the configuration commands allow Honeyd to change the personality of a honeypot, select the network space, set port behavior and more. HoneyPLC leverages the personality setting, subsystem virtualization, port behaviour and network space commands. First, the base subsystem is created and the s7comm server subsystem is added by providing the required directory. Next the base is cloned to create host1. This host will be the actual virtual honeypot that Honeyd exposes. Then the personality of host1 is set to use the S7-300 PLC fingerprint. Finally, host1 is bind to an IP address.

                                           Fig 2: Honeyd Configuration file

 

  Honeyd Subsystem Virtualization

The Subsystem Virtualization feature allows for Honeyd to start a regular Unix application within Honeyd’s virtual address space. In theory, any Unix application that supports networking can be used as a subsystem by Honeyd and in turn by HoneyPLC. This feature allows the integration of all network services, s7comm, http and snmp.

 

  TCP/IP Stack Attack Surface

Honeyd’s personality engine enables HoneyPLC to deceive fingerprinting tools, e.g., Nmap, and present honeypot as any device we wish. To achieve this, the engine reads a particular fingerprint from Nmap’s database and reverses it. Reversing the fingerprint means that when Honeyd simulates a particular device it introduces its IP/TCP stack peculiarities. These peculiarities are for example, TCP SYN packet flags, IMCP packet flags and timestamps. In order to provide the best possible simulation first Nmap is used to generate a detailed TCP/IP Stack fingerprint for each of the Siemens PLCs. These fingerprints are then integrated with the Honeyd fingerprint database. This is done by appending fingerprints to Honeyd’s nmap-os-db text file.

 

 

  SNMP Attack Surface

SNMP is used to monitor network connected devices. A typical SNMP setup, includes a manager and an agent, the manager continually queries the agent for up-to-date data. A SNMP agent exposes a set of data known as Management Information base or MIB. In order to simulate the SNMP protocol a light Python application called snmpsim is used. This application is capable of simulating any SNMP agent based on real time or archived MIB data. When a SNMP request is received by HoneyPLC, snmpsim handles the request and replies with the correct OID in the same way as the real PLC would do.

 

  HTTP Attack Surface

Most Siemens PLC devices include an optional HTTP service to manage some of its features. This is implemented with lighttpd, a lightweight webserver to handle all HTTP quests. When an HTTP request hits the honeypot, Honeyd’s Subsystem virtualization relays it to the lighttpd server and in turn the webserver replies with the website data from a HoneyPLC profile.

 

 

  HoneyPLC Profiler

The HoneyPLC Profiler is implemented to automate the creation of new HoneyPLC Profiles. It is written as a command line script in Python and interfaces with four different applications: snmpwalk, nmap, and wget. HoneyPLC Profiler requires the IP address of the target PLC device as the only input. It will then run a series of queries to obtain three discrete sets of data from the target PLC: An SNMP MIB, a webiste directory, and a nmap fingerprint.

                                     Fig 3: HoneyPLC Profiler Architecture

 

First, snmpwalk is used to read all the available OIDs from the public community string. The default configuration assumes the PLC is using SNMP version 1, this is because this is default version of the protocol for the PLCs we have encountered. After all OIDs are read  an MIB identical to the one used by the PLC is created. Second, Nmap’s OS detection is used to get the TCP/IP stack fingerprint of the target PLC. In order to obtain a better fingerprint, all well-known TCP and UDP ports are scanned. After the scan is completed the Nmap formatted fingerprint are extracted so that Honeyd can understand it. Finally, wget is used to download a complete copy of the administration website of the PLC. If there are no errors after gathering the data, HoneyPLC Profiler will create a custom directory and data structure that can be used by the HoneyPLC to simulate the target PLC.

 

 

  Logging

All of HoneyPLC’s components have powerful built-in logging functionalities. Honeyd is configured along with lighttpd and snmpsim to automatically log all interactions. s7comm server is the exception. The Snap7 framework doesn’t create log files automatically modified the main library source code to write to the file system all interactions including: IP address of originating host, timestamp, memory block ID in case of reading or writing. Next, snmpsim logs IP information, what OIDs were accessed and timestamps. Finally, the lighttpd webserver includes all the major features of a modern webserver with detailed logging that includes IP address information, accesses website files and timestamps. All of them log every single interaction all the time.

Evaluation:

Given an IP address Honeyscore calculates the probability that the host is a honeypot or not. This Honeyscore is a value between 0.0 and 1.0 where 0.0 means that the host is definitively a real system and 1.0 means that the host is definitively a honeypot.