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:
A rogue honeypot router responds to an STA probe request (w/ probe response or beacon). This honeypot initiates the WPA/WPA2 authentication process.
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.
???. 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.