FakeMBAM: Backdoor delivered through software updates

Many applications can be updated automatically and without any user interaction. This is commonly considered a good practice from the security point of view, since it allows for quick distribution of patches for critical vulnerabilities. However, automatic updates also carry an additional risk because they allow the software developers to push arbitrary code to users’ machines. Unfortunately, users often have no choice but to trust the developers that they will only use the update channel for its intended purpose and that they will protect it from malicious third parties.

In this blog post, we’ll show that this trust might sometimes be misplaced. Specifically, we’ll show how one torrent client and three adblockers surreptitiously installed the FakeMBAM backdoor through automatic updates. We reverse engineered this backdoor and describe its inner workings in the second part of this post.

An unexpected infection vector

We recently reported on a fake Malwarebytes installer that we detected on over 100,000 machines protected by Avast. This installer attempted to pass itself off as the legitimate Malwarebytes installer, mimicking it to a great extent – it was distributed under the same filename, it used the same icon and it created a Malwarebytes installation directory containing legitimate PE files digitally signed by Malwarebytes. However, that was all just a pretense, because the installer did not actually install Malwarebytes. In fact, the installer’s main purpose was to open a backdoor to attacker-controlled servers in order to give its operators the ability to push additional malicious payloads to the infected machines. 

A map illustrating the distribution of Avast users protected from the FakeMBAM backdoor. The backdoor is most active in Russia, Ukraine and Kazakhstan.

In our first report, we stated that we did not know how this fake installer was being distributed. Since then, we spent some time reverse engineering the malware and investigating its infection vector. We found that the fake installer was pushed to the victims’ machines through automatic updates of one torrent client (download[.]studio) and three adblockers (netshieldkit[.]com, myadblock[.]com and netadblock[.]com). Listed on the websites of these applications are three different companies that are supposedly behind these applications, “Sigma Software”, “GRAND MEDIA, TOV” and “Birmon Software”. However, based on high code similarities and shared infrastructure (and on the fact that they all distributed the very same piece of malware), we consider it very likely that there is one actor behind all four applications. 

Download Studio

To investigate the infection vector used to distribute the fake installer, we first turned to the metadata that was submitted to us when we detected the installer in the wild. This provided us with two important clues: The installers were supposed to be executed with the command line arguments /SP- /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NOCANCEL /NOICONS, by a process named dstudio-gui.exe. The first clue suggested that the installer was not supposed to be spread through social engineering, because the above arguments instruct Inno Setup to install software silently in the background. The second clue hinted at the possible suspect: Download Studio.

A screenshot of the Download Studio product page.

Download Studio is a free torrent client popular in Russia and Ukraine. It features an embedded library of torrent files, offering a wide selection of movies, software, video games, music and more. As is usually the case with torrent downloaders, there is a lot of copyrighted material that can be easily downloaded for free using this software, which seems to be the main reason why it is so widespread. Download Studio is detected by some anti-malware software as a potentially unwanted program (PUP) or as riskware, because it encourages illegal behavior and puts its users at risk through downloading torrents of unknown origin.

A screenshot of Download Studio’s movie library.

To clear up some potential confusion, let us state that there is also another piece of software named Download Studio: a download manager developed by Conceiva. Apart from the name, this software has nothing in common with the torrent client described in this blog post and there is therefore no reason to doubt its legitimacy. In the rest of this blog post, the name Download Studio will denote the torrent client described in the previous paragraph.

Since Download Studio can be used to download various software, it would make sense to think that the fake Malwarebytes installer was distributed through it as a regular torrent file (after all there were 609 results when we searched for “Malwarebytes” inside Download Studio). However, that would not explain the command line arguments that we observed in the wild. They simply indicated that running the installer was not a user-initiated action and that the user might not have been aware of the installer at all. Furthermore, the number of users that we protected from the fake installer matched our estimates of the number of Avast users running Download Studio, which made it look like Download Studio itself was somehow responsible. Therefore, we decided to reverse engineer it to see if it contained hidden malicious code. 

