1. Introduction
2. General information
3. Analysis of malware and tools
   1. MyKLoadClient
      1. Scheme 1
      2. Scheme 2
      3. Test sample
      4. Payload
   2. Zupdax
      1. Payload
      2. Connection with Redsip
      3. Connection with Winnti and FF-RAT
      4. Connections with Bronze Union and TA428
   3. Downloaders
      1. Downloader.Climax.A
      2. Downloader.Climax.B
   4. RtlShare
      1. Dropper rtlstat.dll
      2. Injector rtlmake.dll
      3. Payload rtlmain.dll (rtlmainx64.dll)
      4. Use of RtlShare
   5. PlugX
      1. Demo dropper
   6. BH_A006
      1. Stage 0. Loading DLL from the overlay
      2. Stage 1. DLL dropper
      3. Stage 2. .dat loader (SbieDll.dll / SbieMsg.dll)
      4. Stage 3. Shellcode .dat and DLL
      5. Stage 4. MemLoadLibrary
      6. Stage 5. Payload
      7. Connection with 9002 RAT
   7. Deed RAT
4. Conclusion
5. Appendices
   1. MITRE
   2. IOCs
      1. File indicators
      2. Network indicators

Introduction

At the end of 2019, Positive Technologies Expert Security Center (PT ESC) found a phishing email aimed at a Russian aerospace enterprise. It contained a link to previously unknown malware. Our experts discovered the same malware in 2020 when investigating an information security incident at a Russian government agency. During the investigation, several new malware families using a common network infrastructure were also discovered, some of which had not previously been mentioned in open sources.

In the summer of 2021, PT ESC revealed traces of compromise of another Russian aerospace enterprise. The organization was duly informed. As a result of the investigation, we found connections to the same network infrastructure on its computers. Further research made it possible to identify at least two more organizations in Russia, both partially state-owned, that were attacked using the same malware and network infrastructure.

We could not unambiguously link the detected malicious activity to any known hacker group, so we gave the attackers a new name—Space Pirates. The reason for the name was the P1Rat string used in the PDB paths, and the targeting of the aerospace industry. This report describes the group's detected activity, the features of the malware it uses, as well as its connection with other APT groups.

General information

We assume that Space Pirates has Asian roots, as indicated by the active use of the Chinese language in resources, SFX archives, and paths to PDB files. In addition, the group's toolkit includes the Royal Road RTF (or 8.t) builder (common among hackers of Asian origin) and the PcShare backdoor, and almost all intersections with previously known activity are associated with APT groups in the Asian region.

The group began its activity no later than 2017. The main targets of the criminals are espionage and theft of confidential information. Among the victims identified during the threat study are government agencies and IT departments, as well as aerospace and power enterprises in Russia, Georgia, and Mongolia. At least five organizations were attacked in Russia, one in Georgia, and the exact number of victims in Mongolia is unknown.

Some APT group attacks using malware were also targeted at Chinese financial companies, which suggests a monetary motivation. All potential victims were notified by the respective national CERTs.

At least two attacks on Russian organizations can be considered successful. In the first case, the attackers gained access to at least 20 servers on the corporate network, where they remained for about 10 months. During this time, more than 1,500 internal documents were stolen, as well as information about all employee accounts in one of the network domains. In the second case, the attackers managed to gain persistence in the company's network and remain there for more than a year, obtain information about the computers on the network, and install malware on at least 12 corporate nodes in three different regions.

The Space Pirates toolkit includes unique downloaders and several backdoors which we have not previously encountered and which are presumably specific to the group: MyKLoadClient, BH_A006, and Deed RAT. The criminals also have access to the Zupdax backdoor: its modern variants use a similar MyKLoadClient execution scheme; however, the code of the backdoor itself dates back to 2010 and cannot be uniquely attributed to the group.

In addition, the attackers use well-known malware, such as PlugX, ShadowPad, Poison Ivy, a modified version of PcShare, and the public shell ReVBShell. The dog-tunnel utility is used to tunnel traffic.

The main network infrastructure of the group uses a small number of IP addresses indicated by DDNS domains. Interestingly, the attackers use not only third-level domains, but also fourth- and higher-level ones, for example, w.asd3.as.amazon-corp.wikaba.com.

In the process of investigating Space Pirates, we found a large number of intersections with previously identified activity, which researchers associate with the following groups: Winnti (APT41), Bronze Union (APT27), TA428, RedFoxtrot, Mustang Panda, and Night Dragon. The reason for this is probably the exchange of tools between groups, which is common practice for APT groups in the Asian region.

The connection between the Space Pirates and TA428 groups should be specially noted. As part of another investigation, we observed the activities of both groups on infected computers, which, however, had no intersections in the network infrastructure. During Operation StealthyTrident, described by ESET, the attackers used Tmanger, attributed to TA428, and Zupdax, associated with Space Pirates. The connection with another TA428 malware, in particular Albaniiutas (RemShell), and Zupdax can also be traced in the network infrastructure adjacent to the one mentioned in the ESET report. All this suggests that Space Pirates and TA428 can combine their efforts and share tools, network resources, and access to infected systems.

The key connections between the affected organizations, malware families, and fragments of the network infrastructure, as well as public information about the attackers, can be seen in Figure 1. Later in the report, we will give more details about them.

Analysis of malware and tools

MyKLoadClient

This malware was used in attacks on Russian organizations, including government agencies and aerospace enterprises, often being distributed through targeted phishing. The email analysis shows that Chinese companies providing financial services also became victims.

Among the malware samples with MyKLoadClient that we found, two typical implementation schemes can be distinguished. The first (hereinafter scheme 1) is based on the use of SFX archives as droppers, implements the DLL Side-Loading technique, and uses an auxiliary launcher library AntiVirusLoader.dll. The second (hereinafter scheme 2) includes only a custom-written dropper which transfers control to the payload directly. In the second case, gaining persistence in the system is not a feature of the code.

Note that, according to the known data, there is a clear relationship between the attackers' goals and the choice of implementation scheme: samples using scheme 1 were targeted at Russian organizations, whereas scheme 2 was used in attacks on Chinese companies. If we rely on the dates of modification and compilation of files (which, however, could be spoofed), the same division can be traced back in time: scheme 1 was presumably used in 2018–2019, and scheme 2 in 2020. It is possible that the attackers updated the implementation chain of the previous malware to reduce the likelihood of its detection in new attacks.

Scheme 1

A typical example of a sample with the first implementation scheme is a file named Петербургский международный экономический форум (ПМЭФ)____2019.exe (Petersburg International Economic Forum (SPIEF)____2019.exe) with SHA-256 d3a50abae9ab782b293d7e06c7cd518bbcec16df867f2bdcc106dec1e75dc80b. The file is an SFX archive that extracts the decoy document 0417.doc and another SFX archive named apple.exe. The files in the archive were modified in April 2019. The document contains a text with a true description of SPIEF.

