Ducky Script Volume 16 — Operational Posture: Legal, Ethics & OPSEC — Ducky Script · Hacking

The framing for a technique that is intrusive by definition — the authorization artifact, the weight of install-and-leave implants, and the discipline that keeps the device family on the right side of the line

Section	Topic
1	About this volume
2	The core fact — there is no passive mode
3	The legal line
4	The authorization artifact
5	Scope discipline
6	The special weight of the implants
7	The keylogging problem
8	OPSEC — protecting the engagement and yourself
9	The pre-engagement checklist
10	Discovery, response, and closeout
11	Resources

1. About this volume

This is the volume everyone reads (Vol 1 §10). The Ducky Script device family — alongside the WiFi Pineapple — is the highest-consequence class of tool in the Hack Tools hub for legal exposure, and the reason is structural, not incidental: covered in §2.

This volume is not legal advice and does not substitute for it; it is the operational posture — the disciplined framing and the concrete practices that keep the use of these devices lawful, ethical, and professional. It sits on top of the hub-wide rules in ../_shared/legal_ethics.md and sharpens them for this specific, intrusive-by-definition tool class.

2. The core fact — there is no passive mode

Start here, because everything else follows from it:

   The structural reason this tool class is high-consequence
   ════════════════════════════════════════════════════════

   The WiFi Pineapple has a genuinely lawful PASSIVE mode —
   it can listen to the airspace, do recon, observe — without
   touching any specific machine. Passive recon is, broadly,
   lawful (see the WiFi Pineapple deep dive).

   A Ducky Script device has NO equivalent.

   The moment a Ducky Script payload runs, it has ACTED — it
   has opened a shell, run a command, changed a setting,
   emulated a device, ON a machine, AS a user, without that
   user's action. There is no "just listening." There is no
   passive mode. If the device is doing anything at all, it
   is DOING something to a computer system.

   (The Key Croc's pass-through keylogging is the closest
   thing to "passive" — and §7 explains why it is not a
   safe-harbour; capturing keystrokes is itself an act.)

This is the fact. Because there is no passive mode, there is no “I was just testing the waters” defensible position. Every use of every device in this family is an act against a computer system — which means every use needs authorization, every time, with no exceptions for “small” or “harmless” payloads. The harmlessness of the content does not change the nature of the act.

3. The legal line

The legal framing — general, jurisdiction-spanning, not a substitute for counsel:

   The legal line for keystroke injection
   ════════════════════════════════════════════════════════

   LAWFUL                          UNLAWFUL (typical)
   ──────                          ──────────────────
   running a payload on a          running a payload on ANY
   machine YOU OWN                 machine you do not own and
                                   are not authorized to access
   running a payload under         ────────────────────────────
   explicit, written, scoped       this is unauthorized access
   AUTHORIZATION from the          to a computer system — a
   system's owner                  CRIMINAL offense in most
                                   jurisdictions (e.g. the US
   ──────────────────────────      CFAA and equivalents
   THE LINE: ownership or          worldwide), REGARDLESS of
   written authorization.          how harmless the payload
   Nothing else is on the          content was.
   lawful side.

The principles that make this concrete:

The act is unauthorized access — not “hacking” in some narrow sense, just accessing a computer system you were not authorized to access. A payload that runs whoami on a machine you do not own is the same category of offense as one that does far worse; the content is a sentencing factor, not a line.
“I didn’t damage anything” is not a defense. Unauthorized access is the offense. Damage is an aggravator.
The implants make it a continuing offense — §6.
The keylogging may trigger wiretap/interception law on top of computer-access law — §7.
Jurisdiction varies and travels. The target’s location, your location, where the data goes — all can matter. Cross-border engagements need real legal review.
../_shared/legal_ethics.md is the hub-wide baseline — regional RF rules, own-hardware-or-authorization, the lab-discipline rules. This volume is the keystroke-injection-specific sharpening of it.

The bright line, stated once: owned hardware, or explicit written authorization. There is no third lawful category.

4. The authorization artifact

