Wi-Fi Pineapple · Volume 8
Hak5 WiFi Pineapple Volume 8 — Operational Posture: OPSEC, Capture Discipline, and the Pre-Engagement Checklist
The practical companion to Vol 4's legal line — how to actually run a Pineapple engagement without harming yourself, your client, or bystanders
Contents
1. About this volume
Vol 4 drew the legal line — what you may do. This volume is the practical companion — how you actually run an engagement without crossing it by accident, without leaving a mess, and without turning the Pineapple’s own capabilities back on yourself.
This is the foundation-level posture. It applies to all four models. The per-model volumes (10, 13, 15) carry model-specific posture notes; the synthesis Vol 20 is the deeper field-OPSEC + detection-signature treatment. If you read Vol 4 and Vol 8, you have the posture; Vol 20 is the elaboration.
The framing throughout: the WiFi Pineapple is the most consequential tool in this hub. The discipline isn’t bureaucratic overhead — it’s the difference between “penetration tester” and “defendant,” and between “trusted professional” and “the person who leaked a building’s worth of credentials.”
2. The authorization artifact, operationalized
Vol 4 § 10 defined what written authorization is. This is how you operate with it:
- Have it on you, physically, during the engagement. Not just an email on a laptop you might not be able to open — a copy you can produce when challenged (§ 9).
- It names the scope — specific SSIDs, BSSIDs, MAC ranges, physical locations, the time window, and which escalations are permitted (recon only? active PineAP? deauth? credential-capturing portals?). Every one of those should be explicit, because the Pineapple makes every one of them a UI toggle.
- It’s signed by someone who can actually grant it — the system/network owner or their authorized agent. “The site manager said okay” is not authorization to attack the corporate Wi-Fi.
- It has a live contact — a name and number for someone on the client side who can confirm, in real time, that you’re authorized, if security or law enforcement asks (§ 9).
For tjscientist’s primary planned use — his own networks and devices, and blue-team watching his own airspace — the authorization is ownership, and the artifact is trivial. The discipline in this section bites the moment the work touches anything he doesn’t own.
3. Scope discipline — keeping an authorized engagement authorized
The single most common way a lawful engagement becomes an unlawful one isn’t malice — it’s scope drift. The Pineapple’s technique catalog (Vol 3) is broad-by-default; staying in scope is active work:
| Scope risk | The discipline |
|---|---|
| Broadcast-target active operations | Vol 3 § 9 — set Source/Target MAC to the specific authorized devices. Broadcast-target PineAP attacks every device in radio range, and an engagement can’t authorize you to attack bystanders. Broadcast-target ≈ out of scope, almost always. |
| Auto-capture-and-broadcast SSID pool | Vol 3 § 8 — open capture-to-pool + broadcast-pool harvests and beacons everyone’s SSIDs. For a scoped engagement, hand-set the in-scope SSID(s) in the pool; don’t run the indiscriminate loop. |
| Deauth blast radius | Vol 3 § 10 — deauth is DoS. Targeted deauth at an authorized device is in-scope; a deauth flood hits the whole channel. |
| ”While I’m here” creep | The engagement authorizes these assets. Not the interesting AP next door, not the device that wandered into range. If it’s not in the artifact (§ 2), it’s not in scope. |
| Time-window drift | The authorization has a start and end. Active operations outside the window are unauthorized operations. |
The mental model: the authorization is a box. The Pineapple’s defaults spill outside it. Your job, continuously, is to keep the operations inside the box — and the targeting controls (Vol 3 § 9) are the tool that lets you.
4. The device’s own attack surface
A Pineapple in the field is itself a target — it’s a wireless interception platform sitting in (often hostile) airspace, and if an adversary owns it, they own everything it’s collecting and everything it can do.
| Surface | The risk | The discipline |
|---|---|---|
| Management interface (web UI / SSH) | Reachable management = adversary control of an interception device | Use the firmware’s Management UI Firewall (Vol 5 § 3, Vol 6 § 8). Never expose management to untrusted networks. Strong root password, changed from default at first boot. |
| The PineAP/operating radios | The device is, by design, transmitting and inviting connections | Understand that the device is findable (§ 7) — there’s no making an actively-PineAP-ing Pineapple invisible. |
| Modules | A module runs with device privileges (Vol 6 § 8) | Vet before installing. Hak5-official or maintained/source-visible community modules only. An untrusted module is an untrusted root process on your interception platform. |
| Cloud C2 | A remote-access path into the device (Vol 5 § 5) | Treat the C2 server, its enrollment tokens, and its exposure as sensitive infrastructure. A compromised C2 server = a compromised fleet. |
| Physical | An unattended Pineapple can be found, photographed, seized, or tampered with | Don’t leave it unattended in a way you can’t account for. Physical possession of the device = possession of its capture data (§ 5). |
The principle: operate the Pineapple as if the airspace is hostile — because during an engagement it is. The device that’s good at attacking Wi-Fi is, unhardened, good at being attacked.
5. Capture-data discipline — handling what the Pineapple collects
A Pineapple collects sensitive data about real people: probe logs (device MACs + the networks they trust — effectively location history and habits), captured handshakes (crackable network keys), intercepted traffic, captured credentials from portals. This is the highest-sensitivity data in the entire Hack Tools hub.
Capture-data discipline
════════════════════════════════════════════════
COLLECT only what scope authorizes
└─ Vol 3 § 9 targeting limits collection to in-scope devices.
The probe log will still pick up bystanders in range —
that's a known artifact to handle, not hoard.
PROTECT it at rest
└─ The device's storage + any host copies = encrypted.
Captured handshakes and credentials are crackable/usable
secrets. Treat them like the secrets they are.
MINIMIZE retention
└─ Keep capture artifacts only as long as the engagement
deliverable needs them. A pentest report cites findings;
it doesn't ship a raw dump of everyone's probe history.
PURGE bystander data — with documentation
└─ Note what was incidental, what was deleted. The probe log
WILL contain non-target devices; document the cull.
SANITIZE the device between engagements
└─ Wipe captures off the Pineapple before the next outing.
A Pineapple carrying last engagement's data into this
engagement is a breach waiting to happen.
CHAIN OF CUSTODY for anything that's evidence
└─ Hash capture files at capture time; encrypted transfer;
out-of-band hash verification for engagement deliverables.The probe log deserves a specific note: it is, by its nature, a list of bystanders’ devices and the networks they trust. Even a perfectly scoped active engagement will passively log bystanders in radio range. That’s an expected artifact — the discipline is to recognize it, not retain it, and document the cull.
6. RF reality — your transmissions don’t stop at the property line
A constraint that operators consistently underestimate: RF doesn’t respect boundaries. The Pineapple’s beacons, probe responses, and deauth frames propagate as far as the RF propagates — through walls, across property lines, into the building next door.
The consequences:
- “It’s my own network” has an RF edge (Vol 4 § 9). Your KARMA AP in your home office can be heard — and associated to — by a neighbor’s device. Your deauth frames hit whatever’s on the channel, not whatever’s on your property.
- A scoped engagement has an RF edge. Even targeted operations radiate. Targeting (Vol 3 § 9) controls who you act on, but the RF still goes everywhere. Targeting limits the legal/scope exposure; it doesn’t contain the radiation.
- The only real containment is physical. A shielded room / Faraday environment is the only way to truly keep Pineapple RF inside a boundary. Short of that: low power, targeted operation, and awareness that bystander devices in range are a real factor.
This is why Vol 4’s grey-areas section (§ 9) kept collapsing back to “whose devices are in RF range” — because RF range, not property line, is the real boundary of a Pineapple’s effect.
7. Detection — the Pineapple is loud, and that’s the point sometimes
A Pineapple running active PineAP is detectable — and an operator has to know the signatures, for two opposite reasons.
As the operator (red/pentest): you should assume a competent blue team will see you. The signatures (Vol 4 § 7, Vol 20):
- A single BSSID answering probes for many SSIDs — no real AP does that. That’s KARMA.
- A flood of SSIDs from one device — that’s Broadcast SSID Pool / “Dogma”.
- A storm of deauth frames — one of the most recognizable hostile signatures in Wi-Fi.
- Two APs, same SSID, different BSSID, one in the wrong place — that’s an evil twin.
“Stealthy” Pineapple operation does not mean invisible — it means surgical: Beacon Response instead of pool broadcast, tight targeting instead of broadcast, minimal deauth. You reduce the signature; you don’t erase it.
As the defender (blue): those exact signatures are what your own recon-mode Pineapple watches for (Vol 4 § 7). The detectability that’s a liability for the red operator is the entire mechanism of the blue use.
The honest framing: the Pineapple is not a stealth instrument. It’s a capable instrument. An operator who needs true stealth has chosen the wrong tool — or needs to operate it surgically and accept the residual signature.
8. The pre-engagement checklist
Run this before any deliberate Pineapple use beyond passive recon of your own airspace:
┌──────────────────────────────────────────────────────────┐
│ WIFI PINEAPPLE — PRE-ENGAGEMENT CHECKLIST │
├──────────────────────────────────────────────────────────┤
│ AUTHORIZATION │
│ [ ] Written authorization in hand (physical copy) │
│ [ ] Scope explicit: SSIDs / BSSIDs / MACs / locations │
│ [ ] Permitted escalations explicit (recon? PineAP? │
│ deauth? credential portals?) │
│ [ ] Time window confirmed; alarm set for the end │
│ [ ] Live client-side contact available (for § 9) │
├──────────────────────────────────────────────────────────┤
│ DEVICE │
│ [ ] Firmware on a known-good version; NOT updating into │
│ the engagement │
│ [ ] Root password changed from default │
│ [ ] Management UI Firewall on; management not exposed │
│ [ ] Modules: only vetted ones installed │
│ [ ] Storage sanitized — no prior engagement's data │
│ [ ] Radios role-assigned correctly for the plan (Vol 7) │
│ [ ] Power sorted (USB-C pack / Pager charged / mains) │
│ [ ] Cloud C2: enrolled + C2 server secured, OR disabled │
├──────────────────────────────────────────────────────────┤
│ SCOPE CONTROLS │
│ [ ] Source/Target MAC set to in-scope targets │
│ [ ] SSID pool hand-set to in-scope SSID(s) — not open │
│ auto-capture-and-broadcast │
│ [ ] Beacon Response (surgical) chosen over Broadcast │
│ Pool unless scope explicitly covers broad operation │
├──────────────────────────────────────────────────────────┤
│ DATA + EXIT │
│ [ ] Capture destination + encryption plan set │
│ [ ] Retention + bystander-purge plan set │
│ [ ] Post-engagement sanitization plan set │
│ [ ] Discovery-response plan rehearsed (§ 9) │
├──────────────────────────────────────────────────────────┤
│ If any AUTHORIZATION or SCOPE box is unchecked → STOP. │
└──────────────────────────────────────────────────────────┘9. Discovery + response — when you’re noticed
A Pineapple running active PineAP will sometimes be noticed — by a sharp user, by venue security, by a blue team (§ 7). Have a plan:
- Stop active operations. Drop PineAP to passive/recon, or power down — don’t keep transmitting while you explain yourself.
- Stay visible and calm. Concealment reads as guilt. You are an authorized professional doing authorized work — act like it.
- Identify yourself and produce the authorization (§ 2). The physical copy. Let security/LE call the live contact to confirm in real time.
- Do not improvise the technical story. “I’m conducting an authorized wireless security assessment for [client]; here is the authorization; here is who to call” is the whole script. Detailed technical explanation of your KARMA configuration to a security guard is not required and not helpful.
- If escalated to law enforcement — cooperate, produce the document, decline to go deep on technical specifics without your client contact / counsel present, and document the interaction (names, time, what was said, what if anything was seized).
- If the device is seized — note exactly what was taken (incl. what capture data was on it — § 5), get a receipt, notify the client immediately, contact counsel. A seized Pineapple is seized capture data.
The discovery-response plan is part of the pre-engagement checklist (§ 8) for a reason — you rehearse it before you need it, not during.
10. Engagement closeout
After the engagement, before the Pineapple goes back in the bag:
- Pull the capture artifacts to encrypted host storage; hash them for the deliverable.
- Sanitize the device — wipe captures, logs, the SSID pool. The Pineapple should leave an engagement carrying nothing from it (§ 5).
- Purge bystander data, with the documentation note (§ 5).
- Restore the device to a known baseline for the next engagement.
- Disable / re-secure Cloud C2 if it was enabled for remote operation.
- Write the engagement note — into the tool’s record (per the Hack Tools convention), capturing what was done, what was found, what to change next time.
- Lessons learned — one honest line: what went well, what to fix in the checklist.
A clean closeout is also a clean start — the next engagement begins with a device that owes nothing to the last one.
11. Resources
Posture
- Vol 4 (this series) — the legal line this volume operationalizes
- Vol 20 (this series) — the deeper field-OPSEC + detection-signature treatment
- Hack Tools shared legal/ethics:
../../../_shared/legal_ethics.md - US CFAA / Wiretap Act / FCC interference — see Vol 4 § 11
Device hardening
- Hak5 docs — Management UI Firewall, firmware updates, Cloud C2 security: https://docs.hak5.org/wifi-pineapple/
- Hak5 Cloud C2 docs: https://docs.hak5.org/cloud-c2
Cross-tool
- [ESP32 Marauder Firmware deep dive Vol 11](../../ESP32%20Marauder%20Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html#vol11), [Nyan Box deep dive Vol 11](../../Nyan%20Box/03-outputs/NyanBox_Complete.html#vol11), [OpenSourceSDRLab PortaRF deep dive Vol 11](../../OpenSourceSDRLab%20PortaRF/03-outputs/PortaRF_Complete.html#vol11) — sibling operational-posture volumes for the same technique class; the discipline rhymes across all of them.
This is Volume 8 of a 21-volume series — and the last of the Foundation phase. The concept is now covered end to end: what a Pineapple is (Vol 1), where it came from (Vol 2), what it does (Vol 3), where it’s allowed (Vol 4), the firmware (Vol 5), the operating surface (Vol 6), the hardware (Vol 7), and the posture (Vol 8). Next: Phase 2 — the per-model deep dives, beginning with Vol 9, the WiFi Pineapple Mark VII hardware and electronics. Vols 9-21 are scaffolded and will be authored in subsequent sessions.