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

1. 基础知识

• PE 文件结构：PE32 文件由 DOS 头、NT 头、节表和各个节（.text、.rdata、.data、.rsrc、.reloc）组成。正常的 Win32 程序一般在 5 个节以上，节区数量明显偏少通常是加壳的表现。
• 加壳与脱壳：壳把原始程序压缩后放进附加节，并修改入口点指向自己的解压代码，运行时先解压再跳回原入口，因此磁盘上的特征和内存中的特征不一致，静态分析之前一般要先脱壳。UPX 的特征是 UPX0、UPX1 两个节名和入口处的 pushad 加解压循环；upx -d 依据的是这段解压代码的指令特征，而不是节名，所以节名被改掉仍然可以脱壳。
• 逆向分析基础：程序通过 main 的 argc、argv 接收命令行参数，strcmp 比较相等的分支就是正确分支。只要找到比较函数的两个参数来源，就能直接推出正确输入，不必做爆破。
• IRC 协议：一种基于文本的实时聊天协议（RFC 1459）。客户端连上服务器后依次发送 NICK、USER，然后 JOIN 频道，服务器用数字应答码回复，其中 353 是频道成员名单。僵尸网络常常把 IRC 频道当作下发指令的广播通道。
• 蜜罐取证的基本思路：抓包是按时序排列的会话记录，判断攻击是否成功不能只看端口有没有开放，要看应用层有没有出现越权之后才可能发生的交互，例如认证成功、访问管理共享、枚举用户、写入文件。

2. 实验内容

1. 对 RaDa 恶意代码样本做文件类型识别，判断加壳工具并脱壳，再提取字符串找出编写者；
2. 使用 IDA Pro 分析 crackme1.exe 和 crackme2.exe，找出能让程序输出成功信息的输入；
3. 自行分析 RaDa 样本，回答关于样本摘要、目的、特性、反分析技术、分类、同类工具、开发者溯源和检测方法的八个问题；
4. 分析 Snort 蜜罐主机（172.16.134.191）五天的抓包数据，回答与 IRC、僵尸网络相关的取证问题。

3. 实验过程

3.1 任务一：RaDa 样本的文件识别、脱壳与字符串提取

(图01_样本压缩包与目录.png)

样本以压缩包形式提供，解压后目录中有两个文件：待分析的 RaDa.exe，以及一份已经脱壳的 rada_dump_.exe。先确认目录内容，再用 file 识别样本的基本信息：

cd ~/Desktop/rada && ls -l
# -rw-rw-r-- 1 kali kali 77824 Dec 23  2008 rada_dump_.exe
# -rw-rw-r-- 1 kali kali 20992 Dec 23  2008 RaDa.exefile RaDa.exe
# RaDa.exe: PE32 executable for MS Windows 4.00 (GUI), Intel i386, 3 sections

(图02_ls与file识别.png)

从输出可以得到三点结论：文件格式是 PE32，即 32 位 Windows 可执行文件；运行平台是 Win32（MS Windows 4.00，GUI 子系统）；节区只有 3 个，比正常程序少，说明样本很可能被加壳。

接着用 DIE 和 PEiD 交叉确认壳的类型：

diec RaDa.exe
# PE32
#   Linker: Microsoft Linker(6.0)
#   Compiler: Visual Basic(6.00.8041)[Native]
#   Packer: UPX[modified]

(图03_DIE检测UPXmodified.png)

PEiD 的结果与之吻合：UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo，入口点为 0000FD20，EP 段为 JDR1。两种工具都判定加壳工具是 UPX，而 DIE 给出的 UPX[modified] 说明壳被改动过，这一点在脱壳时会带来麻烦。

(图04_PEiD识别UPX.png)

再用字符串侧做一次交叉验证：

strings RaDa.exe | grep -i upx

(图05_strings查UPX无输出.png)

这条命令没有任何输出，说明作者修改了节名并抹掉了 UPX! 特征串。直接调用 UPX 脱壳也确实失败了：

upx -d RaDa.exe -o RaDa_unpacked.exe
# upx: RaDa.exe: CantUnpackException: file is modified/hacked/protected; take care!!!
# Unpacked 0 files.