“Authorization” is not a verbal “sure, go ahead.” It is a document, and a usable one. The authorization artifact for a Ducky Script engagement must be specific enough to actually bound the work:

   The authorization artifact — what it must pin down
   ════════════════════════════════════════════════════════

   WHO authorized it      ─ a person with the actual authority
                            to authorize access to those systems
   WHAT systems           ─ specifically. Which machines, which
                            networks. Not "the office."
   WHAT actions           ─ keystroke injection is named. If the
                            engagement stages with a Pineapple
                            (Vol 14), the wireless redirect is
                            ALSO named. Combined work = combined
                            authorization (Vol 14 §8).
   WHICH DEVICES          ─ plug-and-pull? install-and-leave
                            implants? The implants need explicit
                            authorization to be LEFT (§6).
   WHEN                   ─ the engagement window. Start and end.
   DATA HANDLING          ─ what may be captured, how it is
                            stored, how it is destroyed (§7, §10).
   POINTS OF CONTACT      ─ who to call if something goes wrong
                            or the engagement is discovered (§10).

   You carry this. On your person. During the engagement. It
   is the single document that distinguishes a professional
   pentester from a criminal doing the identical act.

The discipline rules:

No payload runs without it. Vol 3 §3 makes the REM header carry an authorization reference for this reason — every payload file points at the artifact that authorizes it.
The artifact bounds the work; the operator does not exceed it. If the payload could do more than the artifact authorizes, the payload gets edited down — §5.
Carry it. Discovery during an engagement (§10) is resolved by producing the artifact. An authorization you cannot produce, in the moment, is not protecting you.
If it is ambiguous, it is not done. “It’s probably fine” is not authorization. Get the artifact specific before the engagement, not during.

5. Scope discipline

The authorization artifact (§4) defines the scope. Scope discipline is the practice of staying inside it — and it is mostly about restraint:

Target only what is named. The artifact lists systems. Those systems, and no others. A Ducky Script device touched to a machine not in scope is unauthorized access, full stop — even if it was an accident, even if it was “right there.”
Do only what is authorized. If the artifact authorizes recon, the payload does recon — it does not “also just check” something more invasive because the operator is curious. Targeting discipline is built into the payload (Vol 13 §10’s vetting checklist explicitly includes “does this exceed authorization”).
Edit community payloads down to scope. A payload from a repo (Vol 13 §9) was written for someone else’s scope. Before it runs on this engagement, it is edited to do only what this authorization permits — the parts that exceed scope are removed, not just “not triggered.”
The implants are a scope-discipline hard case — §6.
When the payload could do more than you are authorized to do, that is a payload defect, to be fixed before the engagement — not a temptation to be resisted during it.

   Scope discipline, in one sentence
   ════════════════════════════════════════════════════════

   The authorization artifact is the perimeter; everything
   you do — every device, every machine, every payload, every
   line in every payload — is inside it, and the way you
   guarantee that is by REMOVING the capability to go outside
   it, not by trusting yourself not to.

6. The special weight of the implants

The Key Croc and the O.MG are install-and-leave devices. That changes the legal and ethical weight in a specific, serious way:

   Plug-and-pull vs. install-and-leave
   ════════════════════════════════════════════════════════

   USB Rubber Ducky / Bash Bunny — plug-and-pull:
     the unauthorized act (if it were unauthorized) is a
     POINT IN TIME. You plugged in, it ran, you left.

   Key Croc / O.MG — install-and-leave:
     the device REMAINS. It is a CONTINUING presence on the
     target's system/environment. If that presence is not
     authorized, it is not "an act" — it is an ONGOING
     STATE of unauthorized access, persisting every minute
     it is in place.

   Legally, a continuing offense is treated more seriously
   than a momentary one. Ethically, you have placed a thing
   that ACTS ON ITS OWN (Vol 13 §8, the conditional pattern)
   — and you are responsible for everything it does while
   it is there, including things you did not specifically
   foresee.

The discipline the implants demand on top of §§4-5:

