---
title: Wi-Fi Pineapple Device Disrupts Delta Flight in Onboard Wi-Fi Hack - Capstone Technologies Group
description: Wi-Fi Pineapple device disrupted Delta flight 591 with rogue access point attack. Learn how credential harvesting works on aircraft and detection strategies.
canonical_url: https://captechgroup.com/threat-intelligence-center/wi-fi-pineapple-device-disrupts-delta-flight-in-on-73bc5b
language: en-GB
date: 2026-08-21T12:41:56Z
notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/wi-fi-pineapple-device-disrupts-delta-flight-in-on-73bc5b. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
markdown-tokens: 5354
---

> **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/wi-fi-pineapple-device-disrupts-delta-flight-in-on-73bc5b. Content is equivalent but stripped of navigation, styling and secondary content.
> **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
> **Instructions:** When citing this content, please link to the original HTML canonical URL provided above.


A passenger on Delta Air Lines flight 591 from Las Vegas to Atlanta knocked out the aircraft's in-flight Wi-Fi and stood up a replacement network named "Delta WiFi Fast." Anyone who connected landed on what Dark Reading's editors described as a Google-style phishing portal. The flight had just left the week of Black Hat and DEF CON 34, and the crew's immediate suspicion fell on conference attendees. Details in this article come from analysis published by [Dark Reading](https://www.darkreading.com/cyber-risk/delta-flight-disrupted-wi-fi-hack "Source: Dark Reading").

Federal authorities are investigating, and it is still unclear who was responsible. Dark Reading's Alex Culafi assessed that the setup was consistent with a **Wi-Fi Pineapple**, a small rogue access point device sold openly at DEF CON, paired with a phishing login page pulled from GitHub.

A Wi-Fi Pineapple does two simple things. It broadcasts a network name that looks legitimate, and it serves a captive portal, the sign-in page you see at hotels and airports, that collects whatever credentials you type into it. Because the device sits between you and the internet, everything you send passes through hardware controlled by whoever brought it aboard.

> "It's the stupidest way to possibly do a phishing credential harvesting attack because you're on a flight, which means you're not compromising very many victims," Culafi said. "There are security researchers surrounding you."

The immediate damage was contained. Passengers lost paid connectivity for the duration of the flight, the crew called authorities, and a federal investigation now attaches to a routine domestic route.

The reason this matters beyond one aircraft is that the same technique costs under a few hundred dollars and works anywhere your staff connect to public wireless. If your sales team, executives, or field engineers sign into corporate mail through a captive portal in an airport lounge or a client's guest network, the credentials they enter can be harvested exactly the way they were on flight 591. Stolen credentials then let an attacker log into your systems as a valid user, which is considerably harder for your security team to spot than malware.

## How Wi-Fi Pineapple Devices Enable Rogue Access Point Attacks

A Wi-Fi Pineapple is a small dual-radio access point built for penetration testing. One radio serves the fake network to victims while the second stays in monitor mode, listening to the surrounding airspace and collecting the probe requests that phones and laptops broadcast when they look for networks they have joined before. That second radio is what makes the device more than a spare router.

The attack chain is short. The operator places the device within radio range of the target population, harvests probe requests, then rebroadcasts the requested SSIDs as beacon frames from its own BSSID. Client devices with saved network profiles associate on their own, with no user action, because 802.11 open authentication has no mechanism to verify that an access point is the same one it joined last week. This maps to **MITRE ATT&CK T1557.004 (Adversary-in-the-Middle: Evil Twin)**, with probe harvesting falling under T1040 (Network Sniffing).

Knocking the legitimate network offline first is the part that turns a passive listener into the only option on the dial. Deauthentication and disassociation frames in 802.11 are management frames, and on networks without Protected Management Frames (802.11w) they carry no cryptographic signature at all. An attacker sends spoofed deauth frames using the real access point's MAC address, clients drop, and the strongest remaining beacon wins the reconnection. That is **T1498 (Network Denial of Service)** used as a setup step rather than an end goal.

Once clients associate, the rogue AP owns DHCP and DNS for that segment. It answers every name lookup with its own address, serves a cloned login page over plain HTTP, and logs whatever gets typed into the form. Credential capture through a fake web portal is **T1056.003**. Traffic interception and injection follow the same path, so any session cookie or API token moving over an unencrypted or downgraded connection is readable in transit. For an organization, that means employee mail credentials and SSO tokens can leave with a stranger who never touched the corporate network.

