threat
ChromeLoader
ChromeLoader, a browser hijacker, went through several evolutions in 2023, challenging our assumptions and allowing us to refine our analysis of this threat.
Pairs with this song#6
OVERALL RANK
3.3%
CUSTOMERS AFFECTED
Threat Sounds
Like the members of Chromeo, ChromeLoader and its suspected delivery affiliate Charcoal Stork make for a dynamic duo.
Analysis
ChromeLoader is a browser hijacker capable of redirecting searches for popular search engines such as Google, Bing and Yahoo, sending search data to its C2, and adding and preventing users from uninstalling a malicious browser extension.
Our evolving understanding of an evolving threat
We began 2023 with a narrower view of ChromeLoader than most other reporting, opting to track the suspected delivery affiliate (Charcoal Stork) separate from the payload. Throughout 2022, we observed the malicious ChromeLoader browser extension frequently following Charcoal Stork initial access, often loaded via a persistent PowerShell command that would add the extension and restart the browser with the extension loaded. We also observed another Charcoal Stork payload, which we initially tracked as AdSearch, consisting of a NodeJS application installed into the AppData\Roaming
folder, that would sometimes spawn the ChromeLoader extension PowerShell loader. Due to differences between the NodeJS application that installed the next stage, and the PowerShell commands used to load the malicious browser extension, we distinguished these two payloads as distinct activity clusters.
However, as this threat evolved throughout 2023, we were able to refine our understanding. In August 2023, we merged AdSearch with ChromeLoader to simplify tracking different variants of this evolving threat. The emergence of SmashJacker, a payload distinct from ChromeLoader but that also stemmed from Charcoal Stork initial access, led to our decision to continue tracking Charcoal Stork separately. Later in 2023 we also observed VileRAT being delivered by Charcoal Stork, and research from other vendors suggests several other payloads have been observed as well.
Technical details
In 2023, we observed ChromeLoader using several different file types. Early in the year, we saw Visual Basic Scripts leading to PowerShell. By mid-year, we were seeing EXE and MSI installers. The initial file, often a NSIS installer for EXE files or an Advanced Installer-created MSI, led to increasingly obfuscated NW.js (formerly node-webkit
) applications including compiled JavaScript. The application, installed in C:\Users\<username>\AppData\Roaming\
, established persistence through a LNK file placed in C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
or a registry key entry in "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\
.
For those not familiar, NW.js
apps include many boilerplate runtime files, including a runtime binary named nw.ex
e, which is often renamed to match the name of the application. These files are not malicious on their own. You can think of it like python.exe executing a malicious .py
file. The malicious code is typically stored in one or more script files included in the package. The most important files for finding the malicious code are the package.json
and the file pointed to by the main: variable in that file. This file is often named index.html
. The HTML has the malicious JavaScript code to execute. In more recent versions of ChromeLoader, the JavaScript runs compiled JavaScript via the win.evalNWbin
function.
While the NW.js
runtime binary is not malicious on its own, the application names used by ChromeLoader are often unique. The application is often named with one or more common words and installed as a subfolder of C:\Users\<username>\AppData\Roaming\
. Throughout 2022 and the first half of 2023, the ChromeLoader NW.js
runtime binary matched the name of the application, however as of September 2023, it began using the default filename nw.exe
.
All of this NW.js
activity sets the stage for installing a malicious browser extension that harvests and redirects search traffic, likely to fuel advertising, and prevents the user from modifying the extensions installed in their browser. Malicious browser extensions often fall lower on defenders’ priority lists, as most just serve up adware. However, the ability to read and redirect user searches and data entered in the browser can expose sensitive company information or allow for more effective phishing campaigns against the user. There is also no guarantee that more malicious code won’t be installed at a later date.
Take action
The best way to stop ChromeLoader is at its source. Charcoal Stork lures distributing ChromeLoader typically masquerade as a download for a cracked video game, software, or movie. Educating users on the risks of downloading illegal content is a first step but not a solution in and of itself. The volume of Charcoal Stork downloads we see is evidence of the persuasiveness of their campaigns.
While ChromeLoader continues to evolve, several iterations create a scheduled task or place a LNK file in the Startup folder that then executes malicious code. In some versions of ChromeLoader, this code includes encoded PowerShell. The encoded PowerShell script downloads and loads a malicious browser extension into the user’s Chrome browser. Creating alerts (or blocking activity) within your EDR software for scheduled tasks that are created as a result of encoded PowerShell could prevent ChromeLoader from reaching its final stage. The strongest mitigation is browser extension allowlisting. This also safeguards against future innovation by ChromeLoader.
Because the attack lifecycle between initial execution and the creation of the Chrome extension is automated and can occur quickly, Red Canary recommends reimaging all systems that are potentially affected by ChromeLoader.
Detection opportunities
Red Canary has had success detecting ChromeLoader by looking for instances of NW.js applications that are unsigned and running from %AppData/Roaming%. This behavior is not unique to ChromeLoader, and some tuning may be required to avoid detecting legitimate applications. A partial list of common ChromeLoader NW.js runtime app installation paths is included below to help distinguish the signal from the noise.
Unique ChromeLoader NW.js
runtime app installation paths
:/users/<user>/appdata/roaming/bloom/bloom.exe
:/users/<user>/appdata/roaming/cash/cash.exe
:/users/<user>/appdata/roaming/diet/diet.exe
:/users/<user>/appdata/roaming/editor/editor.exe
:/users/<user>/appdata/roaming/healthy/healthy.exe
:/users/<user>/appdata/roaming/leading/leading.exe
:/users/<user>/appdata/roaming/movies/movies.exe
:/users/<user>/appdata/roaming/music/music.exe
:/users/<user>/appdata/roaming/prime/prime.exe
:/users/<user>/appdata/roaming/player/player.exe
:/users/<user>/appdata/roaming/tone/tone.exe
:/users/<user>/appdata/roaming/videos/videos.exe
:/users/<user>/appdata/roaming/copy/nw.exe
:/users/<user>/appdata/roaming/coreelevate/nw.exe
:/users/<user>/appdata/roaming/debuggerstepperboundaryattribute/nw.exe
Testing
Start testing your defenses against ChromeLoader using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
This test for T1053.005: Scheduled Task leverages PowerShell to create a scheduled task an is among the best atomics available to emulate late stage ChromeLoader activity, especially if you encode the command (as we do in the modified atomic below).
Run this test on a Windows system using PowerShell:
$ToEncode = @'
$Action = New-ScheduledTaskAction -Execute "calc.exe"
$Trigger = New-ScheduledTaskTrigger -AtLogon
$User = New-ScheduledTaskPrincipal -GroupId "BUILTIN\Administrators" -RunLevel Highest
$Set = New-ScheduledTaskSettingsSet
$object = New-ScheduledTask -Action $Action -Principal $User -Trigger $Trigger -Settings $Set
Register-ScheduledTask AtomicTask -InputObject $object
'@
[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($ToEncode))
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.