The second SFX archive extracts three PE files from itself: the legitimate siteadv.exe, the launcher siteadv.dll, and the library with payload cc.tmp. Note that in the samples studied, the first implementation scheme does not always use a decoy. However, in all cases, a similar SFX archive is used, which contains files with the same names and purpose.

The executable EXE file is signed by McAfee, Inc. and is a component of the McAfee SiteAdvisor installer. At startup, it loads the siteadv.dll library, which is responsible for installing and launching the payload. The launcher resources feature a configuration encrypted with RC4 with key "TDILocker" and containing the necessary paths, registry key names, and flags.

The launcher provides several possible commands that are passed by way of command-line arguments and are responsible for one of the implementation stages:

In addition to the exported function main, which is called by the legitimate siteadv.exe, in siteadv.dll there is an unused buc_uninstallinterface export that is responsible for bypassing the UAC using the IARPUninstallStringLauncher component.

The launcher library has the export name AntiVirusLoader.dll. In some of its instances, you can find the PDB path:
D:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoader_bypassKIS\snake\res\SiteAdv.pdb.

The cc.tmp payload is a backdoor implemented as a dynamic library with the internal name client.dll. It exports the MyKLoad function, which is the actual entry point. We will consider the functionality of the backdoor below.

Scheme 2

The executable file responsible for extracting the decoy and payload acts as a dropper in the second scheme. The binary data is located in the body of the dropper and is XOR-encrypted with a single-byte key. In addition to the standard launch of the extracted payload via the CreateProcess call, the dropper also performs reflective loading and execution of the EXE file directly in the current process.

In some cases, the dropper functions are additionally obfuscated using the control flow flattening technique.

As a decoy, the investigated samples use a PDF document containing a message about a "corrupt file" in the Chinese language, or an application stub that displays the message "正在更新浏览器插件，请稍后…" (The browser plugin is updating, please wait ...) and "更新完毕，请重启浏览器！" (The update is completed, restart the browser!).

The payload in this case is an executable file with the internal name client.exe. Some samples also have the PDB path C:\Users\classone\Desktop\src\client\exe_debug\client.pdb.

Test sample

We also managed to find a test version of the malware created no later than in 2018: b1d6ba4d995061a0011cb03cd821aaa79f0a45ba2647885171d473ca1a38c098. This application is a dropper.

Interestingly, it seems to have been created based on the Snake game. This is indicated by several details:

• When launched, the application creates a window using the string "Snake" as its name.
• There is code presumably responsible for the game logic—in particular, for generating random coordinates of pieces of food on the 50×50 field and comparing them with the position of the snake.
• The application handles presses of the spacebar and cursor keys.
• The application features a menu with items in Chinese: Start, Pause, Restart, and Quit.

In addition, among the dropper resources there is also an "About the program" window (in Chinese), the content of which indicates that this is the second version of the Snake game, which was created in 2016. The email address of the probable author is also given: mexbochen@foxmail.com.

A Google search for the address throws up the profile of the email owner—a programmer from China who specializes in image processing.

Despite the connection between the application and the owner of the email, it is impossible to say unequivocally that he is the author of the malware. It is possible that Snake was once an open-source project, and the attackers used it as a basis for implementing the dropper.

The files extracted by the dropper are contained in its resources in cleartext. Also in the resources is an encrypted configuration that contains the file names—exactly the same configuration is used in the launcher. When files are written to disk, their contents are XOR-encrypted with the 0x80 key, and then the files are reopened and decrypted. The dropper contains the same set of components as SFX archives (scheme 1): a legitimate McAfee SiteAdvisor component, a DLL launcher, and a library with a payload named Client.obj.

After extraction, the dropper generates a command line to run the launcher with the install command (for persistence in the registry and launching the payload), but does not make further use of it. This is probably an error: there is the debug message "CreateProcess success!" in the code, but the CreateProcess function is not called.

The launcher of the test sample differs in its implementation of the mrun command: a variation of the run command responsible for launching the function exported from the DLL with payload. Unlike run, mrun predecrypts the library using the RC4 algorithm with key "GoogleMailData" and uses reflective loading for its execution.

The payload of Client.obj is similar to cc.tmp (scheme 1) and has only minor differences. In particular, the entry point function exported by the library is called "main", which, when run, displays a message box with the text "just a demo for test!!!" In addition, the backdoor configuration is not encrypted and contains the test C2 127.0.0.1.

Payload

Options for implementing the backdoor in the form of the executable file client.exe and the library client.dll have the same functionality. However, they differ in how they initialize the structure with configuration parameters, which include the address and port of the C2, the backdoor activity flag, as well as the string IDs of the malware sent to the C2.

In the client.dll library, just like in the launcher (scheme 1), there is a configuration encrypted with RC4 key "GoogleMailData" in the payload resources. In the EXE version, the structure is filled with values fixed in the code.

The following table lists the backdoor samples we found and the data specified in their configuration, namely the IDs and the control server. The "?" sign means that the string is a random set of bytes.

The connection to the control server is established over TCP, and the traffic is not encrypted. The messages have a header of the following structure:

struct PacketHeader{
    _DWORD Version; // 0x20170510
    _DWORD CommandId;
    _DWORD PayloadSize;
    _DWORD LastError;
};

The 0x20170510 constant is always used as the version, probably denoting some date.

The malware has several classes/modules responsible for the corresponding functionality:

• ShellManager: remote command line
• DiskManager: working with disks installed on the infected computer
• FileTransferManager: file transfer
• RS5Manager: using the infected computer as a proxy server

In the ID of each command, there is a module identifier, which is obtained by applying the 0xFF000 mask. Here is a full list of supported commands:

In the process of collecting information about the system, the backdoor creates a globally unique identifier (GUID) and writes it to the registry in one of the HKLM or HKCU hives using the Software\CLASSES\KmpiPlayer key. If the key is already in the registry, then the existing ID is used.

Zupdax

The first public mention of this malware can be found in the Unit 42 report on HenBox, a malicious application for Android. In the HenBox network infrastructure, researchers found traces of the use of malware of the PlugX, Zupdax, 9002 RAT, and Poison Ivy families. In 2019, Unit 42 combined three years of observed activity related to the above-mentioned set of malware, naming the group (or groups) behind it PKPLUG.

In 2020, ESET discovered traces of an attack on the Able Soft LLC supply chain. One of the attack options was to compromise the Able Desktop installer by adding malicious code to it. The researchers cite the HyperBro and Korplug (PlugX) backdoors as the payload built into the installers.

According to available data, we can say that the payload designated by ESET as Korplug is in fact a Zupdax backdoor. This opinion is shared by NortonLifeLock and Avira analysts, who published a report in the fall of 2021 describing the main features of Zupdax.

Zupdax has been operating since 2014 at least. Our study focused on 2017–2019 samples, but some details can only be traced in earlier versions (2014–2015). We will be referring to them as "old".