Explicit authorization to leave a device. The authorization artifact must specifically permit an implant to be installed and left in place — “you may run payloads on these machines” does not imply “you may leave a device behind.”
A retrieval plan. An implant you cannot account for is a serious problem. The engagement plan includes when and how every implant is retrieved — and §10’s closeout verifies it.
Bounded autonomy. A conditional/triggered payload (Vol 13 §8) acts without you in the loop. Its trigger and scope must be tight enough that it cannot act outside authorization while you are not watching. The O.MG’s geo-fencing (Vol 11 §7) is the model here — read it as a scope-enforcement control, and use it: a covert implant that is geo-fenced to the authorized site cannot travel home with the target and fire on a personal machine.
Account for the worst case. Ask, before placing it: if this device is never retrieved, what happens? If the answer is unacceptable, the deployment is not ready.

7. The keylogging problem

The Key Croc’s pass-through keylogging (Vol 10 §4) deserves its own section, because it is the capability with the sharpest and most distinct legal edges in the family:

   Why keylogging is legally distinct
   ════════════════════════════════════════════════════════

   Keystroke INJECTION engages computer-ACCESS law (§3).

   Keystroke LOGGING — capturing what a person types —
   additionally engages WIRETAP / INTERCEPTION / PRIVACY law,
   which is a SEPARATE body of law with its OWN rules:
     • it often turns on CONSENT — and in some jurisdictions
       ALL parties must consent, not just the system owner
     • it can apply to the COMMUNICATIONS being typed (an
       email, a chat) independently of the computer access
     • it frequently carries its own, separate penalties

   So a Key Croc capturing keystrokes on a machine can be:
     • authorized for computer ACCESS (the owner said yes)
     • but STILL problematic for INTERCEPTION (the person
       typing did not consent; the law may require they do)

   This is genuinely jurisdiction-specific and genuinely
   serious. It needs real legal review, not a posture rule.

The disciplines:

Keylogging gets its own line in the authorization artifact (§4) — “you may access these systems” does not authorize “you may capture what people type on them.” The artifact must specifically address interception, consent, and what may be captured.
Treat captured keystroke data as the most sensitive loot you handle — it contains credentials, personal communications, everything. §8 and §10’s data discipline apply at maximum stringency.
When in doubt, do not log. Of all the capabilities in this manual, keylogging is the one where “I was not sure it was authorized” is least survivable. If the authorization is not explicit and the legal review is not done, the Key Croc logs nothing.

8. OPSEC — protecting the engagement and yourself

OPSEC here means protecting the engagement (its integrity, its data) and the operator (from doing something indefensible) — not “evading detection,” which is Vol 15’s subject from the other side.

Carry the authorization artifact (§4). Always. It is the OPSEC item.
Payload hygiene — every payload REM-headers its authorization (Vol 3 §3); every payload is vetted before it runs (Vol 13 §10); no payload does more than scope (§5).
Data discipline — captured data (loot.bin, keylogs, exfil) is sensitive. Know where it is, encrypt it at rest, transmit it safely, and destroy it per the authorization artifact’s data-handling terms (§4, §10). The Key Croc’s keylogs are the high-water mark of sensitivity (§7).
Device hygiene — know where every device is at all times. The implants especially (§6): an unaccounted-for Key Croc or O.MG is both an OPSEC failure and a legal exposure.
The attack surface you brought — Cloud C2, an O.MG’s Wi-Fi, a Key Croc’s network presence (Vol 14 §6, Vol 15 §7) are all things that can be turned against the engagement. Lock them down; treat their credentials as crown-jewels.
Document as you go — what was done, on what, when. The engagement’s value to the client is the report, and the report is built from contemporaneous notes. It is also your record that you stayed in scope.
Know when to stop. If something is ambiguous, if a machine seems out of scope, if a payload is doing something unexpected — stop, do not improvise. The professional move is always the conservative one.

