20253913 2025-2026-2 《网络攻防实践》第八周作业

《网络攻防实践》第八次作业报告

一、实践内容

1.1 恶意代码静态分析与脱壳分析思路

本次作业中的 rada 样本处理，核心不在于直接运行程序，而在于通过静态分析与有限度的动态观察，逐步还原样本的基本属性、加壳情况、关键字符串和行为意图。面对可疑可执行文件，通常先通过 file、PE 识别工具等确定其文件格式、目标平台和体系结构，再结合字符串提取判断是否存在明显的网络地址、注册表路径、函数名或作者信息。如果原始样本字符串杂乱、信息缺失，则往往意味着样本经过压缩壳或简单保护处理，此时需要进一步借助 PEiD 等工具识别壳类型，再通过脱壳工具得到更便于分析的版本。

脱壳并不等于分析结束。对于经过脱壳的样本，仍需继续通过字符串窗口、导入函数、关键资源和反汇编结果判断其真实目的。本次实验中，rada 样本的分析路径体现了一个较为典型的恶意代码分析流程，即“文件识别—加壳判断—脱壳—字符串提取—反汇编辅助验证—行为归纳”。这一流程适用于许多入门级恶意代码样本，也能够为后续的分类判断和作者归属分析提供证据基础。

1.2 Crackme 程序逆向分析思路

Crackme 程序分析的目标是通过逆向工程寻找能够触发成功输出的输入条件。与普通软件调试不同，Crackme 更强调通过程序内部逻辑理解“为什么这个输入有效”。在分析过程中，字符串窗口通常是重要入口，因为提示信息、错误回显、成功回显、比较字符串常常直接出现在可见字符串中。若字符串中同时出现失败提示和成功提示，便可以围绕这些字符串的交叉引用继续追踪对应函数。

在本次实验中，IDA Pro 的作用主要体现在两个方面：一是通过 String Window 快速定位关键提示语句，二是通过函数调用图和流程图追踪 printf、strcmp 等关键调用，进而明确程序在什么条件下进入成功分支。对于这类小型程序而言，逆向分析的重点并不在于复杂算法，而在于准确找出比较逻辑、参数位置和控制流跳转条件。本次对 crackme1.exe 与 crackme2.exe 的处理，分别展示了“直接字符串比较”和“文件名条件 + 参数比较”两类常见校验模式。

1.3 IRC 协议与僵尸网络控制机制

IRC 是一种基于文本指令的实时通信协议，在正常场景中用于多人聊天和频道交流；在恶意控制场景中，则常被用作早期僵尸网络的命令分发通道。受控主机在感染后，会主动连接指定 IRC 服务器，通过 NICK、USER 完成身份注册，再利用 JOIN 进入特定频道，从而接受控制端下发的指令。由于协议简单、实现成本低、可直接借助现成 IRC 服务器完成组织管理，IRC 在早期 botnet 中具有较强代表性。

本次流量分析的重点，并不是单纯确认某个主机是否访问了 6667 端口，而是判断它是否真正完成了 IRC 入网、加入频道并出现在异常控制通道中。若仅有 TCP 建连，不能直接说明已加入僵尸网络；只有当数据流中出现完整的 NICK、USER、欢迎消息以及后续的 JOIN、频道成员列表等内容时，才能形成较强的控制关系证据。

1.4 蜜罐日志分析与攻击溯源思路

蜜罐日志分析强调从网络证据中还原攻击链，而不是只看单个告警结论。面对一份持续数天的 pcap 日志，需要先识别日志文件格式、时间范围和链路层类型，再围绕目标主机构建分析主线。常见主线包括：对外通信行为、对内暴露端口、入站攻击来源、可疑应用层内容、成功控制证据以及入侵后的后续动作。

本次实验中，分析思路可以概括为“协议基础—对外控制通信—入站攻击梳理—漏洞利用判断—成功入侵举证—僵尸网络纳入确认”。其中，真正困难之处并不在于找出某个端口是否被访问，而在于区分“探测”“尝试利用”“存在可疑会话”和“已明确成功控制”这几种强度不同的结论。只有当共享访问、文件落地、服务创建、服务启动等证据链闭合时，才能将一次攻击明确认定为成功入侵。

二、实验过程

2.1 动手实践任务一：rada 恶意代码样本处理

2.1.1 实验目的

本节实验的目的是对提供的 rada 恶意代码样本进行基础识别、加壳判断、脱壳处理与字符串提取分析，并在此基础上尽可能还原样本的基本属性与作者信息。通过这一过程，可以建立对恶意样本静态分析流程的整体认识，同时为后续的综合分析部分奠定证据基础。

2.1.2 使用工具及作用

实验中主要使用了以下工具：

file 命令用于识别样本文件类型、体系结构和目标运行平台。
strings 用于提取样本中可直接见到的字符串。
PEiD 用于识别可执行文件是否加壳以及壳的类型。
超级巡警脱壳机用于对识别出的压缩壳进行脱壳处理。
IDA Pro Free 用于在脱壳后样本上进一步查看字符串、编码方式和反汇编信息。
样本自带的 rada --authors 与 RaDa.exe --authors 参数则用于直接读取样本中嵌入的作者相关信息。

2.1.3 文件格式识别与加壳判断

在 WinXP Attacker 虚拟机中，将解压后的 RaDa.exe 导入分析环境后，首先在命令行中执行：

file RaDa.exe

识别结果表明，该文件为 PE32 格式的 GUI 可执行文件，运行平台为 Intel 80386 架构下的 32 位 Windows。仅从文件类型看，它属于标准 Windows 可执行程序，没有使用非常规文件封装形式。

随后对原始样本执行：

strings RaDa.exe

可以看到输出内容较为杂乱，能够识别出少量 DLL 名称和函数信息，但整体上缺乏成体系的可读字符串。该现象说明样本中的可见字符串被明显压缩或扰乱，存在被加壳的可能性，因此需要进一步确认壳类型。

在WinXPattacker虚拟机中寻找PEid工具，用于查看RaDa.exe的加壳信息。在开始菜单->所有程序->PE->PEid->PEid_cn

打开PEid之后加载文件选择RaDa.exe

在 PEiD 中载入 RaDa.exe 后，可识别出样本使用的是 UPX 壳，识别信息为 UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo。这一结果解释了原始字符串提取效果较差的原因，也说明后续应以脱壳样本作为主要分析对象。

2.1.4 脱壳过程

确认样本经过 UPX 处理后，在 WinXP Attacker 环境中打开超级巡警脱壳工具（开始菜单->所有程序->脱壳和加壳工具），选择 RaDa.exe 进行脱壳。脱壳完成后，工具生成了新的脱壳文件 RaDa_unpacked.exe。

这一过程的意义在于将经壳压缩后的样本恢复为更接近真实执行逻辑的版本，使其中隐藏的字符串、路径、URL、注册表项和行为提示能够更加完整地暴露出来。对后续分析而言，脱壳后的样本比原始样本更适合进行字符串提取与反汇编查看。

