The KARMA Attack: How It Exploited WiFi Probe Requests

What Was KARMA?

In 2004, security researchers Dino Dai Zovi and Shane Macaulay presented a technique that would haunt WiFi networks for over a decade. They called it KARMA - and it exploited a fundamental flaw in how wireless devices search for known networks.

The concept was deceptively simple. Every WiFi-enabled laptop at the time broadcast a list of networks it had previously connected to. KARMA listened for those broadcasts and responded to every single one, pretending to be whatever network the device was looking for. The device, believing it had found a trusted network, connected automatically - handing its traffic to the attacker.

At the time, this was devastating. Laptops in coffee shops, airports, and conference centers were constantly shouting the names of their home networks, office networks, and hotel networks into the air. KARMA answered every call.

Probe Requests Explained

To understand KARMA, you need to understand probe requests. When a WiFi device is not connected to a network, it does one of two things: it passively listens for beacon frames from access points, or it actively sends probe requests asking if specific networks are nearby.

In 2004, most devices used active probing exclusively. They maintained a Preferred Network List (PNL) - a record of every WiFi network the device had ever connected to. The device would cycle through this list, broadcasting each SSID in turn: "Is HomeNetwork here? Is OfficeWiFi here? Is HiltonHonors here?"

graph TD
    subgraph "Normal WiFi Connection"
        A[Laptop Powers On] --> B[Broadcasts Probe Request - HomeNetwork]
        B --> C[Broadcasts Probe Request - OfficeWiFi]
        C --> D[Broadcasts Probe Request - CoffeeShop]
        D --> E{Matching AP Responds?}
        E -->|Yes| F[Probe Response Received]
        F --> G[Authentication Exchange]
        G --> H[Association Complete]
        E -->|No| I[Continue Scanning]
        I --> B
    end

Normal WiFi probe request cycle - the device broadcasts saved SSIDs looking for known networks

Each probe request was sent as an unencrypted management frame. Anyone within radio range could read the SSID being requested. This meant that a passive observer could build a list of every network a device had ever joined - including home network names, employer names, hotel chains, and more.

The privacy implications alone were significant. But KARMA went further.

How KARMA Worked Step by Step

KARMA operated as a rogue access point with a critical modification: instead of advertising a single SSID, it listened for probe requests and dynamically responded to each one with a matching probe response.

When a laptop broadcast "Is HomeNetwork here?", KARMA responded "Yes, HomeNetwork is right here." When another device asked for "CorpWiFi-5G", KARMA responded to that too. It answered every probe request affirmatively, regardless of the SSID.

graph TD
    subgraph "KARMA Attack Flow"
        A[Victim Laptop] -->|Probe: HomeNetwork?| B[KARMA AP]
        B -->|Response: Yes I am HomeNetwork| A
        A -->|Associate to HomeNetwork| B
        B --> C[DHCP Assignment]
        C --> D[DNS Interception]
        D --> E[Full MITM Position]
        E --> F[HTTP Traffic Visible]
        E --> G[DNS Queries Logged]
        E --> H[Credentials Captured]
    end
    subgraph "Simultaneous Victims"
        I[Phone] -->|Probe: CoffeeShop?| B
        J[Tablet] -->|Probe: HotelWiFi?| B
    end

KARMA attack flow - the rogue AP answers every probe request with a matching SSID

The technical implementation required modifications to the access point's hostapd configuration and driver. The original KARMA patch modified the MadWifi driver to respond to probe requests with the requested SSID rather than its own configured SSID. On association, the access point would accept the client regardless of what SSID it requested.

Once associated, the victim's traffic flowed through the attacker's access point. The attacker controlled DHCP (assigning IP addresses), DNS (resolving domain names), and the default gateway (routing all traffic). This gave them a complete man-in-the-middle position.

The Attack in Action

Picture a busy airport terminal in 2005. A security researcher sets up a laptop running KARMA near the gate area. Within minutes, devices start connecting automatically. No user interaction is required - the laptops and early smartphones connect on their own because they believe they have found a familiar network.

The attacker's machine now sees all HTTP traffic in cleartext. In 2005, almost nothing used HTTPS. Email clients connected via unencrypted POP3 and IMAP. Webmail ran over HTTP. Corporate VPN credentials were sometimes sent before the tunnel was established. FTP sessions, instant messaging, and web browsing - all visible.

The attack was particularly effective in locations where people traveled with devices that had accumulated long PNLs. Business travelers were prime targets. Their laptops had connected to dozens of hotel networks, airport networks, and client office networks. Each saved SSID was another opportunity for KARMA to match.

