Types of Recent .NET Packers and Their Distribution Trends in Korea

0. Overview

This post is a summary of the TI report, ‘Report on the Trends and Types of Recent .NET Packers.’ Please refer to the report in the hyperlink for more details on the topic.

Recently, packers made with .NET are being found in various places both in and outside Korea. Thus, the ASEC analysis team aims to introduce the five most commonly distributed .NET packers and their distribution trends in Korea. We will overview the types of malware distributed with .NET packers and explain the flow of packers in this document with real examples. Afterward, we will conclude by determining the characteristics of each packer before examining their trends in Korea.

1. Significance of .NET Packers in and Outside Korea

According to the statistical data for October 2022 in Korea and overseas, malware strains being distributed via .NET are as follows.

Statistics showed that there were malware compiled with .NET from the beginning, such as AgentTesla and SnakeKeyLogger, as well as types that were compiled in a language other than .NET, such as Formbook (Xloader) and Lokibot. While they were created in different environments, the common trait of these two types is that they are both distributed with .NET packers. Currently, such types make up a considerable portion of malware distribution. For reference, they are not only distributed with .NET packers alone; there are also many cases where an extra stage is added before the execution of .NET, going through processes such as Excel, VBS, Powershell, or Bat2Exe. Such cases were also covered by previous ASEC blog posts.

2. Basic Structure and Flow of .NET Packers

2.1. Basic Structure

.NET packers are known for having an internal binary; in other words, their resources are protected.

In the recent .NET packers, there are multiple pieces of data in the executable. This data contains data or loader binaries, and these binaries contain different data or loaders. The data and loaders here are executables in DLL or EXE formats. Loaders usually perform the role of decoding other executables and loading them onto the memory. and sometimes, this process includes analysis disruption techniques. As for the data, it does not have executable codes but rather only has resource data composed of bitmap images, hex values, or strings. Thus, while both binaries are loaded onto the memory, the loader is the only module where the code flow branches, meaning that data DLL can be seen as storage with only the encoded data.

Therefore, packers from hereon will be expressed with the following rules as shown in Figure 2.

For reference, simple resource data that is not made into executables is not included in the diagram. For example, even if the encoded strings or constants exist as resources for executables and are used, they will not be marked on the flow chart as shown in the above figure.

2.2. Flow

Each packer has unique characteristics, fixed methods and variable names, and disruption techniques. Out of these, we will first cover the two characteristics that can be quickly identified and aid understanding.

These characteristics are expressed in the packer flow below.

First is the ‘internally encoded binary information.’ Certain .NET packers have the same characteristics depending on the period during which they were distributed. The most typical characteristic of these is the file name information of the DLL (loader and data) that is to be loaded onto the memory. Although the surface appearances of most .NET packers differ every time they are distributed, the loader (internal binary) can be distinguished because they use the same information during a set period of time.

The second is the ‘process flow and the location of the encoded data,’ which cannot be easily changed in packers. Generally, when malware is packed, there are builders that pack them, creating the malware according to set structures and also providing options to modify the necessary parts. However, the options include folders to create injection target processes or malicious files in and whether or not to display message boxes; most of the time, there are no features that change the code flow or the location of the decoded data. Therefore, this can be said to be a major characteristic, and even if they are partially modified, similar types can be grouped together.

Below are the five most commonly distributed .NET packers in Korea nowadays.

Before continuing on with the characteristics of packers, we will briefly examine the above two major characteristics based on the flow chart and actual packers.

The following is the flow of the Type 1 packer.

The flow of Figure 4 above is as follows.

The first thing to note here is the name of the loader, which is the internal binary. Type 1 packers have two loaders as shown in Figure 4 as numbers ① and ②. File information of these loaders can be checked using ‘Dnspy,’ a .NET debugging tool, or by dumping the memory’s binaries. The identified information is as follows.

