Close Widget

By Luke Potter, SureCloud Cybersecurity Practice Director 



On the 16th October 2017 there were several vulnerabilities in the WPA and WPA2 protocols that were publicly disclosed by security researcher “Mathy Vanhoef”. The impact of an attack against these vulnerabilities can result in a nearby attacker being able to decrypt wireless network packets, and in some cases inject into the network traffic on the wireless network directly. This would mean that in some cases an attacker could potentially intercept and manipulate requests to sensitive websites with an aim to capture the credentials.

At the point of this public disclosure there were few vendors that have released security patches to resolve these vulnerabilities, with many vendors and package maintainers aiming to release these critical security updates in the coming weeks.

SureCloud will continue to update this article with updated information as/when further developments are known.


  • Detailed information about the vulnerabilities and the exploit has been released, and is available within the vulnerability whitepaper or on the author’s purpose-built website.
  • Exploit code has not yet been released, but the author will be releasing tools that can be used to detect vulnerable clients.
  • Exploitation requires an attacker to be in range of both the wireless client device and the wireless access point.
  • The vulnerability affects clients directly, not wireless access points.


Impact and Mitigation

As briefly mentioned within the introduction, the ultimate impact of this attack being successfully exploited would allow an attacker the ability to decrypt WPA/WPA2 wireless traffic. This essentially would mean that any cleartext network traffic could be viewed as if the attacker were on the same network as the victim. However, this does not necessarily mean that traffic encrypted through a VPN (Virtual Private Network) or secured with HTTPS is directly affected.

The proof of concept video that Mathy has released shows an example where a victim visiting ‘’ is targeted with an additional exploitation layer using ‘SSLStrip’, whereby the victim is downgraded on to a plaintext HTTP connection. This is of course a very real scenario that could happen in the wild, and although the control of security over third-party webservers is not possible, a mitigation that SureCloud would highly recommend would be to ensure that any client devices are using a secure VPN to connect through wireless networks until security updates are available and can be deployed to these devices.

For organisations or individuals offering websites and applications, mobile apps, etc. SureCloud would recommend reviewing the current configuration of these services and ensuring that cleartext protocols and downgrade attacks are not possible. Providing secure services is an aid in mitigation for these attacks.


Security Updates and Patching

Certain vendors were aware of this vulnerability as early as the 14th July 2017, being tested by Mathy directly as part of this research. The extent of which vendors were notified is unknown, but a broad notification was sent to vendors by CERT/CC on the 28th August 2017. As such, there are several vendors that have already released security patches for this vulnerability, with some silently releasing the security updates prior to this public disclosure.

Microsoft and various Linux distributions have claimed to have released updates for their operating systems. Google are expected to release Android patches in the immediate days and weeks following the public disclosure, whilst other vendors will need checking with directly. Unfortunately, there will likely be a large range of IoT (Internet of Things) devices, legacy mobile phones, and other unsupported devices that will never be patched.

The following links will be updated as the security updates become available for most mainstream/common platforms:

A full breakdown of affected vendors and their date of notification can be found here at the vulnerability notes database.


Vulnerability Scanning and Detection

For customers that utilise the SureCloud internal scanning appliance, we will be offering the ability to check for these security updates when performing an authenticated vulnerability scan once the patches have been made publicly available. Several checks, such as Microsoft’s security update, are already available within the SureCloud Platform and are automatically included within the default vulnerability scan configuration settings. A specific scan for the Microsoft patches has been developed and is available when creating new scans. Further details on configuring an authenticated scan for internal assets can be found within our user guide within the Platform’s Support section.

Technical Breakdown

The flaw identified by Mathy that allows this attack to be performed is within a specific part of the WPA/WPA2 protocol that is broadcast during the initial connection to a wireless access point. When a client is authenticating to a wireless network, the access point (AP) and client exchange a 4-way handshake that mutually assures that each device has the appropriate secret key, and then establish an encrypted channel for further communications.

