Modern Wireless Tradecraft

Nytro · November 30, 2019

Modern Wireless Tradecraft Pt IV — Tradecraft and Defensive Strategy

Follow

Nov 23 · 9 min read

We’ve gone over a lot of information in the last three sections of this writeup. In case you missed them, you can find them here:

Now it’s time to make sense of it all, and talk about how each of the techniques we described fits into our toolkit from an operational perspective.

Before we begin, we need to establish some important points from which we’ll build a frame of reference. The first of these is that wireless attacks are inherently risky, since they must be executed within line-of-sight distance to the target. Wireless attacks are a bit like motorcycles: they’re fun, they can be a fast way to get from point A to point B, but they do come with risks that must be managed in order to be used effectively.

I’m pretty opinionated about this: I believe that because of the inherent risk, wireless tradecraft needs to be:

Pragmatic: Focus should be placed on vetted techniques that are known to work reliably. Attacks should be prepared in advance instead of developed or prepared onsite.
Disciplined: Attacks should be executed with deliberation against specific targets to achieve desired outcomes. Attacks should be supervised as they progress. “Spray and pray” tactics such as automatic deauthing should be avoided.
Flexible: Techniques should be adjusted in realtime based on observed results.
Impact Focused: Focus should be placed on attacks that reliably generate maximum impact in minimum time.

Impact Focused Wireless Attacks

The last point is particularly important. I do not believe that SSLStripping or Credential Sniffing are practices that belong in modern wireless playbooks for this reason. The widespread adoption of HSTS and Certificate Pinning means that using these techniques is largely a waste of time, and time is a valuable commodity that can lead to detection if not properly managed.

With that out of the way, here are some situations in which I think that the use of wireless tradecraft can actually make sense:

