Vai al contenuto

14. Kismet Essentials

Kismet1 is a versatile wireless capture tool. It can capture data of different wireless technologies such as Wi-Fi, Bluetooth,2 and nRF3 signals, or it can use Software Defined Radio (SDR)4 to capture ADS-B,5 Automatic meter reading (AMR),6 433MHz,7 and more. For now, we will focus on its Wi-Fi capabilities.

Kismet captures raw wireless frames and decodes them to identify access points and devices on the network. When paired with a GPS8 device, Kismet also includes estimated geolocation data for the discovered devices.9 We can use this data to get a rough idea of where devices are in relation to access points.

Kismet's UI gives us several ways to view wireless networks. We can use it alongside other network tools to enhance our understanding of a given wireless network.

1 (Kismet Wireless, 2021), https://www.kismetwireless.net/ ↩︎

2 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/datasources_bluetooth/ ↩︎

3 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/datasources_nrf_mousejack/ ↩︎

4 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/datasources_sdr_rtl433/ ↩︎

5 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast ↩︎

6 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Automatic_meter_reading ↩︎

7 (Wikipedia, 2020), https://en.wikipedia.org/wiki/LPD433 ↩︎

8 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Global_Positioning_System ↩︎

9 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/gps/ ↩︎

14.1. Installation

To begin, we'll install Kismet in Kali using apt install kismet.

Text Only
kali@kali:~$ sudo apt install kismet
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  kismet-capture-common kismet-capture-linux-bluetooth kismet-capture-linux-wifi kismet-capture-nrf-51822 kismet-capture-nrf-mousejack
  kismet-capture-nxp-kw41z kismet-capture-ti-cc-2531 kismet-capture-ti-cc-2540 kismet-core kismet-logtools libmicrohttpd12 libprotobuf22
  python3-kismetcapturefreaklabszigbee python3-kismetcapturertl433 python3-kismetcapturertladsb python3-kismetcapturertlamr python3-protobuf
Suggested packages:
  gpsd kismet-doc kismet-plugins festival
The following NEW packages will be installed:
  kismet kismet-capture-common kismet-capture-linux-bluetooth kismet-capture-linux-wifi kismet-capture-nrf-51822 kismet-capture-nrf-mousejack
  kismet-capture-nxp-kw41z kismet-capture-ti-cc-2531 kismet-capture-ti-cc-2540 kismet-core kismet-logtools libmicrohttpd12 libprotobuf22
  python3-kismetcapturefreaklabszigbee python3-kismetcapturertl433 python3-kismetcapturertladsb python3-kismetcapturertlamr python3-protobuf
0 upgraded, 18 newly installed, 0 to remove and 112 not upgraded.
Need to get 0 B/6,237 kB of archives.
After this operation, 29.1 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
...
Setting up kismet (2020.04.R3-0kali1) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for kali-menu (2020.3.2) ...
Processing triggers for libc-bin (2.30-8) ...

Listing 1 - Installing Kismet

Now that we've completed the quick install, let's learn more about how to configure Kismet.

14.2. Configuration Files

There are a several ways we could familiarize ourselves with Kismet, but we'll begin with the configuration files.1 These can be found in /etc/kismet/.

Text Only
kali@kali:~$ ls -al /etc/kismet/
drwxr-xr-x   2 root root  4096 Sep 17 13:34 .
drwxr-xr-x 164 root root 12288 Sep 17 13:23 ..
-rw-r--r--   1 root root  4033 Sep 14 07:53 kismet_80211.conf
-rw-r--r--   1 root root  3723 Sep 14 07:53 kismet_alerts.conf
-rw-r--r--   1 root root  7768 Sep 14 07:53 kismet.conf
-rw-r--r--   1 root root  3486 Sep 14 07:53 kismet_filter.conf
-rw-r--r--   1 root root  2717 May 15 03:21 kismet_httpd.conf
-rw-r--r--   1 root root  5106 May 15 03:21 kismet_logging.conf
-rw-r--r--   1 root root  4977 Sep 14 07:53 kismet_memory.conf
-rw-r--r--   1 root root  4737 May 15 03:21 kismet_uav.conf

Listing 2 - Kismet configuration files

Each file in Listing 2 configures a specific aspect of Kismet. Let's quickly review what each file controls.

kismet_80211.conf configures settings related to Wi-Fi.

kismet_alerts.conf configures Kismet's intrusion detection and alert subsystem. Kismet includes a Wireless Intrusion Detection System2 (WIDS), but we will not cover that particular functionality in this module.

kismet.conf is the master configuration file for Kismet.

kismet_filter.conf configures filtering rules for devices and packets.

kismet_httpd.conf configures Kismet's web server.

kismet_logging.conf configures how and where Kismet creates log files.

kismet_memory.conf configures Kismet's memory usage.

