# Study of the Spyder modular backdoor for targeted attacks ----- **© 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 the Spyder modular backdoor for targeted attacks** **3/4/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 Main features 5 Conclusion 8 BackDoor.Spyder.1 operating routine 8 Addendum No. 1 CA_cert information (certificate for establishing a connection with the C&C server) 28 Addendum No. 2. List of 32-bit modification debug messages 30 Addendum No. 3. Indicators of compromise 33 ----- ### Introduction In December 2020, the Doctor Web virus laboratory was contacted by a telecommunications company based in Central Asia after its employees discovered suspicious files on their corporate network. During the examination, our analysts extracted and studied a malicious sample, which turned out to be one of the backdoors used by the hacker group known as Winnti. We already came across the malware Winnti uses when we studied the ShadowPad backdoor samples that we found in the compromised network of a state institution in Kyrgyzstan. In addition, earlier in the same network, we found another specialized backdoor called PlugX, which has many intersections with ShadowPad in the code and network infrastructure. A [separate material was devoted to the comparative analysis of both families.](https://news.drweb.com/show/?lng=en&i=14048) In this study, we analyze the uncovered malicious module, explore its algorithms and features, and define its connection with other well-known tools of the Winnti APT group. ----- ### Main features On the infected device, the malicious module was located in the system directory C: ``` \Windows\System32 as oci.dll. Thus, the module was prepared for launch by the MSDTC ``` (Microsoft Distributed Transaction Coordinator) system service using the DLL Hijacking method. According to our data, the file got to the computers in May 2020, but the method of initial infection remains unknown. The Event Log contained records of the creation of services designed to start and stop MSDTC, as well as for the backdoor execution. ----- We also found traces of other services running that had random names. Their files were located in directories like C:\Windows\Temp\\, where random1 and ``` random2 are strings of random length and random Latin characters. At the time of the study, ``` these services’ executable files were missing. An interesting find was a service that indicates the use of a smbexec.py utility for remote code [execution from the Impacket set. The attackers used this tool to establish remote access to the](https://github.com/SecureAuthCorp/impacket) command shell in a semi-interactive mode. The studied malicious sample was added to the Dr.Web virus database as BackDoor.Spyder.1. In one of the discovered Spyder samples, the debug logging functions and messages remained. Messages used when communicating with the C&C server contained the string "Spyder". ----- The backdoor is notable for a number of interesting features. First, oci.dll contains the main PE module, but with missing file signatures. Erasing the header signatures was presumably done to obstruct the backdoor detection in the device's memory. Secondly, the payload itself does not carry malicious functionality, but serves to load and coordinate additional plug-ins received from the С&С server. With these plug-ins, the backdoor performs its main tasks. Therefore, this family has a modular structure, just like the other backdoor families used by Winnti — the previously mentioned ShadowPad and PlugX. Analysis of Spyder's network infrastructure revealed a link to other Winnti attacks. In particular, the infrastructure used by the Crosswalk and ShadowPad backdoors described in the Positive [Technologies study corresponds with some of the Spyder samples. The graph below clearly](https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/higaisa-or-winnti-apt-41-backdoors-old-and-new/) shows the identified intersections. ----- ### Conclusion The analyzed sample of BackDoor.Spyder.1 is notable primarily because its code does not perform direct malicious functions. Its main tasks are to covertly operate within the infected system and establish communication with the control server and then wait for operator commands. At the same time, it has a modular structure that allows the operator to scale its capabilities, providing any functionality depending on the needs of the attackers. The plug-ins make the considered sample similar to ShadowPad and PlugX, which, together with the intersections in their network infrastructures, allows us to conclude that it is used by Winnti. ### BackDoor.Spyder.1 operating routine A backdoor written in C++ and designed to run on 64-bit Microsoft Windows operating systems. It is used for targeted attacks on information systems, collecting information about an infected device, loading functional malicious modules, coordinating their work, and providing communication with the C&C server. In the infected system, it exists as a DLL file and is loaded by the system service using the DLL Hijacking method. After injection, it functions in the computer's RAM. The backdoor is a malicious DLL file. The function names in its export table duplicate the exported functions of the apphelp.dll system library. ----- On the infected computer, the backdoor file was located in C:\Windows\System32\oci.dll catalog. The file’s original name from the export table is dll. It was loaded by the MSDTC system service using the DLL Hijacking method (Microsoft Distributed Transaction Coordinator Service). From a functional point of view, the sample is a loader for the main payload, which is stored in the .data section as a DLL, with some elements of the DOS and PE headers equal to zero. ----- **The loader operation** Loading is performed in a function designated as malmain_3 and called from the DLL entry point via two transitional functions. First, the header signatures are checked. If they are not standard, the ERROR_BAD_EXE_FORMAT error value is set; however, this action does not affect the loader operation in any way. The memory for the image is then allocated according to the ``` IMAGE_NT_HEADERS64.OptionalHeader.SizeOfImage value, and the loader_struc ``` auxiliary structure is formed. ``` struct loader_struc { IMAGE_NT_HEADERS64 *pPE_header; LPVOID ImageBase; HMODULE *p_imported_modules QWORD number_of_imported_modules HMODULE (__stdcall *pLoadLibrary)(LPCSTR lpLibFileName); FARPROC (__stdcall *pGetProcAddress)(HMODULE hModule, LPCSTR lpProcName); BOOL (__stdcall *pFreeLibrary)(HMODULE hLibModule); QWORD unk; }; ``` This is followed by the standard process of loading the PE module into memory and calling the loaded module's entry point (DllMain) with the DLL_PROCESS_ATTACH argument, and after exiting it, calling it again with DLL_PROCESS_DETACH. **The main module operation** In the main module, the values of all signatures required for the correct file loading are equal to zero. - IMAGE_DOS_HEADER.e_magic - IMAGE_NT_HEADERS64.Signature ----- - IMAGE_NT_HEADERS64.FileHeader.Magic In addition, TimeDateStamp and section names also have a null value. The remaining values are correct, thus after manually editing the necessary signatures, the file can be downloaded for analysis as a proper PE module. The analysis of the main module is complicated, since atypical methods of calling functions are [periodically used. The UT hash library is used for storing and processing structures. It allows one](https://github.com/troydhanson/uthash) to convert standard C structures to hash tables by adding a single member of the ``` ut_hash_handle type. All library functions, such as adding elements, search, delete, etc., are ``` implemented as macros, which leads them to be forcibly inlined by the compiler in the code of the main (calling) function. [The mbedtls library is used to interact with the C&C server.](https://github.com/ARMmbed/mbedtls) **DllMain function** At the beginning of execution, the Global\\BFE_Notify_Event_{65a097fe-6102``` 446a-9f9c-55dfc3f45853}, event, execution mode (from the configuration), and the ``` command line are checked, then the operating threads are started. ----- The module has an embedded configuration with the following structure: ----- The hash field contains a value that can be an identifier. This value is used when communicating with the C&C server and can be represented as a ``` b2e4936936c910319fb3d210bfa55b18765db9cc string, which is the same length as the ``` SHA1 hashes. The string field contains a single character string: 1. ``` CA_cert is a certificate of the certificate authority in the DER format. It is used to establish a ``` connection to the C&C server over the TLS 1.2 protocol. ----- Certificate information can be found in the Addendum No. 1 to the study. The DllMain function enables for the creation of multiple operating threads depending on a number of conditions. - Main thread — thread_1_main - New server request thread — thread_2_get_new_C2_start_communication - Encrypted module execution thread — thread_4_execute_encrypted_module For execution, the value of the builtin_config.exec_mode parameter must be non-zero. - If the builtin_config.exec_mode value is 1 or 2, and the process command line contains the -k netsvcs substring, the main thread and the thread for getting the new C&C server address are started; - If builtin_config.exec_mode is equal to 2, a thread that decrypts and runs the module stored in the system is started; - If the value is 3, the main thread and the thread for getting the new C&C server address are started. In the examined sample, the value of the exec_mode parameter is 3. **The main thread** First, the backdoor checks the OS version then prepares a structure for initializing functions and a structure for storing a certain configuration fields. The procedure looks artificially complicated. ----- 3 pointers to functions are inserted to the funcs_struc structure of the funcs_1 type that will be called in turn inside the init_global_funcs_and_allocated_cfg function. In the set_global_funcs_by_callbacks function, each initializer function is called in turn. The general order of structure forming is as follows: 1) Two structures are passed to each function: the first contains pointers to some functions; the second is empty. 2) Each function transfers function pointers from one structure to another. 3) After calling the initializer function, the function pointers are moved from the local structure to the global array of structures at a certain index. ----- As a result, after all the unusual transformations, a certain number of global structures that are combined into a single array remain. Ultimately, the function call can be represented as follows. The use of complex transformations like copying local structures with functions and transferring them to global structures is probably intended to complicate the analysis of a malicious sample. The backdoor then uses the UT hash library to generate a hash table of service structures responsible for storing the network connection context, connection parameters, etc. Below is the fragment of the hash table generation code. It is worth noting that the hash table contains a signature value that allows one to determine the library used: g_p_struc_10->hh.tbl->signature = 0xA0111FE1;. ----- The backdoor in question is characterized by the distribution of relevant fields and data across several structures created specifically for this purpose. This feature makes it difficult to create meaningful names for structures during analysis. After the preparatory steps, the backdoor proceeds to initialize the connection to the C&C server. **Initializing the connection to the C&C server** It is noteworthy that the program code associated with the network connection contains its own error codes, in addition to the codes from the mbedtls library. A list of error codes found in the sample. ----- After a series of preparatory actions, the backdoor resolves the address of the C&C server stored in the configuration and retrieves the port. Addresses in the configuration are stored as strings: ``` koran.junlper[.]com:80 and koran.junlper[.]com:443. Next, the program creates a ``` TCP socket for the connection. After that, it creates a context for the secure connection and performs a TLS handshake. After establishing secure connection, the backdoor expects a packet with a command from the C&C server. The program works with two packet formats: 1. The packet received after processing the TLS protocol is a "transport" packet. 2. The packet received after processing the transport packet is a "data" packet. It contains the command ID and additional data. ----- The transport packet header is represented by the following structure. ``` struct transport_packet_header { DWORD signature; WORD compressed_len; WORD uncompressed_len; }; ``` The data is placed after the header and packed by the LZ4 algorithm. The backdoor checks the value of the signature field. It must be equal to 0x573F0A68. After unpacking, the resulting data packet has a header in the following format. ``` struct data_packet_header { WORD tag; WORD id; WORD unk_0; BYTE update_data; BYTE id_part; DWORD unk_1; DWORD unk_2; DWORD len; }; ``` The tag and id fields together define the backdoor action, which means they denote the command ID. These header structures are used in both directions of interaction. The order of processing server commands: 1. Client verification 2. Sending the information about the infected system 3. Processing commands by IDs There is a variable that stores the state of the dialog in the structure responsible for communicating with the C&C server. Therefore, before directly executing commands, performing the first two steps is required, which can be considered as a second handshake. **A verification step** To perform the verification step, the values of the tag and id fields in the primary packet received from the C&C server must be equal to 1. ----- The verification process is as follows: 1. The backdoor forms a buffer from an 8-byte array that follows the packet header and the hash_id field taken from the configuration. The result can be represented as the structure: ``` struct buff { BYTE packet_data[8]; BYTE hash_id[20]; } ``` 2. The SHA1 hash of the data in the resulting buffer is calculated. The result is placed in the packet (after the header) and sent to the server. **Sending system information** The next packet received from the C&C server must have the tag value equal to 5 and id value equal to 3. The system data is formed as a sysinfo_packet_data structure. ----- The sysinfo_packet_data.id field contains a 0x19C0001 constant. The sysinfo_packet_data.block_1.bot_id value is extracted from the registry. The backdoor locates it in the instance parameter of the ``` SOFTWARE\Clients\Mail\Hotmail\backup key, which, in turn, depending on the ``` privileges, can be located in the HKLM or HKCU sections. If the value is missing, a random GUID is generated using UuidCreate, then formatted as a ``` XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX string and saved. If the ID already existed, the sysinfo_packet_data.block_1.bot_id_created parameter is assigned the 1 value. If ``` the ID was created, the parameter is assigned the 2 value. The sysinfo_packet_data.block_1.cpu_arch parameter value: - 1 — x86 - 2 — x64 The process of determining the MAC address and IP address values by the backdoor is noteworthy. First, the program searches for the network interface through which the largest number of packets passed, then gets its MAC address and searches for the IP address of this interface. ----- The OS version is encoded with a value from 1 to 13 (0 if an error occurs, starting with 5.0 and then ascending the version. The sysinfo_packet_data.block_1.cfg_string field contains the string value from the backdoor configuration, which is equal to the character 1. **Processing commands** After the verification step and sending the system information, BackDoor.Spyder.1 begins processing the main commands. Unlike most backdoors, whose commands are quite specific (pick up a file, create a process, etc.), in this instance, they are more of a service nature and represent instructions for storing and structuring the received data. In fact, all these service ----- commands are aimed at loading new modules in PE format, storing them, and calling certain exported functions. It is worth noting that the modules and their information are stored in memory in the form of hash tables using UT-hash. **tag** **id** **Description** 6 1 Send the number of received modules to the server. 2 Save the parameters of the received module in memory. 3 Save the body of the module in the memory. 4 Load a previously saved module. The search is performed in the hash table by the ID obtained from the packet with the command. The module is loaded into memory, its entry point is called, then the addresses of the 4 exported functions are obtained, which are stored in the structure for further call. Call the exported function No. 1. 5 Call the exported function No. 4 of one of the loaded modules, then unload it. 6 Send in response a packet consisting only of the data_packet_header header, in which the unk_2 field is 0xFFFFFFFF. 7 Call the exported function No. 2 of one of the loaded modules. 8 Call the exported function No. 3 of one of the loaded modules. 5 2 Send information about the current connection parameters to the server. 4 - Presumably, the exported function No. 1 can return a table of pointers to functions, and the program calls one of these functions at this command. After processing each packet received from the server, the backdoor checks the difference between the two values of the GetTickCount result. If the value exceeds the specified reference value, it sends the 0x573F0A68 signature value to the server without any additional data and transformations. |tag|id|Description| |---|---|---| |6|1|Send the number of received modules to the server.| ||2|Save the parameters of the received module in memory.| ||3|Save the body of the module in the memory.| ||4|Load a previously saved module. The search is performed in the hash table by the ID obtained from the packet with the command. The module is loaded into memory, its entry point is called, then the addresses of the 4 exported functions are obtained, which are stored in the structure for further call. Call the exported function No. 1.| ||5|Call the exported function No. 4 of one of the loaded modules, then unload it.| ||6|Send in response a packet consisting only of the data_packet_header header, in which the unk_2 field is 0xFFFFFFFF.| ||7|Call the exported function No. 2 of one of the loaded modules.| ||8|Call the exported function No. 3 of one of the loaded modules.| |5|2|Send information about the current connection parameters to the server.| |4|-|Presumably, the exported function No. 1 can return a table of pointers to functions, and the program calls one of these functions at this command.| ----- **New server request thread** **BackDoor.Spyder.1 can request the address of the new C&C server if the url_C2_req URL is** provided in the configuration. To request this URL, the program can use both the system proxy and the HTTP proxy provided in the configuration. The request is made using the ``` InternetOpenUrlA WinHTTP API. ``` The response must be a Base64-encoded string between two markers: DZKS and DZJS. It should be noted that a similar algorithm and markers were used in the PlugX family [(BackDoor.PlugX.28, BackDoor.PlugX.38).](https://vms.drweb.com/virus/?i=21507745&lng=en) The decoded string is decompressed using the RtlDecompressBuffer function, resulting in the address of the new C&C server and the port to connect to. ----- **Encrypted module execution thread** If the exec_mode configuration parameter is set to 2 and the command line contains -k ``` netsvcs, the backdoor creates a separate thread to execute the module stored in the file. ``` To do this, the backdoor searches for the C:\Windows\System32\1.update file at first. If such a file exists, the program reads it and decrypts it. This file contains the path to an encrypted file containing a DLL module that the backdoor reads, decrypts, and loads. ----- #### Features of the x86 version The version of the backdoor designed to run on 32-bit Microsoft Windows operating systems is detected by Dr.Web as a BackDoor.Spyder.3 (83e47dbe20882513dfd1453c4fcfd99d3bcecc3d). The main difference of this modification is the presence of debug messages. The list of debug messages can be found in the Addendum No 2 to the study. Messages are recorded on the log file located in the %WINDIR%\temp\deskcpl.ttf directory. Depending on the initialization parameters, they can be output using ``` OutputDebufStringA or encrypted using a simple XOR operation with byte 0x62. ``` ----- Messages related to communication with the C&C server and command processing are output using the OutputDebugStringA function. It is noteworthy that for such messages, the ``` [Spyder] prefix is used. ``` ----- ### Addendum No. 1 CA_cert information (certificate for establishing a connection with the C&C server) ----- ----- ### Addendum No. 2. List of 32-bit modification debug messages ----- ----- ----- ### Addendum No. 3. Indicators of compromise #### SHA1 hashes **BackDoor.Spyder** 41777d592dd91e7fb2a1561aff018c452eb32c28 cf584bd93d76f6546004fedb1fcf56888ced54b6 ----- e1fe3594da5466dd2e5a5713e885760d7e914b91 8af7f35ec09ec77b5a9005a1fff0e22464f2ab7f 699a7c59ab5b437badfaa90071d9fd9304fdcebc ff5b2bd36ae07d994c194ed0f38ed9357a018128 d4bec278dda7c046739d5361eb51fd65f0fedfea 4c871eae022c8088f6e8d46e17002cd0c0006650 83e47dbe20882513dfd1453c4fcfd99d3bcecc3d **Domains** sidc.everywebsite[.]us snoc.hostingupdate[.]club wntc.livehost[.]live hccadkml89.dnslookup[.]services koran.junlper[.]com nted.tg9f6zwkx[.]icu sidcfpprx14.in.ril[.]com sidcfpprx01.in.ril[.]com sidcfpprx25.in.ril[.]com sidcfpprx10.in.ril[.]com -----