Identifying Anomalous Industrial-Control-System Network Flow Activity Using Cloud Honeypots
1 U.S. Naval Postgraduate School, Monterey CA 93943, USA
ncrowe@nps.edu, tdnguyen@nps.edu, dougherty.jeffrey@gmail.com,
matt_bieker@hotmail.com, darry.pilkington@navy.mil
Abstract. This work addressed efficient and effective implementation of honeypots (decoy devices) for industrial control systems in cloud services. The honeypots we investigated simulated control systems of a small electrical-power distribution system. Starting with two honeypot software frameworks called Conpot and GridPot, we increased their deceptiveness by adding new obfuscation techniques, new simulated features of an electric grid, and new control interfaces that mimicked the operator interface for an actual power plant. These deceptions were effective in our first experiments with a standalone honeypot. We then deployed the honeypot at three cloud sites in the U.S. and in Asia. Attacks we observed were mostly similar between the deployments with a few differences. We were concerned that deployment in the cloud could be detected by attackers and discourage them, but we saw no significant differences in activity between the two kinds of deployments; apparently enough systems are managed in the cloud today that such deployment is not suspicious. We conclude that honeypots for industrial control systems using cloud services are an effective tool for collecting attack intelligence.
Keywords: Honeypot, Cloud Services, Industrial Control Systems, Power Plants, Electric Grid, Cybersecurity, Cyberattack, Deception, Conpot, GridPot, Obfuscation, Adversary
This paper appeared in the Proceedings of the National Cyber Summit, Huntsville, Alabama, September 2021.
1 Introduction
In recent years, critical-infrastructure systems have become increasingly complex, interdependent, and reliant on computerized industrial control systems (ICS) [1]. As our dependence on these systems has grown, so has the frequency and complexity of cyberattacks against them. During the initial development of ICS systems from the 1950s, little attention was paid to identifying and managing risk from potential security flaws because the systems were not connected to broad networks. This has now changed [2]. However, ICS systems are often constructed with a planned lifetime of 20 to 30 years, so legacy systems with well-known vulnerabilities continue to be used.
This work studied power-grid (electric-grid) systems in particular [3]. These have become major users of ICSs for power generation, transmission, and distribution. While this has increased efficiency, it has also left power grids increasingly vulnerable to cyberattack. An example occurred in December 2015 when hackers linked to the Russian government used the malware “CrashOverride” to cut electrical power service to over 230,000 people in the Ukraine [4].
Due to the difficulties in securing the legacy software used in many power systems, researchers are examining novel ways to improve their security. One method is the deployment of honeypots (decoy devices) to collect attack intelligence. Cloud services would seem a good way to implement honeypots since they can support large numbers of simultaneous deployments efficiently. Many cyberattack campaigns choose targets and methods randomly, and offering many targets permits defenders to see more variety of attacks [5].
Industries are increasingly using cloud services for
supervisory control of manufacturing, power plants, and other industrial
control systems. Honeypots in the cloud for these purposes may be unconvincing
to cyberattackers who are alert because using cloud services for supervisory
controls is relatively recent, and detection of cloud services is often easy
through lookup of the site owner. Nonetheless, so many cyberattacks are
automated today that rarely do humans attackers inspect the characteristics of
a site anymore.
To confirm this, we can assess the convincingness of cloud honeypots by experimenting
with real cyberattackers. Fortunately, cyberattackers need not be recruited,
as putting any site up on the Internet usually attracts attackers within minutes,
and at a higher rate for industrial control systems than for traditional
computer systems [6].
2 Previous Work
ICS Honeypots are harder to build than other kinds of honeypots because they must simulate physical processes as well as standard network protocols. Nonetheless, several ICS honeypots have emerged. Conpot is the best-known (http://conpot.org), a low-interaction ICS honeypot which simulates basic ICS services including the EtherNet/IP, CIP, HTTP, S7, IPMI, SNMP, CACnet, and Modbus protocols. The GridPot honeypot, built as service of Conpot, simulates an ICS for an electric grid using the grid simulator GridLab-D [7] that provides realistic power-plant data. We developed an enhanced version of GridPot for the experiments reported here.
Other projects have built useful honeypots for ICS systems [8]. One project ran a large-scale low-interaction ICS honeypot using the Amazon EC2 cloud service for 28 days [9]. It serviced several protocols including Modbus, DNP3, ICCP, IEC 104, SNMP (most of the traffic), TFTP, and XMPP. Another project mimicked an electrical provider’s network with an information-technology environment including a data network, an operational-technology environment operating physical processes and machinery, and a controller interface [10]. Soon after its launch, it was subject to ransomware attacks. A commercially available network-appliance honeypot was designed to model electrical-power grids [11] using GridPot. Another project tried to build an ICS honeypot better based on physics, and demonstrated applications to a heating-ventilation system and a water-treatment plant [12]. Two other honeypot prototypes for ICSs are described in [13] and [14]. We have previously studied several other kinds of honeypots [15, 16].
3 Experiments
Our experiments started with an earlier version of GridPot, and debugged and improved it. Client access to the GridPot came in through Conpot on ports 80 and 2404. Changes to the simulated data were sent to a GridLab-D simulation [17] and status changes were returned to the client through Conpot.
Our experiments had five phases. Phases 1 and 2 were run on a network connection through an Internet service provider and outside our organization’s firewall. Phases 3, 4, and 5 were run with the cloud service provider DigitalOcean. More details of the implementations are in [18] and [19].
3.1 Design of Phases 1-2
Our design instantiated the default Conpot template to handle the IEC 60870-5-104 protocol (“IEC 104” for short), and it communicated with GridPot and the GridLab-D simulator. IEC 61850 was used in the original GridPot implementation, and is becoming an industry standard for electrical-substation automation. However, IEC 61850 is substantially more complex than other electric-grid ICS protocols because it specifies a data model, and IEC 61850 products must provide logical descriptions of every device used in the power grid. The IEC 104 protocol is much less prescriptive than IEC 61850, eliminating configuration of the data model as a possible source of error. Since Conpot and our SCADA application both supported full IEC 104 messaging, we chose the IEC 104 protocol for simulating control messaging in our honeypot.
To use IEC 104 with GridPot, a user sends an IEC 104 message to Conpot’s IEC 104 server, which calls a GridPot simulator method to pass the command to the associated GridPot information object. It is then passed to the GridLAB-D simulation which makes any necessary changes and reports back to GridPot, which responds to the user via IEC 104. When Conpot queries a variable value, the GridPot simulator tells that GridPot object to poll its variables and report it.
Our Phase 2 enhanced GridPot with a SCADA (supervisory control) station with a graphical user interface to control the honeypot [20] in the hope of encouraging more direct user interaction with the simulated grid. Users could connect to a virtual machine on a Windows operating system through Microsoft’s Remote Desktop Protocol and communicate with a backend Linux virtual machine running the Phase 1 GridPot. This meant that packets on the Windows host’s inward-facing virtual network interface controller will show only IEC 104 traffic of the types expected between a real SCADA control station and its associated IEC 104 server.
3.2 Changes to the Conpot and GridPot Servers
We gave Conpot ability to distinguish two kinds of IEC 104 information-object variables in the server’s template. GridPot variables mapped to a value in the GridLAB-D simulation, and change whenever they change in the simulation; Python variables mapped to variables in a GridPot object and can only change from user commands. For example, a GridPot switch might have an "enable" flag that must be set to True before the switch can be changed.
We also modified the Conpot IEC 104 server to handle additional commands not in the original GridPot that would increase the realism of the grid simulation. We changed the handling of IEC 104 type-45 (set single-point Boolean), type-46 (set double-point Boolean), type-49 (set scaled value), and type-100 (general interrogation) commands to let them respond without requiring a SCADA application, and added support for type-63 (set floating-point value with time tag) commands for when a user entered a floating-point number in the operator interface.
In Phase 2, we modified the Conpot IEC 104 server to send data updates to a remote user without prompting. To aid handling of updates, we changed the IEC 104 server to provide a pointer to its update handler for the GridPot simulator using the Conpot data bus, and accept a pointer to the simulator’s update handler in return. While this could cause a crash if the server tries to retrieve a nonexistent pointer, testing did not see that.
We changed how the IEC 104 server communicated with our SCADA application. IEC 104 specifies that to change a variable, the remote station must send an "activation" command, to which the server responds with an "activation confirmation" message. The user then commands the server to change the variable and send back both an I-frame with the updated value and an "activation termination" message for the variable. Our SCADA application expects the updated value to come after the termination message and will not listen for it until the termination message has been received, although the documentation was unclear.
We expanded the functionality of the GL_obj class in GridPot to implement methods for object variables not in the GridLAB-D simulation, like the "Python" variables in the Conpot IEC 104 server. We also provided methods for converting between the strings GridLAB-D uses to store data and IEC 104 values which include complex numbers. These changes substantially reduced the amount of device-specific code required for each subclass of GL_obj, as for instance, we could add basic power meters as GridPot devices by instantiating the base GL_obj class without any device-specific code.
We did not simulate the full IEEE 13-Node Model because testing showed it slowed GridPot's operation unacceptably, so we simulated a voltage regulator, a switch, and seven power meters for residential customers. We created two main displays within our SCADA application: a report on the state of all simulated devices in the system, and details of a selected simulated device together with options that allowed users to change the device’s parameters. To lure attackers, the SCADA host provided access to the system by the remote-desktop Guest account, which by default lacks a password and is a popular target for attack [21]. Providing an account without a password required changing the local machine’s security policy and the Windows firewall rules.
3.3 Phases 1-2 Deployment
Phases 1 and 2 ran the honeypot as a virtual machine under VirtualBox 5.2.22 with two virtual processors, 10 gigabytes of memory, and 50 gigabytes of storage in a virtual disk. The physical machine had a bridged adapter, and used the same hardware (MAC) address as that of the host machine’s network-interface controller through which the virtual machine was bridged. The controller's IP address, subnet, and gateway were manually configured to match the host machine's configuration. This allowed Conpot to record the remote IP addresses connecting to its open ports.
In Phase 2 another virtual network-interface controller was attached to the machine to support the graphical user interface. It was itself attached to a VirtualBox internal network equipped with a DHCP server to communicate with the Windows virtual machine hosting the SCADA application. The latter had four virtual processors, 6052 megabytes of memory, and 40 gigabytes of storage. It had two virtual network interfaces; one was connected to the same VirtualBox internal network that the Phase 1 GridPot virtual machine used to communicate with the GridPot virtual machine, and the other was a bridged adapter with its MAC address set to the same address as the host machine’s Internet-facing controller. Since the Windows host could not respond to HTTP traffic, this controller forwarded incoming traffic addressed for TCP port 80 to the internal network-facing controller. This allowed the GridPot HTTP server to respond to these requests.
We collected packet data with Wireshark to compile statistics on the honeypot traffic. Since the Microsoft Remote Desktop Protocol is encrypted, we used the security tool Mimikatz to extract the Windows host's encryption keys, allowing Wireshark to collect traffic in the clear. To restrict packet-capture files to a manageable size, we only recorded packets for the services we studied, HTTP (port 80) and IEC 104 (port 2404). Much IEC 104 traffic was incorrectly formatted and lacked the required starting byte of 0x68. We also collected data from Conpot and Windows logs; the latter were the Windows System, Windows Security, Windows Firewall, Microsoft-Windows-Terminal Services-LocalSessionManager, Microsoft-Windows-Terminal Services-RemoteConnectionManager, Microsoft-Windows-User Profile Service- Operational, Microsoft-Windows-WindowsDefender-Operational, and the Microsoft-Windows-User Profile Service-Operational. Since logs were continuously written to disk, they provided information for periods in which we lost packet captures, though some logs did not record the correct originating IP addresses. We also had trouble with Conpot logs because in some crashes the logger would stop and suddenly output a long list of events at the time it was stopped.
3.4 Phases 3-5 Deployment
We wanted to test whether cloud deployment of our honeypots would see different user behavior since it would involve an easier installation than traditional deployments. Our Phases 3-5 used the cloud provider DigitalOcean. We installed the same honeypot setup with Conpot and GridPot used in Phase 1, but without the SCADA interface because of the problems described in section 4.2. Phase 3 was installed in a virtual machine for easier portability, and Phases 4 and 5 used virtualization methods provided by Digital Ocean. We got baseline data in Phase 3, then further obfuscated the honeypot and ran it at two sites, one in California (Phase 4) and one in Asia (Phase 5), to test regional differences in attacks. Phases 4 and 5 used additional obfuscations (the same for both) beyond Phase 3 in the names used within the honeypot.
Packet data was collected with the software Wireshark and Tshark. Packet capturing was configured to roll over into a new file every 25 megabytes, but this created difficulty for transfer to repositories, so we reduced it to 10 megabytes. Conpot logs were also collected that recorded honeypot-layer activity, and they were useful as backup when other data was unavailable due to crashes.
In Phase 4, the virtual desktop environment initially ran on top of the Ubuntu Linux operating system, but the environment stopped working and we had to use the default terminal console provided by the operating system. When invoked from the console, the bash command to open additional terminal instances did not work, so we executed our programs as background processes. This also required us to switch our packet-capture software to Tshark as Wireshark required a desktop environment for installation. Since background processes are suspended when a secure-shell session ends, Conpot, GridPot, and Tshark were initialized from the “droplet” console on DigitalOcean, and the secure shell was only used for system monitoring, data collection, and data transfer.
3.5 Data Analysis Methods
We wrote a Python program to parse PCAP input files and Conpot log files and record the timestamp, remote IP address, target TCP port, and HTTP method or IEC 104 frame type. For IEC 104 packets, the program also analyzed whether they contained valid frames, defined as TCP segments directed to port 2404 with a payload starting with a byte value of 0x68 and a second byte correctly specifying the length of the message; many packets directed at port 2404 were in HTTP format although that could not possibly work. The remote IP address for each request was also queried in GeoLite2, a free IP geolocation database. The resulting data was then saved into a Pandas DataFrame for analysis.
To determine which IP addresses contacted the honeypot more than once, we wrote another program. A session was defined as all packets exchanged by a socket pair on a day. To more closely inspect IEC 104 traffic, we wrote a program using Scapy to generate IEC 104 packets from Conpot log data for periods in which we lacked PCAP data. We could do this because Conpot logs for IEC 104 messages provide the sending and receiving sockets as well as the payloads, but not for HTTP traffic because Conpot does not capture the full payload of HTTP messages.
4 Results
4.1 Network Scanning
To test whether our honeypots were easy to detect, we used network scanning tools. The Shodan Honeyscore evaluation of our live Phase 1 GridPot said it found a 0% probability of our Phase 1 GridPot being a honeypot. A score of 1.0 (or 100% probability of being a honeypot) was received by the previous version of GridPot [6], indicating that our version is substantially better at evading a commonly used honeypot-detection tool. We also used the Shodan application programming interface to request information on our deployed GridPot. Shodan did not identify it as a honeypot regardless of whether the its history was considered. We conclude that our version of GridPot is better at evading this Shodan-based detection mechanism. We also checked our Phases 3-5 honeypots with the Shodan tool Honeyscore and got a score a score of 0.0 stating they were definitely not honeypots; however, Honeyscore has not been updated recently.
4.2 Compromises in Phase 2
Phase 2 was particularly interesting because our honeypot was compromised twice through the graphical user interface. The first run began on 5/26/20 and indicated compromise on 6/7 when we discovered a process “XMRig Miner” using all our processor. Further investigation found that packet capture had stopped, and a third-party software “Crack_by_NERO” had been installed and locked with a password on the Guest desktop. We found a new folder on the Guest desktop called "xmrig-5.1.1" which appeared to be a crypto-currency miner, as well as a desktop locker executable and a binary file “SpoolerComp.exe”. The password locker achieved persistence by adding itself to the Windows Registry to run automatically on login.
We concluded that malware was installed in the Desktop folder because a Guest user had write access to it. We therefore disabled Guest's write access to Desktop and other folders in their home directory, as well as setting our SCADA software to start at login to make it more apparent that the system was an ICS. A second run was started on 6/17. When we checked the honeypot on 6/29, packet capture was no longer running, the Windows preinstalled Administrator account was visible despite it being made invisible at startup, and a new Administrator-level account called "Admin" had been created. A new executable "opera_portable_56.0.3051.36.exe" had been downloaded to the C:\Program Files directory, as well as several executables labeled as Opera installers.
We concluded that the system was penetrated at least twice on 6/25. The first used the Admin account and installed the infected opera.exe file, but was apparently thwarted by Windows Defender's anti-malware rules. This attack probably originated from the IP address 88.209.137.9. The second attack installed a different file in the same C:\ProgramData directory, which was again stopped by Windows Defender. Then something deactivated Windows Defender and proceeded with the exploit. Although log erasure means we cannot be certain whether these two attacks were related, the occurrence of the same type of malware in the same unauthorized C:\ProgramData directory suggests it.
4.3 Overall Comparison of the Phases
Table 1 shows statistics on the phases so far (as Phases 4 and 5 are still running); Phase 2 provided insufficient data to be useful since much was erased. Sessions were defined as all packets exchanged by a site (socket) pair on a day.
Table 1. Statistics on sessions during the experiments.
|
Phase |
Phase 1 |
Phase 3 |
Phase 4 |
Phase 5 |
|
Days |
157 |
17 |
18 |
18 |
|
Number of addresses that had a single HTTP session |
2747 |
506 |
640 |
3740 |
|
Number of addresses that had multiple HTTP sessions and no ICS sessions |
548 |
118 |
127 |
2464 |
|
Number of addresses that had a single ICS session |
53 |
4 |
9 |
8 |
|
Number of addresses that had multiple ICS sessions and no HTTP sessions |
32 |
1 |
3 |
3 |
|
Number of addresses that had both HTTP and ICS sessions |
20 |
31 |
3 |
3 |
|
Total number of sessions |
7121 |
1811 |
1515 |
21474 |
At first significantly more traffic occurred on the cloud sites in Phase 3 than on the standalone non-cloud sites, indicating that attackers were not discouraged by the cloud implementation. The cosine similarity between the Phase 1 and Phase 3 protocol distributions was 0.998, so the protocol variation was not significantly different. We did see significant differences in the traffic volume between the U.S. and Asia deployments (Phases 4 and 5), which suggest benefits of international cloud services for honeypots. Overall, we confirmed that cloud honeypots are feasible and effective for collecting intelligence on new cyberattacks on industrial control systems.
Table 2 compares the number of sessions and IP addresses between Phases 1 and 3. This suggests that addresses doing single sessions did relatively simple port scans, while others did more detailed investigation of the port. The mean of the weekly fraction of traffic using HTTP over 22 weeks in Phase 1 was 0.934 with a standard deviation of 0.128, so traffic was primarily HTTP.
Table 2. Number of sessions and IP addresses between Phases 1 and 3.
|
Phase |
Protocol |
Number of sessions |
Mean |
Standard deviation |
Number of addresses |
|
1 |
HTTP |
One |
1.97 |
33.67 |
2235 |
|
1 |
HTTP |
Multiple |
38.35 |
169.0 |
573 |
|
3 |
HTTP |
One |
1.37 |
2.96 |
399 |
|
3 |
HTTP |
Multiple |
44.9 |
271.7 |
139 |
|
1 |
IEC 104 |
One |
1.70 |
0.93 |
40 |
|
1 |
IEC 104 |
Multiple |
15.42 |
13.15 |
38 |
|
3 |
IEC 104 |
One |
2.63 |
1.27 |
16.4 |
|
3 |
IEC 104 |
Multiple |
7.68 |
5.50 |
19.4 |
Table 3 further breaks down the IEC 104 traffic seen in all phases. Bearing in mind that Phase 1 ran for a longer period of time than the subsequent phases, Phase 3 actually had the highest rate of IEC 104 activity. The fraction of malformed IEC 104 packets varied significantly from week to week, with a mean over 20 weeks in Phase 1 of 0.505, standard deviation of 0.331, minimum of 0.0, and maximum of 1.0. From this we conclude that valid packets only occur in occasional campaigns and are not broadcast routinely, unlike the HTTP packets.
Table 3. Types of IEC 104 packets observed.
|
Phase |
U-Format frames |
I-Format frames |
Error frames |
Total IEC 104 traffic |
|
Phase 1 |
78 |
19 |
557 |
654 |
|
Phase 3 |
13 |
4 |
171 |
188 |
|
Phase 4 |
11 |
4 |
13 |
28 |
|
Phase 5 |
8 |
2 |
14 |
24 |
Fig. 1 shows that inter-session times for Phase 1 differed significantly between HTTP (on the left) and IEC 104 (on the right). (Sessions were defined as all packets between the same pair of addresses on a day.). Rapid sequences of packets from a single IP address might indicate scanning activity. ICS traffic had short gaps, but HTTP traffic had a wider range with a local peak between 10,000 and 100,000 seconds.
Fig. 1. Inter-packet times for Phase 1
Table 4 shows that the reported countries of origin of the sessions in the experiments were reasonably consistent.
Table 4. Percentages of claimed countries of origin.
|
Phase 1 |
Phase 3 |
Phase 4 |
Phase 5 |
|||||
|
|
Country |
% |
Country |
% |
Country |
% |
Country |
% |
|
1 |
China |
22.5 |
United States |
40.7 |
United States |
34.6 |
United States |
40.9 |
|
2 |
United States |
16.5 |
Russia |
16 |
China |
16.5 |
Singapore |
13.5 |
|
3 |
Russia |
12.3 |
China |
9.1 |
Russia |
10.7 |
Canada |
4.9 |
|
4 |
Taiwan |
4.7 |
Germany |
6.4 |
Netherlands |
6.4 |
Nether-lands |
4.6 |
|
5 |
Brazil |
3.8 |
Nether-lands |
3.2 |
United Kingdom |
5.4 |
France |
4.5 |
|
6 |
Nether-lands |
3.6 |
Brazil |
2.6 |
India |
3 |
Germany |
3.4 |
|
7 |
Germ-any |
3 |
Romania |
2.4 |
Brazil |
2.3 |
China |
2.3 |
|
8 |
Japan |
1.8 |
Seychelles |
2.2 |
Germany |
1.9 |
Italy |
2.1 |
|
9 |
India |
1.7 |
India |
1.8 |
France |
1.7 |
Sweden |
2.1 |
|
10 |
Canada |
1.6 |
Switzer-land |
1.2 |
Romania |
1.7 |
United Kingdom |
2.0 |
|
11 |
Other |
28.5 |
Other |
14.5 |
Other |
15.9 |
Other |
19.6 |
Fig. 2 shows a sample of the traffic rates for Phase 1, and Fig. 3 shows them for Phase 3. These plot the logarithm of the number of incoming requests per day for the honeypots. HTTP traffic is in blue; “IEC 104 traffic” in orange means all traffic using IEC 104’s TCP port 2404; and “IEC 104 messages” in green means only traffic with correctly formatted IEC 104 data. Fig. 2 shows more data because it ran longer than Phase 3. Phase 1 saw HTTP on most days; Phase 3 saw continuous HTTP and IEC 104 probing. However, both phases saw gaps in traffic with valid IEC 104 messages because of its low overall frequency; most IEC 104 traffic was invalid, which most likely means basic port scanning.
Fig. 2. Requests per day for Phase 1.
Fig. 3. Requests per day for Phase 3.
5 CONCLUSIONS AND FUTURE WORK
We saw similar HTTP traffic in the cloud environment of Phases 3-5 than in the physical environment of Phases 1-2, but less IEC 104 traffic in all phases. This could be due to the rarity of industrial control systems in the cloud and disinterest by adversaries in attacking them due to lack of familiarity with them, but this could change as ICS systems become more common.
We added more obfuscations to Phases 4 and 5 to make the GridPot less obvious. Traffic decreased, but it may have only been due to the decreased novelty of the configuration, since a less obvious honeypot should be more desirable to attack. Phase 5 showed significantly more traffic in an Asia-based deployment rather than a US-based deployment, which again may have been due to a novelty effect. However, much data appeared to be due to an previous DNS poisoning attack on the service which may have increased the traffic. This can be an issue when using a cloud service that recycles Internet addresses.
Phases 4 and 5 are still collecting data, and Phase 2 has been resumed on a Linux machine using a Windows Applications Programming translator to avoid the vulnerabilities of the Microsoft environment. We anticipate having more data to see if the trends continue.
Currently we are exploring T-Pot, a multi-honeypot platform, to see if providing better responses to HTTP requests and responses to additional protocols will increase effectiveness of a honeypot. We also identified a section of code in the GridPot implementation that could be modified to make it especially less obvious. Having more detailed simulation capabilities for industrial control systems increased cyberattacker interest and the amount of activity on our honeypots, so those simulation features should be enhanced. As for data analysis, our data find new cyberattacks although that was not our focus so far. Finally, since we observed regional differences, more honeypots could be set up all over the world using cloud services. Being able to compare attacks across many sites should make it easier to see past the randomization of many attacks.
References
1. Stouffer, K., Pillitteri, V., Lightman, S., Abrams, M., Hahn, A.: Guide to industrial control systems (ICS) security. National Institute of Standards and Technology, Gaithersburg, MD, US, NIST SP 800-82 Revision 2 (2015).
2. Hawk, C., Kaushiva, A.: Cybersecurity and the smarter grid. The Electricity Journal 27 (8), 84–95 (2014).
3. Blume, S.: System overview, terminology, and basic concepts. In: Electrical Power System Basics for the Nonelectrical Professional, pp. 1–12. John Wiley, Hoboken NJ (2007).
4. Greenberg, A: Crash Override: The malware that took down a power grid. Wired, 06/12/2017.
5. Atadika, M., Burke, K., Rowe, N.: Critical risk management practices to mitigate cloud migration misconfigurations. Proc. Intl. Conf. on Computational Science and Computational Intelligence, Las Vegas, NV, United States (2019).
6. Rowe, N., Nguyen, T., Kendrick, M., Rucker, Z., Hyun, D., Brown, J.: Creating effective industrial-control-systems honeypots. Proc. Hawaii Intl. Conf. on Systems Sciences, Wailea, HI, United States (2020).
7. Redwood, W.: Cyber physical system vulnerability research. PhD Dissertation, Florida State University (2016).
8. C. Dalamagkas, P. Sarigiannidis, D. Ioannidis, E. Iturbe, O. Nikolis, F. Ramos, E. Rios, A. Sarigiannidis, and D. Tzovaras: A survey on honeypots, honeynets and their applications on the smart grid. Proc. of the 2019 IEEE Conference on Network Softwarization, Paris, France (2019).
9. Serbanescu, A., Obermeier, S., Yu, D.-Y. (2015). ICS Threat Analysis Using a Large-Scale Honeynet. Proc. 3rd Intl. Symposium for ICS and SCADA Cyber Security research, pp. 20-30 (2015).
10. Barak, I.: Cybereason’s newest honeypot shows how multistage ransomware attacks should have critical infrastructure providers on high alert. Journal of Cyber Policy (2020)
11. Quantalytics, Q GridPot, www.quantalytics.com/q-GridPot/, accessed January 18, 2019.
12. Litchfield, S.: Honeyphy: a physics-aware CPS honeypot framework. Master’s thesis, Georgia Institute of Technology, Atlanta, GA, US (2017).
13. Buza, D., Juhász, F., Miru, G., Félegyházi, M., Holczer T.: CryPLH: Protecting smart energy systems from targeted attacks with a PLC honeypot. Proc. Intl. Workshop on Smart Grid Security, pp. 181–192 (2014).
14. Antonioli, D., Agrawal, A., Tippenhauer, N.: Towards high-interaction virtual ICS honeypots-in-a-box. Proc. 2nd ACM Workshop on Cyber-Physical Systems Security and Privacy, pp. 13–22 (2016).
15. Rowe, N, Rrushi, J.: Introduction to cyberdeception. Springer (2016).
16. Rowe, N.: Honeypot deception tactics. In: Al-Shaer, E., Wei, J., Hamlen, K., & Wang, C. (Eds.), Autonomous cyber deception: Reasoning, adaptive planning, and evaluation of Honey Things, Springer, pp. 35-45 (2019).
17. GridLAB-D Project: GridLAB-D Github page, https://github.com/gridlab-d/gridlab-d, accessed: 09-Aug-2020.
18. Dougherty, J.: Evasion of honeypot detection mechanisms through improved interactivity of ICS-based systems. Master’s thesis, U.S. Naval Postgraduate School (2020).
19. Bieker, M., Pilkington, D.: Deploying an ICS honeypot in a cloud computing environment and comparatively analyzing results against physical network deployment. Master’s thesis, U.S. Naval Postgraduate School (2020).
20. Paganini, A.: IndigoSCADA User Manual, rev. 334, http://www.enscada.com/a7khg9/IndigoSCADA_user_manual.pdf, accessed: 13-Aug-2019.
21. Boddy, M., Jones, B., Stockley, M.: RDP exposed - the threat that’s already at your door. Sophos, Inc, Sophos White Paper (2019).