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

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

1.基础知识

本次实验围绕恶意代码分析展开，涉及的知识可以归纳为以下几条主线。

（1）PE 文件结构与识别

Windows 可执行文件遵循 PE（Portable Executable）格式，开头是 DOS 头，e_lfanew 指向 PE 签名，其后是文件头、可选头与节表。节表描述 .text、.data、.rsrc 等节区的虚拟地址、大小和文件偏移。用 file 命令可以读出“PE32 executable for MS Windows (GUI), Intel i386, N sections”一类的信息，判断目标是否为 32 位 GUI 程序、有多少个节，是恶意代码分析的第一步。

（2）加壳与脱壳

加壳器把原始可执行文件的代码和数据压缩、加密后存放在新的节区中，并把程序入口点改成一段解压存根（stub）。程序运行时由存根在内存中还原原始映像，再把控制权交回原入口（OEP）。UPX 是最常见的压缩壳，其典型特征是节名 UPX0/UPX1、文件尾部的“UPX!”标识，以及入口处 pushad、mov esi/lea edi、NRV2B 解压循环一类的指令序列。脱壳就是把原始映像从壳中还原出来，常见手段是用专用脱壳工具（UPX -d、超级巡警、PEiD 插件等），或者动态运行后在内存中 dump。

（3）静态分析与反编译

静态分析不运行样本，只对二进制做反汇编、反编译、字符串和导入表分析。IDA Pro 与 Ghidra 都能把机器码还原成汇编和类 C 伪代码，并通过交叉引用（XREF）把字符串、导入函数与调用点关联起来。恶意代码中的硬编码域名、URL、注册表路径、命令关键字，往往能在字符串表和伪代码里直接看到，是判断其功能最直接的证据。

（4）恶意代码分类与后门

恶意代码大致分为病毒、蠕虫、木马/后门、勒索软件、僵尸程序等。后门（Backdoor）不自我复制，而是通过伪装、捆绑等方式进入主机，建立持久的、隐蔽的远程控制通道；僵尸程序（Bot）则进一步接受 C&C 服务器指令，可被组织成僵尸网络发动 DDoS、发送垃圾邮件或作为跳板。

（5）僵尸网络与 IRC 协议

IRC（Internet Relay Chat）是基于文本的实时聊天协议，客户端注册时需要发送 PASS/NICK/USER 组合消息，加入频道时发送 JOIN，服务器用 353 数值回复广播频道成员名单，用 266 回复广播当前全局用户数（Current global users）。僵尸网络常借用 IRC 服务器作为命令控制信道，因此 IRC 流量中的服务器地址、JOIN/QUIT 记录和成员名单，可以用来估算僵尸网络的规模。

（6）网络取证

取证分析以 pcap 抓包文件为数据源，借助 tcpdump、tshark、tcpflow、Wireshark 等工具还原会话：按五元组过滤流量、重组 TCP 流、统计协议层次和端口分布、提取 HTTP URI 与 SMB 命令，从而判断攻击者用了哪些漏洞、哪些攻击得手。蜜罐是被故意布置的诱饵主机，其流量可以反映真实的攻击行为。

2.实验内容

本次实验共四个部分：

一、恶意代码文件类型标识、脱壳与字符串提取：对提供的 RaDa 恶意代码样本识别文件格式、运行平台和加壳工具；使用脱壳工具对其脱壳；对脱壳后的样本做字符串提取，找出编写作者。

二、使用 IDA Pro（本机以 Ghidra 替代）静态或动态分析 crackme1.exe 与 crackme2.exe，找出能够输出成功信息的特定输入。

三、分析自制恶意代码样本 RaDa，回答样本摘要、目的、特性、反分析技术、分类、相似工具、作者溯源、检测方法等八个问题。

四、取证分析实践：以 Snort 收集的蜜罐主机五天网络数据（botnet_pcap_file.dat）为数据源，回答 IRC、僵尸网络规模、攻击者 IP、攻击漏洞与攻击是否成功等问题。

3.实验过程

3.1 实验环境与样本准备