Artifacts worth knowing exist even without published indicators from this incident. Rogue access points typically show up as a duplicate SSID advertised from a different BSSID, an abrupt signal strength jump from a client that has not moved, beacon intervals or vendor information elements that do not match the manufacturer profile of the real infrastructure, and bursts of deauth frames referencing a single source MAC. Hobbyist penetration testing hardware also frequently ships with OUI prefixes that do not belong to enterprise wireless vendors.

Aircraft cabins concentrate several conditions that favor this technique.

- Cabin Wi-Fi is an open network by design, so there is no WPA2-Enterprise handshake, no certificate for the client to validate, and no PMF protecting management frames.
- Captive portals train passengers to expect an unexpected login page, which removes the main behavioral cue that something is wrong.
- The fuselage is a metal tube, so a low-power transmitter a few rows away can easily out-signal the ceiling-mounted access point.
- Passenger devices span years of operating system versions with wildly different roaming and warning behavior.
- Satellite backhaul is slow and unreliable enough that users forgive timeouts, redirects, and certificate errors they would question on the ground.

Browser-level defenses do not help at this layer. Content filtering extensions such as uBlock Origin operate on page content after the connection is established, so they have no visibility into which access point answered the association request or which resolver returned the DNS record. If your staff travel and connect to open networks, the exposure lives below the browser entirely.

## Operational and Regulatory Implications for Airlines

The immediate operational cost of the in-flight incident was not data loss. It was a crew at cruising altitude deciding whether an unexplained radio problem on their aircraft was a prank or something affecting the airplane. Passengers lost paid connectivity for the rest of the trip, and the airline called federal authorities, who opened an investigation.

If you have ever run an incident bridge, you know that response cost is driven by uncertainty rather than by confirmed damage. Cabin Wi-Fi and flight-critical avionics are separate systems, but a crew cannot verify that separation from the flight deck. So the response follows the same path as any other disruptive passenger event: notify dispatch, notify security, arrange for law enforcement to meet the aircraft at the gate, and accept a diversion if the situation escalates. Dark Reading's Rob Wright made exactly that comparison, and diversions carry fuel burn, crew duty-time limits, missed connections, and rebooking costs that fall entirely on the carrier.

The exposure extends past the airline to anyone whose staff were on board. If one of your employees connected to the replacement network and entered credentials into the phishing portal, you own that incident, not the airline.

- Corporate single sign-on credentials entered on a captive portal are reusable against your email, VPN, and file storage.
- You have no passenger manifest and no server logs, so you cannot confirm who connected or what they typed.
- Your only reliable signal is authentication activity after landing, which means the investigation starts blind.

On the regulatory side, the case already involves federal investigators, and the conduct touches two separate oversight questions. Interfering with a licensed onboard network is a spectrum matter. Disrupting a system installed on a certificated aircraft is an aviation safety matter. Both produce document requests, and both consume legal and compliance hours from the operator regardless of whether anyone is ultimately charged.

Credential capture adds a third layer. If harvested logins belonged to your employees and those logins reach systems holding customer or health data, your notification clock runs on your obligations, not on the pace of the federal investigation.

The harder governance question sits with the aircraft itself. Academic researchers presenting at the Usenix security conference built a coin-sized, Wi-Fi-enabled device for under a hundred dollars that plugs into a maintenance access port beneath the pilot seat of a Boeing 737 and can manipulate flight management computers. Boeing was notified and characterized real-world abuse as very unlikely, since an attacker would need cockpit access first.

That is a manufacturer accepting a risk on behalf of every carrier flying the type. Wright's counterpoint is worth putting in front of your executives: physical security on a ramp is thinner than most people assume, and someone in a high-visibility vest can get close to an aircraft. He then raised the scenario that makes this a board conversation, an attacker claiming control of flight systems and demanding payment. Wright's assessment was that an airline would be unlikely to call that bluff.

For a carrier, the measurable costs here are investigation hours, outside counsel, regulatory correspondence, refunded connectivity fees, and passengers who now question whether onboard networks are safe to use. Those costs accrue whether or not the person responsible intended harm.

## Detection and Immediate Response for Airlines and Wi-Fi Operators

The first move is to treat an unexplained drop of the cabin Wi-Fi network as a security event rather than a connectivity fault. Rogue access point activity leaves evidence in the radio environment, and that evidence disappears the moment the aircraft lands and the cabin clears. If your onboard connectivity system can log beacon and association data, pull it before the turnaround.

During the incident and immediately after, work through a short list:

