AI Pentesting, Part 9: Payload Modification and Ducky Script: Safe Endpoint Labs

1. Separate useful modification from capability escalation

Initial-access payload modification with LLMs is a high-risk area because small changes can add execution, delivery, or concealment capabilities. In this series, the artefact is a benign simulator that writes a labelled local event and exits. AI may improve input validation, error messages, platform compatibility, and tests. It must not add shellcode loading, security-tool tampering, credential theft, persistence, or stealth.

Write the capability contract first: permitted file location, allowed arguments, no network access, no child processes, maximum runtime, and expected telemetry. Build from reviewed source in an isolated environment. Record the compiler/interpreter version, source commit, dependency lockfile when applicable, binary hash, and test results. A model's 'functionally equivalent' claim is not a substitute for review.

Refactor the supplied benign simulator only.
Preserve: one labelled local event and normal process exit.
Improve: argument validation, portability, deterministic errors, tests.
Forbidden: network calls, child processes, persistence, credential access,
security-control changes, obfuscation, executable memory, hidden actions.
Return: source diff, behaviour changes, and tests for every changed branch.

If the assistant proposes disabling antivirus to make a test pass, reject the change and investigate the test design. A blocked lab artefact is evidence about the control, not a reason to evade it.

2. A benign, bounded simulator

This Python fixture prints a structured event. It does not write files, execute commands, or communicate over the network. The optional argument is an exercise identifier constrained to a small ASCII alphabet. Save and run it only in your designated lab. Standard output can be captured by the approved test runner.

import json
import re
import sys

exercise = sys.argv[1] if len(sys.argv) == 2 else "LAB-014"
if len(sys.argv) > 2 or not re.fullmatch(r"LAB-[0-9]{3}", exercise):
    raise SystemExit("expected one exercise ID such as LAB-014")
print(json.dumps({
    "event": "benign_endpoint_simulation",
    "exercise": exercise,
    "network": False,
    "child_processes": False,
    "persistent_changes": False
}, sort_keys=True))

Expected: one JSON line with the selected lab identifier. Negative tests include extra arguments, whitespace, an excessively long identifier, and unsupported characters. The booleans describe this fixture's intended behaviour, not independent proof; validate with process and network telemetry. A compromised interpreter or altered source changes the trust assumptions.

For a compiled equivalent, compare source-level behaviour and observable effects instead of insisting on identical hashes. Compiler flags, timestamps, and signing affect hashes. Do not add string encryption or packaging solely to reduce detection.

3. Ducky Script as a text-only HID demonstration

A USB HID device can type as a keyboard. Ducky Script describes keystrokes, delays, and device-specific control flow; supported syntax varies by firmware and generation. A timing-based script can type into the wrong window. Use a spare lab endpoint, a consenting operator, and a pre-opened blank text editor. Never rely on desktop focus as a security control.

DELAY 3000
STRING PSC-LAB-014: approved keyboard input demonstration.
ENTER
STRING No commands, credentials, downloads, or system changes.
ENTER

This basic example types text only. It does not open a shell, launch a program, navigate to a site, or collect information. Compile it only with the toolchain documented for your owned device. Before insertion, manually focus the blank editor and verify the endpoint is disconnected from sensitive workflows. If focus changes, remove the device and reset the lab.

Use AI to check the script against a syntax allowlist and to explain timing assumptions. Do not let it generate terminal shortcuts or command strings. A policy that permits only DELAY, STRING, and ENTER is intentionally narrower than the language. Review the resulting device artefact as well as source.

4. Measure device and process evidence

Collect USB device-arrival telemetry through your endpoint platform, operating-system device logs where available, and the exercise timeline. Device identifiers can be spoofed, and not every platform records individual keystrokes. Do not claim that a HID insertion must create a unique process tree: typing into an already open editor may create no new process at all.

Correlate time with monotonic or synchronised clocks and preserve sensor configuration. If logging is absent, mark the observation unavailable. Installing invasive keystroke capture just to improve the exercise metric introduces a separate privacy and security problem.

5. Run a controlled before-and-after experiment

