Replay Attack

What is a Replay Attack?

A replay attack is an attack in which an attacker intercepts legitimate communication, stores it and later resends it unchanged, so that the receiver executes an old but valid message as if it were new. The attacker does not need to understand or break the message: it is enough that it was genuine once. In OT networks, this can lead to unintended machine control, deception of SCADA screens or incorrect process data in the Historian.

NIST describes a replay attack as one in which the attacker replays previously captured messages between a legitimate claimant and a verifier in order to masquerade as one of them. In industrial environments the target is often not a login, but control commands and measured values.

🧠 How does a replay attack work?

A replay attack usually consists of three steps:

1. Capture - the attacker gains access to the network, for example through an infected engineering workstation, a man-in-the-middle position or a mirrored switch port, and records traffic with a tool such as Wireshark.
2. Select - the attacker looks for the message that has the desired effect, such as a write to a register, a start or stop command or a valid login.
3. Replay - at a moment of the attacker’s choosing, the message is sent again. Because content, addresses and any signature are correct, the receiver executes it.

Replay differs from spoofing: with spoofing the attacker crafts a forged message, with replay a genuine message is reused. With session hijacking, the attacker takes over a running session instead of repeating individual messages.

🏭 What are well-known examples in OT?

The best-known example is Stuxnet. The older variant, aimed at the cascade protection system of the centrifuges in Natanz, recorded about 21 seconds of normal process values and replayed them in a loop during the attack. The control logic and the operators therefore saw a stable process while the pressure in the centrifuges was rising.

Replay also plays a role with Siemens controllers. The S7 Comm protocol of older S7-300/400 PLCs has no protection at all, so recorded start, stop and write commands can simply be repeated. S7 Comm Plus in the S7-1200 and S7-1500 gained an anti-replay mechanism, used since firmware 4.0 of the S7-1200 and in the S7-1500. Even so, researchers showed at Black Hat Europe in 2017 that they could bypass this protection on an S7-1200 with firmware 4.1: using recorded and crafted messages, they could start and stop the PLC remotely and change its outputs. In 2019 the Rogue7 research followed at Black Hat USA, in which an impersonated engineering station sent commands to S7-1500 PLCs.

🔍 Why are OT protocols vulnerable?

• No authentication or integrity check - classic protocols such as Modbus, Modbus TCP, DNP3 without Secure Authentication and basic GOOSE do not verify who sends a message, so session-level security is missing entirely
• No freshness information - without a timestamp, sequence number or nonce, a receiver cannot tell an original from a copy
• Readable traffic - data is usually not encrypted, so an attacker can see exactly which message does what
• Designed for availability - legacy systems are built to execute commands quickly and reliably, not to question their origin
• Long service life - control systems often run for twenty years or more, which keeps unprotected protocols in use for a long time

🔐 Which measures protect against replay?

Protection against replay always requires two things: the message must be genuine (integrity and authentication) and it must be fresh (used once or within a time window). A signature alone is not enough: a correctly signed old message remains correctly signed.

Timestamps only work when clocks are correct. Synchronise devices with secured NTP or PTP: whoever can shift the clock can make an old message look “valid” again.

🔧 How do modern industrial protocols protect themselves?

For new installations, choose OPC UA over OPC Classic where possible: OPC Classic depends entirely on DCOM for its security and in practice often runs with minimal security settings.

🧪 How do you detect a replay attack?

Note that repeated messages are not always suspicious in OT. GOOSE deliberately repeats every message, and polling SCADA systems read the same registers every second. Detection therefore works best with a baseline of normal traffic.

🏗️ What approach works in an existing plant?

Many plants cannot replace their protocols in the short term. A practical order of work is:

1. Inventory which protocols carry control commands without authentication, and which devices already support secured variants.
2. Segment according to network segmentation and the zones and conduits model, so an attacker has fewer places to capture traffic.
3. Restrict write access - allow write commands only from fixed engineering and SCADA systems, for example with an industrial firewall and deep packet inspection.
4. Enable secured variants where equipment supports them: OPC UA with SignAndEncrypt, DNP3 Secure Authentication, IEC 62351-6 for GOOSE.
5. Monitor with an OT IDS and log commands centrally, so unusual repetitions stand out.
6. Set requirements in procurement: IEC 62443-3-3 requires communication integrity in SR 3.1, with cryptographic protection as an enhancement from security level 3.

For Dutch organisations this is not optional. The Dutch Cybersecurity Act (Cyberbeveiligingswet), in force since 15 August 2026, requires essential and important entities to take appropriate measures for their networks. The Cyber Resilience Act requires manufacturers of products with digital elements to protect the integrity of transmitted data and commands; those requirements apply in full from 11 December 2027. A Zero Trust Architecture helps as well: never trust a message purely because of the IP address it comes from.

❓ Frequently asked questions

What is the difference between a replay attack and a man-in-the-middle attack?

In a man-in-the-middle attack, the attacker sits live between two parties and can read, alter or block messages. In a replay attack, the attacker resends a previously captured, unaltered message. A man-in-the-middle position is often used to record the traffic for a later replay attack.

Does encryption protect against a replay attack?

Encryption alone does not protect against a replay attack, because an encrypted message can be replayed in its encrypted form. Only in combination with sequence numbers, timestamps, nonces or session keys can the receiver recognise a repetition. Protocols such as TLS and OPC UA combine these mechanisms.

Is Modbus vulnerable to replay attacks?

Standard Modbus is highly vulnerable to replay attacks, because it has no authentication, no integrity check and no freshness information. A recorded write command to a register can simply be sent again. Modbus/TCP Security, which carries Modbus TCP inside TLS, solves this for equipment that supports it.

What is a nonce?

A nonce is a random or single-use number used in a message or handshake that is valid only once. Because the receiver keeps track of nonces already used, or sends a fresh challenge itself, a replay attack with an old message fails. Nonces are used in TLS and DNP3 Secure Authentication, among others.

Why does time synchronisation matter for replay attacks?

Much replay protection relies on timestamps with an allowed time window, such as the default 5-minute tolerance in Kerberos. If an attacker can shift a device’s clock through unsecured NTP, an old message may fall within that window again. Secured time synchronisation is therefore part of the defence against replay attacks.

Can an IDS detect a replay attack in OT?

An OT IDS with protocol awareness can detect a replay attack by spotting commands that appear at an unusual moment, from an unknown system or without a process reason. Because OT traffic is repetitive by nature, the IDS needs a baseline of normal behaviour. Detection complements preventive measures such as authentication and sequence numbers, but does not replace them.

📌 In summary

A replay attack exploits the fact that many OT protocols do not check whether a message is both genuine and new. Protection requires authentication plus freshness through sequence numbers, timestamps or nonces, complemented by segmentation, restricted write access and monitoring of commands.