From a Teams Call to a Ransomware Threat: Matanbuchus 3.0 MaaS Levels Up

Matanbuchus is a malware loader that has been available as a Malware-as-a-Service (MaaS) since 2021. It is primarily used to download and execute secondary payloads on compromised Windows systems, making it a critical first step in various cyberattacks.

Introduction

Over the past nine months, Matanbuchus has been used in highly targeted campaigns that have potentially led to ransomware compromises. Recently, Matanbuchus 3.0 was introduced with significant updates to its arsenal. 

In one of the most recent cases (July 2025), a Morphisec customer was targeted through external Microsoft Teams calls impersonating an IT helpdesk. During this engagement, Quick Assist was activated, and employees were instructed to execute a script that deployed the Matanbuchus Loader.

This blog post presents the details of the recent loader version, focusing on changes from previously known analyses including:

• New delivery technique
• Improved communication protocol techniques
• Added in-memory stealthy capabilities
• Enhanced obfuscation, encryption, and evasion techniques
• WQL query support, CMD and Powershell reverse shell support
• EXE/DLL/MSI/Shellcode next stage execution support
• Indirect system call evasion
• Enriched data collection which includes the latest EDR security controls
• Modified persistency methodology

IOCs from recent campaigns are listed at the end of the blog.

Click here to download a full PDF of this analysis.

Technical Analysis

As described in the introduction, victims are carefully targeted and persuaded to execute a script that triggers the download of an archive. This archive contains a renamed Notepad++ updater (GUP), a slightly modified configuration XML file, and a malicious side-loaded DLL representing the Matanbuchus loader. In previous campaigns from September 2024, an MSI installer was downloaded, which ultimately led to a similar flow of Notepad++ updater sideloading execution.

Matanbuchus 3.0 Publication: Our team intercepted the HTTP variant of Matanbuchus 3.0 in active campaigns prior to its public advertisement on July 7, 2025, for $10,000, which is notably cheaper than the DNS variant priced at $15,000. This interception, before the announcement, suggests the adversaries are distributing the HTTP loader within trusted circles or leveraging it themselves. The first advertisement is shown below.

The recent PowerShell script below as has been executed by victims is a one liner command (for convenience we beautified the script). As can be seen from the script, it generates a random temp directory in the local temp folder, unpacks the zip and executes the updater which was renamed to GenericUpdater.exe (originally GUP.exe).

Gup.zip includes 3 files:

GenericUpdater.exe is a notepad++ GUP updater executable which sideloads the malicious libcurl.dll together with the gup.xml configuration file. 

Below is a normal notepad GUP updater located under “Program Files/Notepad++/updater/”:

There is a small but important difference between the legitimate and non-legitimate configuration xml file, normal url that should have pointed to notepad-plus-plus.org instead points to notepad-plus-plu[.]org

The update URL is missing “s”. The attackers utilized cybersquatting techniques.

Looking just at the malicious domain reveals additional campaigns executed by the same adversaries.

Checking in VT for additional downloads from this link, leads to a prolong campaign that was first seen in September 2024.

Payload Analysis

At first, the execution flow starts from the exported DLLInstall method, and its first step is to resolve dynamically the list of Dlls. DllInstall is the only malicious exported function added on top of the legitimate exported functions.

Note that the name is critical as it can be automatically triggered by regsvr32 with a “-i” switch (as we will show in the persistency section), similarly to how DllRegisterServer can be triggered with /s switch (a more popular abuse).

Resolved dll list:

The resolution algorithm was updated to MurmurHash3 with a changing seed (previously fnv1a was used), the function hashes every export name until it finds a match to the hash key input.

While most of the functions are resolved with this API resolution method, a more advanced and generic approach is implemented and is used at a later stage if a specific payload for execution is selected. 

As can be seen from the image, the original api_resolution is applied. Nevertheless, in most cases the generic wrapper function will return the address of the API +1, if MOV opcode (0xb8) is detected. This essentially returns the pointer to the syscall number. Next the code will execute the syscall number indirectly through a sophisticated shellcode execution which leads to the reserved “syscall” opcode.

