# Study of targeted attacks on Russian research institutes ----- **© Doctor Web, Ltd., 2021. All rights reserved.** This document is the property of Doctor Web, Ltd. (hereinafter - Doctor Web). No part of this document may be reproduced, published or transmitted in any form or by any means for any purpose without proper attribution. Doctor Web develops and distributes Dr.Web information security solutions which provide efficient protection from malicious software and spam. Doctor Web customers can be found among home users from all over the world and in government enterprises, small companies and nationwide corporations. Dr.Web antivirus solutions are well known since 1992 for continuing excellence in malware detection and compliance with international information security standards. State certificates and awards received by the Dr.Web solutions, as well as the globally widespread use of our products are the best evidence of exceptional trust to the company products. **Study of targeted attacks on Russian research institutes** **4/2/2021** Doctor Web Head Office 2-12A, 3rd str. Yamskogo polya Moscow, Russia 125124 Website: www.drweb.com Phone: +7 (495) 789-45-87 Refer to the official website for regional and international office information. ----- ## Table of Contents ###### Introduction 4 Who’s behind the attacks? 5 Comparative code analysis of BackDoor.DNSep.1 and BackDoor.Cotx.1 7 Comparative code analysis of the Skeye, Mikroceen and Logtu backdoors 15 Conclusion 23 Operating Routine of Discovered Malware Samples 24 **BackDoor.Skeye.1** **24** **BackDoor.DNSep.1** **33** **BackDoor.Remshell.24** **39** **BackDoor.Farfli.130** **41** **Trojan.Mirage.12** **42** **BackDoor.Siggen2.3268** **48** ###### Appendix 1. Indicators of compromise 58 ----- ### 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](https://www.fireeye.com/blog/threat-research/2019/06/government-in-central-asia-targeted-with-hawkball-backdoor.html) 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.](https://vms.drweb.com/search/?q=BackDoor.PlugX&lng=en) 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](https://www.ptsecurity.com/ww-en/analytics/operation-taskmasters-2019/) 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](https://www.proofpoint.com/us/threat-insight/post/chinese-apt-operation-lagtime-it-targets-government-information-technology) support this conclusion: 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. The latter is a known tool of TA428. 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](https://vms.drweb.ru/virus/?i=21517232&lng=en) [BackDoor.Mikroceen.11.](https://vms.drweb.ru/virus/?i=21512308&lng=en) ### 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 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. ----- ----- ----- ----- ----- ----- ----- 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 the BackDoor.Mikroceen.11 samples.** **Logging functions** Logging in all cases is obfuscated. - BackDoor.Mikroceen.11—messages in the %d - %d-%d %d:%d:%d \r\n format is written to the %TEMP%\WZ9Jan10.TMP file, where 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] ``` \n\n\n format before writing to the %TEMP% \rar.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\t\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; and - 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 the 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. |BackDoor.Mikroceen.11|Col2|BackDoor.Logtu.1|Col4| |---|---|---|---| |SHA1|Id|SHA1|id| |ce21f798119dbcb7a63f8cdf0 70545abb09f25ba|intl0113|029735cb604ddcb9ce85de92 a6096d366bd38a24|intpz0220| ----- |0eb2136c5ff7a92706bc9207d a32dd85691eeed5|hisa5.si4|7b652e352a6d2a511f226e4d 0cc22f093e052ad8|retail2007| |---|---|---|---| |2f80f51188dc9aea697868864 d88925d64c26abc|josa5w5n|1c5e5fd53fc2ee778342a5cae 3ac2eb0ac345ed7|retail| |2e50c075343ab20228a8c0c0 94722bbff71c4a2a|enc0225|00ddcc200d1031b863902653 2c0087bfcc4520c9|716demo| |3bd16f11b5b3965a124a6fc3 286297e5cfe77715|520299|b599797746ae8ccf7907cf88d e232faa30ec95e6|gas-zhi| |5eecdf63e85833e712a1ff88df 1341bbf32f4ab8|Strive|2d672d7818a56029b337e879 2935195d53576a9d|jjlk| |bd308f4d1a32096a3b90cfdae 45bbc5c13e5e801|R0916||| |b1be4b2f874c8309f553acce9 0287c8c6bb2b6b1|frsl.1ply||| |21ffd24b8074d7cffdf4cc339d 1fa8fe892eba27|Wdv||| |8fbec09e646311a285aee06b3 dd45ccf58928703|intz726||| |19921cc47b3de003186e65fd1 2b82235030f060d|122764||| |0f70251abc8c64cbc7b24995c 3d32927514d0a4b|V20180224||| |149947544ca4f7baa5bc3d00 b080d0e943d8036b|SOE||| |e7f5a33b33e023a82ac9eee6e d40e4a38ce95277|int815||| |b4790eec7daa9f931bed43a5 3f66168b477599a7|UOE||| |ab660a3ac46d563c756463bd 1b64cc45f347a1f7|B.Z11NOV20D||| |d0181759a175fbcc60975983b 351f88970f484f9|299520||| ----- |7a63fc9db2bc1e9b1ef793723 d5877e6b4c566b8|WinVideo|Col3| |---|---|---| |13779006d0dafbe4b27bd282 230df299eef2b8dc|SSLSSL|| |f53c77695a162c78c68f693f57 f65752d17f6030|int007server|| |924341cab6106ef993b506193 e6786e459936069|intl1211|| |8ebf78c84cd7f66ca8708467a 28d83658bcf6710|intl821|| |f2856d7d138430e164f83662e 251ee311950d83c|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):** **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. ----- ### Operating Routine of Discovered Malware Samples #### BackDoor.Skeye.1 A backdoor written in C and designed to operate in the 64-bit versions of Microsoft Windows operating systems. It is used for targeted attacks on information systems, collecting information about the infected devices and remotely controlling them by launching cmd.exe and redirecting the I/O to the attacker's C&C server. The malicious module’s original name is sk.exe. The backdoor’s code has similarities with the code of Mikroceen and Logtu malware. ##### Operating routine It has one exported function DllEntry of the following structure: ----- When running the sample as an EXE file, only the malmain function is run. The backdoor writes the event log to the %TEMP%\\wcrypt32.dll file containing the date and time of the message; but instead of the readable message, the program logs its code. The table below shows the message codes decryption. |code|arg|msg| |---|---|---| |4|0|Backdoor launch| |5|Error code|Error upon process launch| |10|botid|A new botid is received from the server| ----- |16|0|Proxy settings for the current user are received| |---|---|---| |17|0|Proxy settings for the current user are not received| |18|0|Proxy settings for the active user are received| |19|0|Proxy settings for the active user are not received| |20|Error code|Error while receiving SID of the active user| |32|Attempt number|Attempting to check the availability of the server| |65|status code|A code other than 200 is received while the command is requested.| |66|Attempt number|Failed to request a command| |67|status code|Attempting to check the availability of the server| |68|0|The proxy flag is not set in the system settings| |70|Error code|Failed to connect to the C&C server| |71|Error code|Request creation error| |72|Error code|Request transmission error| |100 + cmdid|0|Execution command received| |153|Error code|Failed to obtain the status code for the sent request| |256|Attempt number|Attempting to request an execution command| ----- The backdoor initializes the list of commands it can execute upon operation. This is followed by the initial check for any debugging processes—the backdoor checks the ``` BeingDebugged flag in the PEB (Process Environment Block). If there is a debugging process, ``` the backdoor closes. Next, it creates a test0 or test0_cu mutex in case it is not run from NT ``` AUTHORITY/SYSTEM. If the specified mutex already exists, the backdoor terminates. ``` It then reads the bot ID from the file %TEMP%\\test0.dat. An 8-byte encryption key is initialized based on the bot ID. ----- Next, BackDoor.Skeye.1 begins operation with the C&C server. Before sending requests, it again checks whether the sample debugging process is present. This time, using the ``` NtQueryInformationProcess function it checks ProcessDebugPort, ProcessDebugObjectHandle and ProcessDebugFlags. If the backdoor spots the ``` debugging process, it closes. The requests use the User-Agent string: ``` Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2). ``` When connection to the C&C server, the backdoor first sends a GET request to check the availability of the server; the sample contains two sets (server-port) of the C&C addresses. ``` hxxps://atob.kommesantor.com/?t=%d&&s=%d&&p=%s&&k=%d, where t parameter is ``` the bot ID, s is session number, p is dut6@bV0 string, and k is the result of the ``` GetTickCount() function. ``` If the response is code 200, it means the server connection has been successfully established, and the backdoor requests an execution command. If the response is code 403, the program tries to repeat the request, while it enters www.mail[.]ru in the Host HTTP header instead of entering the C&C address. If the code 200 still cannot be obtained, the backdoor then checks the second C&C server. In case of repeated failure, it waits for a few seconds and then makes another attempt. A GET request with the address hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=% ``` d is used to request the command, where e is null, t is the bot ID, and k is the result of the GetTickCount() function. ``` ----- If the response is the code 200, the cookie of that response contains the ID of the command to be executed, and the response data is encrypted with an XOR operation with an 8-byte key based on the bot ID. A POST request with the address hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=% ``` d is used to send back the results, where e is the command ID, t is the bot ID, and k is the result ``` of the GetTickCount() function; the result of the request is transmitted as data encrypted by an XOR operation with an 8-byte key based on the bot ID. Command list |Command id|Resulting action| |---|---| |1|To set a new botid| |16|To idle| |17|To send information about the infected system| |18|To launch a process| |19|To launch a process and send its output| |20|To run the command shell with I/O redirecting to pipes| |21|To close the command shell| |22|To send the command shell output| |23|To launch its file with the stop parameter| |24|To terminate the backdoor operation| |48|To run the file manager| |64|To send the information about disks| |65|To send the directory listing| |66|To delete a file| |67|To move a file| |80|To send a process list| |81|To terminate a process| |85|To send a service list| ----- |86|To launch a process| |---|---| During the investigation of the related targeted attack, the following servers were found: ``` atob[.]kommesantor[.]com term[.]internnetionfax[.]com rps[.]news-click[.]net ``` All three domains are resolved to 103.97.124[.]193. **Other modifications of the Skeye backdoor** Another uncovered backdoor sample (0b33a10c0b286c6ffa1d45b261d8a338) has been added to Dr.Web database as BackDoor.Skeye.2. The key differences of this modification are: - Exported functions are absent. - The sample runs as a service, installing or deleting itself, depending on the arguments it is running with (install, uninstall, without arguments). ----- The malmain function is also run from ServiceMain; - The bot ID is read from the file %TEMP%\Date, but the encryption key is generated in the same manner. - The configuration (mutex name, server address, port, and proxy) is encrypted with the XOR operation with the key 0xB7. www2.morgoclass[.]com is the C&C address. The port is 443. ----- - The protocol of communication with the C&C server is binary. The connection is made via a TCP socket. After connecting to the server, the backdoor sends an 8-byte packet: the first 4 bytes are the bot ID, the second 4 bytes are zeros. Receiving a response from the server is performed in 2 stages: first, a packet with the length of the data (header) is received, then the data itself is received and decrypted. The header structure is the following: ``` struct packet_header { BYTE marker; DWORD cmd_id; DWORD size; } ``` With that, the marker field must be equal to 0xFF. The data is sent to the server by a single call to send with the same header. - This sample does not include all the commands described in the first sample (a259db436aa8883cc99af1d59f05f4b1d97c178b). Commands 80, 81, 85, and 86 are absent - There are differences in the event log message codes. Codes 10, 65-68, and 70-72 are absent. The event log message codes are shown in the table. |The message code|Code|Description| |---|---|---| |0|argc|Written at the beginning of main| |2|0|The backdoor is launched with the install command (installing the service)| |3|0|The backdoor is launched with the uninstall command (deleting the service)| |9|0|An unhandled exception occurred, the program will restart| |21|0|Successful connection to the proxy server| ----- |The message code|Code|Description| |---|---|---| |22|0|Failed to connect via proxy (no addresses from the registry or SID of the active user were received)| |23|Error code|Error at the proxy server connection| |24|Error code|Failed to connect to the C&C server without proxy| |25|Error code|Failed to send a packet to the C&C server| |26|Error code|No answer from the C&C server| |48|command ID|A received command. It is written to the log 2 times| |257|0|Failed to connect to the C&C server| |258|0|Failed to send an initial packet (bot ID)| |cmd_id+10000|0|Command ID + 10000. It is recorded immediately after receiving and decrypting the command| It is worth noting that the two samples use different sets of codes to log the connection to the C&C server. In the first case, these are the codes 70-72, while the connection to the server is made via HTTP. In the second case, these are the codes 24-26, and the connection is made via a socket. #### BackDoor.DNSep.1 A backdoor written in C and C++ and designed to run on 32- and 64-bit Microsoft Windows operating systems. Its main purpose is to provide a communication channel with the C&C server through DNS requests and facilitate unauthorized control over the infected computer. It consists of a malicious loader (a .DLL library), and the main module operating in RAM. Its code has multiple overlaps with the Cotx backdoor. ----- ##### Operating routine The malware is a DNS backdoor. C&C server communication occurs by reading the TXT records of subdomains formed in a certain way. **Loader module** The original name in the export table is Stager.dll. The library has a number of exported functions. With that, most of the functions do not perform any actions. The only working function is ``` InitLoad, where the backdoor is launched. The same function is called from DllMain. ``` The backdoor unpacks the payload from its resources. It is located in the DAT resource compressed through RtlCompressBuffer. In the unpacked main module, the loader searches for the CQKUZXadCXS string, which is a plug for the configuration. After the string is found, the loader replaces it with the current configuration. In the analyzed sample, this string is ``` AB1d3d3MS5kb3RvbWF0ZXIuY2x1Yjsw. ``` Next, the %WINDIR%\\System32\\dllhost.exe process is launched, where the main module is then injected. If the third character in the configuration is 0, both the executable file of the process in the context of which the loader operates and the file of the loader itself are deleted. ----- **The main module operation** The main module is written in C++, with extensive use of the STL library. At the beginning, the backdoor verifies the embedded configuration that was earlier replaced by the loader. If the first two characters do not match AB, it considers the configuration to be absent, so it stops running. Otherwise, it decodes the configuration from Base64, starting from the 4th character: www1.dotomater.club;0. The configuration format is simple and represents a domain of the C&C server and the IP address of the DNS server, which are separated by a semicolon. If the DNS server address is not specified or specified as null, the backdoor uses the DNS servers used by the infected computer. ----- Next, the backdoor creates several threads. The first is used to send heartbeat packets. In response, the C&C server sends the heartbeat%d string where %d is the same number from the packet sent by the bot. The second thread is used to parse the packets queue and send them to the C&C server. After that, it transmits the information about the infected system: ``` sprintf(Str, "%s;%s;%s;%d;%s", szCompName, szUserName, szOSVer, isx64, szCurDateTime);. ``` ----- Next, the backdoor enters the cycle of receiving and processing commands from the C&C server. **Command code** **Command description** 1 Set bot ID 2 Run the command shell and redirect the I/O to the pipes 3 Execute the command in the previously launched shell (command No.2) 4 Get information about the disk or directory listing 6 Send file to the C&C server 7 Copy a file 8 Delete a file 9 Get information about the file size 10 Save file to the specified path 11 Change the interval of C&C server communication 13 Self-deletion **C&C server communication protocol** From the data sent to the C&C server the following structure is initially formed: ``` #pragma pack(push, 1) struct st_packet { _BYTE magic; // 0x65 _WORD botid; _DWORD pktid; _BYTE data[]; }; #pragma pack(pop) ``` - botid initially has the 0 value, but it changes upon the C&C server command, containing ``` opcode == 1, which is sent as a response to the information about the infected system; ``` - pktid has the initial value 0, but it changes upon receiving each packet from the C&C server; - data contains the packet data, including command ID. |Command code|Command description| |---|---| |1|Set bot ID| |2|Run the command shell and redirect the I/O to the pipes| |3|Execute the command in the previously launched shell (command No.2)| |4|Get information about the disk or directory listing| |6|Send file to the C&C server| |7|Copy a file| |8|Delete a file| |9|Get information about the file size| |10|Save file to the specified path| |11|Change the interval of C&C server communication| |13|Self-deletion| ----- The received packet is encrypted with the following function: The dadadadadadadada string is sent into this function as a key. The received encrypted data is coded with Base64. From the encrypted data the subdomain name for the domain, listed in the configuration, is formed. With that, if the length of the encoded data exceeds 62 symbols, the dot is added after each 62nd symbol. Next, the DNS request to receive TXT records of the formed domain is made. The response from the C&C server is decrypted the same way. First, it is decoded from Base64, followed by decryption with the dadadadadadadada key. The resulting data is: ----- #### BackDoor.Remshell.24 A backdoor written in C and designed to operate in the 32-bit versions of the Microsoft Windows operating systems. It allows attackers to remotely control infected computers by implementing remote shell functions—launching cmd.exe and redirecting the I/O to the attacker's C&C server. The malicious module’s original name is client_dll.dll. ##### Operating routine The library has one exported function that implements the main functionality of the backdoor: ``` ServiceMain. ``` At the beginning of the operation, the backdoor creates a mutex to exclude the simultaneous launch of its copy. It then decrypts the strings with an XOR operation with the byte 0x0F. List of decrypted strings: ``` Mozilla/4.0 (compatible; MSIE 10.0; Windows NT 6.2;+SV1; ns02.ns02.us//0xD.html /webdav/0.htm /webdav/%s.htm %02d%02d -download Download OK! Download failed... -pslist -pskill -upload Upload OK! Upload failed... Process is Killed! Process killed failed. -exit cmd.exe /c ``` The URL ns02[.]ns02[.]us//0xD.html is hardcoded in the body of the backdoor that locates both primary C&C servers. After decrypting the strings, BackDoor.Remshell.24 uses the %02d%02d format to store the current minutes and seconds. These values are then used in requests to the C&C server. Next, a separate thread is started in which, in an infinite loop, the program attempts to obtain or update the address of the second-level C&C server. When the address of the secondary C&C server is received, the backdoor starts a thread in which it sends heartbeat requests to this server. ----- The backdoor then periodically requests commands from the C&C server and executes them. **Obtaining the address of the secondary C&C server** To get an address, a GET request is sent to the URL specified in the configuration. In response, the server sends the string -set or -SET , where is either a number or an IP address. The resulting number is interpreted as the interval for accessing the URL specified in the configuration. If an IP address is received, the backdoor adopts it as a secondary C&C server. It is worth noting that the thread does not stop working when it receives the valid address of the C&C server. It continues to work, which allows one to change the C&C server addresses without restarting the backdoor. **Protocol for communicating with the secondary C&C server** At the beginning of the data sent by the PUT request, the backdoor appends a header consisting of 5 bytes, which is a string formed according to the format %02d%02d. The minute and second values representing when the request was formed are substituted in this string. With that, the request and response data are encrypted. The value of each sent byte of the request data is reduced by 0x7F, and each received byte is increased by 0x7F. As heartbeat requests, a PUT request is sent to /webdav/0.htm with data containing the name of the infected computer and the values of the minute and second when the backdoor was launched. To request commands from the C&C server, the backdoor sends a GET request to ``` /webdav/O.html. It then decrypts the server’s response and parses it for ``` commands. Commands list |Command|Description| |---|---| |-download|To download a specified file| |-exit|To terminate the backdoor operation| |-pskill|To terminate a specified process| |-pslist|To form a list of processes| |-upload|To send a specified file to the server| |others|Other commands are launched via cmd.exe /c| ----- Responses to commands are sent by PUT requests to /webdav/.htm, where is the values of the minute and second when the backdoor was launched. #### BackDoor.Farfli.130 A malicious .DLL library written in C++ and supports the 32- and 64-bit Microsoft Windows operating systems. It is a backdoor that allows attackers to remotely control infected computers via the remote shell―by running cmd.exe and redirecting input-output to their C&C server. ##### Operating routine Its original name from the export table is state.dll. It has the Cja and ServiceMain exported functions. The C&C server address is eye[.]darknightcloud[.]com:443. This malware is based on the publicly available Gh0st backdoor source code. Compared to the original program, BackDoor.Farfli.130 has noticeably fewer capabilities, but also has several specific features. In this regard, this description will only cover the essential differences from the classic Gh0st RAT. The C&C server address is encoded with Base64 and encrypted with a simple algorithm: Other encrypted strings are decrypted by subtracting 1 from each byte of the string. The infected computer ID is stored in the %APPDATA%\wins.tmp file instead of the system registry. The traffic between the backdoor and C&C server is encrypted using the RC4 algorithm with the following key: ``` b25lIGluIHRvIE5ldyBZb3JrIHRoYXQgbW9ybmluZyBmb3IgdGhpcyBmZW5jaW5nIG1lZ XQgd2l0aCBNY0J1cm5leSBTY2hvb2wuIE9ubHksIHdlIGRpZG4ndCBoYXZlIHRoZSBtZW V0LiBJIGxlZnQgYWxsIHRoZSBmb2lscyBhbmQgZXF1aXBtZW50IGFuZCBzdHVmZiBvbiB 0aGUgZ29kZGFtIHN1YndheS4gSXQgd2Fzbid0IGFsbCBteSB. ``` ----- The BackDoor.Farfli.130 functionality is limited to the following: - Obtaining information about storage discs - Receiving the process list - Launching the command shell and redirecting input-output to the C&C server - Shutting down the computer - Setting the ID of the infected computer #### Trojan.Mirage.12 **Trojan.Mirage.12 is a multi-component backdoor trojan written in C++ with the use of the** Active Template Library (ATL) and designed for Windows 32- and 64-bit operating systems. It is used to facilitate unauthorized control over infected computers and enabling access to information stored on them. The trojan is a COM server that operates in RAM within the system process. ##### Operating routine The trojan only operates if it is loaded into either the explorer.exe or regsvr32.exe process. This is due to the specifics of the sample’s operation. The trojan is registered in the system via regsvr32.exe, and its execution takes place in the context of explorer.exe. When running through regsvr32 (with the key /i or without keys), the DllRegisterServer function exported by the trojan is called, which registers its COM interface in the system: ----- where is the path to trojan’s file and is its home directory. The trojan enables its autorun also via regsvr32: ``` [\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconO verlayIdentifiers\ServerShellIcon] '' = '{D8956119-6E66-43BD-AAA5231F94859EE6}'. ``` Thus, the process explorer.exe will load the trojan on the next restart. **Main functionality** The trojan begins performing the primary functions either by calling the exported function ``` DllUnregisterServerA, or by loading the process explorer.exe. The difference is that when ``` ----- loading by the process explorer.exe, the trojan creates a FEca72d-abc-efef mutex to prevent another copy from running simultaneously. Next, it reads its configuration from the [HKCU\\Software\\Microsoft\\Keyboard\ ``` \Set] 'HPConf’ registry key. If the specified key does not exist or the configuration stored in ``` the registry does not match the hardcoded configuration, it uses the hardcoded configuration and writes it to the registry. The configuration in the registry and in the trojan’s body is stored in encrypted form: the RC4 algorithm is used for encryption. The encryption key is hardcoded in the trojan body: ``` 13 36 CF 83 2E CC 79 DF 2E AB 79 64. ``` Decryption function: The decrypted configuration has the following structure: ----- In the hardcoded configuration, the fields compname_sum and compname have null values. As the trojan decrypts it, it assigns values to these fields, then encrypts the already updated configuration and writes it to the registry. compname_sum is calculated based on the computer name: Next, the trojan loads the available plug-ins. To do so, it checks whether the %APPDATA%\ ``` \Microsoft\\Media Player folder is present. If it exists, the trojan searches for libraries ``` with two exported functions—GetValue and PluginEntryPoint. For each located library, ``` PluginEntryPoint, and then GetValue are called sequentially. The second function returns ``` the handle of the thread that the trojan is waiting for to complete. After the thread is terminated, the library file is unloaded from the process and deleted. The sleep_time configuration parameter can contain two dates (year, month, day, hour, and minute) that define the time period when the trojan does not communicate with the C&C server. If the current date and time do not fall within this interval or this parameter is not set, the trojan communicates with the C&C server. ----- **Communication with the C&C server** The trojan configuration can contain up to two C&C server’s addresses. Each server has a specified domain and port. The configuration can also specify the URL to which the trojan sends requests to get the control domain address—fallback_url. All requests to the C&C server contain the bot ID: The trojan can send two types of requests: 1. A POST request with URI /result?hl=en&meta=, where botid is the bot ID. The request data is encrypted using the same algorithm as the configuration. 2. A GET request with URI /search?hl=en&q=&meta=, where botid is the bot ID, and data is the request data encrypted in the same way as the configuration, and then encoded in Base64 and urlencode. A POST request is only used to send a file from an infected computer to the C&C server if the size of the data being sent exceeds 528 bytes. The requests use the User-Agent string: Mozilla/4.0 (compatible; MSIE 6.0; ``` Win32). ``` To check the C&C server’s operability, the trojan sends the st_pkt_hello packet: ``` struct st_pkt_hello { _DWORD rnd; _DWORD cmdid; // 0x10001000 _BYTE gap[36]; // 0x00 }; ``` where rnd is a random number. If the server responds to this request, the trojan uses this server for further work. If none of the servers specified in the configuration work, the trojan sends a ``` Get request (just like that, not GET) to the specified URL. In response, it expects to obtain the ``` C&C server’s address, encrypted according to the same algorithm as the trojan configuration. The address obtained in this way is then checked for operability in the same way—using the ``` st_pkt_hello packet. ``` ----- When the trojan finds the C&C server, it starts periodically requesting commands. The packet for the command request is the following: ``` struct st_pkt_req_cmd { _DWORD rnd; _DWORD cmdid; // 0x10001001 _DWORD compname_sum; char compname[16]; _BYTE gap[16]; // 0x00 }; ``` where rnd is a random number, compname_sum is the number derived from the computer’s name, and compname is the computer’s name. If the server responded with the *NONE* string, the trojan ignores the "silent" time specified in the configuration and repeats the request. If the received response is different from *NONE*, the trojan saves this data to the %APPDATA%\\jbl file. This file is then decrypted (using the same algorithm as the configuration) and divided into commands. The trojan determines the command to execute based on its first three characters: ``` opcode = cmdbuf[2] ^ (cmdbuf[1] * cmdbuf[0]); ``` Command list |Command id|cmd|Description| |---|---|---| |0x2718|del|To delete a file| |0x28D7|get|To send the current configuration to the server| |0x2A43|cmd|To run the command in the command shell and send the result to the server| |0x2B2B|dow|To send a specified file to the server| |0x2C89|sde|To change the time interval for connection to the server| |0x2C97|rem|Self-deletion| |0x2D7E|wai|To idle for a specified period of time| |0x2EB5|loa|To launch the trojans plug-in| |0x2F3D|exe|To open a file| |0x30E1|sle|To set the inactivity period for the trojan| ----- |0x322A|unl|To unload a plug-in and delete it from the disk| |---|---|---| |0x3353|upc|To update the configuration| |0x3354|upd|To request and install malicious module updates| |0x335C|upl|To get a file from the server and save it to the specified path| #### BackDoor.Siggen2.3268 A backdoor written in C++ and designed to run on 32- and 64-bit Microsoft Windows operating systems. The functionality of the 32-bit and 64-bit versions is identical. The backdoor is linked to the OpenSSL library, which implements AES- and RSA-based encryption, as well as key generation. It is used in targeted attacks on information systems to gain unauthorized access to data and transferring it to C&C servers. In the infected system, the sample was located in ``` System32 as a DLL named ssdtvrs.dll. It was installed by the ssdtvrs service. This description ``` is based on the 64-bit version. ##### Operating routine It exports the service entry point ServiceMain. Once launched, the backdoor registers a function that handles control requests, creates a thread in which it performs the main functions, and then waits in a loop for the service to stop. ----- **The main thread** First, it prepares a configuration that can be stored both in the registry of the infected computer and in the body of the backdoor. It then decrypts the name of the registry key ``` Software\Microsoft\Internet Explorer\Security. ``` The backdoor checks the presence of this key first in the HKCU section, then in the HKLM section of the registry. Then, it loads the encrypted configuration from a parameter whose name matches the name of the malicious DLL file (in this case, ssdtvrs). If the configuration is not in the registry, the backdoor uses the hardcoded one. The configuration is encrypted with RC4 and the key is generated using the following algorithm: The configuration is stored as a sequence of blocks. BYTE BYTE BYTE[item_len] item_id item_len item_data The backdoor parses all the blocks in turn and saves the resulting configuration as a structure: |BYTE|BYTE|BYTE[item_len]| |---|---|---| |item_id|item_len|item_data| ----- After preparing the configuration, BackDoor.Siggen2.3268 checks that the current system time ranges between cfg.time_1 and cfg.time_2, and waits until this condition is met. It then prepares and sends the registration packet to the C&C server. First, it creates an object of the SBC02DEFE6 class (RTTI structures remained in the backdoor). This object contains another object that stores connection information, and also encapsulates the AZ092342345 object, which is responsible for data encryption. After creating the SBC02DEFE6 object, the backdoor attempts to hinder the debugging process by closing a deliberately incorrect handle. The exception that occurs is processed; and if the debugger is not present, the backdoor continues to operate. ----- After that, the cfg.C2_index_0x0D parameter is checked, according to which a specific C&C server is selected from the configuration. The following addresses are hardcoded in the configuration: - 144.34.145.168 - snow.swingfished[.]com The backdoor then creates a TCP socket to connect to the server, and then prepares the encryption keys. The backdoor has a hardcoded public RSA key, which is encrypted with the same algorithm that is used to encrypt the registry key that stores the configuration. The decrypted RSA key is shown below. ----- After that, the backdoor generates a random "p" After the sysinfo structure, a random sequence of 0 to 255 bytes is appended. After sending the system information, an object of the KCPOI982S class is created to process commands from the C&C server. The main purpose of this object is to check the command ID and create another object designed to handle a specific command. The KCPOI982S object and other command handler objects are inherited from the AM1876234af3 class, which contains only an event descriptor for synchronization and a reference to the SBC02DEFE6 object for managing the connection. ``` KCPOI982S creates separate threads for each command and stores an array of descriptors of ``` these threads and interrupts them in its destructor. ----- **Processing the C&C server’s commands** The command ID is contained in the 1st byte of the packet payload sent by the server (after decryption and unpacking). |id|Name of the handler object|Description| |---|---|---| |0x10|BCJI09RUC|To send a list of processes The following structure is formed for each process: struct process_info { BYTE id; //0x73 DWORD PID; char sz_ExeFile[x]; char sz_exe_full_path[x]; }| |0x15|AS01243895|To create a command shell from cmd.exe. The backdoor runs cmd.exe with StdIn,StdOut,StdErr redirection to pipes. It then sends a packet with the 0x76 byte in the payload. After that, it attempts to read the result from the pipe and send it to the server in a loop.| |0x01|AF434faf845|To send information about all disks (iterates through the letters, except A and B). The following structure is formed for each disk: struct drive_info { BYTE id; //0x67 BYTE drive_type; DWORD total_kbytes; DWORD kbytes_available; char sz_type_name[x]; //szTypeName field of the SHFILEINFOA structure after SHGetFileInfoA call (eg, Local Disk) char sz_filesystem_name; }| |0x20|AC92784f908234|To send the configuration to the C&C server. The packet’s payload is represented as the following structure: struct config_packet { BYTE id; //0x77| ----- |Col1|Col2|cfg config; }| |---|---|---| |0x00|-|To reset the connection| **Artifacts** **BackDoor.Siggen2.3268 contains numerous debugging strings and the links are missing.** ----- ### Appendix 1. Indicators of compromise ##### SHA1 hashes **BackDoor.Skeye** a259db436aa8883cc99af1d59f05f4b1d97c178b: acess.exe b0ff476e3a273af600840d0f3dcd099274035e76: skeye.exe ----- **BackDoor.DNSep.1** 14a652b5b9d71171224541ce2b950cf55da38190: ccL100U.dll f76ae6ee508cf22f52b8533d704667a1893860d9: (payload) **BackDoor.RemShell.24** fffec74a6330e25f97b687f989bb287aeb5fbb76: ftps.dll **BackDoor.Siggen2.3268** bfa1e457afbb1f160094f65b456503b64832d249: ssdtvrs.dll ce3fc5b40231b5a9dd4aeeb0f0c7ef6f7779c53e: ssdtvrs.dll **BackDoor.Farfli.130** b33e65fd1790260ad47a0dbdad2f12f555a0d6ca: Irmon32.dll **Trojan.Mirage.12** fc698eb0d7d6948605a7e5ba6708752b691a3fec: dnvdisp32.dll **BackDoor.PlugX.67** ad5fc8dfe8341d08c118abe72caa7cc8d40efa11: mcutil.dll.bbc ##### Domains www2[.]morgoclass[.]com term[.]internnetionfax[.]com atob[.]kommesantor[.]com rps[.]news-click[.]net www1[.]dotomater[.]club ns02[.]ns02[.]us snow[.]swingfished[.]com ----- skype[.]swingfished[.]com dog[.]darknightcloud[.]com eye[.]darknightcloud[.]com home[.]sysclearprom[.]space tick[.]sysclearprom[.]space atlas[.]golianbooks[.]com dm[.]golianbooks[.]com ##### IP 103.97.124[.]193 103.91.67[.]251 144.34.145[.]168 185.70.185[.]231 45.76.34[.]147 -----