2.1.5 字符串提取与作者信息确认

对脱壳后的文件执行：

strings RaDa_unpacked.exe

此时已经可以看到大量较原始样本更完整的函数与行为相关信息，但仍有部分内容不够直观。为此，进一步在 IDA Pro Free （开始菜单->所有程序->反汇编->IDA Pro Free）中打开 RaDa_unpacked.exe，进入字符串窗口查看样本中的可见字符串。

选择PE Exe对脱壳后文件RaDa_unpacked.exe进行反汇编分析

加载文件选择RaDa_unpacked.exe

打开之后：

初始情况下，字符串窗口中的内容与命令行 strings 输出较为接近；在字符串窗口中调整编码方式，切换到 Unicode 相关选项后，可见信息明显增多，包含了更多路径、注册表项和作者信息。

在Sting窗口单机右键 --> 选择Setup修改编码模式后进一步查看，选择Unicode改变编码格式，会发现内容发生变化：

找到作者信息，为Raul Siles & David Perez。

同时，实验中还直接执行了以下命令：

rada --authors
RaDa.exe --authors

两个命令均返回相同作者信息，表明样本中明确嵌入了作者署名。结合 IDA 字符串窗口中的内容，最终可以确认该样本作者为 Raul Siles & David Perez。

2.1.6 问题回答

本实践任务要求回答三个具体问题，结合上述过程可以形成如下结论。

第一，rada 恶意代码样本的文件格式为 PE32 GUI 可执行文件，目标运行平台为 Intel 80386 架构下的 32 位 Windows。通过 PEiD 识别可知，其使用的加壳工具为 UPX，识别结果为 UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus & Laszlo。

第二，对 rada 样本的脱壳过程是：先使用 PEiD 确认壳类型，再使用 WinXP Attacker 中自带的超级巡警脱壳工具加载 RaDa.exe 并执行脱壳，最终得到脱壳后的文件 RaDa_unpacked.exe。脱壳后重新执行字符串提取，并借助 IDA 进一步分析，可见信息显著增加。

第三，作者信息可通过两种方式确认。一种是直接执行 rada --authors 或 RaDa.exe --authors，样本会返回作者信息；另一种是对脱壳后的样本在 IDA 中查看字符串，特别是在调整编码方式后，可清楚看到作者署名。两种方法所得结果一致，均表明 rada 样本的编写作者为 Raul Siles & David Perez。

2.2 动手实践任务二：分析 Crackme 程序

2.2.1 分析目标与总体思路

本节实验要求在 WinXP Attacker 虚拟机中使用 IDA Pro 对 crackme1.exe 和 crackme2.exe 进行静态或动态分析，找出使程序输出成功信息的正确输入。分析的重点不在于暴力试探，而在于通过字符串提示、函数调用关系和比较逻辑找出程序的真实校验条件。

在实际操作中，先对样本使用 file 判断其格式，确认同样属于可由 IDA 分析的 PE 可执行文件。随后结合字符串窗口定位错误提示和成功提示，再围绕 printf、strcmp 以及对应调用函数进行反向追踪，最终锁定输入条件。

2.2.2 crackme1.exe 分析

对 crackme1.exe 执行 file 查看其类型后，可知该文件同样为 PE 可执行程序。若直接在命令行中随意传参，程序只会返回诸如 “I think you are missing something.” 或 “Pardon? What did you say?” 之类的提示，这说明仅靠试探较难直接得出正确口令。

用IDA打开，同样选择PE Exe新建一个分析界面。

在 IDA 中打开 crackme1.exe 后，进入 String Window，可以看到除了上述错误提示外，还存在两条极具指向性的字符串：一条是 "I know the secret"，另一条是 "You know how to speak to programs, Mr. Reverse-Engineer"。从逆向分析的角度看，前者很可能是待比较的目标输入，后者则很可能是比较成功后的回显信息。

点击打开IDA View窗口，在右上角菜单栏选择：view—>graphs—>function calls 查看函数调用图。

继续查看函数调用图后，可以发现 printf 的调用位于 sub_401280 中，而该函数还调用了 strcmp。这意味着程序通过字符串比较判断用户输入是否正确。

View->Graphs->Flow chart查看sub_401280块的汇编代码。

结合流程图中的分支逻辑可知，程序将用户传入参数与 "I know the secret" 进行比较，比较成功时进入成功分支，并打印成功提示信息。

因此，crackme1.exe 的正确输入为：

crackme1.exe "I know the secret"

在验证过程中，还需要注意引号必须使用英文引号。如果误用中文引号，命令行参数会被错误处理，程序不会返回预期结果。改为英文引号后，程序成功输出正确提示信息，验证完成。

2.2.3 crackme2.exe 分析

对该文件也进行IDA反汇编分析：

crackme2.exe 的分析方式与 crackme1.exe 大体一致，但其逻辑比前者多了一层限制。通过 IDA 查看字符串窗口，可以看到程序中仍然保留了 "I know the secret" 这一关键比较字符串，同时还能看到与文件名有关的内容。

进一步观察反汇编和流程图后可以发现，crackme2.exe 并不是只检查第二个参数是否为 "I know the secret"，它还会先检查程序自身的文件名是否为 "crackmeplease.exe"。只有在文件名与输入参数两个条件同时满足时，程序才会进入成功路径。

这意味着，crackme2.exe 的成功条件由两部分组成：其一，需要先把程序重命名为 crackmeplease.exe；其二，需要以 "I know the secret" 作为参数运行。对应的验证命令为：

rename crackme2.exe crackmeplease.exe
crackmeplease.exe "I know the secret"

完成验证后，程序成功给出正确信息，并输出隐藏结果。结合实验截图中的命令行输出，可以确认程序返回的隐藏内容为 “We have a little secret: Chocolate”，这表明两个条件均已满足，分析结果正确。

本节实验表明，逆向分析的关键在于把程序回显、字符串、比较函数和流程跳转关联起来：crackme1.exe 只要求输入正确口令，而 crackme2.exe 同时要求满足指定文件名和指定参数两个条件。

2.2.4 问题回答

对 Crackme 程序的分析结论如下。

对于 crackme1.exe，程序的正确输入为：

crackme1.exe "I know the secret"

之所以能够得出这一结论，是因为在字符串窗口中发现了 "I know the secret" 和成功提示语句，并在关键函数中确认程序通过 strcmp 将输入参数与该字符串直接比较。比较成功后，程序输出成功信息 "You know how to speak to programs, Mr. Reverse-Engineer"。

对于 crackme2.exe，程序的正确运行方式为：

rename crackme2.exe crackmeplease.exe
crackmeplease.exe "I know the secret"