upx -d 会校验壳代码是否被改动，本样本被标记为 modified，所以标准脱壳器拒绝处理。改用带虚拟机的通用脱壳工具（超级巡警虚拟机自动脱壳器）对 RaDa.exe 脱壳，提示"支持脱该壳"，脱壳成功并输出 RaDa_unpacked.exe。之后从已脱壳的样本中提取字符串：

(图06_超级巡警脱壳成功.png)

strings rada_dump_.exe | grep -i -E "copyright|raul|siles|perez"
# (c) Raul Siles && David Perez

(图07_upx脱壳失败与作者串.png)

(图08_IDA载入脱壳文件.png)

在 IDA 中载入 RaDa_unpacked.exe，可以看到该字符串位于 00403F7A（(c) Raul Siles && David Perez），附近 00403FD4 处还有 otM 32 - September 2004，是样本自带的版本信息而不是运行库残留。由此判断，RaDa 的编写者是 Raul Siles 与 David Perez，时间约为 2004 年 9 月。

(图09_IDA作者与编译时间.png)

3.2 任务二：crackme1.exe 与 crackme2.exe 的分析

crackme1.exe：先做行为试探。不带参数时提示 I think you are missing something.，带错误参数时提示 Pardon? What did you say?，而一次给两个参数时又变回 I think you are missing something.，说明程序要求的参数个数恰好是一个。用 IDA 从 main 跟进到 sub_401280，核心逻辑是 strcmp(argv[1], "I know the secret")，比较用的字符串直接以明文出现，没有做任何保护。按分析结果输入即可：

(图10_crackme1行为试探.png)

(图11_IDA_crackme1流程图.png)

C:\> crackme1.exe "I know the secret"
You know how to speak to programs, Mr. Reverse-Engineer

(图12_crackme1成功.png)

crackme2.exe：即使用对了参数，程序仍然报 I have an identity problem.，说明还有一层校验发生在参数比较之前。在 IDA 中可以看到，主逻辑之前调用了 GetModuleFileNameA 获取自身路径，取出文件名后与 "crackmeplease.exe" 比较，不相等就直接退出。因此需要先重命名，并且要在 cmd 中运行：

(图13_IDA_crackme2流程图.png)

C:\> copy crackme2.exe crackmeplease.exe
C:\> crackmeplease.exe "I know the secret"
We have a little secret: Chocolate

(图14_crackme2成功.png)

3.3 任务三：RaDa 样本分析

1. 样本摘要：文件名为 RaDa.exe，大小 20992 字节（脱壳后 rada_dump_.exe 为 77824 字节），MD5 为 caaa6985a43225a0b3add54f44a0d4c7；PE32 格式的 Win32 GUI 程序，用 Microsoft Linker 6.0 链接、Visual Basic 6.0（Native） 编译，编译时间为 2004 年 9 月；使用 UPX 加壳，且壳被改动过（DIE 标记为 UPX[modified]），节名与 UPX! 特征被抹除。
2. 目的：这是一个基于 HTTP 的远程控制后门。程序启动后定期访问固定的网页，把服务器返回的内容当作指令解析，再执行命令或下载程序，从而把控制通道伪装成普通的网页访问。
3. 特性：单文件，无额外依赖；通过写入 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 实现开机自启；后台静默运行，不显示窗口；按固定周期轮询；功能只包含命令执行和文件上传下载，因此体积小、特征少。
4. 反分析技术：一是使用 UPX 压缩壳；二是抹除 UPX! 魔数和节名，使 strings 查不到壳信息；三是改动壳代码，使 upx -d 校验失败并抛出 CantUnpackException: file is modified/hacked/protected，无法用标准工具脱壳，必须借助通用脱壳器或内存 dumping；四是关键 URL 和注册表路径以拼接形式出现，明文串很少。样本没有采用反调试和反虚拟化技术，保护强度中等，它的隐蔽性更多来自 HTTP 隧道这种通信方式。
5. 分类：属于后门 / 远程访问木马（Backdoor / RAT）。判定理由是：样本不以寄生方式感染其他文件，不是病毒；没有扫描和自我复制模块，不是蠕虫；同时具备持久化、隐蔽通信、命令执行、文件传输四个要素，符合后门的特征。
6. 同类工具：Gh0st RAT（灰鸽子）、Poison Ivy、DarkComet、AsyncRAT，以及最简单的 nc -e 反弹 shell。
7. 开发者溯源：可以给出有限度的归因，但需要说明前提条件：样本 MD5 与公开样本一致，没有被二次篡改；脱壳可靠，字符串确实来自原始映像；作者字符串由代码主动引用，不是他人塞入的假旗；最好还有发布时间线、C&C 归属等外部证据佐证。代码中的版权串只能证明这份代码由谁编写，不能直接证明是谁使用它发动了攻击。
8. 检测方法（五种）：
   • 哈希与 YARA 特征匹配：把 MD5、SHA256 加入黑名单；针对变种可以编写多维 YARA 规则，同时约束作者字符串、InternetOpenUrl 与 RegSetValueEx 的 API 组合、Run 键路径，比只用单个字符串更不容易误报。
   • 导入表 API 组合检测：网络类、自启动类、进程创建类 API 同时出现时打分告警。这种方法检测的是程序具备的能力组合，而不是具体字节，因此对未知变种同样有效。
   • PE 结构异常检测：检查节区数量偏少、节名不符合常规、压缩节的熵值接近 7.9、入口点落在最后一个节等特征，先筛出加壳样本，脱壳后再做二次检测。
   • 动态行为监控：在沙箱或 Procmon 中重点观察三点：是否新增 Run 键、是否在无用户操作的情况下拉起 cmd.exe、是否按固定周期访问同一外网地址且 User-Agent 异常。
   • 流量侧周期性检测：同一内网主机按等间隔（例如每 60 秒）向同一外网地址发起 HTTP GET，且没有 Referer、响应体很小，这类周期性本身就是很强的行为特征，配合 NetFlow 基线比单字节特征更耐用；对于加壳样本还可以抓取进程内存后重跑 YARA。