实验在 VMware Workstation 中的 Kali Linux 2026.2 虚拟机内完成，主机名为 niuyuxuan（本人姓名拼音），CPU 4 核、内存 2 GB、NAT 网络。分析工具包括 file、md5sum、objdump、strings、UPX 4.2.4、Ghidra 12.1.4、wine 10.0、tcpdump、tshark、tcpflow、Wireshark。为便于归档，所有材料放在 /home/kali/20242429_lab4 目录下，截图与脚本均以学号命名。

图1 实验目录与样本文件

3.2 RaDa 样本的文件类型识别与摘要

先用 file 命令识别样本的文件格式与运行平台。结果显示 RaDa.exe 是“PE32 executable for MS Windows 4.00 (GUI), Intel i386, 3 sections”，即 32 位 Windows 图形界面程序，内部包含 3 个节区，与实验要求中“文件格式、运行平台”的描述一致。

图2 用 file 识别 RaDa.exe 的文件类型

计算样本摘要并提取时间戳：md5sum 得到 caaa6985a43225a0b3add54f44a0d4c7，sha1sum 得到 4164423ece62c5c4c287f8c2003b84e4e3a6cfda；exiftool 显示 PE 时间戳为 2004-10-29 19:59:58。MD5 与公开的 Honeynet SotM32 样本一致，说明分析对象就是原始样本，没有在传输过程中被修改。

图3 计算 MD5 摘要并提取编译时间戳

3.3 加壳工具识别

用 objdump -h 查看节表，可以看到两个异常的节名 JDR0 与 JDR1：JDR0 的 RawSize 为 0、VirtualSize 为 0xB000，说明它是运行时才展开的空节；JDR1 才是真正存放压缩数据的节。strings 又提取到“JDR0”“JDR1”“JDR!”等特征字符串。结合入口处 pushad、mov esi, 0x40C000、lea edi, [esi-0xB000]、NRV2B 解压循环的指令特征，可以判断样本使用的是 UPX 压缩壳，但节名和文件尾部的“UPX!”魔数被改成了“JDR!”，属于“改壳”处理。

图4 objdump 查看节表及 JDR 特征字符串

3.4 脱壳处理

直接用 UPX 脱壳失败：程序提示“CantUnpackException: file is modified/hacked/protected; take care!!!”，说明 UPX 识别出了样本被改动过，拒绝处理。

图5 直接使用 upx -d 脱壳失败

针对这种情况，编写脚本 20242429_fixupx.py：解析 PE 节表，把 JDR0/JDR1 改回 UPX0/UPX1，再把文件中的“JDR!”魔数改回“UPX!”，得到 RaDa_fixed.exe。修复后 upx -l 已能把文件识别为 win32/pe 的 UPX 压缩文件，压缩率 36.61%。

图6 修补节名与魔数后 UPX 能正确识别

随后执行 upx -d 成功脱壳，得到 57344 字节的 RaDa_unpacked.exe（原文件 20992 字节），文件类型仍为 PE32 GUI i386、3 个节区。

图7 upx -d 脱壳成功

图8 脱壳后文件类型与大小对比

3.5 字符串提取与作者溯源

对脱壳后的文件执行 strings -a，并过滤 Raul、Siles、Perez、SotM 等关键字，可以直接看到“(c) Raul Siles && David Perez”与“SotM 32 - September 2004”两条明文，另有“!This program is the binary of SotM 32..”。由此确定 RaDa 的编写作者是 Raul Siles 和 David Perez，样本创作于 2004 年 9 月，是 Honeynet“Scan of the Month 32”挑战所用的样本。

图9 脱壳后提取到作者与创作时间字符串

3.6 crackme1.exe 的分析

先在 wine 中直接运行 crackme1.exe，程序输出“I think you are missing something.”；随机给一个参数（hello），输出“Pardon? What did you say?”。这说明程序对参数个数和参数内容都做了检查。

图10 不带参数运行 crackme1.exe

图11 带错误参数运行 crackme1.exe

