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.
A remote Kali instance has bettercap installed
and we will be browsing to it 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.
These commands will block all incoming requests.
The only allowed requests will be on port 443 and 8083
from our main Kali instance to our remote Kali instance that is running bettercap.
We open a terminal on our remote Kali instance.
This command initializes a table named “filter”.
This command will create a chain 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 to the IP address
of our attacking Kali instance on port 443,
and port 8083.
If the commands 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 the https-ui caplet on our remote Kali machine.
This is the same caplet that we will use to start the web interface.
On lines 2 and 3, the API server
is configured to run on all interfaces on port 8083.
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.
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 and 21.
We can run this caplet,
with a wireless adapter on our remote Kali machine,
and passing in https-ui to the -caplet argument.
The sys.log messages 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.
Lets run the bettercap UI on Firefox in our Kali machine.
Since the certificate is self-signed,
we will need to accept the certificate warning when visiting the page.
Once we click Accept the Risk and Continue,
we will be redirected to a login page.
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,
and browse to the API server,
and accept the self-signed certificate on port 8083.
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>/fp> caplet file.
Once logged in, a dashboard is displayed with multiple options.
The icons on top, such as Events,
LAN,
and Wi-Fi
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.
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.
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.
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.
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.