Replay Attacks and Prevention

A replay attack occurs when an attacker intercepts a valid data transmission and fraudulently repeats or delays it. The attacker does not need to decrypt or alter the captured data; they simply retransmit it to trick the receiver into performing an unauthorized action, such as authenticating a session or authorizing a transaction. Replay attacks exploit the fact that a legitimate message, once captured, can be reused if there is no mechanism to detect its duplication.

Replay attacks are particularly dangerous in authentication protocols. For example, if a user sends a password hash to log in, an attacker who captures that hash can replay it to impersonate the user. Even if the password is never revealed, the hash itself becomes a credential.

Nonces (Number Used Once) are random or sequential numbers included in a message to ensure freshness. The receiver checks that a nonce has not been seen before. For example, in the Kerberos protocol, the client includes a nonce in the initial request, and the server includes it in the response to prevent replay of the response.

Timestamps are used to limit the validity window of a message. If the message's timestamp is outside an acceptable skew (e.g., ±5 minutes), the receiver rejects it. This requires synchronized clocks, often via NTP.

Sequence Numbers are monotonically increasing counters. The receiver tracks the last sequence number and rejects any packet with a number less than or equal to the last seen. This is common in TCP (sequence numbers) and IPSec (anti-replay window).

Challenge-Response Authentication inherently prevents replay: the server sends a random challenge (nonce), and the client must respond with a cryptographic operation (e.g., hash of challenge + secret). The captured response is useless for a different challenge.

Variants: - Reflection Attacks: The attacker captures a message and sends it back to the sender, tricking the sender into revealing information. - Replay in Cryptographic Protocols: Even encrypted messages can be replayed if the encryption doesn't include a unique identifier. For example, a captured TLS ClientHello with a session ID could be replayed to resume a session, though modern TLS uses session tickets with built-in replay protection.

Attackers exploit replay attacks in several scenarios:

Nonces:

Timestamps:

Sequence Numbers:

Challenge-Response:

Session Tokens with Context:

One-Time Passwords (OTP):

Capturing with tcpdump:

sudo tcpdump -i eth0 -w capture.pcap port 88 or port 389

This captures Kerberos (port 88) and LDAP (port 389) traffic for potential replay.

Replaying with Scapy (Python):

from scapy.all import *
packets = rdpcap('capture.pcap')
sendp(packets[0], iface='eth0')

This sends the first captured packet onto the network.

Testing replay with netcat:

# On attacker: listen and store
nc -l -p 1234 > captured.bin
# On attacker: replay
nc target 1234 < captured.bin

A security analyst monitors Active Directory domain controller logs and sees Event ID 4768 (Kerberos TGT requested) for the same user account from two different source IP addresses within seconds. One IP is the user's workstation; the other is an unknown IP. The analyst suspects a replay attack. They check the Kerberos pre-authentication timestamp: if the timestamp is outside the allowed skew, the KDC should reject it. However, the attacker may have synchronized their clock. The correct response is to enable Kerberos armoring (FAST) and enforce strict timestamp checking. The analyst also implements network segmentation to prevent ARP spoofing. A common mistake is to assume the user's account is compromised and reset the password, but that does not stop replay of already captured TGTs. The analyst must also revoke existing tickets and enforce replay protection mechanisms.

A web developer implements OAuth 2.0 for API authentication. They use bearer tokens without nonces or timestamps. An attacker captures an access token via a man-in-the-middle attack on a public Wi-Fi network. The attacker replays the token to access the API and exfiltrate user data. The API server logs show multiple identical requests from different IPs with the same token. The correct response is to implement token binding (e.g., include client IP or use mTLS) and short token lifetimes. The developer should also use OAuth 2.0 Proof Key for Code Exchange (PKCE) to prevent authorization code interception. A common mistake is to rely solely on TLS, which protects against interception but not replay if the attacker already captured the token. The analyst should implement rate limiting and anomaly detection to flag repeated token usage.

An attacker captures a valid DNS query for a legitimate domain and replays it to a recursive resolver, hoping to poison the cache with a forged response. The resolver checks the DNS ID (a 16-bit random number) to match queries and responses. The attacker must guess or capture the correct ID. With a captured ID, they can replay the query and inject a spoofed response. The correct defense is to use DNSSEC (RFC 4033-4035) to authenticate responses and enable source port randomization (RFC 5452) to make replay harder. A common mistake is to rely solely on the DNS ID, which is only 16 bits and can be brute-forced. The analyst should monitor for unusual query/response pairs and enable BIND's rate-limit feature to mitigate replay.