The latest versions of Zupdax use the same loading scheme as in the MyKLoadClient test sample. Although there is no Snake game code in them, the main functionality of the dropper is implemented in a similar way: in its resources are the legitimate siteadv.exe, a launcher library, a payload, and a XOR-encrypted configuration with file names and flags. The launcher uses exactly the same configuration.

Unlike MyKLoadClient, in almost all samples with Zupdax, the payload (which is extracted under the name ok.obj) is encrypted and launched using the mrun method. Among the launcher samples that are used in conjunction with Zupdax, you can find more functional options that support UAC bypass (in particular, using buc_uninstallinterface export) and persistence as a service.

In the dropper and launcher samples are the corresponding PDB paths:
d:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoaderBypassNorton\Release\loaderexe.pdb and
d:\Leee\515远程文件\P1Rat_2017_07_28A\src\MyLoader_bypassKIS\snake\res\SiteAdv.pdb.

Malware variants related to the attack on Able Desktop users also contain a PDB with a similar string, MyLoader_bypassKIS:
c:\Users\PC-2015\Desktop\Badger\En-v2\免杀\MyLoader_bypassKIS\bin\loaderdll.pdb.

Interestingly, there is at least one sample (a95dfb8a8d03e9bcb50451068773cc1f1dd4b022bb39dce3679f1b3ce70aa4f9) that is completely identical to the test version of MyKLoadClient and contains exactly the same "About the program" window. The payload in it is a Zupdax backdoor.

Payload

For network interaction with C2, the backdoor uses the UDT protocol, which implements data transfer over UDP. The messages have a header with a structure similar to that used in MyKLoadClient. The only difference is the value of the first field equal to 0x12345678:

struct PacketHeader{
    _DWORD Magic; // 0x12345678
    _DWORD CommandId;
    _DWORD PayloadSize;
    _DWORD Unknown; // 0
};

Immediately after establishing a connection with C2, the backdoor collects and sends information about the system, including the computer name, user name, OS version, information about disk volume, RAM, and CPU, as well as the IP and MAC addresses of the network adapter. The collected information is sent with the 0x1 command ID.

The set of commands that the backdoor can handle does not change significantly from version to version: its main features are reduced to the execution of additional code that it can get from the control server. Older versions of Zupdax contain debug messages that allow you to see the original names of operations:

Old Zupdax samples also have paths to PDB files:
h:\E\项目问题\UDPUDP-英文\bin\server.pdb
d:\磁盘\E\项目问题\版本\UDPUDP-英文\bin\server.pdb

It follows from them that the original name of the project can be translated as "UDPUDP-English."

Connection with Redsip

In 2011, McAfee described a series of attacks on energy companies that was named Night Dragon. Among the malware used by the attackers was a Redsip backdoor (e3165c2691dc27ddaeb21e007f2bf5aeb14ef3e12ec007938e104d6aed512f39).

Apparently, Zupdax is a redesigned version of Redsip. Backdoors, in particular, have an identical structure of network messages (including the magic constant 0x12345678), matching command names and identifiers (CMD_SET_REM and CMD_UNINSTALL_HOST), and similar debug messages. In both cases, the payload is implemented through external plugins.

Note that in 2018 Redsip was used in an attack on a Russian organization associated with the aerospace industry. The attackers used a leaked corporate document as a decoy. We could not find a direct connection between this attack and the activities of Space Pirates.

Connection with Winnti and FF-RAT

Some Zupdax samples have valid digital signatures. In particular, sample 24b749191d64ed793cb9e540e8d4b1808d6c37c5712e737674417573778f665b (upinstall.bat) is signed with a YD Online Corp. certificate, and 84b8bfe8161da581a88c0ac362318827d4c28edb057e23402523d3c93a5b3429 (Slack.exe) is signed with a NFINITY GAMES BILISIM ANONIM SIRKET certificate.

Among the files signed with these certificates are components of the PipeMon malware, which is attributed to the Winnti group. Studying the network infrastructure of the second sample, we also noted the presence of indirect connections with the old Winnti infrastructure, but they require additional confirmation.

However, in the case of Slack.exe, we can state the presence of reliable infrastructure connections with the FF-RAT backdoor, which was described by BlackBerry in 2017. So, both the Zupdax sample and the FF-RAT samples use playdr2.com and gamepoer7.com subdomains as C2.

Connections with Bronze Union and TA428

ESET's previously mentioned report Operation StealthyTrident: corporate software under attack on the compromise of Able Desktop notes the presence of HyperBro and Zupdax backdoors (Korplug according to ESET), as well as Tmanger and ShadowPad as part of a single cybercriminal operation. The researchers give several possible explanations for this connection. We were able to identify several additional facts that give more information about the connections between the Bronze Union (LuckyMouse, APT27) and TA428 groups and Zupdax malware.

Code intersections

The Zupdax sample from the ESET report contains a dropper that is standard for this malware (data1.dat, 2486734ebe5a7fa6278ce6358d995d4546eb28917f8f50b01d8fdd7a1f9627a4), extracting the payload from resources. Of interest is the scheme by which it gains control: it side-loads the pcalocalresloader.dll library, which contains a shellcode that decrypts and executes another shellcode from the thumb.db file. The second shellcode contains a DLL library compressed using the LZNT1 algorithm, which it reflectively loads into memory.

Both shellcodes use an atypical hashing algorithm for the names of imported libraries and functions (see Figure 15). For example, kernel32.dll has the hash 0xD4E88, and ntdll.dll 0x1B708. However, a search for similar samples showed that similar shellcodes can be found in various malware families—for example, in SmokeLoader or in exploits for InPage. It is likely that a builder available to various hacker groups was used to create the shellcodes.

However, the whole scheme, including the legitimate component IntgStat.exe, pcalocalresloader.dll library, and the encrypted file thumb.db, was used in this form only to download the HyperBro backdoor, as described by Kaspersky. The only difference is that in the case of Able Desktop, shikata_ga_nai obfuscation was not applied.

An auxiliary DLL located in thumb.db handles the simultaneous launch of the dropper (data1.dat) and the legitimate Able Desktop installer. It is distinguished by the presence of a large number of unused strings in the data section. Some of them are specific only to samples of the HyperBro backdoor:

Elevation:Administrator!new:{FCC74B77-EC3E-4dd8-A80B-008A702075A9}
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\test
system-%d
CreateProcessAsUser error %d
\\..\\config.ini
Win2008(R2)
Win2012(R2)

As follows from the ESET report and our research, the criminals behind the attack on Able Desktop users have access to both HyperBro and Zupdax. However, most of the code features are specific to the HyperBro backdoor, which, in turn, is attributed to the Bronze Union group.

Network intersections

One of the Zupdax samples (ffe19202300785f7e745957b48ecc1c108157a6edef6755667a9e7bebcbf750b) uses flashplayeractivex.info subdomains, such as update.flashplayeractivex.info and news.flashplayeractivex.info, as C2. For some time in August 2020, these domains resolved to the IP address 209.250.239.96. At the same time, the go.vegispaceshop.org domain was present at the same IP address.

