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
I decided to simulate a programmable logic controller, or PLC for short. In particular, a PLC that acts like a value regulator in a nuclear installation. PLCs interface with actuators and sensors to open valves, run motors and start pumps. They can be found everywhere from the rollercoasters in your local theme park to control boards for huge industrial pumpjacks. PLCs both act in the digital and physical space. This could make them very interesting for malicious actors, as a faulty system could potentially have catastrophic physical outcomes.
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
Siemens PLCs use SZL for showing other machines what type of PLC it is. SZL stands for SystemZustandsListe and is German for system information list. Internet scanners make use of this by making two requests. A module ID request and component ID request. The response is then decoded by the (internet) scanners and used for indexing. See results from Censys and Shodan below.
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.
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: specializedNmap done: 1 IP address (1 host up) scanned in 0.57 seconds
Probe example
This is what the Nmap probes look like from the Honeypot’s side of view.
{
“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
After initial setup I waited for the system to be indexed by scanning services such as Shodan and Censys. These are search engines for actual machines instead of webpages. Setting aside the differences, the goal is the same: to be recorded in online search engines for all of the internet to find. Preferably as an actual nuclear reactor instead of a honeypot.
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…
Most traffic received in the month of operation originated from the United States. This was expected, as most internet scanners are hosted there. Especially Censys using their ZGrab2 scanners is quite active, but ipip.net wins with an average count of two scans a day.
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.
(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
There is active scanning for industrial equipment on the internet. Not only by big companies that index the whole IPv4 space, but also by individuals and organisations interested in which machines are available. Luckily most traffic received is from researchers scanning the whole IPv4 space for systems in the vein of responsible disclosure. However, this does not exclude that there are real people looking for industrial machines on the internet as well.
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…
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.
