A Flexible Architecture for Industrial Control System Honeypots

Alexandru Vlad Serbanescu

1, ∗

, Sebastian Obermeier

and Der-Yeuan Yu

KPMG AG, Zurich, Switzerland

ABB Corporate Research, Baden, Switzerland

Department of Computer Science, ETH, Zurich, Switzerland

Keywords:

Industrial Control System Security, Honeypots, SCADA Security.

Abstract:

While frequent reports on targeted attacks for Industrial Control Systems hit the news, the amount of un-

targeted attacks using standardized industrial protocols is still unclear, especially if devices are mistakenly

or even knowingly connected to the Internet. To lay the foundation for a deeper insight into the interest of

potential attackers, a large scale honeynet system that captures all interactions using industrial protocols is

proposed. Special for the honeynet system architecture is the automated deployment on a cloud infrastruc-

ture and its modularisation of the industrial protocols. The centralized-but-redundant data collection allows

correlating attacks that happen on multiple devices. A real-world experiment conﬁrms the feasibility of the

approach, and results of the observed interactions with the honeynet are presented.

1 INTRODUCTION

A large subset of critical infrastructures, from en-

ergy production and distribution (e.g. nuclear power

plants, gas pipes, the electrical grid) over utilities (e.g.

water and wastewater treatment and transportation)

to the transport and manufacturing industries, relies

on industrial control systems (ICS) for controlling

and monitoring the underlying processes and physi-

cal functions in real-time. A SCADA system (super-

visory control and data acquisition) is a special type

of industrial control system, mainly targeted to wide

area industrial systems and focused on data acquisi-

tion and collection aspects.

Initially air-gapped and often using proprietary

protocols, ICS/SCADA systems had their security

ensured by means of physical isolation and obscu-

rity, which are currently considered unsafe prac-

tices (NIST, 2008). ICS/SCADA systems have since

evolved into being integrated into corporate networks

(e.g. with resource planning solutions) and widely-

deployed, complex systems such as smart grids or ad-

vanced metering infrastructures.

As tools are openly available for identifying and

compromising ICS/SCADA components accessible

∗

All related research activities were performed entirely under si-

multaneous afﬁliation with ABB Corporate Research and the De-

partment of Computer Science of ETH Zurich. KPMG AG repre-

sents the current afﬁliation only.

on the public Internet, the level of skill and resources

required to ﬁnd and perform attacks against them is

reduced (ICS - CERT, 2013). Hence, attacks on criti-

cal infrastructures are occurring, with the threat land-

scape having been recently explored in greater detail

(Robinson, 2013) (Morris and Gao, 2013).

However, there is little publicly-available infor-

mation on the adversarial behaviour and on the

amount of interactions between attackers and their

targets. Moreover, the efforts made so far have been

focused on investigating how classical IT attacks ap-

ply to ICS/SCADA systems, with a notable lack of in-

formation on attacks carried out using ICS/SCADA-

speciﬁc protocols. In addition, the inﬂuence of having

ICS/SCADA components indexed by search engines

on the presumably-malicious activities performed us-

ing industrial protocols represents almost uncharted

territory. Finally, even though some existing tools

could be combined and partially used to investigate

these matters at a small scale, there is no single solu-

tion for achieving this goal, let alone at a larger (i.e.

Internet-wide) scale.

1.1 Contributions

The most important contributions can be summarised

as follows:

• Presentation of a novel ICS/SCADA honeypot ar-

chitecture that can be globally deployed in an

Vlad Serbanescu A., Obermeier S. and Yu D..

A Flexible Architecture for Industrial Control System Honeypots.

DOI: 10.5220/0005522500160026

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 16-26

ISBN: 978-989-758-117-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

automated manner on heterogeneous deployment

platforms, thereby forming a large-scale hon-

eynet. Furthermore, the mimicking functionality

together with the security components integrated

are modularly-structured and can thus be easily

extended.

• Proof-of-concept ICS/SCADA honeynet imple-

mentation, including means of automatically de-

ploying it to various on-premises networks or

cloud platforms.

• Experimental results revealing information on the

adversarial behaviour targeting critical infrastruc-

tures, thus advancing the knowledge of the related

threat landscape.

2 ASSUMPTIONS AND

RESEARCH QUESTIONS

We developed our analysis on the following assump-

tions for investigating the ICS/SCADA-protocols-

based adversarial behaviour pertaining to critical in-

frastructures:

1. Attempts to identify ICS/SCADA systems that be-

long to critical infrastructures are happening more

and more frequently. One of the main techniques

to achieve this goal is port scanning. This is a con-

sequence of systems that are part of critical infras-

tructures attracting the attention of malicious en-

tities, ranging from script kiddies and individual

hackers to hacktivist groups and nation states, as

listed in (Asgarkhani and Sitnikova, 2014, p.27).

