1

I'm using airgeddon (https://github.com/v1s1t0r1sh3r3/airgeddon) to perform a deauthentication attack on my wifi network.

When i put my wireless interface in monitor mode to scan the network from the outside I found the router's BSSID, which is 10:13:31:F1:48:8D, and then I tried to perform various deauthentication attacks on the network but all of them failed: my computer can successfully send packets but the network is not affected (since my other devices can access internet normally).

Then I ran Zenmap from inside of the network to check if my router's BSSID was correct and I found that all the devices connected to wifi shown a different BSSID for the router, which is: 10:13:31:F1:48:8C: the difference is in the last digit.

So I tried to perform the attack on the 8C BSSID manually (because it is not detected by airodump-ng) but the attack fails.

This is what I used for the attack:

aireplay-ng -0 0 -a 10:13:31:F1:48:8C wlp3s0mon

and the result is:

00:03:55 Waiting for beacon frame(BSSID 10:13:31:F1:48:8C) on channel 1
00:04:05 No such BSSID available.

using the channel 1 for the attack (the same attack works with 8D and channel set on 1).

There's a way to perform the attack on the correct BSSID?

Edit -------------------------

I've check if I'm currently injecting packets correctly , using

aireplay-ng -9 wlp3s0mon

and the output says Injection is working! Then I put the security measures of my router in "low mode" but the attack is failing again and again.

I tried to impersonalize another device using -s option but then I recive 0/64 ACKs while attacking computer or phones.

The only devices that seems to be vulnerable is a linux wifi printer which gives me 64/64 ACKs but i can't check easily if it's actually working.

2

Whilst very similar, the base station's BSSID isn't the same as its MAC address.

What you observe on your wireless scanning and deauth attacks are BSSIDs which correspond to individual SSIDs, usually very similar to the interface's MAC address only incremented by one per SSID *:8D, *:8E, ... Notice that each radio on a base station is its own interface, so there could be multiple BSSIDs per SSID.

Once associated and port scanning, what you are seeing is a kind of ethernet network and the base station presents itself as a layer 2 device with its own MAC address *:8C.

For your attack you should definitely target the correct BSSID, not the interface's MAC address.

Possible causes for the attack failing are:

  • Your interface is not injecting packets properly;
  • You could be injecting on the wrong channel or radio band;
  • Some access points have counter-measures against basic attacks like broadcast deauth, so you'll probably need to issue a deauth whilst impersonating the target connected client;
  • In case of enterprise deployments, multiple APs will triangulate your position and compare it to the location of the victim, and decide to ignore your deauth packets;
  • Protected Management Frames (802.11w IIRC) could be required by the AP;
7
  • 1
    A couple other reasons it failed: 1. Protected management frames are used 2. The attacker is transmitting on the wrong channel or band compared to the victim May 27 '20 at 23:07
  • thanks @multithr3at3d I've added these to my answer.
    – Pedro
    May 27 '20 at 23:17
  • thanks for the answers, @Pedro I've not fully understood the first part of the answer, can you specify the difference between BSSID and interface MAC? however I think I'm attacking on the right channel, I set it up using "airmon-ng start wlp3s0 1" which is the correct one, according to airodump. May 27 '20 at 23:21
  • I wouldn't know the theoretical relationship between the two values. But in practice, an attacker (unassociated) will see BSSIDs as the "wireless" MAC addresses of the base station. Comms from access point to clients have a source address of the relevant BSSID. If the AP has multiple SSIDs, then it will have one BSSID per SSID handled. Once on the network and port scanning, etc, you will not see BSSIDs but a single MAC address that identifies the access point at layer 2.
    – Pedro
    May 27 '20 at 23:26
  • 1
    I'm marking this as solution because I think my problem is the router's security protocol Jun 4 '20 at 18:40

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.