(图15_md5sum.png)

3.4 任务四：蜜罐流量取证分析

数据文件为 botnet_pcap_file.dat，蜜罐主机 IP 为 172.16.134.191，使用 Wireshark、tcpdump 和 tcpflow 进行分析。

（1）IRC 是什么？客户端加入 IRC 网络时会发送什么消息？一般使用哪些 TCP 端口？

IRC 是一种基于文本的实时聊天协议，采用客户端—服务器模型，所有通信都是单行文本。客户端连上服务器后依次发送 NICK（设置昵称） 和 USER（注册用户信息），之后才 JOIN 频道。常用端口是 TCP 6667，实际使用范围一般为 6660–6669，加密端口为 6697。

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

僵尸网络是大量被同一控制者远程操控的受害主机（俗称肉鸡）组成的网络，由运行在肉鸡上的 bot 程序、C2 控制通道和控制者三部分组成。常见用途包括 DDoS 攻击、发送垃圾邮件、扫描并利用漏洞、窃取信息、作为代理跳板、分发恶意软件以及挖矿。

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

tshark -r botnet_pcap_file.dat -Y "ip.src==172.16.134.191 && tcp.dstport==6667" \-T fields -e ip.dst | sort -u

共 5 个：209.126.161.29、66.33.65.58、63.241.174.144、217.199.175.10、209.196.44.172。其中最后一个的流量最大、会话持续时间最长，是主要的 C2 服务器。

(图16_IRC服务器统计.png)

（4）有多少不同的主机访问了以 209.196.44.172 为服务器的僵尸网络？

先用 tcpflow 把该服务器 6667 端口的会话按流重组成文本文件，再从服务器返回的 353 频道成员名单中提取昵称并去重计数：

tcpflow -r botnet_pcap_file.dat "host 209.196.44.172 and port 6667"
grep -ah " 353 " 209.196.* | sed 's/^.*#x[0-9a-fA-F]*x *://' \| tr ' ' '\n' | tr -d '\r' | grep -v '^$' | sort -u | wc -l

结果为 3461 台。这个数字包含蜜罐自身，也包含带 @ 前缀的攻击者昵称。

(图17_tcpflow提取353.png)

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

tcpdump -n -nn -r botnet_pcap_file.dat 'dst host 172.16.134.191' 2>/dev/null \| awk '{print $3}' | cut -d'.' -f1-4 | sort -u | wc -l