The latter domain, along with the IP address, can be found in the NTT Security report on the Albaniiutas malware from the TA428 toolkit. As the detailed analysis of Albaniiutas samples by our colleagues from Group-IB shows, this malware is a new version of the RemShell backdoor (BlueTraveller) previously identified by PT ESC.

Another domain appearing at the IP address 209.250.239.96 at the same time is nameserver.datacertsecure.info. The datacertsecure.info and check.datacertsecure.info domains obviously associated with it resolved to the IP address 139.180.208.225 from June to July 2020. The node simultaneously became known as the HyperBro backdoor control server, and was mentioned by ESET in Operation StealthyTrident.

These connections further unite the attackers' goals: the compromised Able Desktop installers, as well as the above-mentioned samples of Albaniiutas and HyperBro, were used in attacks on organizations in Mongolia.

Downloaders

In the Space Pirates network infrastructure, we found two types of downloaders containing decoys with Russian text. One of them was also found in the network of our client, who was attacked by criminals.

Downloader.Climax.A

The first downloader differs by the use of parts of the source code of the Rovnix bootkit (it was described in detail by Kaspersky). Note that, according to our data, the network indicators listed in the report, in particular the bamo.ocry.com domain, as well as IP addresses 45.77.244.191 and 45.76.145.22, are part of the Space Pirates network infrastructure.

We have no information about what malware was delivered by this downloader. However, researchers from Kaspersky managed to identify likely samples based on the similarity of PDB paths and identical control servers.

In the screenshots of the payload presented in the report, you can notice a specific technique for storing strings: they are all in one data block and indexed by numbers with the prefix "PS_". This technique is found in the code of the publicly available PcShare backdoor. The sets of strings highlighted by the researchers correspond exactly to those that can be found in the open backdoor code. A similar correspondence can be made between the commands supported by the malware. As a result, we can confidently say that this payload is based on the PcShare code.

Next, we will consider a modified version of PcShare, which we called RtlShare. Note that during the investigation for our client, we found a RtlShare sample connecting to C2 202.182.98.74. It is also used by the sample Downloader.Climax.A with SHA-256 e9c94ed7265c04eac25bbcdb520e65fcfa31a3290b908c2c2273c29120d0617b. Given the above, we can assume that the payload delivered by the downloader is none other than RtlShare.

Downloader.Climax.B

Another type of downloader can use vulnerabilities in Microsoft Equation Editor for its execution. This vulnerability, in particular, is exploited by a document named "Mayor of Seoul.rtf" (7079d8c92cc668f903f3a60ec04dbb2508f23840ef3c57efffb9f906d3bc05ff), created using the notorious Royal Road RTF (8.t) builder, widely used by Asian APT groups.

The code of this downloader is completely different from Downloader.Climax.A, but does boast some similar features. In particular, both downloaders use TCP to connect to C2, and the resulting payload is decompressed using the LZW algorithm in both cases.

Downloader.Climax.B gains persistence in the system via the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\GetUserConfig. Its task is to get the files named INFOP11.EXE and OINFO11.OCX from the control server and execute the EXE file. Each of the files has its own numeric identifier, which is sent to C2.

After loading, the following configuration parameters in the downloader itself are written to the body of the received OCX file: the node and port of the control server, the waiting time between calls to C2, the TodaySend string, as well as the generated GUID.

RtlShare

The payload of the RtlShare malware is based on the publicly available PcShare backdoor code. The malware has a specific execution chain, the code of which is not available in open sources. It involves three DLLs, each with its own export name. We will be using these names to refer to the corresponding libraries.

Let's consider RtlShare using the example of 8ac2165dc395d1e76c3d2fbd4bec429a98e3b2ec131e7951d28a10e9ca8bbc46.

Interestingly, the attackers used the hacked website of the Petrozavodsk mathematical conference PICCAnA (piccana.karelia.ru) to deliver it; the site is currently unavailable (web archive). As a control server, it uses the private IP address 192.168.193.165.

During incident investigation for our client, we encountered almost identical samples using control servers 45.76.145.22, 141.164.35.87, and 202.182.98.74.

Dropper rtlstat.dll

The rtlstat.dll library acts as the initial stage of infection, exporting a single function named emBedding. Its task is to extract and run the next-stage library with the internal name rtlmake.dll.

To do this, the OS bitness is first checked and the necessary data block is selected, after which it is XOR-decrypted with a key in the form of one of the strings 4af233f4740c2fde7fc95ed3a834d7b1 (x64) and 3ad6faf2d7b714137de31efef137775b (x86). Then the decrypted data is decompressed using the LZ4 algorithm.

A data block containing the configuration is copied to the body of the received library (it is encrypted at this stage). The magic number 0xAADDEE99 is used as a marker indicating the place where the configuration will be copied.

To bypass detection based on hash sums, attackers add a random number of random bytes to the end of the library, while updating the Checksum field in the PE header of the file. This way, a new file is extracted at each new launch.

Then the dropper checks whether it is running under the SYSTEM user by searching for the config substring in the path to the LocalAppData folder. If the substring is present, the library is restarted under the current user via rundll32.exe.

Otherwise, the resulting library is saved to the file %LOCALAPPDATA%\Microsoft\Windows\WER\Security\wuaueng.hlk, and the path to it is written to the registry using the key HKCU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}\InprocServer32. This section is responsible for the MruPidlList COM object used in the library shell32.dll, which, in turn, loads the process explorer.exe—this is a well-known technique for malware persistence in the system.

At the end of its operation, the dropper executes the extracted DLL using regsvr32.exe and self-removes via a BAT file.

Injector rtlmake.dll

Versions of rtlmake.dll with different bitness have the same functionality, which is confined to extracting the next-stage DLL and embedding its code into the process rdpclip.exe (or into the current process).

At the beginning of its operation, the injector makes sure that it is running in one instance: mutexes are most often used for this purpose, but in this case named file mappings are applied. During the operation of rtlmake.dll, a mapping with the name 55fc3f9a654c500932 is created, while the mapping 7f8b6a2440e5c9e5b6 handles the payload.

Then, using a function similar to the previous step, the DLL with the payload and configuration is decrypted and decompressed (recall that it was previously copied to rtlmake.dll). The configuration encryption key is the string 2ae06f136eb6588508eefd4b5f6c98d8345f1104746d15141, and the payload encryption key is 1192f6c4b018c8e0f51d31d6dde22ff3.

Next, the process in which the payload will be injected is selected. If the current process is explorer.exe (which is true, if the library was loaded as a COM component), then the target process will be rdpclip.exe. If rdpclip.exe failed to start, or if the DLL was loaded into another process, the current process becomes the target one.

The decrypted configuration is written to the memory of the selected process, and after that the injector generates a command line of the form /v /c:0x12345678, which contains the configuration address in the address space of the process. The resulting string and payload are also written to the process memory.

To start execution of the payload, the injector determines the offset in the PE file where the exported Putklm function is located, and after that it gains control of the CreateRemoteThread call. In this case, the command-line address is passed to it as arguments. Note that there is no reflective loading up to this point: the Putklm function actually works as a shellcode.

