Hak5 WiFi Pineapple Volume 19 — Tooling, Integrations & Cloud C2 Fleet Ops — Wi-Fi Pineapple · Hacking

The host-side analysis pipeline, the tools the Pineapple pairs with, and running one or many units through Cloud C2

19.1 About this volume

Vol 19 covers everything the Pineapple connects to: the off-device analysis pipeline (the Pineapple captures; your host cracks and analyses — Vol 7 §7), the tools it pairs with, and Cloud C2 as both single-unit remote control and fleet orchestration.

This volume answers a question from the original brief directly — what tools does each model work well with — and it does so by way of a principle established in Vol 7 §7 and reinforced through every per-model volume: the Pineapple is the front end; the heavy lifting is off-device. A Pineapple captures; it does not crack. A Pineapple records; your laptop analyses. Understanding the Pineapple’s tooling means understanding that division of labour.

Foundation cross-refs: Vol 5 §5 (the Cloud C2 foundation), Vol 7 §7 (the modest-on-device-compute design rationale), Vol 8 §4 (capture-data discipline).

19.2 The host-side analysis pipeline

The Pineapple produces captures — handshakes, probe logs, association logs, PCAPs (Vol 3 §5, Vol 10 §3’s Automatic Handshake Capture). Those captures are raw material; turning them into findings happens off-device:

   The capture -> analysis pipeline
   ════════════════════════════════════════════════════════

   ON the Pineapple                OFF the Pineapple
   ────────────────                ─────────────────
   recon ──────────► captures ────► EXPORT ────► host analysis
   PineAP            (handshakes,                 │
   handshake cap     probe logs,    ┌─────────────┴─────────────┐
   client tracking   assoc logs,    │ PCAP analysis (Wireshark/ │
                     PCAPs)         │   tshark)                 │
                                    │ probe-log analysis        │
   Campaigns ──────► on-device      │ handshake cracking (§3)   │
                     SUMMARY        │ correlation, reporting    │
                     (Vol 5 §4)     └───────────────────────────┘

   The Campaigns report is the ON-DEVICE summary — the
   skeleton. The HOST-SIDE analysis is the depth — the
   substance of the finding (Vol 17 §7).

The standard pipeline:

PCAP handling — packet captures move to a host and into Wireshark (interactive) or tshark (scriptable) for inspection.
Probe-log analysis — the probe and association logs (Vol 3 §5) are where client de-anonymisation and pattern analysis happen — and that is host-side scripting work, not an on-device feature.
Campaigns reports as the summary — the on-device Campaign report (Vol 5 §4) is the structured summary; it is the report skeleton, not the full analysis. The depth is built host-side from the raw captures.

The reason the pipeline is shaped this way is Vol 7 §7: the Pineapple’s on-device compute is deliberately modest (Vol 9 §3 — even the Enterprise’s quad-core ARM, Vol 14 §3, is for concurrency, not number-crunching). The device is sized for the capture front-end job; analysis is a host job by design.

19.3 Handshake cracking — off-device

The sharpest example of §2’s principle: handshake cracking is off-device, by design.

   Why cracking is off-device
   ════════════════════════════════════════════════════════

   Cracking a WPA handshake = brute-forcing / dictionary-
   attacking it — a compute-INTENSIVE, GPU-bound workload.

   The Pineapple's SoC (single-core MIPS on the Mark VII;
   even the Enterprise's quad-core ARM) is sized for the
   PROTOCOL work of PineAP — not for GPU-class brute force.

   So the pipeline is:
     1. CAPTURE the handshake on the Pineapple (Vol 3 §10,
        Vol 10 §3 Automatic Handshake Capture)
     2. EXPORT it off-device
     3. CRACK it on a GPU host — hashcat mode 22000 (the
        WPA-PMKID/EAPOL mode) on real GPU hardware

   The Pineapple is the SCALPEL that gets the handshake.
   The GPU box is the HAMMER that breaks it. Different
   tools, different jobs.

Cross-reference to avoid re-authoring: the mechanics of handshake cracking — hashcat mode 22000, the EAPOL/PMKID capture formats, GPU-time expectations, the dictionary-vs-brute-force tradeoffs — are shared 802.11 territory and are covered in depth in the [ESP32 Marauder Firmware deep dive Vol 9](/esp32-marauder/vol-9/) (). The Pineapple captures handshakes; how you crack them is the same as how you crack a handshake captured by any other tool. Read that volume for the cracking mechanics; this volume’s point is just where in the pipeline cracking sits — off the Pineapple, on a GPU host.

