A replay attack happens when a hacker records and replays secure communication between two legitimate sources. While this may sound like a man-in-the-middle attack, replay attacks are a distinct, less complex form of the typical man-in-the-middle approach. That's because it doesn't require that the hacker breaks into anything to get credentials.
It's just a repetition of raw data, captured and replayed to fool the security measures on a resource. To understand how a replay attack works, we first need to go over the typical way in which a legitimate data transaction works between two network devices.
Typically two devices communicating securely over a computer network have ways in which to verify their identities. For example, when you log into a website, you provide a username and password. These credentials tell the server that you are who you say you are. Once that's established, you can access the information stored on your behalf freely.
In most cases, your username and password aren't stored on the target server. Instead, the server has a "hash" of your password. A hash is a mathematical function performed on the text string you use as a password. When you type in your password, the hash function is performed on the text, and the new and old hash are compared. If they match, you're in!
On top of this, the connection and all of the data that passes through it will usually be encrypted. Typically through HTTPS. These are incredibly tough security measures. Which a replay attack completely sidesteps by simply copying and replaying the authentication portion of the original message wholesale.
Man-in-the-middle attacks work because network packets often have to travel through devices and network hardware that don't belong to either the sender or the receiver. Alternatively, the attacker can simply position themselves between the two communicators, intercept the message and pass it on with modification.
In a replay attack, the idea isn't to intercept and modify the originating message for your own purposes. Instead, the attacker simply eavesdrops, recording every bit of data. There's no need to break the encryption or understand anything within the original message. The trick is to figure out which part of the encrypted message is the "handshake," where credentials are asked for, and then simply replaying that before adding your own instructions once authenticated.
In this way, you can access networks and services or repeat financial transactions but with changed amounts and destinations. This sounds too easy, right? Well, the good news is that replay attacks are a well-known issue, and there are various ways they can be mitigated.
The crucial mitigation for replay attacks is to establish whether a message is original or a replay. There are different ways of doing this, but the most common is a randomized session key.
What this means is that the sender and receiver agree to a unique random session number when they originally have their exchange. When the exchange ends, that session key can't be used again, so if a replay attack using the same key is attempted, the receiver knows it's not legitimate.
There's an even simpler way to combat replay attacks. Messages should simply have timestamps built into the transmission. Since the attacker doesn't know what's in the encrypted data, the replay will include exactly the same timestamp as the legitimate sender's original message - which clearly flags it as a fraudulent message.
While mitigations for general replay attacks are standard these days, it doesn't mean this attack vector is dead in the water. Replay attacks can still be effective when combined with specific vulnerabilities.
The biggest recent example was the 2017 KRACK attack, which punched a hole in the WPA 2 security protocol used by virtually every WiFi device on the planet. The only reason KRACK wasn't as serious of a problem as it could have been, but thanks to the short-range at which it works. It has since been patched.
More importantly, WPA 3 is set to replace WPA 2. That being said, new exploits are being discovered all the time. There will always be some sort of vulnerability that makes a replay attack viable.