S1165: FrostyGoop

FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]

ICSS1165MalwareObject v1.0 Modified Nov 20, 2024, 23:33 UTC (UTC+00:00)

FrostyGoop matters because it targets the boundary between IT-managed Windows systems and physical industrial operations. MITRE describes it as a Windows Golang binary that can read and write Modbus TCP holding registers over port 502, meaning normal-looking industrial protocol traffic can be used to change how field devices operate. Its association with the FrostyGoop Incident against district heating services in Ukraine makes this a business-continuity and cyber-physical resilience concern, not just a malware signature problem.

Executive priority

Leaders should treat FrostyGoop as a test of OT visibility and control governance: do we know which Windows control servers can reach PLC/RTU/IED assets over Modbus TCP, who is allowed to issue register writes, and whether SOC/IR teams can prove what changed during an incident? Priority should go to evidence of segmentation, controlled access to port 502, monitoring of process-state reads and parameter writes, and readiness to investigate service-impacting manipulation of industrial systems.

Technical view

For defenders, the key validation point is whether Modbus TCP activity from Windows-based control assets to field controllers is inventoried, baselined, and inspectable. ATT&CK relationships tie FrostyGoop to process-state monitoring, command-line use, parameter modification, standard application-layer protocol use, and commonly used port communication. SOC and OT teams should validate visibility into command-line execution on control servers, network flows and protocol details for TCP/502, and any device or engineering records that show holding-register reads and writes. Because MITRE provides no official detection text, detection engineering should be environment-specific and based on deviations from authorized Modbus masters, expected register ranges, timing, and change windows.

Likely telemetry

OT network traffic and flow records for Modbus TCP, especially TCP/502
Protocol-aware Modbus logs showing read/write functions and holding-register access where available
Windows endpoint telemetry from control servers, including process creation and command-line activity
Firewall, jump host, remote access, and segmentation logs showing paths into control networks
PLC/RTU/IED, engineering workstation, HMI, historian, or control application records that can corroborate process-state reads and parameter changes

Detection direction

Baseline authorized Modbus TCP communications and alert on unexpected Windows hosts issuing Modbus traffic to field devices.
Prioritize visibility into write activity to holding registers, especially outside maintenance windows or from non-standard operator/control paths.
Correlate command-line execution on control servers with new or unusual network connections to TCP/502.
Tune detections with OT operations input because legitimate engineering, maintenance, and HMI activity may also read or write registers.
Look for relationship-driven patterns: process-state reads followed by parameter writes, and standard protocol use that blends into normal ICS traffic.

Mitigation priorities

Restrict Modbus TCP access so only approved control assets can communicate with field devices on required paths.
Segment control networks and enforce firewall rules around TCP/502 and other ICS management paths.
Maintain an authoritative inventory of Modbus-speaking assets, authorized masters, expected registers, and approved change windows.
Harden Windows-based control servers and monitor or restrict command-line execution consistent with operational requirements.
Use change-management and engineering approval processes for parameter modifications that can affect physical operations.

Analyst notes and limits

This take is based on the MITRE ATT&CK S1165 software object and supplied relationships. The most operationally important point is not the malware name but the capability: interaction with ICS equipment using legitimate Modbus commands to read and write holding registers. Defensive value depends heavily on local OT architecture, available protocol inspection, and whether operations teams can distinguish authorized control activity from unauthorized manipulation.

MITRE does not provide official detection guidance, tactics, aliases, or labels for this object in the supplied fields. The object supports Control Server and Field Controller/RTU/PLC/IED platforms and is associated with the FrostyGoop Incident, but this summary does not infer current exploitation, attribution, customer exposure, or guaranteed detection coverage.

Official MITRE ATT&CK definition

FrostyGoop

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 5 rows

Domain	ID	Name	Relationship / procedure
ICS	T0836	Modify Parameter	FrostyGoop allows for the modification of system settings by reading and writing to registers via Modbus commands.CitationDragos FROSTYGOOP 2024CitationNozomi BUSTLEBERM 2024
ICS	T0801	Monitor Process State	FrostyGoop can read data from holding registers via Modbus communication.CitationDragos FROSTYGOOP 2024
ICS	T0869	Standard Application Layer Protocol	FrostyGoop utilizes the Modbus protocol for transmitting commands to victim devices.CitationDragos FROSTYGOOP 2024
ICS	T0885	Commonly Used Port	FrostyGoop communicates using the Modbus protocol over the standard port of TCP 502.CitationDragos FROSTYGOOP 2024
ICS	T0807	Command-Line Interface	FrostyGoop is compiled for Windows systems and leverages a Windows-based command line interface.CitationDragos FROSTYGOOP 2024 Modbus interaction functionality is based off a publicly available Github repository for command line input.CitationNozomi BUSTLEBERM 2024

Associated objects

Groups, software, and campaigns

C0041: FrostyGoop Incident

FrostyGoop Incident took place in January 2024 against a municipal district heating company in Ukraine. Following initial access via likely exploitation of external facing services, FrostyGoop was used to manipulate ENCO control systems via legitimate Modbus commands to impact the delivery of heating services to Ukrainian civilians.[1][2]

Relationship explorer

All related ATT&CK context

uses · Technique T0836: Modify Parameter ICS uses · Campaign C0041: FrostyGoop Incident ICS uses · Technique T0801: Monitor Process State ICS uses · Technique T0869: Standard Application Layer Protocol ICS uses · Technique T0885: Commonly Used Port ICS uses · Technique T0807: Command-Line Interface ICS

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 1.0
Created: Nov 20, 2024, 23:02 UTC (UTC+00:00)
Modified: Nov 20, 2024, 23:33 UTC (UTC+00:00)
Raw hash: 02ae2d9672ec28b3...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.0	Nov 20, 2024, 23:33 UTC (UTC+00:00)	Current bundle	`02ae2d9672ec…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
Dragos FROSTYGOOP 2024

Mark Graham, Carolyn Ahlers, Kyle O'Meara; Dragos. (2024, July). Impact of FrostyGoop ICS Malware on Connected OT Systems. Retrieved November 20, 2024.
Open source URL
[2]
Nozomi BUSTLEBERM 2024

Nozomi Networks Labs. (2024, July 24). Cyberwarfare Targeting OT: Protecting Against FrostyGoop/BUSTLEBERM Malware. Retrieved November 20, 2024.
Open source URL
[3]
BUSTLEBERM

(Citation: Nozomi BUSTLEBERM 2024)
[4]
mitre-attack S1165
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use