2. Publicly-available tools (e.g. nmap) and infor-

mation repositories (e.g. the SHODAN search

engine

) facilitate the aforementioned reconnais-

sance activities. The latter is used for what is

referred to as “indirect intelligence gathering” in

(Byres, 2013). The work in (Wilhoit, 2013a,

p. 21) shows that many of the attacks “started

out with SHODAN queries, but it cannot be ac-

curately said if these were accidental or targeted

in nature”.

3. If an ICS/SCADA system is identiﬁed on the pub-

lic Internet (e.g. by identifying its gateway de-

vice), the classic IT components are most likely

the ﬁrst target for an alleged attacker, not the

ICS/SCADA components. Thus, classic and well-

documented attack techniques are usually em-

ployed, such as brute forcing credentials or ex-

ploiting SQL injection vulnerabilities of a web-

based GUI. Moreover, attacks tailored to lower

SHODAN Computer Search Engine. http://www.shodanhq.com/

level ICS/SCADA equipment are unlikely to be

currently seen on the public Internet. This hy-

pothesis is in line with the experimental results

in (Buza et al., 2014, p. 191), in which the hon-

eypot collected many general PC targeting at-

tacks, but neither of them was speciﬁc to pro-

grammable logic controllers (PLCs), which are

typically used for the actual control of the in-

dustrial processes. However, the rare attacks that

do exploit the ICS/SCADA layer are targeted and

sophisticated, as shown in (Wilhoit, 2013b) and

(Wilhoit, 2013a).

Based on these assumptions, the goal of our ex-

periments was to answer the following questions:

1. Although attacks at the ICS/SCADA level seem

unlikely over the public Internet, can we ob-

serve attempts to identify using industrial proto-

cols (e.g. Modbus, IEC-104) ICS/SCADA equip-

ment that is directly (and hence wrongly) accessi-

ble from the public Internet?

2. Do ICS/SCADA components that are directly

connected to the Internet draw attention, and are

there attempts to interact with them in a short

amount of time (on the order of days or possibly

even hours, as observed for example in (Wilhoit,

2013b))?

3. How fast do information repositories (e.g.,

SHODAN) interact with and list newly-connected

devices?

4. If an ICS/SCADA-speciﬁc device is identiﬁed,

how is it typically interacted with (e.g., port scan,

connection attempts, exchange of protocol-level

data)?

In addition, exploring the feasibility of utilising

a single framework for monitoring the ICS/SCADA-

related threat landscape at a large scale has been es-

tablished as a goal as well.

3 RELATED WORK

One of the ﬁrst attempts of translating honeypots to

the ICS/SCADA application domain is represented

by the SCADA HoneyNet Project, whose authors

tried in 2004 to evaluate the “feasibility of build-

ing a software-based framework to simulate a vari-

ety of industrial networks such as SCADA, DCS [dis-

tributed control system, another speciﬁc type of ICS],

and PLC architectures”

. Their aim was to simu-

V. Pothamsetty and M. Franz. SCADA HoneyNet

Project: Building Honeypots for Industrial Networks.

http://scadahoneynet.sourceforge.net/

AFlexibleArchitectureforIndustrialControlSystemHoneypots

Figure 1: Cloud-based industrial honeynet architecture.

late a PLC using Honeyd

(a popular low-interaction

honeypot) to mimic a set of protocols and services

speciﬁc to industrial networks in order to address

the lack of (publicly-available) information about

SCADA vulnerabilities and attacks and of publicly

available SCADA security tools

. The main contri-

butions include scripts that simulate protocols such as

FTP, Modbus TCP and Telnet, and a web server com-

ponent. The work on this project was discontinued in

2005. The simulation achieved is limited with respect

to the functions and operations implemented, e.g. by

comparing the Modbus synchronous simulation script

to the interactive, full Modbus functionality, and not

designed for automated deployment on cloud infras-

tructures.

Building on the HoneyNet Project, Digital Bond,

Inc. (a control system security consulting and re-

search company) has developed its own version of

a SCADA Honeynet

, which uses two virtual ma-

chines as its foundation instead of the Honeyd hon-

eypot. The simulation of a popular PLC and of its

exposed services (FTP, Telnet, Modbus TCP, HTTP,

SNMP) is carried out by one virtual machine, while

N. Provos. Honeyd Virtual Honeypot. http://www.honeyd.org/

Digital Bond Inc. SCADA Honeynet. http://www.digitalbond.

com/tools/scada-honeynet/

the other one concentrates on monitoring all network

activity and statistics

and includes tools for this pur-

pose. The approach contains in-house-developed IDS

signatures for detecting malicious activity targeting

the simulated PLC. The latest version of this project

dates back to 2011. A recent example of simulating

a control system using this SCADA Honeynet version

can be found in (Wade, 2011). The SCADA Honeynet

