Quick answer: Modbus is a protocol that has been used for over forty years to communicate between supervisory controllers and remote terminal units (RTU) in industrial control systems (SCADA), and security was never considered when it was designed; messages have no authentication, no encryption and no freshness check. This gap makes two concrete attacks possible: in a replay attack, an attacker resends a previously captured valid write command, such as one that opens a valve, without any modification, and the device accepts it as a new and legitimate command; in a time delay attack, the attacker does not block traffic but instead delays certain messages or permanently changes a register value, creating a gap between what the operator sees on screen and the real physical state in the field. Neither attack produces any protocol level error, which is why detecting them is only possible by comparing expected behavior against actual measured behavior.

In a factory or a power plant, there is constant data exchange between a supervisory controller (SCADA) and remote terminal units (RTU) in the field: is a valve open or closed, what is the pressure, is a motor running. The language of this exchange is called Modbus, and almost no industrial facility runs without it. The problem is that this language was designed in 1979 and has fundamentally not changed since.

Why Modbus is this vulnerable

In the Modbus/TCP protocol, a read or write command travels the network as a plaintext frame, and the receiving device does not verify whether this frame actually came from an authorized source. When the same frame is sent again, the device cannot tell the difference because the protocol has no sequence number or timestamp. This is the most fundamental structural problem of ICS and SCADA security: a protocol designed under the assumption that it would run on a trusted wired network has, over time, become exposed to IP networks and sometimes to the internet.

How a replay attack works

In a replay attack, the attacker does not even need to understand the content of the message; it is enough to listen to network traffic, capture a valid write command, such as one that opens a relay or changes a setpoint value, and later resend it exactly as captured whenever desired.

Step What happens
Listening The attacker captures a valid write command
Waiting The command is stored without any modification
Resending The same command is put back on the network at a chosen time
Acceptance The device treats the command as new and legitimate, and executes it

In a controlled test performed in a lab environment, reading a value written to a register, changing it, restoring it, and then resending the exact same raw frame a few seconds later, only to have the device accept it without any objection, concretely demonstrates how fundamental this flaw is at the protocol level.

Time delay attack

A time delay attack is more subtle: instead of blocking traffic entirely, the attacker delays specific messages or permanently changes the value of a specific register. The result is a gap or drift between the value the operator sees on screen and the real physical state in the field. This kind of attack is one of the hardest classes to verify because proving its effect requires answering two questions with evidence, not just whether the write was accepted, but whether response latency actually and measurably changed, and whether that delay actually disappeared once the original state was restored.

Why it is especially serious

Systems managed over Modbus are usually connected directly to the physical world: a valve, a relay, a motor drive. Because of this, a protocol level flaw, unlike a purely digital data leak, can translate directly into a physical consequence. This explains why such assessments must be carried out with extreme care, preferably in an isolated lab environment, with restoration verified at every step; just as in a penetration testing methodology, a baseline must be taken before every active step here as well, and it must be verified afterward that the system has genuinely returned to that baseline.

The KAOS and DSET approach

DSET assesses replay and time delay attacks in a controlled manner in an isolated Modbus RTU test environment in its own laboratory. Our local AI engine KAOS measures a baseline response latency before starting any active test, then applies a controlled change, and finally verifies that the system has actually returned to its original state, both through the register value and through response latency. A finding is only reported as validated once all three steps are backed by evidence; otherwise it is marked inconclusive and never presented as certain.

Frequently asked questions

Haven't newer versions of Modbus solved this problem? Modbus/TCP security (Secure Modbus, with TLS support) has been defined as a separate extension, but the vast majority of devices currently in the field do not support this extension and continue using the old Modbus frame. In practice, network segmentation and network level protection remain a more realistic solution than changing the protocol itself.

Is a replay attack a real incident or just a theoretical risk? Controlled lab tests have repeatedly shown that this attack is real and practically feasible; the complexity of the attack is low and it requires no special tooling or deep protocol knowledge. This means the risk is concrete, not theoretical.

Does this kind of testing damage the device itself? Not when done correctly. A baseline is taken before every step, every change is designed to be reversible, and it is independently verified after testing that the system has genuinely returned to its original state. A test performed without this discipline is an unacceptable risk for a real production system.

Sources

To assess your industrial control system's Modbus surface in a controlled laboratory environment, contact DSET. We provide OT and SCADA security consulting from our Ankara Hacettepe Teknokent laboratory.