Deauthenticating a Client
We can use bettercap to force clients to reconnect to an access point
by deauthenticating them.
Deauthentication can be used to to capture WPA/WPA2 handshakes
or to have clients connect to our rogue AP.
In bettercap, we’ll deauthenticate clients by using the wifi.deauth command.
The command accepts a MAC address as a parameter where the value could be.
We have several choices here.
We can enter the BSSID of a particular AP
to deauthenticate all clients connected to that AP.
Alternatively, we can enter the MAC address of a client
to deauthenticate only that single client.
Finally, we can enter ff’s to deauthenticate everything.
For obvious reasons,
we want to be careful about when and where we use this last option.
We will start our wifi recon again on channel 6,
Our events stream settings will persist, however.
Let’s start by deauthenticating
all clients connected to the Corporate AP we discovered earlier.
By running wifi.deauth and passing in the BSSID of the Corporate AP,
we can observe that deauthentication frames were sent to three clients.
We might not always want to deauthenticate this many clients at once.
Let’s move forward and target a specific client by providing its MAC address.
By passing in the MAC address of a single client,
we are able to deauthenticate only that client from the AP.
This time, we were also able to capture a handshake for just the one client
as determined by the wifi.client.handshake message.
Wi-Fi handshakes will be saved to the file configured
in the wifi.handshakes.file parameter.
If we capture multiple handshakes for different networks,
they will all get aggregated into a single file.
It’s possible to change both of these settings, saving files in a new location
and saving each network’s handshakes into a separate file.
We turned off recon mode
to make sure we’re able to make the appropriate changes.
Next we used the get command,
to obtain the current setting of the wifi.handshakes.file parameter.
Since we’re running bettercap with sudo, the home directory is /root/.
Using the set command,
and the wifi.handshakes.file parameter,
we change the location of the pcaps to our home directory.
In order to instruct bettercap to output 4-way handshakes to a folder,
we set the wifi.handshakes.aggregate parameter to “false”.
Finally, we turn wifi.recon back on and run the deauthentication command.
The handshake is saved and the filename is prepended with the SSID of the network.
Up to this point, we have been using MAC addresses of clients
and APs that were previously discovered by bettercap.
If a MAC address has not been previously discovered,
bettercap will not allow us to run a deauthentication command.
The output mentions a “deauth skip list”.
The skip list is a series of MAC Addresses that we do not want to deauthenticate.
We can edit the list by setting wifi.deauth.skip
to a comma separated list of client or AP MAC addresses.
To demonstrate this,
we will add the AzureWave device to our skip list and then deauthenticate
all clients connected to the Corporate AP.
The Hon Hai and LG devices were deauthenticated,
but the AzureWave device was not.
In addition to the wifi.deauth.skip parameter,
the wifi.deauth command also reads
from the wifi.deauth.acquired,
wifi.deauth.open,
and wifi.deauth.silent parameters.
The wifi.deauth.acquired parameter,
is set to false by default and will prevent bettercap from sending
deauthentication packets if the handshake has already been captured.
The wifi.deauth.open parameter
is set to true by default and instructs
bettercap to send deauthentication packets to open networks.
The wifi.deauth.silent parameter, is set to false by default and,
if set to true,
will instruct bettercap to hide the deauthentication messages in the terminal.
Now that we have an understanding of the actions we can take using bettercap,
let’s review the additional user interfaces that bettercap implements.