kismet_uav.conf contains rules for detecting unmanned aerial vehicles3 (UAV) and drones.

In addition to editing these files individually, we can override settings in multiple files by creating a kismet_site.conf file in /etc/kismet/. Any options we specify in this file override the settings in the default configuration files. We can use this feature to maintain our own custom settings even if an update to Kismet includes modifications to the default configurations files.

We may want to override the default settings with logging in particular. Before we do that, we need to have a better understanding of how Kismet logs data. Eventually, there may be other settings we want to change as well.

1 (Kismet Wireless, 2021), https://kismetwireless.net/docs/readme/config_files/ ↩︎

2 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/alerts_and_wids/ ↩︎

3 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Unmanned_aerial_vehicle ↩︎

14.2.1. Output Files

Kismet creates log files1 in three different formats: kismet, PcapPpi, and PcapNg. The kismet format is the default setting and includes all the gathered data in a SQLite2 database. The PcapPpi format is a legacy Pcap format while the PcapNg format is the modern Pcap format.

The kismet and PcapNg formats allow for packets from multiple Data Link Types3 (DLT). In other words, they can contain a mix of Wi-Fi, Bluetooth, and other signals. Legacy Pcap files can only contain one DLT.

Of these two, the PcapNg format is generally more preferred because it allows us to use the results in other tools, such as Wireshark.

Even though PcapNg supports multiple DLTs, if we enable multiple sensor types during a capture, for example, both Wi-Fi and Bluetooth, Kismet will consolidate all the different frame types in the log file. Other tools may have issues parsing Pcap files with more than one data source.

We can convert PcapNg files that contain a single type of data, such as just Wi-Fi, to Pcap files using tshark. We would use the following command.

Text Only
tshark -F pcap -r ${pcapng file} -w ${pcap file}

Listing 3 - Converting PcapNg to Pcap

Let's change how Kismet logs data by creating an override configuration file. First, we will review the settings in kismet_logging.conf.

Text Only
# Default log title, can be overridden with the '-t' argument to Kismet
log_title=Kismet

# Default location for logs; by default this is the directory Kismet was launched
# in, but the logs can be automatically stored in other directories as well.
# The directory must exist before Kismet is started - Kismet will /not/ create
# the directory list itself.
log_prefix=./


# Logging is enabled by type; plugins may add additional types.  The log types can be
# overridden on the command line with the '--log-types' argument.
#
# Built-in log types (plugins may add more, consult the documentation for plugins):
#   kismet      Unified log which can be turned into multiple types of data
#   pcapppi     Old-style pcap with PPI headers for signal and metadata.  Not as
#               flexible as the pcapng format.
#   pcapng      Pcap-NG (suitable for use with Wireshark and Tshark, as well as other
#               tools) which contains raw pcap data with interface tags.  See the 
#               Kismet readme for methods to turn this into an old-style pcap log.
#
# By default, Kismet only enabled the unified 'kismet' log; the pcapng option is
# provided for special configurations as a legacy fallback mode.
log_types=kismet
...

Listing 4 - Excerpt from kismet_logging.conf

By default, Kismet stores log files in the current working directory. Let's change this to a centralized location in our override configuration file.

We will also change the log types to include PcapNg logs. The kismet log is useful, but as we mentioned previously, if we want to use the data from Kismet in other tools, we will want to log in the PcapNg format as well.

First, let's create a new directory in /var/log to hold our log files.

Text Only
kali@kali:/etc/kismet$ sudo mkdir /var/log/kismet

Listing 5 - Creating the kismet log directory

Next, we will create the kismet_site.conf file with our override settings for log_prefix to store data in the new directory and log_types to create log files in kismet and PcapNg formats.

Text Only
log_prefix=/var/log/kismet/
log_types=kismet,pcapng

Listing 6 - Contents of kismet_site.conf

Now that we have logging configured, let's move on to data sources.

Exercise

Create a directory for Kismet log files and create an override configuration file to use that directory for logging.

1 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/logging/ ↩︎

2 (Wikipedia, 2021), https://en.wikipedia.org/wiki/SQLite ↩︎

3 (The Tcpdump Group, 2021), https://www.tcpdump.org/linktypes.html ↩︎

14.2.2. Data Sources

Kismet captures data from one or more sources.1 We will primarily use a Wi-Fi device as our source, but Kismet used with the appropriate hardware can also capture Bluetooth, Software Defined Radio (SDR), and nRF signals.

We can specify data sources either in configuration files or on the command line when starting Kismet. The command line option is often sufficient for simple tasks with a single data source. However, using configuration files is a good way to stay organized as we add more wireless adapters.

When we specify a Wi-Fi device as our source, Kismet will auto-detect and capture on all the channels supported by that device. We can also configure Kismet to only capture on certain channels or frequencies.2 If we are in an area with a lot of Wi-Fi networks, we can use this feature to hone in on just the channels we are interested in.

