Ducky Script · Volume 14
Ducky Script Volume 14 — Combined-Device & Combined-Tool Workflows
Staging the four devices together, staging Ducky Script alongside the WiFi Pineapple, Hak5 Cloud C2, and multi-stage engagements
Contents
1. About this volume
So far the manual has treated each device on its own. Real engagements rarely do. This volume is about combination — staging the four Ducky Script devices together, staging a Ducky Script device alongside the WiFi Pineapple (the sibling Hak5 platform — ../WiFi Pineapple/), tying a fleet together with Hak5 Cloud C2, and the discipline that multi-stage work demands.
This is the volume tjscientist specifically asked for: Ducky Script as it is used with the Pineapple as well as the other Hak5 devices. The honest framing up front, because it matters: the WiFi Pineapple does not run Ducky Script. It is an OpenWrt-based Wi-Fi-auditing platform (Vol 1 §8), not a keystroke-injection device. What is real — and what §§4-5 are about — is that a Ducky Script payload and a Pineapple are staged together in one engagement, each doing the half of the job it is good at. That is “Ducky Script used with the Pineapple,” and it is a genuine, common, powerful pattern.
2. Why combine — the engagement is the unit, not the device
A device has a capability. An engagement has an objective. The objective almost never maps cleanly onto one device’s capability — so you combine.
One device's reach vs. an engagement's objective
════════════════════════════════════════════════════════
USB Rubber Ducky "I can type on a machine I touch."
Bash Bunny "I can be a network adapter + a Linux box."
Key Croc "I can watch what's typed and act on it."
O.MG "I can be a covert, remote-triggered implant."
WiFi Pineapple "I can own the wireless environment."
Objective: "get a foothold on the target's network and
keep it."
No single line above IS that objective. But:
O.MG (covert physical access) → types a payload that →
re-points the host's Wi-Fi at → the WiFi Pineapple
(which owns the wireless side) → and a Bash Bunny left
behind → holds the network foothold.
The engagement is the unit. The devices are the verbs.The combination skill is decomposition: break the objective into capability-shaped pieces, assign each piece to the device (or tool) that does it best, and sequence them. §§3-5 are worked decompositions.
3. Combining the four Ducky Script devices
Even within the Ducky Script family, the four devices combine — because they have complementary timing models (Vol 10 §2) and capabilities:
| Combination | Why it works |
|---|---|
| O.MG (covert delivery) → payload that stages a Bash Bunny attack | the O.MG gets a payload running invisibly; the payload prepares the host so a Bash Bunny dropped later does more |
| Key Croc (observe) → triggers, operator brings a Rubber Ducky (act) | the Croc’s keylog tells the operator when the target is in a useful state; the operator then does a fast, hands-on Rubber Ducky injection |
| Key Croc (persistent) + O.MG (persistent) | two install-and-leave implants with different strengths — the Croc watches typing, the O.MG is remote-triggerable; together they cover “observe” and “act on command” |
| Rubber Ducky (fast recon) → informs Bash Bunny (deep action) | a quick Ducky payload gathers what OS/config the target is; the operator picks the matching Bash Bunny payload |
The recurring logic: the observe-first devices (Key Croc) and the persistent devices (O.MG) generate the timing and intelligence that the act-first devices (Rubber Ducky, Bash Bunny) need. A Rubber Ducky’s whole weakness is that it must guess the moment (Vol 5); a Key Croc installed first removes the guess.
4. Ducky Script + WiFi Pineapple — the staged workflow
This is the headline combination. The two platforms attack orthogonal surfaces (Vol 1 §8):
The orthogonal surfaces
════════════════════════════════════════════════════════
Ducky Script device WiFi Pineapple
─────────────────── ──────────────
attacks a SPECIFIC MACHINE attacks the WIRELESS
by physical contact / ENVIRONMENT from a distance
keystroke injection
(PineAP rogue-AP / KARMA /
(types, runs commands, evil-twin / recon / handshake
changes settings, capture — see the WiFi
emulates devices) Pineapple deep dive)
A physical-access engagement that ALSO needs the wireless
side staged uses BOTH — and a Ducky payload is the bridge
between them.The Ducky-Pineapple bridge works in (at least) three directions:
A. The Ducky payload re-points the host at the Pineapple. A keystroke-injection payload that changes the target machine’s Wi-Fi configuration — disconnects it from the legitimate network, connects it to a Pineapple-hosted SSID — hands the machine’s network traffic to the Pineapple. The Ducky did the physical-access half; the Pineapple does the network half. §5 works this through.
B. The Pineapple sets the stage; the Ducky exploits it. The Pineapple’s PineAP suite gets a target client associating to it; the operator, with physical access, then uses a Ducky Script device to act on that machine while it is in the Pineapple-controlled network state.
C. They run in parallel, independently. The Pineapple works the airspace; the Ducky Script devices work specific machines; both feed the same engagement. No direct technical handoff — just two halves of one operation.
Cross-reference. The Pineapple side of all of this — what PineAP actually does, how a rogue AP captures a client, the recon and handshake-capture mechanics — is the WiFi Pineapple deep dive:. This volume covers the Ducky Script side and the handoff; that deep dive covers the Pineapple side. Read them together for the combined workflow. (The Pineapple deep dive’s Vol 19 — Tooling & Integrations — links back here.)
5. Worked: the Ducky-points-the-target-at-the-Pineapple play
The most concrete combined workflow, decomposed and worked:
Objective: get a target laptop's traffic flowing through
a WiFi Pineapple, using physical access.
STAGE 1 ── physical access, keystroke injection ──
Operator has brief physical access (or an O.MG is already
in place). A Ducky Script payload runs and reconfigures
the host's Wi-Fi: forget/deprioritize the legit network,
connect to the Pineapple-hosted SSID.
STAGE 2 ── the Pineapple takes over ──
The host is now associated to the Pineapple. From here it
is entirely a WiFi Pineapple operation — PineAP, recon,
capture — covered in the WiFi Pineapple deep dive.
STAGE 3 ── (optional) the Ducky cleans up ──
A follow-up payload (or the same one's CLOSE section)
restores the host's Wi-Fi state at the end of the
engagement — leaving clean (Vol 13 §2, Vol 16).Stage 1 worked — USB Rubber Ducky, Windows, US layout (illustrative skeleton):
REM ── Stage 1: re-point the host's Wi-Fi at the Pineapple ──
REM Target: Win10/11, US layout
REM Authorization: <engagement ref> — BOTH the physical-access
REM AND the wireless-redirect are in scope per the auth.
REM Pairs with: WiFi Pineapple (see ../WiFi Pineapple/)
DELAY 2500
RESET
GUI r
DELAY 500
STRINGLN cmd
DELAY 750
REM (the typed commands manage the host's Wi-Fi profiles so
REM it associates to the Pineapple-hosted SSID — exact
REM netsh/nmcli specifics depend on target OS)
STRINGLN netsh wlan show profiles
DELAY 500
REM ... reconfigure to the Pineapple SSID ...
REM CLOSE: note what was changed so Stage 3 can restore itTwo disciplines this worked example is really about:
- Authorization covers the whole chain. Re-pointing a host’s network at an attacker-controlled AP is a significant act. The authorization artifact (Vol 16) must explicitly cover both the physical-access keystroke injection and the wireless redirect — staging two tools does not mean one authorization stretches to cover both by implication.
- Leaving clean spans devices. Stage 3 exists because Stage 1 changed host state. A combined workflow’s CLOSE discipline (Vol 13 §2) has to account for every device’s footprint, not just the last one used.
6. Hak5 Cloud C2 — the fleet layer
Hak5 Cloud C2 is Hak5’s command-and-control server for managing a fleet of Hak5 devices remotely. It is the layer that ties combined deployments together — and it spans the device family and the WiFi Pineapple alike.
What Cloud C2 does for the Ducky Script family:
- Remote management of the network-capable devices — the Key Croc (Wi-Fi, Vol 10 §7) and, where supported, others — enroll a device, reach it from the C2 server, retrieve loot, re-task payloads, all without physically returning.
- Fleet view — multiple devices, including WiFi Pineapples, managed from one console. For a multi-device engagement, C2 is the operator’s single pane.
- Loot aggregation — captured data from across the fleet, collected centrally.
The honest caveats — Cloud C2 is also an attack surface, and the manual has to say so:
Cloud C2 — capability and exposure
════════════════════════════════════════════════════════
CAPABILITY one console, the whole fleet, remotely.
For a multi-device engagement this is the
difference between "manageable" and "chaos."
EXPOSURE C2 is a REMOTE PATH INTO every enrolled
device. The C2 server, its credentials, its
enrollment tokens, its network exposure are
ALL part of the attack surface now.
A compromised C2 server is a compromised fleet.
DISCIPLINE self-host it; lock it down; treat its
credentials as crown-jewels; enroll a device
only when fleet management is actually needed.The same Cloud C2 framing is in the WiFi Pineapple deep dive (its Vol 5 and Vol 19) — because it is the same server managing the same fleet. Read them as one subject.
7. Combining with the rest of the Hack Tools hub
Beyond Hak5, the Ducky Script devices combine with the wider hub:
| Combine with | The combined play |
|---|---|
Flipper Zero (../Flipper Zero/) | the Flipper has its own BadUSB feature; understanding Ducky Script (this manual) makes the Flipper’s BadUSB legible — and a Flipper can be the carry device for a quick HID payload when you do not want a dedicated Ducky on you |
ESP32 Marauder devices (../ESP32 Marauder Firmware/) | the Marauder devices do Wi-Fi attack on a microcontroller; a Ducky payload on a target machine + a Marauder working the airspace is a lighter-weight version of the Ducky+Pineapple play |
HackRF / PortaRF (../HackRF One/) | RF reconnaissance that informs a physical-access engagement — what is the environment, before you walk in with a Ducky |
Clockwork uConsole (../Clockwork uConsole/) | a portable Linux box that can host Cloud C2, run the analysis side, or be the operator’s field console for a multi-device engagement |
The hub’s cross-tool decision matrix (../_shared/comparison.md) is the structured view of which tool owns which capability — combination is just reading that matrix against an engagement’s decomposed objective (§2).
8. Multi-stage engagement discipline
Combining tools multiplies capability and multiplies what can go wrong. The discipline:
Multi-stage discipline
════════════════════════════════════════════════════════
□ AUTHORIZATION covers the whole chain. Every device,
every stage, every surface (physical AND wireless AND
network) is named in the authorization artifact. A
gap in the chain is an unauthorized act (Vol 16).
□ SEQUENCE is written down. Which device, in what order,
triggered by what. A multi-stage plan in someone's
head is a multi-stage plan that drifts under pressure.
□ STATE is tracked across devices. Stage 1 changed host
Wi-Fi config; Stage 3 must restore it. Know what every
stage touched so the engagement can leave clean.
□ EACH STAGE has an abort. If Stage 1 fails, what happens
to Stage 2? A combined workflow needs a defined "this
went wrong, here's the safe stop" at every handoff.
□ THE ATTACK SURFACE YOU ADDED is accounted for. Cloud C2,
a Pineapple's management interface, an O.MG's Wi-Fi —
every tool you stage in is also a thing that can be
turned against you or found by the defender (Vol 15).
□ DETECTION is cumulative. The Pineapple is loud; the
Ducky's on-screen activity is visible; the O.MG's Wi-Fi
is a signal. A combined workflow's detection signature
is the SUM (Vol 15) — plan for the sum, not the parts.The single most important line: authorization covers the whole chain. It is the easiest thing to get wrong in combined work — each tool individually feels authorized because you have used it under authorization before, but a combination can do something none of the individual authorizations contemplated. When in doubt, the authorization artifact gets more specific, not the operator more optimistic.
9. Resources
- The WiFi Pineapple deep dive — — the Pineapple side of §§4-5; its Vol 19 links back here
- Hak5 Cloud C2 docs: https://docs.hak5.org/cloud-c2
../_shared/comparison.md— the hub’s cross-tool decision matrix (the structured view of §7)../_shared/legal_ethics.md— the hub-wide posture rules that §8’s discipline rests on- Vol 1 §8 — where the Ducky Script family sits relative to the Pineapple
- Vol 13 — the payloads that the combined workflows are built from
- Vol 16 — the authorization framing that §5 and §8 keep invoking
This is Volume 14 of an 18-volume series. Next: Vol 15 turns the manual around — Defense & Detection: how keystroke injection is actually caught, what USB device control and HID allow-listing do, the behavioural and timing detection signatures, and the blue-team view of everything the first fourteen volumes described.