Malicious USB devices (BadUSB, "USB Rubber Ducky", et al.) have a variety of applications for pen-testers and security researchers alike; by providing an additional surface/avenue for the delivery of exploits and direct access to target device USB layer for further analysis. Unfortunately, this can get quite expensive when your typical red-team engagement requires in excess of $500 worth of these disposable USB devices; logistically we cannot depend on the device being out-of-stock or limited in quantity. Additionally, some of these existing devices like the "USB Rubber Ducky" do not have open hardware designs or documentation for extending upon the platform, and the BadUSB platform is an unviable option due to the specific group of USB's and the chipset which had the flaw being phased out of the market, making them impossible to reliably source.
This is part one of a multi-part series describing the design and build of USB attack devices and the underlying use cases for them. In this post, I will discuss the strengths and weaknesses of developing and using this type of device, and then I briefly will walk through how we designed and built a reliable and affordable prototype.
Disclaimer: malicious attacks should be carried out only against systems that you own or have permission to attack. As in all posts on blog.seekintoo related to computer "hacking" or unethical activities, "Seekintoo Ltd." is not liable for involvement with the use of this information in other activities.
What are they?:
Generally speaking, "USB Attack Device(s)" are typically comprised of some type of micro-controller that can interface with a target system through the use of a USB class interface. Once connected, the interface is opened up to the micro-controller and it can configure itself in attempt to infiltrate the target through automatic execution of code and/or actions via the use of the HID (Human Interface Device) class as a keyboard and/or mouse; or composite HID + MSD (Mass Storage Device) class to execute payloads from on-board storage to exfiltrate data in and/or out of the target network, in some cases even if its air-gapped.
Other devices (although not publically discussed) can take advantage of 0-day vulnerabilities in the driver and protocol level of the underlying system implementing the USB stack and it's related facilities, thus (in most cases) providing access to the highest privilege operating level of the target system. These devices are highly targetted and specifically designed for the system in interest.
How/Why are they used?:
Dropping these devices in a parking lot, ontop a photocopier, front desk, etc. is an effective attack vector for a pentester or malicious attacker, as has been demonstrated by large scale studies such as this one1 where 297 standard flash drives of varying makes and models, in different locations, and at different times on the University of Illinois campus were dropped with a malicious piece of software contained in them, notifying the researchers when someone plugged the device in to take a look at the contents.
So, when you see something of value such as an unknown wallet, keys, cellphone, etc. on the ground in front of you, do you pick it up? Perhaps you can find the owner if you just look in the wallet and check for some kind of identification, the premise is the same, and the premise is human nature.
The abstract in the study notes:
"We analyze the types of drives users connected and survey those users to understand their motivation and security profile. We find that a drive’s appearance does not increase attack success. Instead, users connect the drive with the altruistic intention of finding the owner"
Only 18% of unknowing users actually returned the drives to the locations attached to the tag on the USB:
"Most of the users who returned drives to us were administrative personnel that acted as the lost and found contact for their department (59%) or IT staff (33%)"
The statistics represented in the study show that the ability of a pentester or malicious attacker to have this type of device in their toolkit can be an invaluable pivot tool into their target if properly executed.
Compromising a target system using our USB key is done in three stages, as depicted in Fig 3. Those three stages are:
Dropping the Device: The first stage requires getting the innocuous-looking USB(s) as close as possible to the target without raising reasonable suspicion. Here, we place it on a breakroom coffee table.
Flavored Payload Delivery: The second stage involves the victim plugging in the device to a target system (hopefully), once plugged in system fingerprinting will begin by comparing the first ten USB packet control transaction requests collected per major operating system against a known set of control transactions recorded during startup of other platforms. Once fingerprinted, if a given payload "flavor" is available for the target system, it gets run. This usually involves injecting the keystrokes that will form the commands needed to spawn second and third stage payloads for exploitation and information gathering.
Exfiltration/N-stage: Here we connect to 3rd and 4th stage payloads depending on the requirements of the attack and optionally send some gathered system intelligence back to in-house C2 (Command & Control) through a variety of exfiltration methods. - Note: This is the point when you start thinking about getting the data out of the network, even if it's air-gapped - but we will cover this in another post.
|Payload Delivery Methods||Cost & Difficulty Factor||Reliability||Chance of Detection||Multiple Targets|
|0-day (Protocol/Driver)||☠️☠️☠️☠️ (???)||☠️☠️☠️☠️||☠️||☠️|
|HID+-MSD Spoofing (Autorun)||☠️☠️||☠️☠️☠️||☠️☠️||☠️☠️|
|Social Engineering (Clicking)||☠️||☠️||☠️☠️☠️☠️||☠️☠️☠️|
Table 1. Strengths and Weaknesses of Payload Delivery Ratings
Now that we understand the generally how we want to approach attacking our target, we need to evaluate the strengths and weaknesses that might be associated with the payload delivery methods seen earlier using each area reported in Table 1. Briefly, here is an analysis of the possible trade-offs.
Cost & Difficulty Factor: The first aspect to consider about the task at hand it how difficult and costly it is to create each type of USB attack device. Devices that take advantage purely of social-engineering are the easiest to create as they use simple HTML files, shortcuts, etc. HID+-MSD-based keys are moderately difficult to create as off-the-shelf hardware must be programmed by someone with extensive USB protocol expertise and it's appearance made customized. The elusive 0-day-based keys are likely much harder to make as they require finding a 0-day vulnerability, implementing the low-level code to exploit it, and creating a realistic-looking key to deliver it.
Reliability: The second side to take into consideration, is how reliable the attack will be. The social engineering approach is the least reliable attack because it requires the user not only to plug the key in but also to click on a file. This might not sound like a stretch, but for organizations with any resemblance of awareness training, this may be a mitigating factor. On the other hand, a HID+-MSD key can be made to be very reliable as it will forcefully trigger the attack as soon as the key is plugged in; and lastly, 0-day keys are likely to be very reliable for a specific OS version, or even range of versions.
Chance of Detection: The third aspect to consider is how stealthy the attack is and how much suspicion it will trigger. Social engineering attacks can be very obvious, as you have files with HTML, Office or shortcut extensions. An HID-based attack has to spawn a terminal and very quickly inject a set of commands that is very visible but only for a short period. Once the attack has been carried out, there is nothing left to see, so this type of attack is less obvious than the social engineering one. Finally, a 0-day-based attack will be completely invisible, as it is at the driver level. Like an HID attack, the victim may be a little suspicious because the key will appear as if it is not working but this can be fixed by faking or adding legitimate mass storage.
Multiple Targets: The last thing to consider is how portable the attack is. If it is a targeted attack, the OS and even the specific version might be known. However, for a pentest or a broad-spectrum attack, the targets will likely be a diverse pool of Windows, OS X, and even Linux computers. A social engineering attack is by nature cross-platform, as HTML files are understood by every OS. An HID-based attack can be made cross-platform, but this requires quite a bit of work as discussed later. A 0-day attack is usually not portable, as it exploits a bug that is only present in a specific version of a specific OS. Making such attacks portable requires using multiple 0 days (or at least different exploit code) that would cover all the possible OSes and versions targeted. This multi-exploit strategy is one of the methods we attempted by embedding multiple exploits to target various Windows versions.
So with all things above considered, the list of ideal features for our hardware platform would consist of features and capabilities like so:
During some initial research, we decided to check if there were any legitimate "USB Rubber Ducky" clones or alternatives and we found some clones, fakes and DIY versions of the device.
In the end, we found that 99% of these will not work out of the box for one simple reason, they do not come equipped with a supporting USB firmware stack or chipset to deliver a composite USB class device with the combined HID and MSD classes. Bootloader space on the Atmel chips being used by these alternatives is also usually limited to 512B in size, and due to the default bootloaders not being configured properly for MSD class operations, it becomes quite frustrating and challenging fiddling with the low-level development of a more advanced mass storage device within this 512B of codespace. Given the cheapness of these alternatives and lack of knowledge on their design, we opted for something with greater ease of use and already in the form factor we needed.
Fig 5. PJRC's Teensy ver. 3.2
For the hardware, after doing some research through the requirements listed previously, I found the "Teensy" platform to be a prime candidate, as it checks all boxes. The author has created a fully open USB stack in conjunction with a hardware platform that allows for rapid debugging and prototyping thanks to it being able to be flashed over USB instead of ICSP thanks to it's marvelous and proprietary bootloader design called "Halfkay" (512B). The Teensy platform fits within our max size requirement, has a blazing fast NXP ARM processor up to 120MHz and SPI flash support.
As of writing this the Teensy ver. 3.2 can be had for between 17 and 23 bucks CAD, which is quite a lot cheaper than the "USB Rubber Ducky" at 60+ CAD. Unfortunately this Teensy isn't picture perfect and we are still missing flash storage for the MSD USB class we are hoping to use.
The Teensy ver. 3.2 comes with a rear-bottom footprint for adding a USB type A connector directly to the device, after a quick solder job and some shelling out of an old Lexar flash drive, the tiny Teensy seems to fit well:
Next, flash storage needed to be added, but unfortunately the supplier that we used did not sell any SD card or mass storage attachments specifically for the Teensy 3 series that fit in our size constraint. Again, we opted to build a compact storage attachment instead which we called a "backpack"; to connect directly to the Teensy's SPI ports. I shaped the "backpack" into the outline of the microSD card, which I thought gave it a pretty neat and compact look:
Fig 7. "Backpack" PCB design in Eagle PCB Studio & Fitment test in AutoCAD
We then sent the design files in for assembly to a local board house and had some working prototypes just a few days later. The total cost altogether for this little guy is just $5 assembled (not including SD card); a fantastic price.
In the end we were able to build an effective prototype at a total end cost of approximately $25 a piece, it fits neatly in old USB enclosure, which can be had by the thousands on Alibaba for no more than a buck a piece, and it has the same hardware capabilities as the "USB Rubber Ducky". Although we haven't yet discussed the firmware aspect of the device, in a future article we look into how we designed the firmware and other interesting features such as OS fingerprinting, disk size spoofing, filehandle spoofing, and many other interesting tricks and use cases.
1 M. Tischer, Z. Durumeric, S. Foster, S. Duan, A. Mori, E. Bursztein, and M. Bailey, “Users really do plug in usb drives they find,” 2016. [Online]. Available: https://cdn.elie.net/publications/users-really-do-plug-in-USB-drives-they-find.pdf
Comments, concerns, and corrections are welcome and not triaged by any marketing machine we are aware of: dpidhirney (at) seekintoo (dot) com