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.
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.
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.
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.
About Author