1 (Kismet Wireless, 2021), https://kismetwireless.net/docs/readme/datasources/ ↩︎

2 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/datasources_wifi/ ↩︎

14.3. Starting Kismet

Let's run kismet on our wireless network using -c wlan0. Kismet will automatically put our wireless interface in monitor mode. We will let Kismet run for a few moments, then exit by using C+c.

Kismet uses the ncurses1 library to overwrite text in its console output, meaning it only shows the most recent output. Unfortunately, this means we can't scroll back through the output and search for anything we might have missed. We can disable this feature with the command line option --no-ncurses to get all output on new lines in the console.

We will get a lot of output when we run Kismet, so let's break down some of the console output. The first section of output displays which config files are loaded.

Text Only
kali@kali:/etc/kismet$ cd ~
kali@kali:~$ sudo kismet -c wlan0 --no-ncurses
INFO: Including sub-config file: /etc/kismet/kismet_httpd.conf
INFO: Including sub-config file: /etc/kismet/kismet_memory.conf
INFO: Including sub-config file: /etc/kismet/kismet_alerts.conf
INFO: Including sub-config file: /etc/kismet/kismet_80211.conf
INFO: Including sub-config file: /etc/kismet/kismet_logging.conf
INFO: Including sub-config file: /etc/kismet/kismet_filter.conf
INFO: Including sub-config file: /etc/kismet/kismet_uav.conf
INFO: More than one override file included; Kismet will process them in the order they were defined.
INFO: Loading config override file '/etc/kismet/kismet_package.conf'
INFO: Optional sub-config file not present: /etc/kismet/kismet_package.conf
INFO: Loading config override file '/etc/kismet/kismet_site.conf'
INFO: Loading optional sub-config file: /etc/kismet/kismet_site.conf
...

Listing 7 - Kismet configuration information

The output in 7 verifies Kismet loaded our override config file. Kismet checks for an additional override configuration file at /etc/kismet/kismet_package.conf. This file is used to handle platform specific configurations, such as running Kismet on OpenWrt. We can ignore this file on Kali.

Next, we have output about Kismet's web server.

Text Only
...
KISMET - Point your browser to http://localhost:2501 (or the address of this system) for the Kismet UI
INFO: Starting Kismet web server...
INFO: Started http server on 0.0.0.0:2501
...

Listing 8 - Kismet web server information

Finally, Kismet starts capturing data on the wlan0 interface.

Text Only
...
INFO: Found type 'linuxwifi' for 'wlan0'
INFO: wlan0 telling NetworkManager not to control interface 'wlan0': you may need to re-initialize this interface later or tell NetworkManager to control it again via 'nmcli'
INFO: wlan0 bringing down parent interface 'wlan0'
INFO: Data source 'wlan0' launched successfully
INFO: Detected new 802.11 Wi-Fi access point 5B:5C:79:0B:A8:F2
INFO: 802.11 Wi-Fi device 5B:5C:79:0B:A8:F2 advertising SSID 'Galain'
INFO: Detected new 802.11 Wi-Fi access point D5:89:1D:35:20:62
INFO: 802.11 Wi-Fi device D5:89:1D:35:20:62 advertising SSID 'Liosan'
INFO: Detected new 802.11 Wi-Fi device AC:D5:64:3B:A7:BB
INFO: Detected new 802.11 Wi-Fi access point 67:CB:81:07:A7:57
INFO: 802.11 Wi-Fi device 67:CB:81:07:A7:57 advertising SSID 'Emurlahn'
^C
*** KISMET IS SHUTTING DOWN ***
Shutting down plugins...
...
Kismet exiting.
kali@kali:~$

Listing 9 - Running Kismet

As illustrated in Listing 9, Kismet ran successfully and identified three Wi-Fi access points and one Wi-Fi device. We can also verify our override configuration file worked correctly by checking /var/log/kismet/ for log files.

Text Only
kali@kali:~$ ls -al /var/log/kismet/
total 76
drwxr-xr-x  2 root root  4096 Sep 17 12:26 .
drwxr-xr-x 19 root root  4096 Sep 17 11:49 ..
-rw-r--r--  1 root root 61440 Sep 17 11:38 Kismet-20200917-15-38-41-1.kismet
-rw-r--r--  1 root root   744 Sep 17 11:38 Kismet-20200917-15-38-41-1.pcapng

Listing 10 - Listing the Kismet log directory

Let's try running Kismet again, but this time we will limit the channels. We will use -c wlan0:channels="4,5,6" to set our data source to wlan0 and limit it to channels 4, 5, and 6.

Text Only
kali@kali:~$ sudo kismet -c wlan0:channels="4,5,6"
...
INFO: Data sources passed on the command line (via -c source), ignoring
      source= definitions in the Kismet config file.