graph LR
    subgraph "Victim PNL Exposure"
        A[Laptop PNL] --> B[Home-WiFi-5G]
        A --> C[Marriott_GUEST]
        A --> D[ACME-Corp]
        A --> E[JFK-FreeWiFi]
        A --> F[Starbucks]
    end
    subgraph "KARMA Response"
        B --> G[KARMA Responds to All]
        C --> G
        D --> G
        E --> G
        F --> G
    end
    subgraph "Result"
        G --> H[Auto-Association]
        H --> I[Traffic Interception]
    end

A single device may broadcast dozens of saved SSIDs - KARMA answers every one

Evolution to MANA

KARMA was effective, but it had limitations. As operating systems began implementing basic protections, researchers developed more sophisticated variants. The most notable was MANA (More Advanced Nefarious Access point), presented by Dominic White and Ian de Villiers at DEF CON 22 in 2014.

MANA improved on KARMA in several ways. It implemented a "loud mode" that not only responded to directed probe requests but also broadcast beacon frames for every SSID it had observed. This meant that even devices using passive scanning (listening for beacons rather than actively probing) could be captured.

MANA also added a feature called EAP (Extensible Authentication Protocol) harvesting. When enterprise devices probed for WPA-Enterprise networks, MANA would set up a fake RADIUS server and attempt to capture credential hashes during the authentication handshake. These hashes could then be cracked offline.

Other tools built on the KARMA concept include hostapd-mana (an actively maintained fork of hostapd with KARMA and MANA features) and WiFi Pumpkin, which provided a graphical interface for conducting these attacks during authorized penetration tests.

Modern Mitigations

The industry eventually responded to KARMA, though it took over a decade for comprehensive mitigations to appear.

The most significant mitigation was the elimination of directed probe requests for saved networks. Starting with iOS 8 (2014) and gradually adopted by Android and Windows, devices stopped broadcasting their full PNL. Instead, they used wildcard probe requests (with an empty SSID field) that asked "Is anyone there?" without revealing specific network names. Access points responded with their own SSIDs, and the device checked internally whether any matched its saved list.

MAC address randomization added another layer of protection. iOS 14 (2020) and Android 10 (2019) introduced per-network randomized MAC addresses by default. This prevented attackers from tracking devices across locations based on their hardware address, even if they could observe probe requests.

However, these mitigations are not complete. Research has shown that some devices still send directed probes under certain conditions - particularly when connecting to hidden networks (which require directed probes by design). Older devices that have not received updates remain vulnerable. And some operating systems still leak information through the timing and patterns of their probe behavior, even without revealing specific SSIDs.

Scanning Probes With the BLEShark Nano

The BLEShark Nano can scan for WiFi probe requests in your environment, showing you exactly what devices are broadcasting and what SSIDs they are requesting. This capability serves two purposes in authorized security work.

First, it reveals which devices in your environment are still sending directed probe requests with specific SSIDs. If employee devices are broadcasting corporate network names outside the office, that is an information leak that should be addressed through device configuration policies.

Second, it demonstrates the attack surface to stakeholders who may not understand the risk. Showing a non-technical audience that their phones are broadcasting network names they connected to years ago makes the threat concrete and understandable.

The Nano's compact form factor (powered by the ESP32-C3 with 2.4GHz WiFi capabilities) makes it practical to carry during physical security assessments and site surveys. You can walk through an office, a lobby, or a conference venue and map probe request activity in real time.

Lessons Learned

KARMA taught the security community several lasting lessons. The first is that convenience features in wireless protocols often create exploitable attack surfaces. Auto-connection to saved networks was designed for user convenience, but it created a mechanism for automatic compromise.

The second lesson is that protocol-level information leaks compound over time. A single probe request reveals a network name. Thousands of probe requests over hours reveal travel patterns, employer identity, and daily routines. The metadata is often more valuable than any single piece of data.

The third lesson is that mitigations take years to deploy fully. KARMA was demonstrated in 2004. Meaningful probe request protections did not appear until 2014. MAC randomization defaults did not arrive until 2019-2020. That is a 15-year window during which the attack remained viable against most devices.

For security professionals, KARMA remains a relevant case study. The underlying principle - that devices will automatically trust and connect to anything that matches their expectations - applies far beyond WiFi. Bluetooth pairing, NFC interactions, and certificate validation all face versions of the same problem: automated trust decisions that can be exploited by an attacker who provides the expected response.