Defend what you create

Other Resources

Close

Library
My library

+ Add to library

Contact us
24/7 Tech support | Rules regarding submitting

Send a message

Your tickets

Profile

Back to news

Study of targeted attacks on Russian research institutes

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.

#drweb

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:

#drweb

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

#drweb

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
#drweb #drweb
Function for getting information about disks
#drweb #drweb
Function for listing files in a folder
#drweb #drweb
Function for collecting information about files in a folder
#drweb #drweb

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.

#drweb

Search for a proxy in the own log file:

#drweb

Search in active connections:

#drweb

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.

#drweb

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.

#drweb

Intersections in the network infrastructure

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

#drweb

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.

BackDoor.Mikroceen.11 BackDoor.Logtu
id Id id id
ce21f798119dbcb7a63f8cdf070545abb09f25ba intl0113 029735cb604ddcb9ce85de92a6096d366bd38a24 intpz0220
0eb2136c5ff7a92706bc9207da32dd85691eeed5 hisa5.si4 7b652e352a6d2a511f226e4d0cc22f093e052ad8 retail2007
2f80f51188dc9aea697868864d88925d64c26abc josa5w5n 1c5e5fd53fc2ee778342a5cae3ac2eb0ac345ed7 retail
2e50c075343ab20228a8c0c094722bbff71c4a2a enc0225 00ddcc200d1031b8639026532c0087bfcc4520c9 716demo
3bd16f11b5b3965a124a6fc3286297e5cfe77715 520299 b599797746ae8ccf7907cf88de232faa30ec95e6 gas-zhi
5eecdf63e85833e712a1ff88df1341bbf32f4ab8 Strive 2d672d7818a56029b337e8792935195d53576a9d jjlk
bd308f4d1a32096a3b90cfdae45bbc5c13e5e801 R0916
b1be4b2f874c8309f553acce90287c8c6bb2b6b1 frsl.1ply
21ffd24b8074d7cffdf4cc339d1fa8fe892eba27 Wdv
8fbec09e646311a285aee06b3dd45ccf58928703 intz726
19921cc47b3de003186e65fd12b82235030f060d 122764
0f70251abc8c64cbc7b24995c3d32927514d0a4b V20180224
149947544ca4f7baa5bc3d00b080d0e943d8036b SOE
e7f5a33b33e023a82ac9eee6ed40e4a38ce95277 int815
b4790eec7daa9f931bed43a53f66168b477599a7 UOE
ab660a3ac46d563c756463bd1b64cc45f347a1f7 B.Z11NOV20D
d0181759a175fbcc60975983b351f88970f484f9 299520
7a63fc9db2bc1e9b1ef793723d5877e6b4c566b8 WinVideo
13779006d0dafbe4b27bd282230df299eef2b8dc SSLSSL
f53c77695a162c78c68f693f57f65752d17f6030 int007server
924341cab6106ef993b506193e6786e459936069 intl1211
8ebf78c84cd7f66ca8708467a28d83658bcf6710 intl821
f2856d7d138430e164f83662e251ee311950d83c intl821

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):

#drweb

BackDoor.Mirkoceen.11 example (81bb895a833594013bc74b429fb1f24f9ec9df26):

#drweb

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.

Tell us what you think

To ask Doctor Web’s site administration about a news item, enter @admin at the beginning of your comment. If your question is for the author of one of the comments, put @ before their names.


Other comments

The Russian developer of Dr.Web anti-viruses
Doctor Web has been developing anti-virus software since 1992
Dr.Web is trusted by users around the world in 200+ countries
The company has delivered an anti-virus as a service since 2007
24/7 tech support

Dr.Web © Doctor Web
2003 — 2021

Doctor Web is the Russian developer of Dr.Web anti-virus software. Dr.Web anti-virus software has been developed since 1992.

2-12А, 3rd street Yamskogo polya, Moscow, Russia, 125124