{
	"id": "7ade58e8-7ee1-4695-af64-a608666f3216",
	"created_at": "2026-04-06T00:20:10.196632Z",
	"updated_at": "2026-04-10T03:20:25.238097Z",
	"deleted_at": null,
	"sha1_hash": "21e3b27ab19a1ed7f4d4c163bf4ae4ab3f5d0043",
	"title": "How Malware Generates Mutex Names to Evade Detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 108302,
	"plain_text": "How Malware Generates Mutex Names to Evade Detection\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 21:20:05 UTC\r\nMalicious software sometimes uses mutex objects to avoid infecting the system more than once, as well as to\r\ncoordinate communications among its multiple components on the host. Incident responders can look for known\r\nmutex names to spot the presence of malware on the system. To evade detection, some malware avoids using a\r\nhardcoded name for its mutex, as is the case with the specimen discussed in this note.\r\nStatic Mutex Names as Indicators of Compromise\r\nFor background details about mutex (a.k.a. mutant) values and their role in incident response, see my earlier\r\narticle Looking at Mutex Objects for Malware Discovery and Indicators of Compromise. As I described there,\r\nwhen examining a potentially-infected system, we can look for names of mutex objects known to be used by\r\nmalicious programs. Moreover, in some circumstances, mutex values could be used as markers to immunize the\r\nsystem from infection. Not all malware uses mutex objects, but this is an indicator that's worth looking for.\r\nThis approach works well when you've already found malware on some systems and examined it to determine that\r\nit uses specific mutex names. You can also obtain mutex name details from threat intelligence feeds, sites such as\r\nTotalHash, and the use of automated malware analysis tools. For a long list of mutex names used by various\r\nmalware samples, take a look at the list published by Hexacorn.\r\nHowever, malware could name its mutex objects in a less-predictable way, as discussed below.\r\nMutex Defined by TreasureHunter Malware\r\nLet's take a brief look at a malware sample with the MD5 hash 070e9a317ee53ac3814eb86bc7d5bf49. Its author\r\ncalled this malicious program TreasureHunter, according to a couple of strings that were embedded into the file:\r\nc:\\users\\admin\\documents\\visual studio 2012\\projects\\treasurehunter\\release\\treasurehunter.pdb\r\nTreasureHunter version 0.1 Alpha\r\nThis malicious file was named jucheck.exe and was discovered under the %AppData% folder. We won't look at all\r\naspects of this malicious program, since my goal is to focus on its use of mutex objects for this article.\r\nIf you infect a laboratory system with TreasureHunter, you can use a tool such as Process Hacker to spot that this\r\nmalicious process creates a mutex named 53c044b1f7eb7bc1cbf2bff088c95b30.\r\nhttps://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/\r\nPage 1 of 4\n\nYou can further investigate TreasureHunter's use of the mutex by running the malicious executable in a debugger\r\nsuch as OllyDbg. As you can see in the screenshot below, specimen calls CreateMutexA to create the mutex:\r\nRunning the specimen multiple times results in the same mutex name being used across the experiments. At this\r\npoint, you might be inclined to use the mutex name 53c044b1f7eb7bc1cbf2bff088c95b30 as an indicator of\r\ncompromise for TreasureHunter. However, further analysis would show that on other systems this sample names\r\nmutex objects differently. For instance, VirusTotal reports the mutex name 3ed1ed60c7d7374bf0dd76fc664b39cd,\r\nwhile VxStream Sandbox reports the name 3ac22cadc45e0558cad697d777f6c3d3. Why such a discrepancy?\r\nHow TreasureHunter Generates the Name of Its Mutex\r\nThe names of this specimen's mutex object appear to be MD5 hashes, but what value is the specimen hashing?\r\nLooking more closely at TreasureHunter with the help of a debugger can shed some light on this functionality.\r\nThe OllyDbg screenshot above shows that the specimen stored the name of its mutex in a variable located at the\r\noffset 414EA0. You could scroll up in the program's code to find which assembly instruction saves data into that\r\nmemory location. As shown in the following screenshot, the string representing the name of the mutex is being\r\nmoved into that location from the register EAX. This register stores the results of the previously-invoked function,\r\nwhich in our example is 402480:\r\nWe could use the debugger to drill into that function to determine how it derives the name of the mutex. That\r\nfunction ends up calling function 401F10, which returns the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH,\r\nas shown below. I replaced some characters of the string with XXXXX and YYYYY for privacy reasons:\r\nLater, the code calls function 401020, which returns the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH( as\r\nshown below:\r\nhttps://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/\r\nPage 2 of 4\n\nFurther, the code computes the MD5 hash of the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH( to derive\r\n53c044b1f7eb7bc1cbf2bff088c95b30, which it ends up using as the mutex name.\r\nWhere does the string RTTDK-XXXXX-P97R3-YYYYY-8K7PH come from? To figure that out, we can drill into\r\nfunction 401F10, which returned this value. That function invokes several API calls to read the system's registry:\r\nThe goal of this code is to read HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\DigitalProductId:\r\nThis is where Windows stores its Product ID. The specimen also looked in several other registry locations where\r\nWindows sometimes stores this information.\r\nFurther in the function, the specimen's code transformed the Product ID's into the RTTDK-XXXXX-P97R3-\r\nYYYYYY-8K7PH that it later used as the basis for its mutex name using a deterministic algorithm that I had\r\nneither the patience, nor reason to reverse-engineer. This is why when this specimen ran in automated malware\r\nanalysis sandboxes it used a different mutex value--those products must have had different Windows Product IDs.\r\nThe Use of Non-Static Mutex Values in Malicious Software\r\nMalware authors who wish to employ mutex objects need a predictable way of naming those objects, so\r\nthat multiple instances of malicious code running on the infected host can refer to the same mutex. A typical\r\nway to accomplish this has been to hard-code the name of the mutex. The author of TreasureHunter decided to use\r\na more sophisticated approach of deriving the name of the mutex based on the system's Product ID. This\r\nhelped the specimen evade detection in situations where incident responders or anti-malware tools attempted to\r\nuse a static object name as the indicator of compromise.\r\n-- Lenny Zeltser\r\nLenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze\r\nmalware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog, where he\r\ncontemplated using mutex objects and other infection markers for immunizing systems.\r\nhttps://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/\r\nPage 3 of 4\n\nSource: https://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/\r\nhttps://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MITRE"
	],
	"references": [
		"https://isc.sans.edu/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429/"
	],
	"report_names": [
		"19429"
	],
	"threat_actors": [],
	"ts_created_at": 1775434810,
	"ts_updated_at": 1775791225,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/21e3b27ab19a1ed7f4d4c163bf4ae4ab3f5d0043.pdf",
		"text": "https://archive.orkl.eu/21e3b27ab19a1ed7f4d4c163bf4ae4ab3f5d0043.txt",
		"img": "https://archive.orkl.eu/21e3b27ab19a1ed7f4d4c163bf4ae4ab3f5d0043.jpg"
	}
}