该程序除了要求第二个参数为 "I know the secret" 外，还要求程序自身文件名必须为 crackmeplease.exe。因此，仅输入正确口令但不修改文件名，程序仍无法进入成功分支。完成重命名并再次运行后，程序成功输出隐藏内容 “We have a little secret: Chocolate”。

从逆向分析角度看，这两个样本分别体现了两类典型校验模式：crackme1.exe 是单一字符串比较，crackme2.exe 则在字符串比较之外增加了程序名校验。

2.3 分析实践任务一：rada 恶意代码样本综合分析

2.3.1 样本摘要与同源识别信息

从样本基础属性看，RaDa.exe 为 PE32 GUI 可执行文件，目标平台为 Intel 80386 架构的 32 位 Windows；样本大小约为 20.50KB，原始样本使用 UPX 壳进行压缩。为便于同一样本识别，上传微步平台中给出了多个摘要值，其中：

SHA256：13c2379e9d9f679396e21a3391804cc834892f25691381b6d078d07b56d38f90
MD5：caaa6985a43225a0b3add54f44a0d4c7
SHA1：4164423ece62c5c4c287f8c2003b84e4e3a6cfda

这组摘要值与文件名、文件类型、大小、壳信息共同构成了该样本的基本识别信息。实际分析中，只要文件摘要一致，基本可以判断是同一样本；即使摘要不同，只要功能字符串、作者信息、C2 地址与行为特征高度一致，也可用于同源样本比对。

整体对文件的静态分析其基础信息如下：

行为检测：

~~微步的给出的分析结果基本已经可以回答问题了，但是我们接下来还是自己来一遍吧🙃~~

使用以下命令进行MD5摘要的获取：

md5sum RaDa.exe

2.3.2 样本目的分析

打开虚拟机自带的Process Explorer软件(开始菜单->所有程序->监视工具)，进行脱壳后的RaDa.exe文件监听，即RaDa_unpacked.exe (先启动再监听)。

结合脱壳后的字符串、Process Explorer 监听信息和反汇编观察，可以判断 rada 样本的主要目的并不是单纯破坏文件，而是建立一个具有远程控制能力的后门执行环境。样本运行后会主动访问 http://10.10.10.10/RaDa 相关路径，从远程位置下载 RaDa_commands.html，并结合样本内部存在的 download.cgi、upload.cgi 等字符串，显示出其与外部控制端进行命令交互的能力。

此外，样本还会在本机创建目录并复制自身，修改注册表启动项，以便在系统重启后持续运行；在行为层面又具备针对内网地址段的传播或攻击意图，并能根据收到的指令发动 Smurf 类型的 DDoS 攻击。因此，该样本的核心目的可以概括为：在受害主机上建立持久化后门，主动连接控制端接收指令，并进一步执行传播、控制和拒绝服务攻击等恶意行为。

2.3.3 样本主要特性

综合已有分析结果，rada 样本至少具有以下几个方面的特性。

其一，具备明显的持久化能力。样本会在本地创建 C:\RaDa 目录，并将自身复制到 bin 子目录，同时通过 RegWrite、RegRead、RegDelete 等注册表相关操作修改启动项，从而实现开机自启。

其二，具备远程命令获取和控制能力。样本主动访问固定 URL，下载命令文件，并根据控制端返回内容实施后续操作，这一机制说明它并非离线破坏型程序，而是依赖外部控制端进行指令驱动。

其三，具备网络攻击与传播意图。样本内部出现了针对私有地址段 192.168、172.16、10 的相关字符串，这表明其会尝试在内网环境中继续传播恶意代码，或对这些地址段的主机发起攻击。同时，字符串中还出现 “Start DDoS Smurf remote attack” 之类的提示，说明其具备拒绝服务攻击功能。

其四，具备脚本化系统操作能力。样本中出现了 WScript.Shell、Scripting.FileSystemObject 等对象名称，这意味着它在系统操作层面具有较强的自动化控制能力，可执行文件复制、路径创建、注册表处理等操作。

2.3.4 防分析与逆向工程规避技术

该样本采用的防分析或规避技术并不复杂，但具备典型代表性。

最直接的一项技术是 UPX 加壳。在原始样本上执行 strings 时，输出内容明显紊乱，重要字符串难以直接提取；只有在识别壳类型并完成脱壳后，关键 URL、注册表路径、命令文件名和作者信息才变得清晰可见。这说明加壳已经在一定程度上提高了样本的初始分析门槛。

另一项值得注意的技术是 虚拟环境检测。脱壳后的字符串中出现了 HKLM\Software\VMware, Inc.\VMware Tools\InstallPath 相关内容，结合实验中的行为分析，可以判断样本会检查当前是否处于虚拟化环境。此类检测虽然不一定会彻底终止执行，但可以用于区分分析环境与真实受害环境，从而影响后续攻击行为。

此外，作者信息在普通字符串提取中并不总是直接可见，必须在 IDA 中切换字符串编码方式后才能更完整地观察到相关内容。这并不属于强对抗性的加密保护，但说明样本内部信息并非全部以最容易提取的形式呈现。

2.3.5 样本分类与理由

结合样本行为，应将 rada 归类为 后门木马类恶意代码，同时具有一定的 bot 控制特征。

之所以不宜将其简单归类为传统病毒，是因为现有分析并未显示它以感染其他宿主文件为核心传播方式；也不宜直接将其定性为典型蠕虫，因为实验中虽能看到它具有面向内网地址段的传播或攻击意图，但其核心工作模式仍然是“落地—持久化—外联控制端—根据命令执行任务”。

从样本的持久化、注册表启动项、远程命令获取、文件下载/上传、DDoS 指令执行等行为看，它更符合后门木马的特征；而从其可被远程统一控制、可参与批量攻击的能力来看，又具有 bot 程序的典型属性。因此，将其描述为“具备远程控制能力的后门木马”最为准确。

2.3.6 相似功能工具

从功能层面看，rada 与早期 Windows 平台上的远控木马和 bot 工具具有明显相似性。典型的可类比对象包括 Back Orifice、NetBus、Sub7 等早期远程控制工具，它们同样具备远程命令执行、持久化和受害主机控制能力。若从“远程命令接收 + 批量控制 + 攻击执行”这一点看，也可与早期 Agobot 一类具备集中控制与攻击执行能力的 bot 工具进行功能类比。

这里的“相似”主要指功能形态上的相近，而不是代码同源。换言之，它们都体现了早期恶意代码从单点破坏向“远程控制 + 任务化执行”演化的特征。

2.3.7 作者归属是否可调查

针对该样本，作者归属在“样本内嵌署名”层面是可以调查到的。实验中通过 rada --authors、RaDa.exe --authors 以及 IDA 字符串窗口，均能得到 Raul Siles & David Perez 的署名信息，而且样本内部还保留了相应的 URL 与版权相关文本。因此，在样本保持完整、未被再次打包篡改，且能够在隔离分析环境中完成脱壳和字符串提取的条件下，可以较稳定地恢复出这一作者信息。

