mridul249/HyperSentinel
GitHub: mridul249/HyperSentinel
基于Hypervisor层（Ring -1）的恶意软件行为分析与检测系统，通过对恶意软件完全不可见的系统调用跟踪来对抗高级逃逸技术。
Stars: 0 | Forks: 0
# HyperSentinel
基于 Hypervisor 的恶意软件行为分析与检测系统。
## 架构概述
该系统分为三层。**Hypervisor 层**（HyperDbg, `capture.ds`）在 Ring -1 级别拦截 24 个 Windows 内核系统调用，并将其记录为包含四种记录类型的 CSV 行：DEEP（包含已解析字符串参数（如文件路径）的系统调用）、RAW（仅寄存器捕获）、RET（来自 syscall2 的返回值）和 IMG（来自 EPROCESS 遍历的进程元数据）。
**分析引擎**（`engine/`）通过六个组件处理这些跟踪数据：一个将入口调用与其返回值进行匹配的配对引擎；一个将原始数字参数解码为语义含义（访问标志、分配类型、保护位）的增强层；一个跟踪父子关系和跨进程注入模式的进程谱系图构建器；一个将每个增强后的系统调用转换为 38 维特征向量（25 维 one-hot 系统调用身份 + 13 个语义标志）的分词器；以及一个收集训练数据用于 ML 模型开发的评分器。
**自动化层**在训练时是一个脚本，负责编排针对每个样本的完整工作流：将 VM 还原到干净快照、启动、启动 FakeNet 进行网络模拟、通过命名管道连接 HyperDbg、引爆恶意软件、捕获系统调用跟踪、提取每个样本的数据并运行分析引擎。
**Guard 层**（ML 模型）是最后一层，负责做出将恶意软件分类为恶意或良性的决策，并编排响应动作。
## 关键设计决策
**为什么选择 Hypervisor 级别的捕获？** 传统的用户态 Hook（API Hooking、DLL 注入）很容易被恶意软件检测和绕过。通过 HyperDbg 进行的 Hypervisor 级别拦截运行在 Ring -1 —— 恶意软件无法检测、禁用或规避这些 Hook，因为它们存在于客户机整个执行环境之外。
**为什么选择系统调用跟踪而不是静态 PE 特征？** 静态特征（导入表、字节模式、文件结构）很容易被加壳器和多态引擎混淆。行为跟踪捕获的是恶意软件*做什么* —— 文件加密模式、进程注入序列、凭据转储 —— 这些行为无论二进制文件如何加壳都必须发生。
# 技术亮点
本项目构建过程中遇到的非平凡且在典型恶意软件分析工具中不常见的内容。
## Ring -1 系统调用捕获 —— 对恶意软件完全不可见
大多数恶意软件沙箱在 Ring 0（内核）或 Ring 3（用户态）进行 Hook。复杂的恶意软件通过检查内联补丁、IAT 修改或时间异常来检测这些 Hook，并相应地改变其行为。Sentinel 运行在 **Ring -1** —— Hypervisor 级别，位于整个客户机操作系统之下。恶意软件的内核无法看到、禁用或检测到这些 Hook，因为它们存在于一个完全独立的执行上下文（VMX root mode）中。客户机内存中没有 artifact，没有修改的代码页，也没有在 VM 内部可检测到的时间差异。客户机不知道它正在被监视。
## 24 个单独定制的系统调用 Hook 及指针遍历字符串提取
24 个被 Hook 的系统调用中的每一个在 HyperDbg 捕获脚本中都有一个自定义处理程序。其中五个（NtCreateFile, NtOpenFile, NtDeleteFile, NtOpenProcess, NtSetValueKey）在 **VMX root 模式下执行实时内核结构遍历** —— 遍历诸如 `R8 → OBJECT_ATTRIBUTES (+0x10) → UNICODE_STRING (+0x08) → Buffer` 这样的链，以实时提取文件名和注册表路径。每次指针解引用都通过 `check_address()` 进行保护，因为在 VMX root 模式下，一次错误的内存读取不仅会崩溃一个进程 —— 它会崩溃 Hypervisor 并导致整个 VM 崩溃。解引用失败会优雅地回退到原始寄存器捕获，而不是丢失该事件。
## 用于进程元数据的 EPROCESS 侧信道
NtCreateFile Hook 具有双重作用。除了捕获文件操作外，它还遍历当前进程的 `EPROCESS` 内核结构（偏移量 `$proc + 0x5A8`）以提取进程映像名称，从而生成作为侧信道的 IMG 记录。这意味着每个 NtCreateFile 事件还通过读取从用户态完全无法访问的内核内部数据结构告诉我们*哪个进程*进行了调用。无需进程枚举 API —— 数据直接来自内核自身的记录。
## VM 内 PE 加壳 —— 主机从不接触可执行恶意软件
BODMAS 数据集附带了 57,293 个 PE 头被置零（不可执行）的恶意软件样本。标准方法是使用 Python 脚本在研究人员的主机上对其进行加壳。相反，Sentinel 在**一次性客户机 VM 内部**对样本进行加壳 —— 引爆脚本读取主机上的 `meta_disarm.csv`，将原始 `Subsystem` 和 `Machine` 值嵌入到客户机脚本中，客户机在执行前使用原始 .NET 二进制 I/O 精确修补 PE 头中的 2 个字节。主机机器的文件系统上从未存在过可执行的恶意软件二进制文件。引爆后，VM 被强制终止并还原到干净快照 —— 加壳后的二进制文件在一次性环境中存在 5 分钟，然后不复存在。
## 通过模板注入实现零安装客户机脚本
客户机 VM 没有 Python、pefile 或除 7-Zip 和 PowerShell 之外的特殊工具。整个提取 → 加壳 → 执行工作流作为单个 PowerShell 脚本运行，该脚本在主机上为**每个样本新生成**，特定于样本的值（SHA256、zip 密码、PE 头值）通过占位符替换注入到 `.ps1.template` 文件中，然后复制到客户机并执行。这意味着当管道逻辑更改时，黄金快照永远不需要更新 —— 客户机是无状态的，并且每次引爆都会接收其指令。
## 具有快照隔离的全自动引爆
每个恶意软件样本通过一个 12 步自动化工作流运行：强制停止 VM → 还原到黄金快照 → 启动 WinDbg（内核调试，禁用 DSE）→ 启动 VM → 等待 VMware Tools → 启动 FakeNet（网络模拟）→ 通过命名管道连接 HyperDbg → 加载 24 个系统调用 Hook → 记录日志偏移量 → 复制 + 提取 + 加壳 + 执行恶意软件 → 捕获 N 秒 → 提取单样本跟踪 → 复制网络日志 → 终止所有内容 → 运行分析引擎。每一步都有错误处理、超时检测和清理。如果样本导致 VM 崩溃或 HyperDbg 死亡，管道会记录故障并移至下一个样本。它在无人值守的情况下运行了一夜，在 22 小时内处理了 158 个样本。
## 基于偏移量的日志提取 —— 无需单样本日志文件
HyperDbg 通过 `.logopen` 将所有系统调用事件写入单个 `master_stream.csv`。管道不是管理每个样本的单独日志文件，而是记录引爆前后的字节偏移量，然后仅提取新字节。正则过滤器仅保留有效的系统调用行（DEEP/RAW/RET/IMG），剔除 `.logopen` 也捕获的 HyperDbg 自身的状态消息和提示。这处理了 HyperDbg 持有文件写锁的事实 —— 提取使用 `FileShare.ReadWrite` 并发读取。
## 启动时通过 WinDbg 禁用 DSE —— 无需测试模式即可加载未签名驱动
HyperDbg 的客户机侧驱动程序未签名。通常这需要启用 Windows Test Signing 模式，这会留下可见的水印且可被恶意软件检测。相反，管道在 VM 启动**之前**启动带有内核调试连接的 WinDbg，并自动执行 `ed CI!g_CiOptions 0` —— 修补内核内存中的 Code Integrity 选项以在运行时禁用签名强制。没有测试模式水印，没有对客户机可见的启动配置更改，并且每次重新启动时都会重置（反正我们要还原到快照）。
## 具有暂停模式定序的命名管道 HyperDbg 连接
主机 HyperDbg CLI 通过映射到命名管道的 VMware 串口连接到客户机。连接使用 `pause` 模式 —— 客户机在连接的瞬间冻结，让主机有时间在任何客户机代码运行之前发送 `.logopen`、`.script` 并配置所有 Hook。这消除了启动时系统调用在 Hook 准备就绪之前触发的竞争条件。当 Hypervisor 对其进行检测时，客户机实际上在时间上是冻结的。
## 跨越 VMX 边界的入口/返回配对
每个系统调用都有一个入口事件（参数）和一个返回事件（NTSTATUS 结果）。HyperDbg 使用不同的 Hook 机制（`!syscall` 用于入口，`!syscall2` 用于返回）将这些作为单独的 VM-exit 捕获。Python 配对引擎通过 `(pid, tid, syscall_id)` 在 500ms 超时窗口内将它们匹配。这并非易事，因为：线程可以在入口和返回之间被抢占，同一进程中的多个线程可以并发调用同一系统调用，并且 Hypervisor 可能跨 CPU 重新排序事件。超时后未配对的条目作为 UNPAIRED 发出，而不是被静默丢弃。
## 7 种时间攻击模式检测器
进程图不仅跟踪父子关系 —— 它还检测跨越多个系统调用和进程的多步骤攻击序列：
- **Classic Injection（经典注入）：** OpenProcess → AllocateVirtualMemory → WriteVirtualMemory → CreateThreadEx（均针对同一远程进程）
- **Process Hollowing（进程镂空）：** CreateUserProcess(suspended) → UnmapViewOfSection → WriteVirtualMemory → ResumeThread
- **Section Injection（节注入）：** CreateSection → MapViewOfSection 进入远程进程
- **Thread Hijacking（线程劫持）：** SuspendThread → GetContextThread → SetContextThread → ResumeThread
- **APC Injection（APC 注入）：** OpenProcess → AllocateVirtualMemory → WriteVirtualMemory → QueueApcThread
每种模式都需要特定的系统调用按顺序发生，在时间窗口内针对同一远程进程。该图随时间累积边证据，并在观察到所有步骤时触发模式匹配 —— 这是单一事件检测器无法做到的。
## 双模态特征架构
ML 模型接收每个进程的两个根本不同的视图：一个**时间序列**（2048 × 38 个 token 向量，捕获带有已解码语义标志的有序系统调用流）和一个**结构快照**（20 维图特征向量，捕获进程在谱系树中的位置、注入关系和祖先信任级别）。加密文件的勒索软件在序列中看起来很独特（重复的读取 → 分配 → 写入模式）。进程注入器在图中看起来很独特（高注入出度、跨进程边）。双模态设计意味着没有任何单一的规避策略可以同时隐藏在两个视图之下。
## 架构概述
该系统分为三层。**Hypervisor 层**（HyperDbg, `capture.ds`）在 Ring -1 级别拦截 24 个 Windows 内核系统调用，并将其记录为包含四种记录类型的 CSV 行：DEEP（包含已解析字符串参数（如文件路径）的系统调用）、RAW（仅寄存器捕获）、RET（来自 syscall2 的返回值）和 IMG（来自 EPROCESS 遍历的进程元数据）。
**分析引擎**（`engine/`）通过六个组件处理这些跟踪数据：一个将入口调用与其返回值进行匹配的配对引擎；一个将原始数字参数解码为语义含义（访问标志、分配类型、保护位）的增强层；一个跟踪父子关系和跨进程注入模式的进程谱系图构建器；一个将每个增强后的系统调用转换为 38 维特征向量（25 维 one-hot 系统调用身份 + 13 个语义标志）的分词器；以及一个收集训练数据用于 ML 模型开发的评分器。
**自动化层**在训练时是一个脚本，负责编排针对每个样本的完整工作流：将 VM 还原到干净快照、启动、启动 FakeNet 进行网络模拟、通过命名管道连接 HyperDbg、引爆恶意软件、捕获系统调用跟踪、提取每个样本的数据并运行分析引擎。
**Guard 层**（ML 模型）是最后一层，负责做出将恶意软件分类为恶意或良性的决策，并编排响应动作。
## 关键设计决策
**为什么选择 Hypervisor 级别的捕获？** 传统的用户态 Hook（API Hooking、DLL 注入）很容易被恶意软件检测和绕过。通过 HyperDbg 进行的 Hypervisor 级别拦截运行在 Ring -1 —— 恶意软件无法检测、禁用或规避这些 Hook，因为它们存在于客户机整个执行环境之外。
**为什么选择系统调用跟踪而不是静态 PE 特征？** 静态特征（导入表、字节模式、文件结构）很容易被加壳器和多态引擎混淆。行为跟踪捕获的是恶意软件*做什么* —— 文件加密模式、进程注入序列、凭据转储 —— 这些行为无论二进制文件如何加壳都必须发生。
# 技术亮点
本项目构建过程中遇到的非平凡且在典型恶意软件分析工具中不常见的内容。
## Ring -1 系统调用捕获 —— 对恶意软件完全不可见
大多数恶意软件沙箱在 Ring 0（内核）或 Ring 3（用户态）进行 Hook。复杂的恶意软件通过检查内联补丁、IAT 修改或时间异常来检测这些 Hook，并相应地改变其行为。Sentinel 运行在 **Ring -1** —— Hypervisor 级别，位于整个客户机操作系统之下。恶意软件的内核无法看到、禁用或检测到这些 Hook，因为它们存在于一个完全独立的执行上下文（VMX root mode）中。客户机内存中没有 artifact，没有修改的代码页，也没有在 VM 内部可检测到的时间差异。客户机不知道它正在被监视。
## 24 个单独定制的系统调用 Hook 及指针遍历字符串提取
24 个被 Hook 的系统调用中的每一个在 HyperDbg 捕获脚本中都有一个自定义处理程序。其中五个（NtCreateFile, NtOpenFile, NtDeleteFile, NtOpenProcess, NtSetValueKey）在 **VMX root 模式下执行实时内核结构遍历** —— 遍历诸如 `R8 → OBJECT_ATTRIBUTES (+0x10) → UNICODE_STRING (+0x08) → Buffer` 这样的链，以实时提取文件名和注册表路径。每次指针解引用都通过 `check_address()` 进行保护，因为在 VMX root 模式下，一次错误的内存读取不仅会崩溃一个进程 —— 它会崩溃 Hypervisor 并导致整个 VM 崩溃。解引用失败会优雅地回退到原始寄存器捕获，而不是丢失该事件。
## 用于进程元数据的 EPROCESS 侧信道
NtCreateFile Hook 具有双重作用。除了捕获文件操作外，它还遍历当前进程的 `EPROCESS` 内核结构（偏移量 `$proc + 0x5A8`）以提取进程映像名称，从而生成作为侧信道的 IMG 记录。这意味着每个 NtCreateFile 事件还通过读取从用户态完全无法访问的内核内部数据结构告诉我们*哪个进程*进行了调用。无需进程枚举 API —— 数据直接来自内核自身的记录。
## VM 内 PE 加壳 —— 主机从不接触可执行恶意软件
BODMAS 数据集附带了 57,293 个 PE 头被置零（不可执行）的恶意软件样本。标准方法是使用 Python 脚本在研究人员的主机上对其进行加壳。相反，Sentinel 在**一次性客户机 VM 内部**对样本进行加壳 —— 引爆脚本读取主机上的 `meta_disarm.csv`，将原始 `Subsystem` 和 `Machine` 值嵌入到客户机脚本中，客户机在执行前使用原始 .NET 二进制 I/O 精确修补 PE 头中的 2 个字节。主机机器的文件系统上从未存在过可执行的恶意软件二进制文件。引爆后，VM 被强制终止并还原到干净快照 —— 加壳后的二进制文件在一次性环境中存在 5 分钟，然后不复存在。
## 通过模板注入实现零安装客户机脚本
客户机 VM 没有 Python、pefile 或除 7-Zip 和 PowerShell 之外的特殊工具。整个提取 → 加壳 → 执行工作流作为单个 PowerShell 脚本运行，该脚本在主机上为**每个样本新生成**，特定于样本的值（SHA256、zip 密码、PE 头值）通过占位符替换注入到 `.ps1.template` 文件中，然后复制到客户机并执行。这意味着当管道逻辑更改时，黄金快照永远不需要更新 —— 客户机是无状态的，并且每次引爆都会接收其指令。
## 具有快照隔离的全自动引爆
每个恶意软件样本通过一个 12 步自动化工作流运行：强制停止 VM → 还原到黄金快照 → 启动 WinDbg（内核调试，禁用 DSE）→ 启动 VM → 等待 VMware Tools → 启动 FakeNet（网络模拟）→ 通过命名管道连接 HyperDbg → 加载 24 个系统调用 Hook → 记录日志偏移量 → 复制 + 提取 + 加壳 + 执行恶意软件 → 捕获 N 秒 → 提取单样本跟踪 → 复制网络日志 → 终止所有内容 → 运行分析引擎。每一步都有错误处理、超时检测和清理。如果样本导致 VM 崩溃或 HyperDbg 死亡，管道会记录故障并移至下一个样本。它在无人值守的情况下运行了一夜，在 22 小时内处理了 158 个样本。
## 基于偏移量的日志提取 —— 无需单样本日志文件
HyperDbg 通过 `.logopen` 将所有系统调用事件写入单个 `master_stream.csv`。管道不是管理每个样本的单独日志文件，而是记录引爆前后的字节偏移量，然后仅提取新字节。正则过滤器仅保留有效的系统调用行（DEEP/RAW/RET/IMG），剔除 `.logopen` 也捕获的 HyperDbg 自身的状态消息和提示。这处理了 HyperDbg 持有文件写锁的事实 —— 提取使用 `FileShare.ReadWrite` 并发读取。
## 启动时通过 WinDbg 禁用 DSE —— 无需测试模式即可加载未签名驱动
HyperDbg 的客户机侧驱动程序未签名。通常这需要启用 Windows Test Signing 模式，这会留下可见的水印且可被恶意软件检测。相反，管道在 VM 启动**之前**启动带有内核调试连接的 WinDbg，并自动执行 `ed CI!g_CiOptions 0` —— 修补内核内存中的 Code Integrity 选项以在运行时禁用签名强制。没有测试模式水印，没有对客户机可见的启动配置更改，并且每次重新启动时都会重置（反正我们要还原到快照）。
## 具有暂停模式定序的命名管道 HyperDbg 连接
主机 HyperDbg CLI 通过映射到命名管道的 VMware 串口连接到客户机。连接使用 `pause` 模式 —— 客户机在连接的瞬间冻结，让主机有时间在任何客户机代码运行之前发送 `.logopen`、`.script` 并配置所有 Hook。这消除了启动时系统调用在 Hook 准备就绪之前触发的竞争条件。当 Hypervisor 对其进行检测时，客户机实际上在时间上是冻结的。
## 跨越 VMX 边界的入口/返回配对
每个系统调用都有一个入口事件（参数）和一个返回事件（NTSTATUS 结果）。HyperDbg 使用不同的 Hook 机制（`!syscall` 用于入口，`!syscall2` 用于返回）将这些作为单独的 VM-exit 捕获。Python 配对引擎通过 `(pid, tid, syscall_id)` 在 500ms 超时窗口内将它们匹配。这并非易事，因为：线程可以在入口和返回之间被抢占，同一进程中的多个线程可以并发调用同一系统调用，并且 Hypervisor 可能跨 CPU 重新排序事件。超时后未配对的条目作为 UNPAIRED 发出，而不是被静默丢弃。
## 7 种时间攻击模式检测器
进程图不仅跟踪父子关系 —— 它还检测跨越多个系统调用和进程的多步骤攻击序列：
- **Classic Injection（经典注入）：** OpenProcess → AllocateVirtualMemory → WriteVirtualMemory → CreateThreadEx（均针对同一远程进程）
- **Process Hollowing（进程镂空）：** CreateUserProcess(suspended) → UnmapViewOfSection → WriteVirtualMemory → ResumeThread
- **Section Injection（节注入）：** CreateSection → MapViewOfSection 进入远程进程
- **Thread Hijacking（线程劫持）：** SuspendThread → GetContextThread → SetContextThread → ResumeThread
- **APC Injection（APC 注入）：** OpenProcess → AllocateVirtualMemory → WriteVirtualMemory → QueueApcThread
每种模式都需要特定的系统调用按顺序发生，在时间窗口内针对同一远程进程。该图随时间累积边证据，并在观察到所有步骤时触发模式匹配 —— 这是单一事件检测器无法做到的。
## 双模态特征架构
ML 模型接收每个进程的两个根本不同的视图：一个**时间序列**（2048 × 38 个 token 向量，捕获带有已解码语义标志的有序系统调用流）和一个**结构快照**（20 维图特征向量，捕获进程在谱系树中的位置、注入关系和祖先信任级别）。加密文件的勒索软件在序列中看起来很独特（重复的读取 → 分配 → 写入模式）。进程注入器在图中看起来很独特（高注入出度、跨进程边）。双模态设计意味着没有任何单一的规避策略可以同时隐藏在两个视图之下。标签：AI合规, AMSI绕过, Apex, Conpot, EDR, HTTP工具, HyperDbg, Hypervisor, Ring -1, SQLite数据库, Windows安全, 内核监控, 威胁检测, 恶意样本, 机器学习, 沙箱, 深度学习, 特征提取, 系统调用拦截, 网络安全, 网络安全审计, 脆弱性评估, 自动化分析, 虚拟化安全, 跨站脚本, 进程行为, 逆向工具, 隐私保护