A replay attack—sometimes referred to as a session replay attack—is a type of network-based threat where a malicious actor intercepts a legitimate data transmission (such as a login request or payment authorization) and maliciously resends it later to trick a system into performing an unintended action.
Unlike traditional attacks that aim to decrypt or alter data, replay attacks exploit the fact that systems often fail to verify timing, uniqueness, or context of a repeated request. Because the replayed message is technically valid, the system might process it as if it were new.
These attacks are particularly dangerous in stateless communication environments, such as RESTful APIs, IoT devices, or services lacking robust session controls.
How a Replay Attack Works
- Capture: The attacker intercepts the data in transit – this could be a token, session code, or a signed request.
- Delay: The data is stored and then resent at a later time.
- Execute: The receiving system accepts the duplicated request if it lacks protections like timestamp checks or nonces.
Attack vectors are the specific paths or methods an attacker uses to gain unauthorized access to a system or network. In the case of replay attacks, these vectors often involve weak or missing validation checks in communication protocols.
- Man-in-the-middle (MITM) setups that capture data over unsecured or poorly configured HTTPS.
- Token-based systems that do not expire tokens or bind them to specific sessions/devices.
- Legacy authentication systems that fail to validate session freshness.
Types of Brute Force Attacks
- Simple Brute Force Attack: Attempts every possible character combination – effective, but slow.
- Dictionary Attack: Uses a pre-built list of common or leaked passwords. This method is faster and often more successful.
- Hybrid Brute Force Attack: Combines a dictionary list with common character substitutions (e.g., “password” → “P@ssw0rd”).
Prevention Strategies
Replay attacks can be mitigated by verifying the freshness, uniqueness, and authenticity of each request. Strong session and message validation is key.
- Nonces: Attach a one-time, random string to each request. Replays are blocked when the same nonce is reused.
- Timestamps: Include timestamps and reject requests that fall outside a short validity window (e.g., 30 seconds, 1 minute).
- Token Binding: Link tokens to a specific session, IP address, or device to prevent reuse in other contexts.
- Message Authentication Codes (MACs): Use cryptographic signatures to detect tampering or replay.
- TLS Encryption: Secure communications with TLS to prevent data interception.
- Duplicate Request Rejection: Track and reject repeated request IDs or tokens.
These controls are especially important in financial services, API endpoints, and IoT environments where trust in each request is critical.
