By Tomáš Gardoň posted 23 Mar 2016 - 02:49PM
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.
In this article we will examine the technical
details of this interesting malware.
”What really sets this
malware apart is its self-protection mechanism.”
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.