1

I am trying to understand a common "problem" when injection deauthentication frames in 802.11 networks.

My goal is to cause a client to re-authenticate (like one would do, to capture a 4-way-handshake) I do not want to cause a DoS.
Theoretically I would only need to send one fake deauth packet to do this. But when I send out a single deauth packet, nothing happens. Even with 10 or 20 packets I rarely get a re-authentication from the victim.
Aireplay-ng uses 64 packets with default settings, this number seems to work good for me as-well.

My main question now is:
Why does an attacker need to send so many fake frames, when a real AP only needs one frame to get the job done?

My test-setup is as follows:

  • Acces Point:
    • inksys wrt1200ac (openWRT)
    • Channel 11, WPA2, "legacy" mode (no 802.11n)
  • Clients:
    • ESP32
    • Android Smartphone
  • Atacker:
    • Kali VM (running on a MacBook Pro(macOS catalina)
    • ALFA AWUS036NHA
  • No traffic or other devices on the test-network

The network is only used for my testing.
The general RF-space is probably as crowded as in a normal tech enthusiasts home: Bluetooth, ZigBee, 2.4 and 5 Ghz Home-WiFi + neighbors

  • A real AP knows when to send the frame so it doesn't get clobbered by other traffic. – user Jun 8 at 13:58
  • @user are you talking about RTS/CTS? – multithr3at3d Jun 8 at 15:05
  • I also thought about RTS/CTS and CSMA/CA in general, but shouldn't my adapter handle all this for me? – NIoSaT Jun 8 at 15:59
  • Not sure about the latter, but I haven't really seen RTS/CTS in use in the wild. – multithr3at3d Jun 8 at 16:38
0

It could be a layer 1 (physical layer) problem.

It could just be that the victim is receiving too many frames and drops yours, or perhaps the frame doesn't make it all the way to the target (obstacles, interference).

Or, maybe your system isn't staying on the same channel the whole time. If you are transmitting on different channels than the target device, it will not work at all, and if you are hopping channels, it will only work some of the time.

| improve this answer | |
  • My test setup is fairly isolated, as far as that is possible with WiFi ;) Victim, AP and attacker all sit on my desk, so all packets should physically reach their destination. My test-network only has one/two clients, and there is no traffic on the network. So the client should not drop any of my packets. There are no other networks on the same channel. As far as I can tell my attack-adapter should stay on my configured channel. – NIoSaT Jun 8 at 15:42
  • If you have the ability, put the target into monitor mode, and see if it receives the deauthentication frames. Or at least, put another interface in monitor mode on the correct channel to observe that the frames are sent. You could even run wpa_supplicant in debug mode on the target, and see what is going on there. – multithr3at3d Jun 9 at 0:09
  • I did the latter, I was able to see my deauth packets on another laptop using another ALFA adapter in monitor mode. When I sent out a single deauth I could see it, plus several retransmits of the initial packet. I used Wireshark to look at the packets. When I sent out multiple packets I would see one packet followed by several retransmits then a "new" packet followed by several retransmits. When one packet did "work" I saw additional packets between AP and victim. So I would say, the packets get sent and "physically" reach their target. – NIoSaT Jun 9 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.