Note: some dll addresses (e.g. ntdll, kernel32) are also resolved by utilizing MurmurHash3

Deobfuscation of names such as the domain c2 name or user agent and others is now done through Salsa20 with a 256-bit key applied on bytes in the libcurl.dll file

Post DLL resolution, the loader validates that it’s running under the Wow64 by executing IsWow64Process (most traditional OSs today are 64-bit and 32-bit applications are running within the Wow64) and this way avoids potential 32-bit sandbox OSs.

Next, as the loader heavily relies on WMI reconnaissance, it attempts to relax the security module around COM communication as will be shown later in this blog. The loader will be using CoCreateInstance with CLSID_WbemLocator and IWbemServices::ExecQuery. As it requires access to restricted resources, it ensures that the malware can handle COM calls across threads without marshaling, which is suitable for complex execution flows such as communication over pipes or WMI.

The next step validates the preferred language set by the system; it will abort if any of the following languages are identified (this was previously described by CyberArk and is now common in different other ransomware payloads as well):

Next, it generates a very important serial id that is based on the volume drive serial. This id will be used for mutex, COM persistency, and file directories, therefore it’s important to understand how the loader generates this number id.

To get the VolumeSerialNumber, it expands %HOMEDRIVE% path environment with ExpandEnvironmentStringsW, and then it executes GetVolumeInformation for the lpVolumeSerialNumber, it concatenates the 32-bit volume serial number in string format with a string representing the same number shifted right by 2 bits (dividing the number by 4).

wvsprintfW(NewSerialID, "%02x%02x", lpVolumeSerialNumber, lpVolumeSerialNumber >> 2)

Next it generates a mutex “sync<NewID>” using CreateMutexW, to avoid collisions with the persistence mechanism.

Then, it uses Salsa20, to decrypt the C2 domain “nicewk[.]com” -> the same original download domain. In older versions Matanbuchus used RC4.

Next it validates if this is a first-time execution by querying HKCU\SOFTWARE\<NewSerialID>

with RegQueryValueW, and if such exists, it extracts the guid generated identifier.

If the registry path exists (above image is just an example for a serial key), it means that its part of a scheduled execution and no need to recreate persistency, collect additional data and perform additional operations as will be described further. It will jump to the final stage of waiting for next step commands from the C2 domain (this will be described later in this post).

First time execution

The loader generates a new COM id through CoCreateGuid. This ID will be used for COM persistency and will be later written into the registry as was presented in the previous image.

Note, that even here the developers of the loader are careful enough to reset and zero out the API output immediately post string conversion.

It then generates a random empty temp file within the notepad updater execution folder by utilizing GetTempFileNameW

Data Collection

The loader extracts the USERNAME and COMPUTERNAME using GetEnvironmentVariableW (In previous versions ExpandEnvironmentStringsW was used)

It extracts the domain that belongs to the victim by abusing GetComputerNameExW:

GetComputerNameExW(ComputerNameDnsDomain, &target_domain, &Len)

The loader extracts the OS build version by taking it from the version resource from within the ntdll module (which is unusual), utilizing LoadResrouce and VerQueryValueW.

Later the loader iterates over the processes to find any of the listed security controls, this is an important update, as the following execution methods that are sent back from the C2 are likely dependent on the current security stack of the victim.

The final piece of the collected data is the elevation status of the process. The malware needs to know if it’s running with administrative privileges to determine next stage capabilities such as being able to install malicious MSI. It validates elevation status by querying the process token while utilizing GetTokenInformation API (in previous versions CheckTokenMembership was used)

Post collecting all this data, the data is encrypted with salsa20.

Dialing Back Home – C2

Post encryption of the data, the loader needs to send the data back to C2 to decide on the next stage which will be dependent on the current security stack. 

To blend with the normal traffic, the loader impersonates to a Skype desktop application (version 8.69.0.77) running on a 64-bit Windows 10 or 11 system.  

POST “Skype/8.69.0.77 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36”