把 crackme1.exe 导入 Ghidra，自动分析后在反编译窗口查看主函数。伪代码显示：当 _Argc == 2 时，用 strcmp(_Argv[1], "I know the secret") 与固定字符串比较，相等则 puts 成功信息，否则输出“Pardon? What did you say?”；参数个数不为 2 时输出“I think you are missing something.”。因此在命令行第二个参数位置输入 I know the secret 即可得到成功信息。

图12 Ghidra 反编译 crackme1 主函数

验证：执行 wine crackme1.exe 'I know the secret'，程序输出“You know how to speak to programs, Mr. Reverse-Engineer”，分析正确。

图13 输入正确参数得到成功信息

3.7 crackme2.exe 的分析

在 wine 中运行 crackme2.exe 并输入同样的 I know the secret，仍然只得到“Pardon? What did you say?”，说明 crackme2 比 crackme1 多了一层校验。

图14 crackme2 输入关键字仍失败

Ghidra 反编译显示，crackme2 的主函数在参数个数判断之前先执行了 strcmp(_Argv, "crackmeplease.exe")：只有当程序自身的名字（argv[0]）恰好等于 crackmeplease.exe 时，才会继续比较第二个参数是否为 I know the secret。因此需要把文件改名为 crackmeplease.exe 再运行。

图15 Ghidra 反编译 crackme2 主函数（含文件名校验）

需要注意的是，程序比较的是完整的 argv[0]。在 Linux 下用 wine 运行时，若写成 ./crackmeplease.exe，传入的 argv[0] 带上了路径前缀，校验仍然失败（图16）；只有通过 wine cmd /c 按文件名调用，argv[0] 才是“crackmeplease.exe”。另外直接用 wine crackme2.exe 调用也会失败（图17）。

图16 带 ./ 前缀运行导致文件名校验失败

图17 未改名直接运行仍失败

改名后用 cmd 方式运行：wine cmd /c crackmeplease.exe 'I know the secret'，程序输出成功信息，验证了分析结论。

图18 改名后输入正确参数得到成功信息

3.8 RaDa 样本的静态分析

在 Ghidra 中打开脱壳后的 RaDa_unpacked.exe 并完成自动分析。由于样本是 VB6 编写的 P-code 程序，入口被解析成对 MSVBVM60.DLL 的 thunk 调用，直接看流程图意义不大，因此改用“Defined Strings”窗口查看程序中的字符串常量，如图19 所示。

图19 Ghidra 字符串窗口中的关键字符串

字符串窗口集中暴露了样本的行为：http://10.10.10.10/RaDa、RaDa_commands.html、cgi-bin、download.cgi、upload.cgi 构成命令控制与上下载通道；C:\RaDa\tmp、C:\RaDa\bin、RaDa.exe 是工作目录与自复制路径；HKLM\Software\Microsoft\Windows\CurrentVersion 是开机自启动项所在位置；“Starting DDoS Smurf remote attack...”与 Command_install、Command_uninstall、Command_exit、Command_usage、Command_conf、Command_go 则说明它内置了命令解析和 DDoS 模块；“Security through obscurity is the key.”是作者留下的一句话。

在 Listing 中跳转到 004023A4 附近，可以看到这条 C&C 地址以 Unicode 形式存放在 .data 节中，紧邻 RaDa_commands.html；该地址带有 2 个交叉引用。

图20 Listing 中的 C&C 地址与交叉引用

再用 strings -a -el 提取 Unicode 字符串，可以更完整地看到 URL、目录、命令与 HTML 页面标题（<TITLE>RaDa Usage</TITLE>、<TITLE>RaDa Current Configuration</TITLE>）以及“Upload file using http And multipart/form-data”，说明样本通过 HTTP 的 multipart 表单上传文件。

图21 提取样本中的 Unicode 字符串

查看导入表，样本只导入了 MSVBVM60.DLL，所有 Win32 API 都通过 VB6 运行时的 Declare 机制间接调用，这也是它看起来“导入表很干净”的原因。

图22 样本的导入表（仅 MSVBVM60.DLL）

3.8.1 问题回答

