Sorry for such a simple (ignorant) question, but I can't seem to find the answer.
Does the client store and publish the PMKID, or just the AP? In other words, can I gather PMKIDs from a nearby client that has been previously connected to various APs?
(09-24-2019, 11:19 PM)slawson Wrote: [ -> ]
Does the client store and publish the PMKID, or just the AP? In other words, can I gather PMKIDs from a nearby client that has been previously connected to various APs?
Essentially you can obtain the PMKID from either the AP (clientless) or the client just like a 4-way handshake. Both will yield the same results. You cannot gather additional APs PMKIDs from a client from which it is not connected to.
Quick edit: So a client which is visible and connected to an AP which you do not have a signal too can still yield you the PMKID even with the AP NOT IN RANGE of your device.
We can take the PMKID from this frames (PBKDF2 hashcat hashmode 16800):
EAPOL M1 from access point (in this case we need one additional frame to get the ESSID: ASSOCIATIONREQUEST, REASSOCIATIONREQUEST, PROBERESPONSE, directed PROBEREQUEST, BEACON, where BEACON is the last choice we should use)
REASSOCIATIONREQUEST from client (in this case we need only one single frame to get needed information: ESSID + PMKID + MAC_AP + MAC_STA)
Additional we can take the PMKID from this frame (non PBKDF2 - AKM defined authentications: FBT, EAP-SIM, EAP-AKA, ...)
AUTHENTICATION
BTW:
The most important frames in combination with EAP/EAPOL are:
ASSOCIATION + REASSOCIATION
AUTHENTICATION
BEACONs contain less(!) informations!
So it is definitely not(!) a good idea to store only one BEACON and one frame M1 for PMKID or two frames M1/M2, M2/M3, M1/not zeroed M4 or M3/not zeroed M4 for EAPOL 4way in a pcapng, pcap, cap file!
Thanks for the info. You have a very good understanding of how all of this works.
Only superficially - I'm still wrestling with Diffie-Hellman.