Payload rtlmain.dll (rtlmainx64.dll)

This DLL is fully implemented based on the code of the main backdoor module PcShare—PcMain. Here are some of its features that are typical only for the RtlShare family:

• A reflective loader is implemented inside the library, which is located in the Putklm function. The command-line address that it receives is passed to DllEntryPoint via the lpReserved parameter and is XOR-encrypted with the constant 0x73DE2938. Address recovery and command-line parsing occur inside the DllMain function.
• After running rtlmain.dll, all the rdpclip.exe processes are terminated except for the current one.
• The backdoor string storage, in addition to LZ4 compression (which is present in the open-source code), is AES-encrypted with the key 68fa504a1aee69f71df454e554c74eaf. Similarly, the messages received (key 48d426ca6d45496e7413cf435516af06) and transmitted (key 2e5140d04c7d7da454991bae10160369) are encoded.
• Support for the connection via a proxy server has been added.
• There is a special command that allows attackers to overwrite the configuration inside the injector rtlmake.dll (the required offset contains the magic constant 0x76EE38BB).
• The getip command has been added to the code for implementing the remote command shell, which is done through the call nslookup myip.opendns.com resolver1.opendns.com.

Use of RtlShare

RtlShare samples can be found in other reports. For example, Recorded Future researchers found PcShare samples in the network infrastructure of the RedFoxtrot group, which have significant similarities with the RtlShare family. In addition, similar samples were previously detected by Bitdefender when investigating the activity of an APT group with Asian roots aimed at government institutions in Southeast Asia.

There are no connections in the network infrastructure between the above-mentioned cases, nor between these cases and the activity that we found during incident investigation for our client. This suggests that despite the absence of RtlShare code in open sources, several different APT groups of Asian origin have access to this malware.

PlugX

We also found several samples of the PlugX backdoor in our client's network. The samples used micro.dns04.com, microft.dynssl.com, api.microft.dynssl.com, and www.0077.x24hr.com addresses as control servers, which are part of the group's network infrastructure and directly intersect with MyKLoadClient C2.

PlugX is widely used in the cybercriminal environment; it has several versions and multiple modifications. However, the samples identified by us have a set of features that make it possible to distinguish them into a separate group.

As in the usual PlugX, the main payload of the backdoor is implemented in the form of a DLL library, which is reflectively loaded into memory during malware execution. A pointer to the structure is passed to its entry point as an argument; the structure contains, in particular, the signature and address of the encrypted configuration.

In the original PlugX, the signature is the constant 0x504C5547 (PLUG string), but in our sample group, this value was equal to 0xCF455089. The configuration size, which is 0x1924 bytes, is also nonstandard: we could not find a mention of such a configuration in open sources. Unlike many other variants that have the XV signature instead of MZ and PE, in our case, the header of the PE file with the payload remains unchanged.

The inlining technique is actively used in the backdoor, in particular, for API calls and string encryption.

To search for API functions, the backdoor uses CRC32 hashes of their names. The received pointers are cached, while the code fragments responsible for this operation are embedded in every place where access to WinAPI is required.

Almost all the strings in the backdoor are stack-based, most of them are encrypted using the ADD-XOR-SUB method. The decryption code is copied to all places where encrypted strings are used.

The malware uses a standard set of plugins known from early versions. The original PlugX, during their initialization, uses a parameter that looks like a date. For instance, the Disk plugin has the 0x20120325 parameter. In our case, for all plugins, the 2012 combination has been changed to 8102 (which may mean 2018): the same Disk plugin uses the 0x81020325 value.

The entire backdoor also has a numeric value indicating the version: it is transmitted to C2 along with information about the infected system and is equal to 0x20161127. The same version can be found in Backdoor.PlugX.38 from the Dr.Web report on attacks on state institutions in Kazakhstan and Kyrgyzstan. However, other unique values from the Space Pirates variant, such as signature and configuration size, are missing in BackDoor.PlugX.38. Both variants seem to be based on the base code of the same version of PlugX, but its modifications in each of these cases are different.

We found more precise intersections in other reports. Among the PlugX instances used in the attacks on the Vatican in 2019–2020 are several samples similar to those used by the Space Pirates group. In addition, the same backdoor modifications are found in samples associated with the activity of the RedFoxtrot group. However, we failed to detect connections in the network infrastructure, which again suggests the exchange of tools between groups. Given the other intersections between the malware used in the attacks (Zupdax and RtlShare), we can also assume that all this activity belongs to one or more jointly operating groups. This, however, requires additional confirmation.

Demo dropper

Some samples of the PlugX variant we found are extracted into the system by an interesting dropper, whose executable file can be called demo.exe. It is implemented based on the MFC library. Its job is to create a VBS script named msiexece.vbs or cosetsvc.vbs, and perform its subsequent execution.

The path to the EXE dropper and the names of the files to be extracted from it are passed to the script as command-line parameters. The files are in the demo.exe overlay and can be encrypted with a 1-byte XOR (but in all samples known to us, the key is 0). The overlay offset and the length of each of the files are written in the VBS code. The script extracts the standard PlugX components: a legitimate EXE file, a DLL for side-loading, and encrypted shellcode, after which the legitimate file is executed.

BH_A006

As in other cases, we found this malware both on our client's resources and when researching the group's network infrastructure. It contains a modified Gh0st backdoor as a payload. The string BH_A006 is constantly found in PDB paths and internal names of DLL libraries associated with the backdoor, which is why it got this name.

BH_A006 has a nontrivial payload execution scheme, which can vary at the initial stages in different samples. Let's consider it using the example of one of the malicious files.

Stage 0. Loading DLL from the overlay

SHA-256: 1e725f1fe67d1a596c9677df69ef5b1b2c29903e84d7b08284f0a767aedcc097

The source sample is an executable file that uses the MFC library. It extracts the contents of the overlay, decrypts itswith XOR with the 0xA0 key, and reflectively loads the resulting DLL into memory.

Stage 1. DLL dropper

SHA-256: 8bf3df654459b1b8f553ad9a0770058fd2c31262f38f2e8ba12943f813200a4d

extracts the following files:

• C:\ProgramData\resmon.resmoncfg
• C:\ProgramData\Sandboxie\SbieIni.dat (install32.dat)
• C:\ProgramData\Sandboxie\SbieDll.dll
• C:\ProgramData\Sandboxie\SandboxieBITS.exe

After that, there is a check for write permission to the system folder. For this, the dropper tries to create a file in it with the name format: wmkawe_%d.data. The content is the Stupid Japanese string.

If there is no permission, and the system is 64-bit, two additional files are extracted:

• C:\ProgramData\Sandboxie.dll (install64.dll)
• C:\ProgramData\Sandboxie.dat (install64.dat)

The names given in parentheses are not used, but are present in the code. Apparently, they were left there from another version of the dropper.