We immediately found some evident code similarities with the FakeMBAM backdoor. Both Download Studio and the backdoor were developed using the Qt framework and they both used the very same string obfuscation methods. One of the obfuscation methods was particularly interesting, because it was not very effective at, well, obfuscation. It consisted of XORing the obfuscated string twice with the same mask, so the plaintext was clearly visible in the disassembly.

Other code similarities were found in a piece of code that computed HMAC of custom HTTP headers or in a piece of code that created scheduled tasks using the ITaskService COM interface. We also found that Download Studio contained a string with the exact command line arguments that we mentioned earlier. These arguments were used to execute application updates silently in the background. By reverse engineering Download Studio, we also found that the application updates are supposed to be executed from a temporary directory the name of which can be described by the regular expression ds-\d{7}\.tmp, which further matched our metadata from detections of the fake installer.

Disassembled snippet of Download Studio, showing the code responsible for execution of automatic updates.

At this point, it seemed almost certain that the backdoor was distributed through the automatic updates of Download Studio. However, we wanted to be absolutely sure that this was the case, so we monitored the updates and logged the filename and hash of each observed update. This gave us the following list:


Just based on the filenames alone, the last two entries immediately stand out. Indeed, while all the previous entries correspond to legitimate updates of Download Studio, the last two hashes are the fake Malwarebytes installers that we have been investigating. They were executed in the same way as all the other automatic updates, silently in the background and without the users’ awareness. 

This means that someone tried to infect all users of Download Studio with the FakeMBAM backdoor. While we do not know precisely what happened behind the scenes, there are three possible scenarios that come to mind. The first one would be that the developers of Download Studio wished to “monetize” their large install base in a very unethical way. Code reuse between Download Studio and the FakeMBAM backdoor would suggest that this could be the case. Another explanation is that the backdoor was spread by a group of rogue employees who acted without the knowledge of the rest of the company. Finally, it is also possible that some unknown attacker hacked Download Studio and carried out a successful supply chain attack.

We were looking for some answers and so we reached out to the developers of Download Studio, asking about the backdoor. They claimed that they detected a security incident on their continuous integration server in August 2020 and that they have since thoroughly investigated this incident and put additional security measures in place. They did not respond to our additional inquiries about how many of their users could be impacted by this incident and if they notified the impacted users.


Download Studio was not the only software that distributed the FakeMBAM backdoor. We also found three adblockers whose automatic updates were abused in the same fashion. These adblockers are NetShield Kit (netshieldkit[.]com), My AdBlock (myadblock[.]com) and Net AdBlock (netadblock[.]com).

A screenshot of the NetShield Kit product page.

While these adblockers are being advertised as three different products, they are almost the same under the hood. The ad blocking itself is implemented in Golang, using the open-source adblock package. The websites offering downloads of the individual adblockers also look very similar and are even hosted from the same IP address (62.112.11[.]43). It seems like two more adblockers might be launched in the future, since adblockpro[.]net and adblockfree[.]com also resolve to this IP address. 

Domain names corresponding to all three adblockers resolve to the same IP address.

We also identified code similarities between the adblockers and Download Studio, which suggests that they were developed by the same group. What’s more, some installers of Download Studio also present an opt-out offer to install My AdBlock.

An installer for Download Studio that offers the installation of My AdBlock.

Same as with Download Studio, we do not know if the primary purpose of these adblockers is to spread malware. But if this is a supply chain attack or an action of rogue employees, it would be hard to explain why the domain bitminer[.]tech (which hosted XMRig-based coinminers not unlike the ones distributed by the FakeMBAM backdoor) used to resolve to the same IP address as the websites of these adblockers. Also very suspicious-looking is the FAQ section on the NetShield Kit website.

A screenshot of the FAQ section from the NetShield Kit website.

There might be another “catch” that is not mentioned in this answer.

Analysis of the FakeMBAM backdoor

Now that we’ve shown how the fake Malwarebytes installer is delivered to its victims, let’s examine what it actually does. When the malicious installer is executed, it creates a fake Malwarebytes installation directory where it hides the FakeMBAM backdoor. This directory is made to look identical to the legitimate Malwarebytes installation directory, the only difference being one added malicious DLL file, one maliciously modified DLL file and a new data.pak file containing random-looking data.

Comparison of a legitimate Malwarebytes installation directory with the fake installation directory created by the malware. 

Even though the fake installer is supposed to be executed silently in the background, the malware authors still tried to make it appear as if it is the legitimate Malwarebytes installer, in an attempt to fool anyone who would actually analyze it. However, there are still some noticeable differences. First of all, unlike the legitimate installer, the fake installer is not digitally signed. The fake installer was also created using Inno Setup, which makes it look different than the legitimate Malwarebytes installer. The default installation directory varies slightly as well. While the fake installer installs itself into %ProgramFiles%\Malwarebytes (or %ProgramFiles(x86)%\Malwarebytes on 64-bit Windows), the legitimate Malwarebytes usually gets installed to %ProgramFiles%\Malwarebytes\Anti-Malware\. This distinction was probably introduced deliberately by the malware authors, who wanted to avoid a clash between the malware and the legitimate Malwarebytes.

Packed inside the fake installer are all the usual PE files that one would expect in a Malwarebytes installation directory. All of those except for the two malicious DLLs are validly signed by either Malwarebytes or Microsoft. The first of the two malicious DLL files is called Qt5WinExtras.dll. As the name suggests, it is part of the Qt framework and a DLL with the same name can also be found in a legitimate Malwarebytes installation. This malicious DLL file looks almost the same as the legitimate Qt5WinExtras.dll, the only important difference is in the function setCurrentProcessExplicitAppUserModelID, where the malware authors inserted a call to a function exported from Qt5Help.dll

Bindiff between the legitimate and backdoored Qt5WinExtras.dll. 1793 out of 1795 functions are perfect matches.

Qt5Help.dll is the other malicious DLL file. Unlike Qt5WinExtras.dll, a file named Qt5Help.dll cannot be found in a legitimate Malwarebytes installation directory. This DLL file was added by the cybercriminals and it implements the actual backdoor functionality. Note that the main Malwarebytes executable, mbam.exe, imports Qt5WinExtras.dll and calls the exported function setCurrentProcessExplicitAppUserModelID. As described above, Qt5WinExtras.dll in turn imports Qt5Help.dll and calls a function that exposes the malicious functionality. This means that running the legitimate mbam.exe executable while having these two DLL files planted in the same directory will inevitably pass the control flow to the FakeMBAM backdoor that’s hidden in Qt5Help.dll.

The installation process of Inno Setup executables is guided by their setup scripts. These scripts are compiled inside the installers, but they can be extracted and decompiled. The script embedded in the fake Malwarebytes installer is relatively simple. First, it copies all the files that are packed inside the installer into the installation directory. Then, it creates some registry values, among others HKLM\SOFTWARE\Malwarebytes\LicenseKey, where a random-looking hexadecimal string gets stored. As we’ll see later, this string is read by Qt5Help.dll and it contains the malware’s initial configuration, in an encrypted form. Next, mbam.exe is added to the Windows Firewall’s exclusions. Finally, mbam.exe gets executed with the command line argument /install. As was already mentioned, this is the legitimate mbam.exe, digitally signed by Malwarebytes. Due to the way the malicious DLL files have been planted in the same directory, it will inevitably load and execute the main malicious payload, which is hidden inside Qt5Help.dll.

A snippet taken from the fake installer’s Inno setup script.


Qt5Help.dll is responsible for the backdoor’s persistence, configuration updates and delivery of additional payloads. It was developed using the Qt framework and it uses functionality provided by the framework for cryptographic operations, as well as for interaction with the underlying operating system. Only basic obfuscation is used – most noticeable are encrypted strings, which get constructed on the stack and are decrypted at run-time using elementary obfuscation methods, such as a simple XOR cipher with a one-byte key. 

An obfuscated string that is constructed on the stack, encrypted with a simple XOR cipher.

Specific actions performed by Qt5Help.dll are determined by the command line arguments. If the current process was spawned with the /install argument, Qt5Help.dll will create a new service designed to automatically start mbam.exe during system startup. If /remove, /start or /stop were passed on the command line, this service will get deleted, started or stopped, respectively. 

If there are no command line arguments, Qt5Help.dll assumes that it is already being executed in a service process and calls StartServiceCtrlDispatcher. As mentioned above, the Inno Setup script initially executes mbam.exe with the /install command line argument. This installs the service and immediately starts it. The service name of the newly created malicious service is MBAMSvc and the display name is Malwarebytes Service. The legitimate Malwarebytes service is named MBAMService, so this can be seen as yet another attempt to mimic Malwarebytes without actually choosing a conflicting service name.

Decompiled snippet of Qt5Help.dll showing the creation of the malicious service.

When the malware is executed as a service, it enters an infinite loop where it polls the C&C server for configuration updates. The malware’s configuration is saved as an encrypted hexadecimal string in the registry, under HKLM\SOFTWARE\Malwarebytes\LicenseKey (or HKLM\SOFTWARE\Wow6432Node\Malwarebytes\LicenseKey on 64-bit Windows). The configuration can be decrypted using AES in CTR mode with the key cefd8928fd7411b4c9cef7ec35cc827c and the IV 260743d9b464883ecc7f144bfa06e36d (as can be seen in this CyberChef recipe). The key and IV are generated as MD5 digests of the hard-coded strings MGZ_th#l}{JmC^!:4525719127089151290 and ?0@1!elVN]9L.)2. respectively, which means that they are the same for all victims.

Registry values created by the backdoor in HKLM\SOFTWARE\Malwarebytes.

Configuration updates are performed via HTTP GET requests using custom HTTP headers. The malware makes requests containing the X-Build-ID and X-Build-Sign headers, where X-Build-ID is set to the malware’s build number concatenated with the MD5 hexadecimal digest of the encrypted payload configuration (will be described later) and X-Build-Sign is set to the HMAC-SHA256 authentication code of the X-Build-ID header computed using the hard-coded key JXaZy7brRJ. The C&C server checks the HMAC’s validity and returns the 404 (Not Found) response code if it is invalid. Otherwise, if the signature is valid, the C&C server responds with the 204 (No Content) status code. However, this doesn’t mean that the C&C server does not send back any data. It simply means that the response body is empty. The actual response from the C&C server is encoded in the custom X-Payload HTTP response header. When the malware sees such a header, it updates its configuration with the header’s decrypted content.

Fiddler capture of C&C communication. Note the X-Payload response header, which contains the updated configuration.

The decrypted configuration is a JSON string that contains up to five keys in the top-level object. The following keys are supported by the malware:

apiAn array of C&C URLs that are regularly being queried for configuration updates.
paramsThe replacement for placeholders in the distributed malicious payloads (will be explained later). This configuration parameter is currently only used so that the malware can quickly rotate mining pool IP addresses without having to update the entire malicious payload.
refreshThe number of seconds the backdoor waits before querying the C&C server again. The default value is 7200 (two hours).
hashThis seems to be a hash of some part of the configuration. Unfortunately, we were not able to determine how this hash is computed, since it is generated by the C&C server and the malware itself does not verify it at all. The malware only compares this value with the hash of the previous configuration to see if there were any changes. Based on the observed length of the hash, this seems to be an MD5 digest. 
extraExtra malicious payloads to be downloaded. This is an array of three values: url, hash and arguments. Upon receiving a configuration containing this key, the malware downloads a file from url, checks that its MD5 digest matches hash and if it does, executes it while passing it arguments on the command line.
An example configuration distributed by the C&C server.

Persistent payloads

The FakeMBAM backdoor might also drop some persistent payloads, which it will reinstall in regular intervals in case they get removed or terminated. So far, the only persistent payloads we have seen were cryptocurrency miners, but the malware is able to handle multiple persistent payloads at the same time, so other malicious payloads may be added in the future.