The loader connects to the C2 over port 443. The sequence involves opening an internet session, connecting by using InternetConnectW , creating an HTTP request, and sending encrypted data while utilizing HttpOpenRequest and HttpSendReques. We assume that this process differs for the DNS version of the Matanbuchus loader ($15,000).

Immediately after sending the HTTP request, the loader expects a response by leveraging InternetReadFile.

Persistency

To continuously dial home, Matanbuchus needs to create persistency; this is achieved by scheduling a task.

While it sounds simple, Matanbuchus developers implemented advanced techniques to schedule a task through the usage of COM and injection of shellcode.

Creating Registry and DLL file

As this is the first execution and the registry key has not been yet created, it generates the key under HKCU\SOFTWARE\<NewSerialID> by leveraging RegCreateKeyExW and writes the COM guid as a string value into this registry path by leveraging RegSetValueExW.

Next it needs to copy the malicious loader dll into a persistent path.

The loader first, generates a serial id folder name within the APPDATA directory with CreateDirectoryW (this is the same serial id used for registry)

Then it generates a random filename within that path and copies the dll into that file name path. Note that the code supports persistency for executable format as well.

Below is an image representing the file copy (a basic implementation).

Task Creation

This is achieved by utilizing a shellcode: 

• The loader allocates a space on the heap by leveraging VirtualAlloc
• Copying into this region the previously decrypted shellcode
• Changing the protection of the region to READ_EXECUTE to avoid suspicious behavior detection
• Executing the Shellcode by calling it with the parameter of the new generated file path (AppData serial id path)
• Changing the protection of the allocated shellcode region to READWRITE 
• Resetting the memory with 0’s and freeing the region with VirtualFree

The shellcode itself is interesting; it implements a relatively basic API resolution (simple string comparisons), and a sophisticated COM execution that manipulates the ITaskService.

The task executes regsvr32 with “-e –n –i:\”user\” <dll_path>” every 5M.

Execution through regsvr32 is a known Lolbin technique, nevertheless, it’s rare to find this combination of parameters:

• -e : execute silently while suppressing errors
• -n : – allows the loader to run the dll code without modifying the registry, reducing forensic artifacts and avoiding detection by tools monitoring COM registration
• -i:”user”  – this switch triggers automatically the execution of the exported function DllInstall, this technique is not as common and less monitored than DllRegisterServer or DllUnregisterServer. Note that “user” is sent as parameter.

Similarly to what is described by Mandiant, to achieve task creation through COM, the shellcode executes CoCreateInstance with CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD} (Schedule.Service.1) and IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85} (ITaskService). It connects to the task scheduler service by using Connect api, then it generates the relevant NewTask object, settings, and task definitions.

Finally, it sets up the boundary and interval to 5M and registers the new task under the name of EventLogBackupTask.

Downloader Next Stage Capabilities

When executed through Regsvr32 and post identifying that the registry key already exists, the loader goes back to listening for commands from the original C2. The loader command and control support a variety of commands:

1. MSI executable – C2 may respond with a command to download a byte array that represents an executable from a new domain and additionally send a byte representing method of operandi.
   1. The loader will try to download that next stage using similar Skype Desktop impersonation and similar InternetReadFile technique, while this time downloading a buffer of byte arrays.
   2. The loader generates a Temp path executable file (%TEMP%)
   3. It writes the buffer to the file with CreateFileW(GENERIC_WRITE) and with WriteFile
   4. It executes the file with ShellExecuteW (open)

2. MSI executable hollowing – similarly to the previous mode of operandi, the loader downloads and impersonates Skype Desktop, only this time the malicious buffer is injected into a new legitimate misexec suspended process.
   1. The loader then verifies if that byte array represents a legitimate executable post validation of magic bytes and couple of additional offsets
   2. Next, the loader will hollow a new msiexec process that it opened with suspend and will write into the process, the malicious buffer. The loader supports both x64 and x86 and is capable of adapting the injection according to bitnes, including disabling the redirection with Wow64EnableWow64FsRedirection if the buffer represents x64 executable. 
   3. You should expect the standard APIs: CreateProcessW), NtQueryInformationThread, reading the memory (NtReadVirtualMemory), Writing to process memory (NtWriteVirtualMemory), NtProtectVirtualMemory, NtSetContextThread, and finally NtResumeThread – note that all the low level api are executed with direct system calls post retrieval of the syscall APIs using similar method as described before.