问题一：提供对这个二进制文件的摘要，包括可以帮助识别同一样本的基本信息。

回答一：RaDa.exe 为 32 位 Windows GUI 程序（PE32, Intel i386, 3 个节区），文件大小 20992 字节，MD5 为 caaa6985a43225a0b3add54f44a0d4c7，SHA1 为 4164423ece62c5c4c287f8c2003b84e4e3a6cfda，PE 时间戳为 2004-10-29 19:59:58，使用经过改动的 UPX 壳（节名 JDR0/JDR1、魔数 JDR!），脱壳后 57344 字节。样本内含“(c) Raul Siles && David Perez”“SotM 32 - September 2004”等标识，可用于识别同一家族的样本（见图2、图3、图9）。

问题二：找出并解释这个二进制文件的目的。

回答二：它是一个具有持久化能力的远程控制后门。程序启动后先在 C:\RaDa 下建立 bin、tmp 工作目录，把自身复制为 C:\RaDa\bin\RaDa.exe，并修改注册表 HKLM\Software\Microsoft\Windows\CurrentVersion\Run 实现开机自启动；随后访问 http://10.10.10.10/RaDa/RaDa_commands.html 获取指令，通过 cgi-bin/download.cgi、upload.cgi 与 C&C 服务器交换文件和数据，并按指令执行安装、卸载、配置、DDoS（Smurf）等操作。换言之，它把受害主机变成一个可被远程操控的节点。

问题三：识别并说明这个二进制文件所具有的不同特性。

回答三：①持久化：写 Run 键实现开机自启，并在 C:\RaDa\bin 留有副本；②文件与目录操作：建立 C:\RaDa\tmp 作为临时目录，下载文件、上传窃取的数据；③网络通信：硬编码 C&C 地址 10.10.10.10，使用 HTTP 协议与 download.cgi/upload.cgi 交互；④命令解析：Command_install、Command_uninstall、Command_usage、Command_exit、Command_conf、Command_go 等命令字；⑤攻击能力：内置“DDoS Smurf remote attack”模块；⑥配置管理：用 HTML 页面展示 Usage/Current Configuration；⑦开发特征：VB6 编写、GUI 子系统、Unicode 字符串。

问题四：识别并解释这个二进制文件中所采用的防止被分析或逆向工程的技术。

回答四：主要使用了 UPX 压缩壳，并做了针对性改动：把节名从 UPX0/UPX1 改成 JDR0/JDR1、把文件尾部的“UPX!”魔数改成“JDR!”，使 upx -d 和 PEiD 一类工具直接报“modified/hacked”而拒绝处理，从而对抗自动化脱壳和特征识别；此外，样本用 VB6 编译为 P-code，入口是 MSVBVM60 的 thunk，反编译效果差、可读性低；关键字符串以 Unicode 存放，ASCII 方式的 strings 提取不到完整内容，需要专门用 -el 或反汇编器查看。这些手段都只是提高分析成本，并不能真正阻止脱壳与字符串提取。

问题五：对这个恶意代码样本进行分类（病毒、蠕虫等），并给出你的理由。

回答五：属于后门/远程控制木马（Backdoor / RAT），并带有僵尸程序（Bot）的 DDoS 能力。理由：它不具备自我复制和主动传播能力，需要诱导用户执行；进入主机后主要行为是建立隐藏的持久化通道（自启动、固定目录、HTTP 回连），等待攻击者下发指令，符合后门的定义；同时它内置 Smurf DDoS 模块并可接收命令，因此也可看作可被纳入僵尸网络的 bot。

问题六：给出过去已有的具有相似功能的其他工具。

回答六：国内的灰鸽子（Gpigeon）、国外的 SubSeven、Back Orifice、PoisonIvy、DarkComet、njRAT 等远程控制木马；此外 msfvenom 生成的 meterpreter 反向 shell、Cobalt Strike 的 Beacon 也能提供类似的后门与远程控制能力。

问题七：可能调查出这个二进制文件的开发作者吗？如果可以，在什么样的环境和什么样的限定条件下？

