FrostyGoop. A calmer look at the Lviv incident.
A technical comparative analysis of the January 2024 Lviv heating disruption: what the Dragos report claims, how the SCADASEC response pushes back, and why the evidence deserves a closer read.
Last updated:
FrostyGoop is ICS malware that speaks Modbus TCP and was tied to the January 2024 heating disruption in Lviv, Ukraine. Dragos calls it a sophisticated, state-linked attack; SCADASEC, citing Ukrainian sources, reads the same evidence as a smaller, contested event. The numbers below are attributed to each source, not asserted by Trout. Whatever its true sophistication, the exposure it targeted is the durable lesson: externally reachable devices, a flat network, and a control protocol with no authentication. The fix is architectural.
One incident, two different stories.
This report compares the Dragos analysis of the FrostyGoop malware with the SCADASEC response. Dragos characterises FrostyGoop as a sophisticated, Russian-linked ICS attack behind the Lviv heating disruption. SCADASEC presents a different account of the malware's attribution and sophistication, and argues that more evidence is needed to substantiate those claims.
Our independent read is that FrostyGoop lacks the advanced characteristics typically seen in state-sponsored ICS malware, and may not have been involved in the alleged attack as described. It may have disruptive capability, but it does not match the sophistication of families like Triton or Industroyer, so its threat level should be reassessed rather than accepted at face value.
Rare, and reportedly the ninth of its kind.
ICS-specific malware is rare. Per Dragos, FrostyGoop joins a short list of families built to reach industrial control systems. It communicates over Modbus TCP, is written in Golang, and is compiled for Windows, which fits the environments where those protocols and platforms are common.
- 01Stuxnet
- 02Havex
- 03BlackEnergy2
- 04CrashOverride (Industroyer)
- 05Trisis (Triton)
- 06Industroyer2
- 07PipeDream
- 08Fuxnet
- 09FrostyGoop
Where the accounts diverge.
- Russian-linked malware cut heating to 600+ apartment buildings for two days in sub-zero temperatures.
- Initial access via externally facing routers; attackers downgraded ENCO controller firmware to a version without monitoring.
- FrostyGoop is a sophisticated, state-linked ICS threat using Modbus TCP.
- Only 324 individual heating units affected; supply restored to 50 percent in six hours, 100 percent in thirteen.
- ENCO devices mainly read heat-meter data; no clear evidence they controlled physical processes.
- The only ENCO link is a hard-coded IP pointing to Romania, not Lviv, and Shodan showed no exposed ENCO devices there.
Lviv's mayor described the event as a malfunction with a suspicion of external interference under investigation, which captures the contested nature of the incident.
The Lviv chain, mapped.
This maps the chain as Dragos reported it, to MITRE ATT&CK for ICS techniques. It is a reading of public reporting, not an assertion by Trout that every step is settled fact. Where SCADASEC disputes a step, the row says so.
| Technique | ATT&CK stage | What it means here |
|---|---|---|
| T0822 / T0883External Remote Services / Internet Accessible Device | Initial access | Per Dragos, access came through an externally facing router reachable from the internet, not through the ENCO devices directly. SCADASEC disputes how much the ENCO devices were involved at all. |
| T0855Unauthorized Command Message | Impair process control | FrostyGoop issues valid Modbus TCP commands over port 502 (read and write to holding registers). To a controller these are indistinguishable from a legitimate engineering workstation, which is the whole point: no exploit, just access. |
| T0836Modify Parameter | Impair process control | Register writes that change a valve position or a temperature setpoint move the physical process without any software vulnerability being touched. |
| T0857System Firmware | Inhibit response function | Dragos reports the ENCO controller firmware was downgraded to a version that stripped monitoring. SCADASEC questions the control role of the ENCO devices. Attributed as reported. |
| T0815 / T0829Denial of View / Loss of View | Impair process control / Impact | With monitoring removed, operators lose visibility on the affected units. The building is being manipulated while the HMI shows nothing wrong. |
What the operator would have seen
On the wire, the tell is ordinary-looking Modbus TCP on port 502: write commands (function code 6, write single register, and 16, write multiple registers) landing on the holding registers that hold valve position and temperature setpoints, from a source that should only ever read. On the console, the tell is worse, because there is none: per Dragos, the controller firmware was rolled back to a build without monitoring, so the HMIs for the affected ENCO units go dark while the process keeps moving. Heat is being taken off the buildings and the screen still looks normal.
The network is the fix, whatever the attribution.
Argue about FrostyGoop's sophistication all you like. The Lviv incident points at the same familiar weak spots: externally reachable devices, flat networks, and control protocols like Modbus with no authentication. Those are architectural problems, and they have an architectural answer.
Segment the network, put identity on every path to a controller, and log it, so a command cannot be issued or a device reached unless policy explicitly allows it. Concretely, on a district heating floor: put each ENCO controller or heat-meter RTU behind its own enclave, so the only way to reach it is an identity-bound session through Access Gate. The controls vendor gets a read path to the heat-meter registers and nothing else; a setpoint or firmware write requires a named engineer and is logged. During a genuine sub-zero emergency the operator still has an authenticated, logged break-glass path to the controller, so safety never waits on policy.
If the path does not exist, the attack does not either. Go deeper on the enforcement model in what is an industrial proxy and PLC security, and on the protocol specifics in securing Modbus.
Download the comparative analysis.
The full FrostyGoop report: the Dragos and SCADASEC narratives side by side, the technical detail on the Lviv incident, and what it means for how you secure industrial networks.
A new approach to industrial network security
Access Gate is Trout's agent-free zero-trust overlay for OT. It segments control systems, enforces identity on every path, and logs it, without inline appliances, agents, or re-IPing.
About this report
An independent comparative analysis by Trout, published in 2024. It weighs public reporting from Dragos and SCADASEC on the FrostyGoop malware and the Lviv heating incident. Findings reflect Trout's reading of the available evidence.
FrostyGoop FAQ
Known ICS-specific malware family, per Dragos
Mapping the chain as Dragos reported it: initial access via an internet-reachable device (T0822 External Remote Services, T0883 Internet Accessible Device); unauthorized Modbus commands over port 502 to change the process (T0855 Unauthorized Command Message, T0836 Modify Parameter); a firmware downgrade that stripped monitoring (T0857 System Firmware); and the resulting loss of operator visibility (T0815 Denial of View, T0829 Loss of View). SCADASEC disputes the ENCO devices' control role, so treat the chain as a reading of public reporting rather than settled fact.
FrostyGoop is a rare piece of malware reported to target industrial control systems. Per Dragos it is the ninth known ICS-specific malware family, alongside Stuxnet, Havex, Industroyer, Triton, and others. It communicates over Modbus TCP, is written in Golang, and is compiled for Windows, which suits the environments where those protocols and platforms are common.
In January 2024, Dragos reported that Russian-linked malware was used to cut heating to more than 600 apartment buildings in Lviv, Ukraine, for about two days in sub-zero temperatures. SCADASEC, citing official Ukrainian sources, put the impact much lower: 324 individual heating units affected, with supply restored to 50 percent in six hours and 100 percent in thirteen, not the 48 hours reported. Lviv's mayor described it as a malfunction with a suspicion of external interference under investigation.
They diverge on attribution, sophistication, and impact. Dragos characterises FrostyGoop as a sophisticated, state-linked ICS attack. SCADASEC questions the role of the ENCO devices (noting the only link is a hard-coded IP pointing to a device in Romania, not Lviv, and that Shodan showed no exposed ENCO devices there), the Modbus control claim, and the scale and duration of the disruption. The two narratives rest on different evidence and read the same incident very differently.
Our independent analysis is that FrostyGoop lacks the advanced characteristics typically seen in state-sponsored ICS malware, and may not have been involved in the alleged attack as described. It may have some disruptive capability, but it does not match the sophistication of malware like Triton or Industroyer, so its overall threat level should be reassessed rather than taken at face value. This is a call for careful evidence, not a dismissal of the risk.
Whatever FrostyGoop's true sophistication, the Lviv incident points at the same weak spots: externally reachable devices, flat networks, and control protocols like Modbus with no authentication. The durable fix is architectural. Segment the network, put identity on every path to a controller, and log it, so a command cannot be issued or a device reached unless policy explicitly allows it.