From Exposed to Exploited: Drawing the Picture of Industrial Control

Systems Security Status in the Internet Age

Yixiong Wu

, Jianwei Zhuge

1,2

, Tingting Yin

, Tianyi Li

, Junmin Zhu

, Guannan Guo

, Yue Liu

and Jianju Hu

Institute of Network Science and Cyberspace, Tsinghua University, Beijing, China

Beijing National Research Center for Information Science and Technology, Beijing, China

Peking University, Beijing, China

Shanghai Jiao Tong University, Shanghai, China

School of Computer Science and Technology, University of Science and Technology of China, Hefei, China

Qi An Xin Technology Research Institute, Beijing, China

Siemens Ltd., China

Keywords:

Internet-facing ICS Devices, Passive Vulnerability Assessment, Device Search Engine.

Abstract:

The number of Internet-facing industrial control system(ICS) devices has risen rapidly due to remote control

demand. Going beyond beneﬁts in maintenance, this also exposes the fragile ICS devices to cyber-attackers.

To characterize the security status of Internet-facing ICS devices, we analyze the exposed ICS devices and their

vulnerabilities. Considering the ethic, we design and implement ICScope, a passive vulnerability assessment

system based on device search engines. Firstly, ICScope extracts the ICS device information from the ban-

ners returned by multiple search engines. Then, ICScope ﬁlters out the possible ICS honeypots to guarantee

accuracy. Finally, ICScope associates ICS vulnerabilities with each ICS device. Over the past year, our mea-

surements cover more than 466,000 IPs. We ﬁrst perform a comprehensive measurement of Internet-facing

ICS devices from Dec 2019 to Jan 2020. We ﬁnd that there are about 49.58% of Internet-facing ICS devices

that can be identiﬁed are affected by one or more vulnerabilities. We also conduct three times experiments

from Jun 2020 to Dec 2020 to monitor the security status of Internet-facing ICS devices. We observe a slowly

decreasing trend in the number of vulnerable ICS devices during our experiment period.

1 INTRODUCTION

With the rapid growth and deep integration of In-

formation Technology and Operational Technology,

more and more industrial control system (ICS) de-

vices with computing and communication capabili-

ties are introduced to smart factories, buildings, and

cities. The proprietary protocols used in these devices

are originally designed to communicate between de-

vices in isolated operation LANs. As a result, secu-

rity protections for ICS communication are usually

missing. Besides, for economic considerations, ICS

devices are rarely updated or upgraded. Administra-

tors usually avoid upgrades to reduce the possibility

of system crashes. Thus, the life cycle of ICS vul-

nerabilities is much longer than other kinds of vulner-

abilities. However, more and more ICS devices are

exposed to the Internet nowadays. This is usually for

the convenience of data collection and remote mainte-

nance. However, it also makes the fragile ICS devices

exposed to the cyber-attacks. In 2017, Triton attacked

a petrochemical plant in the Middle East, resulting in

an emergency shutdown of a critical industrial con-

trol system (Di Pinto et al., 2018). In 2019, the Triton

was relaunched. Cyber-attacks like these towards ICS

have existed for a long time and have already caused

substantial damage.

To mitigate this type of threat, both the research

community and the industry take proactive actions.

ICS-CERT

provides annual assessment reports for

public ICS vulnerabilities. Kaspersky

further ana-

lyzes these reports and summarizes the vulnerability

characteristics. However, both of them did not an-

https://us-cert.cisa.gov/ics

Industrial Control Systems Vulnerabilities Statistics,

Reported by Kaspersky in 2019

Wu, Y., Zhuge, J., Yin, T., Li, T., Zhu, J., Guo, G., Liu, Y. and Hu, J.

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age.

DOI: 10.5220/0010327902370248

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 237-248

ISBN: 978-989-758-491-6

237

alyze the distribution of vulnerabilities in the actual

network. Existing works also focus on the discov-

ery of online ICS devices. Both Mirian et al. (Mirian

et al., 2016) and Feng et al. (Feng et al., 2016) have

proposed their device discovery approaches to give an

Internet-Wide view of ICS devices. However, they

focus more on the number of exposed devices rather

than vulnerable devices. Further works behind on-

line ICS devices’ detection are to perform a vulnera-

bility assessment for the Internet-facing ICS devices.

Characterizing the vulnerable Internet-facing ICS de-

vices is highly desirable for the interests of securing

Internet-facing ICS devices.

To identify a device’s vulnerabilities, one instinc-

tive reaction is to perform a vulnerability assess-

ment using vulnerability scanners like Nessus (Ac-

tive Mode). However, such techniques cannot be ap-

plied to identify an ICS device’s vulnerability. Be-

cause sending many packets to ICS systems regards

as an intrusive behavior. Therefore, we prefer the pas-

sive vulnerability assessment (Passive Mode), which

is based on a search engine to identify a device’s vul-

nerabilities without any interaction. Most previous

works on passive vulnerability assessment focus on

common services, i.e., HTTP, IMAP. For example,

ShoVAT (Genge and En

achescu, 2016) focuses on

several common services, and Scout (O’Hare et al.,

2019) only supports HTTP service. Because of the

inconsistent banner format between common services

and ICS devices, their methods are not considered

feasible. There are also existing works focus on ICS

services. Both Samtani et al. (Samtani et al., 2016)

and Leverett et al. (Leverett and Wightman, 2013)

identify the vulnerabilities for online ICS devices.

However, the scope of their works is limited to spe-

cial ICS services. Moreover, both of them scan target

ICS devices. In this paper, we aim to answer the fol-

lowing question:

Q: What is the security status of Internet-facing ICS

devices in the whole public IP address space?

To answer this question, we propose a passive vul-

nerability assessment system based on device search

engines. For ethical consideration, our system IC-

Scope uses passive mode to avoid intrusive behaviors.

We face three main technical challenges to build IC-

Scope. 1) The information returned by device search

engines is often incomplete. 2) There are many ICS

honeypots in the results of device search engines. 3)

It is not easy to accurately ﬁnd the vulnerabilities that

affect the ICS devices.