INFO: Probing interface 'wlan0' to find datasource type
...
INFO: Found type 'linuxwifi' for 'wlan0:channels="4,5,6"'
...
INFO: Data source 'wlan0:channels="4,5,6"' launched successfully
INFO: Detected new 802.11 Wi-Fi device AC:D5:64:3B:A7:BB
^C
*** KISMET IS SHUTTING DOWN ***
Shutting down plugins...
...
Kismet exiting.

Listing 11 - Running Kismet on channels 4, 5, and 6

When restricting Kismet to channels 4, 5, and 6, we only found one device, and we didn't find any access points. This feature is useful, but we should be careful not to miss any important devices or access points.

We can also run Kismet as a background process using the --daemonize flag. This option allows us to run Kismet as a service at boot time when combined with the --no-ncurses flag to disable the ncurses wrapper.

Let's try it out by running kismet with the --daemonize flag.

Text Only
kali@kali:~$ sudo kismet --daemonize
Silencing output and entering daemon mode...
INFO: Including sub-config file: /etc/kismet/kismet_httpd.conf
INFO: Including sub-config file: /etc/kismet/kismet_memory.conf
INFO: Including sub-config file: /etc/kismet/kismet_alerts.conf
INFO: Including sub-config file: /etc/kismet/kismet_80211.conf
INFO: Including sub-config file: /etc/kismet/kismet_logging.conf
INFO: Including sub-config file: /etc/kismet/kismet_filter.conf
INFO: Including sub-config file: /etc/kismet/kismet_uav.conf
INFO: More than one override file included; Kismet will process them in the order they were defined.
INFO: Loading config override file '/etc/kismet/kismet_package.conf'
INFO: Optional sub-config file not present: /etc/kismet/kismet_package.conf
INFO: Loading config override file '/etc/kismet/kismet_site.conf'
INFO: Loading optional sub-config file: /etc/kismet/kismet_site.conf
INFO: Setting server UUID 00000000-0000-0000-0000-4B49534D4554
INFO: Serving static content from '/usr/share/kismet/httpd/'
INFO: Serving static userdir content from '/root/.kismet/httpd/'
INFO: Loading saved HTTP sessions
INFO: Opened OUI file '/usr/share/kismet/kismet_manuf.txt
INFO: Indexing manufacturer db

Listing 12 - Staring Kismet as a daemon

We can interact with the daemon process through Kismet's web interface or with a remote capture.

When we are ready to stop Kismet process, we can use ps -aux | grep kismet to find the process id and then kill -9 to shut down the process.

Exercise

Run Kismet on your Wi-Fi network. Experiment with restricting scans to different channels or frequencies.

1 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Ncurses ↩︎

14.4. Web Interface

Kismet includes a webserver1 and a web UI that is accessible on localhost:2501 by default. This web UI provides us another way to view and interact with the captured data. For this example, we have started Kismet without a data source.

We will need to create a user account the first time we attempt to connect to the application.

c2c3cc797a461e035a652e098008a3c9.png

Figure 1: Kismet UI first login

Once we have created our account, we can use the web UI to interact with Kismet and view its collected data. Since we didn't specify a data source, the main page will not have any device data available.

60f41baf281fa7aca8405bf6da4d3836.png

Figure 2: Kismet Web UI

We can start a capture by clicking on the hamburger menu in the top left of the page and then clicking on Data Sources.

69fb0f48f355964cca6235b9be4d220b.png

Figure 3: Kismet Web UI Menu

Next we will click on the Available Interface: wlan0 interface (linuxwifi) and then click on Enable Source to start capturing Wi-Fi data.

b3bd44a97da459e4cbdae0a4bd9b2160.png

Figure 4: Kismet Web UI Start Capture

Once the source has been enabled, the UI will start to show some traffic. If we click on wlan0 again, we will get more details about the configuration for the interface.

ac45b2e979375f84ebeffece46ac91f1.png

Figure 5: Kismet UI Interface Details

We can close the interface details by clicking on the X button.

We should now have some data available on the main page. The top half of the page displays information about identified devices. The lower half of the page displays messages, similar to the console output.

09c13bc42b65b2fe828589e1e822aec6.png

Figure 6: Kismet UI

On the bottom of the page, we can click on Channels to get a chart of the number of devices per channel.

f136e9e462245ff6eb6158eaebc34c9f.png

Figure 7: Kismet UI Channels

We can toggle between Frequency and Wi-Fi channel numbers by clicking the drop-down menu in the upper-right corner of the pane. The chart updates based on real-time information as devices hop between channels.

On the top of the page, we can filter the displayed devices by clicking on All devices and selecting a value from the drop-down list.

22f5df7e82403747f84742775ba3b942.png

Figure 8: Kismet UI Filtering Devices

If we click on a device, we get a detailed view of that device.

8c44e7d9b4896e5f248bc0b61b8c8c9c.png

Figure 9: Kismet UI Device Details

Kismet attempts to identify a device's manufacturer by examining the first three octets of a device's MAC address. It checks those octets against an Organizationally Unique Identifier (OUI) database, which is simply a text file. The OUI database used by Kismet is located at /usr/share/kismet/kismet_manuf.txt.

The details also include the device’s frequency usage, signal strength, packet types, and more. We can close this view and return to the main page by click on the X in the upper right hand corner. The device list includes access points. We can click on an access point device to get a detailed view as well.

We can also click on SSIDs to get additional information about discovered SSIDs.

776b0cec640b0e0751fb97390c70e67a.png

Figure 10: Kismet UI SSIDs

Even though the device list includes access points, the SSID list includes some additional information, such as the encryption type used by the network.

1 (Kismet Wireless, 2021), https://kismetwireless.net/docs/readme/webserver/ ↩︎

14.4.1. Securing the Web Interface

By default, the Kismet web server listens on all interfaces, permitting for remote connections to the UI. This setting is fine in a controlled environment, but we should restrict access before we use Kismet in a real-world scenario. We can configure Kismet's web server to listen on our loopback interface by adding "httpd_bind_address=127.0.0.1" to our kismet_site.conf override configuration file.

Text Only
log_prefix=/var/log/kismet/
log_types=kismet,pcapng
httpd_bind_address=127.0.0.1

Listing 13 - Updated kismet_site.conf file contents

We can also enable HTTPS on the web server1 to encrypt our communications with the web server. This step isn't necessary in a lab environment. However, we recommend setting this up before running Kismet on a public network.

Exercise

Connect to the web interface and explore its functionality.

1 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/webserver/#kismet-and-ssl ↩︎

14.5. Remote Capture

Kismet includes separate tools to capture data. When we run Kismet and specify a source, it will automatically use the appropriate tool. For example, when we run a capture on wlan0 on Kali, Kismet calls the kismet_cap_linux_wifi tool to handle the capture.

We can also call these tools directly to capture traffic locally and send the data to a Kismet server running on a remote host.1 The server does not initiate the capture, but it listens for connections and processes the data. Kismet only allows connections from localhost by default.

We can use this functionality to capture Wi-Fi data on several smaller, cheaper devices and send the data to one centralized server for processing and retention.

To enable remote capture, we need to setup an SSH tunnel to the server or configure the remote instance of Kismet to listening on a specific network interface. We can do the latter by changing the remote_capture_listen value to a specific interface in our override configuration file.

We have two Kali instances with Kismet installed for the following example, a Kali host and kaliremote. We will use our Kali host as our server instance and kaliremote as our capture device since it has a Wi-Fi adapter.

We will start Kismet on our Kali host without supplying a source parameter.

Text Only
kali@kali:~$ sudo kismet
...
INFO: Launching remote capture server on 127.0.0.1:3501
INFO: No data sources defined; Kismet will not capture anything until a
      source is added.
INFO: Opened kismetdb log file '/var/log//Kismet-20200917-15-18-55-1.kismet'
INFO: Saving packets to the Kismet database log.
INFO: Opened pcapng log file '/var/log/kismet//Kismet-20200917-15-18-55-1.pcapng'
ALERT: rootuser Kismet is running as root; this is less secure.  If you
       are running Kismet at boot via systemd, make sure to use `systemctl
       edit kismet.service` to change the user.  For more information, see
       the Kismet README for setting up Kismet with minimal privileges.
INFO: Starting Kismet web server...
INFO: Started http server on port 2501

Listing 14 - Starting a Kismet server without a data source on Kali

Next, we will establish the SSH tunnel from kaliremote, our capturing instance, to our Kali host. Since Kismet listens on localhost port 3501, we need to use port forwarding when we establish our SSH tunnel. We will use ssh with the -L flag to enable port forwarding so that port 8000 on kaliremote forwards to port 3501 on our Kali host.

Text Only
kali@kaliremote:~$ ssh kali@192.168.62.192 -L 8000:localhost:3501
kali@192.168.62.192's password:
Linux kali 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-6kali1 (2019-07-22) x86_64

The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Sep 16 10:21:11 2020 from 192.168.62.219
kali@kali:~$

Listing 15 - Establishing an SSH tunnel with port 8000 forwarded

After establishing an SSH tunnel, we will open a new terminal on kaliremote and start a data capture. Let's use kismet_cap_linux_wifi with the --connect flag set to localhost:8000 and set our --source to wlan0 to use the local wireless network. Since we have forwarded port 8000 through our SSH tunnel to port 3501, kismet_cap_linux_wifi should send the data to our Kali host.

Text Only
kali@kaliremote:~$ sudo kismet_cap_linux_wifi --connect 127.0.0.1:8000 --user offsec --password lab --source=wlan0:name=remote-wlan0
INFO - Connected to '127.0.0.1:8000'...
INFO - 127.0.0.1:8000 starting capture...

