Winnti: an attack on supply chains - Asian game developers are at the forefront

This is not the first time that attackers have attacked the gaming industry, compromised developers, added backdoors to the game’s build environment, and then distributed malware under the guise of a legitimate one. In April 2013, Kaspersky Lab reported a similar incident. This attack is attributed to a cybergroup called Winnti.

Recently, ESET experts have been attracted by new attacks on supply chains. Two games and one gaming platform were compromised to introduce a backdoor. These attacks target Asia and the gaming industry, with Winnti again behind them.

Three cases, one backdoor

Despite the different malware configurations, the three compromised software products included the same backdoor code and started using the same mechanism. Now there are no backdoors in two products, but one is still distributed in a trojanized version - ironically, this game is called Infestation, which is released by the Thai company Extreme Extreme. We have been trying to contact the developer since the beginning of February, but so far to no avail.

We will analyze how the malicious payload is introduced, and then consider the backdoor in detail.

Payload Implementation

The payload code runs during the execution of the trojanized executable. Immediately after the PE entry point, the standard C Runtime initialization call ( __scrt_common_main_sehin the figure below) is intercepted to launch the malicious payload before anything else (Figure 2). This may indicate that the attackers changed the assembly configuration, and not the source code itself.



Figure 1. Net entry point to an executable file



. 2. Entry point of a compromised executable file.

The code added to the executable decrypts and launches the backdoor in RAM before resuming normal execution of the C Runtime initialization code and subsequent host application code. The built-in payload has a special structure, shown in the figure below, which is interpreted by the added decompression code.



Figure 3. Built-in payload structure. It

contains the RC4 key (encrypted XOR with 0x37), which is used to decrypt the file name and embedded DLL file.

Malicious Payload

The actual malicious payload contains only 17 KB of code and data.

Configuration

The configuration data shown in the figure below is a list of lines separated by spaces.



Figure 4. Payload configuration data The configuration

consists of four fields:

1. URL of the managing C & C server.
2. The variable (t) used to determine the timeout in milliseconds before continuing. The waiting time is selected in the range from 2/3 to 5/3 t randomly.
3. Line identifying the campaign.
4. A list of executable file names, separated by a semicolon. If any of them works, the backdoor stops its execution.

We identified five versions of the payload:



In the first three options, the code was not recompiled, but the configuration data was edited in the DLL file itself. The rest of the content is a byte copy.

C&C Infrastructure

Domain names are chosen in such a way as to resemble the sites of developers of compromised applications. The top-level domain is configured to redirect to the corresponding legitimate site using the Namecheap service, while the subdomain indicates a malicious C&C server.



At the time of this writing, none of the domains is available, C & C-servers are not responding.

Study report

The bot ID is generated from the MAC address of the machine. The backdoor transmits machine information to the C&C server, including username, computer name, Windows version and system language, and then waits for a command. Data is encrypted with XOR using the “ *&b0i0rong2Y7un1” key and base64 encoded. Data received from the C&C server is encrypted using the same key.

Teams

A simple backdoor supports only four teams that can be used by attackers:

- DownUrlFile
- DownRunUrlFile
- RunUrlBinInMem
- UnInstall

The names of the teams speak for themselves. They allow attackers to run additional executables from a given URL.

Perhaps the last command is less obvious. UnInstalldoes not remove malware from the system. In the end, it is embedded in a legitimate executable file that will still run. Instead of deleting something, the command disables the malicious code by setting the value to 1 for the registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\ImageFlag

After starting the payload, the value from the registry is requested and, if specified, execution is canceled. Perhaps the attackers are trying to reduce the load on their C&C servers by avoiding callbacks from victims of no interest.

Second phase

According to telemetry, one of the second-stage payloads sent to victims is Win64 / Winnti.BN. As far as we can tell, the dropper of this malware is downloaded via HTTPs api.goallbandungtravel[.]com. We saw that it was installed as a Windows service and as a DLL in C:\Windows\System32, using the following file names:

- cscsrv.dll
- dwmsvc.dll
- iassrv.dll
- mprsvc.dll
- nlasrv.dll
- powfsvc.dll
- racsvc.dll
- slcsvc. dll
- snmpsvc.dll
- sspisvc.dll

The samples we analyzed were large enough - about 60 MB. However, this is only visibility, since the actual size or PE file is from 63 to 72 KB, depending on the version. A lot of clean ones are simply added to malicious files. This is likely to be done by a component that resets and installs a malicious service.

After starting the service, it adds the extension to its DLL path .muiand decrypts it using RC5. The decrypted MUI file contains position-independent code with an offset of 0. The RC5 key is obtained from the serial number of the hard disk and the line “ f@Ukd!rCto R$.”. We could not get either the MUI files or the code that installs them first. Thus, the exact purpose of the malicious service is unknown to us.

Recent malware versions include an auto-update mechanism using a C&C server http://checkin.travelsanignacio[.]com. This server served the latest version of the MUI files encrypted with the RC5 static key. In the course of our research, this C&C server did not respond.

Goals

Let's start with those who the campaign is not specifically targeted at. At the beginning of the payload, the malware checks whether the system language is Russian or Chinese (see the figure below). If the answer is yes, the program stops working. It is impossible to get around this exception - attackers are not fundamentally interested in computers with these language settings.



Figure 5. Checking the language before launching the payload

Distribution statistics

According to telemetry, most infections occurred in Asia, especially Thailand. Given the popularity of the compromised application, which is still being distributed by the developer, it is not surprising if the number of victims amounts to tens and hundreds of thousands.

Conclusion

Supply chain attacks are hard to detect on the user side. It is impossible to analyze all running software, as well as all recommended updates. By default, the user trusts the developers and assumes that their files do not contain malicious code. This is probably why several cybergroups are targeting attacks on software vendors - compromising will allow creating a botnet, the size of which is comparable to the popularity of trojanized software. This tactic has a downside - when the scheme is revealed, attackers will lose control of the botnet, and users will be able to clean the system by installing the next update.

The motives of the Winnti cybergroup are currently unknown. Perhaps the attackers are looking for financial gain or are planning to use the botnet as part of a larger operation.

ESET products detect the threat as Win32 / HackedApp.Winnti.A, Win32 / HackedApp.Winnti.B, the payload as Win32 / Winnti.AG, the second stage as Win64 / Winnti.BN.

Indicators of compromise are available here .