19.4 Tools the Pineapple pairs with

The “what tools does each model work well with” question, answered:

Table 1 — The "what tools does each model work well with" question, answered

Tool	What it does for the Pineapple workflow
Wireshark / tshark	PCAP analysis — the captures the Pineapple produces, inspected and dissected on a host
hashcat	handshake cracking — mode 22000, on a GPU host (§3)
the aircrack-ng suite	shared 802.11 mechanics — handshake handling, capture-format conversion, the broader Wi-Fi-attack toolkit the Pineapple’s techniques are kin to
Kismet	a cross-check / second source for recon — a different recon tool to corroborate the Pineapple’s airspace picture
GPS tooling	for wardrive mapping (Vol 17 §2) — tagging the Pineapple’s recon data with location
the host laptop / browser	the web-UI client itself — the Pineapple is web-UI-driven (Vol 6 §2), so a host with a browser is a required “tool”
a GPU host	the cracking back-end (§3) — not optional for any engagement that captures handshakes to crack

Per-model notes:

Mark VII / + AC — the standard pairing: a laptop as the web-UI client and capture-export target, a GPU host for cracking. The MK7AC (Vol 11 §3) doubles as a standalone Linux Wi-Fi adapter, so it pairs with a Kali/Parrot laptop independently of the Pineapple.
Pager — pairs the same way for the web-UI depth (via its integrated ethernet adapter — Vol 12 §6), but the walk-around workflow (Vol 13 §5) is more self-contained — the on-device UI reduces the moment-to-moment dependence on a paired host. Captures still go off-device for analysis.
Enterprise — pairs at fleet scale (§6): the host-side pipeline is larger, the capture volumes bigger (Vol 15 §5), and Cloud C2 (§5-6) is often the pairing layer rather than a single laptop.

The throughline: the Pineapple does not replace the Wi-Fi-analysis toolkit — it feeds it. It is the best capture front-end in the lineup; the analysis is still Wireshark and hashcat and the rest, on a host.

19.5 Cloud C2 — single-unit remote operation

Hak5 Cloud C2 (Vol 5 §5) is the command-and-control server for operating Hak5 devices remotely. For a single Pineapple:

   Cloud C2 — single-unit model
   ════════════════════════════════════════════════════════

   self-hosted C2 server  ◄──────► enrolled Pineapple
        │                          (planted / deployed
        │                           somewhere you are not)
        ▼
   the operator, remote:
     • remote web-UI access — drive the device from afar
     • remote capture retrieval — pull loot without
       physically returning
     • device management — configure, run Campaigns remotely

   The deployment model: PLANTED UNIT + REMOTE OPERATOR.
   Drop a Pineapple; operate it from somewhere else.

This is what makes a planted Pineapple useful (Vol 17 §4, red-team) — without remote access, a planted device is only valuable if you can get back to it. C2 turns “deploy and return” into “deploy and operate remotely.”

The attack-surface caveat (Vol 6 §8) — stated because it must be: Cloud C2 is a remote path into the device. The C2 server, its enrollment tokens, its credentials, its network exposure are all part of the attack surface now. A C2-enrolled Pineapple is a Pineapple with a standing remote-access door. Self-host the C2 server, lock it down, treat its credentials as crown-jewels, and enroll a device only when remote operation is actually needed. A Pineapple that does not need C2 should not be enrolled in C2 — every enrollment is an added surface.

19.6 Cloud C2 — fleet operation

C2 managing multiple Pineapples — the Enterprise-scale / agency operating model (Vol 15 §6):

   Cloud C2 — fleet model
   ════════════════════════════════════════════════════════

   ONE C2 console  ◄──────► Pineapple A (Mark VII, site 1)
                   ◄──────► Pineapple B (Pager, mobile)
                   ◄──────► Pineapple C (Enterprise, rack)
                   ◄──────► ... a whole fleet ...

     • fleet enrollment — every device in one console
     • coordinated Campaigns — scripted audits across the fleet
     • centralised capture aggregation — loot from everywhere,
       collected in one place

   When the owner has one of each model (Vol 16 §7), Cloud
   C2 is HOW THEY ARE OPERATED AS A SET — the single pane of
   glass over the Mark VII + Pager + Enterprise.

For a multi-device owner, fleet C2 is the layer that makes “one of each model” into a kit rather than three separate devices. The Enterprise is the natural anchor of such a fleet (Vol 15 §6, §8) — its C2-native operating model and rack-install permanence make it the obvious central node.

