20242413 2026-2027-1 《网络与系统攻防技术》实验三实验报告

20242413 2026-2027-1 《网络与系统攻防技术》实验三实验报告

1. 基础知识

（1）杀软的检测机制
杀毒软件对恶意代码的检测分三层：①特征码检测——从已知恶意样本中提取独有字节串存入病毒库，扫描文件时比对，命中即报毒，对已知样本最有效；②启发式检测——不比对具体特征，根据"像不像恶意软件"推断，典型指标是高熵加壳段、可疑 API 组合（如 VirtualAlloc+CreateThread）、无数字签名等；③行为监控——程序运行时挂钩系统 API，一旦出现申请可执行内存、创建远程线程、反弹连接等高危动作立即拦截。此外还有基于机器学习的判定和云查杀作为补充。

（2）免杀的概念与方法
免杀（Anti-Virus Evasion）即通过技术手段让恶意代码规避杀软检测，在目标主机上正常运行。基本方法分两类：静态免杀——修改特征码、对 shellcode 编码/加密、加壳（UPX/Hyperion）、混淆花指令、更换文件格式、分离存储（载荷与加载器分开存放）；动态免杀——内存加载执行、延迟执行、反沙箱检测等。本实验验证的核心结论是：单一手段大多已被特征库收录，真正有效的是多种技术的组合。

（3）实验涉及的工具
msfvenom：Metasploit 的 payload 生成器，可生成 exe/jar/raw/c 等多种格式，支持 -e 指定编码器、-x 指定注入模板；Veil-Evasion：免杀框架，把 shellcode 嵌入自带的 C/Python 程序框架重新编译；UPX/Hyperion：压缩壳/加密壳工具；i686-w64-mingw32-gcc：MinGW 交叉编译器，在 Linux 上编译 Windows 程序；VirusTotal：多引擎在线检测平台，用"命中数/引擎总数"量化免杀效果。

实验环境：Kali Linux 虚拟机（主机名 linlu，IP 192.168.31.129，NAT 模式）；Windows 11 物理机（IP 192.168.31.1）作为被测机；回连端口统一使用 2413（学号后四位）；所有样本文件名均含学号 20242413。

2. 实验内容

1. 使用 msf 编码器（shikata_ga_nai 编码 1 次/10 次）及 msfvenom 生成 jar 等其他格式文件，测各样本在 VirusTotal 的检出率；
2. 使用 Veil-Evasion 框架生成免杀载荷并检测；
3. 使用 C + shellcode 手工编写加载器，并对样本分别施加 UPX 压缩壳、Hyperion 加密壳，检测对比；
4. 组合多种技术（自定义加密 + 组件分离 + 内存加载）实现免杀，并简单描述原理；
5. 在另一台电脑（Windows 11 物理机）实测：杀软开启情况下运行并回连成功，注明杀软名称与版本。

3. 实验过程

3.1 基准样本与 msf 编码器

生成未做任何处理的基准后门，作为后续所有对比的基线：

上传 VirusTotal 检测：基准检出率 52/71，威胁标签 trojan.lazy/swort，家族标签直接显示 meterpreter——说明杀软特征库认的就是 msfvenom 的固定模板和原始 payload 字节。

对同一 payload 分别用 shikata_ga_nai 编码 1 次和 10 次生成 enc1_20242413.exe、enc10_20242413.exe

检测得 34/50、47/68（换算约 68%、69%，与基准的 73% 基本持平）。

结论：编码次数对免杀几乎无影响——威胁标签变为 trojan.lazy/metasploit，家族仍含 metasploit，说明杀软盯的是编码器本身的特征（解码 stub 与模板），编码多少次都没用。

3.2 其他文件格式（jar）

检测得 36/64、37/64（约 56%、58%），低于 exe 基准。

结论：换文件格式有一定效果（部分引擎对 Java 覆盖率不足），但降得有限；且 shikata_ga_nai 是 x86 编码器，对 Java 字节码不起作用（编码前后 payload 大小不变），对 jar 再编码没有意义。

3.3 Veil-Evasion

安装 Veil

进入 Evasion 模块选择 c/meterpreter/rev_tcp（编号 7），set LHOST/LPORT 后 generate 生成 veil_20242413.exe（114KB）。

检测得 39/71（55%）。