To address these challenges, we build ICScope

with data enrichment module, honeypot detection

module, and vulnerability association module. For

the ﬁrst challenge, the data enrichment module inte-

grates the device information extracted from multiple

search engines to enrich the incomplete device infor-

mation. It also uses the ﬁngerprint database. For the

second challenge, the honeypot detection module uti-

lizes the non-interaction features to detect ICS honey-

pots, such as ISP, ICS honeypot ﬁngerprinting. It also

detects ICS honeypots by comparing the results be-

tween multiple search engines. For the last challenge,

the vulnerability association module builds vulnera-

bility trees to identify each ICS device’s vulnerabili-

ties.

We have implemented ICScope and performed a

large-scale measurement of ICS devices’ security sta-

tus in the whole public address space. We collect

270,283 Internet-facing ICS devices on four device

search engines from Dec 2019 to Jan 2020. Among

these ICS devices, ICScope has detected 21,578 ICS

honeypots (about 7.98%). Excluding these ICS hon-

eypots, we observe that 106,382 ICS devices can ex-

tract complete ICS device entries. And ICScope re-

gards 52,739 of them (about 49.58%) as vulnerable

ICS devices. We further analyze the vulnerable ICS

devices and related vulnerabilities. We ﬁnd that the

vulnerable ICS devices are distributed in the vast ma-

jority of countries. Among the vulnerabilities, most

of them are in high or critical severity level and can

be remotely exploitable with little or no limitation.

Over six months, our measurement shows a slowly

decreasing trend in the number of vulnerable ICS de-

vices. We also use ICScope to measure the impact of

a 0day vulnerability. The result shows that the vulner-

ability affects 3,999 ICS devices.

Contribution. Our contributions can be summarized

as follows:

1. We design and implement a passive vulnerability

assessment tool ICScope. ICScope can automat-

ically obtain ICS devices’ information from mul-

tiple device search engines and correlate the vul-

nerabilities of each device.

2. By using ICScope, we perform the large-scale

measurement on the security status of all Internet-

facing ICS devices in the whole public IP address

space and ﬁnd that 49.58% of the Internet-facing

ICS devices with complete device entries are vul-

nerable. We also further characterizing the vul-

nerable ICS devices.

3. We proposed a non-interaction ICS honeypot de-

tection approach to detect the ICS honeypots

without intrusive behaviors. This method has de-

tected 21,578 ICS honeypots (about 7.98%) on

our datasets.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

238

Our results reveal the severe and considerable se-

curity risks faced by ICS devices in the current cy-

berspace. At the end of the paper, we discuss the mit-

igation measures against this security threat.

2 MOTIVATION AND

CHALLENGES

2.1 Motivation

The risk of Internet-facing ICS devices is a persis-

tent problem. Most existing works focus on what

devices have been exposed to the Internet or the at-

tacker’s malicious behaviors (Fachkha et al., 2017).

Researchers perform vulnerability assessments for

Internet-facing ICS devices (Samtani et al., 2016;

Leverett and Wightman, 2013). However, these works

are usually limited in scale and scope. More impor-

tantly, their approaches cannot avoid intrusive behav-

iors.

In this paper, we seek to provide a more compre-

hensive and holistic view of Internet-facing ICS de-

vices’ security status via a large-scale empirical mea-

surement. We obtain more comprehensive Internet-

facing ICS devices by integrating multiple search en-

gines’ data and perform passive vulnerability assess-

ment on them. We further analyze the vulnerable ICS

devices and related vulnerabilities across multiple di-

mensions, e.g., geolocation distribution, vulnerability

ratio. We also conduct a non-interaction ICS honey-

pot detection to decrease false positives while previ-

ous vulnerability assessment works not.

2.2 Challenges

There are three main challenges in designing a passive

vulnerability assessment system.

Incomplete Banners. Not all banners returned by

device search engines contain complete device in-

formation. For example, the different banners of

the same ICS device are respectively returned by

Shodan and FOFA (see Figure 1a and Figure 1b).

Compared to Shodan, the FOFA’s banner lacks the

Basic Firmware information used to extract version

information. Moreover, both of them do not contain

vendor and product information. Existing works that

reconstruct CPE names from banners are limited to

the lack of device information. Fortunately, we ob-

serve that device search engines’ capabilities are dif-

ferent, and part of device information can be identi-

ﬁed through a particular ﬁeld in ICS protocol. Based

on this observation, we try to extract complete device

Basic Hardware: 6ES7 313-6CE01-0AB0 v.0.1

Module: 6ES7 313-6CE01-0AB0 v.0.1

Basic Firmware: v.2.0.11

(a) Shodan banner

Vendor: SIEMENS

Product: SIMATIC S7-300 CPU 313C-2DP

Version: v2.0.11

(d) Device Information

Basic Hardware: 6ES7 313-6CE01-0AB0

Module: 6ES7 313-6CE01-0AB0

(b) FOFA banner

Online Shop

Figure 1: Device information for SIMATIC S7-300 with

banners returned by Shodan and FOFA.

information from banners returned by multiple device

search engines based on ICS protocol features. For

the ICS device in Figure 1, we extract its version from

the Shodan banner. Through the article number found

in the banner, we obtain its vendor and product from

the SIEMENS online shop.

Honeypot Detection. Industrial honeypots are wildly

used in the detection of industrial control security

threats (Serbanescu et al., 2015). The device search

engines also add honeypots to the query results to

monitor the abuse of them by attackers. Previous

works (Feng et al., 2016) that utilize network ﬁnger-

printing technology (Comer and Lin, 1994) are not

working here due to the lack of interaction. We lever-

age the non-interaction features to detect ICS hon-

eypots, such as the ﬁngerprints of open-source ICS

honeypots and the device inconsistencies in different

search engines.

Associate Vulnerabilities. Previous works (Genge

and En

achescu, 2016; O’Hare et al., 2019) utilize the

most similar CPE name reconstructed from banner to

ﬁnd possible vulnerabilities. However, this approach

is limited to ICS. First, some ICS devices might have

more than one CPE name, while some have none. For