developed by Digital Bond, Inc. also supports the use

of a real, hardware PLC instead of a simulated one.

The overall architecture proposed, although reﬂecting

substantial improvement over the SCADA HoneyNet

Project, is unsuitable for wide-scale deployment and

operation (for example because of the lack of manage-

ment, operation and per-node individualization facil-

ities), and makes functionality and protocol-coverage

extensions difﬁcult. Therefore, the approach devel-

oped in this paper also focuses on modularization of

the protocol simulation functionality.

The most recent implementation of a SCADA

honeypot (and also in active development) is Con-

pot, a “low interactive server side [. . . ] honeypot de-

signed to be easy to deploy, modify and extend”

In its default conﬁguration, it simulates a Siemens

The Honeynet Project. CONPOT ICS/SCADA Honeypot.

http://www.conpot.org

SECRYPT2015-InternationalConferenceonSecurityandCryptography

SIMATIC PLC exposing HTTP, Modbus TCP and

SNMP protocols, and also supports the use of pro-

duction equipment instead of the mimicked compo-

nents (e.g. human-machine interface, PLC). A design

and implementation case-study for a honeypot based

on Conpot can be found in (Scott, 2014). According

to (Buza et al., 2014, p. 183), Conpot is easy to in-

stall and use, but requires a lot of customization effort.

The customization and conﬁguration effort represents

a common disadvantage of most, if not all publicly-

available ICS/SCADA honeypots surveyed in this pa-

per.

In contrast to the approach chosen in this pa-

per, none of the aforementioned ICS/SCADA hon-

eypot/honeynet seamlessly integrates a port scanning

detection mechanism – not only from a functional

point of view, but also from a collected data aggre-

gation and analysis perspective.

Concerning the use of publicly-available re-

sources for identifying ICS/SCADA systems – in the

case of SHODAN, a search engine crawling the Inter-

net and indexing devices according to the service ban-

ners returned – recent research efforts such as (Boden-

heim et al., 2014) and (Patton et al., 2014) highlight

their considerable potential as indirect reconnaissance

tools. Speciﬁcally, in (Bodenheim et al., 2014) it is

argued that SHODAN represents a ”powerful recon-

naissance tool for targeting (ICS systems)”, indexing

four newly-connected, Internet-facing PLCs in ap-

proximately 19 days, whereas in (Patton et al., 2014)

roughly 1400 SCADA devices from a SHODAN

database subset are found to be using default login

credentials. It is also reported in (Wilhoit, 2013a) that,

while using a proprietary ICS honeypot, many of the

attacks observed started out with SHODAN queries.

However, (Wilhoit, 2013a) cannot accurately assert if

these were accidental or targeted in nature.

Therefore, being indexed in public information

repositories appears to increase the exposure of

ICS/SCADA systems to Internet-originating attacks

and, hence, the associated risks. However, there is

currently no information available on the inﬂuence of

such listings on the adversarial behaviour using ICS-

speciﬁc protocols itself.

4 APPROACH

The selected approach for investigating the adversar-

ial behaviour pertaining to critical infrastructures is

an ICS/SCADA honeynet, which exposes multiple in-

dustrial protocols to the Internet. It is deployed on a

global scale using the Amazon EC2 cloud environ-

ment.

A honeynet-based approach has been chosen

because it enables a software-only simulation of

ICS/SCADA devices from various manufacturers in

large numbers and adaptable conﬁgurations. Thus, no

deployment or operational constraints other than the

software-related ones are faced.

In order to answer the questions concerning the at-

tack landscape, only the presence of ICS/SCADA de-

vices that support various speciﬁc protocols has been

simulated. It was not necessary to precisely mimic

the devices individually since the research objectives

currently established are not restricted to a particular

device class/type; they are concerned with the over-

all associated threat landscape. Moreover, with only

minimal information available on the particular adver-

sarial behaviour considered, a less-detailed-but-broad

initial investigation has been considered more valu-

able than a deep-but-narrow one, as it provides a good

overview of the threat landscape and, hence, support

for directing and optimising subsequent research ef-

forts.

As capturing port scanning activities is crucial

for relating the amount of targeted interactions to

the overall number of connections, we have designed

each honeypot to seamlessly integrate Snort, an open-

source network intrusion detection system (Beale

et al., 2007). Snort is not only specialized on port scan

detection; it can also detect attempts to ﬁngerprint the

operating system or probes/attacks using various pro-

tocols.

4.1 Simulated ICS/SCADA Protocols

We have simulated protocols that are utilised for re-

mote SCADA/ICS communication as these protocols

could be routed over the Internet and can thus attract

malicious interest.

Modbus is a de facto standard for industrial com-

munication, ubiquitously used in equipment ranging

from small network-enabled sensors over automation

controllers to SCADA system components (Wilam-

owski and Irwin, 2011).

