When Valid OT Commands Become Attacks

Sometimes the most interesting packet in an OT network is not malformed at all. It has the expected fields, follows the protocol, and receives a perfectly ordinary response. The question is whether that action belongs in the process at that moment.

In industrial environments, many commands that can affect a controller are also legitimate engineering functions. Changing an operating mode, writing a value, or modifying a configuration may be completely normal during maintenance or commissioning, which makes that same activity difficult to judge from network traffic alone.

A packet can therefore be perfectly valid at the protocol layer while still representing an action that should not have happened in that context. The same command may be expected from an engineering workstation during an approved maintenance window, but highly unusual from another endpoint during normal production.

This is where OT traffic analysis moves beyond identifying protocols and commands. Understanding what happened on the wire is only the first step; the harder question is whether that behavior makes sense for the asset, the timing, and the process behind it.

The exploit

The exploit I used for this example is EDB-19831: Siemens Simatic S7-300/400 CPU START/STOP Module, originally written as a Metasploit auxiliary module.

Its objective is straightforward: establish communication with the PLC and change its CPU state between START and STOP. According to the module description, moving the PLC into STOP can end the controller's process-control activity.

There is no need for the attacker to invent a new function, the controller already knows how to stop and the attacker is simply abusing the ability to ask it to do so.

This exploit maps closely with MITRE ATT&CK for ICS technique T0858 – Change Operating Mode, which covers adversaries changing controller operating modes such as RUN, PROGRAM, REMOTE, or STOP. MITRE notes that these operating modes are legitimate controller capabilities and may be changed through controller APIs or other remote mechanisms depending on the product.

That is where the distinction between protocol validity and operational legitimacy becomes important.

Following the exchange

When I analyze an exploit like this, I try not to begin with the assumption that every packet generated by the exploit is malicious.

I first reconstruct the conversation.

In the PCAP I captured, the session begins normally over TCP/102 with S7 communication being established between the workstation and the PLC.

View full size

Within that conversation, the important part is not simply that two devices communicated, because an engineering workstation communicating with a PLC over that service could be completely expected.

The interesting moment is the state-changing operation inside that otherwise plausible communication.

View full size

This is the key finding. The packet is not suspicious because it is malformed, it is suspicious because a valid controller function is being used to change operating state. From the protocol's point of view, the command is recognizable and legitimate.

So when does STOP become malicious?

That depends on what surrounds the command. A CPU STOP issued from an approved engineering workstation during maintenance may be completely legitimate, while the same request from an unexpected endpoint during normal production could require immediate investigation.

This makes the command itself useful for visibility, but not enough to determine intent. The source asset, destination PLC, timing, and expected engineering activity all matter. Two packets can look almost identical at the protocol layer while representing very different operational situations.

That is where this type of traffic becomes harder to classify than a malformed exploit payload. There may be no unusual function code or obviously malicious string to match; the difference may exist entirely in the context around a valid command.

Detection becomes a question of context

A detection rule can still be built around the STOP operation. An S7-aware IDS can monitor for a PLC Stop function and generate an alert whenever that operation appears on the network.

The problem is that the same rule may also trigger during legitimate maintenance. A stronger detection therefore combines the command with asset context rather than treating the function alone as malicious.

For example:

S7 PLC STOP observed
+
source is not an approved engineering workstation
+
destination is a protected PLC
=
high-priority alert

This changes the question from “Was a STOP command sent?” to “Was this system supposed to be able to send it?”

Timing can add another layer. A STOP request during an approved maintenance window may be expected, while the same event during normal production may deserve much higher priority.

Virtual patching is less straightforward

This type of exploit is also a good example of where virtual patching becomes difficult.

Virtual patches work best when there is something clearly malicious to match, such as malformed input, an invalid field, or a payload that legitimate engineering software would never generate. In this case, the STOP command itself is a valid S7 operation, so blocking every instance of it could also block legitimate maintenance activity.

A safer control is usually to restrict who can reach the PLC management service in the first place. Firewall policy can limit TCP/102 access to approved engineering workstations or management segments, while detection rules monitor sensitive operations such as STOP within those permitted connections.

The control therefore becomes less about blocking a bad packet and more about limiting which systems are allowed to issue powerful commands at all.

Key takeaway

This capture shows why valid OT commands can be difficult to classify. The protocol can tell us exactly what was requested, but it cannot tell us whether that request belonged in the process at that moment.

In cases like this, the strongest detection often comes from combining packet-level visibility with asset roles, communication paths, and operational context rather than relying on the command alone.