面向安全产品测试的静态混淆型 Shellcode Loader 设计与对抗分析

github 地址：https://github.com/LilDean17/ShellcodeLoader2025

一、项目背景

​ 近年来，随着 C2 框架广泛应用于安全对抗模拟，各大安全厂商也不断提升其检测能力，那么安全厂商自研的安全软件，是否能有效防御此类威胁？对于此疑问的好奇，我开始对安全软件和 C2 框架进行了深入的研究，于是此项目诞生了。此项目旨在模拟严苛的静态环境来测试安全软件对于 C2 框架的检测力度。此项目对于研究安全问题的伙伴，对于安全厂商以及对于研发安全产品的企业提供了关于 C2 框架检测相关的数据支持。

1.1 什么是 C2 框架？

​ C2（Command &Control 命令与控制）框架，特指渗透人员用于建立、管理和维持对已控系统（被控端）的集中化、结构化的软件体系平台。它是高级持续性威胁和定向攻击的核心工具，实现了攻击行动的数据窃取和横向移动。其核心目标如下：

• 持久化：长期地潜伏在目标网络而不被发现。
• 数据窃取：将窃取的机密数据传输回渗透人员。
• 任务执行：向被控端下发指令，用于执行恶意操作。
• 隐蔽通信：在受害者系统与攻击者服务器之间建立难以检测的通信通道。
• 集中化管理：提供渗透人与一个中心界面，用于批量控制大量被控端。

1.2 C2 框架的核心组件是什么？

• C2 服务器：渗透人员的指挥中心，用于接收被控端连接、存储指令和任务、收集渗透数据、管理被控端状态。
• 被控端代理程序：用于植入在被控端的软件程序，在目标系统上接收并执行 C2 服务器下发的指令，也是安全软件对抗的核心。
• C2 操作界面：渗透人员使用的图形化或命令行界面。

C2 框架的核心架构图如下：

1.3 为什么要使用 loader？

​ shellcode 作为威胁存在的一种重要形式，其存储方式非常隐蔽，且可被攻击者快速地传播利用。loader 加载器是加载执行 shellcode 的一串代码，它通常直接或间接的运行 shellcode 程序。为了测试安全软件的功能性，观测其在木马隐蔽场景下的查杀率，所以选用 shellcode + loader 的方式测试安全软件的功能。

1.4 静态查杀与动态查杀的区别？

​ 静态查杀通常是通过扫描文件的静态特征匹配病毒库来判断此文件是否属于木马家族或其他恶意文件，如果属于，安全软件则会发送告警。动态查杀通过监测可执行文件的行为，来匹配其是否属于恶意文件，如果其触发了安全厂商设定的敏感行为（如：修改注册表），则触发告警。

1.5 安全软件对 shellcode 的检测挑战

​ 由于 shellcode 以二进制形式连续存储于内存之中，其可以被攻击者实施加密存储，因此静态识别并查杀情况下，shellcode 具有非常强的隐蔽性，安全软件需要多方面判断来识别 shellcode 所运行的进程是否具有危害。这极大的要求了安全软件在静态查杀和动态查杀方面的结合，通过一系列复杂的判断条件识别潜在的威胁。

二、软件设计

​ 为了测试各大厂商的安全软件对于 shellcode 的识别能力，我自主开发了一套静态混淆型 shellcode 加载框架用于测试。本项目由两个子系统构成，分别承担 shellcode 构建、加壳和加载的任务。

2.1 shellcode builder（构建端）

​ 使用 python 实现，主要职责：

• 读取 shellcode 文件。
• 初始化动态加密密钥/iv，并进行加密和编码。
• 初始化动态的函数哈希。
• 将以上所有配置信息注入到 shellcode loader（运行端）中。
• 使用 ollvm 混淆编译 shellcode loader（运行端）。

​ 包含模块：

• encrypt.py：加密模块，用于生成动态 aes 密钥和 iv 并加密数据。
• patch.py：配置注入模块，用于将如下信息注入到 shellcode loader：
  • 动态生成的 aes key 和 iv。
  • 动态生成的函数哈希。
  • 加密编码后的 shellcode。
• compiler.py：编译模块，使用 ollvm 混淆编译 shellcode loader。

