Unpacking malware can be a tedious task. Often involving intensive static analysis and in-depth knowledge of debugging.

脱壳恶意软件是一项繁琐的工作。通常会涉及频繁的静态分析和深入的调试知识。

In this post, I'll demonstrate an easy method that can be used to unpack files that ultimately load a .NET based malware.

在本篇文章中，我将演示一种简单的方法，用于脱壳最终会加载基于 .NET 的恶意软件的文件。

This method primarily involves running the file and monitoring for process executions using Process Hacker. Upon execution, Process Hacker can be used to observe any .NET files loaded into memory. If a file is identified, it can then be obtained using Dnspy.

该方法主要包括运行文件并使用 Process Hacker 监控进程执行。在执行过程中，Process Hacker 可用于观察加载到内存中的任何 .NET 文件。如果识别到 .NET 文件，就可以使用 Dnspy 获取该文件。

案例样本链接：

Sha256: 05c2195aa671d62b3b47ff42630db25f39453375de9cffa92fc4a67fa5b6493b

Analysis

分析

I will begin analysis by saving the file into my virtual machine and unzipping it with the password infected.

我将把文件保存到虚拟机中并利用字符串“infected”作为密码解压缩后开始分析。

After unzipping, I will also create a copy of the file with a shorter filename.

解压缩后，我还将创建一个文件名更短的文件副本。 

Initial Assessment With DnSpy

使用 DnSpy 进行初步检查

Before attempting to unpack the file, I will also open it within DnSpy.

在尝试脱壳文件之前，我还会在 DnSpy 中打开它。

This is to make sure that the file is not already unpacked. In my initial assessment, I didn't see any functionality that suggested the file was already unpacked.

这样做是为了确保文件没有被脱壳。在初步检查中，我没有发现任何痕迹表明文件已经被脱壳。

Observing Unpacked Content With Process Hacker

使用 Process Hacker 观察已脱壳的内容

At this point, I want to run the file and attempt to let it unpack itself.

此时，我想运行文件并尝试让它自行脱壳。

This can be achieved by running the file for a few seconds, and observing the process as well as any new processes that are spawned.

为此，我们可以运行该文件几秒钟，然后观察进程以及生成的任何新进程。

After a few seconds have passed, we can go ahead and view the process to see if any new .NET modules have been loaded.

几秒钟后，我们可以继续查看进程，看看是否加载了任何新的 .NET 模块。

Running the file for a few seconds, we can see that it spawns aspnet_compiler.exe. This is suspicious and something we can hone in on.

运行该文件几秒钟后，我们可以看到它生成了 aspnet_compiler.exe。这很可疑，我们可以仔细检查一下。 

We can also observe that after the new process is spawned, the original process 05c.exe exits a few seconds later.

我们还可以观察到，在生成新进程后，原始进程 05c.exe 会在几秒钟后退出。

This is an indicator that any suspicious or unpacked content is likely contained within aspnet_compiler.exe.

这表明任何可疑或未脱壳的内容都可能包含在 aspnet_compiler.exe 中。 

Identifying Unpacked .NET Files Using Process Hacker

使用 Process Hacker 识别脱壳后的 .NET 文件

With the suspicious aspnet_compiler.exe identified, we can go ahead and inspect it using Process Hacker.

确定了可疑的 aspnet_compiler.exe，我们就可以使用 Process Hacker 对其进行检查了。

We can do this by double clicking on the process name, or right-clicking and selecting "Properties".

我们可以双击进程名，或点击右键并选择“属性”。

This will open a window like the following. There are two main points here.

这将打开一个如下所示的窗口。这里有两个要点。

* .NET Assemblies tab - This shows us that some kind of .NET module is loaded into the process.

.NET Assemblies（.NET 程序集）选项卡 - 这表明进程中加载了某种 .NET 模块。

* Image Type - 32bit - The process is 32-bit, this tells us that any future debugging will require a 32-bit debugger (eg Dnspy x86)