IEC 60870-5-104 is frequently used in the electri-

cal generation and distribution industry, especially in

Europe (where it is the most commonly-used proto-

col), but also internationally (where it competes with

DNP3 in English-speaking countries).

5 ARCHITECTURE

The honeynet system primarily consists of multiple

honeypot nodes deployed in a scattered manner on the

public Internet and which communicate with one or

AFlexibleArchitectureforIndustrialControlSystemHoneypots

Figure 2: Internal honeypot architecture.

more data storage, analysis and management (SAM)

nodes.

The purpose of each honeypot node is to mimic

the presence of an ICS/SCADA system component

and to monitor for, carry out and record interac-

tions using communication protocols speciﬁc to the

ICS/SCADA application domain. The nodes can si-

multaneously simulate different services, according

to their individual conﬁguration, thus being able to

interact with the environment using different combi-

nations of ICS/SCADA protocols. If a node is inter-

acted with (e.g. port scanned) using a protocol that

is not being simulated at that moment, the attempt is

also logged. In addition, the honeypot nodes apply

local processing to the gathered data before sending it

to the SAM node(s) in order to minimise the load on

the latter one(s). The information to be captured and

stored consists of data at OSI Layer 3 and above, both

sent and received.

The internal architecture of the honeynet system

used to gather the data analysed in the next section

is depicted in Figure 1, with Amazon EC2 as the

deployment platform. The modular architecture al-

lows for scalability, easy addition of functionalities

and straightforward expansion of the protocols simu-

lated. From a high level perspective, the functionality

of the honeynet is organised into data capture, data

collection, data analysis and honeynet management,

hence its structure follows the same logic.

Data capture deﬁnes the recording of all interac-

tions that occur with the surrounding environment in

order to have a raw source of data that can be there-

after analysed and transformed into actionable infor-

mation/knowledge. Hence, the honeynet processes all

interactions, regardless of their characteristics (e.g.

completeness, conformance with the corresponding

standards) and captures and stores all data situated at

OSI Layer 3 and above. This functionality is accom-

plished locally on each honeypot node at both net-

work and application level.

Data collection satisﬁes the essential need of hav-

ing all information captured available at one/multiple

locations in order to enable a real-time, complete and

system-wide image of the honeynet and to be thus

able to detect events and discover correlations. Ac-

cording to (Deng and Shukla, 2013), SCADA systems

require real-time threat monitoring and early warn-

ing systems to identify cyber attacks, whereas effec-

tive intrusion detection requires correlation of mul-

tiple events that are temporally and/or spatially sep-

arated. Therefore, a central data collector has been

SECRYPT2015-InternationalConferenceonSecurityandCryptography

Figure 3: Structure of the honeypot management component.

implemented to allow such correlations between mul-

tiple events.

Data analysis embodies the key functionality of

the honeynet, namely to extract information and to

draw conclusions from the data collected. It is per-

formed only on the SAM nodes in order to reduce the

computational load on the honeypot nodes. Data anal-

ysis is carried out using third-party tools (i.e. Matlab)

and custom Python scripts.

Honeynet management provides mechanisms for

easy conﬁguration, monitoring and deployment (e.g.

automated deployment in the Amazon EC2 cloud)

and covers all aspects of the honeypot life cycle,

from honeypot node bootstrapping over secure remote

management and honeynet-wide conﬁguration/code

updates to honeypot node shutdown. There are two

associated data ﬂows depicted in Figure 1 because

the honeynet SAM nodes need not only to control the

honeypot software itself, but to also programmatically

manage the hosting environment(s) employed using

the API(s) exposed (e.g. provisioning a virtual ma-

chine on the Amazon EC2 cloud).

The structure of the honeypot software itself is

shown in Figure 2, using the same color coding as in

Figure 1 for the data capture, data collection and hon-

eypot management functionalities. One of the main

goals pursued with this modular structuring has been

to enable simple functional extensions, therefore hav-

ing a minimal number of component interdependen-

cies with uniform underlying logic has been assigned

a high priority.

Honeypot main SW represents the entry point,

which starts in a virtual terminal environment so

that its functioning is not dependent on the state of

the SSH session and to also allow operator inspec-

tion/intervention at any time. The state of all other

components (except for the RPC service) is controlled

from here, with global commands subsequently call-

ing the required methods in the corresponding compo-

nents. For example, the command for initialising the

honeypot starts with initialising the database compo-

nent, followed by all protocol simulation services and

ﬁnishing with the portscan detection module.

The RPC service is automatically started in a sep-

arate thread for receiving commands and responding

to queries from the honeynet controller, which are all

tunnelled through an SSH tunnel. The most impor-

tant control commands to be received using the RPC

service are for initialising, starting and stopping the

AFlexibleArchitectureforIndustrialControlSystemHoneypots