结论：比基准 52/71 明显下降——威胁标签变为 trojan.zusy/atraps，家族标签中不再出现 metasploit。Veil 把 shellcode 嵌进自己的 C 框架重新编译，骗过了一批只认 Metasploit 模板的特征码引擎；但行为分析较强的引擎仍会报毒，所以降不到很低。这也说明 Veil 3.x 已老化，其生成物特征也已被部分收录。

3.4 C + shellcode 手工加载器

用 msfvenom 生成 C 格式 shellcode（sc_20242413.c）

编写加载器 loader_20242413.c：VirtualAlloc 申请可执行内存 → memcpy 拷贝 → CreateThread 执行。用 i686-w64-mingw32-gcc ... -static 交叉编译（-static 避免目标机缺 libgcc 等 DLL）。

检测得 25/70（36%），为当时最佳。

3.5 加壳工具测试

对 c_loader_20242413.exe 分别加壳：

• UPX：./upx c_loader_20242413.exe -o c_loader_upx_20242413.exe，
  
  检测 27/71，标签中直接出现 upx——知名压缩壳的节名和 stub 已被全部收录，加壳反而多了"壳特征"；

• Hyperion：AES 加密壳，检测 54/69（78%），不降反升——加密段熵值高触发启发式，且其 2015 年的 FASM 加载器 stub 是公开特征。
  

结论：知名壳已全部失效，单一加壳在现代杀软面前无效甚至负效果；手工加载器（25/70）优于一切现成壳。

3.6 组合免杀（尝试一：凯撒加密 + 内嵌数组）

思路：杀软认的是"shellcode 原始字节"，那就把字节变了——用 perl 把 raw shellcode 逐字节 +3（凯撒加密）写成十六进制文本，加载器运行时逐字节 -3 解密后内存执行。



生成 combo_20242413.exe，检测得 22/70（31%），且家族标签中 meterpreter/msfshell 完全消失（misc/convagent/hwch）——特征码引擎已认不出这是 Metasploit 产物，剩余的 22 家是看"申请可执行内存+创建线程"模式的启发式引擎。

3.7 物理机实测（尝试一：被行为监控拦截）

物理机环境：Windows 11，Microsoft Defender实时保护与云保护均开启。

Kali 端配置监听。

combo_20242413.exe 可正常 curl 下载、dir 验证 109,356 字节 intact——静态免杀骗过了 Defender 的扫描；但双击运行时 Defender 立即弹窗"发现威胁"，cmd 报"系统无法执行指定的程序"。

3.8 组合免杀（尝试二：XOR 加密 + 组件分离）与实测成功

分析 3.7 后改进：单一 exe 即使载荷加密，仍会被"机器学习静态判定 + 启动时行为监控"盯上。采用课件给出的组件分离方案——把载荷和加载器拆成两个文件：loader3_20242413.exe（只含读文件、解密、VirtualAlloc、CreateThread 等通用 API，无任何载荷字节）+ encoded_20242413.txt（XOR 0x5A 加密后的 shellcode 十六进制文本，纯数据文件杀软不报毒）。

生成（凯撒 +1 加密在 0xFF 字节处会溢出成三位十六进制导致串位，见问题3，故改用异或）：

perl -e 'binmode STDIN; binmode STDOUT; while(read(STDIN,$b,1)){ printf "%02x", ord($b)^0x5a }' < sc_raw_20242413.bin > encoded_20242413.txt

loader3 运行时读 txt、逐字节异或解密、申请可执行内存、创建线程执行。

物理机实测：两个文件下载到 Downloads（loader4 429KB、txt 710 字节），在目录下运行 loader4_20242413.exe——控制台依次打印 start / decoded 355 bytes / executing...，Defender 全程无弹窗、无拦截；同时 Kali 端 msfconsole 收到 Meterpreter session 1 opened (192.168.31.129:2413 -> 192.168.31.1:60824)。在杀软开启的情况下实现运行并回连成功。

4. 问题及解决方案

问题1：实验开始时 Kali 无法访问 VirusTotal（Server Not Found）。
解决方案：排查发现实验前把虚拟机网络适配器改成了"仅主机"模式，该模式无外网出口。改回 NAT 模式后执行 sudo dhclient -v eth0 重新获取 IP（恢复为 192.168.31.129），网络恢复正常。这也说明实验环境的网络配置要与实验需求匹配。

