In January 2024, a cyberattack targeted a heating plant in Lviv, Ukraine [1], leaving nearly 600 buildings without heating for 48 hours while the outdoor temperature hovered around freezing. [2] Dragos, a company specialising in cybersecurity for Industrial Control Systems (ICS) and Operational Technology (OT), thoroughly analysed this incident. [3] In April 2024, the Dragos team identified the malware responsible for this attack, naming it FrostyGoop. This malware targets industrial devices using the Modbus TCP/IP protocol. By exploiting this protocol, FrostyGoop can disrupt the regular operation of these devices, potentially leading to many issues, such as shutting them down. To better understand how FrostyGoop works, discussing the Modbus protocol first is essential.
Modbus
The Modbus protocol, developed by Modicon in 1979, is one of the industrial sector’s most widely used communication protocols. Despite being over four decades old, Modbus remains a cornerstone in industrial automation due to its simplicity and reliability. This protocol enables data exchange between various devices, such as sensors, actuators, drives and controllers.
Table 1 A few arbitrarily chosen examples of solutions offered by some of the most reputable automation vendors. The table shows that Modbus is still widely used.
| Vendor | Example Solution Supporting Modbus TCP/IP |
|---|---|
| ABB | Modbus TCP/IP fieldbus adapters for drives: Link |
| Siemens | Siemens PLC series supporting Modbus TCP/IP: Link |
| Mitsubishi Electric | Modbus TCP/IP interface module: Link |
| Schneider Electric | Modbus TCP/IP Communication Device Type Manager: Link |
| Rockwell Automation | Modbus TCP Communication with Logix Controllers: Link |
Originally, Modbus was used with serial communication protocols like RS-232 and RS-485. However, as industrial networks became more sophisticated, Modbus was extended to work over TCP/IP, the protocol suite used for most modern networks, including the Internet. Modbus TCP/IP allows devices to communicate over Ethernet networks, making integrating with existing IT infrastructure more accessible and enabling remote monitoring and control of industrial processes.
Modbus TCP/IP operates on a client-server architecture, as shown in the figure. In this setup, the server is typically a device like a sensor, meter, or actuator that holds data in specific memory locations called registers. The client, such as a PLC (Programmable Logic Controller) or SCADA (Supervisory Control and Data Acquisition) system, requests data from the server or sends commands to it.
Figure 1 Modbus TCP/IP Client/Server architecture. The Modbus TCP/IP Client can control (write selected values into registers) or monitor (read selected register values) industrial components with a Modbus TCP/IP server implemented.
One of the critical concepts in Modbus is the use of holding registers. Holding registers are 16-bit memory locations in a server device that can store various data. These registers allow the client to read or write data directly. A client can read holding registers from the server to obtain data such as sensor readings or status information. For example, if you have a temperature sensor with a Modbus server implemented, the current temperature might be stored in a specific holding register. The client can retrieve the temperature value by reading this register for monitoring or further processing. In addition to reading data, clients can also write data to holding registers. This is commonly used to control devices. For example, a client might write a value to a holding register to set a target
temperature on a thermostat or adjust the speed of a motor. This capability allows for real-time control of industrial processes based on dynamic inputs.
Due to the Modbus protocol’s age, it has a significant limitation by modern security standards – it lacks support for both authentication and authorisation. To establish communication with a Modbus TCP/IP server, a client only needs the following information:
- The server’s IP address,
- The port number (typically port 502, which is rarely changed in practice),
- The Device Identifier (a value ranging from 0 to 247).
As a straightforward protocol, Modbus allows only the reading and overwriting of numerical values in specific registers. These variables are not inherently described within the protocol itself. Manufacturers that produce devices with an integrated Modbus TCP/IP server typically provide a register map in their documentation, detailing which parameters correspond to each address.
The example below illustrates a connection to a Modbus TCP/IP server hosted on a local machine with the IP address 127.0.0.1 and a Device Identifier of 1. In this scenario, 20 registers are being read, starting from the first register at address 0. The first six registers (addresses 0-5) return the current date and time. However, determining the meaning of the subsequent values would require consulting the device’s documentation.
Figure 2 An example of the Modbus TCP/IP client software. The values of the holding registers are visible. The tool allows you to overwrite the register values by selecting the given field and editing the number. The software is free and can be downloaded from https://en.radzio.dxp.pl/modbus-master-simulator/.
FrostyGoop
Having already covered the theoretical fundamentals of the Modbus protocol, it’s easier to understand the concept behind the FrostyGoop malware, which explicitly targets devices using this protocol.
FrostyGoop is a malicious program designed to run on Windows systems. It is written in Golang programming language and utilises publicly available Modbus libraries on GitHub. [4] This malware can read from and overwrite holding registers on a Modbus TCP/IP server. Its configuration can be set through optional command-line arguments or by specifying a configuration file in JSON format. For the malware to operate, the IP address of the Modbus TCP/IP server, the mode of operation (either reading or writing registers mode) and the target register addresses are required. Therefore, as discussed earlier, FrostyGoop can be seen as a Modbus TCP/IP client that performs malicious actions by injecting incorrect data into device registers. Since these data often represent control parameters for industrial devices, the malware could significantly impact the operation of technological processes.
The illustration below shows an example of network traffic generated by FrostyGoop, as observed in Wireshark.
Figure 3 Example traffic generated by FrostyGoop seems legitimate traffic generated by other Modbus TCP/IP Clients. We can see the packets related to reading data from the server (Read Holding Registers) and writing data to the device (Write Single/Multiple Registers). [3]
According to the analysis conducted by the Dragos team, the malware was detected in the victim’s network, which consisted of a router, servers, and heat system controllers (the hackers likely gained access to this network through a vulnerability in the router). The malicious Modbus requests were sent directly to the heating system controllers from the
hackers’ computers via hardcoded network routes. The target of the attack was ENCO-branded heating system controllers. Interestingly, the attackers also remotely downgraded these devices, causing the measurement readings to become inaccurate and losing visibility for the heating plant’s operators. The associated FrostyGoop configuration file (task_test.json) contained an IP address belonging to an ENCO control device exposed on the Internet was found. This led Dragos to assess with medium confidence that before this attack, FrostyGoop was also used to target one or more ENCO controllers where TCP port 502 was Internet accessible. [3] Thus, this malware was most likely responsible for the lack of heat in more than 600 buildings in January 2024 in Lviv.
How dangerous is the FrostyGoop?
Devices with Modbus TCP/IP exposed to the public internet are directly vulnerable to FrostyGoop-like malware. Since the Modbus TCP/IP protocol does not support authentication, it is possible to connect to accessible hosts and attempt to alter register values, which can directly impact the operation of physical industrial devices.
The illustration below shows an estimated number of devices with port 502 opened online. The Dragos group estimates that of these 640,000 assets, approximately 46,000 devices may be vulnerable.
Figure 4 Results of searching publicly available devices with port 502 opened on the Shodan platform.
Devices located within local industrial networks are in the second tier of risk. If an attacker gains access to the internal network, malicious actions against these devices could become possible. If an attacker aims to disrupt the proper functioning of industrial
facilities, devices communicating via the Modbus protocol could be among their primary targets.
Recommendations
This section will be valuable for those working with devices with a Modbus TCP/IP server implemented and looking to mitigate the associated risks. The discussion above leads to one crucial takeaway:
This is the most fundamental and critical rule for enhancing the security of Industrial Control Systems (ICS) and Operational Technology (OT) environments that use the Modbus protocol. To further strengthen the security of these systems, we might consider implementing additional measures listed in the following table.
Table 2 Proposed measures to mitigate risks associated with ICS devices communicating via Modbus TCP/IP protocol. However, it is worth noting that these measures can effectively counter a much more comprehensive range of threats. The measures are linked to the mitigations described in the MITRE ATT&CK ICS framework in the last column.
| Measure | Description | MITRE ATT&CK ICS Mitigations Reference |
|---|---|---|
| Network Segmentation | Implement network segmentation to isolate your Modbus TCP/IP devices from other parts of your network, particularly from the public internet and other untrusted networks. By creating distinct network zones, you limit the potential spread of an attack, making it harder for intruders to access sensitive systems. | M0930: Network Segmentation |
| Use of Alternative Industrial Protocols | Where possible, encrypt network traffic to protect the data transmitted between clients and servers. While Modbus itself does not support encryption, you can tunnel Modbus traffic through a VPN (Virtual Private Network). | M0802: Communication Authenticity |
| Continuous Network Monitoring | Deploy strict access controls to limit who can communicate with Modbus devices. Use firewalls to restrict Modbus TCP/IP server access to only trusted IP addresses. | M0931: Network Intrusion Prevention |
| Access Controls and Firewalls | Monitor your industrial network regularly for unusual or unauthorised activity. Implementing an Intrusion Detection System (IDS) or an Intrusion Prevention System (IPS) specifically tailored for industrial networks can help identify potential threats in real-time, allowing you to respond promptly. | M0807: Network Allowlists |
| Encryption of Network Traffic | Where possible, encrypt network traffic to protect the data transmitted between clients and servers. While Modbus does not support encryption, you can tunnel Modbus traffic through a VPN (Virtual Private Network). | M0808: Encrypt Network Traffic |
| Security Audits | Conduct regular security audits and vulnerability assessments of your ICS and OT environments. These assessments can help identify weaknesses in your current setup and provide insights into areas that require improvement. | M0947: Audit |
By following the above practices, we can significantly reduce the risk of cyber threats to our Modbus TCP/IP devices and improve the overall security of the industrial network.
A Deeper Dive into Modbus Hacking
A small simulation has been prepared and presented in this section to understand further the risks associated with the Modbus protocol. Three short Python programs were written using the pyModbusTCP library as part of the simulation. [5]
The first program simulates a heating system controller operating as a Modbus TCP/IP server.
The next program is an example of a Modbus TCP/IP client. Upon running this program, a window will appear similar to the one shown in the figure below. This window simulates the visualisation interface typically used by operators responsible for monitoring and controlling the heating system. The program retrieves data from the previously launched server. In the interface, the following parameters:
- Overall System status – [OK].
- Date – current date.
- Temperature – Outside – the temperature outside the building where the heating system is installed.
- Temperature – Inside – the temperature inside the building where the heating system is installed.
- Temperature – Setpoint – the setpoint temperature in the building.
- Temperature – Hysteresis – the value of deviation by which the temperature should fall relative to the setpoint temperature to start the heating again.
Figure 5 Simple SCADA-like window for monitoring the Heating System.
The internal building temperature continuously changes during the simulation. The heating system turns off when it exceeds the setpoint temperature (Heater Status: Off). The temperature then begins to decrease. When the temperature drops below the setpoint minus the hysteresis, the heating system turns on (Heater Status: On), and the temperature rises. The system operates correctly, maintaining the temperature close to the setpoint temperature.
The third program simulates a client attempting to perform a malicious action against the heating system. Run it with the following command:
This program performs a simple attack—it connects to the Modbus TCP/IP server and starts writing zeros to the holding registers every second. This action resets the setpoint temperature and hysteresis to zero. Since the setpoint temperature is zero, the heating system never activates, causing the temperature to drop. Eventually, the warning status appears on the visualization—[COLD!].
Figure 6 A simulation of the simple disruptive attack against the heating system with Modbus TCP/IP server. He is writing zeros to the holding registers.
In this scenario, we executed a basic attack simulation against the Modbus TCP/IP server, disrupting the heating system’s operation and forcing it into a continuous shutdown.
Acknowledgements
I enjoyed participating in the webinar Cold Reality: The Impact of FrostyGoop Modbus Malware on Connected OT Systems on 6 August 2024, prepared by the Dragos team. I want to thank them for making their analysis publicly available.
Bibliography
[1] Н. Карнаух, “Частина Львова залишилась без опалення та гарячої води: слідчі перевіряють версію про хакерську атаку,” January 2024. [Online]. Available: https://suspilne.media/lviv/667490-castina-lvova-zalisilas- bez-opalenna-ta-garacoi-vodi-slidci-pereviraut-versiu-pro-hakersku-ataku/.
[2] A. Greenberg, “How Russia-Linked Malware Cut Heat to 600 Ukrainian Buildings in Deep Winter,” WIRED, July 2024. [Online]. Available: https://www.wired.com/story/russia-ukraine-frostygoop-malware-heating-utility/.
[3] Dragos, “Impact of FrostyGoop ICS Malware on Connected OT Systems,” July 2024. [Online]. Available: https://hub.dragos.com/hubfs/Reports/Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf?hsLang=en.
[4] [Online]. Available: https://github.com/rolfl/modbus.
[5] [Online]. Available: https://pymodbustcp.readthedocs.io/en/latest/quickstart/index.html.