USB spear-phishing weapons (part 1)

Patrick Zwahlen
Périphérique USB Phishing Spear Phishing USB Device
Cybersecurity Blog

This two-part article is about using USB pen drives as spear-fishing "weapons". We can argue that simply putting an executable on a standard USB drive has good chances to "just work", but as pen-testers we always want to increase our success rate.

In Part 1 (below), we will see how this can be achieved using very specific tools that we only recently discovered. These tools can completely change the way a USB drive is seen by the operating system, potentially making it easier for users to execute code without realising it.

In Part 2, we will explain how we used these tools for a recent customer engagement.

A good old engagement

It all started with a customer requesting a rather "classical" spear-fishing engagement. However, rather than using an e-mail as the vector, he asked us to send physical USB pen drives to a "randomly" chosen list of employees, together with an accompanying letter designed to encourage the user to look at the drive's contents.

Again, nothing new here, we have all heard about the USB keys left behind in the parking lots years ago. The challenge today is more about how recent operating systems are trying to avoid these scenarios. Windows "AutoRun" [Ref1] died with Windows XP and Windows Vista introduced "AutoPlay" [Ref2]. The major difference is that "AutoPlay" will not automatically execute code from the drive. Instead, the drive will be quickly analysed and based on the content, some options will be presented to the user, such as:

  • Import Pictures and Videos
  • View Pictures
  • Play Music
  • Open folder to view files

However, "AutoPlay" still behaves differently depending on the inserted device "type". For mass storage USB devices, the following types are recognized by the Windows kernel driver (click on images to enlarge):

More specifically, for the type DRIVE_CDROM, "AutoPlay" will still present an option to "Install or run program from your media", which can be entirely configured from an "autorun.inf" file on the drive, as we will see later. This obviously doesn't give us code execution but we are now just one click away from success. The requirement, though, is to have the device seen as a CD-ROM and not as a standard USB pen drive.

The traditional answer

Historically, pen-testers used the now infamous U3 drives [Ref3] for such engagements. U3 was a joint venture between SanDisk and M-Systems, founded in 2004, right when Windows XP had a working "AutoRun" with automatic code execution.

U3 devices were actually "schizophrenic" devices behaving both as a CD-ROM and a USB drive. This was achieved by having 2 partitions. The CD-ROM partition contained a "LaunchPad" that would automatically present and run portable applications hosted on the standard USB partition.

SanDisk provided tools for upgrading the "LaunchPad". These tools were simply grabbing an ISO image from the Internet and burning this image to the CD-ROM drive partition. A simple entry in the local "hosts" file would force this updater to read a modified ISO image from our own web server, containing malicious code. The USB key was then ready to be sent to the target.

As it was considered potentially too harmful (and a bad approach), U3 was phased out in late 2009.

The world of USB manufacturers

Being unable to put our hands on enough U3 old drives we had to look for alternatives for this new engagement.

A quick Google search indicates that in some cases, depending on various factors, some USB drives can still be reflashed and presented as dual-personality drives. This looked interesting and we learned a lot from this. Deep-dive into the world of USB manufacturers!

First of all, we understood that USB drives are actually made out of 3 main components:

  • The hardware flash modules, used to actually store the data
  • The hardware controller, interacting between the USB bus and the flash modules
  • The software firmware executed by the controller

The flash modules are manufactured by a rather limited list of vendors: Micron, Toshiba, SanDisk, Intel, Hynix, Samsung and probably a few others. They can be either SLC, MLC or TLC flash types.

On the controller side, we have identified at least 40 different manufacturers. Finally on the firmware side, we had a hard time finding 2 USB drives with the same firmware so this is a constantly changing area.

To give you a better idea of the situation, we bought 4 identical keys from a local (trusted) shop. These 4 keys were all using the same controller so that seems to be a constant for a manufacturer at a given time. However, the flash chips were from 3 different manufacturers, using both MLC and TLC technologies. Clearly, the manufactures are buying the cheapest flash on a daily basis. Finally, on the firmware side, no two versions were identical.

On top of that, one of the 4 keys was luckily enough containing a pre-installed executable, flagged as "potentially unwanted program" by 70% of VirusTotal. Infection at the supply chain is clearly a reality!

This site [Ref4] is the ultimate reference for everything USB. Be warned, the site is in Russian and you might find that Google translate comes in handy. In the list of generic tools, the most important one is "ChipGenius" which will give us all the details about an inserted USB key. For one of our 4 keys, it tells us the following:

We can see the controller vendor, the firmware version and the flash type.

Then, we looked at all the available low-level tools for the most used controllers. We finally set our minds on Phison, because it was used by many of the USB keys we found around and it has many low-level tools available, including some that can completely update the geometry and partitioning of the drive.

It is interesting to note that the SRLabs BadUSB presentation from 2014 [Ref5] also used the Phison controller as a base.

USB supply-chain tools (Phison)

This page [Ref6] lists all the available tools for the Phison controller. There are dozen of them (some only available with a Chinese user interface!). We found out that the Windows tool "MPALL" was quite generic and covered many versions of the Phison controller. It looks like this:

The tool can flash 16 drives simultaneously and is therefore clearly designed for factory supply-chains. In the picture above, you can see our drive inserted in one of the USB port with the controller hardware (Phison 2251-67) and flash type (Toshiba TLC).

The tool reads its configuration from an .INI file (top-right). There are also Windows GUI tools for creating this file, as can be seen below.

This first tab specifies the controller type. It also allows for reflashing the firmware. Phison firmware is made of two parts, a "burner" file and a "firmware" file. From our experimentations, it looks like some firmware does not allow re-partitioning so depending on the current firmware on the key it might be required to reflash it with a different version. The above-mentioned web site also contains some archives with firmware versions. Note that reflashing the firmware triggered the most issues and that we completely screwed up some keys. You've been warned!

The next tab is definitely the holy grail of this whole process. It is where we can specify the number and type of partitions. When creating a CD-ROM partition, it conveniently takes an ISO image as input.

All that is required now is to save this configuration in an .INI file and use that file as an input to the "MPALL" utility described earlier. Chances are you will end up with a properly configured drive (and chances are you've just lost a few bucks and will throw away your drive).

Conclusion

In this first part, we have seen how to change the personality of a standard USB Pen-drive with existing tools.

In the second part of this article, we will see how we used this "feature" in order to create a specific payload for our customer.

References