当前位置：首页 > news >正文

在 Linux 中实现虚拟机管理程序级行为分析

news 2025/10/23 7:26:56

大家好！我是大聪明-PLUS！

请继续阅读，了解 Linux 流行的恶意软件监控工具的简要概述、我们的插件在 DRAKVUF 中的工作方式描述以及依赖于这些插件的恶意软件分析。

Linux 监控工具

在从操作系统收集事件时，首先要确定其用途。例如，构建 EDR（端点检测和响应）还是在隔离环境中构建分析。今天我们将重点介绍隔离环境中的分析。因此，在评估现有工具时，我们将遵循这一策略。

审计

Auditd因其易于安装、规则语法简单以及能够分析系统调用和文件系统事件的能力而成为最受欢迎的工具之一。然而，Auditd 并非完美无缺。该工具存在一些缺点：

缺乏统一的消息格式。任何与 auditd 兼容的程序都可以使用自己的格式发送消息。此外，消息以键值格式的纯文本形式传输，不如 JSON 等格式方便。
事件不按 ID 排序。例如，首先有一个 ID 为 645 的事件，然后是 646，然后又是 645。这不太方便，尤其是在您需要自动解析事件流时。
规则灵活性低。Auditd仅通过 API 工作，并且对内核的访问权限有限。当您需要编写比拦截系统调用程序更复杂的程序时，这会带来不便。
系统入侵风险。恶意程序获取 root 权限后，可以轻松关闭我们的日志系统。在这种情况下，我们的分析系统将变成一个“南瓜”。

inotify 和 fanotify

Linux 中还有其他用于监控恶意程序的工具，例如inotify和fanotify，但它们也并非完美无缺。让我们来看看 inotify_event 结构。您会发现，它根本不包含任何有关进程的信息，因此我们收到一个事件，表示发生了与文件系统相关的操作，但我们对执行该操作的程序一无所知。为了解决这个问题，内核开发人员提交了一个请求，要求使用 fanotify 并传入文件描述符和 PID。然而，这还不够，因为执行该操作的程序名称仍然未知。

eBPF

这里我们来看一下eBPF（扩展伯克利数据包过滤器），它源自 BSD。现代 eBPF 不仅仅是一个数据包过滤器，而是一个功能齐全的虚拟机，它允许我们用 C 语言编写程序，用于执行从网络流量监控到系统性能分析和安全等各种任务。这些程序使用 BPF_MAP 进行通信，这是一个哈希表，对于用户空间程序和内核空间程序都是相同的。

eBPF 结合了 auditd、inotify 和 fanotify 的功能。实际上，借助 kprobe 机制，您可以拦截任何内核函数；借助 uprobe，您可以拦截任何用户空间函数。但局限性仍然存在：

与称为助手的特殊 BPF 函数紧密绑定；
eBPF 保证了程序的执行时间，这意味着程序中不会出现循环。当然，循环是可以的，但只是常数。
指令数量有限 — 旧内核最多为 4096 条指令，新内核最多为 100 万条指令。

我们制作的插件

DRAKVUF 是一款使用“黑盒”方法动态分析恶意软件的系统。它与“Xen”虚拟机管理程序协同工作，允许您在隔离环境中同时分析多个虚拟机。虚拟机分析借助 LibVMI（虚拟机自检）组件进行，该组件不仅允许您读取虚拟内存，还可以根据需要对其进行修改。通过这种方法，您可以安全地在系统中运行恶意代码并观察其行为。

DRAKVUF 是一个模块化系统，允许您为感兴趣的内核结构编写各种插件。它为分析提供了极大的灵活性，因为即使缺少某些内容，您也可以像我们在 Positive Technologies 中所做的那样自己编写。

Procmon 是 PT ESC 开发的 DRAKVUF 的一个新插件，用于跟踪 Linux 系统中新进程的创建。为了解释它的工作原理，我将介绍 Linux 内核如何生成进程以及进程中存储了哪些信息。

要运行程序，需要调用 exec 系列函数之一。但是，execve/execveat 系统调用不会创建新进程：它们只会替换程序的当前实例，包括堆栈、堆和数据段。也就是说，一个拥有自己标识符的独立进程会创建 fork/clone 调用。以下是创建新进程的简化流程图：

正在运行的进程想要调用 whoami 命令。为此，它从 libc 访问系统函数，然后调用 fork ，并且只有在收到新的进程 ID 后才调用 execve 。

内核将所有进程的信息存储在 task_struct 结构中，该结构是一个链表，允许遍历系统中的每个进程。例如，通过获取当前进程的结构地址，可以访问系统中的所有其他进程。该结构是进程的抽象，描述了其所有字段。您可以从中获得 PID（进程 ID）、父 PID（父进程 ID）、子进程信息、简称等等。

