A unique data-stealing trojan has been spotted on USB devices in the wild – and it is different from typical data-stealing malware. Each instance of this trojan relies on the particular USB device on which it is installed and it leaves no evidence on the compromised system. Moreover, it uses a very special mechanism to protect itself from being reproduced or copied, which makes it even harder to detect.
Where other malware uses ‘good old-fashioned approaches’ like Autorun files or crafted shortcuts in order to get users to run it, USB Thief uses also another technique. This method depends on the increasingly common practice of storing 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, 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.
What really sets this malware apart, however, is its self-protection mechanism.
The protection mechanism
The malware consists of six files. Four of them are executables and the other two contain configuration data. To protect itself from copying or reverse engineering, the malware uses two techniques. Firstly, some of the individual files are AES128-encrypted; secondly, their filenames are generated from cryptographic elements.
The AES encryption key is computed from the unique USB device ID, and certain disk properties of the USB drive hosting the malware. Hence, the malware can only run successfully from that particular USB device.
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).
Because of this, filenames are different for every instance of this malware. Moreover, copying malware to a different place will replace the file creation time so that malicious actions associated with the previous locality cannot be reproduced. For a better understanding of the naming technique, please see the image below.
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) is running, execution is stopped.
Its configuration file is found by 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%\system32\svchost.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.
Conclusion
“IT WOULD NOT BE DIFFICULT TO REDESIGN THE MALWARE TO CHANGE FROM A DATA-STEALING PAYLOAD TO ANY OTHER MALICIOUS PAYLOAD.”
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. 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.
As ESET’s statistics shows, that malware is not very widespread. However, it possesses the ability to be used in targeted attacks – especially at computers that are not connected to the internet for security reasons.
Source: www.welivesecurity.com/
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