Listing 16 - Starting a remote capture

At this point, the Kismet instance on kaliremote captures Wi-Fi data and sends it through the SSH tunnel to the Kismet server on our Kali host.

Text Only
INFO: wlan0 - wlan0 telling NetworkManager not to control interface
      'wlan0': you may need to re-initialize this interface later or tell
      NetworkManager to control it again via 'nmcli'
INFO: wlan0 - wlan0 bringing down parent interface 'wlan0'
INFO: Detected new 802.11 Wi-Fi access point 5B:5C:79:0B:A8:F2
INFO: 802.11 Wi-Fi device 5B:5C:79:0B:A8:F2 advertising SSID 'Galain'

Listing 17 - Capture data on Kali

We will let this run briefly, then disconnect by pressing C+c on kaliremote.

Text Only
kali@kaliremote:~$ sudo kismet_cap_linux_wifi --connect 127.0.0.1:8000 --user offsec --password lab --source=wlan0:name=remote-wlan0
INFO - Connected to '127.0.0.1:8000'...
INFO - 127.0.0.1:8000 starting capture...
^C
kali@kaliremote:~$

Listing 18 - Stopping the capture on kaliremote

The Kismet server will continue to run and wait for connections on our Kali host. Even though the Kismet instance on kaliremote handled the capture, the Kali host instance handles data processing and logging.

We can now close our SSH tunnel.

Text Only
kali@kali:~$ ssh kali@192.168.62.192 -L 8000:localhost:3501
kali@192.168.62.192's password:
Linux kali 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-6kali1 (2019-07-22) x86_64

The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Sep 16 10:21:11 2020 from 192.168.62.219
kali@kali:~$ exit
logout
Connection to 192.168.62.192 closed.
kali@kaliremote:~$

Listing 19 - Closing the SSH tunnel

We can also shut down the Kismet server instance running on our Kali host.

Text Only
INFO: wlan0 - wlan0 found existing monitor interface 'wlan0mon' for source
      interface 'wlan0'
INFO: wlan0 - wlan0 monitor interface 'wlan0mon' already exists for
      capture interface 'wlan0', we'll use that.
INFO: wlan0 - wlan0 bringing down parent interface 'wlan0'
INFO: Detected new 802.11 Wi-Fi access point 5B:5C:79:0B:A8:F2
INFO: 802.11 Wi-Fi device 5B:5C:79:0B:A8:F2 advertising SSID 'Galain'
^C
*** KISMET IS SHUTTING DOWN ***
Shutting down plugins...
...
kali@kali:~$

Listing 20 - Shutting down Kismet on kali

This example just scratched the surface of what is possible with Kismet's remote capture functionality. We can use remote capture with multiple devices to enhance Wi-Fi monitoring capabilities.

1 (Kismet Wireless, 2021), https://kismetwireless.net/docs/readme/datasources_remote_capture/ ↩︎

14.6. Log Files

We have already explored how to configure logging with an override file. We can also use several command line flags to control logging at runtime.

Text Only
 -T, --log-types <types>      Override activated log types
 -p, --log-prefix <prefix>    Directory to store log files
 -n, --no-logging             Disable logging entirely

Listing 21 - Selected Kismet logging command line options

We can use the --no-logging option if we need to debug an issue without creating additional log files.

We previously mentioned that kismet log files are SQLite databases. Let's go over how we can use the sqlite3 tool to interact with kismet files.

Text Only
kali@kali:~$ sudo sqlite3 /var/log/kismet/Kismet-20200917-18-45-34-1.kismet
SQLite version 3.33.0 2020-08-14 13:23:32
Enter ".help" for usage hints.
sqlite>

Listing 22 - Opening a kismet file with sqlite

We can view the tables in the database with .tables.

Text Only
sqlite> .tables
KISMET       data         devices      packets
alerts       datasources  messages     snapshots

Listing 23 - Viewing tables

Let's quickly review each table.

  • The KISMET table contains the database version and which version of Kismet created the log file.
  • The alerts table contains any alerts or WIDS issues.
  • The data table contains records that are not packet related, such as SDR data.
  • The datasources table contains information about the data sources used to capture data.
  • The devices table contains information about the devices Kismet was able to identify.
  • The messages table contains informational messages, such as those displayed in the console or web application.
  • The packets table contains the raw packets captured by Kismet. The table can contain multiple DLTs.
  • The snapshots table contains time-based information.

Kismet's documentation1 includes a further breakdown of each table and its fields. Several tables have a column that stores JavaScript Object Notation2 (JSON) data.

We can get the column names for a table with .schema followed by the table name.

