I first posted the following on the SANS ICS blog here
An article came out on May 5th titled “Daisy-chained research spells malware worm hell for power plants and other utilities” with the subtitle of “World’s first PLC worm spreads like cancer”. Having been on the receiving end of sensationalized headlines before I empathize with the authors of the research. Regardless of the headlines, the research, performed by Ralf Spenneberg, Maik Brüggeman, and Hendrik Schwartke, is quality work highlighting different methods of propagation and infections inside of control networks. However, before any alarmism sets in let’s look at this research and what it might mean as well as trivial methods to detect it.
The Worm
The researchers put out a great presentation and paper showing exactly what they did to create and test the worm. In short, the worm impacts Siemens SIMATIC S7-1200v3, although with some modifications the method would not be limited to Siemens or this version of PLC, and utilizes the S7 protocol to propagate without requiring the industrial PC. The authors put forth that the infection routine could be introducing an already manipulated PLC or if introduced through the PC it could then run wild without further use of the system. After a PLC is infected it starts scanning the network for TCP port 102 for the S7 protocol to identify the SIMACTIC PLCs. It scans the network through initiating and closing connections at incrementing IP addresses until it finds its targets and infects them. The researchers put the diagram below in their paper to show the process.
This research is valuable for a lot of purposes but I want to highlight two reasons I think it’s interesting. First, the worm was written in Structured Text and utilizes the PLC and S7 protocol against itself. The researchers use native commands and functionality which I believe will continually be a theme in ICS intrusions and attacks; there is a lot of value in reducing the reliance on custom code or malware when native functionality serves the purpose. The second reason is that all the communications it puts out should be easily identifiable by anyone watching their ICS network.
Detecting the Worm
The most difficult part of detecting threats in the ICS is getting access to the data. The era of dumb switches and a lackadaisical approach to logging needs to be stamped out; but the remnants of it serve a significant challenge. However, after getting access to the network data there are a lot of opportunities afforded defenders. In the case of the S7 worm it would be trivial to detect for anyone familiar with their ICS network.
In a modification of the Purdue Model for ICS architecture, shown below, we can see that good architecture would require the control network, where the S7 devices would exist, to be segmented off from the Internet and outside connections. Connections to the supervisory level should come through operations support and DMZ networks. All of these are potentially very static but the control devices level should be extremely static. I.e. your PLC shouldn’t be Tweeting anything or updating its Facebook status; it’s easier to spot changes here than it is in an enterprise business network.
The researcher’s worm requires the S7 protocol and it also requires the scanning of new IP addresses on TCP port 102. Even if the worm is modified to have very quick or very slow scan cycles they should all be easily detected. Many SIMATIC PLC environments will use PROFINET to communicate for device to device communications and rely mostly on S7 for configuration and interaction with the Totally Integrated Automation (TIA) portal. There should be a relatively predictable pattern of the PROFINET and S7 communications. It usually gives ICS networks a “heartbeat” that can be observed with the open source tool Wireshark. See below for a PROFINET network where the tool’s “IO Graph” feature (found under “Statistics” in the toolbar) has been selected. Changes to this observable heartbeat such as large spikes or dips in data should be investigated and would reveal increased scanning or command use in the environment.
Likewise, again just using Wireshark you could use the “Endpoints” feature (again found under “Statistics” in the toolbar) to identify what IP address and TCP or UDP ports are in use. This method easily identified the TCP port requests that the ICS scanner in HAVEX performed and here it would be trivial to identify connection attempts to numerous IP addresses that do not exist on the PLC network segment. Below is a picture of the same PROFINET capture from above. Your network will look different but ICS networks, especially in the control device level, are much smaller and static than traditional IT networks. Take advantage of that.
Do a Health Check
At every ICS on the planet defenders should, as a bare minimum, do health checks of the network. In networks with unmanaged infrastructure put in a tap during a maintenance period and gather packet capture. Even if you only are able to do this once a year you will at least be able to identify issues ranging from misconfigured devices to worms like the one in this research. Utilize free tools such as Wireshark to just be aware of what your ICS looks like. Learn what normal looks like and hunt for weird. You’ll be amazed at what you find.
Sustainable Success
You should make the case for managed infrastructure in your ICS and do port mirroring to gather packet captures continuously. These networks do not have a large amount of data and you can gather a lot of packet capture for a small investment in storage space. From there you can learn what the ICS should look like normally and write whitelist styled intrusion detection system rules. There are many awesome professional tools that can help the security of your ICS but for this example you do not need any “next generation” tools; simply using tools such as Snort, Bro, and FlowBAT inside of the Linux distribution SecurityOnion can return huge value for continuously monitoring your ICS.
Ideally, you will have someone (maybe you!) that can perform the tactics I teach in my ICS515 course such as network security monitoring to constantly hunt for threats in your ICS. But if you do not at least you have the data to routinely go back and see if anything is wrong in the ICS or if something goes wrong you can have the data to determine the root cause and apply the appropriate mitigations. And if you ever call in an incident response team just having this data available will significantly reduce the cost and time associated with the response effort.
One other thing the S7 worm highlights is the communications going on inside the S7 protocol. Many defenders simply do not know what is going on inside their ICS protocols. In fact, many ICS protocols are poorly implemented or understood and its an area where much more research is needed. The community must do better with understanding the ICS protocols. Today, detecting changes is trivial through simple methods like Wireshark Endpoints. But the threats are evolving and defenders need to know what commands are being sent across their ICS network. Today, do health checks. Whenever possible, implement continuous monitoring and network security monitoring methodologies. Moving forward, look to deeply understand the ICS protocols and communications.
Closing Thoughts
The S7 worm is good research that highlights what can be done in the control network. But it’s not a worm from hell nor is it some unstoppable capability. The S7 worm is trivial to detect, but few are looking. The worm does however help raise awareness and for that the researchers deserve a lot of credit. For mitigations, ICS defenders should have copies of the logic running on their control devices digitally hashed and stored off of the network. Remediation with good backups is a much less difficult process than remediation without backups.
Regardless if this specific capability is realistic to your environment or not the takeaways are the same: detecting these types of capabilities only requires a minimal amount of effort once data collection is done. There are a lot of mitigations and defenses you should be putting into place but at the very least monitor your environment. If you are not collecting data from your control level you should be, when you move to monitoring the data you collect you will be significantly contributing to the safety and reliability of the ICS.