All the files are contained in the data section in packaged form; a variant of the LZMA algorithm is used for compression. This compression method is also used in further stages of the malware operation. Further in the section, unless otherwise indicated, we will refer to this algorithm.

Depending on the available permissions and the OS bitness, the dropper starts one of the chains to bypass the UAC:

• (x32) C:\ProgramData\Sandboxie\SandboxieBITS.exe ByPassUAC
• (x64) rundll32.exe C:\ProgramData\Sandboxie\SbieMsg.dll,installsvc ByPassUAC

Or it immediately proceeds to the execution of the next stage:
C:\ProgramData\Sandboxie\SandboxieBITS.exe InsertS

In all three cases, the file %tmp%\delself.bat is created, which contains commands for self-removal.

Note that it is not the first time researchers have encountered this sample. Another variant of the MFC loader (stage 0) containing the same dropper was mentioned by ESET in the Operation NightScout report, and then studied in detail by our colleagues from VinCSS.

Stage 2. .dat loader (SbieDll.dll / SbieMsg.dll)

Regardless of the command run by the DLL dropper, execution jumps to one of the extracted DLL libraries. In the case of a 32-bit version, a legitimate component of the Sandboxie utility, which is vulnerable to DLL side-loading, is used for this.

The code in the 32-bit and 64-bit versions of the libraries is almost identical and downloads the corresponding .dat file, decrypts its contents, and executes it. For decryption, XOR is used with the byte sequence: 00, 01, 02, ... FF, 00, 01, ... Just as in the code of the previous stage, here you can see alternative paths to .dat files that are not used during operation.

Stage 3. Shellcode .dat and DLL

The shellcode is a reflective DLL library loader, which is located in its body immediately after the loading function. In this case, the library functionality differs significantly in shellcode versions with different bitness.

Stage 3.1 ByPassUAC (x64)

Stage 3.1.1 Intermediate DLL

The 64-bit version is only responsible for implementing the UAC bypass. To perform this task, it extracts another DLL from itself into memory and transfers control to it. Reflective loading is performed again using a shellcode, which is predecrypted with XOR using the 0x97 key. The shellcode is not autonomous: in addition to the buffer with the PE file, pointers to the necessary functions, such as GetProcAddress and LoadLibraryA, are passed to it.

Stage 3.1.2 DLL with UAC bypass implementation

The DLL contains the path to the PDB file: e:\F35-F22\昆明版本\ElephantRat\nwsapagent\Bin\ByPassUAC64.pdb.

The UAC bypass method used depends on the presence in the system of the avp.exe process (a component of Kaspersky antivirus products) and on the system version. In total, three well-known methods using sdclt.exe, a .NET library, and mocking trusted directories have been implemented.

If the bypass is successfully implemented using any of the methods, the previously encountered command C:\ProgramData\Sandboxie\SandboxieBITS.exe InsertS is run.

Stage 3.2. ByPassUAC / InstallS (x32)

Stage 3.2.1. Intermediate DLL

The 32-bit version of the DLL, which is located in the corresponding DAT file, is obfuscated using an unknown protector.

In the data section of this DLL, there is a compressed shellcode that is decompressed and gains control.

Stage 3.2.2. Decompression shellcode

The shellcode starts with calling the sub_20F function, which takes three arguments: a hash on behalf of VirtualAlloc, the size of the buffer to decompress, and a pointer to the data. The arguments are written immediately after the call statement, and the called function accesses them using an offset relative to the return address.

The sub_20F function gets a pointer to the VirtualAlloc function, for which it finds the kernelbase.dll library in the list of loaded modules (which is always assumed to be in second place on the InInitializationOrderModuleList list) and iterates its export table using a hash to find the required function. Then a buffer of the size specified in the arguments with RWX rights is allocated, and the compressed data is unpacked into it. In this case, compression is done with the NRV family algorithm from the UCL library (used in the UPX packer). The data is another shellcode to which control is transferred.

Stage 3.2.3. Relocation shellcode

The main part of the next shellcode is the contents of data and code sections, apparently extracted from some PE file. To launch correctly at the beginning of its operation, the shellcode performs address correction (relocation). The parameters necessary for it are transmitted in the same way as the previous shellcode using the return address. The relocation is performed relative to the standard base address 0x401000. After its completion, control is transferred to the address of the entry point specified in the parameters (as an offset relative to the end of the relocation table).

Stage 3.2.4. Installer in shellcode format

The main function of the installer loads the WinAPI functions necessary for operation, after which it can perform the operation specified in the command line.

The following commands are supported:

• InsertS: create a service named Network Service. The name of the current module with the runsvc parameter is specified as the launch path. If there are no avp.exe processes in the list, the service is launched immediately.

• Runsvc: delete all auxiliary files and folders that could be used in the UAC bypass. Decompressing the next-stage shellcode, creating an svchost.exe process, and injecting the decompressed shellcode. Interestingly, in the code for impersonation and starting the svchost.exe process, a special check has been implemented only for the Russian language, which indicates an orientation to Russian-language OS versions.

  

  In addition, a separate thread is created that checks for Global\MYKERNELDLLMAPPING06 mapping every 50 seconds. In case of its absence in the system, the creation of svchost.exe and shellcode injection are repeated.

• ByPassUAC: works completely similar to the 64-bit version (stage 3.1.1)—it decompresses the DLL with the implementation of UAC bypass methods and transfers control to it.
• Memload: there is a MemLoadServer debug message in the code. Decompresses the next-stage shellcode and runs it directly in the current process.

Stage 4. MemLoadLibrary

The fourth stage has a previously encountered format: the decompression shellcode extracts the relocation shellcode, which in turn executes the main code (obtained from the PE file). The main code in this case is small in volume and is responsible for decompressing and reflectively loading the DLL into memory. The reflective loader is implemented in the form of an XOR-encrypted shellcode, as in stage 3.1.1. After loading the library, control is transferred to the exported Online function.

The DLL is again just an intermediate loader and runs another shellcode.

The new shellcode is an unpacking shellcode, and stage 4 is repeated exactly, right up to calling the Online function from the latest DLL library.

Stage 5. Payload

It is a backdoor partially obfuscated with the help of a previously encountered packer (stage 3.2.1), which is based on the Gh0st trojan code.

Interestingly, the signature of network packets (Gh0st in the original) in this version is generated and checked in a special way. In a 4-byte value, only the lowest bit of each byte carries the payload, the remaining bits are random. The lower bits must satisfy a set of logical relations involving the lower bits of the magic constant 0x31230C0. Note that a similar algorithm for checking these relations using the same constant can be found in loaders of .dat files (stage 2), but the result of its operation is not used there.

The library has the export name BH_A006_SRV.dll, and in the PE file overlay, you can find the corresponding PDB path:

D:\005（fastapp f35 20181009）\nwsapagent\KernelTrjoan\BH_A006_SRV\BH_A006_SRV\Debug\BH_A006_SRV.pdb

