In 2017, research performed by KU Leuven university uncovered a significant weakness in the IEEE 802.11's WPA2 protocol to attack and intercept cleartext data from a perceived encrypted channel. The weakness and novel attack method was dubbed the key reinstallation attacks or KRACK for short.

https://www.krackattacks.com/

Most vendors have created updates that remediate the ability to be impacted by KRACK attacks. While AIRSHIELD cannot directly identify the installed operating system versions of every device it does look for signs of a potentially vulnerable device. Our detection method monitors the 802.11 frames and looking for repeated message 3 of the 4-way handshake.

From the researchers:

Key reinstallation attacks: concrete example against the 4-way handshake

As described in the introduction of the research paper, the idea behind a key reinstallation attack can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.

AirShield looks for the re-use of nonces in message 3 and will generate KRACK identified events if found. Due to the way the 802.11 4-way handshake works we may sometimes observe this activity when both client and AP have been patched. It is also possible some frames may be re-transmitted or reflected off building materials in some edge cases.

I'm Observing KRACK Events; Am I Still Vulnerable Today?

The existence of KRACK events by themselves do not directly identify a vulnerable Access Point or Client, only the observation of repeating NONCEs in collected 802.11 frames. Should a regularly repeating KRACK event between a specific Client and an Access Point be observed it may indicate the Client device has not been updated and could be vulnerable.

As of 2025 this vulnerability is 8 years old with nearly all vendors having provided software/firmware updates. The likelihood of a recently deployed AP or Client to be vulnerable is low.

Adding Not In Filters

 If you are using an Event filter on the primary dashboard you can add a NOT IN filter on event-based rules. As an example:

This will ignore KRACK events for any AP that is in the Trusted or Semi-Trusted Trust Level. 

Resource Links

• https://www.kb.cert.org/vuls/id/228519

• CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
• CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
• CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
• CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
• CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
• CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
• CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
• CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
• CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
• CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.