OT Detection Engineering
When Modbus Lies: Detecting Threats Inside Industrial Protocols
FrostyGoop disrupted heat for more than 600 apartment buildings using valid Modbus commands. The traffic was allowed, the instructions were legal, and traditional security tools saw nothing wrong.
The difference between routine operation and sabotage may exist inside a valid industrial command.
Analyst Brief
What security teams need to know
Executive Summary
A valid command can still be an attack
Industrial protocol attacks often abuse trust rather than exploit a software vulnerability. FrostyGoop demonstrated this in January 2024 when attackers used valid Modbus commands to manipulate heating controllers in Lviv, Ukraine. The commands were properly formed, the protocol accepted them, and traditional antivirus had no malicious signature to detect.
This is the central challenge of industrial protocol detection. A Modbus write issued during an authorized process change may be completely normal. The same write, sent by an unfamiliar system at an unexpected time, may represent sabotage. The bytes alone do not reveal the difference.
Effective OT detection must interpret what a command instructed, who sent it, which asset received it, what value changed and whether the activity made sense for the current operational state.
Quick Answer
What is industrial protocol detection?
Industrial protocol detection identifies malicious or abnormal behavior inside protocols such as Modbus, DNP3, Siemens S7, EtherNet/IP and OPC UA. It evaluates command intent, source, destination, values, timing and operational context rather than relying only on malware signatures or known exploit patterns.
Key Takeaways
The protocol is part of the evidence
- Properly formatted industrial traffic can still be malicious.
- Modbus does not distinguish an authorized command from an attacker's command.
- Traditional IT detections often miss protocol abuse because no exploit, malware signature or malformed packet is required.
- Function codes and command values reveal what industrial traffic is attempting to do.
- Operational context determines whether an otherwise valid command is legitimate or suspicious.
- Passive monitoring provides protocol visibility without interacting directly with sensitive industrial devices.
Incident Analysis
FrostyGoop spoke the controller's language
In the coldest week of January 2024, the heat went out for roughly 100,000 people in Lviv, Ukraine. More than 600 apartment buildings lost heating and hot water for about two days, and the cause was not a burst pipe or a power failure. It was a piece of malware that security researchers later named FrostyGoop, and it did its damage by speaking the building controllers' own language. FrostyGoop sent Modbus commands that altered temperature readings, and the system, trusting what it was told, turned the heat down.
What makes that attack worth studying is what the defenders did not see. Antivirus tools never flagged FrostyGoop because there was nothing malformed to flag. The Modbus traffic was well formed and the commands were legal. The protocol has no way to tell an authorized instruction from an attacker's, so to it, the sabotage looked exactly like a normal day.
This is the problem at the heart of OT detection: in an industrial network, allowed traffic and safe traffic are not the same thing, and a detection program that cannot read the protocol cannot tell them apart. FrostyGoop was only the latest proof. It joined a short but growing list of malware built specifically to speak to controllers in their own protocols, and given how little has changed about those protocols, it will not be the last.
In an industrial network, allowed traffic and safe traffic are not the same thing.
Protocols Built to Trust
Most industrial protocols were designed decades ago for reliability and real-time performance on networks assumed to be physically isolated and friendly. Security was not a requirement, and it shows. Modbus, the workhorse of industrial automation, has no built-in authentication or encryption in its traditional form, sends commands in plaintext, and is easy to spoof or replay.
DNP3 originally shipped without security and only later added an optional authentication extension that many deployments never enable. Siemens S7 communications have been shown vulnerable to authentication bypass and command injection. EtherNet/IP and IEC 60870-5-104 carry many of the same legacy assumptions.
The common thread is implicit trust. The device assumes that anything able to send it a properly formatted command has the authority to do so. On a friendly, physically isolated network, that assumption was reasonable. On a converged network reachable from IT, it becomes an open door.
There are exceptions worth naming. OPC UA was designed with modern security, including authentication and encryption, built in from the start. But OPC UA is the newcomer, and the installed base of industrial equipment still runs on protocols that trust any device able to reach them.
On those networks, the question a detection program has to answer is not whether a command is well formed. It is whether that command should be happening at all.
When a Legal Command Is the Attack
Modbus identifies every operation with a function code. Reads use codes 01 through 04. Writes include function code 05 to set a single coil, 06 to write a single register, and 15 and 16 to write many values at once.
Nothing in the protocol distinguishes a legitimate write from a hostile one. A write single register operation is a routine instruction during normal operation and a sabotage command in the wrong hands. The bytes on the wire look identical in both cases. FrostyGoop did nothing more exotic than this. It wrote values that were entirely valid Modbus, and the controllers obeyed.
FrostyGoop used valid Modbus instructions to alter operational values rather than exploiting a malformed protocol message.
This is why the most capable industrial malware does not always need to rely on conventional exploits. PIPEDREAM, the modular ICS toolkit disclosed by U.S. agencies in 2022 and associated with CHERNOVITE, targets Schneider Electric and Omron controllers through technologies including OPC UA, Modbus and CODESYS.
The toolkit can abuse legitimate industrial functions to discover devices, obtain access, change operating modes, manipulate parameters and interact with controller logic. A detection program focused only on known exploit signatures may observe the traffic without recognizing the operational danger because the underlying protocol is performing a valid function.
Analyst Note
Modbus Write Operations
A write operation is not inherently malicious. Risk depends on the client, destination asset, value, timing, frequency and current process state.
| Function Code | Operation | Detection Consideration |
|---|---|---|
| 05 | Write single coil | May change the state of one discrete output. |
| 06 | Write single holding register | May change a process value, threshold or operating parameter. |
| 15 | Write multiple coils | Can alter several discrete outputs in one transaction. |
| 16 | Write multiple holding registers | Can modify multiple process values or configuration fields. |
Why Your IT Detection Sees Nothing
Detection content inherited from IT is built to recognize known-bad indicators: malware hashes, exploit patterns, suspicious domains and signatures of things that should never appear. Protocol-abuse attacks may present none of those characteristics.
The traffic is valid, the commands are legal and no software vulnerability needs to be triggered, so there may be no signature to match. FrostyGoop slipped past antivirus for exactly this reason. It was not necessarily hiding inside malformed traffic. There was simply nothing in the Modbus command that a conventional blocklist was designed to catch.
Catching this class of attack means moving beyond pattern matching against a list of bad things. The malicious Modbus write and the benign one differ primarily in context: who sent it, which device received it, what value it carried, when it occurred and whether it fit what the process was doing.
None of that context lives in a malware hash. Much of it lives in the protocol and the operating environment, which are precisely the layers a flat IT-style rule set may never open. It is the same gap that can let a fully equipped security operations center miss an OT attack in progress. The tools are watching closely, but for the wrong kind of wrong.
| Traditional IT Detection | OT-Aware Detection |
|---|---|
| Malware hashes | Industrial command intent |
| Exploit signatures | Legitimate protocol functionality used abnormally |
| Suspicious domains and IP addresses | Authorized and unauthorized protocol clients |
| Malformed packets | Properly formed but operationally dangerous commands |
| Known indicators of compromise | Deviations from process state and operational baselines |
| File and endpoint behavior | Function codes, register values and device interactions |
| Connection allowed or denied | Whether the command should occur at that moment |
A firewall can confirm that Modbus traffic is permitted. It cannot determine whether the permitted command is safe for the process.
Reading the Protocol, Not Just the Traffic
Protocol-aware detection starts by parsing the industrial protocols actually in use and learning what normal behavior looks like within them. From there, high-value detection opportunities become visible: an unexpected write to a device that normally receives only reads, a function code that has never appeared on the segment, a new client speaking Modbus, polling that suddenly runs at an abnormal rate or a command sequence that contradicts the current operational state.
Each of these detections is defined by what the command means, not by a fixed pattern of malicious bytes.
What separates a useful detection from a noisy one is operational context. The same write that is expected during a known batch transition may be alarming when it arrives from an unfamiliar client during an idle period. Only a detection that understands the difference can prioritize the signal correctly.
Built well, these detections turn the protocol from a program's largest blind spot into one of its sharpest sensors, because the command itself may reveal the attacker's operational intent.
The work can be performed passively from network taps and SPAN ports so that monitoring does not risk disturbing fragile devices. Because Modbus and related protocols run across industrial environments worldwide, protocol fluency is the difference between a program that merely sees OT traffic and one that understands what the traffic was trying to do.
Detection Opportunities
What should industrial protocol detection look for?
Unexpected Write Operation
Alert when a device that normally receives only read requests receives a write command.
New Protocol Client
Identify a previously unseen workstation, server or network address initiating an industrial protocol.
Unusual Function Code
Flag a function code that has never appeared on the segment, asset or communication pair.
Abnormal Register Value
Detect values that exceed expected engineering ranges or conflict with the current operating mode.
Process-State Contradiction
Identify commands that do not make sense for the current production phase, batch state or physical condition.
Polling-Rate Change
Detect sudden increases, decreases or irregularities in established polling behavior.
Command Sequence Anomaly
Alert when valid commands occur in an unexpected order or omit a required operational step.
Activity Outside an Approved Window
Increase severity when write or configuration activity occurs outside approved maintenance or transition windows.
Passive monitoring provides protocol visibility without sending commands to industrial devices.
CyberFusion Center Perspective
The Packet Can Be Valid While the Operation Is Wrong
A CyberFusion Center does not stop at determining whether a packet is properly formatted or allowed through the network. It asks whether the command makes sense for that asset, process, source and moment in time.
That requires combining industrial protocol telemetry with asset criticality, network position, engineering baselines, maintenance windows, historian data, identity information and current operational state.
The objective is not simply to detect that a Modbus write occurred. The objective is to determine whether that write represented a normal process action, an engineering mistake, unauthorized activity or an attack.
This is where protocol traffic becomes operational intelligence.
How PhishCloud Approaches It
Industrial protocols must be interpreted, not simply allowed
PhishCloud develops industrial protocol detection logic that inspects function codes, identifies abnormal write operations and evaluates command sequences against operational context.
Our detection approach supports protocols including:
- Modbus
- DNP3
- Siemens S7
- OPC UA
- EtherNet/IP
- IEC 60870-5-104
We treat industrial protocols as operational languages that must be interpreted, not opaque traffic that should be trusted simply because it is allowed.
If your monitoring platform can tell you that OT traffic occurred but cannot explain what the traffic instructed, a detection coverage review can identify the protocol-level blind spots and define the telemetry, context and detection logic required to close them.
Frequently Asked Questions
Industrial Protocol Detection FAQ
Can antivirus detect Modbus attacks?
Antivirus may identify a known malware component running on a workstation or server. It generally cannot determine whether a valid Modbus command is operationally malicious because the command may contain no malware, exploit or recognizable malicious signature.
Why can a firewall miss industrial protocol abuse?
A firewall evaluates attributes such as source, destination, port and protocol. It may allow the communication because the connection is authorized even when the command carried inside that connection is unsafe or unauthorized.
Is Modbus encrypted?
Traditional Modbus TCP does not provide native encryption or authentication. Security therefore depends heavily on network architecture, access control, monitoring and additional protective controls. A separate Modbus Security protocol specification also exists, but it should not be assumed to be deployed across legacy environments.
What is a Modbus function code?
A Modbus function code identifies the operation a client wants a device to perform. Examples include reading coils, reading registers, writing a single value or writing multiple values.
What makes a Modbus write suspicious?
A write becomes suspicious when its source, destination, value, timing or operational purpose deviates from expected behavior. A write from an unknown client or outside a maintenance window may warrant immediate investigation.
How does OT-aware detection differ from SIEM detection?
A SIEM can correlate events and logs, but it may not understand the meaning of an industrial command unless the underlying telemetry has been parsed and enriched. OT-aware detection provides protocol and process context that makes the event operationally meaningful.
Can industrial protocol monitoring be performed passively?
Yes. Network taps, SPAN ports, sensors and other passive collection methods can observe industrial traffic without sending commands to controllers or interfering with sensitive processes.
Which industrial protocols should organizations monitor?
Organizations should monitor every protocol used to control or observe critical processes. Common priorities include Modbus, DNP3, Siemens S7, EtherNet/IP, OPC UA and IEC 60870-5-104.
Sources and Further Reading
Authoritative references
- Dragos: How to Protect Against FrostyGoop, ICS Malware Targeting Operational Technology
- CISA Advisory AA22-103A: APT Cyber Tools Targeting ICS/SCADA Devices
- MITRE ATT&CK for ICS: INCONTROLLER, S1045
- Modbus Organization: MODBUS Application Protocol Specification
- Modbus Organization: Introduction to Modbus and Common Function Codes
Close the Protocol Visibility Gap
Can Your Monitoring Explain What the Command Instructed?
Seeing industrial traffic is not the same as understanding it. PhishCloud OT Detection Engineering helps organizations identify protocol-level blind spots, develop operationally aware detections and turn industrial telemetry into actionable signals.