This internal data seems to have different names according to when they were distributed by the threat actor. The following shows information identified from 2021 until now.

Four types of no. 1 loaders shown in Table 3 were collected. They are listed in chronological order from top (Bunifu_UI.dll) to bottom (Cassa.dll), so the most recently distributed file is ‘Cassa.dll’. The second loader has been using the same original filename, ‘MajorRevision.exe’. By first checking the filenames, packers can be quickly categorized.

The second thing to point out is the ‘process flow and the location of the encoded data of packers. Some packers are being distributed with slightly modified flows, but they do not deviate far from the standard. It was recently identified that Type 1 packers have lengthened their flow by adding another piece of data, and the new flow is as follows.

As can be seen in the flow at the bottom of Figure 6, there recently was an addition of Data 1. This means there is an extra step that requires Data 1 to be decoded, loaded onto the memory, and the internal resources of Data 1 to be referenced in order for the flow to branch to the second loader. Accordingly, there are two executables each for the loader and data.

For reference, the characteristics of the obfuscation tools (.NET Reactor, ConfuserEx, etc.) used to obfuscate binaries cannot be used to distinguish packers. This is because different obfuscation tools may be used for each internal binary in .NET packers, meaning that there is no consistency.

Next, we will examine the types and characteristics of packers.

3. Types and Characteristics of Packers

3.1. Types

There are five major .NET packers that are recently being distributed in Korea, and they are shown below.

.NET packers these days all have time delay features such as Sleep() and use the callback function. It is assumed that the callback function is being used to hinder malware analysis and to make the code flow more flexible.

3.2. Characteristics

Now, we will move on to explain the three characteristics of each packer.

3.2.1. Type 1 (MajorCrypter)

1) flow

Type 1 packer had been briefly covered by Cyble—a non-Korean intelligence company—in their post about Xloader (Formbook), but it does not have a defined name as of yet.

In this report, we will hereby refer to the type as MajorCrypter after Loader 2’s (EXE) name, ‘MajorRevision.exe’. MajorCrypter is thought to have been distributed outside Korea since 2020 or early 2021 and is still currently in circulation. It used to have a 3-step process, but recently has added an extra step.

2) DLL File Information

The file information of MajorCrypter’s loaders collected by the ASEC analysis team as of the present is shown in Table 5.

3) Parameter Names of Decoding Method

In the case of MajorCrypter, the parameter names of Loader 1’s decoding method are always the same. Just before the code branches from Loader 1 to Loader 2, MajorCrypter uses the three arguments shown below. The arguments used to decode Loader 2 are as follows.

As shown in Figure 8 above, the first parameter (resource_name) of the decoding method (AddContext) is the name of the bitmap resource, and it points to the location of the encoded Loader 2. This is as shown in the red string, “WFiLAKn” in Figure 9, below.

The second parameter is used to decode Loader 2 which is encoded with an XOR key. Finally, the third parameter is the root resource name needed to find the bitmap resource. This is shown in Figure 9 as “JumboSports”.

These three parameters (‘resource_name’, ‘(special char)_param’, ‘project_name’) have been used with the same name in the past to call Loader 2. Decoding is performed by using a method such as Bitmap.GetPixel() to make RGB colors into a one-dimensional array before using XOR and decompression to decode Loader 2. Additionally, Data 2, which is the internal binary of Loader 2, contains the malware (payload) to be ultimately executed (refer to Figure 7).

3.2.2. Type 2 (DarkTortilla)

1) Flow

Type 2 was first named ‘DarkTortilla’ in August 2022 by SecureWorks, a cyber security company in the US.

https://www.secureworks.com/research/darktortilla-malware-analysis

DarkTortilla is assumed to have started its propagation in Korea in 2020 and is occasionally detected even now. This packer is normally composed of four steps, but as shown in Figure 10 below, it is likely that there are variants with different formats.

2) Resource Characteristics of Loader 1

