Alerts and WIDS
Kismet can function as a WIDS (Wireless Intrusion Detection System) with configurable alerts for both stateless and stateful fingerprint and trend based monitoring. Kismet fingerprint alerts can trigger on known-hostile specific behavior such as attacks against wireless drivers, and trend-based monitors can detect unusual behavior over time, such as flooding and denial of service attacks.
Kismet can integrate with other tools via the live packet export REST API, the Kismet alert REST API, and via syslog and some SIEM tools.
Kismet is most effective as an IDS in stationary (ie, non-wardriving) capacity. Kismet WIDS functionality can be used in mobile and channel-hopping installations, but accuracy and coverage may suffer.
Alerts are configured with the
alert= configuration option in
kismet_alerts.conf. Alerts are configured by name, with
The throttle option controls how many alerts are allowed per time unit (seconds and minutes), and burst controls how many alerts are allowed in quick succession. For instance:
Will allow at most one alert per second, and at most 5 alerts per minute.
An SSID has changed the encryption options it advertises (not necessarily decreasing the encryption options, but advertising different options). This can occur when a managed access point is reconfigured, but may also indicate an access point spoofing attack.
One of the original 802.11 hacking tools, Airjack, set the initial SSID to
airjackwhen loading. This alert is no longer relevant since the Airjack toolset has long been discontinued.
A list of valid MAC addresses for a given SSID can be configured via the
apspoof=configuration option. If a beacon or probe response for that SSID is seen from a MAC address not found in that list, an alert will be raised. This can be used to detect spoofed or evil twin attacks and attacks like Karma, however it will not detect attacks which also spoof the MAC address.
apspoof=configuration can specify exact string matches for the SSID, regular expressions using PCRE syntax, and single, multiple, or masked MAC addresses:
When providing multiple MAC addresses, they must be enclosed in quotes.
The advertised beacon rate of a SSID has changed; in a managed enterprise environment this may indicate a normal configuration change, however it may also indicate a spoofing attack against an access point.
Invalid channels in 802.11k neighbor report frames can be used to exploit certain Broadcom HardMAC implementations, typically used in mobile devices, as described in project zero 1289
Invalid or out-of-sequence BSS timestamps can indicate AP spoofing. APs with fluctuating BSS timestamps could be an indication of spoofing or an “evil twin” attack. Out-of-order packets from multiple datasources and some AP firmware can both lead to false positives.
A previously detected access point which changes channels may indicate a spoofing attack or simply a configuration change. By spoofing an otherwise legitimate AP on a different channel, an attacker may try to lure clients to the spoofed AP. Centrally managed enterprise access points may change channel if they reboot or if the current channels become congested, and some consumer APs may automatically change channe to a less-used part of the spectrum.
Typically an acess point should not downgrade to a less effective security setting. This may be an attempt to spoof the access point or a misconfigured access point.
By spoofing disassociate and deauthenticate packets, an attacker may disconnect clients from a network which does not support management frame protection (MFP); This can be used to cause a denial of service or to disconnect clients in an attempt to capture handshakes for attacking WPA.
A client which sends a DHCP DISCOVER packet containing a CLient-ID tag (Tag 61) which doesn’t match the source MAC of the packet may be doing a DHCP denial-of-service attack to attempt to exhaust the DHCP pool. To detect the DHCP client ID, the network must be unencrypted so that data may be observed.
Clients which request a DHCP address and receive a response, but operate on a different IP address, may be misconfigured, or may be spoofed by an attacker trying to gain access by simulating an existing client.
A client which has been disassociated from a network legitimately should not immediately continue exchanging data, as it needs to reestablish the connection to the AP. A client behaving oddly can indicate a spoofed client attempting to incorrectly inject data into a network, or a client which is the victim of a denial-of-service attack.
The 802.11 specification defines valid reason codes for disconnect and deauthenticate events. Various clients and access points have been reported to improerly handle invalid/undefined reason codes, and illegal reason codes are often an indicator of a spoofing attack.
The DHCP configuration protocol allows clients to optionally include the desired hostname and the DHCP client vendor/operating system in the DHCP Discovery packet. These values should only change if the client has changed drastically (such as a dual-boot system). As these are typically rare, these values changing can indicate a likely client spoofing attack.
While deprecated, 802.11d country codes are still accepted by many clients. Conflicting 802.11d advertisements can indicate an AP spoofing attack or an attempted to cause a client denial of service.
Some implementations of Karma set a predictable OUI of 00:13:37.
The 802.11 specification allows for a maximum of 32 bytes for the SSID. Over-sized SSIDs are indicative of packet corruption or of an attack attempting a buffer overflow on the access point or client drivers.
Very old 802.11b Lucent Orinico cards, in certain scanning test modes, generated indentifiable packets. These cards are extremely outdated at this point.
Very old versions of the Windows Broadcom wireless drivers did not properly handle SSID fields longer than 32 bytes, which could lead to code execution. This vulnerability is implemented in the Metasploit framework, but these drivers are extremely old and were found on Windows XP systems.
Very old versions of the Windows D-Link wireless drivers did not properly handle extremely long 802.11 rate fields, leading to code execution. This vulnerability is implemented in the Metasploit framework, but these drivers are extremely old and were found on Windows XP systems.
Very old versions of the Windows D-Link wireless drivers did not properly handle over-sized beacon frames, leading to code execution. This vulnerability is implemented in the Metasploit framework, but these drivers are extremely old and were found on Windows XP systems.
Very old versions of Netstumbler (3.22, 3.23, 3.30) generate, in certain conditions, specific packets which are identifiable.
A WPA handshake has attempted to re-use a previous nonce value; this may indicate an attack against the WPA keystream such as the vanhoefm KRACK attack. This alert is disabled by default by it is difficult to distinguish replay attacks vs legitimate retransmission of data in a passive observer.
Probe response packets with a SSID response with a length of 0 could cause extremely old 802.11b cards (prism2, orinoco, and the original Apple Airport) to crash.
Signal levels are abnormally high. This can be caused by using an external amplifier with too much power, or being too close to a network. Over-amplified signals can be distorted, resulting in fewer overall packets; in the absolute worst case, using too strong an amplifier can damage your Wi-Fi cards.
Active scanning tools constantly send network discovery probes but never join any of the networks which respond. This alert can cause excessive false positives in busy environments, so is disabled by default.
Invalid RSN (802.11i) tags in beacon frames can be used to cause loops in some Atheros drivers, as described in CVE-2017-9714 and pleasestopnamingvulnerabilities.com
The Wi-Fi standard specifies 24 bytes for WMM IE tags. Over-sized WMM fields may be an attempt to exploit bugs in Broadcom chipsets, such as the Broadpwn attack.
Excessive WPS negotiations can indicate an attack against WPS, such as Reaver
Too many WMMTSPEC options were seen in a probe response; this may be triggered by CVE-2017-11013 as described at pleasestopnamingvulnerabilities.com