FortiGuard Labs has encountered version 3.0 of what is now dubbed IceXLoader, a new malware loader being advertised in malware hacking forums.
IceXLoader is a commercial malware used to download and deploy additional malware on infected machines. The latest version is written in Nim, a relatively new language utilized by threat actors the past two years, most notably by the NimzaLoader variant of BazarLoader used by the TrickBot group.
This article discusses the technical details of how IceXLoader behaves and the potential malware that it can deliver in an infected system.
Affected Platforms: Windows
Impacted Parties: Windows users
Impact: Potential to deploy additional malware for malicious purposes
Severity Level: Medium
While hunting for new malware families written in the Nim programming language, FortiGuard Labs discovered a loader malware with the strings “ICE_X” and “v3.0”.
A loader is a type of malware that is intended for downloading and executing additional payloads provided by a threat actor to further their malicious objectives.
Collected samples had some incomplete features, for example the code for using a mutex for running only a single instance of the malware is only comprised of dummy code. When coupled with the “v3.0” string (implying the presence of earlier versions of a similar malware), we suspected that this was a work-in-progress port of an existing malware to Nim.
To validate our hypothesis, we dug deeper and found links to underground forums where the developers sell the loader as ICE X at $118 for a lifetime license (Figure 1).
The malware developers’ website (Figure 2), sells several commodity malware and provides related services including hacking, crypting, and malware development. The team of four claims 14 years of experience in the business with more than 200 clients.
FortiGuard Labs researchers chose to name this malware family IceXLoader based on the “ICE_X” strings found in both version 1 and version 3 samples. As there are similarly-named Ice IX / IceX variants of the Zeus banking trojan, we appended Loader to the name to avoid confusion with these older banking trojans.
The developers provided a video to demonstrate configuring the IceXLoader builder with a Server URL containing the familiar Command & Control (C2) URL pattern “icex/Script.php” seen in our samples (Figure 3).
In the same video, the developers showed an IceXLoader version 1 client connected to the C2 server panel (Figure 4), which was likely the production version at that time.
Pivoting around the known C2 URLs for IceXLoader allowed us to collect version 1 samples written in the AutoIt scripting language.
The almost identical implementation of the functions from the two versions confirmed our suspicions that the Nim-based loader is a newer version of the more feature-complete IceXLoader version 1 (Figure 5).
The developers market their loader as FUD (Fully UnDetected), a common term used within malware hacking forums to denote malware that can bypass antivirus products. They also claim that they will continuously update it as security products eventually detect such malware.
This need to evade security products could be a reason the developers chose to transition from AutoIt to Nim for IceXLoader version 3. Since Nim is a relatively uncommon language for applications to be written in, threat actors take advantage of the lack of focus on this area in terms of analysis and detection.
The following technical analysis will focus primarily on IceXLoader version 3. However, comparisons to old versions are mentioned where necessary.
The IceXLoader builder generates a standalone executable EXE file with the chosen configuration values hardcoded into each file that a threat actor can distribute to potential victims.
Once this file is executed on a victim machine, it initializes itself based on the configured settings.
If configured, IceXLoader utilizes Windows startup features commonly abused by malware to survive system reboots. It copies itself to %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\ with a configurable filename.
At the same time, it adds a registry entry in Software\Microsoft\Windows\CurrentVersion\Run with the value set to a second copy previously dropped in %AppData%.
As the mutex implementation is incomplete in the version 3 samples, multiple instances of IceXLoader will run when Windows restarts.
IceXLoader performs a known method of in-memory patching of “AmsiScanBuffer” in AMSI.DLL. It does this to bypass the Microsoft Windows Antimalware Scan Interface used by security products to scan and detect malicious content. This reduces the chance of IceXLoader and its subsequent malware payloads being detected.
It then writes some PowerShell commands to %TEMP%\file.bat (Figure 6) and executes them to disable Windows Defender’s real-time scan. Moreover, it adds exclusions to Windows Defender to prevent it from scanning the directory where IceXLoader is located.
Once the malware has completed initialization, it proceeds to communicate with the C2 to carry out further actions in the victim system.
IceXLoader communicates with a hardcoded list of C2 servers via HTTP/HTTPS POST requests. The User-Agent HTTP header is set to the Windows machine GUID, which uniquely identifies each infected machine. This could be referred to as a victim ID. Communication between the loader and C2 is in plaintext and is not encoded or encrypted.
Figure 7 demonstrates the communication flow between IceXLoader and its C2 server. The “info” command is used as an example below, but other commands use a similar flow:
An initial beaconing POST request with “SetOn=On” is sent by IceXLoader to notify the C2 that it is ready to receive commands.
The C2 server usually responds with an “info” command to register the loader as a valid client in the server panel. The client acknowledges the command by responding with “Done=<command><|>” i.e., “Done=info<|>”. After that, the client executes the command.
For the “info” command, IceXLoader collects the following information and sends it to the C2 server
Figure 8 shows an HTTP POST request with all the information gathered from the victim system.
Once the system info is sent to the C2 server, IceXLoader regularly repeats the beaconing request to poll for additional commands.
The list of all the commands supported by IceXLoader can be found below. The pipe “|” character is used to separate options for the commands. Words in italics refer to values supplied by the threat actor.
As the main function of IceXLoader, the malware operator can interactively send “runFile” commands to the loader to download and execute additional malware on disk or filelessly in memory.
Previous campaigns spotted in the wild distributed DcRat via IceXLoader version 1 and an unknown malware with an associated Monero (XMR) miner via IceXLoader version 3.
The infection chains observed during earlier campaigns are illustrated below.
Malspam-delivered IceXLoader leads to DcRat (May 2022)
IceXLoader version 1 has been observed to be delivered through ZIP email attachments. The infection chain illustrated in Figure 9 is based on a submission by Andre Girondo at MalwareBazaar.
An email with a ZIP file attachment masquerading as an invoice is sent to unsuspecting victims. If a user unzips and executes the invoice.exe, this .NET executable drops and executes IceXLoader version 1. The attacker issues the runFile command to download and execute DcRat, a publicly available .NET-based Remote Access Tool (RAT).
A simple .NET downloader malware downloads and executes a .NET dropper, which then extracts and runs an IceXLoader version 3 embedded in itself. IceXLoader then receives the command to download an unknown malware. While FortiGuard Labs researchers were unable to obtain a sample of this malware, the accompanying configuration file suggested that this malware was likely a RAT or infostealer that will additionally deploy a Monero (XMR) cryptocurrency miner.
FortiGuard Labs is unable to confirm how the initial .NET downloader was delivered to victims. Based on the filenames of similar samples, they may have masqueraded as fake or cracked game-related installers.
In this article, we highlighted how threat actors continually evolve to evade and deter detection of their malware to the extent of porting existing code to a different and uncommon language. While simple and limited in functionality, loaders like IceXLoader pose a threat to users due to the possibility of threat actors deploying more full-featured malware upon infection.
FortiGuard Labs will continue to monitor IceXLoader and emerging trends in the loader threat landscape.
The FortiGuard Antivirus service detects and blocks this threat as W32/IceXLoader.FGLT!tr.
Fortinet customers are protected from this malware through FortiGuard’s Web Filtering, Antivirus, and CDR (content disarm and reconstruction) services and FortiMail, FortiClient, and FortiEDR solutions.
Loaders like IceXLoader are commonly delivered via phishing. Organizations should consider leveraging Fortinet solutions designed to train users to understand and detect phishing threats: