Fixed channel mon0

[Snayler]

1. Same room
2. Yes there is at least one client connected to the target router.
3. Alfa AWUS036H

Ok, I see no problem there. The card is the same model as mine, and mine works flawlessly.
Next step would be to fire up wireshark and connect your client to your router (manually). The handshake should appear on wireshark. If that happens, it could mean there's some problem with aireplay's deauthentication process.

[lucid]

Ok, I see no problem there. The card is the same model as mine, and mine works flawlessly.
Next step would be to fire up wireshark and connect your client to your router (manually). The handshake should appear on wireshark. If that happens, it could mean there's some problem with aireplay's deauthentication process.

I'm sorry I just got home from work and I can't think properly. I'm a little confused. You want me to fire up wireshark on the target computer or the attacking computer?

Again sorry.

[proxx]

Snayler talks about the attacking machine, you run wireshark on the monitor interface , to prevent clutter you could filter on client an AP's MAC.
You'll see the 4 way handshake as you connect the client to the AP.
After that try if you see that same handshake in airodump.
(You dont need aireplay for a handshake, just a connecting device.)

Ow yeah, this might sound like the stupidest thing you ever heard but dont put the stuff too close.
I had some trouble with that myself.
Try placing it just a couple meter away, not right next to each other.

[lucid]

Ok ok ok. I should really probably wait until I'm less sluggish in the brain to post on this thread but alas, I just can't wait. So I need to connect the attacking computer which is running wireshark to the access point? With an ethernet cable? God I'm tired.

[proxx]

Ok ok ok. I should really probably wait until I'm less sluggish in the brain to post on this thread but alas, I just can't wait. So I need to connect the attacking computer which is running wireshark to the access point? With an ethernet cable? God I'm tired.

No no no
You run Wireshark on the attacking machine, on the monitor interface.
Than you dont touch , just watch.

Connect the client to the AP.

Enjoy the show and see the handshake as it connects with the AP.

[lucid]

Yeah I had a feeling I was overthinking it. From the sounds of it I've already done that. I've ran wireshark on the attacking machine on the appropriate interface throughout the entire process. A client(not the attacking machine) is connected to the target AP.

I also set wireshark to filter for only eapol packets. So unless if that was the wrong packets then I'm seeing no handshake.

[Snayler]

Yeah I had a feeling I was overthinking it. From the sounds of it I've already done that. I've ran wireshark on the attacking machine on the appropriate interface throughout the entire process. A client(not the attacking machine) is connected to the target AP.

I also set wireshark to filter for only eapol packets. So unless if that was the wrong packets then I'm seeing no handshake.

You're missing the point. Launch wireshark on the attacking machine on the appropriate interface, then disconnect the client machine and connect it again (over wireless, ofc). Because that should produce the handshake you're looking for.

[lucid]

Sorry. I knew I shouldn't have been posting last night. Brain couldn't absorb what I was reading. Anyway..

I see the packets. As the client connects, I see on wireshark(from the attacking computer) two EAPOL packets from the client to the router. Something I noticed is that I only see this if the connecting client is in Windows.

I originally looked into it because I saw the EAPOL packets when I first booted into Windows. I did not see the same packets when I booted up Arch. Nor did I see those packets when I stopped and started the network interface. It only happens in Windows.

EDIT: I've also just discovered that when I send the deauth signal I see the handshake happen in wireshark on the attacking computer(when the client is in windows). Yet when I actually run aircrack it still tells me that there are no valid WPA Handshakes found.

I also just discovered that if I send the deauth signal to my iPhone  , I only see one EAPOL packet, and in the info it says message 4 of 4. Whereas the other EAPOL packets when deauthing Windows came in groups of two. The first one saying; 'message 2 of 4' in the info and the second saying; 'message 4 of 4'.

[proxx]

Sorry. I knew I shouldn't have been posting last night. Brain couldn't absorb what I was reading. Anyway..

