I'm trying to wrap my head around the WPA/WPA2 4-way handshake in an attempt to determine if it is possible for a rogue wireless access point to retrieve a plaintext (or hashed) version of a router's password that is delivered via a legitimate authentication form prompted by a client's native OS. I have plenty of experience capturing handshakes and cracking them in different pentesting scenarios, but I'm interested in exploring the following scenario:

  1. A rogue honeypot router responds to an STA probe request (w/ probe response or beacon). This honeypot initiates the WPA/WPA2 authentication process.

  2. The client, believing the AP to be a known network, tries to connect, but is initially rejected because the WPA/WPA2 password does not match the password for the true router. For all the client knows, the network is the same, however the administrator has changed the password. A native OS auth form is presented to the client by the OS/Network Manager (likely with a password pre-filled). The client submits the password to the honeypot network that is using the temporary SSID of the trusted network.

  3. ???. Is it possible for the honeypot, which is presenting the STA with a legitimate authentication requests (using any arbitrary WPA password on the router) to view the plaintext version of the password that was sent by the STA in an attempt to authenticate? If not, in what format is this password presented to the AP for authentication?

I'm interested in learning the current options (cli/tools) for this kind of phishing attack (again, relying entirely on a naive OS WPA authentication form, not a captive portal type HTML phishing page). If none exist, I'm curious if WPA/WPA2 would even allow for the scenario described in the above steps to occur. I'm a very comfortable programmer and am willing to patch Hostapd or use libpcap to implement this kind of functionality if need be. I just am having trouble determining if this type of attack is even possible.

1 Answer 1


I would recommend you to understand the four-way handshake of WPA/WPA2 first. The resource in your linked question is very detailed, but the Wikipedia article should also give you an adequate understanding of the process.

It is not necessary that the user inputs the password in the native OS authentication form. If a client finds a network he knows, he automatically try to connect to it. (This is the normal behavior of most clients.) After the association, the four-way handshake is started. Even if the Access Point have a different PSK than the client (e.g. is a rouge honeypot router), the first two messages will be exchanged, because only with the third step the client can verify that the AP has the same PSK. But an attacker needs only the first two messages of a handshake to perform a brute force attack on the PSK. There is a tool for cracking half-way handshakes available on GitHub.

The OS authentication form is an implementation detail of the client (e.g. Windows). The client recognizes with the third message of the handshake, that the AP is using a different PSK and allows the user to input a new password, in case he has changed it recently in his router. If he does this, the client will associate with the AP again and try to perform the four-way handshake. There is no advantage for the attacker, if the user does reenter the password. In no case the PSK will be sent in plain text.

You must log in to answer this question.

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