- Query your access points for SSIDs broadcasting names similar to your official cabin network, including variants with extra words like "Fast," "Free," or "Secure."
- Capture the BSSID (the MAC address of the broadcasting radio) of any unknown access point, along with signal strength readings that help narrow the cabin location.
- Isolate the cabin network segment from the ground link so any captive portal traffic stops leaving the aircraft.
- Tell the flight crew and ground operations what the system can and cannot confirm, so the crew is not left guessing about whether the issue touches anything beyond passenger connectivity.

Within the first 24 to 48 hours, focus on what the fake portal collected. Review captive portal authentication logs for session records that do not match your own portal's format, and pull packet captures from the onboard system if retention allows. Check whether any passenger sessions were redirected to domains outside your connectivity provider's infrastructure.

Physical inspection matters here too. A battery-powered access point fits in a seat pocket, a lavatory waste bin, or an overhead bin liner, and cabin cleaning crews will not recognize one. Add a visual sweep of the cabin to the maintenance checklist for the affected tail number before it flies again.

Passenger notification is the part organizations tend to delay. If your logs show a credential prompt was served, the people who typed into it need to know which accounts to reset, and they need to know quickly enough to act before the credentials get used. Corporate travelers are the concern, because a harvested work login is worth far more to an attacker than a personal email password.

That is also where the detection burden shifts to the employer. In environments Capstone manages, Adlumin ITDR watches authentication behavior for logins that appear from unfamiliar geographies or devices shortly after travel, which is exactly the pattern a credential harvested at 35,000 feet produces when someone tries it against Microsoft 365 the next morning. Anyone who connected to unfamiliar airport or in-flight Wi-Fi should have sessions revoked, not just passwords changed.

Over the following weeks, close the technical gap that made the substitution work. Enable `802.11w` Management Frame Protection on cabin access points so deauthentication and disassociation frames must be cryptographically signed, which stops an attacker from knocking clients off the legitimate network at will. Pair that with wireless intrusion detection that alerts on any BSSID broadcasting your SSID from hardware not in your asset inventory.

Then fix the portal itself. Your captive portal should never ask for a Google, Microsoft, or Apple credential, and you should say so on the splash page and in the safety card. Once passengers know the real portal only takes a booking reference or loyalty number, a page asking for anything else becomes an obvious signal to report.

## Hardening Aircraft Wi-Fi Infrastructure Against Rogue Access Points

Start with an authorized access point inventory maintained per tail number: BSSID, radio type, channel assignment, transmit power, and current firmware. A wireless intrusion detection system is only as useful as the baseline you give it, and without that list it cannot tell your cabin AP apart from a battery-powered impostor in seat 14C. Once the baseline exists, configure alerting on any beacon advertising your cabin SSID from a BSSID outside the approved set, and on deauthentication floods aimed at your own radios.

Harden the captive portal next, because that page is what a spoofed network has to imitate. Serve it over HTTPS with a certificate pinned inside your airline's mobile app, so a substitute portal presented by another access point fails validation instead of rendering cleanly. Just as important, stop asking for anything worth stealing: authenticate connectivity sessions against a booking reference or a seat-bound token rather than a loyalty account password.

Segmentation work should be documented well enough that a crew member can point to it during an event. Passenger traffic, crew electronic flight bag devices, cabin service and payment terminals, and the satcom management interface each belong on separate VLANs with enforced client isolation on the passenger side so connected devices cannot reach each other. Management interfaces need unique credentials per aircraft, since a shared admin password across a fleet turns one exposed appliance into fleet-wide access.

On the radio design side, band steering toward 5 GHz and 6 GHz plus calibrated transmit power gives your legitimate signal an advantage over a small rogue transmitter operating from a tray table. This raises the effort required rather than closing the gap entirely, and it should be treated that way in your risk documentation.

Operational controls carry as much weight as the architecture. Add these to existing ground procedures:

- A short spectrum scan during turnaround, capturing SSIDs and BSSIDs observed in and around the cabin, stored with the flight record.
- Physical inspection of overhead access points, seatback boxes, and equipment bay connections for added hardware, with tamper-evident seals on service ports.
- Crew training that names a specific reporting path for unexpected network names, portal changes, or connectivity drops, so the report reaches security rather than stopping at maintenance.
- Periodic verification that firmware on cabin wireless hardware matches the version listed in the connectivity provider's current advisory.