理解 procmon 插件工作原理的下一个重要结构是 linux_binprm（Linux 二进制程序）。您可以从中获得很多有用的信息。例如，指向文件描述符的指针、解释器的名称以及是否存在权限提升。linux_binprm 的主要区别在于用途。Linux_binrpm 存储即将创建的进程的信息，而 task_struct 描述系统中已运行的进程。

Procmon 实际上并不直接拦截 execve 系统调用，因为它几乎不包含正在运行的程序的上下文信息。一个名为 begin_new_exec 的内部函数负责拦截。值得注意的是，该函数体只是执行了我们期望从 execve 调用中得到的进程替换。因此，在调用开始时拦截该函数后，我们获得了父进程的上下文以及 linux_binprm 结构，从中我们可以获取子进程的信息，并且在退出该函数时，我们还可以获取新运行程序的上下文。

为了演示 procmon 插件，我将在搭载 5.15 内核的 Ubuntu 20.04 上运行两个简单的进程：uname 和 whoami。它们的 ProcessName 字段包含启动进程的名称，ImagePathName 字段包含正在启动的进程的名称。此外，还会从 linux_binprm 结构中提取命令行以及其他字段。由此，我们可以获取有关进程的所有必要信息，例如，构建进程图。

文件追踪器

现在我们来谈谈 DRAKVUF 中的另一个重要插件：filetracer。它允许您观察文件系统中发生的事件。我们在开发和测试过程中面临的一个挑战是自动检测 Linux 内核版本。这是因为内核版本 5.12 改变了函数参数的顺序。我们通过添加一个特殊方法 drakvuf_get_kernel_version 来查找当前内核版本，从而解决了这个问题。

为了演示该插件的运行方式，我们来看一下被拦截方法 do_truncate 的处理程序代码。我们的方法不仅可以确定内核版本，还可以正确获取函数的参数。

至于 filetracer 的逻辑，它比 procmon 的逻辑简单得多。但结果却令人鼓舞：事件包含有关程序活动的所有必要信息，这有助于判断其可能的恶意行为。因此，我们可以使用该插件获取读取文件的进程名称、文件名和使用的方法、其权限以及它在系统中的位置。

还有什么？

我只描述了两个插件，它们都是我们自己开发的，但 DRAKVUF 还有更多插件。它们都旨在全面了解沙盒中恶意软件的工作情况。例如，syscalls 可以监控系统调用，rebootmon 可以监控重启事件。

目前我们正在开发两个插件：

filextractor，它允许您提取分析过程中创建的文件。例如，如果样本下载了一些有效载荷，我们将能够从虚拟机中提取它。
socketmon，它允许您监控程序的网络活动。例如，哪些网站正在被请求，使用了哪些数据等等。它将是流量分析的一个很好的补充，因为它可以让专家进行清晰的匹配：是哪个进程发出的请求，以及它在何处发出的请求。

我们的 DRAKVUF 插件如何分析进入 PT Sandbox 的恶意程序

举例来说，我们来看看它们如何检测三个常见的 Linux 家族：XorDDoS、BPFDoor 和 Mirai。由于恶意软件分析耗时较长，我们仅重点介绍了每个样本的主要行为，以展示 DRAKVUF 的工作原理。

XorDDoS

XorDDoS 的功能之一是：它对临时目录 tmp 执行持久化。

在左侧，您可以看到来自 filetracer 插件的事件，其中进程调用 vfs_write（或简称为系统调用 write）将一个随机名称的文件写入临时目录 tmp。为了清晰起见，右侧显示了反编译器的伪代码，您可以看到直接调用该函数写入文件。我们检测到了 tmp 中的持久性，这意味着我们已经发现了恶意软件。

BPF门

BPFDoor 因在网络套接字上安装 bpf 过滤器而闻名，因此可以过滤网络连接。

左侧是来自 syscalls 插件的事件。在其中，您可以看到进程名称、方法以及枚举值 SOL_SOCKET 和 SO_ATTACH_FILTER 的字符串标识符。右侧显示了伪代码，其中此操作直接在 BPFDoor 中执行。

Mirai

Mirai 是一个用于创建僵尸网络的流行后门。其活动的一个示例是使用参数 PR_SET_NAME 隐蔽执行 prctl 系统调用。此参数允许修改进程名称，以使其无法被正在检查正在运行的进程列表的网络管理员发现。

为了检测此活动，我们需要两个 DRAKVUF 插件的事件：filetracer 和 syscalls。因此，我特别强调了恶意软件样本用于写入 stdout 流的函数。

从 syscalls 插件收到的事件有助于查看系统调用的名称 (prctl) 和参数 PR_SET_NAME。filetracer 插件有助于查找 FileName 的值（“/1”），而 ThreadName 的值则不同：“/var/Sofia”。由于所有这些事件均由系统中的同一进程发起，因此可以通过 ID 进行匹配，从而得出该进程是由 Mirai 启动的结论。