DarkTortilla’s DLLs have random file names and are not consistent. However, they have multiple bitmap images as resources, as shown below. These bitmaps are all encoded payloads and are the malware to be ultimately executed.

3) Parameters of Injection Method (Loader 2’s Main Method)

DarkTortilla transmits the following arguments when the code branches from the Loader 1 class to the Loader 2 class (Loader1.Class11_Install -> Loader 2.Class1_RunCommand).

The first argument is the path of the target file for injection. The second is the command line command argument (cmd) of the target process for injection. The third is the binary of the payload (data) to be used in injection, and the fourth argument is the unique option of the packer. DarkTortilla always uses at least 4 parameters (path, cmd, data, compatible).

In most cases, Loader 2 has the anti-tamper feature enabled. The anti-tamper feature prevents tampering with binaries and does not allow static viewing of the code upon decompiling. This is restored through the constructor (.cctor) that is executed first during runtime.

After the restoration is complete, the Runn() method of the called Loader 2’s Class1_Runcommand receives at least 4 arguments and performs the injection. Depending on the distribution period, there are types that receive five argument values. These parameters can also be seen in LogicNP’s Crypto Obfuscator, a commercial packer, which will be introduced as Type 5. These common features are thought to have been derived from RunPE of a user named Aeonhack who was active in HackForum.

3.2.3. Type 3 (VariantCrypter – a.k.a GameLoader)

1) Flow

Type 3 was introduced as GameLoader in November 2021 by a cyber security company in the US named Gosecure because it is usually disguised as game programs.

https://www.gosecure.net/blog/2021/11/02/new-malware-gameloader-in-discord-malspam-campaign-identified-by-gosecure-titan-labs/

This packer was disguised as not only games, but also various other programs, and is known for having the closest resemblance to the real programs out of all packers in distribution. As Type 3 is the most commonly distributed in Korea and attempts to variegate the most often, we will refer to it as VariantCrypter in this report. 

2) DLL File Information and Modification

VariantCrypter changes its Loader file information after a certain amount of time and propagates itself.

VariantCrypter was distributed in five different formats in 2022. These can be classified into Type A to E according to the name and features of the loader. As each type does not use DLLs from other types and there are no duplicate names among them, it is possible to deduce which type and loader it is by checking the name when the binary is extracted.

Below is an example.

We can identify that the loader in Figure 17 is Type C. Depending on its variant, the flow of VariantCrypter falls into one of three types.

VariantCrypter went through a change from Type A to Type E, so most of the currently distributed versions are Type E. Type E has three executable binaries (loaders), and the decoding feature that was previously included in Loader 1 was taken out and Loader 2 was created. This basically means that Type E’s Loader 2 in Figure 18 is a module with only the decoding feature.

3) Three Types of Loader 1’s Decoding Method Arguments

First, VariantCrypter performs a decoding process to load Loader 1. One thing to note at this stage is that VariantCrypter uses a hard-coded key of a set length.

The hard-coded key is a 22-byte string and is used for the MOD arithmetic. After Loader 1 is loaded onto the memory, it loads Loader 2 and Loader 3 onto the memory as well. Thus, when Loader 1 is loaded as shown below, the external packer transmits certain argument values to Loader 1’s method.

The transmitted argument values are used when loading Loader 3, and they are the XOR key necessary for decoding Loader 3 and the location of the encoded Loader 3 binary. Here, Loader 2 is a simple decoder that uses the above argument values to decode Loader 3.

3.2.4. Type 4 (PureCrypter)

Type 4 is a commercial packer program that is being sold on the official website since 2021 under the name, “PureCrypter.” It has been covered many times in articles from countries around the world because it is being actively used in malware distribution. This packer allows the addition of a fake message box and the setting of initial vectors (downloader, VBA macro, loader), injection method and targets, and anti-techniques.

https://blog.netlab.360.com/purecrypter-is-busy-pumping-out-various-malicious-malware-families/?&web_view=true

https://www.zscaler.com/blogs/security-research/technical-analysis-purecrypter

1) Flow

In the past, there were a total of four executed modules as seen in the structure at the top of Figure 23. Here, Loader 1 and Loader 3 were responsible for the anti-tamper protection feature, while Loader 2 performed the decoding and memory-loading behaviors, and Loader 4 processed Json formats. Currently, PureCrypter is being distributed with only the ‘Loader 1’ module (decoding and memory loading features) and the ‘Loader 2’ module (processing Json formats) as shown at the bottom of Figure 23, and it is assumed that certain anti-tamper protection features have been removed. Additionally, as shown in the diagram at the very bottom, the recent version does not have a separate module for processing Json formats but rather has this feature included entirely in Loader 1.

2) DLL File Information

Recently distributed version has Loader 2’s features included in Loader 1 without a separate Loader 2 (See Figure 24).

3) Using Json Data (DESERIALIZE)

The main characteristic of PureCrypter is the use of Json format data. Json data requires a deserialization step to use method arguments for the option values for the final injection process. Therefore, PureCrypter uses Json data by using frameworks such as Protobuf-net or Newtonsoft.json. 

Protobuf-net was used in the past, but it seems that the recent version uses the Newtonsoft.json framework. Consequently, the encoded location of this module is as follows.

Furthermore, the most recently reported samples do not use the features of Newtonsoft.json as a separate module but rather have them included in Loader 1. Thus currently, the Json processing module is not included in the resources but in the code, as shown in Figure 26 above. An example of this can be seen in the figure below as well.

3.2.5. Type 5 (LogicNP’s Crypto Obfuscator)

1) Flow

Type 5 is a commercial packer like Type 4 (PureCrypter) and is a commercial program from LogicNP. It seems that this packer was been created a long time ago, and it is being distributed from time to time in Korea since the beginning-middle of this year. The main characteristic of this packer is that there is a rule to the resource name depending on the encoded information, and this allows us to identify the packer from the names.

LogicNP packer offers options for strings, variables, control flow obfuscation, anti-debugging, and more by default.

2) Resource Naming Rules

The DLL files of LogicNp’s Crypto Obfuscator have random file names that are not fixed. However, the packer includes the data needed for execution in its resources. By default, this packer names the resource data according to the features, as shown in Table 7.

A summarized, structured representation of the resource data and the actual executable is as follows.

The actual malicious file (payload) is encoded in Base64 inside the packer and is formed into an array after multiple decoding processes such as ‘Replace.’ Afterward, the packer transmits the payload to Loader 1 and performs the injection through it. There’s one thing to point out in the injection method here.

3) Parameters of Injector’s Main Method (Commonalities With Type 2)

After the payload decoding is complete, arguments are transmitted when the packer branches to Loader 1. This can be seen in the figure below.

These arguments are the same as those covered with Type 2, and they include the path of the target file for injection, the command line command (cmd) of the process to be injected, and the payload (data) to be used in the injection process. These are almost the same as the methods of Type 2 and Aeonhack’s RunPE which is available publicly on the internet.

4. Distribution Trends of .NET Packer in Korea

So far, we have covered a total of five packers: Type 1 (MajorCrypter), Type 2 (DarkTortilla), Type 3 (VariantCrypter), Type 4 (PureCrypter), and Type 5 (LogicNP’s Crypto Obfuscator).

The distribution trends of these packers in Korea are as follows.

The graph in Figure 34 shows statistical data composed from samples reported through major client companies and samples collected through email honeypot between July and November 2022. Currently, Type 3 (VariantCrypter) is the most commonly distributed packer in Korea, followed by Type 4 (PureCrypter) which is frequently mentioned by non-Korean security companies. Type 1 (MajorCrypter) showed a similar graph line to Type 4 (PureCrypter), but it’s been showing an increase in recent days. On the other hand, Types 2 (DarkTortilla) and 5 (LogicNP) are seldom used in comparison to the other packers. For reference, Type 2 needs further categorization, and while its count is lower than the others, it’s expected to rise once the categorization process is complete.

