TL;DR: FrostyGoop shows how Modbus-specific malware can send unauthorized commands to PLCs, disable operations, and leave a municipal heating provider exposed for more than two days, according to Acalvio. The lesson is that segmentation alone does not stop protocol-aware OT attacks, and deception plus early detection matter when unauthenticated industrial protocols are in play.
At a glance
What this is: This is an analysis of FrostyGoop, a Modbus-aware ICS malware campaign that can issue unauthorized PLC commands and bypass reliance on segmentation alone.
Why it matters: It matters because OT teams cannot assume network isolation will stop protocol-native abuse, and identity-adjacent control, detection, and deception choices have to account for unauthenticated industrial traffic.
Context
ICS protocol exploitation is the abuse of industrial control traffic itself, rather than a generic network intrusion. In this case, FrostyGoop targeted Modbus commands and PLC control paths in an OT environment, which means the governing problem is unauthorised control of industrial assets, not just perimeter bypass.
For OT security teams, the gap is that segmentation can reduce reachability but cannot authenticate intent inside an unauthenticated protocol. Once an attacker can speak Modbus, the protocol may accept commands that alter register values, disable operations, or change device behaviour without the kind of built-in trust checks common in modern IT protocols.
That makes this a detection and containment problem as much as a prevention problem. The article describes a municipal heating provider, which is a typical example of why OT compromise has real-world safety and service consequences.
Key questions
Q: What breaks when industrial protocols like Modbus are unauthenticated?
A: When industrial protocols are unauthenticated, any actor that can reach the control path may be able to send syntactically valid commands that alter device behaviour. That breaks the assumption that internal network position equals trust. In OT, the result is command-layer abuse, not just packet interception or scanning.
Q: Why do ICS protocol exploits bypass traditional segmentation controls?
A: Segmentation limits reach, but it does not validate whether an allowed command is safe for the asset receiving it. If an attacker gets a foothold inside the OT zone, protocol-specific malware can still issue destructive commands to PLCs. The control failure is trust without command integrity.
Q: How can security teams detect protocol-aware attacks in OT environments?
A: Teams need visibility that understands industrial command patterns, not just network flows. That usually means monitoring for suspicious opcodes, register writes, reconnaissance against PLC services, and decoy interactions that indicate probing. If the tooling only watches for generic anomalies, protocol-specific abuse can slip through as legitimate-looking traffic.
Q: What should OT teams do when protocol abuse is discovered on live assets?
A: Contain the exposure by isolating affected segments, validating which controllers received hostile commands, and moving to response before the attacker completes further protocol interactions. The priority is to stop additional control traffic, preserve evidence from network and decoy telemetry, and determine whether the same path can reach other PLCs.
Technical breakdown
Why Modbus abuse works against PLCs
Modbus was designed for industrial command and monitoring, not for modern trust enforcement. In the article's example, FrostyGoop used Modbus TCP to send opcodes that set register values and alter PLC behaviour. Because the protocol does not natively authenticate clients or encrypt traffic, a device that can reach the service port may be able to issue commands that the PLC accepts as valid. That creates a protocol-level trust gap rather than a mere malware problem. The result is that the attacker does not need to break the PLC, only speak its language.
Practical implication: treat protocol reachability as control exposure, not just network exposure.
Why segmentation alone does not stop OT exploitation
Segmentation reduces the attack surface by limiting who can reach OT assets, but it does not guarantee that reachable traffic is benign. The article notes several bypass paths, including internet-facing OT assets and insider access from administrators or contract staff. Once an adversary is inside the trust boundary, unauthenticated protocol traffic can still carry hostile commands. In other words, segmentation is a perimeter control, while the exploit lives at the protocol layer. That is why a purely network-topology view misses the attack condition.
Practical implication: validate controls that inspect protocol content, not only network path boundaries.
Why decoys improve visibility for protocol-aware attacks
OT decoys work because they present believable industrial assets that respond to reconnaissance and protocol interaction without being production systems. The article describes decoys that support Modbus and BACnet, which means they can surface attacker behaviour before live devices are touched. That is especially useful where endpoint agents are hard to deploy and logs are inconsistent. Decoys create high-fidelity tripwires for protocol-specific probing, allowing defenders to observe the reconnaissance stage and trigger response before unauthorized commands reach real PLCs.
Practical implication: place deception where reconnaissance and protocol probing will reveal attacker intent early.
Threat narrative
Attacker objective: The attacker aimed to disable or manipulate OT operations by issuing trusted-looking Modbus commands to PLCs.
- Entry occurred when the attacker gained access to the OT environment and began probing for reachable industrial assets.
- Reconnaissance identified PLCs supporting Modbus, including devices that could be targeted with protocol-specific commands.
- Escalation came through FrostyGoop's Modbus exploits, which allowed unauthorized command messages to disable PLC operations.
- Impact was operational disruption to the district energy provider, with heating services affected for more than two days.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Protocol trust, not segmentation, is the real failure mode here: FrostyGoop shows that OT compromise can succeed when unauthenticated industrial protocols are still trusted to carry operational commands. Segmentation may reduce exposure, but it does not change the fact that Modbus accepts control traffic without native identity assurance. The practitioner conclusion is that protocol trust has to be governed as carefully as network reachability.
OT detection must move closer to protocol semantics: Network visibility alone is insufficient when the malicious payload is a valid-looking Modbus opcode. This article reinforces that industrial security teams need controls that recognise command intent, not just anomalous ports or flows. The practitioner conclusion is that detection strategy should be measured by whether it sees protocol abuse before the PLC accepts it.
Assume-compromise is now the more realistic OT posture: The idea that segmentation can prevent most protocol abuse was designed for a world where hostile traffic could be kept outside the control plane. That assumption fails when attackers can reach industrial services through internet exposure, insider access, or shared operational paths. The implication is that OT governance must plan for hostile protocol traffic already inside the boundary, not just keep it out.
Decoys create a governance-quality signal, not just an alert: Deception assets are valuable because they expose reconnaissance against industrial assets before production devices are touched. That matters in OT, where agent deployment is difficult and logs are sparse. The practitioner conclusion is that high-fidelity deception can serve as an early validation of whether the environment still assumes secrecy where protocol exposure already exists.
Identity in OT is often implicit, and that is the weakness: This article illustrates a broader governance problem in industrial environments, where devices often trust commands based on network position rather than authenticated identity. When a PLC accepts control traffic from any reachable client, the control model is architectural, not identity-based. The practitioner conclusion is that OT programmes need to treat protocol-level authorisation as a first-class governance issue.
From our research library:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Read next: OT and ICS Identity and Access Guide
What this signals
Protocol-aware OT attacks change the control problem: once an adversary can speak an industrial protocol, segmentation no longer answers the core question of whether the command itself is legitimate. For OT programmes, that means the next control boundary is protocol inspection, not just network separation.
Decoys are especially useful where endpoint controls are weak: the article describes environments where agent-based tooling is often impractical and logs are inconsistent, so deception becomes a way to surface attacker reconnaissance before production devices are hit. That is a useful pattern for any OT estate with limited host visibility.
For practitioners
- Map exposed industrial protocols Inventory which OT assets still accept unauthenticated Modbus, BACnet, or similar traffic, and identify where those services are reachable from broader networks or partner access paths.
- Validate protocol-aware detection Test whether your monitoring can flag unauthorized command messages and suspicious register writes, not just unusual source addresses or port scans.
- Deploy deception on high-value PLC segments Place PLC decoys where they can absorb reconnaissance and protocol probing before real controllers are touched, especially on leaf-switch-connected assets.
- Review insider and contractor pathways Check whether administrators, vendors, and contractors can reach OT control services in ways that segmentation does not meaningfully constrain.
Key takeaways
- FrostyGoop demonstrates that OT compromise can occur through valid-looking industrial commands, not only through generic malware execution paths.
- The incident took over two days to remediate, showing how quickly protocol abuse can become an operational and safety issue in critical infrastructure.
- OT teams should combine segmentation with protocol-aware monitoring and deception, because trust must be evaluated at the command layer, not only at the network layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Unauthenticated industrial protocols are the core weakness exploited in the article. |
| Recommendation — Treat unauthenticated OT protocol access as a control failure and restrict command paths to approved sources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who can issue control commands to OT assets. |
| Recommendation — Align OT command permissions to PR.AA-05 and verify that reachable services still enforce authorisation boundaries. | ||
| MITRE ATT&CK | TA0007;TA0008;TA0040 — Discovery; Lateral Movement; Impact | The article describes reconnaissance, protocol abuse, and operational disruption. |
| Recommendation — Map OT detections to discovery, movement, and impact stages so protocol probing is visible before control disruption. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article highlights insider and contractor access pathways into OT environments. |
| Recommendation — Review account access into OT control zones and remove unnecessary administrator and vendor pathways. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The piece argues that segmentation alone is insufficient and trust must be continuously evaluated. |
| Recommendation — Apply zero trust principles to OT command paths and verify each access request before allowing control traffic. | ||
Key terms
- Industrial Control Systems: Industrial control systems are the components that directly automate and supervise industrial processes, including controllers, sensors, and supervisory software. They are a subset of operational technology, but they often carry the most sensitive control paths and therefore demand specialised access and monitoring controls.
- Programmable Logic Controller: A Programmable Logic Controller is an industrial device that executes control logic for machinery and processes. PLCs are often trusted to run continuously, so unauthorized access can alter physical behaviour quickly. In modern SCADA governance, PLC access must be tightly scoped and traceable.
- OT Deception: OT deception uses decoys that resemble industrial assets to detect reconnaissance, probing, and exploitation attempts. It is especially useful where host-based agents are hard to deploy, because it can reveal attacker intent before real controllers receive malicious commands.
- Protocol-Aware Detection: Protocol-aware detection is a monitoring approach that inspects traffic with knowledge of the specific industrial protocol in use, not just generic network patterns. It helps defenders identify abnormal commands, suspicious session behaviour, and exploit attempts that conventional perimeter tools may miss, especially in encrypted or highly interconnected OT environments.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org