We observed the following timeline of events:

Trend Vision One’s Execution Profile shows the following infection activity:

The first stage of the attack

Analysis of the first stage loader

We were able to obtain a malicious executable file, which turned out to be the loader responsible for the first stage of infection (we will discuss possible initial access methods in a later section). One of the loaders contained the word that the user searched for via search engine:

• C:Users{username}Dwnloadsmicrosoft_barcode_control_16.0_download.exe
  (3364dd410527f6fc2c2615aa906454116462bf96)

Upon analyzing the file microsoft_barcode_control_16.0_download.exe (SHA256: 3364dd410527f6fc2c2615aa906454116462bf96), we discovered that it was packed using Inno Setup, a free installer for Windows — a similar characteristic found in samples analyzed in a report from Sector 7.

The purpose of the loader is to create an explorer.exe process that is injected with malicious code, retrieve the payloads from the command-and-control (C&C), and proceed to the second stage.

The TMP file with the same filename is due to the Inno Setup installer that drops the necessary files. By using a third-party tool such as innounp (an Inno Setup unpacker), we are able to view the setup files and the install script.

For this sample, it simply executes the SutiLauncher.exe file (SHA256: (506accb774d2a2be4b0ee3bdd3c549f09684ab9b) instead of a DLL file, which was mentioned in the Sector 7 report. However, this exe file will load the SutiLauncher.dll file (SHA256: (e3887b1eddbdd9d4e5b042a85909b69919204570), which contains the malicious routines.

SutiLauncher.dll is a .NET Core compiled file capable of performing the following:

• Check connection by accessing hxxps://iplogger[.]com/1uPSK4
• Access hxxps://sito-company[.]com/launcher/auth?login={login}&pass={pass}, and if the site replies with “true”, execute a file named tool.exe
• Connect to hxxps://complete-s[.]monster/upd.php to download an encrypted shellcode that will be decrypted and executed in memory

The process chain recorded by Vision One shows that the malicious code was injected, after which the attack proceeded to the second stage of its routine.

It’s possible that the behavior involving the injection of the malicious code to explorer.exe is performed by the downloaded shellcode. However, as of current analysis, the URL seems to be inaccessible so we were unable to confirm this behavior via reverse engineering.

The second stage of the attack

The first payload: malicious Google Chrome extension with similarities to Genesis Market’s infostealer

The initial payload that the loader installs during the second stage of the attack is a malicious Google Chrome extension, which, once installed, continuously shares sensitive information from the browser —including user credentials — to the threat actors. This malicious extension, shortcuts that are installed, and the PowerShell script that performs the installation, are very similar to previously reported Genesis market samples.

After that, if the user runs Chrome via the shortcuts created in this part, it will start with the malicious extension.

The following series of files will be created for the extension (note that these file path configuration can be used to detect infections):

• C:Users{username}AppDataLocalDefaultapp.html
• C:Users{username}AppDataLocalDefaultconfig.js
• C:Users{username}AppDataLocalDefaultico.png
• C:Users{username}AppDataLocalDefaultmanifest.json
• C:Users{username}AppDataLocalDefaultmodulescontent-scripts-register-polyfill.4.0.0.js
• C:Users{username}AppDataLocalDefaultrules.json
• C:Users{username}AppDataLocalDefaultsrcbackground.js
• C:Users{username}AppDataLocalDefaultsrccontentmain.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsclipper.js
• C:Users{username}AppDataLocalDefaultsrcfunctionscommands.js
• C:Users{username}AppDataLocalDefaultsrcfunctionscsp.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsdomain.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsexchangeSettings.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsextensions.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsgetMachineInfo.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsinjections.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsnotifications.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsproxy.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsscreenshot.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsscreenshotRules.js
• C:Users{username}AppDataLocalDefaultsrcfunctionssettings.js
• C:Users{username}AppDataLocalDefaultsrcfunctionstabs.js
• C:Users{username}AppDataLocalDefaultsrcfunctionsutils.js
• C:Users{username}AppDataLocalDefaultsrcmailsgmail.js
• C:Users{username}AppDataLocalDesktopCleanupGoogle Chrome.lnk
• C:Users{username}AppDataRoamingMicrosoftInternet ExplorerQuick LaunchGoogle Chrome.lnk
• C:Users{username}AppDataRoamingMicrosoftInternet ExplorerQuick LaunchUser PinnedTaskBarGoogle Chrome.lnk
• C:Users{username}OneDriveDesktopGoogle Chrome.lnk

The second payload: abusing a legitimate Node.js module

As part of the second stage of the attack the loader launches the second payload. In one case we analyzed, explorer.exe, which was launched in the first stage by the loader and was injected with malicious code, executed a dropped batch file named svchost.Bat. Next, an MSI installer (Node.js) is executed. 

The next part of the infection chain involved the installation of an old but legitimate Node.js with a valid and legitimate code signing certificate. It is important to note that this does not mean that the user was affected because they were using an old Node.js module. Rather, the module was brought in and installed by the threat actor (instead of being preinstalled on the host machine).

• SHA1 Hash: 6817df1da376e8f6e68fd1ad06d78f02406b6e19
• File Version: 0.10.41
• Signer: Node.js Foundation
• Date signed: 2015-12-04 03:46:00 UTC
• Installed path: C:ProgramDataDNTExceptionnode.exe

A closer look at this payload sample reveals it to be the malware analyzed by Any.run as Lu0Bot.

After being installed, the payload was launched on Node.js, after which it received a number of OS commands (possibly human-operated )from the C&C server via a backdoor, then executed them:

• “C:Users{username}AppDataLocalTempnvnnimjsdfnichvxlmq.exe”
• “C:Users{username}AppDataLocalTempnvnnimjsdlgjnbyhdmf.dat” 3721679456
• attrib.exe +H “C:ProgramDataIntelIntel(R) Management Engine Components”
• attrib.exe +H “C:ProgramDataIntelIntel(R) Management Engine ComponentsIntel MEC 3573217561”
• attrib.exe +H “C:ProgramDataIntelIntel(R) Management Engine ComponentsIntel MEC 3806163581”
• attrib.exe +H C:ProgramDataDNTException
• attrib.exe +H C:ProgramDataDNTExceptionnode.exe
• attrib.exe +H C:ProgramDataIntel
• C:Users{username}AppDataLocalTempnvnnimjsdfnichvxlmq.exe C:Users{username}AppDataLocalTempnvnnimjsdlgjnbyhdmf.dat 3721679456 1369574819
• cacls.exe C:ProgramDataDNTException /t /e /c /g Everyone:F
• cacls.exe C:ProgramDataIntel /t /e /c /g Everyone:F
• cmd.exe /c dir C:
• icacls.exe C:ProgramDataDNTException /t /c /grant *S-1-1-0:(f)
• icacls.exe C:ProgramDataIntel /t /c /grant *S-1-1-0:(f)
• ipconfig.exe /all
• netstat.exe -ano
• node.exe node.lib 3721679456 3015897030
• reg.exe add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v “Intel Management Engine Components 1808681674” /t REG_SZ /d “wscript.exe /t:30 /nologo /e:jscript “C:ProgramDataIntelIntel(R) Management Engine ComponentsIntel MEC 3573217561” “C:ProgramDataIntelIntel(R) Management Engine Components” 2779289286″ /f
• reg.exe add HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun /v “Intel Management Engine Components 1808681674” /t REG_SZ /d “wscript.exe /t:30 /nologo /e:jscript “C:ProgramDataIntelIntel(R) Management Engine ComponentsIntel MEC 3573217561” “C:ProgramDataIntelIntel(R) Management Engine Components” 2779289286″ /f
• reg.exe query “HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders”
• reg.exe query HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun
• reg.exe query HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun
• reg.exe query HKLMSYSTEMControlSet001ControlClass{4d36e968-e325-11ce-bfc1-08002be10318}
• reg.exe query HKLMSYSTEMControlSet001ControlClass{4d36e968-e325-11ce-bfc1-08002be10318}000
• reg.exe query HKLMSYSTEMControlSet001ControlClass{4d36e968-e325-11ce-bfc1-08002be10318}001
• route.exe print
• systeminfo.exe /fo csv
• tasklist /fo csv /nh
• wmic process get processid,parentprocessid,name,executablepath /format:csv
• wmic process get processid,parentprocessid,name,executablepath,commandline /format:csv

The Vision One execution profile shows how the MSI installer starts. First, Node.js is installed, then the Lu0Bot payload is started on the module, after which the backdoor commands are executed.

Alternative secondary payloads masquerading as Service Host (svchost)

In the previous section, we mentioned that svchost.Bat file introduced an old Node.js module and the Lu0Bot malware. However, we have also observed several other types of secondary payloads launched from the loader that are also masquerading as a svchost file. These were not launched by the first payload and we were not able to detect any Node.js abuse connected to these payloads.

Currently, we have observed the following combinations:

• C:Users{username}AppDataLocalTempRTIvsEUane3TLWAsvchost.exe
• C:Users{username}AppDataLocalTempnJAnCiq3sxgojkVsvchost.dll
• C:Users{username}AppDataLocalTemp6kzC88czML4rqbVNsvchost.dll” (43f11d6ec961fc82cf53e4eca97c429285026f3e)

This suggests that the second payload is interchangeable and is obtained during the first-stage loader execution, therefore malicious activities appear depending on the timing of the infection or the infected samples.

The loaders and payloads that have Extended Validation (EV) code signing certificates

We found several samples that had EV code signing certificates during our investigation. It’s likely that the threat actor used this technique for defense evasion (making the samples seem legitimate at first).

Similar to our previous report, EV code signing was added to an executable file that was downloaded from the internet. This suggests that the malicious actors are highly motivated to avoid detection by websites, search engines, browsers, and operating systems whenever executable files are downloaded from the internet. It also has the effect of minimizing the warnings from the operating system whenever users launch the executable.

We found two EV code-signed loaders different locations that had different filenames (related to whatever the user was searching for) but identical file hash values:

• C:Users{username}Downloadsmicrosoft_barcode_control_16.0_download.exe (3364dd410527f6fc2c2615aa906454116462bf96)
• C:Users{username}Downloadsavenir next heavy font.exe (3364dd410527f6fc2c2615aa906454116462bf96)

The certificates have been revoked as of the time of writing. EV code signing certificates mandate hard token specifications for key generation, and today it is no longer possible to take away keys and certificates as software in PKCS12 files, as was the case in the past when private keys were stolen. This time, the certificate used for the signature was for a most likely small, general company, and they are a victim. In addition to the possibility that the attacker somehow holds the private key itself, there is also possibility that the methods using compromised accounts of the remote signing service, or gaining access of the host to which the token containing the private key is connected. It is currently unknown how the threat actor gained access to the private key of the certificate used for signing.

Initial access
Note that while we are unable to definitively conclude the exact methods used for initial access, we have evidence of the potential techniques used by the threat actor to gain entry into their target’s system, which we will discuss in this section.

Possible initial access via Zoom

Trend Vision One was able to record the process chain, which involved  the default browser (in this case, Google Chrome, launched from Zoom), downloading a file that acted as the point of entry for the malicious file. This suggests that Zoom served as the entry point of the attack, but we have not been able to confirm this.

The downloaded file has the name of a specific font — it’s possible that the user may have been on downloading font files since there were several files with this font name in the user’s downloads folder.

Possible initial access via abusing Google Colab to create search engine-optimized download sites

In addition to using Zoom as an initial access method, the threat actor might have also used SEO-friendly Google Colab sites as the starting point for the infection chain.

While investigating this case, we encountered a massive file distribution campaign that abused Google Colab websites, even going so far as to optimize them for search engine optimization (SEO) purposes. A report by Sucuri in July 2023, suggests that this campaign has been active since July 2022 and is being optimized using gambling-related key words and phrases. However, it seems that their SEO targets are now more targeted in scope, involving specific tools and fonts rather than generic words or phrases that have less of a chance to be displayed at the top of a search result.

During our investigation, an infected user mentioned to us that they downloaded a file that appeared on a search engine result page. When we tried searching for the tool name ourselves, we found a suspicious website appearing on the first page.

If this website is accessed, a Google Colab document appears with a link, seemingly to download a legitimate tool (as shown in Figure 7). However, clicking on the link will instead redirect the user to various malicious pages (with different destination pages depending on the timing).

We found many similar websites like this that abuse Colab and lure users into downloading files. During our investigation, we even found websites that used materials from Trend Micro using related search terms such as site:colab.research.google.com trend micro.

During the initial investigation, when we tried accessing any of the abused Cobal sites, we were redirected to a download page for the legitimate Opera GX browser. When we investigated on another day, we ended up on a page to download the legitimate 7zip installer. It’s possible that the malicious actors behind the operation implemented an analysis evasion mechanism that manages access sources and distributes redirect destinations.

While we did encounter a user who was trying to download a specific tool or font file encountering abused Colab sites, we were unable to find any of these sites hosting malware ourselves. Therefore, we labeled these Colab sites as a potential initial access point rather than as a definitive one.

Similar attacks that share the same infrastructure

We were able to observe similar (but different) attacks that share the same C&C infrastructure and modules.

Following the injection of explorer.exe, we detected a connection to two C&C IP addresses: 91[.]212[.]166[.]16:443 and 91[.]103[.]252[.]74:80. Both of these IP addresses had previous associations with information-stealing malware such as StealC and Vidar. One of these connections appeared to try and download a file named rar.exe.

Trend had prior knowledge and information on these C&C addresses, which is why this segment of the attack chain was intercepted and blocked.

Conclusion and recommendations

Given that entry points for this attack likely came from download sites or were delivered through communication apps, it is important that users be vigilant about the files and programs they download from the internet. Users should refrain from installing anything downloaded from the internet (especially on enterprise machines) unless they come from official sources and websites.

When downloading files sent via social media or chat apps, it’s essential to prioritize safety and security. Here are some best practices to follow. Users should verify the sender’s identity before downloading any files. If the message seems suspicious or unexpected, double-check with the sender through a different communication channel. In general, users should be cautious of executable files (e.g., .exe) or files with unusual extensions, since these are often used as entry points for malware attacks.

Finally, and as a general security best practice, both individuals and organizations should make it a point to regularly update their software. Updates often include security patches that can protect against potential vulnerabilities.

Comprehensive detection and response solutions like Trend Vision One can offer robust XDR capabilities. These capabilities gather and correlate data across various security layers — email, endpoints, servers, cloud workloads, and networks — ensuring automated protection to thwart attacks and vigilantly detecting any noteworthy incidents.

Indicators of Compromise

The indicators of compromise for this entry can be found here.