We managed to find a sample of the malware (57d4c08ce9a45798cd9b0cf08c933e26ffa964101dcafb1640d1df19c223e738), which has a similar obfuscation and an identical algorithm for generating a network signature, and contains the name BH_A006_SRV.dll. This sample was uploaded to VirusTotal in 2015.

Connection with 9002 RAT

In studying the execution chain of the BH_A006 backdoor, it turned out that the technique used for converting a PE file into an autonomous compressed shellcode is not unique. Similar decompression and relocation shellcodes, as well as the procedure for loading WinAPI functions, are present in instances of the 9002 RAT malware. For example, they can be found in the sample 52374f68d1e43f1ca6cd04e5816999ba45c4e42eb0641874be25808c9fe15005 from the Trend Micro report on attacks on South Korean companies—one of the last mentions of this malware.

Deed RAT

Another type of previously unknown malware, which we found in a single instance in our client's infrastructure, is a modular backdoor. Based on the value of the signature used in the header of its modules, we named it Deed RAT.

The Deed RAT control server ftp.microft.dynssl.com is directly connected to the infrastructure of the Space Pirates group. Another similarity can be found in one of the code features: the [xor 0xBB, sub 0x1] operations are used to encrypt the shellcode in the same way as in the part of PlugX samples.

The payload execution scheme resembles the standard method that PlugX uses: a legitimate EXE file signed by Trend Micro loads a malicious library TmDbgLog.dll, which, in turn, runs the encrypted shellcode from the file PTWD.tmp.

However, an interesting method of transferring control to the shellcode is used: at the time of loading, the library modifies the executable file so that after returning control to the EXE file, the FreeLibrary function is immediately called for it. Having regained control at the time of unloading, the library modifies the executable file again, writing assembly instructions for calling the shellcode to it—they will be executed immediately after returning from FreeLibrary.

The shellcode is the loader of the main module, which is located in compressed and encrypted form after the loading code. The module has a special structure and uses techniques borrowed from PE files. In particular, the module has three "sections" with different access rights and a relocation table completely similar to the one used in PE format.

The decrypted module consists of a header starting with the signature 0xDEED4554 and a main data block compressed with LZNT1, which contains section data and a relocation table. For each of the sections, the header indicates its actual size and the size in memory, which is aligned to the 0x1000 boundary. The header structure looks as follows:

struct SectionHeader{
    _DWORD VirtualSize;
    _DWORD SizeOfRawData;
};

struct ModuleHeader{
    _DWORD Signature; // 0xDEED4554
    _DWORD ModuleId;
    _DWORD EntryPoint;
    _DWORD OriginalBase;
    _DWORD AbsoluteOffset; // 0x1000
    SectionHeader Sections[3];
    _DWORD Unknown;
};

During operation, the loader allocates the necessary memory area, copies each of the sections into it (taking into account its size in memory), and performs address configuration (relocation). The first of the sections contains executable code, and RX permissions are set for its memory area, the other sections have RW permissions. After loading the sections, the module entry point specified in the header gain control.

The main backdoor module has the identifier 0x20 and is responsible for loading and managing plugins that implement various functions. In its data section, there are eight encrypted plugins that are initialized at the beginning of operation:

Unlike the main module, an algorithm based on Salsa20 is used to encrypt plugins. Among the modifications is a custom constant for the key extension, equal to arbitraryconstat. The structure of the decrypted plugin completely copies the structure of the main module, and a similar algorithm is used to load it.

Each plugin implements five service operations that are implemented at its entry point:

1. Initialization.
2. Obtaining the numeric ID of the plugin.
3. Obtaining the plugin name.
4. Obtaining a link to the structure with the plugin's API functions.
5. Resource deallocation.

The useful functionality of the plugin is available through the structure with its API functions. Among them, there may be a dispatcher function responsible for processing network commands that the plugin supports. The main module also has an API that allows you to access other plugins and implements auxiliary functions, such as encryption or access to the registry.

One interesting feature of the backdoor is the pseudorandom generation of various kinds of strings—registry keys, names of mutexes and pipes, and command-line arguments. A string of the required length is created on the basis of a seed, which is generated using the numeric identifier of the string and the serial number of the system volume. As a result, each of the infected computers uses its own unique set of string constants.

The backdoor stores all the necessary data in the registry key [HKLM|HKCU]\Software\Microsoft\. For each type of information, it creates its own subkey, the name of which is obtained using the string generator described above. To get all the keys that the backdoor can use, we implemented a script in Python that accepts the serial number of the volume and reproduces the operation of the generator.

                      

import click


def rshift(val, n):
    s = val & 0x80000000
    for i in range(0,n):
        val >>= 1
        val |= s
    return val


def generator(volume_number, seed, length):
    gr_seed = (volume_number + seed + 0x1000193) & 0xffffffff
    r = []
    for i in range(length):
        r1 = (gr_seed * 0x2001) & 0xffffffff
        r2 = rshift(r1, 7)
        r3 = r2 ^ r1
        r4 = (r3 * 9) & 0xffffffff
        r5 = rshift(r4, 17)
        r6 = r4 ^ r5
        r7 = (r6 * 33) & 0xffffffff
        r.append(((r7 & 0xffff) % 26) + 0x41)
        gr_seed = r7 
    
    return bytes(r).decode('utf-8')

@click.command()
@click.argument("VOLUME_NUMBER")
def main(volume_number):
    try:
        serial_number = int(volume_number, 16)
    except ValueError:
        print("[~] Invalid Volume number")
        return 

    registry_key_1 = generator(serial_number, 0xC4DA8B2F, 6)

    registry_key_2 = generator(serial_number, 0x7BD90AA1, 10)
    registry_key_3 = generator(serial_number, 0xF7BBC23F, 10)

    registry_key_4 = generator(serial_number, 0xDF12A5B2, 8)
    registry_key_5 = generator(serial_number, 0x6EB208A4, 9)

    registry_key_6 = generator(serial_number, 0xDE8765CB, 8)
    registry_key_7 = generator(serial_number, 0x6D3C218A, 8)

    registry_key_8 = generator(serial_number, 0x78D3BC22, 8)
    registry_key_9 = generator(serial_number, 0xD53BCA90, 10)

    registry_key_11 = generator(serial_number, 0x4FD82CB4, 8)
    registry_key_13 = generator(serial_number, 0xDCBC5D23, 8)

    registry_key_10 = generator(serial_number, 0xE2C7BA56, 15)
    
    registry_key_12 = generator(serial_number, 0x8BD43C12, 8)

    print(f"[+] Plugin monitor registry key: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_1}")
    print(f"[+] Executable path: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_3}; ValueName: {registry_key_2}")
    print(f"[+] Machine ID: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_5}; ValueName: {registry_key_4}")
    print(f"[+] Shellcode for injection: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_6}; ValueName: {registry_key_7}")
    print(f"[+] Proxies: [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_9}; ValueName: {registry_key_8}")
    print(f"[+] Config : [HKCU|HKLM]\\Software\\Microsoft\\{registry_key_11}; ValueName: {registry_key_13}")