To understand the vulnerability from a technical level the diagram and description below provide an overview of this 4-way TCP handshake:

Note: STA refers to the wireless client, AP refers to the Access Point.

  1. Before the negotiation starts, both sides calculate the “Pairwise Master Key” (PMK) using the Passphrase and SSID.
  2. The AP first sends a nonce (ANonce in the diagram) to the client.
  3. The client then uses this nonce, in combination with its own nonce (SNonce) and the PMK to generate the “Pairwise Transient Key” (PTK)
  4. The client then sends the SNonce to the AP with a Message Authentication and Integrity Code (MIC) to prevent it being tampered with. The MIC is generated from the PTK.
  5. The AP then builds the same PTK for itself, and sends one final “Group Temporal Key” to the client.
  6. The client “installs” the PTK and GTK, which brings them into use and the AP installs the PTK.
  7. Finally, the client acknowledges the handshake and the handshake is complete.

The client will hold a single PTK for each wireless network it is actively connected to, so in most cases just one. The AP will hold a different PTK for each of the connected clients.

The Pairwise Transient Key (PTK) Sometimes called the “Session Key” breaks down into the following parts:

  • Key Confirmation Key
  • Key Encryption Key
  • Temporal Key
  • Message Integrity Code (MIC) Authenticator Transmit Key
  • Message Integrity Code (MIC) Authenticator Receive Key

Each of these keys has a difference usage within the WPA protocol, but the main one that is affected is the “Temporal Key”, which is the key-part that is used to encrypt the Wi-Fi traffic, or to be more specific, the non-broadcast Wi-Fi traffic. The Group Temporal Key (GTK) is used in a similar way to encrypt broadcast and multicast traffic.

There are also other handshakes too; while the GTK is initially transferred during the first 4-way handshake as described above, it is independent of the PTK and is updated with a separate handshake, which will be explained further below.

To be able to leverage these vulnerabilities to attack a client device an attacker would need to be present during the 4-way handshake, which is only performed when first connecting to the wireless network’s access point. However, an attacker can force this by sending de-authentication packets to the client device, which will effectively forcibly disconnect the client from the wireless network, resulting in the client and access point performing another 4-way handshake. This technique is typically used when attempting to capture the handshake for wireless network attacks against PSK networks.

When an attacker is present during the 4-way handshake, it is possible to replay message 3, which is where the GTK is transmitted. This causes the PTK to be “installed” again (or “reinstalled”), which means while the same PTK is used various associated counters and nonce values that have already been used are re-used again. These values being used a second time means the keystream is reused when encrypting network traffic. If a message that reuses this keystream has known content, such as the predictable words found in HTTP headers, then it becomes trivial to derive the keystream. This keystream can then be used to decrypt messages with the same nonce. If there is not a source of predictable underlying content, the decryption does become harder, for example if the target is exclusively using a VPN. But if the target is using a VPN, successful exploitation would still not defeat the protections of the VPN.

With Android 6.0 and WPA Supplicant 2.6 an additional bug can be triggered where the Temporal Key within the PTK (part used to encrypt the network traffic) to be set to all 0’s, thus rendering the entire stream trivial to intercept or inject into. This requires also forging message 1 within the 4-way handshake, as well as retransmitting message 3.


This is no doubt the most critical vulnerability found within the WPA/WPA2 protocol, with the vulnerabilities affecting every computer or wireless-enabled device across the world. Security patches are being released quickly by many vendors; however, we expect to see this vulnerability present in IoT devices for years to come. One of the mitigating factors for this particular flaw is that Windows and iOS devices are slightly less affected in comparison to Android, Linux, MacOS, and OpenBSD. With Windows being one of the lesser affected systems, the fact the attack works on WPA2 Enterprise is made somewhat less dangerous. In conclusion, blue teams and individuals should look to patch as soon as possible as the exploit tools will likely be available in the next few days or weeks.



Vulnerability Notes Database:

KRACK Attack Website:

KRACK Whitepaper:

How can we help?