honeypot software, respectively for setting its unique

identiﬁer and for querying its state.

The key activity performed by the honeypot nodes

– simulating services and capturing interactions – is

realised with individual components for every ser-

vice/protocol simulated. Each such component gath-

ers data using network- and application-level mecha-

nisms and can respond to the messages received, pro-

vided that a reply generation function is also imple-

mented. After processing each incoming message, the

information thus extracted is sent to the database com-

ponent.

The portscan detection component employs Snort

for the actual detection. Hence, the honeypot could

also be extended with IPS-speciﬁc tasks done by

Snort. All events detected are handed over to the

database component.

The database component handles the data to be

sent to the honeynet central database(s). Every simu-

lated protocol has a speciﬁc buffer associated for stor-

ing the data gathered, which is in turn ﬂushed when

full or at regular intervals (whichever occurs ﬁrst).

The port scanning activity detected is also handled by

such a buffer.

5.1 Data Capture

The capture of data is realised by the sensing points

of the honeynet, namely the honeypot nodes, at two

different levels on the OSI stack.

Network level: For each protocol simulated, ipt-

ables entries for both incoming and outgoing trafﬁc

on the associated ports are automatically added in or-

der to redirect the raw trafﬁc using netﬁlter queues

to the honeypot software residing at the application

level. Here, each packet received is processed by a

callback function that either stores it in a temporary

buffer if the packet is still needed by other methods or

sends it to the associated buffer in the database com-

ponent directly. In the case of the former, after all

methods have ﬁnished utilising the captured packet

the last one sends the data to the buffer in the database

component. This approach has been chosen as it en-

ables using the raw capture and examination of the

entire packet (using a packet manipulation tool such

as Scapy). In addition, persistently storing the packet

dump in the honeynet database becomes also possible

– this allows a subsequent detailed inspection of the

captured packets using packet analysers.

Application level: If there are services imple-

mented for a protocol (e.g. a Modbus server for the

Modbus component), each simulated service can in-

tegrate the raw data received through the aforemen-

tioned netﬁlter queue redirection and use it internally.

For example, the Modbus component makes use of an

open-source implementation for simulating a server

and by adding hooks at appropriate places speciﬁc

events can be logged.

An advantage of this data capture mechanism is

that tasks such as handling TCP connections can be

ofﬂoaded from the honeypot software onto the oper-

ating system through the use of standard techniques

(e.g. creating a TCP socket for listening on a port),

thus improving performance.

With regard to the detection of port scans, the out-

put of the port scan detection module is redirected to a

ﬁle, which is continuously monitored by the honeypot

software for ﬁle system events. In this way, any port

scanning occurrence detected by Snort is immediately

processed by the honeynet.

5.2 Data Collection

After the data has been captured and processed by the

protocol-speciﬁc or portscan detection components, it

is sent to the associated buffer in the database com-

ponent. These buffers inherit a base buffer that im-

plements the logic for ﬂushing their content to the

database(s) on the SAM nodes and they specialise

the structure of the data buffered, the SQL commands

employed and the logging API exposed to the data-

capture-responsible components. Thus, under normal

operation all databases hold identical data. To assure

this property under non-ideal conditions, database

synchronization mechanisms can be easily added on

the SAM nodes with no modiﬁcation to the honey-

pot software itself. The logical topology of the hon-

eynet with regard to data collection is hub(s) and

spoke, with the SAM node(s) being the hub(s). Multi-

threaded connection pools are created for each desti-

nation database.

5.3 Honeynet Management

The management of the honeypot nodes is performed

using a honeynet controller component, which is en-

tirely separated form the honeypot software. This

structure of the honeynet management software is de-

picted in Figure 3.

Starting from the top, the honeypot level opera-

tions component exposes an interface for controlling

the honeynet from a high-level, system-wide perspec-

tive, i.e. for executing commands such as “launch

honeypot node on deployment environment X”. It

fulﬁls the role of the gateway redirecting user com-

mands to the underlying component that can execute

them according to the deployment environment they

are destined for. In addition, it handles queries that

SECRYPT2015-InternationalConferenceonSecurityandCryptography

request honeypot-level information, such as learning

the state of the honeypot nodes or inspecting captured

packets.

The next layer (blue) contains one component for

each deployment environment used by the honeynet

in order to handle the commands distributed by the

previously mentioned gateway. High-level commands

such as “add honeypot node” are broken down into the

sequence of main steps to be carried out using the cor-

responding deployment-environment-speciﬁc mecha-

nisms, which are implemented in the green layer be-

low, and/or of queries to be send to the honeynet

database(s). In other words, the components belong-

ing to this level incorporate the logic behind all oper-

ations that the honeynet management software sup-

ports. In addition, they also expose interfaces for

carrying out actions at the request of the underlying

mechanisms targeting the same deployment environ-

