{
	"id": "8b70b2ee-3f32-4bca-ba1a-088125758d4a",
	"created_at": "2026-04-06T00:13:24.288908Z",
	"updated_at": "2026-04-10T03:20:30.753814Z",
	"deleted_at": null,
	"sha1_hash": "c4bfac2bf9f229d7e1476c9edbc5daf0d6fee9da",
	"title": "Loki-Bot: Come out, come out, wherever you are!",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1100551,
	"plain_text": "Loki-Bot: Come out, come out, wherever you are!\r\nBy Published by R3MRUM View all posts by R3MRUM\r\nPublished: 2017-05-07 · Archived: 2026-04-05 19:07:25 UTC\r\nIntro\r\nI’m going to make my first post an easy one. I’m currently in the middle of writing up my GREM Gold paper,\r\nwhich focuses on the reverse engineering of a Loki-Bot v1.8 sample. This post is going to focus on how Loki-Bot\r\ncreates its mutex and the folders, files, and registry keys that are created as a result.\r\nPer PhishMe:\r\nLoki Bot is a commodity malware sold on underground sites which is designed to steal private data\r\nfrom infected machines, and then submit that info to a command and control host via HTTP POST.\r\nThis private data includes stored passwords, login credential information from Web browsers, and a\r\nvariety of cryptocurrency wallets.\r\nWhat is a Mutex?\r\nUnderstanding what a Mutex is can be a bit difficult to understand for those with little-to-no programming\r\nbackground. I found it best described on the SANS DFIR Blog:\r\n“Programs use mutex (“mutual exclusion”) objects as a locking mechanism to serialize access to a\r\nresource on the system.” … “Furthermore, malware might use a mutex to avoid reinfecting the host. For\r\ninstance, the specimen might attempt to open a handle to a mutex with a specific name. The specimen\r\nmight exit if the mutex exists, because the host is already infected.”\r\nCreating the Mutex\r\nSo, based on the mutex description, Loki-Bot uses a mutex to ensure that multiple versions of Loki-Bot cant be\r\nrunning at the same time. In order for this to happen, both versions of Loki-Bot need to have the same logic for\r\nnaming the mutex. What we are going to talk about next is said logic.\r\nObtaining the Machine GUID\r\nhttps://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nPage 1 of 5\n\nFirst and foremost, know that Loki-Bot employs function hashing to thwart analysis. This is what you are seeing\r\nfrom 0x404A63 to 0x404A6C. Two important arguments passed to the function labeled\r\ngetDLLFunctionFromIDXAndHash are Arg1 (DLL Index) and Arg2 (Function Hash). In this instance, these\r\nvalues are set to 9 and ‘F4B4ACDC’. Without diving too deep into this, know that the DLL Index of 9 equates to\r\nADVAPI32 and the hash ‘F4B4ACDC’ decodes to RegOpenKeyEx. At 0x404A81, we see the decoded function\r\nADVAPI32.RegOpenKeyEx being called.\r\nThis will open the registry path:\r\n“HKEY_LOCAL_MACHINE\\SORTWARE\\Microsoft\\Cryptograpy\\”\r\nBut it doesn’t actually read the value contained within the key it needs. For this to happen, ADVAPI32’s\r\nRegQueryValueEx function needs to be called.\r\nAfter successful execution, the value stored in the memory address referenced in the pData argument (0x292388)\r\nnow contains the value that was in the\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography\\MachineGuid registry key.\r\nWe can validate this by simply loading up RegEdit on the Windows host that is about to be compromised and\r\nnavigating to the referenced registry key.\r\nhttps://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nPage 2 of 5\n\nThe Machine GUID is supposed to be a value that is unique for each system. This means that your Machine GUID\r\nwill be different from the Machine GUId depicted here; thus, your mutex will be different from mine.\r\nMD5 Hash Machine GUID\r\nOnce the Machine GUID is obtained from the registry, Loki-Bot obtains the MD5 hash of the Machine GUID by\r\nmaking calls to ADVAPI’s CryptAcquireContext, CryptCreateHash, CryptHashData, and CryptGetHashParam.\r\nAfter CryptGetHashParam executes, the MD5 hash of the Machine GUID is returned.\r\nThe MD5 hash of our Machine GUID appears to be “9BD0BA527DFA20AB1F4A05B8D0D4E04B“. There are a\r\nnumber of different ways that we could validate this result but I find that it’s easiest using the linux command line.\r\nhttps://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nPage 3 of 5\n\nTrim Hash \u0026 Create Mutex\r\nFinally, Loki-Bot trims the MD5 hash of the Machine GUID to 24-characters:\r\n“9BD0BA527DFA20AB1F4A05B8“.\r\nIt then passes this trimmed value to Kernel32’s CreateMutexW function as the lpName attribute. If the function\r\nsucceeds, it means that no other version of Loki-Bot is running on the system at that time and execution continues\r\non. If it fails, it means another version of Loki-Bot is running, so Loki-Bot quietly exits.\r\nIdentify Folder/Files\r\nNow that we know the mutex, we can identify the folders and files that are related to Loki-Bot. As part of setting\r\nup persistence, Loki-Bot will create a hidden folder within your %APPDATA% path whose name set by the 8th\r\nthru 13th characters of the mutex.\r\nOnce the hidden folder “%APPDATA%\\27DFA2\\” has been created, Loki-Bot will store several different types of\r\nfiles within it; all with the same filename but with different extensions. The filename used for the different files is\r\nalso extracted from the mutex.\r\nhttps://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nPage 4 of 5\n\nWith the filename known, we can then identify the following files:\r\n%APPDATA%\\27DFA2\\20AB1F.exe – A copy of the malware that will execute every time the user\r\naccount is logged into.\r\n%APPDATA%\\27DFA2\\20AB1F.hdb – A database of hashes for data that has already been exfiltrated to\r\nthe C2 server.\r\n%APPDATA%\\27DFA2\\20AB1F.lck – A lock file created when either decrypting Windows Credentials\r\nor Keylogging to prevent resource conflicts.\r\n%APPDATA%\\27DFA2\\20AB1F.kdb – A database of keylogger data that has yet to be sent to the C2\r\nserver.\r\nIdentify Registry Key\r\nThe path for the specific persistence registry key used is encrypted within the binary using Triple DES encryption,\r\nwhich is why static analysis wont yield much. Once decrypted, my sample returned the following registry path\r\nused for persistence:\r\n“HKEY_LOCAL_MACHINE\\ Software\\Microsoft\\Windows\\CurrentVersion\\Run\\”\r\nThe registry key within this path is then derived from the Mutex exactly how our %APPDATA% subfolder was:\r\n“HKEY_LOCAL_MACHINE\\ Software\\Microsoft\\Windows\\CurrentVersion\\Run\\27DFA2“\r\nThe value assigned to this key is the executable that is stored within the %APPDATA% subfolder:\r\n“%APPDATA%\\27DFA2\\20AB1F.exe”\r\nConclusion\r\nThat pretty much covers all artifacts related to Loki-Bot that could be present on a compromised system. First step\r\nis to identify your system’s Machine GUID. Once you do that, MD5 hash and then trim that value. The result will\r\nhelp you identify all the different folders, files, and registry keys associated with the malware.\r\nSource: https://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nhttps://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://r3mrum.wordpress.com/2017/05/07/loki-bot-atrifacts/"
	],
	"report_names": [
		"loki-bot-atrifacts"
	],
	"threat_actors": [],
	"ts_created_at": 1775434404,
	"ts_updated_at": 1775791230,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c4bfac2bf9f229d7e1476c9edbc5daf0d6fee9da.pdf",
		"text": "https://archive.orkl.eu/c4bfac2bf9f229d7e1476c9edbc5daf0d6fee9da.txt",
		"img": "https://archive.orkl.eu/c4bfac2bf9f229d7e1476c9edbc5daf0d6fee9da.jpg"
	}
}