9. The pre-engagement checklist

   Pre-engagement checklist — Ducky Script device family
   ════════════════════════════════════════════════════════

   AUTHORIZATION
   □ Written authorization artifact in hand, and ON me
   □ It names: who, which systems, which networks, which
     ACTIONS (incl. wireless redirect if staging w/ a
     Pineapple — Vol 14)
   □ It names which DEVICES, and explicitly authorizes any
     install-and-leave implants to be LEFT (§6)
   □ It addresses KEYLOGGING specifically if a Key Croc is
     in play, incl. interception/consent (§7)
   □ It specifies data handling + destruction (§8, §10)
   □ It names points of contact for discovery/problems (§10)

   PAYLOADS
   □ Every payload REM-headers its authorization reference
   □ Every payload vetted (Vol 13 §10) — read, understood,
     scoped, does NOT exceed authorization
   □ Community payloads edited DOWN to this engagement's scope
   □ Every payload TESTED on owned hardware, target layout,
     target OS (Vol 12 §10)

   DEVICES
   □ Right device(s) chosen for the job (Vol 17)
   □ Each device's deploy verified (Vol 12 §§6-9)
   □ Implants: geo-fence / trigger scoped tight (§6); a
     retrieval plan exists for every one
   □ Cloud C2 (if used) locked down (Vol 14 §6)

   POSTURE
   □ I can articulate the legal basis for every action I
     plan to take
   □ I have a STOP plan — what I do if something is ambiguous
   □ Closeout plan ready (§10)

10. Discovery, response, and closeout

If the engagement is discovered or challenged:

   Discovery response
   ════════════════════════════════════════════════════════

   1. STOP active operations immediately. No improvising,
      no "just finishing this one thing."
   2. PRODUCE the authorization artifact (§4). This is the
      moment it exists for.
   3. CONTACT the named point of contact (§4) — both the
      client's and yours.
   4. DO NOT destroy anything, do not flee, do not lie. The
      authorization artifact is your standing; relying on it
      is the correct move. Acting like a criminal converts a
      professional engagement into one.
   5. DOCUMENT what happened, contemporaneously.

Engagement closeout:

   Closeout checklist
   ════════════════════════════════════════════════════════
   □ Every plug-and-pull device accounted for and removed
   □ Every install-and-leave implant RETRIEVED (§6) — and
     verified retrieved, not "probably still there"
   □ Every host whose state a payload changed is RESTORED
     (Vol 13 §2 CLOSE, Vol 14 §5 Stage 3) — left clean
   □ All captured data handled per the authorization
     artifact: stored as specified, transmitted safely,
     and DESTROYED on the specified schedule (§7, §8)
   □ Cloud C2 / device Wi-Fi / any added attack surface
     torn down
   □ The report written from contemporaneous notes — incl.,
     for the client's actual benefit, WHICH CONTROLS would
     have stopped each technique (Vol 15 §10)
   □ Lessons-learned captured

The closeout is not bureaucratic overhead — it is the half of the engagement that makes it professional rather than merely technical. An engagement that injected brilliantly and then left an unaccounted-for implant, a dirty host, and undeleted keylogs is a failed engagement regardless of how good the payloads were.

11. Resources

../_shared/legal_ethics.md — the hub-wide posture baseline this volume sharpens
The WiFi Pineapple deep dive — its posture volumes (the sibling high-consequence tool; combined-engagement authorization is Vol 14 here and there)
Real legal counsel — for any engagement, especially cross-border, and especially anything involving the Key Croc’s keylogging (§7). This volume is posture, not legal advice.
Vol 13 §10 — payload vetting, the operational half of scope discipline
Vol 14 §8 — combined-workflow authorization discipline
Vol 15 — the defensive view; §10 there on why the offensive operator’s product is defensive insight

This is Volume 16 of an 18-volume series. Next: Vol 17 — Device Comparison & Which-to-Use-When: the four owned device families side by side, and a setup-per-job guide for the recon job, the smash-and-grab, the persistent implant, and the keylog-and-trigger.

Ducky Script Volume 16 — Operational Posture: Legal, Ethics & OPSEC

Contents