问题2：Hyperion-1.2 附件是源码包，直接运行报 File not found，编译接连报错。
解决方案：三连修——① Makefile 使用 Windows 反斜杠路径，Linux 下 make 不认，sed -i 's/\\/\//g' Makefile 统一改为正斜杠；② Makefile 默认调原生 g++ 编译 Windows 程序报"找不到 windows.h"，sed 把编译器替换为 i686-w64-mingw32-g++（并 apt 安装 g++-mingw-w64-i686）；③ 编译出的 hyperion.exe 动态链接 libgcc_s_dw2-1.dll、libstdc++-6.dll，wine 环境没有，给链接命令加 -static 静态链接后重新编译成功。

问题3：组件分离第一次尝试（loader3 + 凯撒加密 txt）运行时秒退，退出码 -1073741795（0xC000001D，非法指令）。
解决方案：用带打印的调试版 loader4 定位到"解密成功、执行即崩"，分析加密环节发现 bug：凯撒 +1 加密遇到原始字节 0xFF 时结果为 0x100，printf "%02x" 输出三位 "100"，导致后续整个十六进制串错位，解密出垃圾字节。改用异或（XOR 0x5A）加密——任何字节异或都不会溢出，问题消失，成功回连。

问题4：combo（加密载荷内嵌单文件）在物理机运行时 Defender 弹窗拦截。
解决方案：分析拦截发生在启动瞬间，判定为 Defender 的行为监控/云保护对"加密数据段 + RWX 内存申请"模式的判定，而非特征码命中（VT 静态检出已降至 22/70 且 meterpreter 特征消失）。改用组件分离：exe 里彻底不含载荷字节，载荷以 txt 形式存在，运行时再读入解密。实测通过。

问题5：VirusTotal 各次扫描的引擎总数不一致（71/50/68/64/70）。
解决方案：部分引擎对某些文件格式"无法处理"则不计入总数，属平台正常现象；报告与对比时统一换算为百分比（检出率/引擎数）再比较，避免分母不同造成误判。

5. 学习感悟、思考等

动手之前我以为免杀就是"换个壳、编个码"，做完才发现完全不是：编码 10 次和 1 次检出率纹丝不动，UPX、Hyperion 壳一加检出率反而更高——现成工具的特征就是杀软特征库的第一批收录对象。真正管用的反而是最朴素的组合：自己写个几十行的 loader、用最基础的异或把 shellcode 藏起来、让载荷和加载器分家。从 52/71 一路压到"Defender 全程无感"，最有成就感的不是某个工具，而是理解原理后自己动手的过程。

另一个深刻体会是静态免杀 ≠ 运行时免杀：combo 在 VT 上只有 22/70、特征码引擎全部放行，却仍然被 Defender 在启动瞬间拦下——杀软的终点防线是行为监控。这也让我对日常安全有了更具体的认识：不乱点陌生程序是对的，但更要警惕那些"看起来正常"的程序，因为行为监控是最后一道、也是会被高级免杀绕过的防线。

在法律与道德层面，我也深有感触。技术本身没有善恶，可以用于渗透测试检验自身防护，也可以用于作恶。本次实验所有样本只在自有机器的实验环境中测试，在此我学习了攻击手法，也学习了守住不滥用的底线。

回答问题：

(1) 杀软如何检测恶意代码：①特征码检测，比对病毒库中已知恶意样本的字节特征；②启发式检测，根据高熵、可疑 API 组合等"像不像"的特征推断；③行为监控，运行时挂钩 API，拦截申请可执行内存、远程线程注入、反弹连接等高危动作；④机器学习与云查杀辅助。本实验的多组数据分别对应了这几层：编码器失效对应①，Hyperion 高熵被报对应②，combo 运行被拦对应③。

(2) 免杀是做什么：通过技术手段修改恶意代码及其投递方式，规避杀毒软件的检测与拦截，使恶意程序在杀软开启的目标机上能够正常运行并达到预期目的（本实验中为回连控制）。

(3) 免杀的基本方法：静态方面——修改/消除特征码、编码与加密（msf 编码器、自定义 XOR/AES）、加壳（UPX/Hyperion）、混淆花指令、更换文件格式（exe/jar/php）、组件分离（载荷与加载器分文件存放）；动态方面——内存加载执行、延迟执行绕过沙箱超时、反沙箱检测、间接系统调用绕过用户态 Hook 等。实践中需多层组合，本实验最终方案即"自定义加密 + 组件分离 + 内存加载"的组合。