回答七：可以。该样本在代码中保留了明文的版权信息“(c) Raul Siles && David Perez”与创作时间“SotM 32 - September 2004”，脱壳后用 strings 或反汇编器即可读到。能够调查出作者的前提是：作者在编译时留下了可读的标识；样本虽然加壳但可以脱壳；分析者具备脱壳工具与反汇编工具，并且知道要同时检查 ASCII 与 Unicode 字符串。需要说明的是，这类字符串可以被伪造或删除，因此它只能作为归因的线索，不能作为唯一证据。

问题八：给出至少 5 种检测该恶意软件的方法，例如基于特征码的方法，需要详细介绍每种方法。

回答八：

方法一，基于特征码的检测。提取样本的 MD5/SHA1、节名组合（JDR0/JDR1）、字符串“RaDa_commands.html”“http://10.10.10.10/RaDa”、以及“JDR!”魔数，写入杀毒软件病毒库或 YARA 规则，扫描时逐一比对。优点是速度快、资源占用低、对已知样本几乎无误报；缺点是对加壳变形、修改字符串的变种无效，本例中攻击者仅仅改了节名和魔数就足以绕过只认“UPX!”的规则，因此特征应覆盖多个维度。

方法二，基于启发式的检测。不依赖具体特征，而是按行为规则打分：程序是否在 C:\ 根目录下创建工作目录、是否写 Run 注册表键、是否把自身复制到隐藏目录、是否在字符串中出现 http 地址与 cgi 路径、导入表是否只有 MSVBVM60 这类“异常干净”的组合。得分超过阈值即判定可疑。优点是能发现未知变种，缺点是误报率较高，需要结合白名单调参。

方法三，沙箱动态检测。把样本放进隔离的虚拟机运行，监控其进程、文件、注册表和网络行为。RaDa 运行后会创建 C:\RaDa\tmp、C:\RaDa\bin，写 HKLM\...\CurrentVersion\Run，并向 10.10.10.10 发起 HTTP 请求，这些行为链在沙箱报告中一目了然。优点是能看到完整行为、准确率高；缺点是资源消耗大、速度慢，且高级恶意代码会检测沙箱环境而选择不发作。

方法四，基于网络流量的检测。在网关或 IDS 上匹配 HTTP 请求中的“/RaDa”“RaDa_commands.html”“cgi-bin/download.cgi”“upload.cgi”等 URI，或对目的地址 10.10.10.10 的周期性 HTTP 连接告警；也可以在 DNS/代理日志中检索异常外联。优点是加壳与否都能检测，能发现已经落地的样本；缺点是遇到加密通道或域名 fast-flux 时效果下降。

方法五，基于主机日志与取证的检测。检查注册表 Run 键中是否有指向 C:\RaDa\bin\RaDa.exe 的启动项、C:\RaDa 目录是否存在、系统盘是否有异常副本；结合 Windows 事件日志、Sysmon 的进程创建与网络连接事件回溯。优点是可用于事后取证和失陷确认；缺点是要求日志完整，攻击者常会清除日志。

方法六，内存取证。对可疑主机抓取内存镜像，在进程列表中查找由 explorer.exe 启动、名为 RaDa.exe 的进程，dump 其内存并搜索“RaDa_commands.html”“Command_install”等字符串。优点是不受磁盘上文件被删除的影响；缺点是需要专业工具和较高的分析成本。

3.9 取证分析实践

数据源为 botnet_pcap_file.dat。先用 capinfos 查看整体情况：文件为 libpcap 格式、Ethernet 封装，共 54536 个数据包、约 18 MB，抓包时间从 2003-03-01 04:08:09 到 2003-03-06 03:27:57，持续约 429588 秒（约 5 天），与“蜜罐主机五天的网络数据”相符。

图23 capinfos 查看抓包文件基本信息

协议层次统计显示，54536 个包中 TCP 占 54350 个、17197075 字节（约 99.7%），UDP 仅 186 个、49962 字节（约 0.3%）；TCP 之上主要是 SMB/NBSS（2590 个）、HTTP（1443 个）和 IRC 流量，UDP 之上是 NBNS（129 个）。

