This is not the first time the gaming industry has been targeted by attackers who compromise game developers, insert backdoors into a game’s build environment, and then have their malware distributed as legitimate software. In April 2013, Kaspersky Lab reported that a popular game was altered to include a backdoor in 2011. That attack was attributed to perpetrators Kaspersky called the Winnti Group.

Yet again, new supply-chain attacks recently caught the attention of ESET Researchers. This time, two games and one gaming platform application were compromised to include a backdoor. Given that these attacks were mostly targeted against Asia and the gaming industry, it shouldn’t be surprising they are the work of the group described in Kaspersky’s “Winnti – More than just a game”.

Three Cases, Same Backdoor

Although the malware uses different configurations in each case, the three affected software products included the same backdoor code and were launched using the same mechanism. While two of the compromised products no longer include the backdoor, one of the affected developers is still distributing the trojanized version: ironically, the game is named Infestation, and is produced by Thai developer Electronics Extreme. We have tried informing them several times, through various channels, since early February, but without apparent success.

Let’s look at how the malicious payload is embedded and then look into the details of the backdoor itself.

Embedding the payload

The payload code is started very early during the execution of the backdoored executable file. Right after the PE entry point, the standard call to the C Runtime initialization (__scrt_common_main_seh in Figure 1) is hooked to launch the malicious payload before everything else (Figure 2). This may suggest that the malefactor changed a build configuration rather than the source code itself.

Figure 1 Clean executable file entry point

Figure 2 Compromised executable file entry point

The code added to the executable decrypts and launches the backdoor in-memory before resuming normal execution of the C Runtime initialization code and all the subsequent code of the host application. The embedded payload data has a specific structure, seen in Figure 3, that is parsed by the added unpacking code.

Figure 3 Embedded payload structure

It includes an RC4 key (which is XORed with 0x37) that is used to decrypt a filename and the embedded DLL file.

The malicious payload

The actual malicious payload is quite small and only contains about 17 KB of code and data.

Configuration

Illustrated in Figure 4, the configuration data is simply a whitespace-separated list of strings.

Figure 4 Payload configuration data

The configuration consists of four fields:

1. C&C server URL.
2. Variable (t) used to determine the time to sleep in milliseconds before continuing the execution. Wait time is chosen randomly in the range 2/3 t to 5/3 t.
3. A string identifying a campaign.
4. A semicolon-separated list of executable filenames. If any of them are running, the backdoor stops its execution.

ESET researchers have identified five versions of the payload:

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

C&C infrastructure

Domain names were carefully chosen to look like they are related to the game or application publisher. The apex domain was set to redirect to a relevant legitimate site using the Namecheap redirection service, while the subdomain points to the malicious C&C server.

At the time of writing, none of the domains resolve and the C&C servers are not responding.

Reconnaissance report

A bot identifier is generated from the machine’s MAC address. The backdoor reports information about the machine such as the user name, computer name, Windows version and system language to the C&C server and awaits commands.  The data is XOR encrypted with the key “*&b0i0rong2Y7un1” and base64-encoded. The data received from the C&C server is encrypted using the same key.

Commands

This simple backdoor has only four commands that can be used by the attacker:

• DownUrlFile
• DownRunUrlFile
• RunUrlBinInMem
• UnInstall

The commands are pretty much self-explanatory. They allow the attacker to run additional executables from a given URL.

The last one is perhaps less obvious. The UnInstall command doesn’t remove the malware from the system. After all, it is embedded inside a legitimate executable that still needs to run. Rather than removing anything, it disables the malicious code by setting the following registry value to 1:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\ImageFlag

When the payload is started, the registry value is queried and execution is aborted if set. Perhaps the attackers are trying to reduce the load from their C&C servers by avoiding callbacks from uninteresting victims.

Second stage

Based on ESET telemetry, one of the second stage payload delivered to victims is Win64/Winnti.BN. As far as we can tell, its dropper was downloaded over HTTPS from api.goallbandungtravel[.]com. We have seen it 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 have analyzed were actually quite large, each of them about 60 MB. This is, however, only for appearance because the real size or the PE file is between 63 KB and 72 KB, depending on the version. The malware files simply have lots of clean files appended to them. This is probably done by the component that drops and installs this malicious service.

Once the service runs, it appends the extension .mui to its DLL path, reads that file and decrypts it using RC5. The decrypted MUI file contains position-independent code at offset 0. The RC5 key is derived from the hard drive serial number and the string “f@Ukd!rCto R$.” — we were not able to obtain any MUI files nor the code that installs them in the first place. Thus, we do not know the exact purpose of this malicious service.

Recent versions of the malware include an “auto-update” mechanism, using C&C server http://checkin.travelsanignacio[.]com. That C&C server served the latest version of the MUI files encrypted with a static RC5 key. The C&C server was not responding during our analysis.

Targets

Let’s start with who is not targeted. Early in the payload, the malware checks to see if the system language is Russian or Chinese (Figure 5). In either case, the malware stops running. There is no way around this: the attackers are simply not interested in computers configured with those languages.

Figure 5 Language checks before running the payload

Distribution statistics

ESET telemetry shows victims are mostly located in Asia, with Thailand having the largest part of the pie. Given the popularity of the compromised application that is still being distributed by its developer, it wouldn’t be surprising if the number of victims is in the tens or hundreds of thousands.

Conclusion

Supply-chain attacks are hard to detect from the consumer perspective. It is impossible to start analyzing every piece of software we run, especially with all the regular updates we are encouraged or required to install. So, we put our trust in software vendors that the files they distribute don’t include malware. Perhaps that’s the reason multiple groups target software developers: compromising the vendor results in a botnet as popular as the software that is hacked. However, there is a downside of using such a technique: once the scheme is uncovered, the attacker loses control and computers can be cleaned through regular updates.

We do not know the motives of the attackers at this point. Is it simply financial gain? Are there any reasons why the three affected products are from Asian developers and for the Asian market? Do these  attackers use a botnet as part of a larger espionage operation?

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

Indicators of Compromise (IoCs)

Compromised file samples (Win32/HackedApp.Winnti.A and B)

Some hashes were redacted per request from one of the vendor. If for a particular reason you need them, reach out to us at threatintel@eset.com.

Payload Samples (Win32/Winnti.AG)

Second stage samples (Win64/Winnti.BN)

Dropper delivered by api.goallbandungtravel[.]com.

MITRE ATT&CK matrix