Text Only
sqlite> .schema devices
CREATE TABLE devices (first_time INT, last_time INT, devkey TEXT, phyname TEXT, devmac TEXT, strongest_signal INT, min_lat REAL, min_lon REAL, max_lat REAL, max_lon REAL, avg_lat REAL, avg_lon REAL, bytes_data INT, type TEXT, device BLOB, UNIQUE(phyname, devmac) ON CONFLICT REPLACE);

Listing 24 - Schema for the devices table

Let's review the columns.

  • The first_time and last_time columns contain when Kismet saw a device, the first time and last time, respectively.
  • The devkey column contains a unique identifier for each device.
  • The phyname column contains the physical layer for the device.
  • The devmac column contains a device's MAC address.
  • The strongest_signal column contains the strongest recorded signal for the device.
  • The min_lat, max_lat, and avg_lat columns contain the minimum, maximum, and average latitude values for the device.
  • The min_lot, max_lot, and avg_lot contain the minimum, maximum, and average longitude values.
  • The bytes_data column contains the number of bytes of data seen for the device.
  • The type column contains a human readable value for the physical layer device type.
  • Finally, the device column contains a JSON version of the device record, which can be quite lengthy.

Now that we know about the columns in the devices table, let's use a query to get the types and MAC addresses. We will also enable column headers in our output with .headers.

Text Only
sqlite> .headers on
sqlite> select type, devmac from devices;
type|devmac
Wi-Fi AP|67:CB:81:07:A7:57
Wi-Fi Device|E0:46:9A:29:49:F9
Wi-Fi Client|64:B0:A6:D9:73:52
Wi-Fi Device|AC:D5:64:3B:A7:BB
Wi-Fi AP|5B:5C:79:0B:A8:F2
Wi-Fi AP|D5:89:1D:35:20:62
Wi-Fi Client|00:0F:13:F6:A7:A6

Listing 25 - Getting MAC addresses from the devices table

When finished, we can exit using .quit.

Text Only
sqlite> .quit
kali@kali:~$

Listing 26 - Exiting sqlite

We have a lot of flexibility when using sqlite3 and kismet log files. We can use SQLite queries to easily filter the captured data for manual analysis.

We can also run an SQLite query as a one liner by using sqlite3, specifying a log file, and then a query as one command.

Text Only
kali@kali:~$ sudo sqlite3 /var/log/kismet/Kismet-20200917-18-45-34-1.kismet "select type, devmac from devices;"
Wi-Fi AP|67:CB:81:07:A7:57
Wi-Fi Device|E0:46:9A:29:49:F9
Wi-Fi Client|64:B0:A6:D9:73:52
Wi-Fi Device|AC:D5:64:3B:A7:BB
Wi-Fi AP|5B:5C:79:0B:A8:F2
Wi-Fi AP|D5:89:1D:35:20:62
Wi-Fi Client|00:0F:13:F6:A7:A6

Listing 27 - sqlite one-liner

Regardless of how we interact with it, the kismet log file provides access to all the information captured while running Kismet.

1 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/devel/kismetdb/#log-sections ↩︎

2 (Wikipedia, 2021), https://en.wikipedia.org/wiki/JSON ↩︎

14.6.1. Reading Log Files

Kismet can use log files as a data source, including Pcap or PcapNg capture files. When reprocessing a file, Kismet attempts to replay through the file as fast as possible. We can throttle the processing with the pps and realtime options. These options are mutually exclusive.

If we want the file processed at the original capture rate, we can use the realtime flag set to true. If we want to control Kismet's processing rate, we can use the pps option to set a packets-per-second processing rate. This option is useful when we have a large file and limited CPU resources.

Warning

Setting the realtime flag to false is the same as not including either option. In other words, Kismet will still attempt to process the file as fast as it can.

Let's try this out with the Network_Join_Nokia_Mobile.pcap sample file from the Wireshark website.1 We will use -c to specify a log file as our source and we will append :realtime=true to have kismet process the file at the original capture rate. We may need to wait a few moments for the complete results to show up.

Text Only
kali@kali:~$ sudo kismet -c Documents/Network_Join_Nokia_Mobile.pcap:realtime=true
...
INFO: Pcapfile 'Documents/Network_Join_Nokia_Mobile.pcap' will replay in
      realtime
INFO: Data source 'Documents/Network_Join_Nokia_Mobile.pcap:realtime=true'
      launched successfully
INFO: Detected new 802.11 Wi-Fi access point 00:01:E3:41:BD:6E
INFO: 802.11 Wi-Fi device 00:01:E3:41:BD:6E advertising SSID 'martinet3'
INFO: Detected new 802.11 Wi-Fi device 00:01:E3:42:9E:2B
INFO: Detected new 802.11 Wi-Fi device 00:15:00:34:18:52
INFO: Detected new 802.11 Wi-Fi device 00:16:BC:3D:AA:57
ALERT: noclientmfp IEEE80211 network BSSID 00:01:E3:41:BD:6E client
       00:16:BC:3D:AA:57 does not support management frame protection
       (MFP) which may ease client disassocation or deauthentication
