Discovering APs
The wifi.recon command will start the Wi-Fi module
and allow us to discover nearby APs.
By default,
bettercap will hop on every supported channel.
We can start the recon command by passing on as an argument.
At this point,
each client probe and AP discovered will be written to the event stream buffer,
which is displayed to the screen.
Since bettercap is scanning all channels,
we might find it useful to limit that.
We’ll do this by running the wifi.recon.channel command,
and passing in a comma-separated list of channels that we would like to scan.
bettercap is now set to only hop on channels 6 and 11.
This will limit the number of APs and clients we will discover.
If we want to clear this filer at any point,
we would pass in the string “clear” instead a commaseparated list of channels.
Even after limiting reconaissance to specific channels,
we may find the alerts to be distracting.
The events core module is useful for limiting this output.
These wifi specfic commands will filter out most alerts.
The events and stream submodule can turn on and off alerts completely.
bettercap supports tab completion, which can make things a bit easier for us.
Typing wi into the interactive shell,
and pressing the tab key,
will autofill the Wi-Fi module and add the trailing period.
Pressing tab again,
will display all the available modules or commands within a module.
We can use the tab completion to complete the wifi.show command,
which will list the discovered wireless stations.
Excellent!
The wifi.show command displays the four APs we discovered:
guest,
WuTangLan,
Corporate
and dot11.
In addition to the SSID,
Encryption and BSSID,
the table also shows RSSI
the Received Signal Strength Indicator,
the version of WPS (if supported),
the channel,
number of clients,
the amount of data sent,
and received,
and the last time the AP was seen.
Using the ticker module in bettercap,
we can periodically execute multiple commands.
Instead of manually running wifi.show when we want to inspect the table,
we can use a ticker to clean the output and show the table.
The set command is used to configure the commands parameter
within the ticker module.
The parameter is configured to a string that will execute clear,
and then display the table using wifi.show.
The default refresh interval is one second.
If we need to,
we can change this by setting the ticker.period parameter,
to the amount of seconds bettercap should wait before rerunning the ticker commands.
Once the ticker.commands parameter is set,
we will use ticker on,
to start the ticker module.
As a side note,
we can also run commands as soon as bettercap starts
instead of using the interactive session.
To do this,
we would use the -eval argument with a string of commands that we want to run.
For example,
this command will automatically start the ticker
to display the discovered APs on channels
6 and 11
and with the message alerts off to keep our output clean.
Once bettercap has collected enough data,
we can stop the execution of the ticker
by running ticker off.
To display the final list,
we will use the wifi.show command again.
At this point,
we may want to sort and filter the output.
For example, if we want to target the AP with the most clients,
we can sort the table by the Clients column.
We do this by setting the wifi.show.sort parameter to “clients”,
and passing in “desc” to sort the results in descending order.
As displayed, WuTangLan is on top with seven clients,
followed by Corporate with three clients.
We can also set the wifi.show.filter parameter,
to WPA2
to display only APs with WPA2 encryption.
The filter parameter accepts a regular expression
and will apply the regex to the BSSID,
SSID and Encryption.
Now only the WPA2 encryption type is displayed.
To clear the filter,
we can set wifi.show.filter to an empty string.
Now that we have a list of WPA2 APs,
let’s take a look at the clients connected to an AP.
In order to list the clients,
we will use a BSSID with the wifi.recon command.
We provide the BSSID of the Corporate AP
to the wifi.recon command.
When we run wifi.show,
the clients of the Corporate AP are displayed.
While the column for the client MAC addresses is labeled BSSID,
this can be misleading.
BSSID references only the MAC address for APs and not the clients.
We can also filter the client list using the same commands.
For example, we can use the following command to display
only clients with a MAC Address starting with “dc”,
Again, we will clear the filter.
We’re also able to filter clients, and APs,
by their signal strength
by setting the wifi.rssi.min parameter.
By default,
this parameter is set to “-200”
but we’ll try setting it to “-59”.
We will reset the signal strength to the default.
To exit the client view,
we can pass the clear argument to wifi.recon.
If we want to delete the APs and clients discovered,
we could run wifi.clear,
Or to stop the recon altogether,
run wifi.recon off.
The following parameters are useful for formatting the Wi-Fi table.
wifi.show.limit,
adds an upper limit to the number of clients or APs displayed.
The integer we enter will be the maximum number.
Entering “0” will disable the limit.
wifi.show.manufacturer,
adds an additional column to the table
listing the manufacturers of the wireless device.
It is set to “false” by default.
wifi.sta.ttl,
is how long bettercap should wait before marking a client as disconnected.
It is measured in seconds and the default is 300 or five minutes.
wifi.skip-broken,
instructs bettercap to skip 802.11 packets with invalid checksums.
The default value is true.
Now that we have a good list of the clients and APs in our area,
let’s learn how to deauthenticate a client.