2.2 shellcode loader（运行端）

​ 使用 c 实现，主要职责：

• 通过对比函数哈希初始化 winapi 地址。
• 初始化 syscall 函数。
• 解密并还原加密的 shellcode 数据。
• 选择加载方式进行加载（指针回调、纤程执行、winapi 回调）

​ 包含模块：

• peb.cpp：用于读取函数哈希初始化 winapi 函数地址。
• syscall.cpp：用于初始化间接 syscall 函数。
• decrypt.cpp：用户解密解码 shellcode。
• cLoader.cpp：用于执行 shellcode。

2.3 架构图

三、静态混淆策略

3.1 函数哈希的随机化

​ 特征提取检测是安全软件检测市面上木马病毒常用手段，安全厂商通过提取特征码并存储到病毒库中来匹配某一特定的恶意程序。通常情况下特征码是从一些静态数据或恒定的二进制代码端提取的，为了避免被提取特征码，我将一些静态数据如函数哈希和密钥/iv 做了随机化处理，确保每一次生成的 loader 的静态数据都是不唯一的。

3.2 shellcode 加密处理

​ shellcode 加密是最常见的混淆手段，在程序运行前，shellcode 同时是加密存储在二进制文件中。加密存储虽然有效，但是安全厂商也有针对的应对策略，基于熵值的检测。shellcode 加密会导致文件熵值增高，这会导致可执行文件在安全软件严重十分可以，为了避免熵值的膨胀，我们需要将加密后的数据转换成合法数据。

3.3 shellcode 编码处理

​ shellcode 编码将加密后的数据转换成合法数据，如：ipv4 地址、uuid、mac 地址等，此软件实现 ipv4 地址和 uuid 编码降低熵值。

3.4 ollvm 混淆

​ 为了防止代码段特征的提取，我使用了 clang 编译器开发此软件，重点使用此编译器拓展的 ollvm 混淆功能。ollvm 混淆能有效提升编译后的代码复杂度和逆向难度，ollvm 有非常多的混淆机制：如控制流平坦化、指令替换、虚假控制流等。

3.5 动态混淆策略

​ 由于此项目的目的是针对安全软件对静态混淆型 shellcode loader 的测试，而不是单一地去绕过某一安全软件的检测，所以只添加了最基础的动态混淆的代码以提升 shellcode loader 的存活率。动态混淆方面，此项目使用到了开源 syscall 工具 hell’s gate，结合本项目，其详细功能如下：

• 动态解析 ssn 号：遍历 ntdll 导出表。（动态解析 ssn 号，能防止源码嵌入 ssn 号而提取静态特征。）
• 直接 syscall：动态获取 nt 函数地址并进行 0x12 偏移来提取多个 syscall 地址。

四、项目拓展

​ 为了进一步测试安全软件的功能，我对此项目进行了扩展。真实场景中 loader 不一定是 exe 可执行文件，它很有可能是 dll 文件。某些情况下，dll 文件可能通过进程劫持注入代码。这种情况下，shellcode 的执行可能会更加隐蔽，为了模拟这种效果，我为我的项目实现了生成 dll 的功能。

五、安全软件测试结果

​ 本项目设计目标之一是验证相同的静态混淆策略对主流终端安全软件的触发行为差异，以评估各加载方式的有效性与隐蔽性。

5.1 测试环境

• windows 10 22H2（x64）
• 测试平台：VMware 17
• 是否接入互联网：是
• 测试样本（被控端代理程序）：
  • cobaltstrike 4.8 beacon
  • havoc demon
• 安全软件版本
  • Microsoft Defender（客户端版本: 4.18.1909.6）
  • 360 安全卫士（版本：13.0.0.2009）
  • 火绒安全（个人版：6.0.6.6，病毒库：2025.6.28）
  • 卡巴斯基（企业版：kes 11.6.0.394）

5.2 测试方式说明

阶段	说明
静态查杀	下载 loader 可执行文件并执行后是否触发报毒。
解密解码	解密解码 shellcode 后是否触发报毒
执行阶段	开始执行是否触发报毒
执行后	执行后进行常规操作是否触发报毒（这里采用读取文件信息进行测试）
敏感操作	执行后进行敏感操作是否触发报毒（这里采 用读取系统进程信息进行测试）

