[Ducky-Harvest] General questions

[InfiniteBSOD]

Payload Title

Ducky-Harvest

Payload URL

https://github.com/hak5/usbrubberducky-payloads/blob/master/payloads/library/credentials/Duckie-Harvest/payload.txt

Payload Setup

In Payload.txt changed the following:
$_OS = WINDOWS
DEFINE #DUCKY_DRIVER_LABEL DUCKY

In sy_cred.ps1 changed the following:
$DRIVE = 'OUTPUT' # Drive letter of the USB Rubber Ducky
$IP = '' # IP address of the attacker machine
$PORT = '' # Port to use for the reverse shell

Problem Description

In Payload.txt on this row:
$duckletter = (Get-CimInstance -ClassName Win32_LogicalDisk | Where-Object { $_.VolumeName -eq '#DUCKY_DRIVER_LABEL' }).DeviceID;cd $duckletter

Question 1: How can it identify a driveletter for "#DUCKY_DRIVER_LABEL" when it isn't mounted as a storage device?
The error we get is that it can't "cd" to "$duckletter" since the variable duckletter is NULL.
"Cannot process the argument because of the value of argument 'path' is null".

Question 2: If we change #DUCKY_DRIVER_LABEL to a recognized storage device which returns a driveletter we get a lot of other errors which is due to malformed input. For instance "Get-CimInstance" is written as "et-CimInstance" for some reason.

Question 3: How exactly is the:

# IP address of the attacker machine
# Port to use for the reverse shell

meant to work?
Then we need to have another device on the network which runs some application / service and that device isn't a RubberDucky?

Troubleshooting steps

Changing the "DEFINE #DUCKY_DRIVER_LABEL" from "DUCKY" to "OUTPUT" which is a recognized storage device.

Suspected Cause

No response

Screenshots or additional information

No response

Checklist ✅ - READ CAREFULLY

• I checked and didn't find a similar issue already reported
• I am using PayloadStudio to encode this payload
• I made sure to redact any private information in the details shared above
• I have read and followed the documentation provided by the original payload author and configured the payload (if required)
• I have confirmed I am deploying this payload with the correct device intended by the original author (Original USB Rubber Ducky vs New USB Rubber Ducky)
• I have confirmed I am deploying this payload on the correct target host intended by the original author (Windows, Mac, Linux, etc)
• I have confirmed the payload is compiled in the correct keyboard language for the target host I'm trying to deploy it on (US, DE, etc)
• I have actually read the above checkboxes before checking them, including this one, which I have intentionally left unchecked as confirmation of this statement

Agreement

• I believe this is an issue with the actual payload itself. I acknowledge this form is not a request for help following instructions.
• I have carefully read and filled out every section of this issue form to the best of my ability. I acknowledge by providing insufficient information I cannot receieve adequate assistance.

[hak5peaks]

1. The drive label name, is the name used to identify the USB rubber Ducky's drive to a computer. You will see this name when you plug in the Ducky into a computer while its in arming mode or ATTACKMODE STORAGE By default the name is DUCKY this name will be persistent unless changed on the target machine.

2. That DEFINE is used for the drive label name, and should be pointed to the drive label of the Ducky.

3. Yes, this powershell script exfiltrates data and also spawns a reverse shell on the target machine, this is stated in the README.md

[bad-antics]

For Ducky-Harvest setup questions:

Common Setup Issues:

1. Drive Label:
The $DRIVE variable in sy_cred.ps1 must match your Ducky's volume label exactly. Check it:

DEFINE #DUCKY_DRIVER_LABEL DUCKY

Then in PowerShell: (Get-Volume | Where-Object {$_.FileSystemLabel -eq 'DUCKY'}).DriveLetter

2. IP/Port for exfiltration:
If using network exfil, the attacker machine must be listening:

# On your machine:
nc -lvnp <PORT>
# or
python3 -m http.server <PORT>

3. Common pitfalls:

• The Ducky must be formatted as FAT32 with the label matching your config
• $_OS = WINDOWS is correct for Windows targets
• The PowerShell script needs to run with -ExecutionPolicy Bypass
• Windows Defender may block the script — the payload should use obfuscation or AMSI bypass

4. Testing without a target:
You can test the PowerShell script manually first:

Set-ExecutionPolicy Bypass -Scope Process
. .\sy_cred.ps1

5. Exfil methods (in order of reliability):

1. Save to Ducky USB storage (most reliable, no network needed)
2. HTTP POST to attacker server
3. DNS exfiltration (stealthiest)
4. SMTP/email exfil

What specific error are you seeing?