I see the packets. As the client connects, I see on wireshark(from the attacking computer) two EAPOL packets from the client to the router. Something I noticed is that I only see this if the connecting client is in Windows.

I originally looked into it because I saw the EAPOL packets when I first booted into Windows. I did not see the same packets when I booted up Arch. Nor did I see those packets when I stopped and started the network interface. It only happens in Windows.

EDIT: I've also just discovered that when I send the deauth signal I see the handshake happen in wireshark on the attacking computer(when the client is in windows). Yet when I actually run aircrack it still tells me that there are no valid WPA Handshakes found.

I also just discovered that if I send the deauth signal to my iPhone  , I only see one EAPOL packet, and in the info it says message 4 of 4. Whereas the other EAPOL packets when deauthing Windows came in groups of two. The first one saying; 'message 2 of 4' in the info and the second saying; 'message 4 of 4'.

If you have half the handshake you have all the info you need for a cracking attempt.

[lucid]

Well, perhaps I just need to try different tools then. Or I'm just a huge idiot. Because despite that I see the handshake happen with my Windows computer and my iPoop, aircrack still tells me there are no valid WPA handshakes.

[proxx]

If you save the pcap file in wireshark you should be able to do a attacking attempt with aircrack.
Just make sure you put the word in the wordlist and do a quicky crack attempt.
See if that works, airodump is not always as reliable.

[lucid]

I'm not exactly sure why you're getting the issue. On my laptop it has never come across as a problem until now, however I do have an alternative for your needs which might allow you to actually crack wpa because it's with wash and reaver.

Code: [Select]

airmon-ng stop wlan3

airodump-ng wlan3

wash -i wlan3 -c <channel> -C -s

//don't think the next part will work if it's WPS Locked, didn't try yet

reaver -i wlan3 -b <BSSID> --fail-wait=360

Maybe this will work? Might also give some clues as to why the normal WPA cracking method is causing troubles with the channels.

I just tried using reaver. Did all the same steps. Changed wlan3 to monitor mode and forced it to channel 2, ran airodump-ng wlan3, copied the mac address and did NOT run any further aircrack suite commands. Then I just went straight to cracking the password with reaver. Seemed to work until it quickly got caught in a loop trying the same pin over and over. Will do some tweaking, and also try to identify using wash as well.

Using reaver seems a lot more straight forward then aircrack.

EDIT: Does aircrack-ng require the router to be using WPS like reaver does?

[proxx]

I just tried using reaver. Did all the same steps. Changed wlan3 to monitor mode and forced it to channel 2, ran airodump-ng wlan3, copied the mac address and did NOT run any further aircrack suite commands. Then I just went straight to cracking the password with reaver. Seemed to work until it quickly got caught in a loop trying the same pin over and over. Will do some tweaking, and also try to identify using wash as well.

Using reaver seems a lot more straight forward then aircrack.

Ive had a lot of completely weird issues with wash and reaver.
The PIN looping could be a protection from the router itself.
Manually tweaking the attempt speed often does the trick , some routers however are just not vuln to bruteforcing them this way.
I have a collection of aliases and some scripts that allow me to very quickly kill any services, switch channels etc etc etc.
Basically anything I need for messing with wireless.
Can higly recommend doing something similar, very useful , lot less frustration.

[lucid]

Ive had a lot of completely weird issues with wash and reaver.
The PIN looping could be a protection from the router itself.
Manually tweaking the attempt speed often does the trick , some routers however are just not vuln to bruteforcing them this way.
I have a collection of aliases and some scripts that allow me to very quickly kill any services, switch channels etc etc etc.
Basically anything I need for messing with wireless.
Can higly recommend doing something similar, very useful , lot less frustration.

I actually just figured out that neither of my routers use WPS... which is why it keep looping like that. So I guess there are downsides to go along with the upsides. Reaver seems to be a much simpler process, but it requires that the router is running WPS... and obviously not all routers do.

Really good idea about the scripts though. Sounds like a fun project to do too.