不过，需要区分“样本中声明的作者”与“现实世界中具有法律意义的开发者身份”。前者可以通过样本自带信息加以确认；后者若要进一步落实，则还需要历史上下文、来源链、外部资料和其他佐证。就本次实验范围而言，可以确认的是样本所署名的开发作者，而不是进行更高强度的现实身份归因。

综上，rada 样本在技术形态上属于一类典型的早期后门木马：样本被 UPX 加壳，脱壳后可观察到持久化、虚拟环境检测、远程命令获取、私网目标处理和 DDoS 指令执行等行为；其作者信息在样本中保留较完整，能够在受控分析环境下被恢复出来。

2.3.8 问题回答

结合前述分析过程，可以对题目中的七个问题逐项作答。

1. 该二进制文件的摘要与样本识别信息

该样本文件名为 RaDa.exe，文件类型为 PE32 GUI 可执行文件，运行于 Intel 80386 架构的 32 位 Windows 平台，文件大小约 20.50KB。原始样本使用 UPX 壳压缩。实验中得到的关键摘要值为：SHA256 13c2379e9d9f679396e21a3391804cc834892f25691381b6d078d07b56d38f90，MD5 caaa6985a43225a0b3add54f44a0d4c7，SHA1 4164423ece62c5c4c287f8c2003b84e4e3a6cfda。这些信息足以用于识别同一样本或进行同源样本比对。

2. 该二进制文件的目的

从脱壳后的字符串、运行监听结果和行为线索来看，rada 的主要目的并不是单纯破坏文件，而是在受害主机上建立一个可持续运行的远程控制后门。样本会主动访问远程地址 http://10.10.10.10/RaDa，下载 RaDa_commands.html 等指令内容，并结合本地目录、注册表和脚本对象实现持久化与命令执行。与此同时，它还具备进一步传播和发动 DDoS 攻击的能力。因此，该样本的核心目标是建立后门控制环境，接受远程命令并执行后续攻击任务。

3. 该样本具有的不同特性

样本具备多种典型恶意代码特性。其一，具备持久化能力，会在本地创建 C:\RaDa 相关目录，并将自身复制到 bin 子目录，同时修改注册表 Run 项实现开机自启。其二，具备远程控制能力，会主动连接固定 URL 获取命令文件。其三，具备文件下载与上传能力，从 download.cgi 与 upload.cgi 等字符串可以看出其与远端控制端存在数据交换功能。其四，具备针对内网地址段的传播或攻击意图。其五，具备 DDoS 攻击能力，字符串中明确出现了 Smurf 远程攻击相关提示。

4. 样本采用了哪些防止被分析或逆向工程的技术

样本采用的第一种防分析手段是 UPX 加壳。原始样本的字符串提取结果较乱，重要信息不易直接暴露，必须先识别壳类型并完成脱壳后，才能更完整地恢复内部信息。第二种是虚拟环境相关检查。样本字符串中出现了 HKLM\Software\VMware, Inc.\VMware Tools\InstallPath，说明程序会关注当前是否处于 VMware 环境。这种环境感知虽不属于复杂的反调试技术，但足以在一定程度上提高分析门槛，并影响样本在分析环境中的行为呈现。

5. 对该恶意代码样本的分类及理由

该样本更适合被归类为 后门木马类恶意代码，同时带有一定的 bot 控制属性。之所以不宜简单归类为传统病毒，是因为现有分析并未显示其以感染其他宿主文件为核心；之所以不直接归类为典型蠕虫，是因为其主要工作模式仍是“落地—持久化—外联控制端—按指令执行任务”。从持久化、命令获取、远控执行与 DDoS 功能来看，它本质上是一类具备远程控制能力的后门木马。

6. 具有相似功能的其他工具

若从功能角度比较，rada 与早期 Windows 平台上的远控木马和 bot 工具较为相似，例如 Back Orifice、NetBus、Sub7 等。这些工具同样具备远程控制、持久化、接受指令和执行系统操作的能力。若从受控主机统一调度与批量攻击的角度看，也可与早期 Agobot 一类 bot 程序进行功能类比。

7. 是否可能调查出该二进制文件的开发作者，若可以需要什么环境和限定条件

在本次实验范围内，作者信息是可以调查出来的。样本本身支持通过 rada --authors 或 RaDa.exe --authors 输出作者署名，同时在脱壳后的 IDA 字符串窗口中也能看到同样的信息，均指向 Raul Siles & David Perez。要恢复这一信息，需要具备受控的分析环境，能够对样本进行脱壳与字符串查看，并保证样本本身未被二次篡改或重新打包。需要说明的是，这里能够确认的是“样本中嵌入的开发署名”，而不是更高层次的现实身份法律归属。

2.4 分析实践任务二：Windows 2000 系统被攻破并加入僵尸网络

2.4.1 分析背景与方法

本节分析对象是一份经过整理的蜜罐网络流量日志 botnet_pcap_file.dat。日志记录了一台 Windows 2000 蜜罐主机在约 5 天观察期内遭受攻击并被纳入僵尸网络的过程。实验中主要结合 Wireshark 的 Conversations、Follow TCP Stream、端口过滤，以及 tcpdump、tcpflow 等工具对关键会话进行还原，分析重点包括：IRC 控制通信、攻击来源、漏洞利用方式、成功攻击链条以及入侵后的后续行为。

2.4.2 IRC 协议基础与僵尸网络用途

从协议角度看，IRC（Internet Relay Chat）是一种基于文本命令的实时通信协议。客户端接入 IRC 网络时，通常会先发送 NICK 与 USER 两类消息完成身份声明；真正进入某个频道时，还会进一步发送 JOIN 消息。常见的 IRC TCP 端口包括 6667、6660—6669、7000，若启用加密，也常见 6697 端口。本次实验数据中，蜜罐主机与 IRC 服务器之间的有效通信集中出现在 6667 端口，这与典型 IRC 使用场景一致。

僵尸网络则是由大量已被控制的受感染主机构成的控制网络。受控主机会主动连接控制端或控制通道，等待接收命令，并执行 DDoS、扫描、下载执行新程序、发送垃圾邮件、充当代理或继续传播等任务。若把 IRC 用作控制通道，控制者只需维护频道和指令分发机制，就能够统一调度大量 bot 主机。

2.4.3 蜜罐主机与 IRC 服务器的通信情况

由于IRC端口众多，常用有：6660 - 7000，使用以下命令，将IRC服务器的端口和蜜罐主机的ip作为过滤条件，对Wireshark日志进行包的筛选：

ip.src==172.16.134.191 && tcp.port == 6660

...

ip.src==172.16.134.191 && tcp.port == 7000

最终只有6667端口有数据通信，其他端口都无效。

