Fluxion: Handshake snooper not capturing handshake

[s4iya]

Do you want to request a feature or report a bug?

Bug

What is the current behaviour?

Handshake snooper does not capture handshake, injection is working, several devices are connected to the AP, deauth is working.

What do you think the expected behaviour should be?

Capturing handshake

Specs

FLUXION Info

FLUXION V4.8

BASH Info

GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Path: /bin/bash

Interface (wlp2s0mon) Info

Device: phy0
Driver: iwlwifi
Chipset: Intel Corporation Wireless 3165 (rev 81)
Master Modes Yes
Injection Test: Injection is working!

XTerm Infos

Version: XTerm(322)
Path: /usr/bin/xterm
Test: XServer/XTerm success!

HostAPD Info

hostapd v2.4
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2015, Jouni Malinen [e-mail] and contributors
Path: /usr/sbin/hostapd

Aircrack-ng Info

Aircrack-ng 1.2 rev 237e361 - (C) 2006-2018 Thomas d'Otreppe
https://www.aircrack-ng.org

Pyrit Info

Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Scapy Version: 2.3.3

System Info

Chipset: Linux version 4.15.0-15-generic (buildd@lcy01-amd64-018) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)) #16~16.04.1-Ubuntu SMP Thu Apr 5 12:19:23 UTC 2018

Linux Mint 18.3

[MPX4132]

Considering the fact we've got people reporting the same thing, and the fact we haven't changed the attack's deauthentication or capturing, I can only guess there was an update to either the wireless hardware's driver, or airodump-ng. I think it's more likely it was to the driver, but I'm not sure. You can check if the captor still works by running it in monitor mode only, so instead of using deauthenticator, just choose the "monitor" option. It'll take longer, but you'll verify it does in fact work.

[MPX4132]

@s4iya are you selecting an interface for target tracking?
If you are selecting an interface for target tracking, answer the following questions:

• Which interface did you select for target tracking?
• Which interface did you select for monitoring?

[djmeero]

@MPX4132 sorry for off topic.. I won't open a new thread for this... just a question...how can I start the portal and continue the atttack if the target cloaked the ESSID ? (I've got the probe request with the ESSID)

[MPX4132]

@djmeero You're going to need another type of attack for that man. I think you can just use airodump-ng and it'll de-cloak the ESSID if a client is connected to it.

[djmeero]

Yeah I've got the ESSID from the scanner...can I start the portal specifying the ESSID ? Or it's no way around it?

[MPX4132]

@djmeero Yes, you can start it with the ESSID, but you MUST also specify the BSSID and channel:

./fluxion.sh -b XX:XX:XX:XX:XX:XX -e "SECURITY BY OBSCURITY SUCKS" -c N
# or the following with long options
./fluxion.sh --bssid=XX:XX:XX:XX:XX:XX --essid="SECURITY BY OBSCURITY SUCKS" --channel=N

[djmeero]

Yes, perfect, thank you.

[s4iya]

So after discussing with @MPX4132, skipping the target tracking in combination with cowpatty and no special parameters passed to fluxion, I was able to capture the handshake.

[vishalkhanal]

Hlo s4iya can you give your output of iw list.
And does your adapter disconnect user from real ap at last step not during handshake.