example, the device’s CPE name in Figure 1 can be

cpe:/h:siemens:simatic s7-300 cpu:2.0.11 or

cpe:/h:siemens:simatic s7-300 cpu 313:2.0.

11. Second, CPE data used to identify the impact

range of a vulnerability in the National Vulnerability

Database (NVD) is exaggerated or underesti-

mated (Dong et al., 2019). Rather than reconstructing

the CPE name, we construct vulnerability trees from

multiple public vulnerability libraries and use them

to associate vulnerabilities.

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age

239

Banner

Processing

Data

Enrichment

Data Acquisition Information Extraction Vulnerability Association

Banners

Shodan

Censys

FOFA

SiNan

ICS Device

Entries

Vulnerability

Tree

Associate

Vulnerabilities

Vulnerable

ICS Devices

Vulnerability

Databases

Honeypot

Detection

Figure 2: Architecture of the ICScope.

3 ICScope

In this work, we design and implement a search en-

gine based automatic passive vulnerability assess-

ment tool for ICS, ICScope, and present its design in

this section.

3.1 Overview

The overall architecture of ICScope is shaped in Fig-

ure 2, which consists of three modules. First, the data

acquisition module (§3.2) collects all Internet-facing

ICS device data via the Application Programming In-

terface (API) of search engines. Then, the informa-

tion extraction module (§3.3) extracts device infor-

mation, i.e., vendor names, product names, and ver-

sions, from the ICS device banners returned by search

engines. The information extraction module (§3.3.3)

also detects and excludes the ICS honeypots in the

results. Finally, the vulnerability association module

(§3.4) constructs vulnerability trees from the public

vulnerability libraries and utilizes it and the extracted

device information to associate possible vulnerabili-

ties.

3.2 Data Acquisition

The search engines provide APIs with search ﬁlters,

which are special keywords for special properties. For

example, protocol:s7 is used to ﬁnd all Internet-

facing ICS devices in FOFA

, which use the S7 proto-

col. As reported by Guo et al., the data integration of

multiple device search engines can obtain more com-

prehensive Internet-facing ICS devices (Guo et al.,

2018). Table 1 shows the industrial control protocols

and device search engines supported by ICScope. IC-

Scope leverages the APIs and special search ﬁlters to

acquires all Internet-facing ICS devices from different

device search engines’ databases.

https://fofa.so/

Table 1: Protocols supported by ICScope. X: supported by

device search engine; 4: enriched by ICScope.

Protocol Name

Device Search Engines

Enrich

Shodan Censys FOFA SiNan

Modbus X X X X -

Siemens S7 X X X X 4

DNP3 X X X X -

Niagara Fox X X X X 4

BACnet X X X X 4

EtherNet/IP X - X X 4

GE-SRTP X - X X -

HART-IP X - X X -

PCWorx X - X X 4

MELSEC-Q X - X X -

OMRON FINS X - X X 4

Crimson v3 X - X X -

CoDeSys X - X X 4

IEC 60870-5-104 X - X X -

ProConOS X - X X -

VertX Edge - - X X 4

Moxa NPort - - X X -

Lantronix UDP - - X X -

Koyo DirectNet - - - X -

HollySys MACS - - - X -

Proﬁcy-webspace - - - X -

Siemens License - - - X -

Total 15 5 18 22 8

3.3 Information Extraction

As shown in Figure 2, the information extraction

module consists of three submodules:

3.3.1 Banner Processing

This submodule takes the banners as input and out-

puts the device information. An ICS device entry

can be characterized by the tuple hvendor, product,

versioni. Except for the ICS device entry, device in-

formation also includes feature information for data

enrichment or honeypot detection, i.e., the article

number in the S7 protocol. However, the ﬁelds of de-

vice information are different in different ICS proto-

cols. We analyzed 22 ICS protocols and wrote parsers

for them separately.

3.3.2 Data Enrichment

The challenge here is that the banners returned by

search engines are incomplete. To address this, we

take the following three ways to enrich the incomplete

ICS device entry:

Data Enrichment based on Industrial Control Pro-

tocol. Some attributes of ICS device entry might show

as identiﬁers rather than the exact value in some ICS

protocols. For example, BACnet deﬁnes a numerical

”vendor identiﬁer” to arbitrate between non-standard

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

240

messages of different manufacturers. Each vendor

identiﬁer has been assigned to a vendor. For the pro-

prietary protocols, we can identify their vendors di-

rectly, e.g., SIEMENS for S7 protocols. Based on

these observations, we manually build several map-

pings between identiﬁers and exact values. ICScope

utilizes these mappings to supplement the missing at-

tributions.

Data Enrichment based on Fingerprint Database.

Some banner ﬁelds can be used to identify the de-

vice information, such as the product-ID system’s

ﬁeld. An example is the article number 6ES7

313-6CE01-0AB0 in Figure 1, which is the SIEMENS

product-ID system’s identiﬁer. We utilize these ﬁelds

to build the ﬁngerprint database for ICS devices.

Data Enrichment based on Multiple Search En-

gines. Device search engines perform differently

on each ICS protocols. Excepting the number of

discovered devices, the banners can also be differ-

ent. As shown in Figure 1, Shodan can acquire

Basic Firmware, but FOFA not. The strategy is to

integrate the device information extracted from mul-

tiple search engines for complete ones. ICScope

supports four search engines: Shodan, Censys (Du-

rumeric et al., 2015), FOFA, and SiNan

3.3.3 Honeypot Detection

To achieving accuracy in discovering vulnerable

Internet-facing ICS devices, ICScope detects ICS

honeypots within the results in passive mode. IC-

Scope adopts the following approaches:

Multi-source Comparison. Although the search en-

gines’ scanning time is different, the industrial con-

trol system devices are usually neither upgraded nor

replaced for the duration. So the data information for

an ICS device should be the same at different search

engines. If the data information is inconsistent, we

regard this ICS device as an ICS honeypot. Notice

that if multiple ICS protocols are found for one ICS

device, we can not verify whether it is an ICS honey-

pot based on current features. We regard them as ICS

honeypots to decrease false positives. After inspect-