镜像类型 - 32 位 - 进程是 32 位的，这表明今后的任何调试都需要 32 位调试器（例如 Dnspy x86）

* (Verified) Microsoft Corporation - This is likely a legitimate process that has been hijacked.

(已验证）微软公司 - 这很可能是一个被劫持的合法进程。 

Inspecting Loaded .NET Modules With Process Hacker

使用 Process Hacker 检查已加载的 .NET 模块

We can go ahead an inspect any loaded modules with the .NET assemblies tab.

我们可以使用“.NET 程序集”选项卡检查任何已加载的模块。

This will list any loaded .NET modules within the current process. As well as information for each module. We want to look for loaded modules that look out of place, or different to the others.

这将列出当前进程中任何已加载的 .NET 模块，以及每个模块的信息。我们要查找那些看起来与其他模块不匹配或不同的加载模块。

In this case, there is a loaded module named vik that doesn't look right. It has a completely different style of name to the other modules, and doesn't have a corresponding native image path (like all the other modules)

在本例中，有一个名为 vik 的加载模块看起来不太对劲。它的命名风格与其他模块完全不同，也没有相应的本地镜像路径（与其他模块一样）。 

If we look closer, we can also see that the "regular" path is that of aspnet_compiler.exe. This is suspicious, why would aspnet_compiler be named vik?

如果我们仔细观察，还可以发现“常规”路径是 aspnet_compiler.exe。这很可疑，为什么 aspnet_compiler 会被命名为 vik？ 

Verifying Suspicious .NET Modules Using DnSpy

使用 DnSpy 验证可疑的 .NET 模块

Now that we have identified a suspicious module, we can go ahead and obtain it using DnSpy.

现在我们已经确定了一个可疑模块，可以继续使用 DnSpy 获取它。

To obtain the file, we can open up Dnspy (32-bit) and attach to the aspnet_compiler.exe process.

要获取文件，我们可以打开 Dnspy（32 位）并附加到 aspnet_compiler.exe 进程。

This will allow us to inspect the loaded modules and view their corresponding source code.

这将允许我们检查已加载的模块并查看其相应的源代码。

Attaching Dnspy To a .NET Process

将 Dnspy 附加到 .NET 进程

We can attach to aspnet_compiler.exe using Debug -> Attach To Process -> Aspnet_compiler.exe

我们可以使用 “调试”->“附加到进程”->“Aspnet_compiler.exe”来附加到 aspnet_compiler.exe。 

With the process attached, we now want to inspect any loaded modules.

附加进程后，我们现在要检查任何已加载的模块。

We can do this by opening a "Modules" tab, using Debug -> Windows -> Modules.

我们可以使用“调试”->“窗口”->“模块”打开“模块”选项卡。 

With the new Modules tab, we can list the same loaded modules that were observed with Process Hacker.

通过新的“模块”选项卡，我们可以列出与 Process Hacker 中观察到的相同的已加载模块。

Interestingly, there is no vik module, but there is an aspnet_compiler.exe module that we know was associated with vik.

有趣的是，这里没有 vik 模块，但有一个 aspnet_compiler.exe 模块，我们知道该模块与 vik 有关。 

By clicking on aspnet_c0mpiler.exe, and selecting "Go To Module", we can view the module contents and corresponding decompiled code.

点击 aspnet_c0mpiler.exe，选择“转到模块”，我们就可以查看模块内容和相应的反编译代码。 

However, this will open the original aspnet_compiler.exe file from disk and not from within memory.

不过，这将从磁盘而不是内存中打开原始的 aspnet_compiler.exe 文件。

Hence, the "real" file will be loaded and we won't see anything suspicious.

因此，我们以为“真正的”文件将被加载，我们不会看到任何可疑之处。 

Instead, we can go back and re-open the file from memory.

相反，我们可以返回上述步骤并从内存中重新打开文件。 

With the file opened "from memory", we can obtain the real suspicious content. Which has likely been used to overwrite the original file in memory.

通过“来自内存”选项打开文件，我们可以获得真正的可疑内容。这些内容很可能被用来覆盖内存中的原始文件。

Here we can see the vik module loaded into DnSpy.

在这里，我们可以看到加载到 DnSpy 中的 vik 模块。 

Jumping to the Entry Point of .NET Malware

跳转到 .NET 恶意软件的入口点

To inspect the vik file more closely, we can righ-click on vik and select "Go To Entry Point".

要更仔细地检查 vik 文件，我们可以右键单击 vik 并选择“转到入口点”。

This will take us to the beginning of the code. Which very closely resembles that of Asyncrat.

这将带我们进入代码的开头。这与 Asyncrat 的代码非常相似。 

Clicking on the Settings.InitializeSettings() method, we can see where the configuration values are decrypted and loaded into the file.

点击 Settings.InitializeSettings() 方法，我们可以看到配置值被解密并加载到文件中。 

Identifying the Malware With Google

用谷歌识别恶意软件

If you haven't seen Asyncrat before, you could instead take some of the values in the "unpacked" sample and google them.

如果你以前没见过 Asyncrat，你可以将已脱壳的样本中的一些值放到谷歌上搜索。

If the malware is known and there are existing reports, you will likely encounter reports that will suggest which family the malware belongs to.

如果恶意软件是已知的，并且有现有的报告，那么你很可能会发现一些报告，这些报告会提示恶意软件属于哪个家族系列。

You may have to experiment with which values to google, some return better results than others. Below we can see Asyncrat comes up straight away when googling Settings.InitializeSettings Malware

有些值返回的结果比其他值更好，你可能需要尝试在谷歌上搜索不同的值。下面我们可以看到，谷歌搜索“Settings.InitializeSettings Malware”时，会直接出现 Asyncrat。 

Verifying With a Sandbox

使用沙箱进行验证

With an unpacked module now obtained, you can use DnSpy to save the file for additional analysis.

获得已脱壳的模块后，你可以使用 DnSpy 保存文件，以便进行更多分析。

From here, you can submit the unpacked file to a sandbox or scan it against a set of Yara rules. This is useful if the strings/functions within the file are obfuscated or you aren't able to obtain a good result from google.

在这里，你可以将解压后的文件提交到沙箱，或根据一组 Yara 规则进行扫描。如果文件中的字符串/函数被混淆或无法从谷歌获得良好的结果，这将非常有用。

This will save the file from memory, so you don't have to worry about saving the "wrong” file

这将从内存中保存文件，因此不必担心保存了“错误”的文件。 

Submitting the File To Hatching Triage

将文件提交到 Hatching Triage

After saving, you can submit the file to an online sandbox like Hatching Triage.

保存后，你可以将文件提交到在线沙箱，如 Hatching Triage。

Hatching Triage is correctly able to identify the file as Asyncrat and extract the associated configuration values.

Hatching Triage 可以正确地将文件识别为 Asyncrat，并提取相关的配置值。 

Submitting the File to Unpacme

向 Unpacme 提交文件

Another option which is effective and significantly cheaper for researchers, is Unpacme.

对研究人员来说，另一个有效且成本更低的选择是 Unpacme。

Unpacme is correctly able to identify the file as Asyncrat and extract all configuration values.

Unpacme 能够将文件正确识别为 Asyncrat，并提取所有配置值。 

Conclusion

结论

In this post, we performed some basic analysis of an Asyncrat loader, and utilised Process Hacker to identify an unpacked payload. We then used Dnspy to obtain the unpacked malware and identify it as Asyncrat.

在这篇文章中，我们对 Asyncrat 加载器进行了一些基本分析，并利用 Process Hacker 来识别已脱壳的 payload。然后，我们使用 Dnspy 获取了已脱壳的恶意软件，并将其识别为 Asyncrat。