# ESTABLISHING THE TIGERRAT AND TIGERDOWNLOADER MALWARE FAMILIES Author: Markel Picado Ortiz December 2021 ----- ### TABLE OF CONTENTS #### EXECUTIVE SUMMARY 3 INTRODUCTION 4 #### PACKER ANALYSIS 6 MALWARE FAMILIES AND VARIANTS 11 TIGERDOWNLOADER VARIANTS 14 TIGERRAT VARIANTS 17 CONCLUSIONS 21 APPENDIX 22 #### ABOUT THREATRAY 30 ----- The initial report by Malwarebytes attributes the attack to the Lazarus group. Kaspersky refines the attribution to the Andariel APT, a subgroup of Lazarus. Korea CERT (KrCERT) reports a new attack and calls the malware tools seen in this attack TigerDownloader and TigerRAT. The KrCERT report provides a thorough and detailed, indicator-based analysis of the relationship between their malware samples and those previously analyzed by Kaspersky and Malwarebytes. They also employ a proprietary attribution technology to further relate the attacks. In this report, we focus on the malware tooling from the previously reported attacks. We provide new evidence to attribute these tools to the same downloader and RAT families. We will refer to these families as TigerDownloader and TigerRAT respectively. We've chosen these names in recognition of KrCERT's important work where the names were first introduced to refer to the malware tools they studied in that same work. We systematically study code reuse as well as functional commonalities between all the samples used in different stages of the previously reported attacks (i.e., packers, downloaders, and RAT payloads). We have also found that while the tools fall into the mentioned families, there are different variants of the tools which have been deployed in the reported attacks. For the RAT payloads, we have found three versions with distinct capabilities. For the downloaders we have found two versions, one with and the other without persistence capabilities. Apart from these findings, we contribute novel insights and speculations to the existing body of knowledge toward a clearer mapping of the techniques and tools used by this threat actor. Finally, we are making our unpacking and config extraction scripts as well as raw data available to the community (https://github.com/threatray/tigerrat) to facilitate further research and defense capabilities. capabilities. ----- ##### PREVIOUS RESEARCH **April 19, 2021: Malwarebytes has reported a recent attack targeting South Korea using a malicious** Word document. The Malwarebytes report describes the attack and attributes it to the Lazarus group. Malwarebytes discovered a novel downloader component used in the attack. https://blog.malwarebytes.com/threat-intelligence/2021/04/lazarus-apt-conceals-malicious-codewithin-bmp-file-to-drop-its-rat/ **June 15, 2021: Kaspersky released a blog post about the same attack, mentioning the** Malwarebytes report, saying they detected the Word document in April. Kaspersky refines the attribution to the Andariel APT group, a subgroup of Lazarus. Kaspersky’s analysis is based on operational similarities found between the current and past attacks of the Andariel APT group. They also identify novel downloaders and RAT payloads. In addition, they find a new ransomware deployed by the RAT. – https://securelist.com/andariel-evolves-to-target-south-korea-withransomware/102811/ **September, 2021: KrCERT reports on an operation they call "ByteTiger", a campaign targeting** South Korean entities which they have attributed to the Andariel APT group. This report analyses in detail a multistage attack with two unknown pieces of code which they call TigerDownloader and TigerRAT. They link the new attack to the samples previously disclosed by Malwarebytes and Kaspersky using some proprietary tooling. Linkage is apparently done through similarities / re-use of code, rich headers, section hashes and C2 infrastructure, yet no further details are shared in the report. https://www.krcert.or.kr/filedownload.do?attach_file_seq=3277&attach_file_id=EpF3277.pdf ### INTRODUCTION ##### WHAT IS THE ANDARIEL APT GROUP? Andariel group is a state-sponsored threat actor. It is a subgroup of the Lazarus cybercrime group, considered one of the most sophisticated North Korean threat actors to which threat researchers have attributed many attacks from 2009 to 2021. The Andariel group is mostly targeting South Korean entities focusing mainly on financial gain and cyber espionage. This group is known to employ custom tools and new techniques to increase the effectiveness of its attacks. ----- _Figure 1: Similarities and differences between the attack chains reported by Malwarebytes,_ _Kaspersky and KrCERT._ The attack chains in all the reported cases have some structural similarities (see Figure 1). In all three reports a downloader malware has been observed. Kaspersky and KrCERT have additionally seen a third-stage RAT components. Concerning the access methods, malicious documents have been used in the cases reported by Malwarebytes and Kaspersky, whereas a compromised website was used in the KrCERT case. ----- To quickly understand if the packed samples are related, we performed an automated code reuse analysis at the function level. The results forming that analysis are shown in Figure 2. In the table, the numbers in the “function reuse” column measure the number of samples in which a function occurs. As an example, the function at the address 0x140002b70 (first row) appears in 27 out of 27 the packed samples. That is, this is a function that occurs in all packed samples. _Figure 2: Function reuse across the 27 packed binaries which we have analyzed._ ### PACKER ANALYSIS In this section we will first establish that the packed binaries share common code that originates from the unpacking algorithm. Then we show that there is a common packing scheme underlying all the packed samples at our disposal. Our findings thus provide strong evidence that the binaries are related by the same packer. Should the packer be under exclusive control of the attacker (which we don’t know) then our findings would allow attribution of all the binaries to the same actor. ##### SHARED CODE IN PACKED SAMPLES To quickly understand if the packed samples are related, we performed an automated code reuse analysis at the function level. The results forming that analysis are shown in Figure 2. In the table, the ----- Based on the analysis, we suspected that the samples share a few functions for the effective unpacking, while some of the remaining functions are used to avoid detections by antivirus, Yara and related pattern-based detection technologies. We then took a closer look at these stable functions and could confirm that they do, indeed, contain packing functionality. The results of this analysis are shown in Figure 3. **Packed hash** **Function address** **Function reuse** **Functionality** 0996a8e5ec1a41645309... 140002b70 (27/27) map_decrypted_payload() 0996a8e5ec1a41645309... 140001bf0 (27/27) anti_analysis_check() 0996a8e5ec1a41645309... 140002030 (26/27) do_unpacking() 0996a8e5ec1a41645309... 140002860 (26/27) dynamic_winapi_resolution() 0996a8e5ec1a41645309... 140002360 (12/27) main_program() 0996a8e5ec1a41645309... 140002a30 (14/27) relocate_mapped_payload() _Figure 3: Functionality found in the most stable functions._ We could also confirm the presence of junk code to avoid detection technologies. Figure 4 shows the same function decrypt_payload() in two different samples. We can see junk functions like GetFontUnicodeRanges(), GetSysColorBrush() and CreateBitMap() which are called but whose return values are not being used. In the figure, the effective unpacking code, which in this case is the XOR decryption algorithm, is contained within the green boxes shown. We have found this junk-code strategy in all the packed code and throughout many functions. There are several other functions (i.e., 0x140001bf0, 0x140002030, 0x140002860) that appear in 27 or 26 samples. From the table, we can establish that the packed samples are clearly related. All of them have two functions in common and there are various subsets of the samples that feature substantial code reuse. In a nutshell, the automated function reuse analysis gives us a quick understanding about the relations of the packed samples. As we shall see next, it also directs our manual analysis efforts. Based on the analysis, we suspected that the samples share a few functions for the effective unpacking, while some of the remaining functions are used to avoid detections by antivirus, Yara and related pattern-based detection technologies. We then took a closer look at these stable functions ----- _Figure 4: Junk code in packer code to avoid anti-virus and Yara detections._ In summary, we have seen so far that the packed samples are related by a common packer code. The code-wise differences between the packed samples is mainly due to the presence of junk code. ##### COMMON PACKING SCHEME The packer is a simple loader, which decrypts and maps the payload into memory. The decryption scheme is a simple XOR using a 16-byte key. This has been established in previous research. Additionally, we found that all packer variants follow the same common packing scheme, whereas the variants of the scheme are determined by two parameters. One parameter is whether or not the packed payload is Base64 encoded, the other is where the packed payload is stored within a PE file. The variations concerning encoding of the payload are illustrated in Figure 5. ----- _Figure 5: Above, Base64 encoding of encrypted payload; below, encrypted payload without encoding._ Concerning the location of the packed code, we have observed that there are three locations within a PE file where the packed payload is stored. The locations are depicted in Figure 6. _Figure 6: Variations of packed code locations in a PE file. Left to right, packed code in PE overlay, in the PE_ _resource section, or in a dedicated PE section which is named OTC in this example._ ----- For the third variant using a dedicated section, we observed the following section names: “KDATA,” "OTC,” “OTS,” “OTT,” and “data.” We could not identify the significance, if any, underlying these names. Our findings are summarized in Figure 7, which shows the packing scheme common to all packed downloader and RAT variants we analyzed. _Figure 7: Packing scheme common to all samples._ ----- ### MALWARE FAMILIES AND VARIANTS In this section, we will establish through code reuse analysis that all the unpacked binaries fall into a downloader or RAT family. We are calling these families the TigerDownloader and TigerRAT malware family. These names were introduced in the KrCERT report to refer to the downloader and RAT components in their investigation. To get a quick understanding of the unpacked binaries, we have performed a combined cluster and code-reuse analysis. This analysis allows us to automatically identify malware families and malware variants within a family. The goal of this analysis is to gain a quick understanding of the relationship between binaries and to direct analysts to the relevant samples for further manual analysis to eventually understand the attacker’s tooling and capabilities. The results of the cluster and code-reuse analysis are shown in Figure 8. The figure confirms that the unpacked binaries either fall into the TigerDownloader (blue) or TigerRAT (orange) family. Moreover, we see that each family has three variants (shown as large circles). We have used a cluster threshold of 97.5%, meaning that binaries which are at least 97.5% similar fall into the same cluster. The clusters in the graph consist of the so-called “cluster representatives” (large circles) and samples (small circles) directly connected to a cluster representative. The underlying idea is that the samples within a cluster are essentially identical and thus well represented by the cluster representative. _Figure 8: Cluster and code-reuse analysis of the unpacked samples with their abbreviated hashes._ We note that the choice of the cluster threshold has an obvious impact on the variants: A high threshold will reveal minor and more variants, while a low one reveals fewer and only major variants. We draw the following conclusions from the graphs: - There is no code reuse between the TigerDownloader and the TigerRAT family. We recall from the packer analysis that although the families are code-wise distinct, they are packed using the same packing scheme. ----- The table in Figure 9 shows the detailed composition of the clusters from the previous graphs. We also notice that some (hash-wise) unique packed samples result in (hash-wise) identical unpacked sample, reducing the effective diversity of the samples under consideration. _Figure 9: Detailed cluster information._ ----- In the following sections we will analyze the downloader and RAT variants in more detail, limiting our analysis to the cluster representatives. This ability to reduce analysis to cluster representatives is key for the directed and efficient analysis and tracking of malware variants. The choice of cluster representatives and their names used in the following analysis are shown in Figure 10. **Cluster** **Stage** **Sample Name** **Hash** 0 RAT (x64) RAT-Kaspersky- bbddcb280af742ce10842b18b9d71206 3[rd] stage x64 32cc042a8fe42eed90fc4bc94f2d71ac 1 RAT (x64) RAT-KrCERT-x64 32f6b229913d68daad937cc72a57aa452 3[rd] stage 91a9d623109ed48938815aa7b6005c 2 Downloader (x64) 2[nd] stage 3 Downloader (x64) 2[nd] stage 4 Downloader (x86) 2[nd] stage 5 RAT (x86) 3[rd] stage DownloaderMalwarebytes-x64 RAT-Kasperskyx86 1177105e51fa02f9977bd435f9066123ac e32b991ed54912ece8f3d4fbeeade4 DownloaderKaspersky-x64 588cdbd3ee3594525eb62fa7bab148f6d 7ab000737fc0c311a5588dc96794acc DownloaderKaspersky-x86 49a13bf0aa53990771b7b7a7ab31d6805 ed1b547e7d9f114e8e26a98f6fbee28 464eaa82103f6f479e0d62dd48d2dab8e ce300458136c03165d20915ee658067 _Figure 10: Cluster representatives used in the subsequent analysis._ ----- ### TIGERDOWNLOADER VARIANTS In this section, we take a closer look at the two downloader variants: Downloader-Malwarebytes-x64 and Downloader-Kaspersky-x64. From the cluster and code reuse analysis (see Figure 8) we know that they share 97% of code and thus are minor variants of the TigerDownloader family. Using the binary diffing capabilities of our analysis toolchain, we see in Figure 11 that the samples are largely made up of the same functions, except for one unique function (the one with the address 0x140001230) in the Kaspersky (Downloader-Kaspersky-x64) sample. _Figure 11: Function level diff between Downloader-Kaspersky-x64 and Downloader-Malwarebytes-x64._ Analyzing the downloader sample from Kaspersky (see Figure 12), we see that the unknown function (0x140001230) is called from the main function of the downloader. _Figure 12: Left, Downloader-Kaspersky-x64; right, Downloader-Malwarebytes-x64._ ----- It turns out that this function is used to achieve persistence. The technique being used is straightforward and consists of creating a link in the current user startup folder to make sure that the downloader is started upon reboot of a victim machine (see Figures 13 and 14). _Figure 13: Function which creates a shortcut for persistence._ _Figure 14: Shortcut to persistent executable._ Finally, we note that we haven’t found any persistence techniques in the Downloader-Malwarebytesx64 sample. The reason is likely to minimize indicators being left on victim machines. ----- ##### POSSIBLE CONNECTIONS TO THE KRCERT TIGERDOWNLOADER Unfortunately, the downloader sample (f0ff67d4d34fe34d52a44b3515c44950) from the KrCERT report is not available publicly, thus we could not include it into our analysis. To nevertheless examine possible relations between KrCERT and the Malwarebytes and Kaspersky downloaders, we attempted to connect them purely based on the artifacts and behaviors publicly reported by KrCERT. Let’s start with a negative result. KrCERT reports a couple of C2 commands which they have found in their downloader (see Figure 15). We couldn’t find any of the “Tiger10X” identifiers in the downloaders at our disposal. Neither were we able to find any other identifiers which could be possible C2 commands. **Identifier** **Action** Tiger101 Send victim info Tiger102 Receive command Tiger103 File upload _Figure 15: TigerDownloader C2 commands reported by KrCERT._ On the other hand, we have found various aspects reported by KrCERT that are also present in the other downloaders: ###### • The packer in the KrCERT reports fits into the packer scheme which we have established above. - KrCERT reports that the communication is encoded using Base64, which we have also observed in our samples. - The 3rd stages (RATs) which are downloaded by the 2nd stages (downloaders) all belong to the same TigerRAT family (as we shall establish in the following section). In a nutshell, the observations above suggest that the KrCERT Downloader might be related to the downloaders observed by Malwarebytes and Kaspersky. However, this is speculative because we lack hard evidence since we don’t have access to the KrCERT sample. ----- For this analysis, we’ll focus on the representatives RAT-Kaspersky-x64, RAT-KrCERT-x64 and RATKaspersky-x86 which we established earlier (see Figure 10). ##### COMMANDS AND CAPABILITIES PER VARIANT Let’s look at the C2 commands which we have found in the different variants. Figure 16 shows all the C2 commands that we have observed in at least one of the three RAT variants. The absence of the commands with the ids 0x08 and 0x09 lead us to speculate that there are yet unknown samples in the wild which do include these commands. **Command** **ID** SelfDelete 0x01 SystemInfo 0x02 Shell 0x03 FileManager 0x04 Keylogger 0x05 SocksTunnel 0x06 ScreenCapture 0x07 PortForwarder 0x0a _Figure 16: Summary of all C2 commands which are available in at least one of the three RAT variants._ ### TIGERRAT VARIANTS We recall from the code reuse and cluster analysis (see Figure 8) that we could connect all RATs to the same TigerRAT family through code-reuse analysis. We have also seen that there are RAT variants that differ more substantially than the downloader variants. For instance, the variants RAT-Kaspersky- x64 and RAT-KrCERT-x64 share only about 50% of their code. In this section, we take a closer look at the RAT variants. We present strong new evidence on the functional and design levels that further attributes the RAT variants at our disposal to the same TigerRAT malware family. We also show that variants mainly differ in terms of the C2 commands they implement. ----- RAT-KrCERT-x64 FileManager, Keylogger, PortForwarder, ScreenCapture, SelfDelete, Shell, SocksTunnel, SystemInfo _Figure 17: C2 commands found in the different RAT variants._ We see that the three variants which we have automatically identified using cluster analysis are indeed three functionally distinct variants. Apart from these variations in C2 capabilities, the core code of the variants is largely identical. Thus, it is essentially the C2 commands that define the three variants. We also observe that the four commands “FileManager,” “ScreenCapture,” “SelfDelete” and “Shell” are common to all variants. ##### A COMMON INTERFACE FOR C2 COMMANDS We have found an interface that is common to all three variants, as follows: Next, we’re looking at the C2 commands which are supported by the different variants (see Figure 17). **RAT variant** **Commands** RAT-Kaspersky-x86 FileManager, ScreenCapture, SelfDelete, Shell RAT-Kaspersky-x64 FileManager, Keylogger, ScreenCapture, SelfDelete, Shell, SocksTunnel, SystemInfo RAT-KrCERT-x64 FileManager, Keylogger, PortForwarder, ScreenCapture, **struct t_Module_GenericCommandInterface** { t_GenericCommand *Command; _DWORD id; // Command id t_MainStructure *MainStructure; _BYTE unk_data[0x10]; _BYTE initialized; }; **struct t_GenericCommand** { **void (*init)(t_Module_GenericCommandInterface *a1);** **void (*execute)(t_Module_GenericCommandInterface *a1);** **void (*enable)(t_Module_GenericCommandInterface *a1);** **void (*disable)(t_Module_GenericCommandInterface *a1);** **void** *enabled; }; The interface provides an abstraction that is implemented by all C2 commands found in the RATs. This common interface establishes a strong relation between the variants within their core C2 functionalities. ----- **struct t_TCP** { **void (*constructor)(t_Module_TCP *a1);** **void (*set_cncs)(t_Module_TCP *a1);** **void (*connect_to_cnc)(t_Module_TCP *a1);** **void (*check_response_from_cnc)(t_Module_TCP *a1);** **void (*listen_to_new_commands)(t_Module_TCP *a1);** **void (*close_socket)(t_Module_TCP *a1);** **void (*send_data)(t_Module_TCP *a1, t_EncData *a2, int a3);** **void (*process_recv_command)(t_Module_TCP *a1);** **void (*enable_commands)(t_Module_TCP *a1);** **void** *var_1; }; **struct t_TCP_Variant_KrCERT-x64** { **void (*constructor)(t_Module_TCP *a1);** **void (*set_cncs)(t_Module_TCP *a1);** **void (*connect_to_cnc)(t_Module_TCP *a1);** **void (*check_response_from_cnc)(t_Module_TCP *a1);** **void (*new_check_from_cnc_response)(t_Module_TCP *a1); // new in RAT-KrCERT-x64 variant** **void (*listen_to_new_commands)(t_Module_TCP *a1);** **void (*close_socket)(t_Module_TCP *a1);** **void (*send_data)(t_Module_TCP *a1, t_EncData *a2, int a3);** **void (*process_recv_command)(t_Module_TCP *a1);** **void (*enable_commands)(t_Module_TCP *a1);** **void** *var_1; }; ##### NEW C2 PROTOCOL VARIANT IN RAT-KRCERT-X64 The C2 protocol is essentially identical across all variants. The exception is a minor protocol change which we spotted in the RAT-KrCERT-x64 variant. The change concerns the registration of the malware with the C2 and consists of an extra check located in the TCP module, which is responsible for all communication with the C2: **struct t_TCP** { **void (*constructor)(t_Module_TCP *a1);** **void (*set_cncs)(t_Module_TCP *a1);** **void (*connect_to_cnc)(t_Module_TCP *a1);** **void (*check_response_from_cnc)(t_Module_TCP *a1);** In Figure 18, the red rectangle contains the new protocol check which was added to the RAT-KrCERTx64 variant. _Figure 18: Left, other variants; right, RAT-KrCERT-x64 variant._ ----- The new function essentially sends a 17-byte length chunk to the C2. We have not analyzed what data is sent, but it looks like it could be related to a bot identifier or something similar. Once the data is sent, it checks that the C2 returns the string "n0gyPPx" (see Figure 19). _Figure 19: C2 protocol check for "n0gyPPx."_ In addition to this protocol change, we have also observed a change in the HTTP header that is sent at the beginning of the communication in the very first request by the RAT-KrCERT-x64 variant (see Figure 20). **RAT variant** **HTTP header** RAT-KrCERT-x64 HTTP 1.1 /index.php?member=sbi2009 SSL3.3.7 RAT-KrCERT-x64, RAT-Kaspersky-x86 HTTP 1.1 /member.php SSL3.4 _Figure 20: HTTP header variants._ Based on this protocol analysis, we believe that RAT-KrCERT-x64 is a slightly newer version of the RAT which is at the same time clearly related to the other versions. ----- The analysis in this report is based on the malware samples at our disposal at the time of writing. During our analysis, we found indicators suggesting that additional, not yet publicly known, variants may exist. Since threat analysis and attribution is data driven and evolving work, additional samples may complete our current findings or lead to new findings. We invite you to contact us with additional information, particularly if you can share suspected or confirmed TigerDownloader or TigerRAT binaries. ### CONCLUSIONS Our analysis revealed new evidence and insights enabling us to attribute the previously reported Andariel APT binaries by Malwarebytes, Kaspersky and KrCERT to two new malware families. We call these the TigerDownloader and TigerRAT families, using names originally introduced by KrCERT. We have also seen that all the binaries are related by the same packing scheme. Our results are based on both automated code-reuse analysis and manual analysis of the malware tooling reported in the previous reports. To facilitate further research and defense capabilities, we are sharing our unpacking and config- extraction scripts as well as data with the community (https://github.com/threatray/tigerrat). ----- On the other hand, we have found that the compilation dates of the unpacked samples appear reasonable and likely correspond to the effective compilation dates. In fact, the unpacked compilation timestamp is always before the first seen date. In many cases, it is 1 to 2 days before the first seen date which makes sense due to the time delay between the infection/detection and reporting/submission to platforms like VirusTotal. Also, none of the dates are in the future or unrealistically old. While these still could be false flags, it is reasonable to assume that the compilation dates of the unpacked samples correspond to their effective production date. We also see that most of the 3rd stage (TigerRAT) samples were detected before the 2nd stage (TigerDownloader) samples. This could indicate that until a host becomes infected by the 3rd stage, the 2nd stage samples are not detected. It could also be due to the fact that 2nd stage samples are stealthier and have fewer features/functions. The raw data is shown in the table below. ### APPENDIX ##### ALLEGED COMPILATION DATES We have looked at the compilation timestamps of the packed samples and concluded that they are randomly chosen. For instance, some timestamps are in the future (e.g., “2024/06/09”) and others many years in the past (e.g., “1996/10/17”). On the other hand, we have found that the compilation dates of the unpacked samples appear reasonable and likely correspond to the effective compilation dates. In fact, the unpacked compilation timestamp is always before the first seen date. In many cases, it is 1 to 2 days before the first seen date which makes sense due to the time delay between the infection/detection and **Packed hash** **Unpacked** **Arch.** **Stage** **Compilation** **Compilation** **time** **(unpacked** **sample)** **First seen** **(packed)** **First seen** **(unpacked)** **hash** **time** **(packed** **sample)** f4765f7b089d 99b1cdcebf3a d7ba7e3e23c e411deab29b 7afd782b233 52e698f ed5fbefd61a7 2ec9f8a5ebd7 fa7bcd632ec5 5f04bdd4a4e 24686edccb0 268e05 008e906f2727 d502f130a549 eeebfda23362 e24b2f1ac6e2 c198ea82acc8 a06a b59e8f44822a d6bc3b4067b fdfd1ad286b8 ba76c1a3faff8 2a3feb7bdf96 b9c5 5c2f339362d0 cd8e5a8e310 5c9c5697108 7bea2701ea3 b7324771b0e a2c26c6c 1177105e51fa 02f9977bd43 5f9066123ace 32b991ed549 12ece8f3d4fb eeade4 1177105e51fa 02f9977bd43 5f9066123ace 32b991ed549 12ece8f3d4fb eeade4 63bae252d79 6bc9ac331fdc 13744a72bd8 5d1065ef41a8 84dc11c6245 ea933e2 x64 Downloader (2nd stage) x64 Downloader (2nd stage) x64 Downloader (2nd stage) x64 Downloader (2nd stage) 1996-04-05 2020-12-13 2021-04-21 2021-06-19 1996-10-17 2020-12-03 2021-04-13 2021-04-22 1996-10-17 2020-12-03 2021-04-20 2021-04-22 1996-04-05 2020-12-11 2021-04-19 2021-04-19 ----- 350082b3f14 e130c6337ef8 8d46d54d353 ca678550826 4112dfbd20c e4e47b98 f40d387631d db0db70128e 72239d0cae7 a22b2135c0e c0d540e018a a727d4c8e 0996a8e5ec1 a41645309e2 ca395d3a6b7 66a7c52784c 974c776f258c 1b25a76c 4da0ac4c3f47 f69c992abb5d 6e9803348bf 9f3c6028a721 4dcabec9a2e 729b99 ab194f2bad3 7bffd32fae98 33dafaa04c79 c9e117d86aa 46432eadef64 a43ad6 4d03a981bed 15a3bd91f36 972d7391b39 791c582bb29 59a9be154a7 4bd64db31 1f8dcfaebbcd 7e71c2872e0 ba2fc6db81d 651cf654a21d 33c78eae666 2e62392 63bae252d79 6bc9ac331fdc 13744a72bd8 5d1065ef41a8 84dc11c6245 ea933e2 588cdbd3ee3 594525eb62fa 7bab148f6d7 ab000737fc0c 311a5588dc9 6794acc 588cdbd3ee3 594525eb62fa 7bab148f6d7 ab000737fc0c 311a5588dc9 6794acc 588cdbd3ee3 594525eb62fa 7bab148f6d7 ab000737fc0c 311a5588dc9 6794acc 49a13bf0aa53 990771b7b7a 7ab31d6805e d1b547e7d9f 114e8e26a98f 6fbee28 4aadf7674910 77ab83c6436 cf108b014fc0 bf8c3bd01cc6 087a0f2b8056 4bc08 f32f6b229913 d68daad937c c72a57aa452 91a9d623109 ed48938815a a7b6005c 6310cd9f8b6a 63bae252d79 x64 Downloader 1996-04-05 2020-12-11 2021-04-19 2021-04-19 e1fdc1b55fe1 6bc9ac331fdc (2nd stage) 90026a119f7e 13744a72bd8 a526cd3fc22a 5d1065ef41a8 215bda51c9c 84dc11c6245 28214 ea933e2 350082b3f14 63bae252d79 x64 Downloader 1996-04-05 2020-12-11 2021-05-11 2021-04-19 e130c6337ef8 6bc9ac331fdc (2nd stage) 8d46d54d353 13744a72bd8 ca678550826 5d1065ef41a8 4112dfbd20c 84dc11c6245 e4e47b98 ea933e2 x64 Downloader (2nd stage persistence) x64 Downloader (2nd stage persistence) x64 Downloader (2nd stage persistence) x86 Downloader (2nd stage) x64 RAT (3rd stage) x64 RAT (3rd stage – Variant 3) 1996-10-13 2020-11-24 2021-04-27 2021-04-27 1996-10-13 2020-11-24 2021-04-27 2021-04-27 1996-10-13 2020-11-24 2021-04-28 2021-04-27 1996-09-08 2020-07-20 2020-07-22 2020-07-22 2023-11-28 2020-10-18 2020-10-19 2021-06-17 1997-09-30 2021-01-18 2021-06-30 2021-10-21 ----- da787cf1f4fd8 29dd4a7637b ec392438b79 3c5f9c920560 197545d20b5 8691af 69bac736f42e 37302db7eca 68b6fc138c3a a9a5c902c149 e46cce8b42b 172603 b0d6aee39e9 88196fdc8218 95a1f1aa63d1 c032ea880c2 6a15c857068f 34bfd9 0e447797aa2 0bff41607328 1adb09b73c1 5433ab855b5 cdb2d883f8c2 af9c414 f13aff9e1192c 081c012f974b 29bf6048738 5eed644d506 d7f82b3538c2 b035f 9137e886e41 4b12581852b 96a1d90ee87 5053f16b79b e57694df9f93 f3ead506 d26987b705f 537b10a11fb 9913d0acc02 18a0c0ae5f27 e6f821d6d98 7b1cd4c7 fec82f2542d7f 82e9fce3e16b fa4024f253ad ee7121973bd 9d67a3c7944 1b83c 8b3c8046fa77 6b70821b7e5 0baa772a395 d3d245c10bd aa4b6171e0c 5ce3f717 bbddcb280af 742ce10842b 18b9d712063 2cc042a8fe42 eed90fc4bc94 f2d71ac bbddcb280af 742ce10842b 18b9d712063 2cc042a8fe42 eed90fc4bc94 f2d71ac bbddcb280af 742ce10842b 18b9d712063 2cc042a8fe42 eed90fc4bc94 f2d71ac bbddcb280af 742ce10842b 18b9d712063 2cc042a8fe42 eed90fc4bc94 f2d71ac bbddcb280af 742ce10842b 18b9d712063 2cc042a8fe42 eed90fc4bc94 f2d71ac d231f3b6d6e ed11e94fd9aa x64 RAT (3rd 2021-10-12 2020-12-13 2021-04-21 2021-06-21 4c56cb7f149c 3c7d4dd0b43 stage – bc0178f7b804 45c106631fe5 Variant 3) 48c24f14dced 2929c6e26a0 5a864015512 daec2ed7d22 b0ba1f e47ada0 da787cf1f4fd8 fec82f2542d7f x64 RAT (3rd 1997-04-29 2020-11-24 2021-04-21 2021-04-21 29dd4a7637b 82e9fce3e16b stage – ec392438b79 fa4024f253ad Variant 3) 3c5f9c920560 ee7121973bd 197545d20b5 9d67a3c7944 8691af 1b83c x64 RAT (3rd stage – Variant 2) x64 RAT (3rd stage – Variant 2) x64 RAT (3rd stage – Variant 2) x64 RAT (3rd stage – Variant 2) x64 RAT (3rd stage – Variant 2) x64 RAT (3rd stage – Variant 2) 1995-08-15 2020-09-21 2020-09-26 2021-06-17 2024-06-09 2021-01-11 2021-01-21 2021-01-21 2024-06-09 2021-01-11 2021-01-25 2021-01-21 2024-06-09 2021-01-11 2021-01-25 2021-01-21 2024-06-09 2021-01-11 2021-01-25 2021-01-21 2024-06-09 2021-01-11 2021-01-25 2021-01-21 ----- 87f389d8f3a6 3f0879aa9d9d fbbd2b2c9cf6 78b871b704a 01b39e1eaa2 34020c 2f53109e01c4 31c1c1acec66 7adee07cf907 cdc4d364290 22f915654c9b 7113b ebe4befd2a7f 941baa65248 d5dea09de80 9e638ec8e8c affae322aa3b 6863c1c 1892b72c053 ab48edae830 5ef449f2b539 1921efea8b1 d7c37d6d29f 59edc92e e83f5e0a5184 5d7078a3aca 8ca7a5b786e 8bdf284efd3e 08b3472dbf3 e098930 - 868a62feff8b4 x64 RAT (3rd 2021-01-11 2021-01-25 6466e9d63b8 stage – 3135a7987bf6 Variant 2) d332c13739a a11b747b3e2 ad4bbf 87f389d8f3a6 464eaa82103f x86 RAT (3rd 2000-07-07 2020-08-27 2020-09-24 2020-09-24 3f0879aa9d9d 6f479e0d62d stage – fbbd2b2c9cf6 d48d2dab8ec Variant 1) 78b871b704a e300458136c 01b39e1eaa2 03165d20915 34020c ee658067 d0fa0bfef8b1 99a42f4f3314 5274576e5a7 edeb5522fb3 42af41fdc16e 9021e2 f62adc678eaa dc019277640 e6695143a45 336c2f91019f 5d9308812db 1d07285 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 x86 RAT (3rd stage – Variant 1) x86 RAT (3rd stage Variant 1) x86 RAT (3rd stage – Variant 1) x86 RAT (3rd stage – Variant 1) x86 RAT (3rd stage – Variant 1) x86 RAT (3rd stage – Variant 1) 2000-07-07 2020-08-27 2020-09-25 2020-09-25 2000-07-07 2020-08-27 2020-09-25 2020-09-25 2000-07-07 2020-08-27 2020-09-24 2020-09-24 2000-07-07 2020-08-27 2020-09-24 2020-09-24 2000-07-07 2020-08-27 2020-09-24 2020-09-24 2000-07-07 2020-08-27 2020-09-25 2020-09-25 ----- 7d7dc8125a2 6d9515d90a6 6bfd20d6098 20197c87903 0cb932d39b1 c2998e9d4 464eaa82103f 6f479e0d62d d48d2dab8ec e300458136c 03165d20915 ee658067 0dc3f66f4af32 464eaa82103f x86 RAT (3rd 2000-07-07 2020-08-27 2020-09-24 2020-09-24 50f56a32f8e1 6f479e0d62d stage – b9e772c514f7 d48d2dab8ec Variant 1) 4718358d19c e300458136c 195e3950d37 03165d20915 0ea01 ee658067 7d7dc8125a2 464eaa82103f x86 RAT (3rd 2000-07-07 2020-08-27 2020-09-24 2020-09-24 6d9515d90a6 6f479e0d62d stage – 6bfd20d6098 d48d2dab8ec Variant 1) 20197c87903 e300458136c 0cb932d39b1 03165d20915 c2998e9d4 ee658067 ----- ##### EXTRACTED C2S Another indicator to group these samples could be the C2 used by each sample. To do so, we created a config extractor for these samples. The following table shows the C2s for each sample. The 2nd stage samples use a domain whereas the 3rd stage samples directly use an IP address. NOTE: In the configuration of the 3rd stage there are 4 hardcoded IPs. In almost all cases, three of them are the same IP which belong to the C2. The remaining IP is empty in some cases, and in others it looks like a network mask (e.g. 1.0.0.0, 2.0.0.1, 4.0.0.0, 16.0.0.0). We omitted these in the following table. You can find the “raw” configuration here: https://github.com/threatray/tigerrat/blob/main/iocs/payload_configs.csv **Unpacked hash** **Arch** **Stage** **Variant** **C2** f32f6b229913d68daad937c c72a57aa45291a9d623109 ed48938815aa7b6005c ed11e94fd9aa3c7d4dd0b4 345c106631fe52929c6e26a 0daec2ed7d22e47ada0 fec82f2542d7f82e9fce3e16 bfa4024f253adee7121973b d9d67a3c79441b83c 4aadf767491077ab83c6436 cf108b014fc0bf8c3bd01cc6 087a0f2b80564bc08 RAT-KrCERTx64 (TigerRAT) RAT-KrCERTx64 (TigerRAT) RAT-KrCERTx64 (TigerRAT) RATKasperskyx64 (TigerRAT) RATKasperskyx64 (TigerRAT) RATKasperskyx64 (TigerRAT) RATKasperskyx64 (TigerRAT) RATKasperskyx86 (TigerRAT) DownloaderKasperskyx64 52.202.193.124 185.208.158.208 185.208.158.208 10.101.30.127 8b3c8046fa776b70821b7e5 0baa772a395d3d245c10bd aa4b6171e0c5ce3f717 23.229.111.197 bbddcb280af742ce10842b 18b9d7120632cc042a8fe42 eed90fc4bc94f2d71ac 45.58.112.77 868a62feff8b46466e9d63b 83135a7987bf6d332c13739 aa11b747b3e2ad4bbf 45.58.112.77 464eaa82103f6f479e0d62d d48d2dab8ece300458136c 03165d20915ee658067 23.229.111.197 5c2f339362d0cd8e5a8e310 5c9c56971087bea2701ea3 b7324771b0ea2c26c6c x64 RAT (3rd stage) x64 RAT (3rd stage) x64 RAT (3rd stage) x64 RAT (3rd stage) x64 RAT (3rd stage) x64 RAT (3rd stage) x64 RAT (3rd stage) x86 RAT (3rd stage) x64 Downloa der (2nd stage) hxxp://mail.sisnet.co.kr/jsp/user/sms/sms_recv.jsp hxxp://mail.neocyon.com/jsp/user/sms/sms_recv.jsp ----- 49a13bf0aa53990771b7b7a 7ab31d6805ed1b547e7d9f 114e8e26a98f6fbee28 x86 Downloa der (2nd stage) DownloaderKasperskyx86 hxxp://www.allamwith.com/home/mobile/list.php 1177105e51fa02f9977bd43 x64 Downloa Downloader- hxxp://www.jinjinpig.co.kr/Anyboard/skin/board.php 5f9066123ace32b991ed549 der (2nd Kaspersky- hxxp://mail.namusoft.kr/jsp/user/eam/board.jsp 12ece8f3d4fbeeade4 stage) x64 63bae252d796bc9ac331fdc x64 Downloa Downloader- hxxp://snum.or.kr/skin_img/skin.php 13744a72bd85d1065ef41a der (2nd Malwarebyte hxxp://www.ddjm.co.kr/bbs/icon/skin/skin.php 884dc11c6245ea933e2 stage) s-x64 588cdbd3ee3594525eb62f x64 Downloa Downloader- hxxp://www.jinjinpig.co.kr/Anyboard/skin/board.php a7bab148f6d7ab000737fc0 der (2nd Kaspersky- hxxp://mail.namusoft.kr/jsp/user/eam/board.jsp c311a5588dc96794acc stage) x64 (Persistence) 49a13bf0aa53990771b7b7a x86 Downloa Downloader- hxxp://www.conkorea.com/cshop/banner/list.php ----- ##### MITRE ATT&CK MAPPING The table below shows the MITRE ATT&CK Mapping after combining all these attacks/campaigns from previous reports and our analysis. **Technique** **Tactic** **Technique Name** T1584.006 Resource Development Compromise Infrastructure: Web Services T1583.003 Resource Development Acquire Infrastructure: Virtual Private Server T1566.001 Initial Access Phishing: Spearphishing Attachment T1189 Initial Access Drive-by Compromise T1204.002 Execution User Execution: Malicious File T1059.007 Execution Command and Scripting Interpreter: JavaScript T1036.005 Defense Evasion Masquerading: Match Legitimate Name or Location T1027.003 Defense Evasion Obfuscated Files or Information: Steganography T1497.001 Defense Evasion Virtualization/Sandbox Evasion: System Checks T1049 Discovery System Network Connections Discovery T1057 Discovery Process Discovery T1113 Collection Screen Capture T1056.001 Collection Input Capture: Keylogging T1071.001 Command and Control Application Layer Protocol: Web Protocols T1095 Command and Control Non-Application Layer Protocol T1573.001 Command and Control Encrypted Channel: Symmetric Cryptography T1041 Exfiltration Exfiltration Over C2 Channel T1486 Impact Data Encrypted for Impact ----- ### ABOUT THREATRAY Threatray is a novel malware analysis and intelligence platform. We support all key malware defense use cases, including identification / detection, hunting, response, and analysis. Threatray helps security teams of all skill levels to effectively identify and analyze ongoing and past compromises. At the core of Threatray are highly scalable code similarity search algorithms that find code reuse between a new and millions of known samples in seconds. Our core search algorithms do not make use of traditional byte pattern matches and are thus highly resilient to code mutations. Our user facing features are based on the core search technology. They include best of class threat family identification and detection, easy to use real-time retro-hunting and retro-detection, cluster analysis to quickly find relevant IOCs, and low-level multi-binary analysis capabilities. Some of our binary analysis capabilities have been used for the research presented in this report. Contact us at https://threatray.com/contact-us or https://twitter.com/threatray -----