Just as the title states. We've had an alert for a replay attack being detected, how would I investigate this? It's the first alert of this type I've seen, so I'm unsure how to proceed.

  • Was the attack successful? If so, the reason might be that there is no/insufficient forward secrecy in the crypto scheme used. Normally, updating to a secure protocol version would fix that. Commented Nov 25, 2019 at 16:34
  • potential duplicate, but the answer might not suffice: security.stackexchange.com/questions/194223/…
    – schroeder
    Commented Nov 25, 2019 at 20:00

1 Answer 1


I snagged this potential answer from Reddit which linked to an article at ITProToday:

”When the Kerberos logic on a DC or resource server validates a Kerberos authentication message, it will always check the authenticator's timestamp. If the timestamp is earlier or the same as a previous authenticator, the server-side Kerberos logic will reject the packet because it considers it part of a replay attack and user authentication will fail. The Kerberos server-side logic also compares the timestamp in the authenticator to the local server time. If the timestamp in the authenticator isn't within five minutes of the time on the server, it will also reject the packet. These five minutes are referred to as the Kerberos time skew.”

I would start by having the local time checked on that remote host. Then any issues on the vpn infra. Apparently this type of attack grants nothing for the attacker so it most likely is not an attacker but a misconfiguration.


So, your first step should be to determine if this is a "true positive" by ruling out potential configuration issues while also analyzing your Domain Controller logs.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .