Malware
Attack Signals Possible Return of Genesis Market, Abuses Node.js, and EV Code Signing
The Trend Micro Managed XDR team encountered malicious operations that used techniques similar to the ones used by Genesis Market, a website for facilitating fraud that was taken down in April 2023.
Save to Folio
The Trend Micro Managed XDR team encountered malicious operations that used techniques similar to the ones used by Genesis Market, a website for facilitating fraud that was taken down in April 2023 (although there are reports that its infrastructure and inventory were sold on the underground, which might explain why techniques connected with Genesis Market are being used in this attack). The threat actor behind these operations abused Node.js to act as a platform for the backdoor, Extended Validation (EV) Code Signing for defence evasion, and possibly Google Colab to host search engine-optimised download sites. Infected users could be vulnerable to attackers executing backdoor commands on their system, as well as payloads such as the Lu0bot malware, which can perform a number of functions that includes gathering data and performing distributed-denial-of-service (DDoS) attacks.
This blog entry provides a technical analysis of these attacks, including what we can definitively confirm and our speculations on the other techniques used by the threat actor behind these activities.
Infection chain
We observed the following timeline of events:
| Timeline | Activity |
|---|---|
| T0 | The file, microsoft_barcode_control_16.0_download.exe, (3364dd410527f6fc2c2615aa906454116462bf96) is downloaded using a browser |
| + 20 seconds | The file is executed by the user |
| + 1 minute and 15 seconds | The first payload is executed |
| + 1 second | The second payload is executed. |
| + 13 seconds | The first backdoor command is executed via lu0bot. |
| + 3 mins 20 seconds | The last backdoor command is executed via lu0bot. |
Table 1. Observed timeline of events
Trend Vision One’s Execution Profile shows the following infection activity:
The first stage of the attack
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}\Dwnloads\microsoft_barcode_control_16.0_download.exe
(3364dd410527f6fc2c2615aa906454116462bf96)
Upon analysing 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 analysed 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 instal 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 behaviour 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 behaviour via reverse engineering.
The second stage of the attack
The initial payload that the loader instals 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}\AppData\Local\Default\app.html
- C:\Users\{username}\AppData\Local\Default\config.js
- C:\Users\{username}\AppData\Local\Default\ico.png
- C:\Users\{username}\AppData\Local\Default\manifest.json
- C:\Users\{username}\AppData\Local\Default\modules\content-scripts-register-polyfill.4.0.0.js
- C:\Users\{username}\AppData\Local\Default\rules.json
- C:\Users\{username}\AppData\Local\Default\src\background.js
- C:\Users\{username}\AppData\Local\Default\src\content\main.js
- C:\Users\{username}\AppData\Local\Default\src\functions\clipper.js
- C:\Users\{username}\AppData\Local\Default\src\functions\commands.js
- C:\Users\{username}\AppData\Local\Default\src\functions\csp.js
- C:\Users\{username}\AppData\Local\Default\src\functions\domain.js
- C:\Users\{username}\AppData\Local\Default\src\functions\exchangeSettings.js
- C:\Users\{username}\AppData\Local\Default\src\functions\extensions.js
- C:\Users\{username}\AppData\Local\Default\src\functions\getMachineInfo.js
- C:\Users\{username}\AppData\Local\Default\src\functions\injections.js
- C:\Users\{username}\AppData\Local\Default\src\functions\notifications.js
- C:\Users\{username}\AppData\Local\Default\src\functions\proxy.js
- C:\Users\{username}\AppData\Local\Default\src\functions\screenshot.js
- C:\Users\{username}\AppData\Local\Default\src\functions\screenshotRules.js
- C:\Users\{username}\AppData\Local\Default\src\functions\settings.js
- C:\Users\{username}\AppData\Local\Default\src\functions\tabs.js
- C:\Users\{username}\AppData\Local\Default\src\functions\utils.js
- C:\Users\{username}\AppData\Local\Default\src\mails\gmail.js
- C:\Users\{username}\AppData\Local\DesktopCleanup\Google Chrome.lnk
- C:\Users\{username}\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\Google Chrome.lnk
- C:\Users\{username}\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Google Chrome.lnk
- C:\Users\{username}\OneDrive\Desktop\Google Chrome.lnk
As part of the second stage of the attack the loader launches the second payload. In one case we analysed, 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:\ProgramData\DNTException\node.exe
A closer look at this payload sample reveals it to be the malware analysed 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}\AppData\Local\Temp\nvnnimjsd\fnichvxlmq.exe"
- "C:\Users\{username}\AppData\Local\Temp\nvnnimjsd\lgjnbyhdmf.dat" 3721679456
- attrib.exe +H "C:\ProgramData\Intel\Intel(R) Management Engine Components"
- attrib.exe +H "C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 3573217561"
- attrib.exe +H "C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 3806163581"
- attrib.exe +H C:\ProgramData\DNTException
- attrib.exe +H C:\ProgramData\DNTException\node.exe
- attrib.exe +H C:\ProgramData\Intel
- C:\Users\{username}\AppData\Local\Temp\nvnnimjsd\fnichvxlmq.exe C:\Users\{username}\AppData\Local\Temp\nvnnimjsd\lgjnbyhdmf.dat 3721679456 1369574819
- cacls.exe C:\ProgramData\DNTException /t /e /c /g Everyone:F
- cacls.exe C:\ProgramData\Intel /t /e /c /g Everyone:F
- cmd.exe /c dir C:\
- icacls.exe C:\ProgramData\DNTException /t /c /grant *S-1-1-0:(f)
- icacls.exe C:\ProgramData\Intel /t /c /grant *S-1-1-0:(f)
- ipconfig.exe /all
- netstat.exe -ano
- node.exe node.lib 3721679456 3015897030
- reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "Intel Management Engine Components 1808681674" /t REG_SZ /d "wscript.exe /t:30 /nologo /e:jscript \"C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 3573217561\" \"C:\ProgramData\Intel\Intel(R) Management Engine Components\" 2779289286" /f
- reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "Intel Management Engine Components 1808681674" /t REG_SZ /d "wscript.exe /t:30 /nologo /e:jscript \"C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 3573217561\" \"C:\ProgramData\Intel\Intel(R) Management Engine Components\" 2779289286" /f
- reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders"
- reg.exe query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- reg.exe query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- reg.exe query HKLM\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11coe-bfc1-08002be10318}
- reg.exe query HKLM\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11coe-bfc1-08002be10318}\0000
- reg.exe query HKLM\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11coe-bfc1-08002be10318}\0001
- 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.
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}\AppData\Local\Temp\RTIvsEUane3TLWA\svchost.exe
- C:\Users\{username}\AppData\Local\Temp\nJAnCiq3sxgojkV\svchost.dll
- C:\Users\{username}\AppData\Local\Temp\6\kzC88czML4rqbVN\svchost.dll" (43f11d6aec961fc82cf53e4eca97c429285026f3e)
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 defence 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 minimising 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}\Downloads\microsoft_barcode_control_16.0_download.exe (3364dd410527f6fc2c2615aa906454116462bf96)
- C:\Users\{username}\Downloads\avenir 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.
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.
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 optimise them for search engine optimisation (SEO) purposes. A report by Sucuri in July 2023, suggests that this campaign has been active since July 2022 and is being optimised 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 labelled 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 programmes 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 prioritise safety and security. Here are some best practises 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 practise, both individuals and organisations 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.