{
	"id": "5e7863ba-0a01-40f7-baa9-881ef20664ba",
	"created_at": "2026-04-06T00:08:17.593432Z",
	"updated_at": "2026-04-10T03:36:13.639041Z",
	"deleted_at": null,
	"sha1_hash": "09fe5055a1fe9fd9b91df38ee0d2fc78d6a05145",
	"title": "MATANBUCHUS: Another Loader-as-a-Service | 0ffset Training Solutions",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1971123,
	"plain_text": "MATANBUCHUS: Another Loader-as-a-Service | 0ffset Training\r\nSolutions\r\nBy Chuong Dong\r\nPublished: 2022-02-15 · Archived: 2026-04-05 21:20:33 UTC\r\nMATANBUCHUS is a commercialized loader that is used to download and launch malware on victim machines\r\nsuch as QAKBOT and COBALT STRIKE beacons. It has been observed that the loader spreads through social\r\nengineering in the form of malicious Excel documents.\r\nThroughout different versions of the malware, the author has changed the API and string obfuscation methods, but\r\nthe functionality of the loader has remained the same. In this post, we will focus on analyzing the latest loader\r\nDLL instead of the whole infection chain.\r\nTo follow along, you can grab the sample on MalwareBazaar.\r\nSHA256: E58B9BBB7BCDF3E901453B7B9C9E514FED1E53565E3280353DCCC77CDE26A98E\r\nStep 1: API Obfuscation\r\nIn the latest version of MATANBUCHUS, the malware dynamically resolves its API to avoid exposing its\r\nfunctionality through its import table. The function to import APIs takes in a hash value and the DLL name of the\r\ntarget API.\r\nAs observed, the API address returned from the function is stored into a global variable. Since resolving these\r\naddresses requires MATANBUCHUS to walk through the loaded DLL list in the PEB to locate the target DLL and\r\nthrough its import table to find the address, storing the result in a global variable allows the malware to reuse it\r\nwithout wasting computing power to resolve the address again.\r\nA quick and easy way to identify the API’s name hashing algorithm is by using Mandiant’s capa explorer or\r\nOALabs’s HashDB IDA plugins. As shown in the screenshot below, we can use HashDB’s Hunt Algorithm\r\nfeature to find that the hash 0xE463DA3C belongs to an API name hashed by the FNV-1a algorithm. By agreeing\r\nto set HashDB’s default algorithm to FNV-1a, we can use the plugin to manually resolve each API as we\r\nencounter them.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 1 of 16\n\nIn the function to resolve API, MATANBUCHUS accesses the Process Environment Block (PEB) through the\r\nThread Environment Block (TEB) and retrieves its InMemoryOrderModuleList field. This field contains the\r\nhead of a doubly-linked list that contains the loaded modules of the malware’s process, and MATANBUCHUS\r\niterates through this list to find the base of the target DLL.\r\nThe function to get the target API address retrieves the DLL’s export table directory, iterates through the list of\r\nexported APIs, checks their hash against the target hash, and returns the API address upon finding a match.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 2 of 16\n\nSince HashDB was down when I was performing the analysis, I wrote a small IDAPython script to find all\r\nfunctions to automatically resolve all imported APIs in the IDB. For those who are interested in doing this\r\nprogrammatically, feel free to check it out!\r\nStep 2: String Obfuscation\r\nThe next obfuscation that MATANBUCHUS uses is string encryption. Every encrypted string in the malware is\r\ndecrypted through two separate functions.\r\nThe first one simply populates the encoded data in a stack string and copies that data into a global character buffer.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 3 of 16\n\nThe address of this buffer is then returned to be decrypted before the malware can use the unobfuscated string.\r\nThe use of stack strings in this part is a bit redundant since the global buffer can be populated directly in a similar\r\nmanner.\r\nThe decoding function takes the address of the global buffer in as a parameter. To decode each string, it calls a\r\nsubroutine that takes in the encoded buffer, its length, and a DWORD64 number.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 4 of 16\n\nThe DWORD64 number is used as the XOR value to decode the string. For each byte in the string, the malware\r\nXORs it with the least-significant byte in the XOR key before rotating it to the right by 1 byte\r\nA quick example is if the encoded buffer contain 0xAABBCC and the XOR key is the same as above, the malware\r\nwill decode it by XOR-ing 0xCC with 0x1B, 0xBB with 0x31, and 0xAA with 0xCB.\r\nStep 3: Entry Points\r\nThe DLL comes with 4 different export functions. Beside looking at their names, a quick analysis of their code\r\ncan tell us which ones are used as the DLL entry points.\r\nThe DllEntryPoint function simply leads to the DllMain entrypoint, which does not contain anything important.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 5 of 16\n\nThe DllUnregisterServer function resolves the API MessageBoxA, decrypts the strings “Dll Uinstall” and\r\n“UnregisterServer”, and uses them as parameters for calling MessageBoxA.\r\nThe remaining two functions, DllInstall and DllRegisterServer, are pretty much the same since they execute the\r\nsame functionalities. However, their anti-sandbox and RunOnce mutex checks are a bit different from each other.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 6 of 16\n\nIn DllRegisterServer, the malware first calls GetTickCount64 to retrieve the first timestamp. Next, it executes\r\nSleep to suspend itself for 6 seconds and Beep to generate some tone on the system’s speaker for 3 seconds, and\r\nthis is repeated in a loop for 10 times. Finally, the malware calls GetTickCount64 to retrieve the final timestamp\r\nand checks to see if at least 55 seconds have passed.\r\nThis is a simple check since a lot of sandboxes hook and bypass the Sleep and Beep APIs to prevent malware\r\nfrom idling over their execution time. If these APIs are bypassed and the time difference between tick counts is\r\nless than the expected value, the malware assumes that it is running in a sandbox and exits immediately.\r\nTo check for multiple instances of the malware executing, MATANBUCHUS decrypts the string\r\n“%COMPUTERNAME%” and calls ExpandEnvironmentStringsA to retrieve the victim’s computer name. It\r\ncalls CreateMutexA using that name and exits if there is another instance running with the same mutex.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 7 of 16\n\nUnlike DllRegisterServer, the DllInstall function does not have a RunOnce mutex check. It instead has a check\r\nto see if the browser Opera is installed on the victim’s machine. It does this by decrypting the string\r\n“%PROGRAMFILES%\\Opera\\Opera.exe”, calls ExpandEnvironmentStringsA to expand it to the full path to\r\nthe Opera executable, and calls PathFileExistsA to check if it exists.\r\nBoth functions share an anti-sandbox check by checking for the number of processes running on the system. The\r\nmalware retrieves the total number of processes by calling K32EnumProcesses and checks if it is less than 50. If\r\nit is, then MATANBUCHUS exits immediately.\r\nStep 4: Loading Libraries Dynamically\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 8 of 16\n\nThe way MATANBUCHUS dynamically resolves API requires the imported DLLs to be already loaded in\r\nmemory. Since only DLLs specified in the malware’s PE are loaded in memory upon execution, it must manually\r\nload external libraries that it needs using GetModuleHandleA and LoadLibraryA calls.\r\nFor each of the libraries, MATANBUCHUS decrypts its name and calls GetModuleHandleA to check if it’s\r\nalready loaded, and if not, the malware calls LoadLibraryA to load it into memory.\r\nBelow is the list of all loaded libraries.\r\nShell32.dll\r\nIPHLPAPI.DLL\r\nWS2_32.dll\r\nWininet.dll\r\nShlwapi.dll\r\nUSER32.dll\r\nThe malware also calls GetModuleHandleA to check if rundll32.exe and regsvr32.exe are loaded in memory.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 9 of 16\n\nStep 5: Dropping Self \u0026 Launching Through Regsvr32\r\nOne of the main functionalities of MATANBUCHUS is downloading a DLL from a remote server and launching it\r\nthrough Regsvr32.exe.\r\nFirst, the malware checks if the target folder to drop the next stage already exists. It decrypts the environment\r\nstrings “%ProgramData%\\” and “%PROCESSOR_LEVEL%\\” and retrieves their values by calling\r\nExpandEnvironmentStringsA. The malware then appends the processor level to the ProgramData path to\r\nconstruct the drop folder path and calls PathIsDirectoryA to check if the folder exists.\r\nIf it doesn’t exist yet, the malware creates the folder by calling CreateDirectoryA and downloads the remote file\r\nin there.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 10 of 16\n\nThe malware retrieves the revision number of the processor by calling ExpandEnvironmentStringsA on the\r\nenvironment string “%PROCESSOR_REVISION%” and uses it as the filename of the next stage.\r\nNext, it appends the filename and the extension .ocx to the ProgramData folder path, and calls a function to\r\ndownload the DLL to register from the following URL.\r\nhxxps://manageintel[.]com/RKyiihqXQiyE/xukYadevoVow/QXms.xml\r\nThe function to download the next stage first calls InternetCheckConnectionA to check if a connection to the\r\nURL can be established. Then it calls InternetOpenA to initialize the use of WinINet functions, CreateFileA to\r\ncreate the target file at the specified path, and InternetOpenUrlA to open a connection to the URL.\r\nTo read data from the remote file, MATANBUCHUS calls VirtualAlloc to allocate a memory buffer with size\r\n0x100000 bytes, InternetReadFile to read remote data into this buffer, and WriteFile to write the file content\r\ninto the local file.\r\nFinally, the malware crafted the following string before executing it with CreateProcessA.\r\n\"C:\\Windows\\system32\\schtasks.exe\" /Create /SC MINUTE /MO 3 /TN %PROCESSOR_REVISION% /TR \"%windir%\\system32\\reg\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 11 of 16\n\nThis command schedules a task to execute every 3 minutes with the task name of the processor’s revision number,\r\nand this task will execute the regsvr32.exe command to register the downloaded DLL as a command component\r\nin the registry.\r\nWhen registering a DLL, regsvr32.exe internally calls the DLL’s DllRegisterServer export function. Therefore, if\r\nthe malicious DLL exports the DllRegisterServer export, it is periodically launched every 3 minutes.\r\nBecause the remote server is down by the time I’m writing this post, I’m unable to retrieve this specific DLL for\r\nfurther analysis. However, thanks to JoeSandbox, I found out that the downloaded file is the exact same file that\r\nwe are analyzing.\r\nFrom this, we can conclude that this scheduled task to execute the regsvr32.exe command is a method of\r\npersistence for the malware to periodically launch itself.\r\nStep 5: Launching Remote File From Memory\r\nFinally, MATANBUCHUS downloads another file from the remote server using the same method at the URL\r\nbelow. This time, the downloaded content is stored in a memory buffer instead of being written to a file.\r\nhxxps://manageintel[.]com/RKyiihqXQiyE/xukYadevoVow/BhJM.xml\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 12 of 16\n\nIf the downloaded file contains the proper MZ header, the malware loads the PE in memory, relocates it properly\r\nand launches its entry point.\r\nWhen loading the PE into memory, the malware retrieves its number of sections and image size through its\r\noptional header. It calls VirtualAlloc to allocate a virtual memory buffer with the image size to write the PE in.\r\nFirst, MATANBUCHUS writes the image’s DOS header and NT headers in. Next, it iterates through the PE’s\r\nsection headers to write each section in the memory buffer.\r\nTo relocate the PE, the malware checks if its requested image base from the optional header is the same as the\r\naddress of the allocated buffer. If it is not and the PE contains a relocation table, MATANBUCHUS relocates it by\r\niterating through each block in the table and relocates fields in the PE according to the difference between the\r\nbases.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 13 of 16\n\nNext, the malware manually resolves the addresses of imported APIs in the PE’s import table. It first checks if the\r\nimport table exists in the PE’s data directory and iterates through each import descriptor in the table if it exists.\r\nFor the library name in the import descriptor, MATANBUCHUS calls GetModuleHandleA or LoadLibraryA to\r\nretrieve its handle depending if the library is loaded in memory or not.\r\nNext, the malware retrieves the virtual address of the PE’s Import Lookup Table through the import descriptor. It\r\niterates through this table, extracts each API’s name or ordinal number, calls GetProcAddress to retrieve its\r\naddress from the loaded library, and writes the result back into the PE’s table.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 14 of 16\n\nOnce this is done, MATANBUCHUS executes the PE from memory by retrieving its entry point address from the\r\noptional header and executes a call instruction to launch it.\r\nBeside launching the PE from its entry point, the malware resolves the string “DllRegisterServer” in memory,\r\ncalls a function to find the export DllRegisterServer’s address in the PE’s export table, and launches the PE from\r\nit.\r\nThe function to find an export address iterates through each export in the PE’s export directory, extracts its name,\r\nand returns its address if the name matches with the target export being looked up.\r\nAnd with that, we have fully analyzed MATANBUCHUS’s functionalities as a loader! If you have any questions\r\nregarding the analysis, feel free to reach out to me via Twitter.\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 15 of 16\n\nSource: https://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nhttps://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/"
	],
	"report_names": [
		"matanbuchus-loader-analysis"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d9b39228-0d9d-4c1e-8e39-2de986120060",
			"created_at": "2023-01-06T13:46:39.293127Z",
			"updated_at": "2026-04-10T02:00:03.277123Z",
			"deleted_at": null,
			"main_name": "BelialDemon",
			"aliases": [
				"Matanbuchus"
			],
			"source_name": "MISPGALAXY:BelialDemon",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434097,
	"ts_updated_at": 1775792173,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/09fe5055a1fe9fd9b91df38ee0d2fc78d6a05145.pdf",
		"text": "https://archive.orkl.eu/09fe5055a1fe9fd9b91df38ee0d2fc78d6a05145.txt",
		"img": "https://archive.orkl.eu/09fe5055a1fe9fd9b91df38ee0d2fc78d6a05145.jpg"
	}
}