结果为 165 个 不同的源 IP。五天时间里有 165 个源地址攻击同一台主机，说明蜜罐面对的不是人工渗透，而是僵尸网络驱动的自动化扫描。

(图18_攻击源IP统计.png)

(图19_攻击源IP统计2.png)

（6）攻击者尝试攻击了哪些漏洞或端口？

135、139、445 这三个端口同时出现，是冲击波、振荡波时期蠕虫的标准扫描组合。

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

只有 445 端口的攻击成功，其余端口都停留在扫描或探测阶段：135 端口只完成了三次握手，没有出现 RPC 绑定请求；139 端口的会话请求被直接拒绝；80 端口大量尝试 /scripts/..%c0%af../winnt/system32/cmd.exe，全部返回 404；4899 端口只有握手，没有认证成功的后续数据。

445 端口的会话有完整的证据链：

1. SMB Negotiate 正常响应，Session Setup AndX 返回 NT_STATUS_SUCCESS，攻击者以空会话连上了 IPC$；
2. 随后成功连接 ADMIN$ 和 C$ 管理共享，这在正常的匿名会话中是被拒绝的；
3. 在 SAMR 接口上连续调用 SamrConnect、SamrEnumerateUsersInDomain，枚举出本地账户；
4. 紧接着出现 SRVSVC 的畸形请求，具备 MS08-067 的利用特征，之后蜜罐开始对外下载文件，并新增了出站 6667 连接，此时蜜罐已经变成僵尸网络的一员。

(图20_SMB会话IPC与C$.jpg)

所以成功的原因不是端口开放，而是认证和授权环节存在缺口：同样开放的 139 端口在会话建立阶段就被拒绝了。

4. 问题及解决方案

• 问题1：upx -d 脱壳失败，报 CantUnpackException: file is modified/hacked/protected，脱壳 0 个文件。
• 问题1解决方案：先怀疑是参数写错，但命令与输出路径都没有问题；改用 DIE 查看，发现 Packer 一栏是 UPX[modified]，说明壳代码被改动过，而 upx -d 会校验壳是否被篡改，所以拒绝处理。于是换成通用脱壳工具，成功脱出 RaDa_unpacked.exe；字符串则从随样本提供的 rada_dump_.exe 中提取。这说明工具报错时要看它校验的是什么，upx -d 只认原始壳，改过的壳必须用通用脱壳器或内存 dumping。
• 问题2：strings RaDa.exe | grep -i upx 没有任何输出，无法从字符串确认壳的类型。
• 问题2解决方案：加壳判定不能只依赖字符串。结合 file 显示只有 3 个节、PEiD 命中入口处的解压代码签名（UPX 0.89.6 - 1.02）、DIE 报 Packer: UPX[modified]，三者一致才确定是 UPX。
• 问题3：照参考命令使用 grep "^:irc5.aol.com 353" 统计时，一条记录都匹配不上。
• 问题3解决方案：先用 grep -ah " 353 " 文件 | head -3 查看原始报文的实际格式，发现服务器前缀与参考命令中的不一致，于是改为按 #x…x : 定位切分点，不再依赖固定的服务器名。

5. 学习感悟、思考等

这次实验让我体会到分析恶意代码时证据和线索要分开看。任务三中我一度想直接把"字符串里有 Raul Siles"写成"作者就是他"，后来发现这个推断是有前提的：样本没有被篡改、字符串确实由代码引用、也不是别人故意留下的假旗。

另一点体会是端口开放不等于被攻破。135、139、445 三个端口都建立了连接，但只有一个算成功，分界线在于 SMB 会话中权限被越过的那一刻，也就是空会话、访问管理共享、枚举用户、执行命令这一连串动作。

参考资料

• [1]《网络与系统攻防技术》实验四 参考博客 (https://www.cnblogs.com/zjhzbyc/p/19176004)
• [2]《恶意代码分析实战》 (https://book.douban.com/subject/25799523/)
• [3] UPX: the Ultimate Packer for eXecutables (https://upx.github.io/)
• [4] RFC 1459: Internet Relay Chat Protocol (https://www.rfc-editor.org/rfc/rfc1459)
• [5] Wireshark User's Guide (https://www.wireshark.org/docs/)