What FrostyGoop Is
FrostyGoop, designated BUSTLEBERM by Dragos, is an ICS-specific malware discovered in April 2024 and publicly reported in July 2024 by Dragos and ESET. It is written in Go and targets ENCO controllers — industrial control devices used in district heating systems — by communicating directly over Modbus TCP on port 502. FrostyGoop is only the ninth publicly disclosed malware family designed to interact directly with industrial control system protocols. Its significance lies not in technical sophistication but in operational effect: in January 2024 it was used to disrupt district heating for approximately 600 apartment buildings in Lviv, Ukraine during winter, leaving residents without heat for 48 hours.
What makes FrostyGoop analytically important for ICS security practitioners is the attack methodology it represents. Previous ICS-specific malware (STUXNET, Industroyer/Crashoverride, TRITON/TRISIS, INCONTROLLER/PIPEDREAM) required deep knowledge of specific proprietary protocols. FrostyGoop uses Modbus TCP — a 1979-vintage open protocol with no authentication, no encryption, and virtually universal implementation across industrial devices. The attack surface it exploits is the protocol itself, not any single vendor’s vulnerability.
The Attack: January 2024 Lviv District Heating Incident
Dragos’s July 2024 report, produced in coordination with Ukraine’s CERT-UA, reconstructed the attack chain:
Initial access (April 2023, approximately nine months before impact): Attackers gained initial access to the Lviv district heating utility’s IT network. CERT-UA attributed the access to exploitation of an internet-facing Mikrotik router running a vulnerable firmware version. This is consistent with documented Sandworm tradecraft and with the group’s pattern of long-duration pre-positioning in Ukrainian critical infrastructure.
Lateral movement and OT access: Over the following months, the attackers moved from the IT network into the operational technology network. The OT network contained ENCO controllers managing the district heating system’s temperature regulation. These controllers communicate via Modbus TCP and were accessible from the compromised IT network — a classic Purdue model convergence failure where IT and OT network segments were not properly isolated.
Deployment and execution (January 22–24, 2024): FrostyGoop was deployed and executed during the coldest week of the 2023-2024 winter. The malware sent Modbus TCP write commands to the ENCO controllers, instructing them to report incorrect temperatures to the supervisory control system. The district energy management system, reading falsified sensor data, reduced heating output. Approximately 600 buildings lost heat for 48 hours at outdoor temperatures approaching -10°C.
The impact was deliberately disruptive rather than destructive. The controllers were not physically damaged and normal operation was restored. This is operationally significant: the attack achieved psychological and infrastructural impact (residents without heat, emergency response activation, media attention) without destroying the hardware that would require physical replacement.
Technical Analysis of FrostyGoop
FrostyGoop is a compiled Go binary. Its core functionality is straightforward and reflects the simplicity that Modbus TCP’s lack of authentication enables:
Configuration file parsing: The malware reads a JSON configuration file specifying target IP addresses, Modbus TCP port (502), function codes, register addresses, and values to write. This configuration-driven approach means the operators can retarget the tool against any Modbus-speaking device by changing the configuration file — no recompilation required.
Modbus TCP communication: FrostyGoop implements Modbus TCP function codes for reading and writing holding registers. The specific function codes used in the Lviv attack targeted register addresses controlling temperature setpoints and reporting values in ENCO controller firmware.
No C2 communication required for execution: Once deployed with a configuration file, FrostyGoop executes autonomously. The absence of C2 communication during execution makes it invisible to network monitoring tools looking for external communication patterns during the active attack phase.
No persistence mechanism: FrostyGoop does not install persistence. It runs as a one-shot process. This is consistent with an attack designed for a specific operational objective — once the malware is executed, the attack effect is achieved without the risk of persistent implant detection.
Why Modbus TCP Makes This Attack Class Scalable
The most significant aspect of FrostyGoop for industrial security practitioners is not the specific incident but the attack methodology’s broad applicability. Modbus TCP is the most widely deployed industrial protocol in the world. It is implemented by virtually every major ICS vendor across energy, water, manufacturing, building automation, and transport sectors. It has no authentication. It has no encryption. Any device reachable over TCP port 502 accepts commands from any host that can connect.
The attack surface FrostyGoop exploits is not a specific vulnerability in a specific vendor’s product. It is the base protocol specification. An attacker with Modbus TCP access to your OT network can issue arbitrary read and write commands to any Modbus-speaking device. FrostyGoop demonstrates that a 300-line Go program with a JSON configuration file is sufficient to operationalise this access.
This means the Modbus TCP attack surface is not narrowed by patching. There is no patch for Modbus TCP’s lack of authentication — it’s a design characteristic of the 1979 specification. The only controls are network segmentation, access control at the network level, and monitoring for anomalous Modbus traffic.
Detection Opportunities
Dragos’s BUSTLEBERM detection guidance emphasises network-level monitoring as the primary detection path:
Modbus TCP anomaly detection: Baseline normal Modbus communication patterns in your environment. FrostyGoop’s execution sends write commands (Function Code 16: Write Multiple Registers) to ENCO controllers from a host that does not normally issue such commands. Any Modbus write command from a previously read-only host, or a write command to register addresses outside the normal operational range, is a high-fidelity detection signal.
IDS signatures for Modbus Function Code 16 from IT segments: In environments where Modbus traffic should only flow between known engineering workstations and field devices, any Modbus TCP session originating from an IT-segment IP address is anomalous and should trigger an alert.
ENCO controller integrity monitoring: If ENCO controllers are in your environment, monitor reported temperature values against expected operational ranges. Significant deviations from expected values during a period of unchanged process conditions may indicate sensor reporting manipulation.
Mikrotik router firmware: The initial access vector in the Lviv incident was a Mikrotik router with unpatched firmware. Mikrotik has been a consistent initial access target in Sandworm and affiliated campaigns. Audit your OT network perimeter for Mikrotik devices and confirm they are running current firmware.
Hardening Recommendations
Network segmentation between IT and OT is non-negotiable. FrostyGoop’s successful execution required that the attacker could reach OT devices (ENCO controllers on Modbus TCP/502) from the compromised IT network. A properly enforced Purdue model boundary, or zero-trust OT network architecture, would have blocked the lateral movement path.
Deploy Modbus-aware OT monitoring. Passive OT monitoring platforms (Dragos Platform, Claroty, Nozomi Networks) parse Modbus TCP traffic and can alert on anomalous function codes, register writes from unexpected sources, and traffic volumes inconsistent with normal operations. This is the primary compensating control for a protocol that cannot authenticate.
Remove Modbus TCP devices from internet exposure. Internet-facing industrial devices are the first step in many OT attack chains. Any ENCO controller, PLC, or HMI accessible from the internet should be treated as already compromised and moved behind segmented networks with jump server access only.
Review OT network segmentation against real traffic. Many organisations have Purdue model diagrams that do not reflect actual network flows. Passive OT network monitoring typically reveals IT-to-OT traffic paths that were not known to exist. Review actual traffic patterns before assuming your segmentation controls work as designed.
FrostyGoop is not the last ICS malware to use Modbus TCP. Its discovery and the Lviv incident demonstrate that OT-native attack capability has reached a level where a single developer with protocol knowledge and network access can disrupt critical infrastructure. The response is not primarily technical — it’s about network architecture and visibility.