Posts: 19
Threads: 6
Joined: Jul 2017
04-04-2020, 03:57 AM
(This post was last modified: 04-04-2020, 04:01 AM by fromdusktillpwn.)
What are indirect ways to tell if PSK has been changed since the time we captured handshake? Any side-channel signs maybe?
For example, failed eapols with stations known to previously successfully connect to particular access point could service as one of such markers. Although this one is pretty direct (as much as probabilistic) but it can be utilized in automated way to inform Charlie that he should maybe update capture and start over.
Anything else? Could be implementation-dependant, any knowledge appreciated.
Posts: 1,011
Threads: 2
Joined: Jun 2017
04-04-2020, 08:18 AM
(This post was last modified: 04-04-2020, 08:21 AM by ZerBea.)
If the old PSK is known, hcxdumptool --weakcandidate will do that. No alert == PSK changed.
If the old PSK is known, you can use hcxpcapngtool --all option to identify PSK changes.
If ESSID and PSK changed, hcxdumptool will notify you (M1M2RGOGUE). Now compare M1M2RGOGUE results with M2M3 or M1M4 or M3M4 results.
BTW:
We must assume, that if the PSK changed by admin, authorized users will change their PSK, too.
Posts: 19
Threads: 6
Joined: Jul 2017
No, I'm talkink about unrevealed PSKs, some long-runners that might be out of date by the time Charlie finally reveals em. Same ESSIDs.
(04-04-2020, 08:18 AM)ZerBea Wrote: We must assume, that if the PSK changed by admin, authorized users will change their PSK, too.
I understand that. Still a legit technique tho in case you able to capture air on 24/7 basis (or close enough). As soon as Charlie sees series of M12' from one or several known stations followed by full M1-4 it's quite safe to say that Charlie should cut his losses, mark resources spent on old PSK as wasted, capture new eapol and start over (I assume he needs access and does not need ability to decrypt old traffic).
It's been proven to work but has obvious flaws so I'm fishing for new signs to raise red flags in my home-brew notification system. I mentioned side-channel approach since I do believe there is nothing to score within hasdshake per se (which I also might be wrong about). I dunno... some known implementation flaws, proprietary extensions, another behavioral patterns, anything even remotely related that could be recorded and utilized to raise warning.