ing these IPs, we ﬁnd they might be veriﬁed by the

non-ICS ports’ information, such as the HTTP service

ports. We leave it as our future work.

Fingerprinting Detection. We utilize ﬁngerprint-

based methods to detect ICS honeypots. We extract

characteristics from the open-source industrial hon-

eypot as ﬁngerprints, such as default conﬁguration,

prompt information.We also ﬁnd that some ﬁelds in

the ICS protocol are assigned to a unique device, i.e.,

An internal device search engine newly developed by

QiAnXin, china in 2018.

Vendor 1

Product 1 Product 2



Product n



…



<CVE, Version Range>

Figure 3: Data structure used to store vulnerabilities (Vul-

nerability Tree). Green color denotes the information stored

on the leaf.

the MAC in Moxa NPort protocol. ICScope leverages

such ﬁngerprinting to detect ICS honeypots.

ISP-based Detection. ICS honeypots are often de-

ployed on cloud service. However, no cloud ser-

vice provider has provided online industrial control

device services. Therefore, we can reasonably infer

that the devices with an IP belonging to cloud service

providers are ICS honeypots.

3.4 Vulnerability Association

Vulnerability Tree. We adopt a multi-forked tree for-

est to store all vulnerability information, and each tree

represents all vulnerabilities that affected the same

vendor. As shown in Figure 3, each tree takes the

vendor as the root node. The intermediate nodes are

the vulnerable products that belong to the vendor, and

each leaf node represents a related vulnerability. Each

leaf node stores the CVE name and corresponding

version range of the vulnerability. Notice that the dif-

ferent intermediate nodes might denote the same de-

vice. For example, the ICS device in Figure 1 has two

different intermediate nodes (simatic s7-300 cpu

and simatic s7-300 cpu 313) on the vulnerability

tree. For more comprehensive vulnerabilities, we use

multiple vulnerability libraries (NVD, China National

Vulnerability Database of Information Security (CN-

NVD), and SecurityFocus) to construct the vulnera-

bility trees. We also use the data from Exploit-DB,

SecurityFocus, PacketStorm to determine whether

there is a public exploit for a vulnerability.

Associate Vulnerabilities. We utilize the information

extraction results and vulnerability tree to associate

ICS devices with vulnerabilities. We adopt a version-

based associating scheme. We assume that an ICS

device is affected by a vulnerability when its version

is in the vulnerability affected scope. The overall as-

sociation strategy is shaped in Algorithm 1. For each

ICS device, we ﬁrst use the sim lookup() function

to ﬁnd similar vendors and products in the vulnerabil-

ity tree. Through the vulnerability tree, we decrease

unnecessary comparisons. Second, we extract all vul-

nerabilities associated with similar vendors and prod-

ucts in the vulnerability tree. For each vulnerability,

we check whether the ICS device’s version is in the

vulnerability affected scope. If the version is affected,

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age

241

Algorithm 1: Associate ICS device with vulnerabilities.

Input: ICS device entry hvendor, product, versioni, Vul-

nerability Tree(V T )

Output: a set of possible CVE names (R

cve

)

cve

← {}

vt vendors ← all root nodes of VT

for each vt vendor ∈ vt vendors do

if sim lookup(vendor, vt vend or) then

vt products ← all sub-nodes of vt vendor in V T

for each vt product ∈ vt products do

if sim lookup(product, vt product) then

vt vuls ← all leaves of vt product in V T

for each hcve, versionRangei ∈ vt vuls do

if match(version, versionRange) then

cve

← R

cve

+ cve

end if

end for

end if

end for

end if

end for

we add the CVE name of the vulnerability into the set

of possible CVE names.

4 DEMYSTIFYING

INTERNET-FACING ICS

DEVICES SECURITY STATUS

In this section, we use ICScope to evaluate the se-

curity status of Internet-facing ICS devices in the

whole public IP address space. We ﬁrst introduce the

datasets used by ICScope and then we analyze the se-

curity status of Internet-facing ICS devices. Finally,

we compare our work with the vulnerability detection

function provided by Shodan.

4.1 The Datasets of ICScope

The data collected by ICScope can be divided into two

parts: data of Internet-facing ICS devices from the de-

vice search engine and vulnerability information from

public vulnerability database. We retrieve Internet-

facing ICS devices from the four device search en-

gines between Dec 2019 and Jan 2020. We ob-

tain 76,489/219,238/78,363/85,531 device informa-

tion from Shodan, Censys, FOFA and SiNan, respec-

tively. The device number of FOFA is much larger

than the others because the time span of the FOFA

is one year, but the others not. The independent IPs

for the above results is 270,283. To monitor Internet-

facing ICS devices, we also conducted the experi-

ments per three months from Jun 2020 to Dec 2020.

We obtain 229,048/225,473/242,034 Internet-facing

ICS devices in Jun 2020, Sep 2020, and Dec 2020,

respectively. We crawl the published vulnerability in-

formation from NVD, CNNVD, Exploit-DB, Secu-

rityFocus and PacketStorm, and merged all the in-

formation into 286,269 distinct enriched vulnerability

records, of which 160,795 are from CVE and 129,653

are from NVD.

4.2 Discovery Approaches Validation

First, we evaluate the performance of our honeypot

detection module. Shodan provides an interface

query the probability that an IP is a honeypot. Among

the above ICScope datasets, Shodan only ensures

55 IPs as honeypots. We use these IPs as a cross-

validation dataset to validate the honeypot detection

module results. For these ICS honeypots, ICScope

can detect 52 of them (about 94.55%). We manu-

ally inspect the remaining 3 IPs. We notice that the

information extraction module returns none for two

of them. However, our approach is based on the de-

vice information returned by the information extrac-

tion module. The last one seems like a normal ICS

device. The reason might be the limitation of the fea-

tures in our approach.

Secondly, we evaluate the precision of our device

discovery approach. The ICS devices reside in the re-

mote Internet space. We cannot perform active-mode

scanning due to ethical considerations. We also try

to contact several vendors with their devices exposed,

but none of them accept our request to ﬁll a survey