1. Document the benign objective, endpoint snapshot, and exact artefact hash.
2. Run the baseline manually and collect expected logs.
3. Apply one reviewed AI-assisted refactor, with no new capabilities.
4. Run positive and negative input tests.
5. Compare process, filesystem, network, and event observations.
6. Run the text-only HID exercise under operator control.
7. Restore the endpoint and verify the artefact inventory.

Example change: replace an ambiguous error with a deterministic exit code. Expected result: invalid input fails earlier with no extra action. Another change: support a different lab interpreter path. Expected result: the same labelled event, not an added launcher. A third change: improve a unit test. Expected result: better branch coverage without changing runtime behaviour.

Keep the diffs small. Large generated rewrites make it harder to prove that the simulator's capability boundary stayed intact. Use static checks and runtime observation together.

6. Turn findings into endpoint controls

Recommendations may include application control, restricted interpreter use where appropriate, device-control policies, least privilege, physical access controls, and user reporting. Validate the business impact of device restrictions before deployment; keyboards, accessibility devices, and legitimate support tools need consideration.

Report what was actually observed: a lab device typed approved text, a policy blocked the device, or a sensor lacked visibility. Do not claim a text demonstration proves arbitrary code execution or an initial-access compromise. The point is to verify the boundary and improve evidence. Part 10 extends this bounded approach to command-and-control research tooling and MCP interfaces.

7. Step-by-Step Lab: Compare a Benign Simulator and a Text-Only HID Script

Prerequisites: An isolated endpoint, the benign simulator earlier in this article, an owned HID device if used, a blank editor, an operator, and a reset plan. No shell launcher, download, credential action, persistence, security-tool modification, or real-person impersonation belongs in this exercise.

1. Write the capability contract and expected event before changing source: one labelled local output, no network, no child process, normal exit, and a small accepted exercise-ID format.
2. Run the baseline simulator and collect its output plus the process and network observations available from the approved sensor. Do not treat self-reported JSON flags as independent telemetry.
3. Ask an assistant for one small change, such as a clearer error or stricter argument validation. Review the diff for new imports, calls, network behaviour, process creation, or hidden actions.
4. Test valid input, excess arguments, unsupported characters, and a too-long identifier. Confirm the changed branch fails safely before any action.
5. If using Ducky Script, limit source to the text-only demo. Run the syntax allowlist example below before compilation, then inspect the resulting device artefact using the vendor's supported process.
6. Manually focus the blank editor on the disconnected lab endpoint, insert the owned device under observation, and remove it immediately if focus changes. No terminal shortcut is part of the task.
7. Compare expected text, device-arrival evidence, and any process observations. Remove the device, restore the lab, and confirm the artefact inventory and reset status.

const script = "DELAY 3000\nSTRING PSC-LAB-021\nENTER";
function allowedLine(line) {
    return /^DELAY [0-9]{1,4}$/.test(line) || /^STRING [\x20-\x7e]{1,120}$/.test(line) || line === "ENTER";
}
const lines = script.split(/\r?\n/).filter(Boolean);
if (!lines.every(allowedLine)) throw Error("unapproved HID syntax");
if (allowedLine("GUI r") || allowedLine("DELAY 99999")) throw Error("allowlist failure");
console.log(JSON.stringify({ approvedLines: lines.length, policy: "text-only lab" }));

Expected result: Three approved source lines and rejection of the shortcut and oversized delay fixtures. This is a source syntax gate, not a hardware safety proof. STRING can still type harmful text into the wrong application, which is why the operator, known editor, isolated endpoint, and reviewed artefact remain necessary.

8. Worked Examples and Expected Outcomes

Example A: a deterministic error-code refactor

The baseline prints a vague message for malformed IDs. The reviewed change rejects the same input with a documented error and no additional action. Preserve branch tests and observable effects instead of judging equivalence by a model summary.

Example B: a compiler changes the hash

An equivalent benign build has different timestamps or code generation. Record the build toolchain and compare source/behaviour evidence. A changed hash is a new artefact identity, not proof of maliciousness or equivalence.

Example C: a device types into the wrong window

