Running a fake power plant on the internet for a month

People think of the internet as a host for services like banking websites, blogs and social networks. However, this is only a small part of everything connected. The internet is home to a big range of IoT systems and machines as well. These vary from simple “smart” light switches, to machinery used in industrial plants.

One of the concerns stated in the yearly publication by the Dutch government called “Cybersecuritybeeld Nederland” (2019) was the lack of insight into malicious digital (state sponsored) activity towards vital infrastructure. We (the Dutch) don’t know who is trying to hack our dams, locks, dikes and bridges.

One of the systems often used to get more information about digital attackers are called honeypots. These mechanisms detect attempts at unauthorised use of computer systems. You could think of these as a digital version of bait cars used by the police to catch thieves. For this particular project I wrote a small HoneyTrap listener (an open-source project by DTACT) that can interact with systems scanning for devices on the s7comm protocol.

About the simulator

The simulation I created is very basic and is not considered “high-interaction”. After little interaction a skilled hacker would know that the system is actually a fake. However, this is not a concern of mine, as my sole purpose is to figure out who is responsible for the initial contact. Despite its simplicity, it was still able to deceive simple exploitation scripts in faking a system disruption.

How it works

(old) test setup with two Siemens S7 1200 PLCs
Setting up communications to the PLC

First, a TCP connection is set up using the 3-way handshake. After that a COTP connection request (CR) is sent to the machine. If accepted, the PLC will return a COTP Connection Confirmed response. The client system will now send a S7Comm job request to setup a connection on the Siemens s7 protocol called s7comm.

Now that everything is in place, the client can start retrieving information about the PLC by doing multiple requests.

Retrieving SLZ information using Nmap

The image above shows the interaction that the honeypot needs to setup to be fingerprinted as a Siemens PLC. It needs to react to 3 Read SZL requests. These have SZL ID 0x11 and 0x1c (module ID and component ID requests).

Next to implementing SZL it’s also interesting to fake exploit execution to deceive a malicious actor in thinking they can damage the system.

One method used to disable the machines is using a CPU stop command. This is also part of the S7Comm protocol and will disable the unit. After implementing the right response, my honeypot would fake being disabled.

And voilà, ICSSploit shows the exploit ran successfully.

For al the Nmap users: result of a network scan on the honeypot crafted to simulate industrial PLCs below.

PORT    STATE SERVICE
102/tcp open iso-tsap
| s7-info:
| Module: 6ES7 518-4AP00-0AB0
| Basic Hardware: 6ES7 518-4AP00-0AB0
| Version: 2.6.0
| System Name: INTERN_VALVE_REG_O1
| Serial Number: S C-N5820302
| Plant Identification: NUCL_POWER_GEN_05
|_ Copyright: Original Siemens Equipment
Service Info: Device: specialized
Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds

Probe example

{
“category”: “s7comm”,
“date”: “2020–12–08T21:23:32.541508039+01:00”,
“destination-ip”: “x.x.x.x”,
“destination-port”: 102,
“payload-hex”: “0300002102f080320700000000000800080001120411440100ff09000400110001,
“payload-length”: 33,
“request.ID”: “17”,
“request.type”: “module ID request”,
“sensor”: “services”,
“source-ip”: “x.x.x.x”,
“source-port”: 53662,
“token”: “bssglu3k2l04oeabnus0”,
“type”: “ics”
}

Getting indexed by internet scanners

First system to connect was an internet scanner in Romania. The machine resolved to turtle.census.shodan.io which meant the Shodan.io scanners started to index the valve regulator from the fake nuclear reactor! This resulted in the following record on their site:

It also seemed to fool the Honeypot detector created by Shodan when the honeypot ran at lesser known hosting providers.

Censys also had no problem indexing the HoneyPot as a real industrial machine.

About the data…

Top 10 hosts connecting to the honeypot

When looking at the data a bit more in-depth, it becomes apparent that most requests received by the honeypot are not recognised. This can have two reasons. First, this specific honeypot implementation is a rather specific. It’s best used as a decoy in an internal network. This is because of its low interaction and the fact that S7commPlus is not implemented yet. And secondly, not all traffic sent to the honeypot was traffic destined for the device itself. Someone even tried sending RDP packets to the machine.

Total amount of requests received by category

(Un)fortunately no-one tried to actively harm the PLC by trying to send CPU stop commands like (https://www.exploit-db.com/exploits/19833) to the machine.

When filtering out all regular big internet scanners I was left with a list of small scanners and people genuinely interested in the simulator.

The first domain that stands out is security.criminalip.com, this is a somewhat smaller global internet scanning project, so not targeting the honeypot in particular.

The top results is coming from telenet.be, which is an internet provider for consumers in Belgium. This is interesting as it’s targeted traffic. When looking at the requests it becomes clear that this system tried to connect to our honeypot, using the s7commPlus protocol.

Next is traffic coming from a system at a Swedish hosting company. It’s a system from F-Secure for global indexing.

The fourth system is from ovo.cs. It claims to be a global collective of service providers and provided services and that its members share knowledge, resources, and support with the aim of building sustainable, independent online businesses.

Lastly, we have a system pointing to cron.optisan.com.tw, which is a weird one. The domain didn’t resolve, but optisan.com.tw gets redirected to www.optisanoptics.eu a store that sells weaponry. It seems they’ve sent multiple GET requests to the honeypot on port 102/tcp which is not part of the s7comm protocol. Interesting, to say the least.

Conclusion

Questions & Answers

Q: Tools used? A: Wireshark, Nmap, Zgrab2, ICSSploit, MetaSploit.

Q: Aware of the Purdue model for ICS security? A: Yes, but setting up level 3, 4 and 5 would’ve made this small project way too big.

Q: Did you run just one? A: Yes, for this project at least. This simulator has also been part of bigger global deployment at as part of a project at DTACT

Q: Difficult to create the simulator? A: Implementing? No, HoneyTrap is very well suited for such projects. Protocol research? Quite. The protocol knows multiple iterations and implementations…

ISO — OSI classification

Q: Why not use Conpot? A: I wanted a simulation with a bit more interaction, a bit of s7commPlus support and have the ability to fake system exploits. Also, Conpot has become easily detectable as it uses some static values in its component ID response.

Follow me on Twitter for more!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store