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.

This introductory note explores a useful distinction: a command can be valid at the protocol layer while being inappropriate for the operating context.

Start with the process

Before interpreting a capture, establish what the system is supposed to do. Which workstation normally initiates communication? Which device receives it? What operations are expected during normal production, maintenance, and commissioning?

Without that context, a write request is just a write request. With context, the same request might be routine maintenance, a configuration mistake, or an action worth investigating.

The packet tells us what was requested. The process context helps us ask whether it should have been requested.

Packet analysis

A useful first pass is to describe an exchange without assuming intent. Record the source, destination, operation, timing, and response. Keep observation separate from interpretation.

The following is a synthetic annotation, not an extracted exploit payload or a real capture:

Observation: a state-changing request
Source role: engineering workstation
Destination role: laboratory controller
Context: outside the planned maintenance window
Response: request acknowledged
Conclusion: requires contextual review

An acknowledgment does not, by itself, establish the physical outcome. That requires additional evidence from the controller, logs, or process measurements.

Attacker objectives

For defensive analysis, think about the effect a state-changing action could have: modifying a setting, interrupting an expected operation, or changing how a controller behaves. The objective is to understand the relationship between a network action and the process it influences.

Detection opportunities

Consider several pieces of context together rather than treating any single field as a verdict.

False-positive considerations

Maintenance, commissioning, failover, and troubleshooting can look different from ordinary production. A useful alert should carry enough context for an engineer to distinguish those activities from an unexplained change.

Document the assumptions behind a rule. An assumption that is true for one cell, workstation, or shift may not hold elsewhere.

Mitigation and validation

A detection rule and a blocking rule answer different questions. Before considering enforcement, evaluate representative legitimate traffic, identify the consequences of a mistaken block, and agree on a rollback procedure with the system owner.

Key takeaways

• Protocol validity is a starting point, not a judgment about intent.
• Relate requests to endpoint roles, timing, and expected process behavior.
• Separate what a capture shows from what still needs to be verified.
• Evaluate false positives and operational effects before moving from detection to blocking.