Breaching Wireless Networks: This is the obvious one. The end goal may be to gain access to an internal corporate network, or it may be something simpler like direct access to surveillance equipment, point-of-sale systems, or other networked hardware.
Payload Delivery: APTs will phish under most circumstances, and you should too. However if phishing isn’t your thing or the situation calls for something different, rogue AP attacks can be a startlingly effective platform through which to deliver payloads to WiFi enabled devices. Once you’ve forced a device to connect to you, you gain the ability to act as either a captive portal or an internet gateway. As a captive portal, you can redirect users to pages that prompt them to install implants (aka “updates”), and restrict their Internet access until they comply. When acting as a network gateway, you can inject malicious code into static content (i.e. modify unencrypted JavaScript files in transit, etc). In both cases, you can restrict communication to endpoint protection servers, buying you time to complete the attack.
AD Credential Theft: Many organizations tie their wireless infrastructure into Active Directory (AD). If these organizations use weak WPA/2-EAP configurations, the same attacks that you’d use to breach the wireless perimeter can also be effective tools for harvesting AD credentials. Until recently, it was even possible to use HTTP-to-SMB redirection to force Windows devices to surrender AD credentials, although this flaw seems to have been patched in Chrome and Edge within the past year (see: https://github.com/s0lst1c3/eaphammer/wiki/III.-Stealing-AD-Credentials-Using-Hostile-Portal-Attacks).

For the sake of simplicity, let’s group these scenarios into the two overarching use-cases:

Breaching Wireless Networks
Targeting Client Devices

In the sections that follow, we’ll example the suitability of each of the techniques we’ve learned for these two specific purposes.

Choosing a Rogue AP Technique

Evil Twin Attacks

Optimal Use-Case: Breaching Wireless Perimeter

Evil Twin attacks are the primary means of attacking WPA/2-EAP networks, and can be a also be an effective means of attacking WPA/2-PSK networks. Breaching WPA/2-EAP networks involves using rogue AP attacks to exploit weak EAP configurations. This is a topic for which educational material is already widely available, so I’m not going to cover this in depth in this post. With that said, here’s a quick primer on the subject if you’re interested:

http://solstice.sh/workshops/advanced-wireless-attacks/ii-attacking-and-gaining-entry-to-wpa2-eap-wireless-networks/

To attack a WPA/2-PSK network using an evil twin, you create a rogue access point with the same ESSID as the target and configure it to use WPA/2-PSK. You then capture the first two messages of the 4-way WPA handshake from any client that attempts to connect, and crack them to obtain the plaintext password.

To perform this attack using EAPHammer, use the --creds flag in conjunction with the —-auth wpa-psk flag:

./eaphammer -i wlan0 -e exampleCorp -c 1 — creds — auth wpa-psk

I should point out that this is not a new attack: it’s existed in hostapd-mana since January 2019 and in airbase-ng since dinosaurs roamed the earth.

Secondary Use-Case: Targeting Client Devices

Evil Twin attacks can be a good choice for targeting specific client devices if you have knowledge of at least one network on the device’s PNL. However, this approach can be dangerous. Evil Twins broadcast beacon frames by default, which prevent us from using MAC-based MFACLs to restrict the attack’s impact to specific devices. If the ESSID of the evil twin is target specific (i.e. you’re attacking EvilCorp and the ESSID of your rogue AP is something specific to EvilCorp’s infrastructure), then you’re probably ok. But if your rogue AP has a fairly common ESSID such as “attwifi”, you stand a high chance of causing collateral damage.

Using EAPHammer’s --cloaking full flag can mitigate a lot of this risk, because it will cause your AP to rely exclusively on broadcast probe responses to force targets to connect.

./eaphammer -i wlan0 -e exampleCorp -c 1 — hostile-portal — cloaking full — auth owe

However, cloaked evil twin attacks can be stopped using many of the same countermeasures that are used to stop classic karma attacks, so this may not be the best approach.

Opsec Considerations

Savvy network defenders often whitelist their access points by BSSID. As an attacker, you can circumvent these restrictions by spoofing the BSSID of a whitelisted IP (make sure to choose one that is a considerable distance away to avoid BSS conflicts). You should try to match the capabilities of the target access point though, since failure to do so will make your rogue AP stick out like a sore thumb.

MANA (and loud MANA) Attacks

Optimal Use-Case: Targeting Client Devices
MANA (and all karma-style attacks for that matter) are mainly designed for situations in which you need to target a client device but do not know the device’s PNL. They are also ideal for targeting specific devices, since they can be controlled using MAC-based MFACLs (unlike Evil Twins which rely primarily on beacon frames).

Secondary Use-Case: Breaching Wireless Perimeter

If the goal of the attack is to steal credentials for a WPA network, an evil twin is generally a better choice. However, it can make sense to use MANA attacks to breach WPA/2-PSK and WPA/2-EAP networks when Wireless Intrusion Prevention Systems (WIPS) are present.

MANA attacks can be used to execute a quieter version of the traditional evil twin attack. To do this, begin by creating an ESSID whitelist file containing the ESSID of the target access point:

echo exampleCorp > target-ess.txt

Next, create a MAC address whitelist file containing the MAC addresses of our targets:

echo 00:CB:19:D1:DD:B2 > mac-whitelist.txt
echo A3:A5:9A:A9:B3:A4 >> mac-whitelist.txt
echo FE:47:F2:7B:69:5C >> mac-whitelist.txt
echo C0:AF:A8:23:8D:7E >> mac-whitelist.txt
echo 33:58:A1:6E:A4:5F >> mac-whitelist.txt
echo C1:62:2A:5D:F8:80 >> mac-whitelist.txt

Next, create a rogue AP with the following configuration:

cloaking enabled
ESSID of target network
802.11w enabled (but not required) to prevent deauths from WIPS
MAC-based MFACL to restrict probe responses to specific devices
ESSID-based MFACL to restrict probe responses to target network
Set auth to either WPA-PSK or WPA-EAP (depending on target network configuration)

./eaphammer -i wlan0 \
 --e exampleCorp \
 — pmf enable \
 — cloaking full \
 — mana \
 — auth wpa-eap \
 — creds \
 — mac-whitelist mac-whitelist.txt \
 — ssid-whitelist target-ess.txt

Optional: deauthenticate client devices to coerce them to roam to new AP:

for i in `cat mac-whitelist.txt`; do aireplay-ng -0 5 -a de:ad:be:ef:13:37 -c $i; done

The rogue AP will stay “dormant” (not advertise its presence) until it receives probe requests from the target device(s), at which point it will respond in an attempt to trick the targets into associating.

Opsec Considerations

All karma-style attacks (including MANA) create a an easily detectable one-to-many relationship between a single BSSID and multiple ESSIDs. See the section on detection strategies for more information.

Known Beacon Attacks

Optimal Use-Case: Targeting Client Devices
Known Beacon attacks make sense in situations where you do not know the target devices’ PNL and where MANA attacks fail.

Opsec Considerations
Known beacon attacks are extremely loud due to the one-to-many relationship they create between a single BSSID and numerous ESSIDs. They also have a high potential for collateral damage. MAC-based MFACLs can limit this collateral damage to some extent — devices will still attempt to connect to your rogue AP, even though they won’t be able to complete the association process. Depending on the rogue AP’s transmission rate and the number of spoofed ESSIDs in use, known beacon attacks can cause network congestion.

Detection Strategies

Rogue AP detection is a pretty expansive topic, so this won’t be an exhaustive writeup. I do plan on writing at least one dedicated post on this subject in the future though, most likely geared towards Kibana and Wifibeat.

With that out of the way, here’s a list of fundamental indicators that any Wireless Intrusion Prevention System (WIPS) should monitor for:

1. New ESSIDs
It’s unusual to see new ESSs appear out of nowhere. Although the presence of a new ESS is not an indicator by itself, it does warrant additional investigation.

2. Legacy versions of 802.11
Most modern networking hardware uses 802.11ac, although it’s not uncommon to see 802.11n deployed in production as well. On the other hand, the vast majority of wireless pentesting hardware is limited to 802.11n and earlier. Unless adversaries are particularly aware of what they’re doing, they are likely to use an external wireless interface that is limited to 802.11g or 802.11a. If you suddenly see a new ESS appear and operating in 802.11g/a mode, that’s a pretty good indication that you should take a closer look.

3. Uncommon OUIs
The first three octets of any device’s MAC address contains an Organizationally Unique Identifier (OUI) that is used to uniquely identify the device’s manufacturer. Most rogue AP attacks are executed using external hardware made by manufacturers such as Alfa, TP-Link, and Panda Wireless. As such, it’s typically a good idea to monitor for devices that have OUIs that from these types of manufacturers.

4. ESSID Whitelist Violations
Keep an inventory of BSSIDs in your network, and use it as a whitelist. If you see an access point that is using your ESSID but is not in your whitelist, that is a strong indication that your network is being attacked.

5. One-to-many relationships
A single BSSID should never map to more than one ESSID. The presence of multiple beacon packets or probe response packets for multiple ESSIDs originating from a single BSSID is a strong indicator of malicious activity.

6. Known default settings for rogue AP attack tools
Most publicly available tools for performing rogue AP attacks (including the WiFi Pineapple and EAPHammer) have easily identifiable default settings. For example, both EAPHammer and the WiFi Pineapple have a default BSSID of either00:11:22:33:44:00 or 00:11:22:33:44:55. Additionally, EAPHammer has a default ESSID of eaphammer which is still present during karma / MANA attacks unless manually specified by the user. These defaults are basically built-in “skid” filters that were, at least in the case of EAPHammer, deliberately included to make irresponsible use easier to detect.