Wi-Fi Pineapple · Volume 19
Hak5 WiFi Pineapple Volume 19 — Tooling, Integrations & Cloud C2 Fleet Ops
The host-side analysis pipeline, the tools the Pineapple pairs with, and running one or many units through Cloud C2
Contents
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).
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.
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%20Marauder%20Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html#vol09) (). 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.
4. Tools the Pineapple pairs with
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.
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.
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 tjscientist owns 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.
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.
7. Integrations within tjscientist’s 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%20Script/03-outputs/DuckyScript_Complete.html#vol14) (“Combined-Device & Combined-Tool Workflows”), and it links back to this series; the Ducky Script deep dive is at.
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.