obtaining the ground truth of the exposed devices.

Therefore, we report the 319 vulnerable ICS devices

located in our own country to the relevant Computer

Emergency Response Team (CERT). Until the time of

paper submission, the CERT team has dealt with 59

of them and they conﬁrm that ICScope identiﬁes the

vendor, product and version information and the asso-

ciated vulnerabilities of all 59 devices correctly. The

results show that our device discovery approach has

high accuracy. And we plan to share the ICScope tool

and discovered vulnerable ICS devices to the inter-

ested CERT teams and help to deal with the exposed

and vulnerable ICS devices.

4.3 The Honeypots in Internet-facing

ICS Devices

Among the 270,283 Internet-facing ICS devices, IC-

Scope regards 21,578 of them (about 7.98%) as ICS

honeypots. Among these ICS honeypots, the multi-

source comparison-based approach detects 18,428 of

them (about 85.40%), while the ISP-based approach

https://honeyscore.shodan.io/

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

242

detects 3,653 (about 16.93%). Furthermore, the

ﬁngerprinting-based approach detects 1,216 (about

5.64%). Notice that an ICS honeypot might occur

multiple times on the above results.

Vendor Product

Version

2.75% 6.60%

0.77%

2.40%

0.69% 12.86%

73.93%

Figure 4: Attribution-distribution of inconsistent ICS de-

vices. The three circles represent the percentage of devices

with vendor, product, and version inconsistency among all

inconsistent devices.

(a) Vendor recognition rate

at all ICS protocols

(b) Product recognition rate

at all ICS protocols

(d) Vendor recognition rate

at BACnet protocols

(e) Product recognition rate

at BACnet protocols

(f) Version recognition rate

at BACnet protocols

Figure 5: Recognition rate of different attributions.

4.4 The Advantage of Multiple Device

Search Engines

Inconsistencies in Device Search Engines. We

ﬁrst analyze the inconsistencies between the different

search engines. Since the probability of upgrading or

replacing the device during the scanning cycle is ex-

tremely low, the differences indicate that it may be

a honeypot. We are mainly concerned about the in-

consistency of the vendor, product, and version. As

shown in Figure 4, most of the inconsistencies are

related to the version. Devices with version incon-

sistency account for 89.89% of the total inconsistent

devices. It is worth noting that search engines identi-

ﬁed entirely different results on 2.4% of inconsistent

devices. We tag these inconsistent devices as honey-

pots.

Data Enrichment with Multiple Device Search En-

gines. As mentioned in Section 2.2, the results of

search engines, including incomplete data. This prob-

lem can be alleviated by data enrichment. Different

search engines have different ability to recognize dif-

ferent attributes of devices. We extract the attributes

that can be identiﬁed by different search engines and

combine them to get complete device information.

Figure 5 shows the different abilities of the four

search engines on recognizing different device at-

tributes. From Figure 5a, Figure 5b and Figure 5c,

we can know that the search engines, except for Cen-

sys, performs well in recognition of vendor and prod-

uct. But all the four search engines are weak in rec-

ognizing version, among which, Censys get the best

recognition rate of 56.6%. Taking the BACnet proto-

col as an example, we can obtain the version informa-

tion from Censys and the other information from the

other three search engines (See Figure 5d, Figure 5e,

Figure 5f).

4.5 The ICS Devices Affected by Public

Vulnerabilities

For the 22 industrial control protocols mentioned in

this paper, we can completely extract vendor, prod-

uct and version information in only 9 of them (See

Table 2). We obtain 215,649 ICS devices using one

of the 9 ICS protocols from device search engines.

After excluding 15,294 devices that may be indus-

trial controlled honeypots, 106,382 (about 53.10%)

devices can extract complete information. For those

devices with complete information, there are 52,739

(about 49.58%) devices affected by one or more vul-

nerabilities. Figure 6 shows the percentage of vul-

nerable ICS devices in different protocols. Next, we

focus on the analysis of the impact of public vulnera-

bilities on these 52,739 devices.

Protocol-distribution of Vulnerable ICS Devices.

Table 2 shows the impact of public vulnerabilities

in ICS devices. We ﬁnd that about half of Internet-

facing ICS devices are still vulnerable, thus having

the risks of being compromised. More than half of

the ICS protocols have at least 40% vulnerable de-

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age

243

Figure 6: Vulnerable device percentage at protocol-level.

Table 2: Statistics result of vulnerable devices.

Protocol Name Vulnerable Devices

Vulnerable

Percentage

Modbus 3461 28600 12.10%

Siemens S7 4400 7663 57.42%

Niagara Fox 35669 37060 96.25%

BACnet 1918 14405 13.31%

EtherNet/IP 4006 9171 43.68%

PCWorx 1444 3610 40.00%

OMRON FINS 208 2032 10.24%

CoDeSys 1633 3526 46.31%

VertX Edge 0 315 0.00%

Total 52739 106382 49.58%

*Devices: refers to total number of ICS devices with complete vendor,

product and version information.

vices. In particular, the percentage of vulnerable ICS

devices using Niagara Fox protocol, the most seri-

ous protocol, is close to 100%. For Vertx Edge, we

only ﬁnd one remote code execution vulnerability of

an HID VertX/Edge device in the public vulnerabil-

ity databases, more speciﬁc, from SecurityFocus and

PacketStorm. However, there is no detailed impact

scope of this vulnerability. Thus the assessment re-

sult for VertX Edge is 0.00%.

Geo-distribution of Vulnerable ICS Devices. We

adopt the Hilbert curve (Moon et al., 2001) to visu-

alize the vulnerable ICS device distribution in the In-

ternet space. As shown in Figure 7, the distribution

of vulnerable ICS devices is irregular. It is hard to

ﬁnd any correlation between vulnerable ICS devices

and IP. Although we cannot ﬁnd any correlation at IP-

layer, we can also investigate the correlation between

spatial location and vulnerable ICS device distribu-

tion. Figure 8 shows the geographical distribution of

Internet-facing ICS devices affected by public vulner-

abilities. These vulnerable ICS devices are distributed

in the vast majority of countries around the world,