if __name__ == "__main__":
    main()
                      
                    

The Network plugin is responsible for the algorithm of interaction with the control server. It extracts the C2 address as a URL string from the configuration and, depending on the scheme specified in it, selects one of the connectors available in the NetSocket plugin. All of them implement a common interface for uniformly receiving and transmitting network messages. Before sending, messages are compressed using the LZNT1 algorithm and encrypted with a modified Salsa20 using a random key.

To resolve the domain of the control server, the backdoor consistently uses DNS over HTTPS and the usual DNS servers specified in the configuration (public servers of Google and other providers), before resorting to the standard mechanism. This gives the malware the opportunity to hide the C2 domain from network traffic inspection tools.

Supported connection protocols include TCP, TLS, HTTP, HTTPS, UDP, and DNS.

The REUSEPORT option is available for TCP—specifying it leads to prebinding of the socket with which the connection to C2 is established. Binding is performed on the largest free port in the range of system (well-known) ports. The ports are checked starting from 1022 in descending order. Apparently, this technique is implemented to bypass security measures and disguise traffic as system network services.

The backdoor also provides for the possibility of obtaining a new C2 over HTTP. To do this, a web page can be used, the address of which is specified in the configuration with the URL:// scheme. After the page loads, its body is searched for the agmsy4 and ciou0 substrings, which indicate the beginning and end of the string with the control server. This string is encoded using base16 (hex) with the abcghimnostuyz0456 alphabet and is processed similarly to the address from the configuration.

TCP/TLS and HTTP/HTTPS connectors support connection via a proxy server, which can be obtained using the NetProxy plugin. The plugin has its own proxy storage, which is located in the registry and can be filled with values from the configuration, system proxies, and data from installed browsers (Chrome, Opera, and Firefox). In addition, the plugin has the functionality of a built-in sniffer that listens to the traffic of the infected computer using a raw socket. If the sniffer detects an attempt to connect to a proxy server (SOCKS4, SOCKS5, or HTTP) in the outgoing packet, it saves information about it in the storage.

Before connecting to the control server, the backdoor checks the schedule: up to four entries can be specified in its configuration, containing the days of the week and the hours during which the connection is prohibited.

After the connection is established, the backdoor can execute the following commands:

If a command is received that is not on the list above, it is assumed that it is a network command of one of the plugins. Its ID is determined by applying the mask 0xFFF0 to the command ID. If the plugin is not available locally, it is preloaded from C2 and saved in the registry.

On the computer infected with Deed RAT, we were able to detect a single plugin obtained dynamically from the control server. It is called Shell, and its ID is 0x270. Shell supports two network commands (0x270 and 0x271); each of them starts the specified process and redirects its I/O to C2. In the first case, the interaction takes place in text mode via pipes. In the second case, Windows Console API operations are used, which allows attackers to fully emulate a console window on their side, taking into account information about the size of the screen buffer, cursor position, and other parameters.

The configuration of the sample we examined contained the following set of strings:

Conclusion

APT groups with Asian roots continue to attack Russian companies, as evidenced by the activity of Space Pirates. Cybercriminals both develop new malware that implements non-standard techniques (such as Deed RAT) and use modifications of existing backdoors. Such modifications sometimes feature multiple layers of obfuscation to defeat security tools and complicate the analysis procedure—as in the case of BH_A006, built on the code of the popular Gh0st backdoor.

A separate difficulty as regards APT groups operating out of the Asian region is accurate attribution: the frequent exchange of tools and, in some cases, joint activity of groups significantly complicate this task. The core part of our research is based on the results of our investigation of an information security incident at our client's premises and analysis of specific network infrastructure that uses DDNS domains. The data obtained allows us to state with certainty that the same attackers are behind the detected activity.

PT ESC will continue to monitor the threats: new facts may provide more information about the activities of Space Pirates and its relationship with other groups.

Appendices

MITRE

IOCs

File indicators

MyKLoadClient

Zupdax

Downloader.Climax.A

Downloader.Climax.B

RtlShare

PlugX

PlugX demo dropper

BH_A006

Note: the file with SHA-256 9843ceaca2b9173d3a1f9b24ba85180a40884dbf78dd7298b0c57008fa36e33d was erroneously listed in our previous report as a ShadowPad sample. In actual fact, it belongs to the BH_A006 family of backdoor samples.

Deed RAT

ShadowPad

Poison Ivy

Network indicators

MyKLoadClient

microft.dynssl.com

micro.dns04.com

207.148.121.88

47.108.89.169

120.78.127.189

121.89.210.144

Zupdax

ns2.gamepoer7.com

mail.playdr2.com

pop.playdr2.com

news.flashplayeractivex.info

update.flashplayeractivex.info

ns9.mcafee-update.com

154.211.161.161

192.225.226.218

Downloader.Climax.A

bamo.ocry.com

202.182.98.74

Downloader.Climax.B

ruclient.dns04.com

loge.otzo.com

RtlShare

asd.powergame.0077.x24hr.com

w.asd3.as.amazon-corp.wikaba.com

45.76.145.22

141.164.35.87

202.182.98.74

PlugX

microft.dynssl.com

api.microft.dynssl.com

micro.dns04.com

www.0077.x24hr.com

js.journal.itsaol.com

fgjhkergvlimdfg2.wikaba.com

goon.oldvideo.longmusic.com

as.amazon-corp.wikaba.com

freewula.strangled.net

szuunet.strangled.net

lib.hostareas.com

web.miscrosaft.com

eset.zzux.com

elienceso.kozow.com

lck.gigabitdate.com

miche.justdied.com

45.77.16.91

103.101.178.152

123.1.151.64

154.85.48.108

154.213.21.207

192.225.226.123

192.225.226.217

BH_A006

comein.journal.itsaol.com

www.omgod.org

findanswer123.tk

45.76.145.22

103.27.109.234

108.160.134.113

Deed RAT

ftp.microft.dynssl.com

ShadowPad

toogasd.www.oldvideo.longmusic.com

wwa1we.wbew.amazon-corp.wikaba.com

Poison Ivy

shareddocs.microft.dynssl.com

Third-level DDNS domains

microft.dynssl.com

reportsearch.dynamic-dns.net

micro.dns04.com

werwesf.dynamic-dns.net

fssprus.dns04.com

loge.otzo.com

alex.dnset.com

ruclient.dns04.com

bamo.ocry.com

tombstone.kozow.com

toon.mrbasic.com

fgjhkergvlimdfg2.wikaba.com

rt.ftp1.biz

apple-corp.changeip.org

amazon-corp.wikaba.com

0077.x24hr.com

staticd.dynamic-dns.net

srv.xxxy.biz

serviechelp.changeip.us

mktoon.ftp1.biz

noon.dns04.com

ybcps4.freeddns.org

oldvideo.longmusic.com

chdsjjkrazomg.dhcp.biz

q34ewrd.youdontcare.com

journal.itsaol.com