The USB Stick O' Death
Alright, so maybe this title is a bit hyperbolic and misleading, but I think that this post deserves an exciting name. And yes, it's been a long time since I posted, but screw it, I'll post when I get around to it.
I've recently been researching and experimenting with USB malware, and I wanted to take a shot at developing my own malicious USB stick. Now, I'm aware that SET provides a simple way to quickly backdoor an USB drive, but their implementation is a little lacking in a lot of areas (not to detract from the application, it is a great tool). The executable it creates is a simple meterpreter backdoor, which, though not perfectly detected by any means, still has a higher detection rate than I would like. In addition, it only exploits a single attack vector, abusing AutoPlay. My goals were a 0% detection rate of the payload by antivirus, 32 and 64 bit support, and for the drive to utilize as many technical and social engineering vectors as possible, so it was clear I was going to have to do some work myself. By all accounts, I believe I have largely achieved these goals, and created a very effective, and largely undetected, malicious USB drive. A side note: if you are interested in USB malware, the Teensy HID vector, as far as I can tell, is really the next generation of USB attacks. Sadly, however, I do not have one of these devices yet to play around with, so I decided to focus on getting the most out of the lowly USB drives I had laying around.
I do want to start by saying that this post is not meant to be a "how to" guide on how to create a malicious USB drive, but rather, a documentation of the thought process an attacker might go through to create their own, as well as an illustration of just how large of a security risk the lowly USB drive still poses. There are literally thousands of different design choices that could be made at every point during this process, from social engineering strategies, to what payloads to include, to how to evade antivirus. The methods I ended up choosing are, admittedly, crude and unrefined, but they achieved my intended goals, and gave me, surprisingly quickly, an effective and largely undetected malicious USB drive. Readers interested in creating their own drives should keep this in mind while reading, and are definitely encouraged to take their own approach to solving the problem. As always, let me know if you find something interesting or if you try something different, I'd be very interested in hearing what you did.
Software and Supplies
First, of course, you will need to get the necessary software and supplies. I did all of this with an Ubuntu installation and a Windows VM, so it will be documented as such. If you have a different setup, you will need to alter the process accordingly. In addition to these, I had a U3 enabled USB drive, a recent copy of the Metasploit framework, a copy of the U3 Customizer, a working installation of the mingw64 compiler, a really obscure application called Quick Batch File Compiler, and Ollydbg (or your debugger of choice). A side note: for mingw64 on Ubuntu, I actually ended up using this excellent PPA to get things working; there seems to be a packaging bug in the repositories right now that prevents cross-compilation of 64 bit executables. You probably won't end up needing this, but it's nice to have in case you do. Finally, you can grab a tarball of some of the code I wrote and my autorun configurations, if you want to follow along.
Once you have these things, you should be all set to get started.
Writing a Simple XOR Crypter
The first problem I had to solve was how to decrease the detection rate of my payload. As my first payload, I decided on a standard reverse_tcp meterpreter shell. From this, I could do whatever post exploitation I wanted, including remotely managing the victim's computer safely from a remote location. Many tools, such as the U3 switchblade, run a bunch of tools that collect information on the local machine (passwords, IP, patches, etc) and store the back to the USB drive. However, as I was intending to use this drive in a USB drop style attack, it didn't make much sense to try to gather and save a bunch of information that I might not be able to recover later. As long as I have a shell connecting back to me, I can make any of these attacks run automatically with the AutoRunScript setting anyway.
However, even just with the reverse_tcp shell running, antivirus tends to start throwing up red flags. The meterpreter shell alone, even when embedded in another executable using Metasploit's handy template option, has a little less than 40% detection rate, clearly unacceptable for my purposes. It was pretty obvious that I was going to have to write something to obfuscate my payload.
What surprised me during all of this was how ridiculously easy it is to do just that. About 60 lines of Python (I know, way too many) and 20 lines of C was all it took to take my detection rate from 40% to 1% (32 bit version / 64 bit version). The Python code largely is just to automate things, but it also made the XOR crypting easier and allowed me to more easily embed arbitrary executables in my code (which is useful in embedding other, non-metasploit payloads). It should also help me extend and modify my code when backdoor starts becoming detected (I don't give it long, it's basically the simplest obfuscation ever). In the tarball you grabbed earlier, I included one of the earlier versions of my code (wouldn't want to spoil all the development fun for you all, would I? :P). That version will use Metasploit to generate a payload, create a simple C file that wraps it in a simple XOR crypter, and then compiles it into 32 bit (and 64 bit, if desired) binaries using mingw64. This alone should be more than you need to get started making your own payloads.
I'm still struggling with how low the detection rates got with such a simple technique, as it was essentially the most basic XOR crypter one could write. Even factoring in that it was being cross-compiled with mingw64 rather than natively compiled in Visual Studio or the like (which can throw off some signatures), it still shouldn't have ruined detection rates that badly. I guess I just expect more from antivirus companies than they actually deliver. As you can see, only a single detection is still occurring in my tests: Microsoft's definitions catch my 32-bit payload. However, I suppose 1/86 isn't bad, and I'll be looking into getting that to 0. Any suggestions are welcome.
EDIT: I did a follow-up to this post on avoiding AV detection, in which I solved this detection issue by simply wasting some processor time prior to decrypting the payload. Who knew bypassing AV would be as easy as adding a lowly for loop? :P
64 Bit Support
The next problem to tackle was how to get the payload to work on both 32 and 64 bit systems. And actually, as it turns out, this isn't a problem at all. Although I researched how to generate 64 bit executables, and they hide remarkably well, the 32 bit payload works just fine in 64 bit Windows. I was a bit worried that Metasploit wouldn't be able to migrate to 64 bit processes, but it seems that they added that feature awhile back. So hooray! On to the next step.
In case you do, for some reason however, want a separate 64-bit payload, the quick and easy solution is to simply write a batch file that checks the %PROCESSOR_ARCHITECTURE% environment variable and runs the corresponding payload. There are plenty of other ways to do it too, but this method is pretty straightforward.
Packing Into a Single Executable
For a social engineering attack I will describe later, I wanted to be able to pack a text file, a payload, and a tiny batch file that runs both into a single executable. This is where Quick Batch File Compiler came in. Although a rather obscure, and slightly shady, application, it was able to do four things that are very useful: embed a batch file in an executable (obviously), customize the generated executable with description text and icon, compress and pack any other necessary files inside the executable, and (also very importantly) run the executable in what it calls "ghost mode" (which basically means that no windows are created). You could pretty easily do all of these things on your own using Resource Hacker, iexpress, and/or a little bit of C, but why do work someone has already done for you? There is one drawback to using QBFC: any application compiled in Ghost Mode (with the free version) displays a nag screen every time you run it. I will leave it as an exercise for the reader to figure out how to use Olly (or your favorite debugger) to bypass said issue. Hint: you only need to change a single byte.
Weaponizing the Drive
Once I had a sufficiently invisible and properly packaged payload that would run anywhere, I was ready to weaponize the drive. Now, there are two classic approaches to doing this: either through the use of a U3 drive to exploit AutoRun, or through various social engineering avenues that AutoPlay and Windows provide us. For mine, I decided to take advantage of both.
The U3 vector is pretty straightforward to exploit, and you can see how I went about exploiting it if you look at the autorun.inf in the U3 directory in my source package. All you really need to do is make sure that the open command in the autorun.inf file points to your desired payload, and you are good to go. There are a couple other very useful things that you can do (as you can see in the file), but I will discuss these in the next section. Once you've made your autorun.inf, take it, your icon file, and your malicious executable (I have not supplied one, for obvious reasons), and throw it into the U3CUSTOM folder in the extracted UniversalCustomizer folder. Then simply run the ISOCreate batch file, insert your U3 drive, run the Universal_Customizer.exe file, and walk through the steps. Once your done, you should have a brand new, hard to detect, malicious U3 payload that runs silently in the background on XP.
Now that I had a payload that would run on many computers that aren't locked down sufficiently, I also needed some backup plans, in the probable case that I encountered machines with a competent system administrator. This is where AutoPlay abuse and executable resource hacking come into play. The main problem this tries to address is how can we trick a user into running our backdoor for us, even if they are protected by stronger than ordinary security policies.
As I alluded to earlier, there are a couple of fun, useful tricks that one can do to use AutoPlay to their advantage. The classic one (and one that has been exploited quite effectively by the Conficker worm) is to set a default action for the drive that looks exactly like Windows' normal "Open folder to view files" command. When AutoPlay then pops up, the user (on Windows XP) is presented with a default option to "Open folder to view files" that looks almost exactly like the original one, but that now runs our malicious payload.
We also exploit this same social engineering attack on the Windows 7 U3 autorun. Windows 7 has significantly locked down USB security, but CD security (which is what matters in the U3 attack) is still somewhat lacking. Although the payload no longer runs silently, the user is presented with a prompt asking them if they want to view the files with our malicious payload.
Beyond this attack, we can also set what are known as shell commands, more commonly known as the right click options for the drive. Windows, in its infinite wisdom, decided it was a good idea to allow devices to override the default shell commands if they so desired. By overriding the "Open", "Explore", and "Search..." commands, we can not only all but ensure that any user trying to evade AutoPlay by opening the drive through a right click command will still be compromised, but in a convenient twist, we also override the default double-click command. This means that basically any interaction directly through the drive icon will result in code execution. In fact, the only way I have found to get into the drive if the autorun.inf file has been processed is to browse in manually through the Folders sidebar or by selecting the proper (non-default) "Open folder to view files" command at the AutoPlay prompt. It is unlikely that a user will do things this way, so we can be fairly confident that if AutoPlay isn't disabled (on XP at least) and the user tries to view the files, we will get code execution.
And there you have it: how I developed my USB Stick O' Death, from start to finish. It's not the be-all end-all of malicious USB drives, as the name might imply, but it does provide a down-and-dirty example of how to achieve silent and reliable code execution using USB exploitation quickly and easily. Because I have now published these techniques, it is likely that detection rates for my specific method will go up significantly. However, I hope that I have illustrated just how easy it is to bypass current antivirus detection mechanisms with a little thought and a few lines of C, so that it is trivial for you, the reader, to make them undetectable once again. For myself, writing up this post took significantly longer than actually doing the work, if that gives you any idea of how long it took me to do all of this.
In addition, I hope this has raised awareness on just how trivial it is to use U3, AutoPlay, and social engineering to get users to run malicious code. I know that I certainly learned a few things (specifically, not to use the Explore shell command to open drives). It is clear to me that the only real way to prevent these kinds of attacks, barring some big changes from Microsoft, is to disable or greatly limit USB drives on most networks, and to educate people (possibly through the demonstration of this drive) just how easy it is to go from plugging in a USB drive to an attacker having full access to their computer. Even with proactive steps to counteract these attacks, it is likely, given the current state of USB security, that these attacks will continue to be effective well into the foreseeable future.