^C
*** KISMET IS SHUTTING DOWN ***
Shutting down plugins...
...

Listing 28 - Processing a PcapNg file with Kismet

Even though another tool created the .pcap file, Kismet identified one access point and three devices from the file's content. While we are not particularly focused on it right now, Kismet also identified that Management Frame Protection2 (MFP) wasn't enabled on the network. This alert is an example of Kismet's Wireless Intrusion Detection System (WIDS).

Exercise

Run Kismet with an 802.11 sample capture file from Wireshark as the data source.

1 (Wireshark, 2021), https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=Network_Join_Nokia_Mobile.pcap ↩︎

2 (Wikipedia, 2021), https://en.wikipedia.org/wiki/IEEE_802.11w-2009 ↩︎

14.7. Exporting Data

Kismet includes several tools we can use to export data into a variety of file formats. Let's go over several commonly used formats and the associated tools.

14.7.1. Pcap

Earlier in this module we configured Kismet to output kismet and PcapNg files. Even if we only have kismet log files, we can use the kismetdb_to_pcap1 tool to convert kismet logs to Pcap and PcapNg logs. The tool is straightforward to use. However, we must keep in mind that Kismet can capture multiple data types from multiple data sources. There are tools that cannot handle different data types within a PcapNg file.

Let's run kismetdb_to_pcap, specifying our kismet log file with --in, and using --list-datasources to get a list of data sources in that log file.

Text Only
kali@kali:~$ kismetdb_to_pcap --in Kismet-20200917-18-45-34-1.kismet --list-datasources
Datasource #0 (5FE308BD-0000-0000-0000-26C65C9CEA7A wlan0 wlan0) 104 packets
   DLT 127: IEEE802_11_RADIO 802.11 plus radiotap header

Listing 29 - Checking datasources in a kismet file

We do not need to use the --datasource flag since there is only one data source. We will use kismetdb_to_pcap, setting --in to our kismet file and --out to our new PcapNg file.

Text Only
kali@kali:~$ kismetdb_to_pcap --in Kismet-20200917-18-45-34-1.kismet --out sample.pcapng --verbose
* Preparing input database 'Kismet-20200917-18-45-34-1.kismet'...
* Found KismetDB version 6
* Collecting info about datasources...
* Opening pcapng file sample.pcapng
kali@kali:~$

Listing 30 - Converting a kismet file to a PcapNg file

Now that we have a PcapNg file, we could open it in Wireshark or other tools for further processing and analysis.

1 (Kismet Wireless, 2021), https://www.kismetwireless.net/docs/readme/kismetdb_to_pcap/ ↩︎

14.7.2. JSON

We can convert kismet log files to JSON format using the kismetdb_dump_devices1 tool.

Let's try it out. We'll use kismetdb_dump_devices, use the --in flag to specify our kismet log file, --out to set our output file, --skip-clean to skip the SQL vacuum2 command, and --verbose to enable verbose mode.

Text Only
kali@kali:~$ kismetdb_dump_devices --in /var/log/kismet/Kismet-20200917-17-45-17-1.kismet --out sample.json --skip-clean --verbose
* Preparing input database '/var/log/kismet/Kismet-20200917-17-45-17-1.kismet'...
* Found KismetDB version 6 6 devices
* 17% Processed 1 devices of 6
* 34% Processed 2 devices of 6
* 51% Processed 3 devices of 6
* 67% Processed 4 devices of 6
* 84% Processed 5 devices of 6
* 101% Processed 6 devices of 6
* Processed 6 devices
* Done!

Listing 31 - Using kismetdb_dump_devices to create a .json file

Many of the Kismet export tools run the SQL VACUUM command to optimize the sqlite database before exporting data from it. This process involves rewriting the log file and therefore requires write access to the log file. If we do not have write access, we can run the export tool with sudo or using the --skip-clean flag.

With our captured data in JSON format, we can perform further post-processing or data aggregation on it with other tools, such as Elastic Stack,3 custom Python scripts, or jq,4 a sed-like tool for JSON.

If we plan to load Kismet data into Elastic Stack, we may need to use the --json-path or --ekjson flags to generate a compatible output file.

1 (Kismet Wireless, 2021), https://kismetwireless.net/docs/readme/kismetdb_devices_json/ ↩︎

2 (SQLite, 2021), https://sqlite.org/lang_vacuum.html ↩︎

3 (Elasticsearch B.V., 2021), https://www.elastic.co/what-is/elk-stack ↩︎

4 (stedolan, 2018), https://stedolan.github.io/jq/ ↩︎

14.8. Wrapping Up

Kismet is a versatile tool for capturing data about wireless devices. Its focus on devices and access points makes it a good complement to other wireless and network tools. We reviewed how to capture data and how to output it in a variety of formats for use in other tools.