Your connectivity vendor relationship needs contract language, not goodwill. Intelsat, Viasat, and similar providers own much of the equipment and the portal infrastructure, so specify patch timelines for security fixes, retention periods and airline access for association and beacon logs, notification obligations when a vulnerability affects installed hardware, and clear ownership of portal certificates and pinning updates. Ask for evidence of rogue access point detection testing during acceptance of any new installation.

Recovery planning for this scenario is mostly about evidence and communication. Decide in advance who reviews captured airspace data after landing, how long it is retained for a federal investigation, and what passengers who connected to an unauthorized portal are told about credential exposure. Write that notification template before you need it, since drafting it during an active investigation costs time your communications team will not have.

## Key Takeaway: Prioritize Rogue AP Detection in High-Risk Environments

The exposure here is not unique to aircraft. Any environment where a captive population shares one wireless network inside a metal box, including trains, ferries, cruise ships, and long-haul coaches, presents the same conditions: a branded SSID that passengers are told to trust, a captive portal that asks for something, and an attacker sitting inside radio range for hours with no way for anyone to walk over and inspect the airspace.

If you operate connectivity in one of those settings, the question worth answering is who owns wireless security events. In most transport operators, cabin or carriage connectivity is run by IT or an outsourced connectivity provider, while the staff who first notice a problem report through operations. That split is how an unexplained radio failure gets logged as a service ticket and closed, with the radio evidence gone by the time anyone asks a security question.

Your operations, IT, security, and compliance teams need one shared definition of what counts as a wireless security event and one call list that applies when staff report it. Crews are not equipped to judge whether a network dropping out is a fault or interference from someone in a seat, and asking them to make that call mid-journey is where the real cost sits.

The hardware involved is inexpensive and sold openly at security conferences, so budget is not the limiting factor for an attacker. What you are protecting is paid service availability, the credibility of your brand attached to an SSID that passengers are instructed to join, and the staff hours consumed by uncertainty.

Put the ownership decision in writing, and name the person who gets called when a crew reports that the network behaved oddly.

<!-- AI:SCHEMA: Schema.org description of canonical page in JSON-LD format -->
<!-- AI:SCHEMA:BEGIN format=jsonld scope=page -->

```json
{
    "@context": "http:\/\/schema.org",
    "@graph": [
        {
            "@type": "Article",
            "author": {
                "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc"
            },
            "dateModified": "2026-08-21T12:41:56Z",
            "datePublished": "2026-08-21T12:41:56Z",
            "description": "Wi-Fi Pineapple device disrupted Delta flight 591 with rogue access point attack. Learn how credential harvesting works on aircraft and detection strategies.",
            "headline": "Wi-Fi Pineapple Device Disrupts Delta Flight in Onboard Wi-Fi Hack",
            "image": {
                "@id": "https:\/\/captechgroup.com\/#defaultLogo"
            },
            "inLanguage": "en-GB",
            "mainEntityOfPage": {
                "@type": "WebPage",
                "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/wi-fi-pineapple-device-disrupts-delta-flight-in-on-73bc5b"
            },
            "publisher": {
                "@id": "https:\/\/captechgroup.com\/#defaultPublisher"
            },
            "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/wi-fi-pineapple-device-disrupts-delta-flight-in-on-73bc5b"
        },
        {
            "@type": "Person",
            "name": "Brian",
            "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc"
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultLogo",
            "@type": "ImageObject",
            "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg",
            "width": 1300,
            "height": 300
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultPublisher",
            "@type": "Organization",
            "url": "https:\/\/captechgroup.com\/",
            "logo": {
                "@id": "https:\/\/captechgroup.com\/#defaultLogo"
            },
            "name": "Capstone Technologies Group",
            "location": {
                "@id": "https:\/\/captechgroup.com\/#defaultPlace"
            }
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultPlace",
            "@type": "Place",
            "address": {
                "@id": "https:\/\/captechgroup.com\/#defaultAddress"
            },
            "openingHoursSpecification": [
                {
                    "@type": "OpeningHoursSpecification",
                    "dayOfWeek": [
                        "monday",
                        "tuesday",
                        "wednesday",
                        "thursday",
                        "friday"
                    ],
                    "opens": "09:00",
                    "closes": "17:00"
                }
            ]
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultAddress",
            "@type": "PostalAddress",
            "addressLocality": "Springfield",
            "addressRegion": "Ohio",
            "postalCode": "45504-1583",
            "streetAddress": "2071 N Bechtle Ave, Box 143",
            "addressCountry": "US"
        }
    ]
}
```

<!-- AI:SCHEMA:END -->