.NET packers were usually used in the following malware.

Figure 35 shows the dispersion of malware distributed in Korea using the aforementioned packers. These malware strains were mostly Infostealers and RATs, which is quite similar to the trends seen in 1. Significance of .NET Packers in and Outside Korea. The malware that showed the highest distribution case using .NET packers was AgentTesla, an info-stealing type of malware AgentTesla was by far the highest, making up 37% of the whole. Formbook, SnakeKeylogger, Lokibot, and Remcos are samples often covered in the ASEC blog posts.

Additionally, Type 1 (MajorCrypter) packers were used in distributing ransomware in late November.

This ransomware encoded files with the ‘*.OBZ’ file extension, and it appears to be a RaaS-type.

Conclusion

This blog post covers only a portion of .NET packers. Only the packers with comparatively high distribution rates were categorized, and there may still be other uncategorized packers that are active overseas but unknown in Korea due to low influx. Thankfully, Microsoft has been providing a new blocking interface, AMSI, from Windows 10 onwards. AMSI is a feature that can efficiently block obfuscated malware that have been distributed from the past, including VBS and JS scripts or Word, Excel, and Powershell scripts provided through MS Office. AhnLab V3 preemptively blocks .NET packers and obfuscated malware through this interface, and users are advised to use this product with these options enabled.

AhnLab detects the packers using the aliases below.

Trojan/Win.MSILKrypt.R478738 (2022.03.21.01)
Trojan/Win.MSILKrypt.R479010 (2022.03.22.03)
Trojan/Win.AgentTesla.C4826923 (2021.12.09.02)
Trojan/Win.MalwareX-gen.C4922823 (2022.01.19.01)
Trojan/Win.MSILKrypt.C5020026(2022.03.21.01)
Trojan/Win.MSIL.R503383 (2022.07.08.03)
Trojan/Win.MSIL.R510208 (2022.12.02.00)
Trojan/Win.MSIL.R492640 (2022.05.16.03)
Trojan/Win.MSILKrypt.R478746 (2022.03.21.01)
Trojan/Win.MSIL.R491654 (2022.05.12.00)
Trojan/Win.MSIL.R479032 (2022.07.13.03)
Trojan/Win.MSIL.R536135 (2022.11.26.00)
Trojan/Win.Loader.C5020045 (2022.03.21.01)
Trojan/Win.MSILKrypt.R479033 (2022.03.23.00)
Trojan/Win.Generic.C5197697 (2022.07.07.04)
Trojan/Win.MSILKrypt.R479202 (2022.03.23.03)
Trojan/Win.MSIL.R5288800 (2022.10.31.00)
Trojan/Win.MSIL.C5134406 (2022.05.19.03)
Trojan/Win.MSIL.R5288800 (2022.10.31.00)
Trojan/Win.MSIL.C5134406 (2022.05.19.03)
Trojan/Win.MSIL.R498082 (2022.06.15.03)
Trojan/Win.MSIL.C5198300 (2022.07.08.03)
Trojan/Win.MSIL.R510204 (2022.10.27.01)
Trojan/Win.MSIL.R510208 (2022.12.02.00)
and more

[IOC Info]

MD5