Statistics -> Conversations 中显示 63.241.174.144、217.199.175.10、209.196.44.172 66.33.65.58 、209.126.161.29 的 6667 会话

围绕蜜罐主机 172.16.134.191 的 IRC 相关流量进行筛选后，可以观察到其曾向五个 IRC 相关主机的 6667 端口发起连接尝试，分别为：

63.241.174.144:6667
217.199.175.10:6667
209.196.44.172:6667
66.33.65.58:6667
209.126.161.29:6667

但其中并非所有连接都形成了有效 IRC 会话。对题目所问“与哪些 IRC 服务器进行了通信”，应以完成会话建立并出现应用层 IRC 交互为判断标准。按照这一标准，真正发生了有效通信的 IRC 服务器共有三个：

63.241.174.144:6667
217.199.175.10:6667
209.196.44.172:6667

其中，前两个连接未形成稳定控制关系。与 63.241.174.144 的会话中，蜜罐主机发送了 NICK eohisou 与 USER eohisou，服务器返回 433 Nickname is already in use，随后连接超时结束；与 217.199.175.10 的会话中，蜜罐主机更换为随机昵称 rgdiuggac，但服务器返回 Sorry, server is full - try later，连接同样未能继续。

相比之下，与 209.196.44.172:6667 的会话完成了完整入网过程：蜜罐发送 NICK rgdiuggac 与 USER rgdiuggac localhost localhost :rgdiuggac，服务器返回 001 Welcome、002 Your host is irc5.aol.com、376 End of /MOTD 等欢迎消息，表明蜜罐主机已经作为 IRC 客户端成功接入该网络。

需要补充说明的是，66.33.65.58 与 209.126.161.29 也出现在 IRC 相关主机列表中，但抓包只显示 SYN 及其重传，未完成 TCP 三次握手，因此不应将其计为已发生通信的 IRC 服务器。

2.4.4 蜜罐主机加入僵尸网络的证据与规模判断

完成 IRC 入网后，蜜罐主机继续发送 MODE rgdiuggac -x、MODE rgdiuggac +i、JOIN #x...x :sex0r、WHO rgdiuggac 等指令。这里最关键的行为是 JOIN，因为它说明主机并非仅仅登陆到 IRC 服务器，而是进一步加入了具体频道。此后服务器返回大量 353 NAMES 响应，列出了频道中的在线昵称。频道成员昵称呈现出高度一致的随机命名特征，数量众多，与普通人工聊天频道明显不同，更符合恶意程序自动生成 bot 标识的特征。

使用以下命令安装TCPflow工具：

sudo apt-get install tcpflow

使用以下命令对日志进行分析：

sudo tcpflow -r botnet_pcap_file.dat " host 209.196.44.172 and port 6667"

生成了report.xml报告文件。

使用以下grep命令进行过滤后查看该文件便可得到主机数量，即利用管道命令来筛选：

sudo cat 209.196.044.172.06667-172.016.134.191.01152 | grep -a "^:irc5.aol.com 353" | sed "s/^:irc5.aol.com 353 rgdiuggac @ #x[^x]*x ://g" | tr ' ' '\n' | tr -d "\15" | grep -v "^$" | sort -u | wc -l

针对题目“在观察期间，多少不同主机访问了以 209.196.44.172 为服务器的僵尸网络”，实验中使用 tcpflow 提取对应会话，再利用管道命令从 353 返回中统计唯一昵称数，最终得到的结果为 3461 台主机。这一数值是按实验中给定统计方法得到的作业口径答案。与此同时，从 Follow TCP Stream 所见频道成员规模也可以看出，该控制通道已达到明显的大规模 botnet 特征。

因此，可以确认：蜜罐主机不仅成功接入 IRC 网络，而且进一步进入了由 209.196.44.172 提供控制服务的异常频道，并处在一个规模达数千主机的 IRC 型僵尸网络之中。

2.4.5 攻击源与被攻击端口

使用以下命令重新利用tcpflow来进行分析，并生成一个名为IP.txt的文件，文件中是被用于攻击蜜罐主机的所有IP地址：

tcpdump -n -nn -r botnet_pcap_file.dat 'dst host 172.16.134.191' | awk -F " " '{print $3}' | cut -d '.' -f 1-4 | sort | uniq | more > IP.txt;wc -l IP.txt

围绕蜜罐主机入站流量继续分析，可以统计出共有 165 个不同 IP 地址 对该主机发起了攻击或探测。实验中已通过 tcpdump 和 tcpflow 将其导出到 IP.txt 中，因此可以确认攻击源数量较多，属于面向公网暴露主机的持续性攻击场景。

利用tcpflow工具分析网络日志文件，提取攻击蜜罐主机的流量。使用命令tcpdump -r ...and tcp...提取TCP端口信息，使用命令tcpdump -r... and udp...提取UDP端口信息。

 tcpdump -r botnet_pcap_file.dat -nn 'src host 172.16.134.191' and  tcp[tcpflags]== 0x12 | cut -d ' ' -f 3 | cut -d '.' -f 5 | sort | uniq

tcpdump -r botnet_pcap_file.dat -nn 'src host 172.16.134.191' and udp | cut -d ' ' -f 3 | cut -d '.' -f 5 | sort | uniq

从端口层面看，蜜罐主机被攻击的 TCP 端口包括 135、139、25、445、4899、80，UDP 端口包括 137。

使用以下命令在Wireshark中查询以上端口：

ip.addr == 172.16.134.191 && tcp.port ==135

ip.addr == 172.16.134.191 && tcp.port ==139

ip.addr == 172.16.134.191 && tcp.port ==25

ip.addr == 172.16.134.191 && udp.port ==137

ip.addr == 172.16.134.191 && tcp.port ==4899

ip.addr == 172.16.134.191 && tcp.port ==80

ip.addr == 172.16.134.191 && tcp.port ==445

135端口：

基本只是三次握手
没看到 RPC bind、接口调用、后续 payload

139端口：

有 Session request
有 Positive session response
有 Tree Connect AndX Request
但后面多次直接 RST

这说明攻击者在尝试 NetBIOS/SMB 共享访问，只能算探测/尝试，没有攻击成功。

25端口：

25 端口虽对外返回了 SYN/ACK，说明 SMTP 服务处于开放状态，但从抓包看，攻击方仅完成了 TCP 三次握手，随后连接很快进入 FIN/ACK 关闭过程，且未出现 SMTP 协议的 banner、HELO/EHLO、MAIL FROM、RCPT TO、DATA 等应用层交互内容。因此，该端口只能认定为遭到连接探测或浅层服务测试，不能认定为攻击成功，更无证据表明攻击者通过 25 端口完成了漏洞利用或系统控制。

137端口：

基本都是 NBSTAT 名称查询
这是典型主机枚举、NetBIOS 信息探测

这是侦察，不是成功入侵。

下面的4899端口、80端口、445端口都有疑似攻击出现，在下一小节着重分析。