图24 协议层次统计

3.9.1 问题回答

问题（1）：IRC 是什么？当 IRC 客户端申请加入一个 IRC 网络时将发送哪个消息？IRC 一般使用哪些 TCP 端口？

回答：IRC（Internet Relay Chat）是一种基于文本的实时聊天协议，采用客户端—服务器模型，支持多用户、多频道交流。客户端注册加入网络时需要发送 PASS（可选的口令）、NICK（昵称）、USER（用户信息）组合消息，服务器确认后返回 001 等欢迎码，之后客户端用 JOIN 加入频道。IRC 默认使用 TCP 6667 端口（明文），加密版本通常使用 6697 端口，另有 6660-6669、7000 等备用端口。

问题（2）：僵尸网络是什么？僵尸网络通常用于什么？

回答：僵尸网络（Botnet）是攻击者通过 C&C 服务器集中控制的大量被感染主机（肉鸡）组成的网络，被控主机上运行僵尸程序，定期回连并等待指令。它常被用于发动 DDoS 攻击、发送垃圾邮件与钓鱼邮件、作为跳板隐藏真实身份、窃取数据与挖矿等；本例中蜜罐主机被攻陷后加入的正是以 IRC 为控制信道的僵尸网络。

问题（3）：蜜罐主机（172.16.134.191）与哪些 IRC 服务器进行了通信？

回答：在 tshark 中过滤“源地址为 172.16.134.191、目的端口为 6667、SYN=1 且 ACK=0”的建连请求，统计目的地址并去重，得到 5 台 IRC 服务器：209.126.161.29（9 次）、66.33.65.58（9 次）、209.196.44.172（1 次）、217.199.175.10（1 次）、63.241.174.144（1 次）。

图25 统计蜜罐主机连接的 IRC 服务器

问题（4）：在这段观察期间，多少不同的主机访问了以 209.196.44.172 为服务器的僵尸网络？

回答：用三种方法估算，结果不同：

方法一，利用 IRC 服务器广播的当前全局用户数。用 tcpflow 还原与 209.196.44.172:6667 的会话，在服务器返回的 266 消息中读到“Current global users: 4752 Max: 4765”，即可认为该服务器上同时在线约 4752 个客户端。

图26 从 266 消息中读取 current_global_users

方法二，统计 JOIN/QUIT 中出现过的主机。用 tcpflow 把会话落成文本文件，按“@主机名”截取 JOIN 与 QUIT 记录中的主机并去重合并，共得到 5582 台主机。

图27 tcpflow 还原 209.196.44.172 的 IRC 会话

图28 统计 JOIN/QUIT 中出现的不同主机数

方法三，统计频道成员名单中的昵称数。对服务器 353 回复中的昵称列表去重计数，得到 3461 个不同昵称。

三种结果分别反映“当前在线数”“观察期内出现过的主机数”“名单中出现的昵称数”。我认为 4752 更接近僵尸网络在该时刻的规模：current_global_users 是服务器维护的状态计数，相对准确；JOIN/QUIT 统计会把观察期内进出的主机累加，数值偏大；昵称统计则会漏掉未加入频道的主机、并把改昵称的主机重复计算，数值偏小。因此取约 4752 台。

问题（5）：哪些 IP 地址被用于攻击蜜罐主机？

回答：用 tcpdump 读取抓包，筛选目的地址为 172.16.134.191 的数据包，取源地址、去掉端口后排序去重并计数，得到 165 个不同的攻击源 IP（完整列表另存为文件）。

图29 统计攻击蜜罐主机的源 IP 数量

问题（6）：攻击者尝试攻击了哪些安全漏洞？

回答：结合端口分布与协议内容，主要有：

① UDP 137（NetBIOS 名称服务）查点：65 个请求、64 个响应，均为 NBSTAT *<00> 查询，用于获取主机名、工作组和 MAC 地址；