Persistent payloads are stored encrypted in a file named data.pak, located in the fake Malwarebytes installation directory. Decryption can be performed using AES in CTR mode using the same key and IV as for decrypting the configuration. When decrypted, the data.pak file should start with the magic bytes 71 72 65 73 (qres), which identifies the file format: Qt binary resource. This is basically a custom archive format that can be unpacked using API functions provided by the Qt framework.

The data.pak archive always contains a file named config.json, which holds the payload configuration. In the example config.json shown below, there is only one payload, named app5. To install this payload, the malware first extracts all the files from the app5 directory in the data.pak archive into payload['path'] (C:\ProgramData\VMware\VMware Tools\ in this case). Then, it performs several setup actions based on the values of payload['type'] and payload['pre'], which will be explained later. When all the setup actions are finished, the backdoor executes the file specified as payload['file'][0] while passing it payload['file'][1] on the command line. For the example configuration shown below, the command line of "C:\ProgramData\VMware\VMware Tools\vm3dservice.exe" /detach would get executed.

An example payload configuration that describes a coinminer payload.

The third element of payload['file'] specifies the method used to execute the payload. The malware can either run the payload directly by creating a new process, or it can create a one-time scheduled task that will execute the payload in one minute and automatically delete the task afterward. The payload can also be executed either in the security context of the malicious service or with lower privileges. To lower the privileges, the malware attempts to steal the access token of an active user and to execute the payload with the stolen token. There are several techniques used to steal the token, for example, using the API functions WTSGetActiveConsoleSessionId/WTSEnumerateSessions together with WTSQueryUserToken or using OpenProcessToken on the explorer.exe process. All in all, there are six methods in which the persistent payload can be executed:

1Execute the payload in a scheduled task using a stolen token and if that fails, fall back to direct execution (also using a stolen token). 
2Execute the payload in a scheduled task in the current security context and if that fails, fall back to direct execution (also in the current security context).
3Execute the payload in a scheduled task using a stolen token.
4Execute the payload directly using a stolen token.
5Execute the payload in a scheduled task in the current security context.
6Execute the payload directly in the current security context.

The payload['type'] configuration parameter allows the malware to perform some custom actions based on the type of the payload. Currently, there is only one custom action specified and it is performed only if payload['type'] equals 1. If that is the case, the malware searches for a file named config.json inside the current persistent payload and replaces all occurrences of the placeholder {params} with the value of params from the volatile configuration. This is used to specify the mining pool URL in the XMRig config file.

XMRig’s config.json file used by the malicious miner. Note the {params} placeholder, which will get substituted by the malware with a real mining pool URL.

The final configuration parameter left to describe is payload['pre']. This is an array describing various setup actions that the malware is going to perform before actually running the persistent payload. Each action is fully specified by its integer type and a string that should be interpreted in the context of the specific type. Currently, the malware supports three setup action types:

1Terminate processes with the given name. Based on the configuration observed in the wild, this is used to terminate previous instances of the persistent payload, not to terminate well-known malware analysis tools.
2Delete a scheduled task with the given name using the ITaskService COM interface.
3Create a Windows Defender exclusion for the given filesystem path. The exclusion is added using the IGroupPolicyObject COM interface, by creating a new Group Policy Object that modifies HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths.


This blog post reports how cybercriminals abused the update process of Download Studio and three adblockers in an attempt to deliver the FakeMBAM backdoor to hundreds of thousands of victims. It also presents technical analysis of this backdoor, with special attention given to documenting how the malware stores and protects its configuration and what the individual configuration parameters represent. This information should help incident responders deal with this piece of malware. The C&C communication protocol was also documented, which should help create network-based detection rules, as well as implement trackers that would monitor the C&C activity.

Indicators of Compromise

The full list of IoCs is available at https://github.com/avast/ioc/tree/master/FakeMBAM.




Download URLs


Miner payloads




Private mining pool IP addresses

IP address