among which the United States, Italy, Canada, France

and Spain are on the top. In particular, the United

States is the only country that has over 10,000 vulner-

Figure 7: Hilbert curve heatmap of vulnerable ICS devices

in the IPv4 addresses space.

Figure 8: Geo-distribution of vulnerable ICS devices.

able devices (21,156), which accounts for 40.11% of

all vulnerable Internet-facing ICS devices. We further

analyze the proportion of vulnerable ICS devices in

each country. Among the six continents, North Amer-

ica has the highest proportion of vulner- able ICS de-

vices, with an overall rate of 39.48%. This is mainly

because the proportion of vulnerable ICS devices in

the United States and Canada with more than 1000

ICS devices is as high as 40.72% and 35.48%, respec-

tively. The rest are Australia (20.99%), South Amer-

ica (20.23%), Europe (19.93%), Asia (11.66%) and

Africa (9.15%). As shown in Figure 9, more than 90%

of the Niagara Fox vulnerable devices can be found in

the top 10 countries, and there is a long-tail effect in

their vulnerable ICS devices distribution. There are

similar distribution characteristics in other vulnera-

ble ICS devices. At the city-level, Figure 10 shows

a long-tail effect in vulnerable ICS devices. The Ni-

agara Fox protocol has the most extensive coverage.

More than 43% of the Niagara Fox vulnerable devices

are located in the top 50 cities, 60% of the Niagara

Fox are in the top 134 cities. OMRON FINS has the

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

244

Figure 9: Location distribution of vulnerable ICS devices at

country-level.

Figure 10: Location distribution of vulnerable ICS devices

at city-level.

least coverage. The cities which have ICS devices us-

ing OMRON FINS protocol are only 34.

Vulnerable ICS Devices over Time. Among

the three experiments over six months, we ﬁnd

46,489/38,466/37,027 vulnerable ICS devices, re-

spectively, and the details are shown in Figure 11.

There is a slowly decreasing trend in the number of

vulnerable ICS devices for most ICS protocols dur-

ing our measurement period. This indicates that peo-

ple had taken some measures to mitigate the risk

of Internet-facing ICS devices, but still not enough

counter-measures. However, the Siemens S7 pro-

tocol shows an anomalously increasing trend in the

number and percentage of vulnerable ICS devices.

This mainly due to the growing number of exposed

SIMATIC S7-1200 devices.

4.6 The Statistics of ICS Vulnerabilities

We then carry on the statistical analysis of the ICS

vulnerabilities mentioned above. We ﬁnd that only

207 different vulnerabilities affect a total of 52,739

ICS devices. We classify these vulnerabilities accord-

ing to protocols and then further analyze the impact

scope, CVSSv3 score, and life cycle of vulnerabili-

ties under different protocols.

Figure 11: Vulnerable ICS devices over time. The solid

lines represent the number of vulnerable ICS devices. The

dash lines represent the percentage of vulnerable ICS de-

vices.

Top 5 Vulnerabilities in Different ICS Protocols. Ta-

ble 3 shows the top 5 ICS vulnerabilities in different

industrial control protocols. For Niagara Fox proto-

col, the three vulnerabilities we found affect about

96.25% of all Niagara Fox ICS devices with com-

plete information. There are similar characteristics in

PCWorx and CoDeSys protocols. For such vulnera-

bilities, ICS engineers should take measures to ﬁx or

mitigate them as soon as possible.

Figure 12: Severity distribution of ICS vulnerabilities in

different protocols.

The Severity of ICS Vulnerabilities in Different ICS

Protocols. We use the Common Vulnerability Scor-

ing System(CVSS)(version 3) to assess the severity

of ICS vulnerabilities. CVSS version 3.0 was released

in June 2015, and vulnerabilities released before that

date have no CVSSv3 score. 46 out of 207 ICS vul-

nerabilities are released before June 2015, and the ICS

vulnerabilities of OMRON FINS and CoDeSys are all

among them. As shown in Figure 12, the ICS vulner-

abilities with high or critical severity in all ICS pro-

tocols are at least 60%. The severity of vulnerabili-

ties in the PCWorx protocol, the most severe proto-

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age

245

Table 3: Top 5 vulnerabilities in different ICS protocols.

Modbus Siemens S7 BACnet EtherNet/IP

CVE Numbers CVE Numbers CVE Numbers CVE Numbers

CVE-2015-7937 3095 CVE-2017-2680 4384 CVE-2019-18249 1770 CVE-2017-7898 3147

CVE-2015-6461 3077 CVE-2017-2681 4384 CVE-2016-4495 37 CVE-2017-7899 3147

CVE-2015-6462 3077 CVE-2017-12741 4337 CVE-2016-3155 36 CVE-2017-7901 3147

CVE-2018-7241 2462 CVE-2019-10936 4246 CVE-2018-7779 27 CVE-2017-7902 3147

CVE-2018-7242 2462 CVE-2018-13815 3021 CVE-2018-7795 25 CVE-2017-7903 3147

Total vul num: 22 Total vul num: 56 Total vul num: 93 Total vul num: 29

Niagara Fox PCWorx OMRON FINS CoDeSys

CVE Numbers CVE Numbers CVE Numbers CVE Numbers

CVE-2017-16744 35669 CVE-2019-9201 1444 CVE-2015-0987 208 CVE-2014-0760 1633

CVE-2017-16748 35669 CVE-2019-10953 605 CVE-2015-1015 195 CVE-2014-0769 1633

CVE-2018-18985 35669 - - - - - -

Total vul num: 3 Total vul num: 2 Total vul num: 2 Total vul num: 2

*Numbers: refers to the number of devices affected by the vulnerabilities.

Figure 13: Average score and outliers of ICS vulnerabilities

in different protocols.

Figure 14: Vulnerabilities Existing Time.

col, is high or critical. Figure 13 shows the CVSSv3

scores of vulnerabilities in different protocols. The

average scores revolve around 7.5, and the scores of

most vulnerabilities are spread across the 7.5-10 spec-

trum. Among the ICS vulnerabilities, 69.23% are re-

