FrostyGoop: Defending Against ICS Protocol Exploits

An attacker on an OT network does not need malware that evades your defenses. FrostyGoop, the industrial control system (ICS) malware the Cyber Security Situation Center in Ukraine identified in April 2024, proves the point. It carries native Modbus protocol support and sends unauthorized commands straight to programmable logic controllers (PLCs). In the confirmed incident, it disabled central heating for over six hundred apartment buildings in a Ukrainian municipality, and remediation took over two days while residents faced sub-zero temperatures.

At a glance

• FrostyGoop is the first publicly documented ICS malware with native Modbus support, capable of sending unauthorized commands directly to PLCs to disable industrial operations.
• Anomaly-based NDR and log analytics strain against FrostyGoop because the malware operates with precise, native awareness of ICS protocol values and opcodes, not the noisy behavior these tools are tuned to flag.
• Modbus and BACnet were built without authentication or encryption, making protocol-specific exploits a structural weakness in most OT environments rather than a misconfiguration.
• OT deception, specifically PLC decoys with native Modbus and BACnet support, surfaces FrostyGoop-style reconnaissance before the exploit executes, at the leaf-switch layer where core-switch NDR has no visibility.
• Acalvio ShadowPlex runs additively alongside existing OT monitoring and validated an 80 percent denial of attacker objectives against automated, credential-driven techniques in the U.S. Navy ANTX FY25 exercise.

FrostyGoop is a first-of-its-kind ICS malware with built-in support for Modbus-specific exploits. It communicates with devices over Modbus TCP to send unauthorized commands, manipulate control values, and modify operational parameters, giving an attacker direct influence over physical processes without going through legitimate control software.

Malware has traditionally targeted IT infrastructure, but OT assets run on protocols built for administration and monitoring rather than general computing. Modbus is one of the most widely deployed of these ICS protocols, used extensively across PLCs and other field devices.

FrostyGoop’s ability to send specific opcodes over Modbus lets it set register values that govern PLC operation directly. In the Ukraine incident, attackers used this to send remote commands that disabled PLC operations entirely, a level of physical impact IT-focused malware rarely achieves.

Modern IT protocols such as HTTPS and TLS build authentication and encryption into the protocol itself, so a client has to prove it belongs on the connection before it can act. Modbus and BACnet, by contrast, provide no authentication or encryption at all, which means every reachable device is a potential target, not just a misconfigured one.

Most ICS protocols were defined before protocol-level security was a design consideration. That gap enables a range of protocol-specific exploits: unauthorized clients issuing remote commands, man-in-the-middle interception, and protocol replay attacks that resend previously captured commands.

The combination of an exploitable attack surface and the mission-critical nature of OT assets makes protocol exploits a serious threat vector, and it is why OT-specific detection matters as much as prevention.

OT security has long relied on network segmentation and air gapping to isolate assets and reduce exposure. Segmentation remains a necessary prevention control and stays essential for shrinking the OT attack surface.

ICS protocol-specific malware is pushing OT security toward an assume-compromise posture, because prevention controls have more than one way to be bypassed. Internet-facing OT assets are one route, and it is the exploit vector the Lviv district heating attack made concrete. Insider risk from plant administrators and contract staff is another, and it does not depend on any network boundary at all.

A layered defense that pairs prevention with active threat detection closes that gap: segmentation limits what an attacker can reach, and detection shortens the distance between initial access and response once they reach it anyway.

OT assets need a detection approach built around their constraints, not one inherited from IT. Most cannot run security agents, which limits endpoint-centric tools such as EDR, and log availability and format vary widely across vendors and device generations, which limits log analytics too.

That has pushed OT security toward network-centric detection, primarily NDR, which analyzes traffic for known malicious patterns and anomalous behavior. NDR is a reasonable baseline, and it strains against protocol-specific malware for a structural reason: FrostyGoop operates with precise, native awareness of Modbus values and opcodes, so its traffic often does not deviate from what anomaly baselines expect. NDR is also typically deployed at the core switch, leaving a visibility gap for threats targeting leaf-switch assets, including unauthorized commands sent directly to PLCs.

Closing that gap calls for OT-specific decoys: instrumented assets that represent real OT devices and that no legitimate process ever needs to touch. Any interaction with one is a high-fidelity signal on its own, without baselining or tuning, and the same decoys extend visibility to leaf-switch assets that core-switch NDR cannot see. Decoys need to be automated and deployed at scale to keep pace with attackers acting at machine speed; a handful of hand-built decoys will not hold up the way an autonomous deployment does. Deception works alongside NDR and log analytics here, not in place of them.

Consider an energy provider built on the Purdue reference architecture. The OT security team deploys PLC decoys with native support for Modbus and BACnet.

An attacker gains access and stages FrostyGoop for use. Before deploying it against a specific target, the attacker runs reconnaissance to find exploitable PLCs, typically by scanning the subnet for devices responding on the Modbus port:

Because decoys are present, the reconnaissance sweep in step one surfaces decoy devices alongside real ones, and the OT security team gets notified before step two ever runs. The relevant question is why anything touched an asset no legitimate process should need. That question is the detection signal itself, not an inference the team has to build from weaker evidence elsewhere.

This early-warning capability, combined with high-fidelity decoy alerting, gives defense teams a response window before FrostyGoop’s payload executes. Acalvio ShadowPlex extends this same protocol-aware decoy coverage across core and leaf switches, closing the visibility gap that NDR alone leaves in most OT deployments.