Stealthy malware targeting air-gapped PCs leaves no trace of infection

Researchers have discovered highly stealthy malware that can infect computers not connected to the Internet and leaves no evidence on the computers it compromises.

USB Thief gets its name because it spreads on USB thumb and hard drives and steals huge volumes of data once it has taken hold. Unlike previously discovered USB-born malware, it uses a series of novel techniques to bind itself to its host drive to ensure it can't easily be copied and analyzed. It uses a multi-staged encryption scheme that derives its key from the device ID of the USB drive. A chain of loader files also contains a list of file names that are unique to every instance of the malware. Some of the file names are based on the precise file content and the time the file was created. As a result, the malware won't execute if the files are moved to a drive other than the one chosen by the original developers.

"In addition to the interesting concept of self-protecting multi-stage malware, the (relatively simple) data-stealing payload is very powerful, especially since it does not leave any evidence on the affected computer," Tomáš Gardoň, a malware analyst with antivirus provider Eset, wrote in a blog post published Wednesday. "After the USB is removed, nobody can find out that data was stolen. Also, it would not be difficult to redesign the malware to change from a data-stealing payload to any other malicious payload."

The malware has targeted organizations in African and Latin American countries, Gardoň said in an e-mail that didn't elaborate or identify the specific industries hit. At the moment, detection rates are extremely low. At the time this post was being prepared, Virus Total, the Google-run service that tracks unique malware infections around the world, had no record of the malware ever being uploaded.

Bridging the (air) gap

The malware is notable for its similarities to state-sponsored threats that have targeted governments and critical infrastructure in the Middle East for years. The Stuxnet worm that the US and Israel reportedly unleashed to disrupt Iran's nuclear program was also spread on USB drives, because many of the systems it targeted weren't connected to the Internet. By infecting computers each time a booby-trapped drive was inserted, Stuxnet aimed to bridge these so-called air gaps. USB Thief has the same ability to infiltrate sensitive networks.

One of the major failures of the Stuxnet operation was its designer's inability to maintain control of the computers that were infected by the self-replicating malware. What's more, the Stuxnet code was also easily dissected by researchers, allowing them to eventually figure out it targeted industrial control systems. Gauss, another piece of malware spawned from at least some of the same developers as Stuxnet, didn't make the same critical mistakes. Its mystery warhead was encrypted using a key derived from a single computer that has yet to be publicly identified.

By binding the malicious payload to a single computer, Gauss ensured it wouldn't inflict collateral damage the way Stuxnet did. It has also created one of the biggest mysteries in the annals of computer security: what does the Gauss payload do, and who did it target?

Preventing copycat attacks

The encryption used by USB Thief has a similar, though less limiting, effect. It ensures that only the USB drives originally designated by the malware developers can act as infection agents. There's nothing in the Eset analysis that indicates a single USB drive can't infect an unlimited number of computers, so the measure still isn't as powerful as the one put into Gauss. Still, binding the malware to a single USB stick goes a long way to reducing its ability to spread and is an indication the developers intended narrow, surgical strikes rather than one that hit large numbers of victims. Beyond preventing copycat attacks, the self-protection measure also makes analysis and reverse engineering much more difficult.

Gardoň wrote:

It was quite challenging to analyze this malware because we had no access to any malicious USB device. Moreover, we had no dropper, so we could not create a suitably afflicted USB drive under controlled conditions for further analysis.

Only the submitted files can be analyzed, so the unique device ID had to be brute-forced and combined with common USB disk properties. Moreover, after successful decryption of the malware files, we had to find out the right order of the executables and configuration files, because the file copying process to get the samples to us had changed the file creation timestamp on the samples.

The execution flow of malware is quite simple. Each loader, in turn, loads and executes the following loader identified by computed hash according to the naming technique described above. However the execution must always start with the first stage loader, otherwise the malware terminates itself.

First stage loader

The first stage loader is just the malware’s starting point and its main goal is to trick the user into running it. This can be done in several ways, but the most interesting is the use of portable applications. We have seen portable Notepad++ compromised by a malicious plugin as well as a TrueCrypt portable compromised by a malicious “RichEd20.dll”. This loader also checks whether it is executed from a USB device and whether it is writeable, which is important because the payload will store stolen data here.

Second stage loader

The second stage loader is located using the first stage hash. Subsequently, its configuration file is found using its own hash. The configuration file contains the encrypted name of the parent process to be verified. This is an anti-debugging trick, which will cause termination of the malware if it is running under a different parent process, i.e. a debugger. Finally, the hash of the configuration file is used to compute the name of the third stage loader.

Third stage loader

The third stage loader handles some anti-AV checks. If one of the processes running is “avpui.exe” (Kaspersky security software) or “AVKTray.exe” (G Data security software)... execution is stopped.
Its configuration file is found by [the] same technique as used by its predecessor, as is the payload executable. It also creates a named pipe to be used to pass the configuration data to the payload. The pipe name consists of the first 30 bytes of a SHA512 hash computed from the computer name.

Payload

Finally, the payload implements the actual data-stealing functionality. The executable is injected into a newly created “%windir%system32svchost.exe -k netsvcs” process. Configuration data includes information on what data should be gathered, how they should be encrypted, and where they should be stored.

The output destination must always be on the same removable device. In the case we analyzed, it was configured to steal all data files such as images or documents, the whole windows registry tree (HKCU), file lists from all of the drives, and information gathered using an imported open-source application called “WinAudit”. It encrypts the stolen data using elliptic curve cryptography.

Unlike most USB-borne attacks, USB Thief doesn't rely on autorun features or operating system vulnerabilities to spread. Instead, it inserts itself into the command chain of portable versions of legitimate applications. Such portable versions are often run from USB drives and are common with applications such as Firefox, NotePad++, and TrueCrypt. As a result of the chaining, when the portable app is run the malware is executed in the background.

There are indications that the USB Thief developers devoted a fair amount of testing to make sure the trojan worked properly under a variety of different scenarios. The malware, for instance, won't install itself in the event the target machine is running antivirus software from Kaspersky Lab or G Data, presumably because those programs either detected the malware or created performance problems.