Download PDF

April 2, 2021

Introduction

At the end of September 2020, one of the Russian research institutes contacted the Doctor Web virus laboratory seeking assistance. The research institute’s staff drew our attention to technical problems that could indicate the presence of malware on one of the servers in their local network. During the investigation, Doctor Web virus analysts found that the institute had been the victim of a targeted attack using specialized backdoors. A detailed study of the incident revealed that the facility's network had been compromised long before the institute contacted us and, judging by the available data, by more than one APT group.

The data obtained during the investigation suggests that the first APT group compromised the internal network of the institute in fall 2017. The initial infection was carried out using BackDoor.Farfli.130 —a modification of the Gh0st RAT malware. Later in spring 2019 the network was infected with Trojan.Mirage.12, and again in June 2020—with BackDoor.Siggen2.3268.

The second hacker group infiltrated the institute's network no later than April 2019. The infection began with the installation of BackDoor.Skeye.1. During the course of the investigation, we also found that around the same time—in May 2019—Skeye was deployed to the local network of another Russian research institute.

Meanwhile, in June 2019, FireEye published a report on that backdoor used in a targeted attack on the public sector of a number of Central Asian countries. Doctor Web virus analysts later uncovered various trojans that were installed in the institute’s network between August and September 2020 by the same APT group. The previously unknown BackDoor.DNSep.1 DNS backdoor, as well as the all-too-familiar BackDoor.PlugX were among the malware.

To top that off, in December 2017, a BackDoor.RemShell.24 was also installed on the servers of the research institute that contacted us. Samples of this malware family were previously described by Positive Technologies specialists in the study "Operation Taskmasters". At the moment we do not have enough data to decisively determine which of the two APT groups used this backdoor.

Who’s behind the attacks?

What we know about the first APT group is not enough to identify the attackers as one of the previously described hacker groups. At the same time, analysis of the malware and infrastructure used revealed that this group has been active since at least 2015.

We believe the second APT group that attacked the research institute is TA428, previously described by Proofpoint researchers in the "Operation Lag Time IT" study. The following facts support this conclusion:

1. 1) There are explicit intersections in the code of the BackDoor.DNSep and BackDoor.Cotx backdoors.
2. Both BackDoor.Skeye.1 and Trojan.Loader.661 were used in the same attack.
3. The backdoors we analyzed during the investigation of these attacks have intersections in the C&C servers' addresses and the network infrastructure with the backdoors used by TA428.

At this point, we’ll take a closer look at the uncovered connections. The graph shows part of the infrastructure involved in the attack with intersections between the Skeye backdoor and another well-known APT backdoor—PoisonIvy:

This graph shows the infrastructure intersections between the Skeye and Cotx backdoors:

A detailed analysis of the DNSep backdoor and a code comparison with the Cotx backdoor code revealed similarities in the general logic of processing commands from the C&C server and in specific implementations of individual commands.

Another interesting finding was the Logtu backdoor. We previously described one of its samples during our investigation of the incident in Kyrgyzstan. Its C&C server turned out to be atob[.]kommesantor[.]com, which was also the server for the Skeye backdoor. In this regard, we also conducted a comparative analysis of BackDoor.Skeye.1 with samples of BackDoor.Logtu.1 and BackDoor.Mikroceen.11.

For a detailed description of the malware used and how it works, see the PDF-version of the study or the Dr.Web Virus Library.

Comparative code analysis of BackDoor.DNSep.1 and BackDoor.Cotx.1

Even though Cotx and DNSep have radically different communication channels with the C&C server, we managed to find interesting matches in the code of both backdoors.

The function responsible for processing commands from the C&C server takes the structure as an argument:

struct st_arg
{
  _BYTE cmd;
  st_string arg;
};

At the same time, if the required function accepts several arguments, they are all written in the arg field with the separator |.

The BackDoor.Cotx.1 has more commands than the BackDoor.DNSep.1 does and includes all the commands as the latter.

The table below shows an almost complete code match for some of the backdoor functions. It is worth noting that Cotx uses Unicode encoding, while DNSep uses ANSI encoding.

BackDoor.DNSep.1	BackDoor.Cotx.1
A handler for a command to send a directory listing or disk information
Function for getting information about disks
Function for listing files in a folder
Function for collecting information about files in a folder

