Zach-Rehrman/Flare-VM-Malware-Analysis-Lab
GitHub: Zach-Rehrman/Flare-VM-Malware-Analysis-Lab
一个完整的恶意软件分析实验室搭建指南，结合 FLARE VM 和 REMnux 实现静态与动态分析，以 WannaCry 为案例展示从环境隔离到 IOC 提取的全流程。
Stars: 0 | Forks: 0
# 恶意软件分析实验室（进行中）
## 目标
使用 Windows 和 Linux 虚拟机设计并部署一个专用的恶意软件分析实验室，以安全地分析可疑和恶意文件。本项目利用 Flare VM 和 REMnux 执行静态和动态分析，重点关注理解恶意软件行为、持久化机制以及入侵指标，旨在将分析发现转化为可操作的安全洞察。
### 掌握的技能
- 对静态和动态恶意软件分析技术的实际理解
- 能够在隔离环境中安全地引爆（detonate）并分析恶意文件
- 提取和情境化 IOC 的经验
- 培养适用于 SOC 操作的分析思维和调查技能
### 使用的工具
- **VirtualBox：** 用于托管和隔离恶意软件分析环境的 Hypervisor
- **Windows 10：** 作为主要恶意软件执行和分析平台的真实终端
- **Flare VM：** 安装在 Windows 上的恶意软件分析工具包，提供一套预配置的静态和动态分析工具
- **Ubuntu Linux：** 作为 REMnux 分析环境基础的 Linux 操作系统
- **REMnux：** 基于 Linux 的恶意软件分析发行版，用于网络分析和恶意工件提取
- **INetSim：** 模拟常见的互联网服务，允许恶意软件按预期执行，从而提供可观察的真实恶意软件网络活动和 Payload 获取尝试
## 步骤
### 1：创建架构图
_注意：图表和文档中显示的 IP 地址使用 RFC 5737 文档范围，仅作代表。实际的实验室环境使用私有 RFC1918 地址。_
本项目的第一步是记录恶意软件分析实验室的高层架构，说明如何利用虚拟化和隔离技术安全地分析恶意文件。该设计通过使用专用的 Windows 10 虚拟机、FLARE VM 工具集、Ubuntu 虚拟机和 REMnux 工具集，强调了隔离和控制执行。
*参考 1：架构图*
### 2：Windows 10 VM 配置与 FLARE VM 安装
此步骤涉及创建 Windows 10 虚拟机并在运行 FLARE VM 安装脚本之前对其进行配置。有几个 Windows 配置前置条件需要满足，否则安装将会失败。FLARE VM 设计为仅在干净的 Windows 虚拟机中安装，而不是在主机 OS 上，因为它包含许多恶意软件分析和逆向工程工具，可能会受到系统保护的干扰。配置包括启用/禁用所需功能，并确保环境能够支持 FLARE VM 的自动安装，从而为恶意软件分析工具集建立稳定的基础。一切设置完成后，拍摄了快照以确保实验室可以在干净配置下重复使用（也是为了不必再花 3 个小时下载 Flare VM……）。
### 3：Ubuntu Linux VM 配置与 REMnux 安装
下一步是创建一个专用的 Ubuntu Linux 虚拟机以支持网络恶意软件分析。系统被配置为满足 REMnux 安装要求，并设置为受控分析环境。随后安装了 REMnux，以提供用于检查恶意网络流量、提取工件以及支持与 FLARE VM 环境互补分析的工具。也拍摄了该环境的快照以便在需要时恢复。
### 4：网络配置与隔离
这是过程中最重要的一步，因为现在需要配置一个隔离网络，以确保我们拥有一个安全的环境来分析和引爆恶意软件。当然，这是因为如果在与物理操作系统可达的网络区域中处理恶意软件是极其危险的。此步骤涉及设计和验证一个隔离的分析网络，以安全地支持恶意软件执行，但在虚拟机之间保持逻辑连接以便观察。在 VirtualBox 中使用私有 RFC1918 地址空间和 /24 子网创建了一个专用的 Host-Only 网络，但出于文档目的，实验室将在 192.0.2.0/24 地址空间中描述，并启用 DHCP 以允许虚拟机之间的受控通信，同时阻止外部互联网访问。
Windows 10 Flare VM 和 Ubuntu REMnux VM 均被配置为仅使用 Host-Only 适配器，并移除了所有其他网络适配器以确保严格隔离。通过确认虚拟机之间的成功通信验证了网络连接，同时测试了外部连接并将其故意阻止。尝试访问公共 IP 地址和外部域导致网络不可达和名称解析失败，从而验证环境已完全与互联网隔离。
### 5：配置 INetSim
INetSim 为常见的面向互联网的服务（如 HTTP、HTTPS、FTP、SMTP 和 DNS）提供模拟，使我们能够在不将环境暴露于公共互联网的情况下观察恶意软件行为。当恶意软件尝试获取额外的 Payload 时，INetSim 会提供占位符内容并记录请求，记录工件本应交付的位置，而不是返回标准连接错误。这种行为允许分析人员识别第二阶段下载尝试和相关的入侵指标，而无需执行未知的二进制文件。
INetSim 默认包含在 REMnux 中，但需要额外配置以在隔离的实验室环境内支持真实的恶意软件网络行为。此步骤侧重于配置 INetSim，使其既充当模拟互联网服务平台，又充当分析网络的中央 DNS 响应器。修改了 `inetsim.conf` 配置文件，以确保 DNS 服务在 INetSim 启动时自动启动，将网络服务绑定到 REMnux 主机接口，并为所有 DNS 查询返回 REMnux 主机 IP 地址。此配置确保任意域名一致地解析到模拟服务主机，允许恶意软件像外部基础设施可用一样进行通信，同时完全限制在实验室范围内。作为此步骤的一部分，Windows FLARE VM 被显式配置为使用 REMnux 主机作为其 DNS 服务器，确保所有基于域的流量都通过 INetSim 进行路由以进行监控和分析。
### 6：定位恶意软件样本
在分析环境完全隔离并经过验证后，下一步的重点是获取用于分析的恶意软件样本。虽然恶意软件在开放网络上广泛可用，但关键是要仅从知名、信誉良好的来源获取样本，以最大限度地减少法律、伦理和操作风险。本项目利用了安全专业人员和研究人员常引用的既定恶意软件存储库。其中包括 theZoo，它提供用于研究目的的活恶意软件二进制文件和相应的源代码；VX-Underground 的 MalwareSourceCode，它托管跨越多种操作系统和架构的精选恶意软件样本；以及 Zeltser.com，它维护着恶意软件资源集合，包括对 ANY.RUN 等公共分析平台的引用。
我们注意确保所有样本都是在受控实验室环境中出于防御研究目的而合乎道德且有意地获取的。所有恶意软件仅在隔离的虚拟机内处理，未在连接到公共互联网的主机系统或网络上执行任何样本。
### 7：Wannacry 静态分析
接下来的两部分将分析的恶意软件是 Wannacry 勒索软件的样本。首先，我将对样本进行一些基本的静态分析。我要做的第一件事是使用 Cmder Windows 中的 `sha256sum.exe` 命令查找样本的 sha256 文件哈希，该命令返回 sha256 哈希：24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c。在 Virus Total 上搜索此文件哈希时，返回的结果压倒性地表明这是一个恶意文件，指出该文件似乎是特洛伊木马勒索软件。之后，我从 cmder 运行 `file.exe` 查看可执行文件的真实文件类型，因为混淆恶意软件的文件扩展名是一种常见做法，返回结果为 PE32 executable。然后我继续在恶意软件样本上运行 FLOSS.exe，它类似于 strings 命令，我设置了 `-n` 标志为 7 以避免一些干扰信息，并将此输出复制到 txt 文件以便于查看。在字符串文件中，显示超过 3000 个字符串符合我设置的条件，我花了一些时间查看我认为有趣的属性，重点关注动态链接库 以及看起来像函数的东西以及一个奇怪的 URL，这将在未来的部分中介绍。
DLLs
- ADVAPI32.dll -> 恶意软件用于在低级别与 Windows 操作系统交互，主要用于注册表操作、服务管理和安全/权限管理
- WS2_32.dll -> 原始套接字操作，表明存在网络通信
- iphlpapi.dll (IP Helper API) -> 查询网络接口/适配器信息，可能用于枚举本地子网以进行横向移动
- wininet.dll -> HTTP 通信，主要用于下载额外的 Payload、渗出窃取的数据以及在恶意软件中连接到命令与控制 (C2) 服务器
- USER32.dll -> 管理用户界面元素，如窗口、按钮、菜单和输入交互
文件函数 -> 文件系统操作，与编辑和重命名受害者文件一致
- ReadFile
- GetFileSize
- WriteFile
- CreateFileA
- MoveFileW
加密函数 -> 确认与勒索软件一致的加密操作
- CryptAcquireContext
- CryptGenRandom
- CryptReleaseContext
- CryptGenKey
- CryptDecrypt
- CryptEncrypt
- CryptDestroyKey
- CryptImportKey
- WanaCrypt0r
之后，我继续使用 Detect it Easy (DIE) 分析样本。在这个例子中使用 DIE 的主要目的是检查样本的熵，尽管它可以用于多种任务，包括分析基本文件详细信息和查看字符串、内存映射和反汇编。熵衡量文件中数据的随机性或不可预测性，通常在 0（有序/可预测）到 8（随机/混乱）的范围内。高熵通常表明存在加密、压缩或加壳的恶意代码，而低熵则表明是正常的或结构化的代码。DIE 将熵分解到不同的 PE 节区，例如 headers、.txt（可执行代码）、.rdata（通常是只读数据）、.data 和 .rsrc（资源）。我们可以看到大多数节区显示的熵很低，但 .rsrc 节区占据了样本的近 90%，并被测定具有 7.99523 的极高熵分，这意味着它很可能被加壳。加壳是指可移植可执行文件中的一个压缩或加密段，用于隐藏恶意 Payload 以规避基于特征的检测。
接下来我们可以使用 Ghidra 进行一些基本的静态分析。一旦 Ghidra 分析了样本，我们可以花一些时间查看符号树，其中包括导入项，其中许多是我们在之前的 floss 分析中看到的 .dlls，在程序树中我们可以看到我们之前介绍的 PE 节区。如果我们点击进入这些，我们可以看到 PE 中调用的函数归属于不同的导入项，例如在 ADVAPI32.dll 导入项下看到我们介绍过的一些加密函数。继续看函数选项卡，我们将深入研究入口函数，因为它是程序的初始执行点，非常关键。许多函数是随机名称，但有一个入口函数，这是完美的起点，因为它是整个执行树的根。初步检查伪代码，第一页有许多变量和几个函数。经过一番研究，似乎第一部分只是标准的 Microsoft Visual Studio C++ 运行时初始化样板代码。在点击进入 3 个可用函数以获取更多细节后，只有最后一个函数提供了新的调查路径。经过一些额外的分析，我发现这很可能就是所谓的 WinMain() 函数：“MSVC 运行时总是遵循相同的序列：设置 SEH、初始化 CRT 全局变量、解析命令行参数，然后调用 WinMain，最后以 WinMain 的返回码退出”。此外，GetStartupInfoA 和 GetModuleHandleA 在此函数之前被调用，这也是 WinMain 的特征。
当双击 WinMain 函数时，我们会看到更多变量，包括顶部附近一个熟悉的变量。它看起来像我们在原始 FLOSS 命令中发现的 URL 的一部分，但是末尾附加了看起来像内存偏移量的东西。在朋友的帮助下，我确认这只是 ghidra 对长字符串执行的截断。在编译器中双击此项后，我们被带到该地址存在于内存中的位置，它返回了完整的 URL。查看此 URL 后，这就是传说中的 Wannacry Killswitch（开关）！
killswitch: "hxxp[://]www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com"
### 8：Wannacry 动态分析
之后是时候开始动态分析了。由于我们处于完全安全的实验室环境中，执行样本是安全的。在此之前，我想在 FlareVM 机器上启动 ProcMon，在 Remnux 机器上启动 Wireshark，并且我想将其分为 2 次执行。其中一次是在 INetSim 运行的情况下，另一次则不运行。这是因为，理论上，INetSim 会使得每当对 killswitch 域进行调用时，该调用都会成功，从而停止进一步的执行。之后，我们将进行一次没有运行 INetSim 的执行，这应该允许样本完全执行，我们将能够记录样本完全执行时实际发生的情况，并通过 PorcMon 和 Wireshark 分别识别任何基于主机或基于网络的 IOC。
让我们从运行 INetSim 以及全新的 ProcMon 和 Wireshark 开始。让它运行几分钟后，让我们从初步观察开始描述发生了什么。查看执行后的 FlareVM 主机，我真的没看到任何变化？我桌面上的所有内容看起来都很正常，样本仍然可用。如果我们开始在 ProcMon 中查找，过滤条件为 Process Name = Wannacry.exe 以查看任何被调用的进程，似乎有超过 6k 个结果！然而，我没看到任何主要感兴趣的东西。看起来有一些创建和写入文件的尝试，但没有明显恶意的东西。之后我们可以查看 Wireshark 以了解拾取了哪些网络指标。我看到的第一件事是对 Killswitch URL 的 DNS 调用，当然，这是由 INetSim 作为我们的代理 DNS 服务器响应的。紧接着，我看到一个 HTTP GET 请求和一个 OK 响应，确认 killswitch URL 被调用并被找到，实际上停止了任何进一步的执行。
现在是时候在 INetSim 不运行的情况下执行 Wannacry，在这种情况下，我们应该看到它表现出恶意活动。清除 ProcMon 和 Wireshark 中以前的日志后，我再次运行可执行文件。大约 10 秒后，我们开始注意到有些不对劲。在我们的 FlareVM 机器上，桌面上的文件图像开始消失，悬停在这些文件上显示它们现在具有 WNCRY 扩展名。大约 30-60 秒后，我们开始看到一个新的图像文件和 txt 文件出现在桌面上，然后我们看到了 Wannacry 的名片，形式为 WannaDecrypt0r 以及臭名昭著的桌面背景。
查看桌面上的一些文件，它们现在似乎无法打开，包括一些测试用的 txt 和图像文件。
Procmon
Wireshark 日志再次显示了对 killswitch url 的调用，但这次只有 DNS 查询，在 wireshark 中过滤 http 时没有尝试对该域进行 http 调用，因为没有返回结果。
### 2：Windows 10 VM 配置与 FLARE VM 安装
此步骤涉及创建 Windows 10 虚拟机并在运行 FLARE VM 安装脚本之前对其进行配置。有几个 Windows 配置前置条件需要满足，否则安装将会失败。FLARE VM 设计为仅在干净的 Windows 虚拟机中安装，而不是在主机 OS 上，因为它包含许多恶意软件分析和逆向工程工具，可能会受到系统保护的干扰。配置包括启用/禁用所需功能，并确保环境能够支持 FLARE VM 的自动安装，从而为恶意软件分析工具集建立稳定的基础。一切设置完成后，拍摄了快照以确保实验室可以在干净配置下重复使用（也是为了不必再花 3 个小时下载 Flare VM……）。
### 3：Ubuntu Linux VM 配置与 REMnux 安装
下一步是创建一个专用的 Ubuntu Linux 虚拟机以支持网络恶意软件分析。系统被配置为满足 REMnux 安装要求，并设置为受控分析环境。随后安装了 REMnux，以提供用于检查恶意网络流量、提取工件以及支持与 FLARE VM 环境互补分析的工具。也拍摄了该环境的快照以便在需要时恢复。
### 4：网络配置与隔离
这是过程中最重要的一步，因为现在需要配置一个隔离网络，以确保我们拥有一个安全的环境来分析和引爆恶意软件。当然，这是因为如果在与物理操作系统可达的网络区域中处理恶意软件是极其危险的。此步骤涉及设计和验证一个隔离的分析网络，以安全地支持恶意软件执行，但在虚拟机之间保持逻辑连接以便观察。在 VirtualBox 中使用私有 RFC1918 地址空间和 /24 子网创建了一个专用的 Host-Only 网络，但出于文档目的，实验室将在 192.0.2.0/24 地址空间中描述，并启用 DHCP 以允许虚拟机之间的受控通信，同时阻止外部互联网访问。
Windows 10 Flare VM 和 Ubuntu REMnux VM 均被配置为仅使用 Host-Only 适配器，并移除了所有其他网络适配器以确保严格隔离。通过确认虚拟机之间的成功通信验证了网络连接，同时测试了外部连接并将其故意阻止。尝试访问公共 IP 地址和外部域导致网络不可达和名称解析失败，从而验证环境已完全与互联网隔离。
### 5：配置 INetSim
INetSim 为常见的面向互联网的服务（如 HTTP、HTTPS、FTP、SMTP 和 DNS）提供模拟，使我们能够在不将环境暴露于公共互联网的情况下观察恶意软件行为。当恶意软件尝试获取额外的 Payload 时，INetSim 会提供占位符内容并记录请求，记录工件本应交付的位置，而不是返回标准连接错误。这种行为允许分析人员识别第二阶段下载尝试和相关的入侵指标，而无需执行未知的二进制文件。
INetSim 默认包含在 REMnux 中，但需要额外配置以在隔离的实验室环境内支持真实的恶意软件网络行为。此步骤侧重于配置 INetSim，使其既充当模拟互联网服务平台，又充当分析网络的中央 DNS 响应器。修改了 `inetsim.conf` 配置文件，以确保 DNS 服务在 INetSim 启动时自动启动，将网络服务绑定到 REMnux 主机接口，并为所有 DNS 查询返回 REMnux 主机 IP 地址。此配置确保任意域名一致地解析到模拟服务主机，允许恶意软件像外部基础设施可用一样进行通信，同时完全限制在实验室范围内。作为此步骤的一部分，Windows FLARE VM 被显式配置为使用 REMnux 主机作为其 DNS 服务器，确保所有基于域的流量都通过 INetSim 进行路由以进行监控和分析。
### 6：定位恶意软件样本
在分析环境完全隔离并经过验证后，下一步的重点是获取用于分析的恶意软件样本。虽然恶意软件在开放网络上广泛可用，但关键是要仅从知名、信誉良好的来源获取样本，以最大限度地减少法律、伦理和操作风险。本项目利用了安全专业人员和研究人员常引用的既定恶意软件存储库。其中包括 theZoo，它提供用于研究目的的活恶意软件二进制文件和相应的源代码；VX-Underground 的 MalwareSourceCode，它托管跨越多种操作系统和架构的精选恶意软件样本；以及 Zeltser.com，它维护着恶意软件资源集合，包括对 ANY.RUN 等公共分析平台的引用。
我们注意确保所有样本都是在受控实验室环境中出于防御研究目的而合乎道德且有意地获取的。所有恶意软件仅在隔离的虚拟机内处理，未在连接到公共互联网的主机系统或网络上执行任何样本。
### 7：Wannacry 静态分析
接下来的两部分将分析的恶意软件是 Wannacry 勒索软件的样本。首先，我将对样本进行一些基本的静态分析。我要做的第一件事是使用 Cmder Windows 中的 `sha256sum.exe` 命令查找样本的 sha256 文件哈希，该命令返回 sha256 哈希：24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c。在 Virus Total 上搜索此文件哈希时，返回的结果压倒性地表明这是一个恶意文件，指出该文件似乎是特洛伊木马勒索软件。之后，我从 cmder 运行 `file.exe` 查看可执行文件的真实文件类型，因为混淆恶意软件的文件扩展名是一种常见做法，返回结果为 PE32 executable。然后我继续在恶意软件样本上运行 FLOSS.exe，它类似于 strings 命令，我设置了 `-n` 标志为 7 以避免一些干扰信息，并将此输出复制到 txt 文件以便于查看。在字符串文件中，显示超过 3000 个字符串符合我设置的条件，我花了一些时间查看我认为有趣的属性，重点关注动态链接库 以及看起来像函数的东西以及一个奇怪的 URL，这将在未来的部分中介绍。
DLLs
- ADVAPI32.dll -> 恶意软件用于在低级别与 Windows 操作系统交互，主要用于注册表操作、服务管理和安全/权限管理
- WS2_32.dll -> 原始套接字操作，表明存在网络通信
- iphlpapi.dll (IP Helper API) -> 查询网络接口/适配器信息，可能用于枚举本地子网以进行横向移动
- wininet.dll -> HTTP 通信，主要用于下载额外的 Payload、渗出窃取的数据以及在恶意软件中连接到命令与控制 (C2) 服务器
- USER32.dll -> 管理用户界面元素，如窗口、按钮、菜单和输入交互
文件函数 -> 文件系统操作，与编辑和重命名受害者文件一致
- ReadFile
- GetFileSize
- WriteFile
- CreateFileA
- MoveFileW
加密函数 -> 确认与勒索软件一致的加密操作
- CryptAcquireContext
- CryptGenRandom
- CryptReleaseContext
- CryptGenKey
- CryptDecrypt
- CryptEncrypt
- CryptDestroyKey
- CryptImportKey
- WanaCrypt0r
之后，我继续使用 Detect it Easy (DIE) 分析样本。在这个例子中使用 DIE 的主要目的是检查样本的熵，尽管它可以用于多种任务，包括分析基本文件详细信息和查看字符串、内存映射和反汇编。熵衡量文件中数据的随机性或不可预测性，通常在 0（有序/可预测）到 8（随机/混乱）的范围内。高熵通常表明存在加密、压缩或加壳的恶意代码，而低熵则表明是正常的或结构化的代码。DIE 将熵分解到不同的 PE 节区，例如 headers、.txt（可执行代码）、.rdata（通常是只读数据）、.data 和 .rsrc（资源）。我们可以看到大多数节区显示的熵很低，但 .rsrc 节区占据了样本的近 90%，并被测定具有 7.99523 的极高熵分，这意味着它很可能被加壳。加壳是指可移植可执行文件中的一个压缩或加密段，用于隐藏恶意 Payload 以规避基于特征的检测。
接下来我们可以使用 Ghidra 进行一些基本的静态分析。一旦 Ghidra 分析了样本，我们可以花一些时间查看符号树，其中包括导入项，其中许多是我们在之前的 floss 分析中看到的 .dlls，在程序树中我们可以看到我们之前介绍的 PE 节区。如果我们点击进入这些，我们可以看到 PE 中调用的函数归属于不同的导入项，例如在 ADVAPI32.dll 导入项下看到我们介绍过的一些加密函数。继续看函数选项卡，我们将深入研究入口函数，因为它是程序的初始执行点，非常关键。许多函数是随机名称，但有一个入口函数，这是完美的起点，因为它是整个执行树的根。初步检查伪代码，第一页有许多变量和几个函数。经过一番研究，似乎第一部分只是标准的 Microsoft Visual Studio C++ 运行时初始化样板代码。在点击进入 3 个可用函数以获取更多细节后，只有最后一个函数提供了新的调查路径。经过一些额外的分析，我发现这很可能就是所谓的 WinMain() 函数：“MSVC 运行时总是遵循相同的序列：设置 SEH、初始化 CRT 全局变量、解析命令行参数，然后调用 WinMain，最后以 WinMain 的返回码退出”。此外，GetStartupInfoA 和 GetModuleHandleA 在此函数之前被调用，这也是 WinMain 的特征。
当双击 WinMain 函数时，我们会看到更多变量，包括顶部附近一个熟悉的变量。它看起来像我们在原始 FLOSS 命令中发现的 URL 的一部分，但是末尾附加了看起来像内存偏移量的东西。在朋友的帮助下，我确认这只是 ghidra 对长字符串执行的截断。在编译器中双击此项后，我们被带到该地址存在于内存中的位置，它返回了完整的 URL。查看此 URL 后，这就是传说中的 Wannacry Killswitch（开关）！
killswitch: "hxxp[://]www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com"
### 8：Wannacry 动态分析
之后是时候开始动态分析了。由于我们处于完全安全的实验室环境中，执行样本是安全的。在此之前，我想在 FlareVM 机器上启动 ProcMon，在 Remnux 机器上启动 Wireshark，并且我想将其分为 2 次执行。其中一次是在 INetSim 运行的情况下，另一次则不运行。这是因为，理论上，INetSim 会使得每当对 killswitch 域进行调用时，该调用都会成功，从而停止进一步的执行。之后，我们将进行一次没有运行 INetSim 的执行，这应该允许样本完全执行，我们将能够记录样本完全执行时实际发生的情况，并通过 PorcMon 和 Wireshark 分别识别任何基于主机或基于网络的 IOC。
让我们从运行 INetSim 以及全新的 ProcMon 和 Wireshark 开始。让它运行几分钟后，让我们从初步观察开始描述发生了什么。查看执行后的 FlareVM 主机，我真的没看到任何变化？我桌面上的所有内容看起来都很正常，样本仍然可用。如果我们开始在 ProcMon 中查找，过滤条件为 Process Name = Wannacry.exe 以查看任何被调用的进程，似乎有超过 6k 个结果！然而，我没看到任何主要感兴趣的东西。看起来有一些创建和写入文件的尝试，但没有明显恶意的东西。之后我们可以查看 Wireshark 以了解拾取了哪些网络指标。我看到的第一件事是对 Killswitch URL 的 DNS 调用，当然，这是由 INetSim 作为我们的代理 DNS 服务器响应的。紧接着，我看到一个 HTTP GET 请求和一个 OK 响应，确认 killswitch URL 被调用并被找到，实际上停止了任何进一步的执行。
查看桌面上的一些文件，它们现在似乎无法打开，包括一些测试用的 txt 和图像文件。
Procmon
Wireshark 日志再次显示了对 killswitch url 的调用，但这次只有 DNS 查询，在 wireshark 中过滤 http 时没有尝试对该域进行 http 调用，因为没有返回结果。标签：DAST, DNS 反向解析, Flare VM, HTTP工具, INetSim, IP 地址批量处理, Linux 安全, Python3.6, REMnux, RFI远程文件包含, SOC 分析, VirtualBox, Windows 安全, 云安全监控, 云资产清单, 入侵指标, 威胁情报, 子域名变形, 安全实验室, 安全运营中心, 开发者工具, 恶意代码分析, 恶意文件检测, 恶意软件分析, 持久化机制, 沙箱技术, 漏洞利用分析, 网络信息收集, 网络威胁追踪, 网络安全审计, 网络映射, 网络模拟, 蓝队建设, 虚拟化安全, 蜜罐技术, 逆向工程, 配置文件, 防御规避检测, 静态分析