Wi-Fi Pineapple · Volume 15
Hak5 WiFi Pineapple Volume 15 — Enterprise: Firmware, Multi-Radio Operation, Scale & Mods
Running the rack platform — multi-radio role orchestration, fleet-scale Campaigns and Cloud C2, mods, and where the Enterprise fits
Contents
1. About this volume
Vol 15 is the operating treatment of the Enterprise — the hardware of Vol 14 put to work. The Enterprise’s distinguishing operational fact is radio count: five role-assignable radios let it do concurrently what a three-radio Mark VII does serially (Vol 14 §4). This volume covers multi-radio orchestration, sustained/scaled operation, fleet-scale Campaigns + Cloud C2, mods, and the use-case fit.
Foundation cross-refs: Vol 5 (the firmware foundation — Campaigns + Cloud C2), Vol 7 §3 (the role-based radio model this volume operates at five radios), Vols 4 + 8 (posture — unchanged by scale: a bigger platform is not a looser legal line). Research-baseline applies.
2. First boot and rack deployment
The Enterprise’s setup is unlike the Mark VII’s or the Pager’s, because the Enterprise is installed, not carried (Vol 14 §6):
Enterprise deployment sequence
════════════════════════════════════════════════════════
1. RACK mount the Enterprise in the rack / fixed
position. It is permanent infrastructure
(Vol 14 §6) — site it deliberately.
2. POWER 100-240 V AC mains (Vol 14 §6). No battery,
no power bank — it is wired to mains.
3. CABLE the dual GbE (Vol 14 §5): one port uplink,
one port a segregated test/management
network — or whatever two-network topology
the install needs.
4. WEB UI reach the web UI over the management network.
The Enterprise has no on-device screen (unlike
the Pager) — it is web-UI-operated (Vol 6 §2).
5. FIRST-RUN root password, management interface, the
Management UI Firewall (Vol 6 §8) — and on a
PERMANENT install this matters MORE, because
the device sits in hostile-airspace-adjacent
infrastructure indefinitely (Vol 20 §6).
6. FIRMWARE update to the current Enterprise firmware (§3).
7. RADIOS assign roles across the FIVE radios (§4).
8. C2 Cloud C2 enrollment — for the Enterprise this
is often the POINT (§6), not an option.The permanent-deployment posture starts at deployment. A Mark VII is a bring-it-and-take-it device; an Enterprise stays. That changes the security calculus from day one — the management interface hardening (step 5) is not “harden it for this engagement,” it is “harden it because this device will sit in this rack for months” (Vol 20 §6 carries the full permanent-install posture). The exact steps are firmware-version-specific (doc-audit); docs.hak5.org/wifi-pineapple-enterprise is authoritative.
3. The Enterprise firmware build
The Enterprise runs the Enterprise firmware — the same OpenWrt + PineAP core as the rest of the line (Vol 5), tuned for the quad-core ARM platform (Vol 14 §3) and the five-radio array (Vol 14 §4).
What the Enterprise firmware exposes that the Mark VII firmware does not:
- Multi-radio management — the role-assignment UI (Vol 6 §3 — Settings → radios) handles five radios, and supports the multiple-instances-of-a-role model (§4) that three radios cannot express.
- Scale-oriented features — the firmware is built around the ~100-client capacity (Vol 14 §7): the client-tracking, DHCP, and routing surfaces are sized for that population.
- Fleet orientation — the Enterprise firmware assumes Cloud C2 as a first-class operating mode (§6), not an optional add-on.
The shared core means the operating model is the same as the Mark VII (Vol 10): the web UI, the PineAP engine, Recon, Campaigns. An operator who knows the Mark VII knows the Enterprise’s interface — what is different is the scale the interface is now managing. “Which firmware is best” — the Vol 5 §6 answer holds: the current stable Hak5 Enterprise release; no alternative firmware; update on release; doc-audit re-pins the version.
4. Multi-radio role orchestration
This is the Enterprise’s whole operational point. The role-based radio model (Vol 7 §3) at five radios:
Multi-radio orchestration — what 5 radios let you do
════════════════════════════════════════════════════════
A typical Enterprise role assignment:
radio 0 ──► MANAGEMENT
radio 1 ──► PineAP (2.4 GHz, channel set A)
radio 2 ──► PineAP (5 GHz, channel set B)
radio 3 ──► MONITOR (2.4 GHz recon/capture)
radio 4 ──► MONITOR (5 GHz recon/capture)
= MULTIPLE PineAP instances + MULTIPLE monitor instances,
CONCURRENTLY, across BOTH bands.
The Mark VII (3 radios) does 1 PineAP + 1 monitor — it
covers one band-and-channel-set of attack and one of
recon at a time. The Enterprise does SEVERAL at once.
That is the difference between "audit a network" and
"audit a VENUE."What multi-radio orchestration buys, concretely:
- Concurrent dual-band attack — a PineAP instance on 2.4 GHz and one on 5 GHz, at the same time. No band-switching, no choosing.
- Concurrent broad recon — multiple monitor radios covering more channels / both bands simultaneously, so the airspace picture is wider and updates faster.
- Parallelism, not serialisation — the Mark VII does its jobs one-band-at-a-time-ish; the Enterprise does them in parallel, because it has the radios to dedicate.
The web UI’s role-assignment surface is where this is configured (Vol 6 §3); the assignment above is the typical shape, not the only one — the operator tunes it to the engagement. The exact assignment options are a doc-audit item; the architectural capability — multiple concurrent role instances across five radios — is fixed and is the Enterprise’s reason to exist.
5. Operating at scale — many clients, sustained runs
The Enterprise’s two scale dimensions, in operation:
Many clients (~100 DHCP — Vol 14 §7). In practice this means large-venue assessments: a conference floor, a corporate building, a venue with many devices in the airspace and many potential clients to engage. When PineAP is running and clients associate (Vol 3 §6), the Enterprise holds them — issues DHCP, routes their traffic, tracks them — at a scale a puck cannot. The operating consequence: the capture-data volume is large, and the Vol 7 §7 / Vol 19 principle applies hard here — the Enterprise captures at scale; the analysis (and any cracking) moves off-device to a real analysis pipeline (Vol 19). A hundred clients’ worth of capture is not analysed on the Enterprise; it is collected on the Enterprise and processed off it.
Sustained runs (mains power, no battery clock — Vol 14 §6). The Enterprise runs indefinitely. There is no ~4-hour Pager clock, no power-bank limit. This makes it the platform for:
- Multi-hour / multi-day engagements — a large assessment that runs over days.
- Continuous Campaigns (Vol 5 §4, §6 below) — scheduled, repeating, long-running scripted audits.
- Permanent monitoring — the blue-team install (Vol 8 §6, Vol 17 §5, Vol 20 §4) where the Enterprise sits and watches the airspace continuously.
The Enterprise's scale, in one frame
════════════════════════════════════════════════════════
WIDE — 5 radios, multiple concurrent roles, both bands
(§4) → covers a VENUE's airspace, not a network's
DEEP — ~100 DHCP clients held concurrently (Vol 14 §7)
→ engages a CROWD, not a handful
LONG — mains power, no battery clock (Vol 14 §6)
→ runs for DAYS, or PERMANENTLY
Wide + deep + long is a deployment shape NO puck can
serve. That shape is the Enterprise's entire job.6. Campaigns and Cloud C2 at fleet scale
Campaigns on the Enterprise. Campaigns (Vol 5 §4) — the scripted-audit-to-report system — runs larger on the Enterprise: longer-duration Campaigns (sustained power), bigger-scope Campaigns (five radios, ~100 clients), and Campaigns that are part of a continuous monitoring posture rather than a one-shot engagement. The Revamped Campaigns of the current firmware line (Vol 10 §3) is the same system; the Enterprise just runs it at the scale its hardware allows.
Cloud C2 — and for the Enterprise, this is often the point. Hak5 Cloud C2 (Vol 5 §5) is the remote command-and-control server for managing Pineapples remotely. For a permanently-installed Enterprise, C2 is not an optional convenience — it is frequently how the device is operated at all, because the device is in a rack in a closet and the operator is not:
Cloud C2 + the Enterprise — the fleet operating model
════════════════════════════════════════════════════════
A permanently-installed Enterprise + Cloud C2:
• the device is in the rack; the operator is remote
• C2 is how you reach it: configure, run Campaigns,
retrieve captures — all remotely
• a FLEET of Enterprises (an agency, a multi-site firm)
is managed from ONE C2 console
• captures from the whole fleet aggregate centrally
This is the agency / permanent-deployment operating
model, and it is the Enterprise's native habitat.The attack-surface caveat (Vol 6 §8, Vol 19 §5, Vol 20 §6) — stated because it must be: Cloud C2 is a remote path into the device, and a permanently-installed Enterprise reachable over C2 is a permanently-available remote-access surface. The C2 server, its enrollment tokens, its credentials, its network exposure are all part of the attack surface — and a compromised C2 server is a compromised fleet. Self-host C2, lock it down, treat its credentials as crown-jewels, and weigh the enrollment decision deliberately. The Enterprise’s C2-native operating model is powerful and it is also the model with the largest standing attack surface in the line — Vol 19 §5-6 and Vol 20 §6 carry the full framing.
7. Mods — Hak5 and community
Hak5 mods for the Enterprise: rack accessories, antenna arrays for the five-radio array, and the standard Hak5 accessory line (research the current shop.hak5.org list). The Enterprise’s mods skew toward installation (rack hardware, antenna placement) rather than carry (the Mark VII’s case, the Pager’s belt clip) — because the Enterprise is installed, not carried.
Community mods — the same module-layer model as the whole line (Vol 5 §7, Vol 6 §4-5): the community builds modules, installed from the web UI’s Modules area. For a scaled platform, the modules that matter most are the ones that suit scale — reporting/export tooling for large captures, recon visualisations that handle a venue-sized airspace, integrations with a real analysis pipeline. The staleness caveat (Vol 6 §5) and the vetting discipline (Vol 6 §8, Vol 18 §8) apply with extra weight: a community module on a permanently-installed device is an untrusted root process that stays — vet harder, prefer current/maintained/source-visible modules, and reconsider any module on a permanent install the way you would reconsider any long-lived dependency. Vol 18 carries the full catalog and vetting discipline.
8. Use cases — where the Enterprise fits
The Enterprise fits the wide, deep, long deployment shape (§5) — and nothing else in the line does:
| Use case | Why the Enterprise fits |
|---|---|
| Agency / firm-scale work | the fleet-of-Enterprises-via-Cloud-C2 model (§6) is built for organisations running many engagements / many sites |
| Large-scale assessments | the ~100-client capacity + five-radio coverage handles a venue, not just a network (§5) |
| Permanent monitoring deployments | mains power + rack chassis + sustained operation = the device that sits and watches indefinitely — the blue-team install (Vol 17 §5, Vol 20 §4) |
| The central node of a Cloud C2 fleet | an Enterprise is the natural anchor of a managed Pineapple fleet (§6) |
| Multi-radio orchestration | when an engagement genuinely needs concurrent multi-band, multi-instance PineAP + monitor (§4) |
Where the Enterprise is the wrong tool:
- A single scoped pentest — five radios, a rack chassis, and mains power are overkill for one network. That is a Mark VII job (Vols 9-11).
- Walk-around / mobile / opportunistic — the Enterprise is installed; it does not move. That is the Pager (Vols 12-13).
- Learning the platform — the Enterprise is the most specialised model; learn the baseline on a Mark VII first (Vol 11 §7). Vol 16 §7 puts the Enterprise last in the acquisition order for exactly this reason.
The Enterprise is not “the best Pineapple” — it is the Pineapple for the deployment shape (wide + deep + long) the others cannot serve. Vol 16 is the full comparison; Vol 17 §5 is the blue-team monitoring playbook; Vol 19 §6 is the fleet-ops detail.
9. Resources
- WiFi Pineapple Enterprise docs: https://docs.hak5.org/wifi-pineapple-enterprise/
- WiFi Pineapple Enterprise FAQ: https://shop.hak5.org/pages/wifi-pineapple-enterprise-faq
- Hak5 Cloud C2 docs: https://docs.hak5.org/cloud-c2
- Vol 14 — Enterprise hardware
- Vol 5 — the firmware foundation (Campaigns, Cloud C2) · Vol 7 §3 — the role-based radio model
- Vol 16 — model comparison · Vol 17 §5 — the blue-team monitoring playbook
- Vol 19 — tooling and Cloud C2 fleet ops · Vol 20 §6 — the permanent-install posture
This is Volume 15 of a 21-volume series — the end of Phase 2 (the per-model deep dives). Next, Phase 3 (synthesis) opens with Vol 16: the model comparison and the which-to-get-first decision — the four current models side by side, the spec matrix, the capability deltas, and the acquisition order for owning all four.