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.

Figure 1. Comparison of malware statistics in Korea (ASEC) and ANY.RUN (overseas) for 2022

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.

Figure 2. Basic structure of .NET packers

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.

DLL files without executable codes: Red (Data)
DLL files with executable codes: Green (Loader)
Final malware: Red with a yellow border (Payload)

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.

1) Internally encoded binary information (file name information)
2) Process flow and the location of the encoded data

These characteristics are expressed in the packer flow below.

Figure 3. Notable points focus in the flow (① and ②)

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.

TypePacker
1MajorCrypter
2DarkTortilla
3VariantCrypter(a.k.a GameLoader) 
4PureCrypter
5LogicNP’s Crypto Obfuscator
Table 1. Major .NET packers that are recently being distributed

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.

Figure 4. Type 1’s basic flow

The flow of Figure 4 above is as follows.

1) The packer decodes the first loader, loads it onto the memory, and the code branches to Loader 1.

2) Loader 1 decodes Loader 2 that is in the packer, loads it onto the memory, and branches the code to Loader 2.

3) The second loader decodes and loads the data inside itself.
4) The second loader decodes the payload, which is the data inside the loaded data DLL.
5) After executing the target process, the second loader injects the decoded payload.
Table 2. Flow stages of Type 1 packer

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.

Figure 5. Loader names of a Type 1 packer
(Left: Loader 1 (Bunifu.UI.dll), Right: Loader 2 (MajorRevision.exe))

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.

LoaderFile Information
1 (First)Bunifu.UI.dll
Resource_Meter.dll
QuestKingdom.dll
Cassa.dll
2 (Second)MajorRevision.exe
Table 3. File information of Type 1’s loaders

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.

Figure 6. Recent Type 1 packer’s flow (with additional data, outlined in black)

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.

PackerType 1
(MajorCrypter)
Type 2
(DarkTortilla)
Type 3
(VariantCrypter) a.k.a GameLoader
Type 4
(PureCrypter)
Type 5
(LogicNP’s Crypto Obfuscator)
Domestic Distribution
Period
(estimate)
Since early 2021Since 2020Since 2021Since early 2021Since mid-2022 ~
Initial
Vector
LoaderDownloader,
Loader
LoaderDownloader,
Loader
Loader
Stage43 or 4323
Loader 1
Information
Data location: Inside code
(Encoded Base64)
File name:
Bunifu.UI.dll,
Resource_Meter.dll,
QuestKingdom.dll,
Cassa.dll
Data location: Inside code
(Encoded Binary)
File name:[Random_string].dll
Data location: Resource
(Encoded Binary or Bitmap)
File name: (Explained in features)
Data location: Inside code
(Encoded ASCII or Encoded Array or Download data)
File name: [Random_string].dll
Data location: Resource
(Encoded Binary)
File name: [Random_string].dll
Loader 2
Information
Data location: Resource
(Bitmap)
File name:
MajorRevision.exe
Data location: Resource
(Encoded Binary)
File name: [Random_string].dll
Data location: Resource
(Encoded Base64)
Feature: Only decoding
 
File name: (Explained in features)
Data location: Resource
(Encoded ASCII)
Feature: Only deserializing
 
File name: protobuf-net.dll,
Newtonsoft.Json.dll
X
Loader 3
Information
XFeature : Shellcode(WIN API)Data location: Resource
(Bitmap)
File name: (Explained in features)
XX
Sleep MethodInside the codeInside the codePowershell,
Inside the code
Powershell,
Inside the code
Inside the code
Callback
Function
ResourceResolveAssemblyResolveResourceResolveResourceResolveResourceResolve
AssemblyResolve
Table 4. Overview of packers

.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
Figure 7. Type 1 (MajorCrypter), whose form has recently been changed

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
LoaderFile Information
1 (First)Bunifu.UI.dll
Resource_Meter.dll
QuestKingdom.dll
Cassa.dll
2 (Second)MajorRevision.exe
Table 5. File information of Type 1’s loaders

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.

Figure 8. Loader 1’s method of decoding and loading (decoding target: Loader 2)

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.

Figure 9. Loader 2 binary encoded as bitmap in the resource area

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.

Figure 10. Type 2 (DarkTortilla) packer’s flow (B Type shows additional data)
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.

Figure 11. Resource structure of Type 2 (DarkTortilla)
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).

Figure 12. Four argument values transmitted to Loader 2’s method

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.

Figure 13. Before code restoration of Loader 2 (left) and after restoration (right)

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.

Figure 14. Comparison between Aeonhack’s RunPE open source code (left) and the DarkTortilla packer (right)

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

1) Flow
Figure 15. Type 3 (VariantCrypter) packer’s 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/

Figure 16. Malware disguised as a game program

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.

CategoryLoader 1 (Hex Binary or Bitmap)Loader 2 (Array)
// Decoder
Loader 3 (Bitmap)
Type APrivateBinPath.dll
SafeSerializationManager.dll
XUI.dll
Type BSharpStructures.dll
SpaceChemSolver.dll
EverCraft.dll
abzQueueReader.dll
introspective.dll
FuncAttribute.dll
CustomAttrubute.dll
PoolWait.dll
Fort.dll
XDotNetZipAdditionalPlatforms.dll
Type CFort.dll
Cerbera.dll
MLang.dll
XIVectorView.dll
Type DArgIt.dll
ArgIteratorZAA.dll
CloneHelper.dll
Egra.dll
TokenImpersonation.dll
NativeVariant.dll
OAA.dll
RangePartition.dll
TweenEngineAPI.dll
Tokenizer.dll
Thookinieng.dll
Type EPlates.dll
KeysNormalize.dll
TargetParameterCount.dll
Wise.dll
Precision.dll
Froor.dll
WebName.dll
Inspector.dll
SchedulingClerk.dll
Doncepre.dll
Metal.dll
Collins.dll
Table 6. Variants of Type 3 (VariantCrypter) found up to November 2022

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.

Figure 17. Type C loader of the Type 3 packer (VariantCrypter)

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.

Figure 18. Type 3’s three kinds of flow

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.

Figure 19. Type 3 (VariantCrypter) packer’s Loader 1 decoding process

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.

Figure 20. Argument values transmitted when Loader 1 is loaded

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.

Figure 21. Loader 2’s decoding method (Target: Loader 3, Key: “vth”)

3.2.4. Type 4 (PureCrypter)

Figure 22. PureCrypter’s official website and PureCrypter(v2) options

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
Figure 23. Changes in the structure and flow of PureCrypter

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.

Figure 24. Structure of Loader 1 including all features for processing Json formats (namespace: Newtonsoft.Json)
2) DLL File Information
LoaderFile Information
1 (First)[Random_string].dll
2 (Second)protobuf-net.dll
Newtonsoft.Json.dll
Table 8. PureCrypter’s 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. 

Figure 25. Conversion process of Json data (deserialization)

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.

Figure 26. Changes to the Json processing module and its flow (Top: past vs Bottom: recent)

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.

Figure 27. The most recent PureCrypter

3.2.5. Type 5 (LogicNP’s Crypto Obfuscator)

1) Flow
Figure 28. Type 5’s flow (LogicNP’s Crypto Obfuscator)

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.

Figure 29. Type 5’s (LogicNP’s Crypto Obfuscator) official website
Figure 30. Type 5’s (LogicNP’s Crypto Obfuscator) builder options

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.

Resource NameFeature
&& or &PE file (Data.dll)
$Encoded string
(Argument, External APIs Name, ..etc)
%PE file (Loader.dll)
Table 9. Rules based on the resource name

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

Figure 31. Structure and resource data of Type 5 (LogicNP’s Crypto Obfuscator)

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.

Figure 32. Four arguments transmitted to Loader 1

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.

Figure 33. Common parameters of main injection functions (Type 2, Type 5, Aeonhack’s RunPE)

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.

Figure 34. Distribution trends of the five packer types (July ’22 – Nov ’22)

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. Top 8 malware distributed with .NET packers (Korea)

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.

Figure 36. Ransom note of ransomware distributed with Type 1 (MajorCrypter)

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.

Figure 37. AMSI feature of V3 (Settings – PC Scan Settings – Realtime PC Scan)

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.

5 3 votes
Article Rating
guest

1 Comment
Inline Feedbacks
View all comments
trackback

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