The operator notices focus moved before insertion. Abort, remove the device, and reset. Do not compensate by adding aggressive shortcuts or terminal launch commands. The failed precondition is the meaningful exercise result.

Review checklist:
source diff contains no new capability
valid and invalid argument cases recorded
device source and compiled artefact reviewed
blank editor focus confirmed manually
unexpected focus or sensitive workflow -> abort
device removed and lab restored

9. Troubleshooting, Retesting, and Completion Evidence

Retest and completion: Retain the capability contract, source/build hashes, reviewed diff, input cases, telemetry limits, operator checklist, and restoration evidence. Report only the benign actions demonstrated. A text-entry exercise does not establish an initial-access compromise or arbitrary code execution.

10. Real Tool Workflow: Use Hashes, Pester, and Device Evidence for a Benign HID Lab

Prerequisites: An owned isolated endpoint, the text-only Ducky Script from this article, an operator, a blank editor, an approved device toolchain, and optionally an approved Pester installation for PowerShell tests. No launcher, download, persistence, credential capture, or security-control bypass is part of the task.

Use reviewed releases and record the versions actually installed. Command references for this workflow were reviewed on 29 October 2026; product support and flags can change. Instructions and output shapes are not claims of a live assessment.

Step-by-Step Tool Operation

1. Prepare ducky-demo.txt using only the reviewed text-only lines. Define the maximum delay and line length and prohibit shortcut keys, terminal activation, network locations, and hidden actions.
2. Record source hash and compile with the version-specific toolchain for the owned device. Do not download an arbitrary third-party payload collection or execute an opaque binary from a model response.
3. If Pester is already approved, create the small source-policy test below as TextOnly.Tests.ps1. Run it locally and review failures before loading the device. It is not a complete Ducky Script parser.
4. Inspect the compiled artefact's hash and any available signing/provenance information. Compare source and build records so the device cannot silently use a different file than the one reviewed.
5. On the isolated endpoint, manually focus the blank editor, confirm no sensitive workflow is open, and insert the owned device under observation. Abort immediately if focus or expected behaviour changes.
6. Remove the device, collect the approved arrival/removal evidence, restore the endpoint snapshot or documented baseline, and preserve the operator decision. Do not interpret text entry as proof of code execution.

Describe 'Text-only HID source policy' {
    It 'contains only approved line forms' {
        $Lines = @(Get-Content -LiteralPath .\ducky-demo.txt | Where-Object { $_.Trim().Length -gt 0 })
        $Lines.Count | Should -BeGreaterThan 0
        foreach ($Line in $Lines) {
            ($Line -cmatch '^(DELAY [0-9]{1,4}|STRING [\x20-\x7e]{1,120}|ENTER)$') | Should -BeTrue
        }
    }
}

Get-FileHash -LiteralPath .\ducky-demo.txt -Algorithm SHA256
Get-Module -ListAvailable Pester | Select-Object Name, Version
Invoke-Pester -Path .\TextOnly.Tests.ps1 -Output Detailed
Get-FileHash -LiteralPath .\compiled-demo.bin -Algorithm SHA256
Get-PnpDevice -PresentOnly | Where-Object { $_.Class -eq 'Keyboard' } | Select-Object Status, Class, FriendlyName, InstanceId

Expected Evidence and Interpretation

The Pester example uses current-style syntax and assumes a compatible approved version. The device artefact filename is a local example; use the file produced by your actual device toolchain. The test should reject a GUI shortcut line or an overlong delay but cannot prove that a STRING is safe in every application. Context, compilation, operator control, and endpoint isolation remain essential.

Expected evidence is the reviewed text appearing in the blank editor plus whatever device telemetry the platform actually supplies. Typing into an existing editor may create no new process. Missing telemetry is a visibility limitation, not permission to install invasive keylogging.

Troubleshooting and Cleanup

If Pester is absent or incompatible, use manual source review and the offline JavaScript policy control already provided; do not install unreviewed modules to make the walkthrough pass. If a security product blocks the artefact, record the control outcome instead of disabling it. Remove the device and temporary source/build files according to the agreed retention plan, preserving the reviewed hashes and reset evidence.