② UDP 1434（SQL Server 解析服务）SQL Slammer 蠕虫：55 个数据包，UDP 长度均为 384 字节（净荷 376 字节），报文内含 Slammer 的特征代码，属于蠕虫自动扫描传播；

③ UDP 28431：2 个外部 IP 以固定源端口 28432 访问，包长 60 字节，属于历史上出现过的端口扫描模式；

④ TCP 80：Code Red 蠕虫与 Web 探测，24.197.194.106 发送大量 /null.ida、/NULL.ida?AAAA… 请求，218.25.147.83 发送 /default.ida?NNNN… 请求；同时存在对 /iissamples、/_vti_bin、/scripts/root.exe 等 IIS/FrontPage 敏感路径的探测；

⑤ TCP 139/445：SMB 查点与枚举，65 个 IP 访问 139，8 个 IP 访问 445，通过空会话连接 IPC$、访问 \samr 管道枚举用户、访问 \srvsvc 枚举共享，并对 Administrator、Guest、IUSR_PC0191、IWAM_PC0191、TsInternetUser 等账户做口令猜测；

⑥ TCP 25/135/4899：对 SMTP、RPC、Radmin 端口的连接探测，其中 4899 上存在持续的远程控制通信；

⑦ 弱口令与远程服务安装：攻击者用 Administrator 账户登录成功后，通过 SMB 上传可执行文件并注册系统服务。

图30 蜜罐主机出站连接的目的端口与入站 UDP 端口

图31 NBNS 请求/响应数量

图32 UDP 1434 报文长度统计（Slammer 特征）

图33 Code Red 的 .ida 请求与来源

图34 SAMR/SVCCTL 枚举流量统计

问题（7）：哪些攻击成功了？是如何成功的？

回答：从会话内容看，至少有以下几起攻击得手：

① 80 端口的红色代码（Code Red）探测没有成功。虽然出现了典型的 /null.ida、/default.ida 溢出请求，但蜜罐没有返回相应页面，攻击者拿不到 shell，属于扫描/探测性质；

② 1434 端口的 SQL Slammer 没有感染成功。蜜罐只收到外部发来的 Slammer 报文，没有出现蜜罐向外发送 1434 流量的行为，说明主机未打补丁但也未被成功执行；

③ 137/139 端口的查点获得了信息：攻击者通过 NBSTAT 拿到主机名 PC0191、工作组 SBM 和 MAC 地址，通过 SMB 空会话枚举出 5 个账户及其描述，为后续爆破提供了用户名；

④ 445 端口的弱口令爆破最终成功。210.22.204.101 对 Administrator 进行了 23 次认证尝试，状态码最终变为 0x00000000（成功），随后在会话中上传了 r_server.exe（Radmin 服务端）、raddrv.dll、admdll.dll 并尝试注册服务；此后该 IP 与蜜罐在 4899 端口上有 490 个报文交互，说明 Radmin 远程控制通道被建立；

⑤ 61.111.101.78 通过 SMB 上传了 PSEXESVC.EXE，并用 svcctl 的 CreateServiceA（opnum 24）注册服务、启动服务，抓包中能看到“PSEXESVC”字样和完整的服务创建参数，服务名、二进制路径、启动类型一应俱全，响应状态为成功，属于典型的 PsExec 横向移动；

⑥ 66.139.10.15、209.45.125.69 等 IP 也做了账户枚举与口令猜测，但认证结果均为失败，属于未遂攻击。

图35 PSEXESVC 服务创建与 4899 端口通信统计

4.问题及解决方案

问题1：实验材料中没有随附 RaDa 样本与抓包文件，虚拟机里也没有现成文件，无法直接开始分析。

解决方案：根据实验要求中的样本特征（SotM32、UPX 加壳）在 Honeynet 官方站点找到 Scan of the Month 32 的 RaDa.zip 与 Scan of the Month 27 的抓包，下载后校验 MD5：RaDa.exe 为 caaa6985a43225a0b3add54f44a0d4c7，与实验报告要求完全一致，说明拿到的是同一份样本；抓包文件解压后重命名为 botnet_pcap_file.dat，共 54536 个包、时间跨度 5 天，与题目描述吻合。