motely exploitable, 74.52% do not require any special

conditions, and 66.35% could be executed without au-

thorization.

The Timeline of ICS Vulnerabilities in Different ICS

Protocols. Figure 14 shows the disclosure time of

the vulnerabilities mentioned above. We can ﬁnd

that most of the vulnerabilities are disclosed within 3

years, yet 19.80% have been disclosed for more than 5

years. Among these vulnerabilities, we ﬁnd that there

are 40 vulnerabilities (about 19.32%) which exploits

are published on the Internet. This indicates that these

corresponding affected devices are in a highly danger-

ous state.

4.7 The ICS Devices Affected by 0day

Vulnerabilities

ICScope also supports the evaluation of the impact of

0day vulnerabilities. We use ICScope to evaluate the

impact of a 0day vulnerability we found in Schneider

Electric device. This vulnerability affects four dif-

ferent products, including Modicon M580 (version ≤

3.10). We ﬁnd that 3,999 Schneider Electric devices

exposed to the Internet are affected by this vulnerabil-

ity. We have reported this vulnerability to the vendor

and waiting for the vendor to ﬁx it.

4.8 Comparison with Shodan

Vulnerability Detection

Shodan also tries to verify whether the target device

is affected by known vulnerabilities. We use this

function of Shodan to detect the vulnerability of the

ICS devices that the complete information can be ex-

tracted. For 106,382 different IP addresses, Shodan

ﬁnds only 3,472 (about 3.26%) associated with one

or more vulnerabilities. Moreover, the vulnerabili-

ties detected by Shodan are all Web-based vulnerabil-

ities instead of ICS vulnerabilities. Comparing with

Shodan, ICScope ﬁnds that 52,739 Internet-facing

ICS devices (about 49.58%) are affected by at least

one ICS vulnerabilities. As for ICS vulnerability de-

tection, ICScope performs better than Shodan.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

246

5 RELATED WORK

Passive Vulnerability Assessment in Cyberspace.

Passive vulnerability assessment is an eco-friendly

and resource-conserving research method for large

scale security measurement towards Cyber-Space.

B Genge et al. are the ﬁrst to propose the

Shodan-based passive vulnerability assessment tool,

ShoVAT (Genge and En

achescu, 2016). The CPE

based vulnerability matching technique used by

ShoVAT is heavily dependent on the quality of its

CPE dictionary. Jamie O’Hare et al (O’Hare et al.,

2019) improved the previous work and proposed

Scout to perform a passive vulnerability assessment

of HTTP services on the Internet. Compared with

ShoVAT, Scout focuses on the accuracy of vulnerabil-

ity matching. By comparing with the scanning result

of OpenVAS, Scout’s results are more practical. How-

ever, neither of the works mentioned above is suit-

able for the industrial control scenario. Their match-

ing techniques depends on the quality of the banners

returned by search engines. However, it is common

that the banners are incomplete in ICS. We mitigate

this problem with our data enrichment module. More-

over, previous works on passive vulnerability assess-

ment rarely consider the honeypot problem. ICScope

try to address it to increase the accuracy of vulnera-

bility detection.

Online ICS Device Discovery. Previous works on the

discovery of online ICS devices are always a hot topic

on ICS security. Mirian et al. (Mirian et al., 2016) ex-

tend ZMap (Durumeric et al., 2013) to support four

ICS protocols and scan the public IPv4 address space

to discover online ICS devices. Differently, Feng et

al. (Feng et al., 2016) investigates 17 industrial con-

trol protocols and develop their ICS device discovery

system to conduct ICS device discovery. Although

both of them have tried to minimize the number of

probing packets, their systems still need to interact

with target devices. By using search engines, ICScope

can discover online ICS devices without any commu-

nication interactions. By using multiple search en-

gines, ICScope can better tolerate the limitation of

scanning nodes.

ICS Honeypot Detection. The honeypots in ICS se-

curity are often used to perform ICS threat analy-

sis (Mirian et al., 2016; Vasilomanolakis et al., 2016;

Serbanescu et al., 2015). There are few works con-

sidering ICS honeypot detection. Feng et al. (Feng

et al., 2016) propose a learning model to determine

the probability of an ICS honeypot and a heuristic al-

gorithm to verify it with the least number of packets.

However, both the learning model and the algorithm

are based on the probing packets. The ICS honeypot

detection approach used in ICScope is based on the

non-interaction features. So it has no probing packet

with ICS devices.

6 DISCUSSION

Ethical Considerations. From an ethical perspective,

we perform our measurements in a completely passive

mode to avoid any potential damage. The data used

for ICScope contains no sensitive data, and the data

provided by public search engines are publicly avail-

able. However, because the vulnerable ICS devices

are still unﬁxed, we cannot publish our datasets and

over 52K vulnerable ICS devices directly. Instead, we

report vulnerable ICS devices in our country to rele-

vant CERT, and we also try to contact several vendors.

Limitations. First, the above experiment results only

show a subset of the security status of Internet-facing

ICS devices. The actual situation should be more se-

rious. This is a limitation because it is difﬁcult or

impossible to obtain all Internet-facing ICS devices

via search engines, and not all ICS devices can be ex-

tracted full information. Second, while we obtain vul-

nerable Internet-facing ICS devices, we still do not

conﬁrm whether there is any defensive measure on

them. Because ICScope is based on version to iden-

tify vulnerabilities rather than proof of concept(PoC).

Third, the supporting ICS protocols of ICScope is

limited to the ability of search engines. ICScope sup-

ports one ICS protocols only if its banners contain key

ﬁelds. Fourth, a lack of raw probing packets makes

it harder to extract device information or detect ICS

honeypots because the banners generated by search

engines might lose some information.

Honeypot Detection. It is hard to detect ICS honey-

pots accurately in passive mode. For example, ICS

devices might share one IP by port forwarding. How-

ever, this is also a ﬁngerprint to detect honeypots. We

cannot distinguish them without the help of probing

packets. So we regard all of them as ICS honeypots

to reduce false positives. Fortunately, we ﬁnd that this

problem might be corrected by the data from non-ICS

