The Bash Bunny is a versatile USB tool. It comes with several “Attack Modes” which actually are instructions to enable certain devices it should present to the “victim” machine.
The “Attack Modes” are SERIAL, ECM_ETHERNET, RNDIS_ETHERNET, STORAGE, and HID. Today, we’re going to look specifically at the “HID” type.
Since the Bash Bunny expects a payload in order to perform its duties, we need to create a payload file. This will be a file actually named “payload.txt” located in one of the switch directories under the payloads directory of the device.
In order to play with this, we’ll present two different payload files that do essentially the same thing, but will identify which switch folder the payload came from. This will let us validate that the switch positions labeled by the documentation match the “switch” folder name on the device itself.
Our first payload will be located under the “switch1” folder, and our second under the “switch2” folder. The payloads are below.
#Payload1 = switch1/payload.txt
ATTACKMODE HID
QUACK STRING I am on switch one!
#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK STRING I am on switch two!
After saving both of these, we can unplug the Bash Bunny, click the switch one notch (to the documented “switch2” position,) bring up a notepad or other scratch space typing field, and plug it back in. We wait a few seconds for the Bunny to initialize/boot, and then we see “I am on switch two!” as we expect to see.
Unplug, click the switch one more notch (to the documented “switch1” position,) and do the same wait for boot, and finally we get “I am on switch one!” as we expected.
If we have a more elaborate DUCKY script we would like to use, we can put that into a file to itself, and change our “QUACK” command to call that file.
#Ducky Script1 = switch1/ducky_payload.txt
#Payload1 = switch1/payload.txt
ATTACKMODE HID
QUACK ducky_payload.txt
#Ducky Script2 = switch2/ducky_payload.txt
#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK switch2/ducky_payload.txt
In the examples above, the first payload does not work, but the second payload, does. This means the “switch#/<filename>” format is necessary in order to load that DUCKY script file. These are things that need to be considered when working with the Bunny payloads.
These example payloads just mimic the USB Rubber Ducky at this point. The LED wasn’t manipulated in these examples. There is no feedback other than the keyboard, and we didn’t utilize any other devices. The wait time to boot makes this a poor choice when speed is of the essence, so this definitely does not replace the USB Rubber Ducky for straight up HID attacks. It does, however, provide the ability to produce more feedback (by way of blinking/solid/different colors on the LED) as well as the ability to carry two different payloads without having to “reload” the device by updating the “inject.bin” file in between. It is easier to use, since the DUCKY script doesn’t have to be converted into an “inject.bin” to begin with. Once we throw in some other Attack Modes, we’ll be able to do some more elaborate payloads to carry out our needs.
It also has some flexibility in that you can use “QUACK STRING” followed by a “bash” variable, or a command, in order to see output from such. You could use this functionality to use a network based attack mode to generate a “loot” file, then follow it up with a HID attack mode to pull up a text editor, and type the contents of the “loot” file for immediate display, if you so desired.
#Ducky Script2 = switch2/ducky_payload.txt
#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK STRING $( ls /root/udisk )
One caveat with this is that using “QUACK” with any combination of “switch” followed by “.txt” (no matter what the characters are in between) causes it to NOT display that string. It seems like a bug, since “QUACK STRING” shouldn’t care what comes after it, but “QUACK switch1/<filename.txt>” matters for loading from a file. I think it should do a “QUACK STRING” check before it does any decision making on whether to try to load a file, and if it’s not “STRING” then consider the file name from there, but I haven’t looked at the code (if it’s available) to see if there’s an easy fix to offer.
Next week, we’ll look at the STORAGE Attack Mode.
