Conventional Modbus and Modbus TCP do not define protocol-layer authentication or encryption. Modbus dates to 1979, and Modbus TCP commonly uses Transmission Control Protocol (TCP) port 502. (see our Modbus glossary entry for the full background). A separate Modbus Security specification now combines the protocol with Transport Layer Security (TLS), X.509v3 client and server authentication, and message-integrity protection on port 802 [1][2]. That distinction matters: a reachable conventional Modbus TCP server that exposes writable coils or holding registers and lacks compensating controls may process a valid write request without an application-layer login. It can still reject unsupported functions, addresses, or values, so network reachability does not mean that every write will succeed.
That design characteristic was one enabling condition in the January 2024 attack on a Ukrainian district-heating operator, but it was not the whole cause. The public account describes an operational technology (OT) attack path involving an externally facing router, persistent access, stolen credentials, inadequate segmentation, hardcoded routes, a controller firmware downgrade, and direct Modbus commands. Dragos assesses that FrostyGoop was used to facilitate the final operational steps [3][4].
We've spent enough years around industrial protocols to have a reflex about stories like this one: the interesting question is usually not the binary alone; it is the path. MITRE ATT&CK for industrial control systems (ICS) gives us a disciplined way to separate initial access, persistence, command and control, impairment of operator visibility, parameter modification, and operational impact. This article walks the public evidence end to end, identifies the techniques the evidence supports, and then answers the financial question honestly: no verified incident-loss figure has been published. Industry benchmarks can provide context, but they cannot tell us what this event cost.
MITRE catalogs the event as Campaign C0041, the FrostyGoop Incident, and the malware as Software S1165 [4][5]. The Security Service of Ukraine (SBU) told Recorded Future News that the affected operator was Lvivteploenergo. Dragos's intelligence brief, based partly on information shared by the SBU's Cyber Security Situation Center, refers more generally to a municipal district energy company. The distinction matters: the victim identity was reported publicly through the SBU, while the use of FrostyGoop remains a Dragos assessment [3][6].
Dragos reported that the facility supplied more than 600 apartment buildings and that remediation took almost two days during sub-zero temperatures. The SBU spokesperson quoted by Recorded Future News said more than 600 households. [3][6]
Investigators found that the adversaries may have entered months earlier by exploiting an undetermined vulnerability in an externally facing router. They then deployed a ReGeorg-like web shell, accessed it predominantly through Tor, retrieved the Windows Security Account Manager (SAM) registry hive, and in January established Layer Two Tunneling Protocol (L2TP) connections to Moscow-based Internet Protocol (IP) addresses [6]. MITRE maps these parts of the campaign to T1190 Exploit Public-Facing Application; T1505.003 Web Shell; T1003.002 Security Account Manager; and T1071 Application Layer Protocol [3][4].
The network path was the critical bridge. Dragos reports that the router, management servers, and district-heating controllers were not adequately segmented, and that hardcoded routes allowed adversary hosts to send Modbus commands directly to ENCO controllers. The attackers also downgraded controller firmware to a version that lacked monitoring capabilities used at the facility, producing Loss of View (T0829). MITRE maps the downgrade to T1689, Downgrade Attack, and T1693.001, Modify Firmware: System Firmware [3][4].
With visibility impaired, the adversaries caused controllers to report inaccurate measurements and the system to operate incorrectly, leading to loss of heating. Press reporting from the Dragos briefing said the altered values made the system read water as hotter than it was, so cold rather than heated water was circulated. That operational effect is consistent with Modify Parameter (T0836), followed by Loss of Availability (T0826) [4][7][8]. Dragos expressly states that the attackers did not attempt to destroy the controllers [3].
FrostyGoop itself is narrower than the entire intrusion. It is a Windows command-line binary written in Go that communicates over Modbus TCP. The analyzed samples can read holding registers and can write a single or multiple holding registers using function codes 3, 6, and 16 [3][5]. The public incident brief confirms that Modbus commands were sent, but it does not enumerate the precise function codes used against the victim. Palo Alto Unit 42 also found that the public task_test.json configuration contained read commands only, even though the binaries supported write operations [11]. That does not disprove Dragos's assessment, but it is a reason to distinguish demonstrated malware capability from the complete incident sequence.
MITRE currently maps FrostyGoop directly to T0836 Modify Parameter; T0801 Monitor Process State; T0869 Standard Application Layer Protocol; T0885 Commonly Used Port; and T0807 Command-Line Interface [5]. The unauthorized command mechanism was T1692.001 Unauthorized Message: Command Message (aka., T0855 Unauthorized Command Message) [9].
Modify Parameter deserves attention because it is an effect, not a particular exploit. MITRE's procedure examples include FrostyGoop, INCONTROLLER/PIPEDREAM, Industroyer2, the Maroochy Water Breach, and Stuxnet [8]. The common thread is that an attacker changes values or settings that a control process trusts. The technical means and consequences differ substantially: inaccurate measurements and heating loss are not equivalent to sewage release or centrifuge damage.
FrostyGoop is notable precisely because the public samples are comparatively simple. The tool uses a publicly available Go Modbus library, accepts target and register information through command-line arguments or JavaScript Object Notation (JSON) configuration, and performs normal Modbus transactions [3][11]. No Modbus protocol vulnerability was required at the command stage. The attacker still needed network reachability, knowledge of the target device and register map, and a wider intrusion path. Simplicity at the protocol layer should not be confused with simplicity of the complete operation.
There is also a legitimate evidentiary caveat. Forescout Vedere Labs noted that router exploitation and firmware downgrade were not capabilities of the public FrostyGoop sample and argued that the public evidence did not independently connect every part of the reported incident to that binary [10]. This is not a basis to dismiss the attack. It is a reason to state confidence correctly: the SBU shared incident details; Dragos assessed that FrostyGoop was used; other researchers verified the samples' Modbus capabilities; and no public source has identified a named threat actor or released a complete forensic record [3][10][11].
Exposure data reinforces the defensive concern but must also be handled carefully. Dragos estimated more than 46,000 internet-exposed ICS devices communicating over Modbus TCP in July 2024 [3]. Palo Alto Unit 42 later reported telemetry counts of 1,088,175 exposed Modbus TCP devices during 2 September to 2 October 2024 and 6,211,623 devices "exposed overall" [11]. Those figures are not directly comparable: they come from different data sets, scopes, time windows, and device-counting methods, and should not be combined into a single installed-base estimate. Separately, 33% of OT-protocol interactions observed in Forescout's 2023 adversary-engagement environment targeted Modbus [10]. The defensible conclusion is that internet-facing Modbus is measurable and routinely probed.
Here is the honest answer: we found no public, verified monetary loss for the Lvivteploenergo incident. Dragos and the SBU reporting describe the operational impact and restoration period, but neither publishes an incident-cost figure [3][6]. The outage may have generated response, repair, labor, customer-service, and potentially regulatory or public-sector costs, but assigning amounts without the operator's data would be speculation.
This is where generic industry benchmarks are often misused. IBM's 2024 Cost of a Data Breach research reported an average industrial-sector data-breach cost of $5.56 million, an 18% year-over-year increase [12]. That statistic concerns data breaches across an industrial sample. It is not a benchmark for a two-day OT service outage, and it should not be presented as an estimate of the Ukrainian event.
A Kaspersky and VDC Research survey published in May 2025 found that nearly one-quarter of more than 250 industrial decision-makers estimated that each cyberattack could cause more than $5 million in damage over a two-year period; 70% said unplanned downtime typically lasted four to 24 hours [13]. The study is useful for understanding the categories organizations consider - incident response, lost revenue, downtime, equipment or property repair, ransom, and scrap or work-in-progress - but it is vendor-commissioned, self-reported survey evidence. Lviv's roughly two-day restoration period lies beyond that most commonly reported downtime band, but the survey still cannot price this incident.
At the portfolio level, the 2025 OT Security Financial Risk Report from Dragos and Marsh McLennan modeled a severe but plausible 1-in-250-year global OT cyber scenario at $329.5 billion, including $172.4 billion of OT-related business interruption (BI) loss [14]. These are global modeled tail-risk figures built from claims, event data, and simulations. They are relevant to insurers and reinsurers assessing accumulation and systemic exposure; they are not a substitute for a site-specific loss model.
The same research found the strongest correlations between lower modeled financial risk and incident response planning (18.46% average risk reduction), defensible architecture (17.09%), and ICS network visibility and monitoring (16.47%) [14]. These percentages are not deterministic savings and should not be applied as direct discounts to an individual utility's annual expected loss. They are portfolio-level associations that support control prioritization, subject to the operator's architecture, dependencies, hazards, and implementation quality.
Translate the evidence back to the attack path. Segmentation would not have prevented exploitation of the edge router; it could have restricted the adversary's path from the router and management systems to the controllers and denied the direct Modbus route. Risk-based vulnerability management and hardening of externally facing infrastructure could have reduced the likelihood of initial compromise. Secure remote access, including multi-factor authentication (MFA) where feasible, could have reduced the usefulness of stolen credentials, although MFA does not prevent credential dumping itself [3][15].
ICS network visibility and protocol-aware monitoring could have alerted on unexpected Modbus reads or writes, new communicating hosts, and activity outside an established operational baseline. Detection of the firmware downgrade also requires asset, configuration, and firmware-change visibility; Modbus monitoring alone is not enough. An ICS-specific incident response plan, tested with operations and engineering, could have shortened decision and restoration time. These measures align with the SANS Five ICS Cybersecurity Critical Controls: ICS-specific incident response, defensible architecture, ICS network visibility and monitoring, secure remote access, and risk-based vulnerability management [15].
If you're wondering how to know where your organization actually stands on these controls before an incident forces the question, that's a maturity assessment question, and we cover exactly that in How to Assess OT Cybersecurity Maturity.
If you operate OT, the first question is not only whether a Modbus device is directly exposed to the internet. It is whether any credible path - an edge appliance, remote-access service, information technology (IT) management server, vendor connection, or misconfigured route - can reach a conventional Modbus endpoint that exposes writable process data. Internet exposure is the clearest failure mode; unintended reachability inside a flat or poorly controlled architecture creates the same command opportunity after initial access.
For underwriters and reinsurers, FrostyGoop is a useful worked example, but not a complete actuarial case study. Model the chain explicitly: external-service compromise, persistence and credential access, inadequate segmentation, controller reachability, loss of view, parameter manipulation, loss of service, response, and restoration. Record the confidence and source for each link. Do not treat the absence of physical equipment damage as absence of loss, and do not infer a loss amount from an ATT&CK technique or a cross-industry average.
ATT&CK supplies the taxonomy. Annual expected loss (AEL) requires additional evidence: event frequency, asset and process dependencies, outage duration, restoration constraints, contractual obligations, liability pathways, safety and environmental consequences, control effectiveness, and insurance terms. That translation - from an evidence-backed attack path to a quantified loss distribution - is a good part of what we work on at DeNexus.
This piece extends our Learn portal explainer on MITRE ATT&CK for ICS and the "From ATT&CK to AEL" reference guide, which map ATT&CK tactics to loss categories in the abstract, this is the worked example. For how initial access vectors trend across the industry more broadly, see our analysis of SANS's ICS/OT attack vector survey data. For the EU threat-reporting context this incident sits inside, see our ENISA Threat Landscape analysis. And for how to assess whether your own organization would have caught this attack path before it caused physical impact, see How to Assess OT Cybersecurity Maturity.
MITRE ATT&CK gives you the taxonomy of how an attack path unfolds. It can't tell you what that path would cost you. The DeRISK Platform closes that gap — translating evidence-backed OT attack paths into quantified financial risk: Annual Expected Loss (AEL), Value at Risk, and loss exceedance curves that operators can act on and risk assumers can underwrite to. Explore the DeRISK Platform →
[1] Modbus Organization. "MODBUS Application Protocol Specification V1.1b3." 26 Apr. 2012. https://www.modbus.org/file/secure/modbusprotocolspecification.pdf. Accessed 28 July 2026.
[2] Modbus Organization. "Modbus Specifications." Section "Modbus Security Protocol." https://www.modbus.org/modbus-specifications. Accessed 28 July 2026.
[3] Graham, Mark, Carolyn Ahlers, and Kyle O'Meara. "Impact of FrostyGoop ICS Malware on Connected OT Systems." Dragos, July 2024. https://hub.dragos.com/hubfs/Reports/Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf. Accessed 28 July 2026.
[4] MITRE. "FrostyGoop Incident, Campaign C0041." MITRE ATT&CK for ICS. https://attack.mitre.org/campaigns/C0041/. Accessed 28 July 2026.
[5] MITRE. "FrostyGoop, Software S1165." MITRE ATT&CK for ICS. https://attack.mitre.org/software/S1165/. Accessed 28 July 2026.
[6] Antoniuk, Daryna. "FrostyGoop Malware Left 600 Ukrainian Households Without Heat This Winter." Recorded Future News, 23 July 2024. https://therecord.media/frostygoop-malware-ukraine-heat. Accessed 28 July 2026.
[7] Lyons, Jessica. "FrostyGoop Malware Shut Off Heat to 600 Ukraine Apartment Buildings." The Register, 23 July 2024. https://www.theregister.com/special-features/2024/07/23/frostygoop-malware-used-to-shut-down-heat-in-ukraine-attack/765633. Accessed 28 July 2026.
[8] MITRE. "Modify Parameter, Technique T0836." MITRE ATT&CK for ICS. https://attack.mitre.org/techniques/T0836/. Accessed 28 July 2026.
[9] MITRE. "ATT&CK Changes: v18.1 to v19.0." Entries T0855 and T1692.001. https://attack.mitre.org/docs/changelogs/v18.1-v19.0/changelog-detailed.html. Accessed 28 July 2026.
[10] Forescout Vedere Labs and Michael Bacon. "ICS Malware 'FrostyGoop/BUSTLEBERM': Insights Others Missed." 2 Aug. 2024. https://www.forescout.com/blog/ics-malware-frostygoopbustleberm-insights-others-missed/. Accessed 28 July 2026.
[11] Unit 42. "FrostyGoop's Zoom-In: A Closer Look into the Malware Artifacts, Behaviors and Network Communications." Palo Alto Networks, 19 Nov. 2024, updated 3 Dec. 2024. https://unit42.paloaltonetworks.com/frostygoop-malware-analysis/. Accessed 28 July 2026.
[12] IBM. "Cost of a Data Breach: The Industrial Sector." 2024. https://www.ibm.com/think/insights/cost-of-a-data-breach-industrial-sector. Accessed 28 July 2026.
[13] Kaspersky and VDC Research. "Almost a Quarter of Industrial Companies Report Cyberattack Damages Exceeding $5 Million." 29 May 2025. https://www.kaspersky.com/about/press-releases/almost-a-quarter-of-industrial-companies-report-cyberattack-damages-exceeding-5-million. Accessed 28 July 2026.
[14] Dragos and Marsh McLennan Cyber Risk Intelligence Center. "2025 OT Security Financial Risk Report." Aug. 2025. https://www.dragos.com/2025-ot-security-financial-risk-report. Accessed 28 July 2026.
[15] Lee, Robert M., and Tim Conway. "The Five ICS Cybersecurity Critical Controls." SANS Institute, 7 Nov. 2022. https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls. Accessed 28 July 2026.