port, and we leave it as our future work.

Mitigation. We need to take some defensive mea-

sures to mitigate the risk of Internet-facing ICS de-

vices. The intuitive measure is to keep the latest ver-

sion of each ICS device. However, this is difﬁcult or

impossible in the actual ICS environment. Instead, we

can take the following defensive measures:

Add Firewall Policy. By adding ﬁrewall to restrict

source IP and destination port, we can prevent the at-

tack from accessing the vulnerable ICS devices.

Network Isolation. Isolate the ICS devices that need

From Exposed to Exploited: Drawing the Picture of Industrial Control Systems Security Status in the Internet Age

247

Internet connection from the ones that do not need

to prevent the attacker from accessing the vulnerable

devices.

7 CONCLUSION

As a crucial component of modern city infrastructure,

the industrial control system exists in every corner of

our life. However, the Internet-facing ICS devices

are under the risk of known vulnerabilities. In this

work, we develop ICScope to discover the vulnerable

Internet-facing ICS devices. Base on the results, we

perform a comprehensive analysis of the security sta-

tus for online ICS devices. We ﬁnd that 49.58% of

Internet-facing ICS devices that we can extract com-

plete device information are affected by known vul-

nerabilities. The most serious ICS protocol is Niagara

Fox, which proportion of vulnerable devices is even

as high as 96.25%. We observe that most of the vul-

nerable devices are affected by the same vulnerabil-

ity in Niagara Fox, PCWorx, and CoDeSys protocols.

In all ICS protocols, at least 60% of the ICS vulner-

abilities are with high or critical level severity. We

also observe a slowly decreasing trend in the number

of vulnerable ICS devices during our six-month mea-

surement period. Moreover, our measurement results

only present the lower limit of the actual situation. In

response to these severe industrial control security is-

sues, we also discuss the mitigation measures, such as

add ﬁrewall policy.

ACKNOWLEDGEMENTS

We would like to thank all anonymous reviewers for

their valuable feedback that greatly helped us improve

this paper. Besides, we would like to thank Yuxiang

Lu, Zhenbang Ma, Yu Wang, for their helping in our

work.

REFERENCES

Comer, D. E. and Lin, J. C. (1994). Probing tcp implemen-

tations. In Usenix Summer, pages 245–255.

Di Pinto, A. A., Dragoni, Y., and Carcano, A. (2018). Tri-

ton: The ﬁrst ics cyber attack on safety instrument sys-

tems. In Proc. Black Hat USA, pages 1–26.

Dong, Y., Guo, W., Chen, Y., Xing, X., Zhang, Y., and

Wang, G. (2019). Towards the detection of inconsis-

tencies in public security vulnerability reports. In 28th

{USENIX} Security Symposium ({USENIX} Security

19), pages 869–885.

Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., and Hal-

derman, J. A. (2015). A search engine backed by

internet-wide scanning. In Proceedings of the 22nd

ACM SIGSAC Conference on Computer and Commu-

nications Security, pages 542–553. ACM.

Durumeric, Z., Wustrow, E., and Halderman, J. A. (2013).

Zmap: Fast internet-wide scanning and its security ap-

plications. In 22nd {USENIX} Security Symposium

({USENIX} Security 13), pages 605–620.

Fachkha, C., Bou-Harb, E., Keliris, A., Memon, N. D., and

Ahamad, M. (2017). Internet-scale probing of cps:

Inference, characterization and orchestration analysis.

In NDSS.

Feng, X., Li, Q., Wang, H., and Sun, L. (2016). Character-

izing industrial control system devices on the internet.

In 2016 IEEE 24th International Conference on Net-

work Protocols (ICNP), pages 1–10. IEEE.

Genge, B. and En

achescu, C. (2016). Shovat: Shodan-

based vulnerability assessment tool for internet-facing

services. Security and communication networks,

9(15):2696–2714.

Guo, G., Zhuge, J., Yang, M., Zhou, G., and Wu, Y. (2018).

A survey of industrial control system devices on the

internet. In 2018 International Conference on Inter-

net of Things, Embedded Systems and Communica-

tions (IINTEC), pages 197–202. IEEE.

Leverett,

E. and Wightman, R. (2013). Vulnerability inheri-

tance programmable logic controllers. In Proceedings

of the Second International Symposium on Research

in Grey-Hat Hacking.

Mirian, A., Ma, Z., Adrian, D., Tischer, M., Chuenchujit,

T., Yardley, T., Berthier, R., Mason, J., Durumeric,

Z., Halderman, J. A., et al. (2016). An internet-wide

view of ics devices. In 2016 14th Annual Conference

on Privacy, Security and Trust (PST), pages 96–103.

IEEE.

Moon, B., Jagadish, H. V., Faloutsos, C., and Saltz, J. H.

(2001). Analysis of the clustering properties of the

hilbert space-ﬁlling curve. IEEE Transactions on

knowledge and data engineering, 13(1):124–141.

O’Hare, J., Macfarlane, R., and Lo, O. (2019). Identifying

vulnerabilities using internet-wide scanning data. In

2019 IEEE 12th International Conference on Global

Security, Safety and Sustainability (ICGS3), pages 1–

10. IEEE.

Samtani, S., Yu, S., Zhu, H., Patton, M., and Chen, H.

(2016). Identifying scada vulnerabilities using pas-

sive and active vulnerability assessment techniques.

In 2016 IEEE Conference on Intelligence and Secu-

rity Informatics (ISI), pages 25–30. IEEE.

Serbanescu, A. V., Obermeier, S., and Yu, D.-Y. (2015). Ics

threat analysis using a large-scale honeynet. In 3rd In-

ternational Symposium for ICS & SCADA Cyber Se-

curity Research 2015 (ICS-CSR 2015) 3, pages 20–30.

Vasilomanolakis, E., Srinivasa, S., Cordero, C. G., and

uhlh

auser, M. (2016). Multi-stage attack detec-

tion and signature generation with ics honeypots.

In NOMS 2016-2016 IEEE/IFIP Network Opera-

tions and Management Symposium, pages 1227–1232.

IEEE.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

248