4899端口：

80端口：

445端口：

不同端口所反映的攻击强度并不相同：

135 端口主要表现为三次握手，未见明确 RPC bind 或后续 payload，属于探测或浅层连接。
139 端口出现 Session request、Positive session response 与 Tree Connect AndX Request，但后续多次被 RST 终止，只能认定为 NetBIOS/SMB 共享访问尝试。
25 端口虽可建连，但未见 SMTP banner、HELO/EHLO、MAIL FROM 等应用层交互，应视为服务探测。
137/UDP 基本体现为 NBSTAT 名称查询，属于主机枚举。
80、4899、445 端口则出现了更高强度的可疑行为，需要进一步结合应用层内容判断是否存在真实漏洞利用。

若从后续攻击链角度看，较为关键的源地址包括 61.111.101.78、210.22.204.101 和 24.197.194.106。这几个地址分别与 SMB 远程控制链、Web 漏洞利用流量以及多端口异常交互有关，是后续重点分析对象。

2.4.6 攻击者尝试利用的安全漏洞与技术

从应用层内容来看，本次攻击者尝试的安全漏洞与入侵技术主要集中在两类。

第一类是 IIS NULL.IDA / idq.dll 相关 Web 漏洞利用。80 端口上存在明确的 Web 漏洞利用攻击。利用 wireshark 对 ip.dst==172.16.134.191 && tcp.dstport==80 进行筛选后，可以直接观察到多类典型的恶意 HTTP 请求。来自 210.22.204.101 的流量中，多次出现带有超长参数和 shellcode 的 GET /NULL.IDA?...&cmd.exe$ 请求，这属于典型 IIS NULL.IDA / idq.dll 相关攻击流量，目标是利用历史漏洞执行系统命令；同时，来自 24.197.194.106 的流量则呈现出更明显的自动化漏洞扫描与批量利用特征，其请求涉及大量敏感路径和典型利用入口，包括：

