{
	"id": "5af04769-856a-4b61-997b-1fc0781c9635",
	"created_at": "2026-04-06T00:09:04.591858Z",
	"updated_at": "2026-04-10T03:21:09.118643Z",
	"deleted_at": null,
	"sha1_hash": "655b9e297dba1249a7727c20cb26b54a10f2b934",
	"title": "New self-protecting USB trojan able to avoid detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 222464,
	"plain_text": "New self-protecting USB trojan able to avoid detection\r\nBy Tomáš Gardoň\r\nArchived: 2026-04-05 14:28:07 UTC\r\nA unique data-stealing trojan has been spotted on USB devices in the wild – and it is different from typical data-stealing malware, reports ESET's Tomáš Gardoň.\r\n23 Mar 2016  •  , 5 min. read\r\nA 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\r\nleaves no evidence on the compromised system. Moreover, it uses a very special mechanism to protect itself from\r\nbeing reproduced or copied, which makes it even harder to detect.\r\nIn this article we will examine the technical details of this interesting malware.\r\n”What really sets this malware apart is its self-protection mechanism.”\r\nWhere other malware uses ‘good old-fashioned approaches’ like Autorun files or crafted shortcuts in order to get\r\nusers to run it, USB Thief uses also another technique. This method depends on the increasingly common practice\r\nof storing portable versions of popular applications such as Firefox, NotePad++ and TrueCrypt on USB drives.\r\nThe malware takes advantage of this trend by inserting itself into the command chain of such applications, in the\r\nform of a plugin or a dynamically linked library (DLL). And therefore, whenever such an application is executed,\r\nthe malware will also be run in the background.\r\nWhat really sets this malware apart, however, is its self-protection mechanism.\r\nThe protection mechanism\r\nThe malware consists of six files. Four of them are executables and the other two contain configuration data. To\r\nprotect itself from copying or reverse engineering, the malware uses two techniques. Firstly, some of the\r\nindividual files are AES128-encrypted; secondly, their filenames are generated from cryptographic elements.\r\nThe AES encryption key is computed from the unique USB device ID, and certain disk properties of the USB\r\ndrive hosting the malware. Hence, the malware can only run successfully from that particular USB device.\r\nThe name of the next file in malware execution chain is based on actual file content and its creation time. It is the\r\nfirst five bytes of SHA512 hash computed from mentioned attributes (file content concatenated with eight bytes of\r\nthe creation time).\r\nBecause of this, filenames are different for every instance of this malware. Moreover, copying malware to a\r\ndifferent place will replace the file creation time so that malicious actions associated with the previous locality\r\nhttp://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/\r\nPage 1 of 4\n\ncannot be reproduced. For a better understanding of the naming technique, please see the image below.\r\nIt was quite challenging to analyze this malware because we had no access to any malicious USB device.\r\nMoreover, we had no dropper, so we could not create a suitably afflicted USB drive under controlled conditions\r\nfor further analysis.\r\nOnly the submitted files can be analyzed, so the unique device ID had to be brute-forced and combined with\r\ncommon USB disk properties. Moreover, after successful decryption of the malware files, we had to find out the\r\nright order of the executables and configuration files, because the file copying process to get the samples to us had\r\nchanged the file creation timestamp on the samples.\r\nThe execution flow of malware is quite simple. Each loader, in turn, loads and executes the following loader\r\nidentified by computed hash according to the naming technique described above. However the execution must\r\nalways start with the first stage loader, otherwise the malware terminates itself.\r\nhttp://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/\r\nPage 2 of 4\n\nFirst stage loader\r\nThe first stage loader is just the malware’s starting point and its main goal is to trick the user into running it. This\r\ncan be done in several ways, but the most interesting is the use of portable applications. We have seen portable\r\nNotepad++ compromised by a malicious plugin as well as a TrueCrypt portable compromised by a malicious\r\n“RichEd20.dll”. This loader also checks whether it is executed from a USB device and whether it is writeable,\r\nwhich is important because the payload will store stolen data here.\r\nSecond stage loader\r\nThe second stage loader is located using the first stage hash. Subsequently, its configuration file is found using its\r\nown 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\r\ndebugger. Finally, the hash of the configuration file is used to compute the name of the third stage loader.\r\nThird stage loader\r\nThe third stage loader handles some anti-AV checks. If one of the processes running is \"avpui.exe\" (Kaspersky\r\nsecurity software) or \"AVKTray.exe\" (G Data security software) is running, execution is stopped.\r\nIts configuration file is found by same technique as used by its predecessor, as is the payload executable. It also\r\ncreates a named pipe to be used to pass the configuration data to the payload. The pipe name consists of the first\r\n30 bytes of a SHA512 hash computed from the computer name.\r\nPayload\r\nFinally, the payload implements the actual data-stealing functionality. The executable is injected into a newly\r\ncreated “%windir%\\system32\\svchost.exe -k netsvcs” process. Configuration data includes information on what\r\ndata should be gathered, how they should be encrypted, and where they should be stored.\r\nThe output destination must always be on the same removable device. In the case we analyzed, it was configured\r\nto steal all data files such as images or documents, the whole windows registry tree (HKCU), file lists from all of\r\nthe drives, and information gathered using an imported open-source application called “WinAudit”. It encrypts the\r\nstolen data using elliptic curve cryptography.\r\nConclusion\r\n\"It would not be difficult to redesign the malware to change from a data-stealing payload to any other\r\nmalicious payload.\"\r\nIn addition to the interesting concept of self-protecting multi-stage malware, the (relatively simple) data-stealing\r\npayload is very powerful, especially since it does not leave any evidence on the affected computer. After the USB\r\nis removed, nobody can find out that data was stolen.Also, it would not be difficult to redesign the malware to\r\nchange from a data-stealing payload to any other malicious payload.\r\nhttp://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/\r\nPage 3 of 4\n\nAs ESET’s statistics shows, that malware is not very widespread. However, it possesses the ability to be used in\r\ntargeted attacks - especially at computers that are not connected to the internet for security reasons.\r\nOur detection name:\r\npayload: Win32/PSW.Stealer.NAI trojan\r\nloaders : Win32/TrojanDropper.Agent.RFT trojan\r\nSHA1 hashes of decrypted binaries:\r\n2C188C395AB32EAA00E6B7AA031632248FF38B2E\r\nB03ABE820C0517CCEF98BC1785B7FD4CDF958278\r\n66D169E1E503725A720D903E1DFAF456DB172767\r\n4B2C60D77915C5695EC9D3C4364E6CD6946BD33C\r\n76471B0F34ABB3C2530A16F39E10E4478CB6816D\r\nSource: http://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/\r\nhttp://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"http://www.welivesecurity.com/2016/03/23/new-self-protecting-usb-trojan-able-to-avoid-detection/"
	],
	"report_names": [
		"new-self-protecting-usb-trojan-able-to-avoid-detection"
	],
	"threat_actors": [],
	"ts_created_at": 1775434144,
	"ts_updated_at": 1775791269,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/655b9e297dba1249a7727c20cb26b54a10f2b934.pdf",
		"text": "https://archive.orkl.eu/655b9e297dba1249a7727c20cb26b54a10f2b934.txt",
		"img": "https://archive.orkl.eu/655b9e297dba1249a7727c20cb26b54a10f2b934.jpg"
	}
}