Figure 1 — 1 — The fleet model, as Hak5 frames it: Pineapples (and the wider Hak5 gear family) distributed across sites, every one enrolled into a single Cloud C2 console. This is the operating pict… — Figure 1 — 1 — The fleet model, as Hak5 frames it: Pineapples (and the wider Hak5 gear family) distributed across sites, every one enrolled into a single Cloud C2 console. This is the operating picture of §6 — and the reason the C2 server is sensitive infrastructure (§5, Vol 20 §6): the same console that reaches the whole fleet is the whole fleet's single point of compromise. Image: Hak5 (shop.hak5.org).

The fleet-scale caveat is the single-unit caveat, multiplied: a compromised C2 server is now a compromised fleet — every enrolled device, at once. Fleet C2’s convenience (one console, the whole kit) is exactly proportional to its risk (one console, the whole kit, as a single point of compromise). The discipline from §5 — self-host, lock down, crown-jewel the credentials — scales up, not down, with the fleet. Vol 20 §6 carries the full standing-attack-surface posture.

19.7 Integrations within the lineup

How the Pineapple sits alongside the other Hack Tools (the structured view is ../_shared/comparison.md):

The ESP32 Marauder devices (AWOK Dual Touch V3, Flipper WiFi Devboard — ../ESP32 Marauder Firmware/) — overlapping Wi-Fi-attack scope, different form and depth. The Marauder devices do deauth / evil-portal / probe capture as features on a microcontroller; the Pineapple is the integrated Linux/OpenWrt platform with the PineAP engine, a real web UI, modules, Campaigns, and C2. Use a Marauder device for a quick pocket job; the Pineapple is the platform for a sustained, scoped, reportable engagement. Not redundant — the Pineapple is the depth tool. (The cracking mechanics shared between them are why §3 cross-references the Marauder Vol 9.)
HackRF / PortaRF (../HackRF One/, ../OpenSourceSDRLab PortaRF/) — RF breadth the Pineapple does not cover. The Pineapple is a Wi-Fi (and, on the Pager, BT) tool; it is not an SDR. RF reconnaissance of an environment, before or alongside a Pineapple engagement, is the SDR tools’ job.
Clockwork uConsole (../Clockwork uConsole/) — a portable Linux box that can be the Pineapple’s paired host: the web-UI client, the capture-analysis machine, even a self-hosted Cloud C2 node in the field. The uConsole + a Pineapple is a self-contained field kit.

The sibling Hak5 platform — the USB Rubber Ducky and the Ducky Script device family. The Pineapple attacks the wireless environment from a distance; the Ducky Script devices (USB Rubber Ducky, Bash Bunny, Key Croc, O.MG — ../Ducky Script/) attack a specific machine via physical-access keystroke injection. They share the Hak5 ecosystem (Cloud C2, the product line) and the same high-consequence posture class, but cover orthogonal attack surfaces. A physical-access engagement commonly stages both — for example, a Ducky Script payload that re-points a target host’s Wi-Fi at a Pineapple-hosted rogue AP, handing the machine’s traffic to the Pineapple. The full treatment of that combined workflow is the [Ducky Script deep dive Vol 14](/ducky-script/vol-14/) (“Combined-Device & Combined-Tool Workflows”), and it links back to this series; the Ducky Script deep dive is at.

19.8 Resources

Hak5 Cloud C2 docs: https://docs.hak5.org/cloud-c2
Vol 5 §5 — the Cloud C2 foundation · Vol 7 §7 — the off-device-compute design rationale · Vol 8 §4 — capture-data discipline
Vol 15 §6 — Cloud C2 at fleet scale on the Enterprise
Vol 17 §7 — capture handling and reporting across the playbooks
../ESP32 Marauder Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html — shared cracking / 802.11 mechanics (Vol 9 there)
../Ducky Script/03-outputs/DuckyScript_Complete.html — the sibling Hak5 platform (physical-access keystroke injection); its Vol 14 is the combined-workflow treatment
../_shared/comparison.md — the cross-tool decision matrix

This is Volume 19 of a 21-volume series. Next: Vol 20 — Operational Posture in the Field: field OPSEC, detection signatures, per-model posture, regional RF reality, the device’s own attack surface, and the discovery-and-response protocol.

Hak5 WiFi Pineapple Volume 19 — Tooling, Integrations & Cloud C2 Fleet Ops