ment: for example, the illustrated Amazon EC2 oper-

ations component will add data to the database when

the underlying component has ﬁnished updating and

restarting a honeypot node running on the Amazon

EC2 cloud platform.

Amazon EC2 mechanisms, together with all other

components from the same layer (green), expand the

steps exposed to the layer above into the actual op-

erations that have to be executed on the target de-

ployment environment, including possible interac-

tions with the API provided by the latter or with other

resources (e.g. the ShodanHQ component). For ex-

ample, the “launchHoneypot” method will: use the

Amazon EC2 API to launch a new instance, request

a unique identiﬁer from the overlying component,

check whether the services to be simulated by the

new honeypot node are already listed on SHODAN

(and take appropriate actions if they are), provision

the new instance, initialise and start the honeypot soft-

ware. All these steps have to be translated to actual

commands issued for the operating system used on

the instance obtained from the deployment environ-

ment – this is done in the lowest layer of the honeypot

management software, as subsequently introduced.

The (deployment) platform-independent compo-

nent implements the entire set of operations to be car-

ried out on the actual hosting environment, i.e. the

underlying operating system. This includes, among

others, installing the required software, deploying or

updating the honeypot software, pushing the speci-

ﬁed conﬁguration ﬁles, controlling the honeypot soft-

ware, and retrieving the log ﬁles. The role of this

component is to hide the operating-system speciﬁc

implementation details and provide a uniﬁed set of

commands to all other components that depend on

it. The platform-independent component has been im-

plemented for Ubuntu Linux.

Table 1: Deployment scheme on Amazon EC2.

Amazon EC2 Region Honeypots DBs

Asia Paciﬁc (Tokyo) 2 –

Asia Paciﬁc (Singapore) 2 –

Asia Paciﬁc (Sydney) 2 –

EU (Ireland) 3 1

South America (Sao Paulo) 1 –

US East (N. Virginia) 3 –

US West (N. California) 2 –

US West (Oregon) 3 1

Total 18 2

Using this deployment scheme, all Amazon EC2

regions available at the start of the experiment were

covered and all their underlying availability zones

contained one honeypot instance, with the exception

of South America (Sao Paulo) and US East (N. Vir-

ginia).

The functionality of the honeynet as a whole is

augmented by including access to external sources

of information. SHODAN has been chosen for this

proof-of-concept implementation. A corresponding

component is present – the ShodanHQ component in

this case – in order to hide the external API and to

implement more advanced functionalities (compared

to the API-provided ones) in cooperation with other

components. In addition, a database component is

also present, which enables the interaction of the other

components with the honeynet database(s).

This approach of structuring the honeynet man-

agement software offers the following advantages:

• GUIs or other user interfaces can interact with the

management system in a technically-transparent

manner. In addition, deployment environments

can be added without being forced to change the

existing user interfaces or the honeynet manage-

ment software itself – they only have to add sup-

port for the new ones.

• Newly-added deployment environments can

utilise already implemented components, mecha-

nisms and/or sources of information. Conversely,

existing components can be rapidly and easily

integrated and beneﬁt from new information

sources and/or new auxiliary modules.

• The logic is separated from its actual realisation,

thus keeping change requirements from propa-

gating back and forth between them. Moreover,

schema alterations in the honeynet database(s)

only affect the former, whereas updates of the ex-

ternal components (e.g. ShodanHQ component)

inﬂuence only the latter.

AFlexibleArchitectureforIndustrialControlSystemHoneypots

Figure 4: Series of Modbus connections and requests.

• The components that deﬁne the operations to

be carried out on each operating system can

be reused for multiple environments offering

the same operating system to the user. More-

over, honeynet management software modiﬁca-

tions due to changes in the operating system are

restricted to a single component, without affect-

ing the upstream components.

5.4 Implementation

Both honeypot node and honeynet management soft-

ware are implemented in Python, with the Twisted

framework being used for asynchronous operations,

network interactions and protocol simulation. The

honeynet databases run on PostgreSQL DBMS, with

which the honeypot nodes communicate through psy-

copg2. The virtual terminal environment employed

for running the honeypot software is provided by

screen.

Scapy offers the required support for packet in-

spection and manipulation tasks and also plays a role

in the enumerated protocol simulation, with nfqueue-

bindings alongside iptables being responsible for

redirecting raw trafﬁc to/from it. The Modbus server

is simulated using PyModbus, whereas Snort handles

the detection of port scanning attempts. In addition,

information about the interaction peers is gathered us-

ing dnspython for reverse DNS lookups and GeoIP for

their geographical origin.

Fabric is used for running commands remotely on

the honeypot nodes, while RPyC and Plumbum enable

the secure use of remote procedure calls. GitHub has

been used for code storage, while code deployment

is achieved using the git tool. The interaction with