0aafb32868f183efaf80ba7176ec3a16
138ca47d7eb25b2522090f8a3688f1b9
3456bfcebe8c7d4f988ec4eab5d9c25e
461af5cc340963ea11fcd822bfdb3a62
5d39675de3c860d023f92fbc8ad33300
8b10aff2ad146b2d05700932571d7306
963296ff9287f30af86c6ae029627753
9f36c6884ecc5ac7fe027121871596ed
b43f26346d14e50a9c45658c08fbc9dd
c5c7371e2b483d74c95afe992857a887
c5f5f08ed0ff1aa0134c2d101766fa9f
dd5fce942f380f6130e6c798f2bbdb44
e3662856ae63484de56f4f69019bee4e
016da09b26d08c7f213523b281b3a209
2a6fe3324ecded60b8eb3af192750b9d
47926d4e06f1a28fc1f9bab98f08f310
577b4a8ffd3d2ede7f85c53ee88feaa7
5c3dc31e9aa2777603f97a12def0a9de
5c4d20b4a621d7b81f273b94df51e5da
69835df32c3a41f9caf849700c5c511b
74a5200a7ea77a462e3b6bef77d791e1
7fb55d4603a18e4167d6c75eac2803d8
841e9dcec96b65c9a9c2991180b2f3b2
84c2e71de354539e426781a0db952fa9
8a1d7b15b9a0c2e304462c7415b1ea60
8e81fc66692d64bfe5b5375855aa5d78
9f537825c82946571a945b1d0b5c5b73
aba6ea39e2ad2fbff27f5d26ebfa1108
bc512e753ef24ba7c089db020e07c6da
c6ab29668433ac0e7358b07d4d662cb8
cd644c1ebc45ee3d06445a91284f1767
d311c4b0e72f08e881094f31d0831d54
e2d07c1194008eacff161c48fcb8b1c5
and more

URL

hxxps://cdn.discordapp[.]com/attachments/1012175409779052625/1012220255885611028/DHL_SHIPMENT_Dgiqqkwt.png
hxxps://cdn.discordapp[.]com/attachments/1011828934763106316/1012203140214427718/hesaphareketi_Guctuslk.png
hxxp://80.66.75[.]88/Hublast_Idiwdgcw.png
hxxp://80.66.75[.]98/Gpthxnldfea.png
hxxp://80.66.75[.]217:8080/Wliukdbs.png
hxxp://80.66.75[.]103/Rsgbmepvbv.jpeg
hxxp://80.66.75[.]123/Idmna_Gtwobgsx.bmp
hxxp://80.66.75[.]230:8060/Kkrzzsc.jpeg
hxxp://80.66.75[.]238:8021/Xgevj.jpeg
hxxp://80.66.75[.]27/arx-Zanmveyvwvi.bmp
hxxp://80.66.75[.]27/arx-2-Ylqvxlmv.jpeg
hxxp://80.66.75[.]28/a-Aembvui.jpeg
hxxp://80.66.75[.]28/aa-Zgqgzeqgvc.png
hxxp://80.66.75[.]25/pl-Thjct_Rfxmtgam.bmp
hxxp://80.66.75[.]25/arx-Slkmrtswx_Vttmygcq.bmp
hxxp://80.66.75[.]25/pl-Puuyc_Ibpaiuhr.bmp
hxxp://81.161.229[.]7/Re_order_144_23-09-2022_Wuyewluh.png
hxxp://103.57.223[.]182:25258/Vgtznlkxzhi.png
hxxp://104.223.106[.]33/loader/uploads/Qmmaa_Ypaocsue.jpg
hxxp://112.136.239[.]71/Tsfifp_Rhpuibqx.png
hxxp://121.4.69[.]26:50294/Ccijxlpv.bmp
hxxp://147.124.209[.]112/DatedAugust_25th_Needed_Dqeoywpe.png
hxxp://107.172.13[.]154/Vlbmzaqrb_Gtsxcxjx.png
hxxp://107.172.13[.]154/Pjdcopfml_Xxbbkmat.png
hxxp://172.245.142[.]35/77.bmp
hxxp://185.216.71[.]120/Rxefnjsexz.jpeg
hxxp://185.216.71[.]120/Pbdocvt.png
and more

Subscribe to AhnLab’s next-generation threat intelligence platform ‘AhnLab TIP’ to check related IOC and detailed analysis information.