Inside the USB Thief self-protection mechanism
Researchers at ESET have this week revealed technical details of a rather interesting new piece of malware called USB Thief. Not only does the malware, a data-stealing Trojan, exclusively use USB devices for propagation but it also features a remarkable mechanism for self-protection.
The aptly-named USB Thief differs from your typical piece of data-stealing malware in many ways, not least in that it is tied to a single and specific USB device. This prevents it from leaking from the target and enables a very stealthy attack methodology against even air-gapped systems.
Although the email informing us about the malware nearly had us reaching for the ‘nonsense file’ here at IT Security Thing HQ courtesy of the line “cannot be detected or reverse-engineered” quickly followed by “has been discovered in the wild” – we persevered and are glad we did. What we found was not just some PR puff-wrapped FUDfest but rather a truly intriguing development in malware technology.
USB Thief exclusively uses USB devices for propagation
Obviously whoever wrote the ‘cannot be detected’ line needs to lay down in a dark room for a bit, as ESET appears to have spotted it. The truth is that USB Thief (or Win32/PSW.Stealer.NAI as ESET formally labels it) remains very hard to detect courtesy of the self-protection mechanisms it uses.
For start there is that small fact that it exclusively uses USB devices for propagation and leaves no evidence on the compromised computer that it was ever there. And then there’s the ability it has to prevent reproduction or copying of the malware code itself…
ESET Malware Analyst Tomáš Gardon explains that rather than using Autorun files or shortcuts to get users to run the malware, USB Thief relies upon the storing of portable versions of popular applications such as Firefox, NotePad++ and TrueCrypt on USB drives.
“The malware takes advantage of this trend by inserting itself into the command chain of such applications,” Tomáš says, “in the form of a plugin or a dynamically linked library (DLL). And therefore, whenever such an application is executed, the malware will also be run in the background.”
The malware itself comprises six files, four of which are executables, while the other two act as configuration holders. Some of these files are encrypted using AES-128 in order to prevent copying or reverse-engineering techniques being used against it. Even the filenames themselves are generated from cryptographic elements according to Tomáš.
“The AES encryption key is computed from the unique USB device ID, and certain disk properties of the USB drive hosting the malware,” he writes and goes on to reveal that “the name of the next file in malware execution chain is based on actual file content and its creation time. It is the first five bytes of SHA512 hash computed from mentioned attributes (file content concatenated with eight bytes of the creation time).”
This is one stealthy and intelligent piece of badass malware
So, not only can the malware only run from that particular USB device itself, but filenames will be different for every instance that occurs. Because the file creation time is replaced if you copy the malware to a different location, any malicious actions associated with the original location cannot be reproduced. This is one stealthy, and intelligently constructed piece of badass malware.
No wonder then, that Tomáš admits it was “quite challenging” to analyse. With no access to a malicious USB device itself, and no dropper, creating a clone under controlled conditions was impossible. What ESET did have, however, were submitted files they could analyse.
By brute forcing the unique device ID, and combining this with common USB disk properties, as well as then working out the correct order for the executables (remember the copying process changes the creation timestamps of the samples), researchers were able to eventually get to grips with how this thing works.
Tomáš explains it as a three stage loader flow, leading to the payload. The first stage loader exists to trick the user into running it. ESET notes that a malicious .dll for TrueCrypt portable and a malicious plugin for Notepad++ portable can be used for this purpose. The first stage loader also checks that the USB device is writable, as this is where the exfiltrated data will be stored.
The second stage loader, located using the first stage hash and the configuration file using its own hash subsequently, features an anti-debugging technique whereby the config file contains the encrypted name of the parent process. Unless this is verified, which it won’t be if the malware is running under a debugger as the parent process for example, it will terminate there and then.
That configuration file hash is also used to generate the third stage loader name. This then looks for certain AV processes and stops execution if found. The third stage loader also creates a pipe that is used to squirt config data to the payload, with a name derived from the first bytes of a SHA512 hash generated from the computer name itself.
Which just leaves the payload, that injects the data stealing executable into a “%windir%\system32\svchost.exe -k netsvcs” process created for the occasion.
It sounds unbelievable, like something from a spy movie
In the case that ESET explored, this was configured to steal all data files (images and documents) as well as the entire Windows registry tree and file lists from all drives. This data then being encrypted using elliptic curve cryptography and, as mentioned earlier, stored on the same USB device itself.
This is quite probably the closest we have seen to the spy film type devices where a USB stick is inserted into a target machine, steals all the data and is then removed leaving no trace that it was even there.
As Tomáš points out: “after the USB is removed, nobody can find out that data was stolen” and when you combine this with it being perfect for targeted attacks against high security air-gapped systems, USB Thief looks very dangerous indeed.
So how should you mitigate against such an attack? “USB ports should be disabled wherever possible and, if that’s not possible, strict policies should be in place to enforce care in their use” Tomáš advises, adding that “it’s highly desirable for staff at all levels to undergo cybersecurity training – including real-life testing.”