the Amazon EC2 and SHODAN APIs is carried out

through the boto and shodan python libraries, respec-

tively.

6 EXPERIMENTAL EVALUATION

We have evaluated the framework and implementa-

tion through experiments carried out using the Ama-

zon EC2 cloud environment. The protocols exposed

are Modbus and IEC 60870-5-104 (IEC 104), and the

duration of the experiment was 28 days. During this

time, no changes were made to the running honey-

pots. The deployment scheme for the honeypot nodes

is depicted in Table 1.

In order to avoid loss of experimental data, two

nodes were used for hosting a database each and for

controlling the honeynet, as described in Section 5.2.

This also shows the feature of the honeynet to simul-

taneously log to multiple databases.

As a general note, the interactions are categorized

using their type (new connection, request), the pro-

tocol employed and their relation to SHODAN (peer

belonging to the scanning infrastructure of SHODAN

or not). The latter characteristic is determined by per-

forming a reverse DNS lookup of the peer’s IP address

and checking whether the associated PTR record is a

subdomain belonging to SHODAN or not. The infor-

mation obtained using this method in the case of non-

SECRYPT2015-InternationalConferenceonSecurityandCryptography

Table 2: Summary of data collected on Amazon EC2.

Peer IP addr. CC DNS PTR

Modbus IEC-104

Pscans.

Conns. Reqs. Conns. Reqs.

66.240.192.138 US census8.shodan.io. 48 46 13 13 1

66.240.236.119 US census6.shodan.io. 45 43 8 8 2

71.6.135.131 US census7.shodan.io. 49 41 6 6 5

71.6.165.200 US census12.shodan.io. 44 44 7 7 1

82.221.105.6 IS census10.shodan.io. 8 8 - - 2

82.221.105.7 IS census11.shodan.io. 3 3 - - -

85.25.43.94 DE rim.census.shodan.io. 14 12 7 7 3

85.25.103.50 DE paciﬁc.census.shodan.io. 10 8 - - 1

93.120.27.62 RO m247.ro.shodan.io. 4 4 1 1 1

95.19.182.113 ES [...].dynamic.jazztel.es. 5 58 - - -

104.54.177.50 US [...].rcsntx.sbcglobal.net. 6 - - - -

108.163.245.114 US server.albrari.com. 813 738 - - 7

118.192.48.6 CN - 4 3 - - -

198.20.69.98 DE census2.shodan.io. 2 - 3 3 4

198.20.70.114 US census3.shodan.io. 16 16 6 6 -

188.138.9.50 US atlantic.census.shodan.io. 8 8 2 2 3

202.108.211.62 CN - 13 8 - - 4

Totals (SHODAN): 251 233 53 53 23

Totals (non-SHODAN): 841 807 0 0 11

SHODAN peers can reveal useful details, such as ties

to different organizations, presumed owner’s identity

or the ISP used.

6.1 Results

A summary of the experimental data collected is

shown in Table 2. The IP address, associated GeoIP

source country information (if available) and corre-

sponding DNS PTR record (if any) for each peer

that has interacted with the honeynet are listed in the

ﬁrst three columns. The next four columns provide

a breakdown of the interaction by protocol and/or

type, while the last column contains the number of

portscans detected by the Snort module from the cur-

rent peer, i.e., it must not be used to assess the place-

ment attractiveness of the honeypots/honeynet.

The experiments show that SHODAN frequently

scans large parts of the Amazon EC2 cloud infras-

tructure and also lists our honeypot nodes that it dis-

covers.

Figure 4 illustrates the number of new Mod-

bus connections and Modbus TCP requests observed

throughout the experiments. For a better visualisa-

tion, we have ﬁltered out two source IP addresses

that established excessive amounts of new connec-

tions (813 occurrences for the ﬁrst one alone) and

issued a disproportionately-large number of requests

(738 and 58 for the ﬁrst and second addresses, respec-

tively).

This experiment reveals that the interactions are

happening frequently and regularly. Moreover, it con-

ﬁrms that the deployed honeypots are of interest and

have hence attracted determined/interested peers.

The experiments have also shown the feasibility

of our approach and have validated the automated de-

ployment concept. In the future, we plan to run more

experiments to get a deeper insight into the industrial

protocol landscape.

7 SUMMARY AND

CONCLUSIONS

We have presented an architecture for a honeypot

that enables building a large-scale honeynet. This

honeynet can be automatically deployed on a cloud

infrastructure, and allows for a centralized and re-

dundant collection of data. Particular attention has

been given to the modular character of the industrial

protocol implementation, which enables a straight-

forward expansion of the industrial protocols that a

honeypot can expose. A special feature is also the

seamless integration of Snort, an open source intru-

sion detection system, which is used to detect port

scans and operating system ﬁngerprinting in a sophis-

AFlexibleArchitectureforIndustrialControlSystemHoneypots