5.3 测试结果

cobaltstrike 4.8 beacon 测试结果

安全软件	文件类型	静态查杀	解密解码	执行阶段	执行后	敏感操作
Microsoft Defender	exe 可执行文件	❌触发扫描，但未报毒	❌内存明文存放 shellcode，未报毒	✔️立刻报毒	无	无
Microsoft Defender	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
360 安全卫士	exe 可执行文件	❌主动扫描，未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
360 安全卫士	dll 劫持	✔️立刻报毒，标记为检测到 dll 劫持	无	无	无	无
火绒安全个人版	exe 可执行文件	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
火绒安全个人版	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
卡巴斯基企业版	exe 可执行文件	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
卡巴斯基企业版	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒

havoc demon 测试结果

安全软件	文件类型	静态查杀	解密解码	执行阶段	执行后	敏感操作
Microsoft Defender	exe 可执行文件	❌触发扫描，但未报毒	❌内存明文存放 shellcode，未报毒	❌未报毒	❌未报毒	❌未报毒
Microsoft Defender	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
360 安全卫士	exe 可执行文件	❌主动扫描，未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
360 安全卫士	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
火绒安全个人版	exe 可执行文件	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
火绒安全个人版	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
卡巴斯基企业版	exe 可执行文件	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒
卡巴斯基企业版	dll 劫持	❌未报毒	❌未报毒	❌未报毒	❌未报毒	❌未报毒

⚠️注：以上测试仅用作数据参考，不代表安全产品的优劣。

六、测试结果分析

6.1 C2 框架测试结果对比

对比维度	cobaltstrike 4.8 beacon	havoc demon
静态检测风险	高（即使高强度加密编码，仍能被 360 启发式识别）	极低（无法识别）
内存行为检测风险	高（Defender 捕获 exe 内存特征可以识别）	极低（无法识别）
感知强度	高（安全厂商针对性研究）	极低（全平台规避监测）

6.2 各大厂商安全软件测试结果对比

安全厂商	查杀方式类别	对 beacon 的响应	对 demon 的响应	查杀策略水平评估	初步技术判断/推测机制
Microsoft Defender	内存行为感知 + 部分特征扫描	✔️ 执行阶段立刻报毒	❌ 全程绕过	⭐⭐⭐⭐（4/5）	监控内存 + 内存扫描
360 安全卫士	启发式判定	✔️ dll 劫持加载瞬间拦截，exe 无响应	❌ 全程绕过	⭐⭐⭐（3/5）	启发式判定系统评估
火绒安全软件	以防护为主	❌ 全程绕过	❌ 全程绕过	⭐⭐（2/5）	未知
卡巴斯基企业版	未知	❌ 全程绕过	❌ 全程绕过	⭐⭐（2/5）	未知

6.3 什么是启发式查杀？

​ 启发（heuristic）：（一种教学方法）让学生通过自己发现事物并从自己的经验中学习，而不是通过告诉他们事物来学习。

​ 启发式查杀：给予安全软件一定的规则，让安全软件以此规则作为经验，去分析一个程序的合规性，而不是通过严格的逻辑推理来解决问题。常见的启发式查杀经验：

• 文件熵值过高。
• 导出表空但含大量代码段。
• 导出表含大量函数，但代码段很小。

6.4 Microsoft Defender 测试结果分析

查杀 beacon 原因推测分析如下：

​ 执行阶段立刻查杀，此时 shellcode 已被解密解码，明文存储在内存中。但是，Microsoft Defender 全程监控此进程内存，当检测到 shellcode 的内存由 RW -> RX 修改时，扫描该区域并匹配到 beacon 特征。

未检测到 dll 劫持原因推测分析如下：

​ 完全忽视 dll 劫持场景，不对进程进行监控。

未检测到 demon 的原因：

​ 未分析并提取 demon 特征。

6.5 360 安全卫士测试结果分析

瞬间查杀 beacon 的 dll 劫持原因推测分析如下：

​ 启发式判定系统检测到可疑 dll（导出表可疑等），最主要的判定其为恶意 dll 的原因是分析加密编码后的 shellcode 的特征，如：