问题2：直接用 upx -d 脱壳失败，提示“file is modified/hacked/protected”。

解决方案：先用 objdump -h 和 strings 对比，发现节名是 JDR0/JDR1、魔数是 JDR!，判断是改过的 UPX 壳。编写 Python 脚本解析 PE 节表，把节名改回 UPX0/UPX1、把 JDR! 改回 UPX!，再执行 upx -d 就成功了。这个过程也说明：只改壳的特征串就能骗过一部分自动化工具，检测规则不能只依赖单一特征。

问题3：crackme2 改名后仍然得不到成功信息。

解决方案：阅读反编译代码发现它比较的是完整的 argv[0]。在 Linux 下用 wine 运行时，./crackmeplease.exe 会把“./”带进 argv[0]，直接 wine crackmeplease.exe 传入的又是完整路径，因此都失败；改用 wine cmd /c crackmeplease.exe 让 cmd 以文件名调用，argv[0] 才是“crackmeplease.exe”，校验通过。这与在 Windows 上“要在 cmd 而不是 PowerShell 里运行”的经验是同一个原因。

问题4：本机没有 IDA Pro 与 PEiD，无法按教材的方式做图形化反汇编。

解决方案：在 Kali 中安装开源的 Ghidra 12.1.4 作为替代。Ghidra 同样提供反汇编、反编译、交叉引用和字符串窗口，功能上足以完成 crackme 与 RaDa 的分析；加壳识别则改用 objdump 查看节表加 strings 提取特征串，效果与 PEiD 一致。

问题5：统计“访问僵尸网络的主机数”时，最初按 JOIN 记录统计得到的结果与预期不符。

解决方案：检查发现抓包里同时存在两个方向的会话文件，JOIN 与 QUIT 记录分散在服务器到客户端、客户端到服务器两个文件中，且部分记录带控制字符。改为对全部会话文件统一用 grep -a 提取 JOIN/QUIT、按“@”截取主机名、tr 删除控制字符后排序去重，才得到稳定的 5582 台；同时也说明单一指标（在线数、JOIN 数、昵称数）各有偏差，需要交叉验证。

5.学习感悟、思考等

这次实验把“恶意代码分析”从概念变成了手上的一套流程：先用 file、md5sum 给样本“验明正身”，再看节表和字符串判断有没有加壳，然后脱壳、提字符串、进反汇编器找关键逻辑，最后回到网络流量里验证样本的实际行为。整个链条走下来，我对“静态分析看意图、动态与流量分析看行为”这句话有了更具体的理解。

印象最深的是脱壳这一环节。原以为 upx -d 一条命令就能解决，结果被“modified/hacked”挡了回来。把节名和魔数改回去之后立刻成功，这件事让我意识到，很多所谓的“反分析技术”并没有想象中高深，它们利用的往往是工具对特征的依赖；反过来，做检测时如果规则也只盯着一个特征，就很容易被同样的手法绕过。

另一个体会是工具不是目的。本机没有 IDA Pro，用 Ghidra 一样完成了反编译；没有 PEiD，用 objdump 加 strings 也能判断壳的类型。真正重要的是知道“要找什么”：找入口点附近的解压存根、找字符串的交叉引用、找参数比较的分支。工具只是把这些线索呈现出来。

取证分析部分让我第一次完整地看了一次真实的入侵过程：扫描、查点、爆破、上传、注册服务，每一步在流量里都有痕迹。特别是把 SAMR 枚举出的用户名和后面的口令爆破、PsExec 上传服务串起来之后，攻击链就变得非常清晰。这也让我理解了蜜罐的价值——它记录的不是“可能被攻击”，而是“确实被怎样攻击”。

当然，本次实验也有不足：受环境限制，样本和抓包是从公开渠道获取的，crackme 也只做了静态分析和 wine 下的运行验证，没有做真正的动态调试；RaDa 是 VB6 的 P-code 程序，Ghidra 的反编译结果可读性有限，对其命令分发逻辑的分析还不够深入。