3. Similar to the previous process, an executable is downloaded and written to file on disk, nevertheless, its execution process differs:
   1. Execution of “regsvr32 /s dll_path”. The command will try to register the malicious COM dll.
   2. Execution “rundll32 dll_path,init_function”. The command will try to execute an exported function from the malicious dll.

4. MSI Product Installation – there is no difference in how the file is downloaded and written to disk, aside from writing its extension as “msi”.
   1. The downloaded msi file is installed using MsiInstallProductW

5. Direct commands – The loader allows to directly execute commands using 3 methods:
   1. CMD command execution – CMD is directly executed by leveraging CreateProcessW (child process), /Q /K parameters, it also supports writing (NtWriteFile) and executing cmd with a script, and it also supports executing over named pipe.

2. Powershell command execution – PowerShell is directly executed by leveraging CreateProcessW (child process)

3. WQL query execution –

6. Finally, the Loader have 4 built-in capabilities that can be invoked from the C2:
   1. Collect all executing processes by leveraging CreateToolhelp32Snapshot
   2. Collect all services by leveraging WQL with query “SELECT DisplayName FROM Win32_Service”

3. Collect all installed products by leveraging RegOpenKeyExW with the registry path SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%s

4. Collect all updates / hotfixes, again by leveraging WQL with a query “SELECT HotFixID FROM Win32_QuickFixEngineering”

5. Collecting Installed Applications 

Summary

The Matanbuchus 3.0 Malware-as-a-Service has evolved into a sophisticated threat. This updated version introduces advanced techniques such as improved communication protocols, in-memory stealth, enhanced obfuscation, and support for WQL queries, CMD, and PowerShell reverse shells. It collects detailed system data, including EDR security controls, to tailor subsequent attacks, which may culminate in ransomware deployment. The loader’s ability to execute regsvr32, rundll32, msiexec, or process hollowing commands underscores its versatility, making it a significant risk to compromised systems.

To share this research with a friend or colleague, download the full PDF report here.

How Morphisec Can Help

Morphisec delivers proactive protection where traditional tools fall short. Powered by Automated Moving Target Defense (AMTD), the Morphisec Anti-Ransomware Assurance Suite blocks ransomware and advanced threats like Matanbuchus malware before they can gain a foothold. Its multi-layered prevention approach stops infiltration attempts at the earliest stage and prevents impact by shielding systems, files, and critical assets in real time.

Unlike reactive, detection-based solutions that Matanbuchus malware can easily bypass, Morphisec prevents attacks from executing altogether. Its AMTD engine works hand in hand with adaptive exposure management to minimize the attack surface and close security gaps that attackers can target.

See it in action – schedule a demo today and learn how Morphisec stops Matanbuchus malware and threats like it.

IOCs

References 

• https://www.cyberark.com/resources/threat-research-blog/inside-matanbuchus-a-quirky-loader
• https://www.0ffset.net/reverse-engineering/matanbuchus-loader-analysis/ 
• https://www.esentire.com/security-advisories/matanbuchus-malware 

About the author

Michael Gorelik

Chief Technology Officer

Morphisec CTO Michael Gorelik leads the malware research operation and sets technology strategy. He has extensive experience in the software industry and leading diverse cybersecurity software development projects. Prior to Morphisec, Michael was VP of R&D at MotionLogic GmbH, and previously served in senior leadership positions at Deutsche Telekom Labs. Michael has extensive experience as a red teamer, reverse engineer, and contributor to the MITRE CVE database. He has worked extensively with the FBI and US Department of Homeland Security on countering global cybercrime. Michael is a noted speaker, having presented at multiple industry conferences, such as SANS, BSides, and RSA. Michael holds Bsc and Msc degrees from the Computer Science department at Ben-Gurion University, focusing on synchronization in different OS architectures. He also jointly holds seven patents in the IT space.