ticated way. The real-world experiments conducted

on a cloud infrastructure show the feasibility of the

approach proposed. The honeynet not only was regu-

larly probed and indexed by SHODAN (a search en-

gine that searches for speciﬁc types of devices), but

it has also attracted multiple seemingly-independent

peers to interact with it.

The results of the experiments conducted moti-

vate the fundamental need of having proper security

mechanisms in place within industrial control systems

that are connected to the Internet, as these systems

will be swiftly listed in relevant information reposito-

ries, thus possibly becoming further exposed to both

classical IT and ICS-speciﬁc attacks. Moreover, they

indicate that potentially malicious activities targeting

industrial control systems and using ICS-speciﬁc pro-

tocols may be currently conducted on the public In-

ternet.

As future work, we plan to extend the number of

protocols simulated and also to evaluate the inﬂuence

of search engine listings on the adversarial behaviour

observed. To summarize, we consider the proposed

architecture for an ICS honeynet system an important

foundation for obtaining a deeper insight into the in-

terest of potential attackers for industrial devices.

REFERENCES

Asgarkhani, M. and Sitnikova, E. (2014). A strategic ap-

proach to managing security in SCADA systems. In

Proceedings of the 13th European Conference on Cy-

ber warefare and Security, pages 23–32. Academic

Conferences and Publishing International Limited.

Beale, J., Baker, A., Esler, J., Kohlenberg, T., and Northcutt,

S. (2007). Snort: IDS and IPS Toolkit. Jay Beale’s

open source security series. Syngress.

Bodenheim, R., Butts, J., Dunlap, S., and Mullins, B.

(2014). Evaluation of the ability of the Shodan search

engine to identify internet-facing industrial control de-

vices. International Journal of Critical Infrastructure

Protection, 7(2):114–123.

Buza, D. I., Juh

asz, F., Miru, G., F

elegyh

azi, M., and Hol-

czer, T. (2014). CryPLH: Protecting smart energy sys-

tems from targeted attacks with a PLC honeypot. In

Smart Grid Security, Lecture Notes in Computer Sci-

ence, pages 181–192. Springer International Publish-

ing. http://dx.doi.org/10.1007/978-3-319-10329-7 12.

Byres, E. (2013). Project SHINE: 1,000,000 Internet-

Connected SCADA and ICS Systems and Counting.

Web page.

Deng, Y. and Shukla, S. (2013). A distributed real-time

event correlation architecture for SCADA security. In

Critical Infrastructure Protection VII, volume 417 of

IFIP Advances in Information and Communication

Technology, pages 81–93. Springer Berlin Heidelberg.

http://dx.doi.org/10.1007/978-3-642-45330-4 6.

ICS - CERT (2013). Increasing threat to industrial

control systems (update A). https://ics-cert.us-

cert.gov/alerts/ICS-ALERT-12-046-01A.

Morris, T. H. and Gao, W. (2013). Industrial

control system cyber attacks. In Proceed-

ings of the 1st International Symposium for

ICS & SCADA Cyber Security Research.

http://ewic.bcs.org/content/ConWebDoc/51165.

NIST (2008). Guide to General Server Secu-

rity – Recommendations of the National

Institute of Standards and Technology.

http://csrc.nist.gov/publications/nistpubs/800-

123/SP800-123.pdf.

Patton, M., Gross, E., Chinn, R., Forbis, S., Walker, L., and

Chen, H. (2014). Uninvited Connections: A Study of

Vulnerable Devices on the Internet of Things (IoT).

In Intelligence and Security Informatics Conference

(JISIC), 2014 IEEE Joint, pages 232–235.

Robinson, M. (2013). The SCADA threat landscape.

In Proceedings of the 1st International Sympo-

sium for ICS & SCADA Cyber Security Research.

http://ewic.bcs.org/content/ConWebDoc/51166.

Scott, C. (2014). Designing and implementing a honeypot

for a SCADA network. Technical report, The SANS

Institute.

Wade, S. M. (2011). SCADA honeynets: The attractiveness

of honeypots as critical infrastructure security tools

for the detection and analysis of advanced threats.

Master’s thesis, Iowa State University, Ames, Iowa.

http://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=

3130&context=etd.

Wilamowski, B. M. and Irwin, J. D. (2011). The Indus-

trial Electronics Handbook – Industrial Communica-

tions Systems, volume 2 of The Industrial Electronics

Handbook. CRC Press, Taylor & Francis Group, 2

edition.

Wilhoit, K. (2013a). The SCADA that didnt cry wolf –

whos really attacking your ICS equipment? – part

deux! Black Hat US 2013.

Wilhoit, K. (2013b). Whos really attacking your ICS equip-

ment? Black Hat Europe 2013.

SECRYPT2015-InternationalConferenceonSecurityandCryptography