eSentire is The Authority in Managed Detection and Response Services, protecting the critical data and applications of 2000+ organizations in 80+ countries from known and unknown cyber threats. Founded in 2001, the company’s mission is to hunt, investigate and stop cyber threats before they become business disrupting events.
We provide sophisticated cybersecurity solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs). Find out why you should partner with eSentire, the Authority in Managed Detection and Response, today.
Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes.
We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware.
Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team.
In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward.
Here’s the latest from our TRU Team…
What did we find?
In recent weeks, TRU has observed an uptick in cases related to LummaC2 across multiple industry verticals.
LummaC2 is an information stealer distributed as a Malware-as-a-Service (MaaS) offering on Russian-language forums. The malware was first observed in mid-2022 and remains under active development. As is common with information-stealers, LummaC2 targets an array of information on infected systems including browser credentials and cryptocurrency accounts.
Our analysis suggests it also has the ability to load additional malware onto the system. In a recent case in mid-August, a user became infected with LummaC2, Amadey, and PrivateLoader after running a fake Chrome browser update.
This blog will cover the initial access vector and follow on payloads from this case.
Analysis of the Fake Chrome Update Delivery Mechanism
In the recent case involving a retail customer, the victim performed a Google search for a non-profit educational organization based in El Salvador.
Figure 1 The infection was kicked off with a Google search
When the page was visited, the user was presented with a fake update for their Chrome browser:
Figure 2 Fake Chrome Update Overlay
Examining the page’s source code, it’s apparent that an iframe has been injected and overlaid over the legitimate page:
Figure 3 Close inspection of the iframe
The iframe loads threat-actor controlled HTML from
Figure 4 The first stage of HTML initially loaded by the iframe. The code is replaced with a longer HTML file containing the Chrome page and tracking scripts.
This new HTML contains JavaScript that manipulates the DOM and replaces the entire document with the content of ‘X2luZGV4LnBocA==' (’_index.php'). This new page contains a 6000+ line HTML document containing various scripts associated with Keitaro TDS and FingerprintJS.
Figure 5 Comparison of a snippet from the threat actor's script and Keitaro's docs
Keitaro TDS is a popular traffic distribution system used for advertising campaigns. It offers robust device-based filtering options which, in this case, is likely used to deliver payloads to specific groups of targets and to avoid scanners/known vendor IPs.
Snippets of code related to FingerprintJS are also found:
Figure 6 Snippet of FingerPrintJS found in the HTML
When the FingerprintJS library is initialized, it collects device fingerprint data, encodes it then uses an AJAX function to send it to hxxps://stats-best[.]site/fp.php via POST request:
Figure 7 Code for initializing FingerPrintJS and sending the data to a third site.
The fingerprint data contains various attributes about the visitor, including Operating System, keyboard language, screen resolution, time zone, plugins, canvas fingerprint and the visitor ID. How this data is used is not immediately clear. It’s a strong possibility that it is used for campaign tracking and/or filtering of victims.
When examining the fake Chrome update, we noticed the HREF tied to the “Update Chrome” button leads to a legitimate Google link, further increasing the apparent authenticity of the update warning.
Figure 8 The user perspective when hovering over the "Update Chrome” button
However, when clicked, the user is instead redirected to a malicious download. Examining the DOM, we noticed this JavaScript:
Figure 9 JavaScript code responsible for hijacking the legitimate Google.com link to threat actor controlled infrastructure
The script attaches an event listener to the anchor element “js-download-hero”. This element contains the legitimate Chrome URL:
Figure 10 Snippet of the js-download-hero element
When this element is clicked, it triggers the event listener. The script first modifies the default behavior using e.preventDefault(), effectively stopping the click from navigating the Google URL. It then constructs a new URL using the Fingerprint ID (FPID) and other parameters then redirects to the new malicious URL.
The “DownloadMouse” class likely uses a hover event listener to track mouse movement. If the element is hovered over by the user’s mouse, it’s reported in the subsequent request for the payload as True.
All of this culminates in a callback to the Keitaro gateway (wnimodmoiejn[.]site), where filters are likely applied before ultimately redirecting to a file hosted on Microsoft’s OneDrive. The user is then presented with a ChromeSetup.exe file (c9094685ae4851fd5a5b886b73c7b07efd9b47ea0bdae3f823d035cf1b3b9e48).
Figure 11 Handoff to OneDrive hosted payload
ChromeSetup.exe Analysis
When opened by the victim, ChromeSetup.exe initiates a series of steps to load LummaC2 Stealer which in turn loads additional remote payloads. In this instance, the payloads were Amadey and PrivateLoader.
MSI file Retrieval and Execution
ChromeSetup.exe launches Msiexec.exe with command line options to retrieve and install a remove package:
Update.msi is a Windows installer file created using Advanced Installer. The package contains various files including DLLs, a log file, and an executable file:
Figure 12 Bundled files in the installer package
It also contains a Custom Action to launch VMwareHostOpen.exe:
Figure 13 Custom action launches the VMware binary using Viewer.exe
At first glance the bundled files appear to be legitimate VMware-related files. Two of these files (vmtools.dll and vmo.log) are not legitimate and are components used for loading the next stage of the malware. The bundled files are written to AppData\Roaming\installation-assistant-*\.
VMwareHostOpen.exe DLL Replacement
VMwareHostOpen.exe (0edde5e8300ad4e03f68c05bd022b998) is a valid VMware executable with a signature timestamp from August 2020. It loads several DLLs (including vmtools.dll) from its current working directory before searching other standard paths.
In this case when VMwareHostOpen.exe is executed using the custom action described above, it loads vmtools.dll (95bd27110f462e416904970631fd48a0) which is dropped in the same directory by the installer. We located the original vmtools.dll file and from a quick glance at the file properties it’s apparent the one packaged here has been modified:
Figure 14 Comparison between DLLs.
Examining the execution flow of both the legitimate and modified DLL, we can see the threat actor patched the legitimate DLL to redirect execution flow to attacker supplied shellcode. Given that the file size remained the same between the files, it’s likely legitimate code was overwritten to achieve this.
Figure 15 Execution flow is redirected to shellcode in the modified DLL.
Config Extraction and Next-Stage Payloads
Vmtools.dll, loaded by VMwareHostOpen.exe copies the files from the installation directory to a new path under AppData\Roaming\*randomstring*. It then reads from vmo.log, another of the bundled files. Examining the log file reveals it appears to be a PNG image:
Figure 16 Examining vmo.log
The image contains steganographic data which holds injection targets, write locations and deconstructed PE’s (we assess sections, or the entire PEs are injected into targets cmd.exe or explorer.exe). This is likely done for defense evasion purposes by inhibiting memory analysis of intact binaries. A copy of the cleartext file can be found here.
Figure 17 Vmo.log Vmo.png. The rows of pixel blocks suggest embedded data. Our analysis inferred this to be configuration data used for subsequent payload retrieval. Figure 18 Snippet of decoded PNG data.
TRU member Saptarshi Laha created a Python script to decode the PNG file, which is available here.
This step may seem redundant, but we assess it was likely done to maintain the original file size of vmtools.dll and add modularity.
The shellcode is loaded by vmtool.dll to create an executable section with injected code from the PNG file within mshtml.dll. This is further used to create a hollowed cmd.exe process which in turn injects LummaC2 into a new explorer.exe process using process hollowing. Under the hollowed explorer.exe process, LummaC2 contacts URL (doorblu[.]xyz/c2conf) to retrieve a base64 string containing an XOR-encrypted configuration file:
Figure 19 Encoded data retrieved from one of several command and control servers.
This object decodes to a JSON file containing configuration data:
Figure 20 JSON configuration retrieved from C2 path /c2conf.
The configuration file contains a list of targets common with information stealing, including browser credentials, crypto wallets, password etc.
Figure 21 Snippets of the configuration showing targeted data.
A series of HTTP POST requests are made to the C2 to upload system information and the stolen data targeted within the above configuration. Also present within the configuration file is a payload URL:
Figure 22 URL path for the .NET loader. Found at the bottom of LummaC2's config.
In our testing the configuration file changed over time, with new URLs rotated in and out which served a .NET loader covered below. Observed URLs include:
The .NET loader is executed by the same hollowed Windows Explorer process mentioned above. Its lineage can be traced back to the VMwareHostOpen.exe process if examining a parent/child process tree. It contains two encrypted resource files containing Amadey and PrivateLoader (in recent testing StealC was also observed). These resources are decrypted using an AES decryption routine and executed.
Figure 23 Snippets from.NET loader analysis. The embedded payloads are decrypted at runtime.
For persistence, recent Amadey samples we analyzed established persistence using Startup Folder, scheduled tasks and Run/RunOnce keys. For scheduled tasks, the task name will match the name of the binary dropped to the %temp% directory. We have also observed modifications to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders to point the startup folder to the directory containing the Amadey binary.
Recent samples connected to Amadey C2 panel at IP 45.9.74[.]182.
Figure 24 Amadey C2 Panel login
In summary, this infection scheme delivered a malicious installation package via a compromised website using a Chrome update overlay. The installation package uses a modified VMware DLL to load shellcode from a PNG containing hidden data. This shellcode is injected into legitimate Windows processes whereby data is stolen from the system and uploaded to the C2 before loading additional payloads.
This final order of operations is a bit unusual. We typically observe malware report basic system information before dropping additional payloads, not wholesale information theft from the system. It’s possible this is simply a precautionary measure in case the subsequent payloads are detected.
Alternatively, considering the MaaS model, it remains a realistic possibility that the threat actor is skimming valuable information before dropping the final payloads.
How did we find it?
MDR for Endpoint identified file activity related to suspicious installer files.
What did we do?
Our team of 24/7 SOC Cyber Analysts isolated the host and alerted the customer while an investigation took place before remediating the threat.
What can you learn from this TRU positive?
Fake browser updates remain a popular method for malware delivery. As demonstrated in this case, a new webpage is overlaid on top of a page visited by the user. The overlay instructs the visitor to update their browser by clicking a download link.
The Chrome update page shown in the above case looks nearly identical to the real download page.
Furthermore, the link preview points to Google.com, making detection by the user that much more difficult.
Recommendations from our Threat Response Unit (TRU):
An effective PSAT program emphasizes building cyber resilience by increasing risk awareness, rather than trying to turn everyone into security experts.
The eSentire Threat Response Unit (TRU) is an industry-leading threat research team committed to helping your organization become more resilient. TRU is an elite team of threat hunters and researchers that supports our 24/7 Security Operations Centers (SOCs), builds threat detection models across the eSentire XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. By providing complete visibility across your attack surface and performing global threat sweeps and proactive hypothesis-driven threat hunts augmented by original threat research, we are laser-focused on defending your organization against known and unknown threats.
Cookies allow us to deliver the best possible experience for you on our website - by continuing to use our website or by closing this box, you are consenting to our use of cookies. Visit our Privacy Policy to learn more.