msadc 目录遍历与 cmd.exe?/c+dir
/_mem_bin/ 与 /_vti_bin/ 相关路径
/bin/scripts/、/cgi/、/cgi-bin/ 下的 cmd.exe?/c+dir
iisadmpwd/*.htr
null.ida、null.idq、default.ida
boot.ini、win.ini、repair/sam._
多种 ../、..\\、%c0%af 等目录遍历变形写法

这些请求的目标非常明确：一类是尝试通过 IIS 历史漏洞直接触发远程命令执行，另一类是尝试通过目录遍历读取系统文件或访问 IIS 示例组件、管理脚本和 FrontPage 扩展等弱点位置。因此，80 端口上的行为应明确认定为“真实漏洞利用攻击”，而不是普通探测或页面访问。

不过，对这些恶意 Web 会话继续分析后，并未观察到与之对应的成功回显结果。例如，在正常 HTTP 会话中，访问 / 或图片资源时可以正常看到 HTTP/1.1 200 OK 等应用层响应；但在上述恶意请求中，并没有看到清晰的命令执行回显、目录列表、敏感文件内容返回，也没有形成能直接归因于该 Web 会话的 shell、文件落地或持续控制流量。因此，80 端口虽然发生了明确的漏洞利用尝试，但从现有证据看并未成功完成漏洞利用。

第二类是 SMB/DCERPC 方向的枚举与远程控制技术。在 445 端口流量中，可以看到对 \\172.16.134.191\IPC$、\samr、\\172.16.134.191\ADMIN$、\System32\PSEXESVC.EXE、\svcctl、\psexecsvc 的访问，以及 OpenSCManagerA、CreateServiceA、StartServiceA 等服务控制调用。这表明攻击者不仅在尝试共享访问和账户管理接口枚举，还在进一步实施典型的 PsExec 式远程服务创建与执行。

对于 4899 端口，需要谨慎区分。若使用 ip.addr == 172.16.134.191 && tcp.port == 4899 这类宽泛过滤条件，可能会把“攻击者本地源端口为 4899、目标实际是 80 端口”的 HTTP 攻击混入分析结果。这一点在抓包中表现得非常明显。图中下半部分由 24.197.194.106:4899 -> 172.16.134.191:80 组成，其实际含义并不是攻击者在访问目标的 4899 端口，而是攻击者以本地临时源端口 4899 向蜜罐主机的 80 端口发送 HTTP 请求。该会话中出现的 HEAD /cgi/.../winnt/system32/cmd.exe?/c+dir HTTP/1.0 等内容，本质上仍属于前文分析过的 Web 漏洞利用攻击，应归入 80 端口分析，而不能算作对 4899 端口服务的攻击证据。

使用准确的 ip.dst == 172.16.134.191 && tcp.dstport == 4899 过滤后，可以发现确有一条持续的双向二进制协议会话，即 tcp.stream 167。该会话具有以下特征：

会话持续时间明显长于普通探测流量；
双方存在大量 PSH, ACK 数据包，而不是仅完成三次握手后立即断开；
客户端到服务端约传输 13KB 数据；
服务端到客户端约返回 123KB 数据；
会话内容不是 HTTP 文本，也不是简单命令行回显，而是结构化的二进制协议数据；
服务端在多个时间点连续返回大块数据，说明双方完成了真实的应用层交互。

这些特征说明，攻击者确实成功连接到了蜜罐主机 4899 端口上运行的某个服务，并与该服务进行了较深入的协议通信。因此，4899 端口不能被归类为单纯的端口扫描或浅层探测，它反映的是一次真实的远程服务会话。

然而，尽管这条会话本身是成功建立的，当前抓包仍然不足以证明该端口上的通信已经导致系统被攻破。原因在于：从现有数据中无法直接提取出明确的命令执行结果、文件写入行为、服务创建记录或其他可以证明系统控制权已被获取的关键证据。也就是说，当前证据只能证明“攻击者成功连接并使用了 4899 端口上的服务”，但不能证明“攻击者通过 4899 端口成功入侵了系统”。

结合后续 445 端口上出现的 ADMIN$ 访问、PSEXESVC.EXE 落地以及 CreateServiceA、StartServiceA 等实锤证据，可以进一步判断：本次样本中，真正得到明确证实的成功入侵路径是 445 端口，而不是 4899 端口。4899 端口更适合定性为“可疑服务通信成功”，而不应直接定性为“攻击成功”。

因此，对 4899 端口的最终结论应为：攻击者成功连接并与 4899 端口上的服务进行了持续二进制交互，但现有证据不足以证明其通过该端口成功控制系统。

2.4.7 成功攻击与实现方式

在本次样本中，只有 445 端口上的攻击可以被明确认定为成功。最强、最直接的证据来自源主机 61.111.101.78。从抓包内容可见，该攻击者完成了如下链条：

成功访问 \\172.16.134.191\IPC$
成功访问 \\172.16.134.191\ADMIN$
在目标系统 System32 目录中涉及 PSEXESVC.EXE
通过 \svcctl 访问服务控制管理器
在 DCE/RPC 解码结果中出现 OpenSCManagerA
出现 CreateServiceA: PSEXESVC: %SystemRoot%\System32\PSEXESVC.EXE
出现 StartServiceA
后续还能看到 ControlService、DeleteService、CloseServiceHandle

这条证据链说明，攻击者已经不再停留于端口探测或共享枚举，而是成功在目标主机上创建并启动了远程服务，随后再进行停止和删除服务等操作。这是典型的 PsExec 式远程执行行为，足以证明攻击者已经获得了管理员级远程执行能力，也就是说，445 端口上的攻击已经成功控制系统。

相比之下，80 端口上的攻击虽然能够明确认定为真实漏洞利用尝试，但当前日志中未见稳定的命令执行回显、文件落地或能够独立闭合的持续控制证据，因此不能单独实锤为成功入侵；4899 端口虽存在持续的双向二进制交互，但同样缺乏命令执行、文件写入、服务创建等关键证据，不能直接写成攻击成功。其余 135、139、25、137/UDP 端口，则仅表现为探测或浅层尝试。

系统被成功控制后，蜜罐主机又进一步与 209.196.44.172:6667 建立稳定 IRC 会话，完成入网、加入频道，并处于大规模随机昵称 bot 集群同一控制通道中。因此，“Windows 2000 系统被攻破并加入僵尸网络”这一结论是成立的：攻击链条先在 445 端口上形成明确成功入侵，再在后续阶段表现为 IRC 型 botnet 纳入。

2.4.8 小结

在本次样本中，只有 445 端口上的攻击可以明确认定为成功；80 端口和 4899 端口均存在较强可疑性，但证据强度仍不足以达到与 445 同等级的“已实锤成功”结论；其余端口则没有显示出成功攻击的证据。

445 端口之所以可以明确认定为成功，关键在于它不仅存在连接建立，更出现了完整的后渗透行为链。攻击者访问了 IPC$ 和 ADMIN$，在目标系统的 System32 目录中涉及 PSEXESVC.EXE，并通过服务控制接口执行了 OpenSCManagerA、CreateServiceA 和 StartServiceA。后续还能看到服务状态变化以及停止、删除服务等操作。这些行为已经超出了“探测”或“尝试利用”的范围，足以证明攻击者取得了管理员级远程执行能力，因此应认定为成功控制系统。

80 端口的情况则应区分“明确利用尝试”与“是否成功执行”两个层次。现有流量已经足以证明攻击者确实在针对 IIS 及相关 Web 组件进行漏洞利用，包括 NULL.IDA 请求和大量针对 cmd.exe 的目录遍历与远程命令执行尝试。但从当前日志中，尚未看到足够强的直接证据来证明这些 HTTP 请求已经成功返回命令执行结果，也没有形成可以明确归因于该 Web 会话的 shell、文件落地或后续控制动作。因此，80 端口最准确的表述应是：存在明确的漏洞利用攻击行为，但不能仅凭现有证据确认该攻击已单独成功控制系统。

4899 端口介于“普通探测”和“明确成功”之间。流量显示 210.22.204.101 与 172.16.134.191:4899 之间存在持续的双向数据交换，说明这不是简单的 SYN 扫描或一次性测试，而是已经与某个服务建立了稳定交互。从这个角度看，它显著强于 135、25、137 这类浅层探测流量。但由于没有观察到类似 445 端口那样的文件写入、服务创建或命令执行证据，因此仍不宜直接写成“攻击成功”。更稳妥的说法是：4899 端口存在高度可疑的持续会话，疑似后门或远控服务通信，但当前证据不足以单独确认利用成功。

其余端口均缺乏成功证据。135 端口只有短暂建连，没有后续 RPC 行为；139 端口虽然有 SMB 会话尝试，但很快被重置，没有进入控制阶段；137/UDP 仅是 NetBIOS 名称状态查询，属于枚举信息；25 端口仅见 TCP 建连和关闭，没有 SMTP 层命令，因此只能认定为服务探测，不构成成功攻击。

综上所述，本次样本中应采用如下定性：

445：明确成功，攻击者已获得远程执行能力。
80：明确存在漏洞利用攻击，是否成功尚无法实锤。
4899：高度可疑，存在持续交互，但暂不能确认已成功控制。
135、139、137/UDP、25：仅表现为探测、枚举或浅层尝试，未见成功证据。

2.4.9 问题回答

结合上述分析，可以对题目七问逐项作答。

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

IRC 是一种基于文本协议的实时聊天系统。客户端接入 IRC 网络时，通常会先发送 NICK 和 USER 消息完成身份登记，进入具体频道时还会发送 JOIN。常见的 IRC TCP 端口包括 6667、6660—6669、7000；若为加密 IRC，常见端口还包括 6697。

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

僵尸网络是由大量已被攻击者控制的受感染主机构成的控制网络。受控主机会连接控制端或控制通道，等待命令。其常见用途包括发起 DDoS 攻击、大规模扫描、下载并执行新恶意程序、发送垃圾邮件、充当代理节点，以及继续扩散蠕虫或后门程序。

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

真正与蜜罐主机 172.16.134.191 发生有效通信的 IRC 服务器共有三个：

63.241.174.144:6667
217.199.175.10:6667
209.196.44.172:6667

其中前两个连接未形成稳定控制关系，真正成功完成 IRC 入网并进入频道的是 209.196.44.172:6667。

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

按照实验中使用 tcpflow 和 grep 管道统计 IRC 频道成员的结果，可以得到共有 3461 台不同主机 访问了以 209.196.44.172 为服务器的僵尸网络。

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

实验中通过导出 IP.txt 的方式统计得出，共有 165 个不同 IP 地址 被用于攻击或探测蜜罐主机。若从关键攻击源来看，较突出的地址包括 61.111.101.78、210.22.204.101 和 24.197.194.106 等。

6. 攻击者尝试攻击了哪些安全漏洞？

攻击者明确尝试了两大类攻击。一类是 IIS NULL.IDA / idq.dll 相关漏洞、目录遍历与远程命令执行攻击，可从 GET /NULL.IDA?...&cmd.exe$、cmd.exe?/c+dir、msadc、boot.ini 等访问行为中看出。另一类是针对 SMB/DCERPC 暴露面的共享访问、SAMR 枚举和 PsExec 式远程控制操作，可从 IPC$、ADMIN$、samr、svcctl、PSEXESVC.EXE 等访问内容中看出。其余端口主要反映探测、枚举或可疑服务交互。

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

在本次样本中，能够被明确认定为成功的攻击只有 445 端口上的 SMB/PsExec 式远程控制攻击。攻击者 61.111.101.78 通过访问 IPC$ 和 ADMIN$，在目标主机上处理 PSEXESVC.EXE，并通过服务控制管理器执行 OpenSCManagerA、CreateServiceA 和 StartServiceA，最终完成了远程服务的创建与启动。这说明攻击者已经获得了系统级远程执行能力。80 端口上的漏洞利用虽明确存在，但当前证据不足以单独实锤成功；4899 端口高度可疑，但也不能单独确认为成功控制。最终，蜜罐主机在被攻破后成功接入 209.196.44.172:6667 的 IRC 控制网络，说明其确已被纳入僵尸网络。

三、学习中遇到的问题及解决

3.1 问题一：原始样本字符串信息杂乱，难以直接看出有效特征

问题描述：
在对 RaDa.exe 直接执行 strings 时，输出内容可读性较差，除了零散的 DLL 名称和函数片段外，很难直接提炼出 URL、作者、注册表路径或行为意图。

原因分析：
该样本并非纯净的未保护程序，而是经过 UPX 加壳处理。壳的存在压缩并扰乱了原始程序结构，使很多原本可直接见到的字符串被隐藏，导致命令行层面的简单字符串提取效果不理想。

解决过程：
先用 PEiD 对样本进行识别，确认壳类型为 UPX，再使用超级巡警脱壳机对样本脱壳，得到 RaDa_unpacked.exe。之后重新对脱壳样本执行 strings，并结合 IDA Pro 字符串窗口继续查看。为了提高可见度，还在 IDA 中调整了字符串编码方式，切换到 Unicode 相关选项，使作者信息、路径信息和控制地址更清晰地显示出来。

最终结果或经验：
该问题说明，面对可疑样本时不能把第一次 strings 的结果视为最终结论。若可读信息明显不足，应优先考虑是否存在加壳，再决定是否需要脱壳与反汇编辅助分析。

3.2 问题二：Crackme 程序已经找到关键字符串，但验证时没有得到成功结果

问题描述：
在对 crackme1.exe 和 crackme2.exe 进行分析时，即使已经从字符串窗口中定位到 "I know the secret" 这样的关键内容，命令行验证仍可能出现未得到预期成功提示的情况。

原因分析：
这一问题有两层原因。对 crackme1.exe 而言，若命令行中误用了中文引号，参数不会以程序预期的方式传入，因此即便文字内容看似正确，程序也不会进入成功分支。对 crackme2.exe 而言，程序除了检查第二个参数外，还额外检查文件名是否为 crackmeplease.exe，如果没有先重命名程序文件，即使输入口令正确也无法通过校验。

解决过程：
针对 crackme1.exe，将命令行中的引号改为英文引号后重新测试，程序即可返回正确的成功提示。针对 crackme2.exe，在 IDA 流程图中确认其确实先比较程序名，再比较输入参数后，先执行重命名操作，再使用正确参数进行运行，最终得到成功输出。

最终结果或经验：
逆向分析得到的“正确字符串”并不一定代表完整的成功条件。验证失败时，应反向检查程序是否还对文件名、参数数量、调用方式等外部条件进行了额外约束。

3.3 问题三：日志中过滤条件不准确，容易把可疑会话误判为成功攻击

问题描述：
在分析 botnet 日志时，若只根据 ip.addr 和端口号进行宽泛筛选，容易把一些本地源端口恰好相同的其他会话混入结果，从而误把普通 HTTP 攻击流量当成对 4899 端口服务的攻击，或者把可疑交互直接写成“攻击成功”。

原因分析：
网络流量分析的结论强度取决于过滤精度和证据链完整性。ip.addr == 172.16.134.191 && tcp.port == 4899 这种写法同时包含“源端口为 4899”和“目的端口为 4899”两类会话，若不进一步区分方向，就会混淆完全不同的应用层内容。另一方面，仅凭建连成功或持续收发数据，也不足以证明已获得系统控制权。

解决过程：
分析时改用更精确的过滤方式，如 ip.dst == 172.16.134.191 && tcp.dstport == 4899，只保留真正访问目标 4899 服务的会话；同时将端口分析与 Follow TCP Stream、SMB/DCERPC 解码、文件落地和服务创建信息结合起来，区分“探测”“真实利用尝试”“可疑会话”“已明确成功控制”几个层次。

最终结果或经验：
网络安全取证中最容易出错的地方并不是找不到异常流量，而是对异常流量下结论过快。只有在过滤条件准确、应用层内容清晰、后续行为链闭合时，才适合把某次攻击明确写成成功入侵。

四、学习感想和体会

通过本次实验，对恶意代码分析和网络取证之间的关系有了更具体的认识。过去对恶意代码的理解更多停留在“看静态特征、找可疑字符串”的层面，而在这次实践中，可以明显体会到静态分析、脱壳、字符串提取、反汇编查看和有限动态观察是相互补充的。原始样本中看不清的内容，在脱壳后才逐渐显现；仅有字符串信息又不足以完整解释样本目的，还需要结合路径、对象名、注册表项和网络地址进行归纳。这样得到的结论，比单纯依赖某一种工具更稳固。

Crackme 分析带来的体会则集中在“程序行为必须由逻辑解释”这一点上。命令行中一个表面上正确的输入，未必就是程序真正接受的完整条件。只有把字符串、比较函数、流程图和运行结果放在一起理解，才能准确找出成功分支的触发条件。尤其是 crackme2.exe 这种既检查文件名又检查参数的样本，更能说明逆向分析不能只看表面提示，而要回到程序内部的控制逻辑。

在 botnet 日志分析部分，最大的收获是对“攻击链条”有了更清楚的层次理解。一次成功攻击并不等于看到某个可疑请求，也不等于某个端口完成了三次握手，而是需要从探测、尝试利用、应用层交互、共享访问、文件落地、服务创建到后续外联控制逐层确认。也正因为如此，445 端口能够被明确认定为成功，而 80 端口和 4899 端口则只能分别写成“明确利用尝试”和“高度可疑服务交互”。这种区分使结论更加严谨，也更符合真实取证分析的写法。

从工具使用角度看，本次实验也进一步说明了工具只是手段，真正重要的是分析思路。PEiD、IDA、Process Explorer、Wireshark、tcpdump、tcpflow 各自解决的是不同层面的问题：有的用于看文件结构，有的用于看程序逻辑，有的用于看运行时痕迹，有的用于看网络证据。只有把这些结果串联起来，才能把“样本是什么”“它想做什么”“它是否真的成功了”这些问题回答清楚。

总体来看，本次作业把恶意代码样本处理、逆向分析、IRC 控制通信识别和蜜罐网络日志取证几个环节连接到了一起，使对攻击与防御的认识不再停留在单个知识点上，而是转向对完整攻击过程的理解。这种从静态样本到动态行为、从单机分析到网络证据还原的训练方式，对于后续继续学习恶意代码分析、溯源取证与安全运营都有很强的基础价值。

posted @ 2026-04-23 20:09 4eversinc2 阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

4eversinc2