• 即使 aes 加密 + uuid 编码，其 payload 长度与 beacon 做同样操作后长度类似。
• aes 加密 + uuid 编码后长度过长，引起怀疑。

未检测到 exe 中的 shellcode 的原因如下：

​ 启发式判定系统认为 exe 中存在过长的数据是合理行为。

dll 劫持未查杀 demon 的原因：

• 缺乏 demon payload 的确切特征。
• aes 加密 + uuid 编码后长度非常小。

6.6 火绒安全软件测试结果分析

未检测到 shellcode 的原因：

​ 个人版以安全防护为主，考虑真实用户体验。

6.7 卡巴斯基企业版测试结果分析

卡巴斯基企业版即使开启云查杀等所有功能，但仍未检测到 shellcode 的原因：

• 个人研发的 loader 具备强大的静态混淆能力，几乎达到 100% 的静态混淆。
• 未对内存中的明文 shellcode 进行扫描。可能扫描机制是延迟或事件触发型。
• 卡巴斯基可能没有 360 那种对 beacon payload 的泛化机制，它没有对 aes 加密 + uuid 编码的 shellcode 起疑心

本实验使用卡巴斯基企业版默认配置，联网环境并开启云查杀，但在本测试环境下确实未触发检测机制。

⚠️注：以上结论可能导致对卡巴斯基的查杀水平错误低估，请理性看待。

6.8 总结

针对严苛静态无特征化的 shellcode loader 有用的技术：

• 内存监控 + 内存扫描
• 启发式判定

七、使用方法

7.1 运行环境

• Python：3.11.0
• ninja：1.12.0.git
• clang：20.1.5（ollvm）
• vs 2022 C++ 桌面开发环境
• python 库：pycryptodome=3.20.0
• python 库：pyfiglet=1.0.2

注：以上是本人使用的运行环境，仅仅作为参考。

7.2 支持参数

• --i：用于输入 shellcode.bin 文件。
  • shellcode 的 文件路径。
• --exec：用于设置执行方式。
  • thread：创建线程执行 shellcode。
  • fiber：创建纤程执行 shellcode。
  • callback：Winapi 回调函数执行 shellcode。
• --encode：
  • ipv4：用于将加密的 shellcode 编码成 ipv4 地址。
  • uuid：用于将加密的 shellcode 编码成 uuid 地址。
• --file：
  • exe：用于指定生成 exe 文件。
  • dll：用于指定生成 dll 文件。
• --export（仅在生成 dll 文件情况下生效）：
  • 文件路径：用于指定 dll 文件的导出函数。

其中 --export 导出函数文件存储如下示例内容：

7.3 构建过程

使用如上默认配置进行构建，python 将执行如下操作进行构建：

配置注入：

• 获取 loader 的项目路径（c 语言） 。
• 获取 shellcode.bin 文件路径，读取、加密、编码并 patch 到源文件。
• 初始化 aes 密钥和 iv，并 patch 到源文件。
• 初始化 Winapi 函数哈希，并 patch 到源文件。

编译 loader：

• 构建并编译 loader。

构建完成后，在 build 目录下会生成 loader。

八 、项目价值与边界

8.1 应用场景价值

​ 本项目设计初衷为在合法授权的环境中，用作以下内容的研究与评估：

• 安全软件测试评估：测试安全软件在严苛的静态对抗环境下的检测能力。
• 安全软件行为研究：测试安全软件用于检测威胁的技术方式。
• 教学与演示：适合作为教学样例，展示设计架构和静态混淆技术。
• 提供数据：向研究人员提供数据参考。

8.2 合规边界声明

​ 本项目不包含任何恶意 payload 或远控功能，仅提供 loader 框架和加密封装机制，所有测试 payload 必须由用户在合法授权环境下自行提供，且尽在授权环境中使用。

8.3 作者声明

• 本人不对任何非法使用本项目代码所产生的后果负责。
• 严禁在未授权的目标环境中部署与测试。
• 若您是安全厂商/研究人员，欢迎就技术实现展开探讨。

九、声明与许可

9.1 项目免责声明

​ 本项目仅供安全研究、教育教学和防御评估。不得将其用于任何非法用途，包括但不仅限于未授权渗透、后门植入等。所有示例均在授权环境下进行测试。