Search…
Getting Started
The Ducky Script Language
Guides
The Attack Workflow
Whether you’re auditing an ATM, esoteric cash register system, an electronic safe, specialized kiosk or an ordinary Windows PC - the workflow will be similar. Following these steps while developing your attack will help ensure a successful deployment.
Pre-engagement Interactions
As with any audit, pre-engagement interactions may help determine the hardware, software and network environment of the target. Asking detailed questions about the environment before the engagement begins will save time down the line.
Reconnaissance
Regardless of what information is provided in the pre-engagement interactions, it’s always good to double check with reconnaissance. Either in person or online, seek to determine the software and hardware being used by the organization before going in. Since the USB Rubber Ducky will only act as a simple pre-programmed keyboard, a payload written for one system may be useless when deployed against another. Utilize the best social engineering and open source intelligence gathering techniques to determine the state of the environment.
Target
Once you’ve performed your recon, you’ll likely be able to pick out a key target. Perhaps it’s an often unattended kiosk or workstation, a computer connected to a segmented part of the network, or a machine with high level access.
Research
With this target in mind, research the operating system of the machine, it’s installed software and network access. If possible, obtain similar hardware or emulate the target in a virtual machine. For instance, if the target is a slow thin client running an old version of Windows as a domain member running specialized banking software, try to match the target as closely as possible with bare metal or virtual machines.
Write
Begin writing your payload by first manually typing into the target test machine, making careful notes of which keystroke combinations and delays succeed at accomplishing your objective. It is only after you can successfully reproduce your desired outcome manually that you should move on to writing the corresponding USB Rubber Ducky payload to automate the task.
Carefully mind any necessary delays in the ducky script, especially when interacting with GUI elements. The target computer’s CPU speed will play an important role in determining how long to delay between input. If you know that your target is a high-end modern machine you may craft a quicker payload with less delays. On the other hand, if the target is an old and slow machine, you’ll need to be much more conservative on your delays.
Remember, the USB Rubber Ducky does not receive interaction back from the computer, such as the active window. If for instance you script a payload to launch a command prompt and begin typing, be sure to delay long enough for the command prompt to appear before injecting your command prompt keystrokes.
Encode
Once your human-readable ducky script has been written, it’s ready to be converted into a USB Rubber Ducky compatible inject.bin file. Using one of the many duck encoders, specify the ducky script text file as the input and the inject.bin file as your output. Copy this inject.bin file to the root of the Micro SD card.
Depending on your target’s keyboard layout, you may need to specify a language file. This is because different regions use different keymaps. For instance, a computer with a United States layout will interpret SHIFT+3 as the octothorpe / hash / pound symbol (#). A computer with a United Kingdom layout will interpret the same keyboard combination as the symbol for Great Britain Pound / Pound Sterling (£).
Test
With the Micro SD card loaded with the newly created inject.bin file, it’s time to test the payload. Insert the Micro SD card into the USB Rubber Ducky and connect it to the target test machine. Note where the payload succeeds and where it does not. You may need to write, encode and test several times in order to develop a stable, reliable payload. Using a virtual machine for the target test machine is very handy in this regard, as snapshots can be restored after each payload test. Moreover, virtual machines may be more easily customized in order to match the speed of the actual target.
Optimize
Once the payload has been successfully tested and provides the auditor with the desired outcome, it’s time to begin optimization. This may be done to shave off a few seconds from the delivery, or to obfuscate the payload in some way. It’s only after a payload has been successfully developed that optimization should be done, and similar to the initial development, testing should be done at every step to ensure reliable deployment.
If it’s speed you’re after in a payload, be careful not to tweak the delays too low. Just because you’re able to reliably reproduce the attack against your target test machine, doesn’t mean the real target will be as receptive - especially if background tasks are eating up CPU resources. Often it’s the reduction of keystrokes and steps necessary to achieve the goal that’s most effective in optimizing a payload, such as reducing it to a single line of powershell or similar.
Deploy
With the payload written, tested and optimized, you’re finally ready to deploy it against the target. This is where strategies can vary wildly. One scenario may be to social engineer the target machines operator into plugging the USB Rubber Ducky in for you. Another may be to obtain unobserved physical access to the target with a partner or other distraction. Get creative!
As with most things in computing, two is one - one is none. Have a backup. It would be a shame to spend valuable resources gaining access to a secure facility only to have the initial payload fail. Having a less optimized, yet more reliable payload ready to go on another USB Rubber Ducky can make all the difference on an engagement.
Finally, consider a decoy, either as part of your social engineering strategy or in case you get caught. For instance, if you’re attempting to deploy an extremely quick one-line powershell reverse shell against a target Windows PC by pleading the user into printing a document from your USB drive for you - it may seem odd if there are no actual files on the “drive”. Having a similar looking real USB flash drive loaded with a benign document will lower suspicion and make your story seem more legitimate.
Copy link