The data obtained during the analysis suggests that the author of the DNSep backdoor had access to the Cotx source codes. Since these resources are not publicly available, we assume the author or group of authors of DNSep is related to TA428. The DNSep sample supports this version, as it was found in the same compromised network along with other known TA428 backdoors.

Comparative code analysis of the Skeye, Mikroceen and Logtu backdoors

Over the course of the Skeye backdoor study, we found that the Logtu backdoor uses the same C&C server address. For comparative analysis, we used the previously described BackDoor.Logtu.1 and BackDoor.Mikroceen.11.

Logging functions

Logging in all cases is obfuscated.

• BackDoor.Mikroceen.11—messages in the %d - %d-%d %d:%d:%d <msg>\r\n format is written to the %TEMP%\WZ9Jan10.TMP file, where <msg> is a random text string. In the sample 2f80f51188dc9aea697868864d88925d64c26abc, the messages are written to the 7B296FB0.CAB file;
• BackDoor.Logtu.1—messages in the [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n format before writing to the %TEMP%\rar<rnd>.tmp file are encrypted with the XOR operation with the key 0x31;
• BackDoor.Skeye.1—messages in the format %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n are written to the %TEMP%\wcrypt32.dll file.

The general logic of the sequence of writing messages to the log is also similar for all three samples:

• The start of the execution is fixed
• A direct connection to the C&C server is recorded in the log in Logtu and Mikroceen.
• In each case, the proxy used to connect to the server is specified.
• A separate entry is recorded in the log in case of an error when obtaining a proxy from a particular source.

It should be noted that such detailed and obfuscated logging is extremely rare. Obfuscation implements the logging of some message codes and, in some cases, additional data. In addition, in this case, the general principle of the sequence of recording events is traced as follows:

• The start of the execution is fixed.
• Direct connection attempt
• Proxy addresses obtainment
• A record of the connection via a particular server

Search for a proxy server

The connection sequence to the C&C server also looks similar in all three samples. Initially, each backdoor attempts to connect to the server directly, and in case of failure, it can use proxy servers whose addresses are originating from three sources in addition to the built-in one.

BackDoor.Mikroceen.11 can obtain proxy servers addresses:

• From the %WINDIR%\debug\netlogon.cfg file;
• From its own log file;
• By searching for connections to remote hosts via ports 80, 8080, 3128, 9080 in the TCP table.

Search for a proxy in the own log file:

Search in active connections:

BackDoor.Logtu.1 can obtain proxy servers addresses:

• From the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• From the HKU section of the registry by the SID of the active user; and
• by WinHttpGetProxyForUrl WinHTTP API requesting google.com.

BackDoor.Skeye.1 can obtain proxy servers addresses:

• From the HCKU section of the registry Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• From the HKU section of the registry by the SID of the active user; and
• By searching for connections to remote hosts via ports 80, 8080, 3128, 9080 in the TCP table.

Intersections in the network infrastructure

Some samples shared the same network infrastructure. A fragment of the graph clearly shows the relationship between the families.

IDs

The Logtu and Mikroceen samples contain strings that are used as builds IDs or version IDs. Some of these strings share the same format.

In addition, a significant number of samples showed that this ID is equal to the value of TEST or test.

BackDoor.Logtu.1 example (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

BackDoor.Mirkoceen.11 example (81bb895a833594013bc74b429fb1f24f9ec9df26):

Thus, the comparative code analysis revealed similarities in the considered families in:

• The logic of event logging and its obfuscation;
• The logic of connection to the C&C server and in the proxy address search algorithms; and
• The network infrastructure.

Conclusion

Throughout the investigation into the attacks on the Russian research institutes, our virus analysts found and described several families of specialized backdoors, including previously unknown samples. It is worth noting that the unauthorized presence of the first APT group has gone unnoticed since 2017.

One of the most interesting findings is the code and network infrastructure intersections of the analyzed samples. We assume that the discovered connections indicate that the backdoors in question belong to the same APT groups.

Doctor Web specialists suggest regular monitoring of important network resources and pay timely attention to failures that may be the results of malware activity in the network. APT poses a significant threat not only by compromising data, but also by the prolonged presence of intruders in corporate networks. This allows them to monitor the organization’s work for years and gain access to sensitive information at will. If malicious activity within a corporate network is suspected, the prudent course of action is to contact the Doctor Web virus laboratory for qualified help. Prompt countermeasures will significantly reduce any actual damage and prevent further detrimental consequences of targeted attacks.

Indicators of compromise.