elicryoung/network-traffic-analysis

# 第一阶段 - 熟悉 Wireshark 在深入研究更大的数据包捕获之前，我想花些时间让自己熟悉 Wireshark 本身。 我从 Wireshark 示例捕获存储库下载了几个示例 PCAP 文件，并用它们来探索界面、检查数据包，以及了解不同协议在应用程序中的表现形式。 我查看的两个捕获文件是： - `dhcp.pcap` - `ipv4frags.pcap` ### DHCP DHCP 捕获是一个很好的起点，因为其中没有太多复杂的操作，并且易于跟进。 通过这次捕获，我熟悉了 Wireshark 的三个主要面板： - 数据包列表 - 数据包详情 - 数据包字节 我还能够清晰地看到，当客户端尝试从网络获取 IP 地址时发生的 DHCP 过程。由于客户端还没有 IP 地址，初始流量在本地网络上进行了广播。 打开单个数据包还让我能够检查以下字段： - 源端口和目标端口 - TTL 值 - 数据包时间戳 - 协议特定信息 （见图 1.1 和 1.2） ### IPv4 分片 接下来我查看了 `ipv4frags.pcap`。 这次捕获引入了分片的 IPv4 流量，也是我第一次在实践中看到数据包重组。 引人注目的是 Wireshark 自动重建分片数据包的能力。捕获结果显示数据包被标记为“Reassembled in #2”，表明 Wireshark 已将多个分片重新组合成一条完整的消息。 尽管捕获文件很小，但它引入了一个在分析大型网络捕获时非常重要的概念。 （见图 1.3） ### 我学到了什么 到这个阶段结束时，我已经能够轻松地： - 浏览 Wireshark 界面 - 打开并检查单个数据包 - 追踪通信流 - 理解 DHCP 广播 - 识别分片和重组的流量 最重要的是，我对这个工具已经足够熟悉，可以开始分析自己捕获的流量了。 # 第二阶段 - 实时流量分析 一旦我对使用 Wireshark 感到得心应手，我就想分析一些来自我自己网络的真实流量。 目标并不一定是发现任何可疑的东西。相反，我想习惯于处理更大的捕获文件，并学习分析师如何使用过滤器来调查网络活动。 我从我的无线网络捕获了大约两分钟的流量。 ## 捕获概述 | 指标 | 数值 | |----------|----------| | 捕获持续时间 | ~134 秒 | | 总数据包数 | 3,642 | | 主要协议 | TCP (32.5%) | | IPv6 流量 | 存在 (34.9%) | | DNS 流量 | 存在 | | ARP 流量 | 存在 | | NTP 流量 | 存在 | | 主要应用流量 | HTTPS (TCP/443) | 捕获统计数据是通过以下方式收集的： - `Statistics → Capture File Properties` - `Statistics → Protocol Hierarchy` （见图 2.1 和 2.2） ## 初步观察 立刻让我感到惊讶的一件事是，在如此短的时间内竟然产生了这么多流量。我并没有进行任何特别繁重的操作，却捕获了数千个数据包。 大部分流量是基于 TCP 的，同时也存在大量的 IPv6 流量。大多数应用流量是加密的 HTTPS 流量，这正是您在现代网络中所期望看到的。 我很快就明白了为什么过滤器如此重要。一次查看数千个数据包会让人眼花缭乱，并且很难识别出任何有用的信息。过滤使您能够专注于特定的协议、行为和会话。 ## 我使用的过滤器 ### DNS ``` dns ``` 这是最有用的过滤器之一，因为它让我能够看到我的机器正在与哪些域名进行通信。 我注意到了与 Microsoft 服务、VS Code 和 GitHub Copilot 基础设施相关的请求。 示例： ``` 172.20.10.2 → 172.20.10.1 Standard query HTTPS main.vscode-cdn.net ``` 尽管大部分流量是加密的，但 DNS 仍然提供了关于正在访问哪些服务的有用上下文。 ### TCP ``` tcp ``` 这显示了捕获中的所有 TCP 流量。 由于 TCP 占了捕获的大部分，因此该过滤器产生了大量输出。它有助于获得通信的广泛概述，但通常需要与更具体的过滤器结合使用。 ### HTTPS ``` tcp.port == 443 ``` 此过滤器分离出了加密的 HTTPS 流量。 尽管流量的内容是加密的，但我仍然可以看到源地址和目标地址、连接时序和会话行为。 很快就能清楚地看出，即使在无法检查 payload 数据时，元数据为何仍然具有价值。 ### TCP 连接请求 ``` tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` 此过滤器显示用于建立 TCP 连接的初始 SYN 数据包。 它有助于直观呈现何时创建新会话以及设备启动新连接的频率。 ### TCP 重传 ``` tcp.analysis.retransmission ``` 此过滤器显示 Wireshark 识别为重传的数据包。 在捕获期间只出现了少量此类数据包，这是正常的，可能由于丢包或暂时的网络拥塞引起。 ### TCP 重置数据包 ``` tcp.flags.reset == 1 ``` 此过滤器显示 TCP 重置 (RST) 数据包。 我在整个捕获过程中发现了几个示例，表明连接被意外终止或被远程主机拒绝。 ### ARP ``` arp ``` 此过滤器显示地址解析协议流量。 ARP 请求显示了设备在通信之前解析 MAC 地址的过程。这是一个有用的提醒：在用户永远看不到的正常网络通信之下，还发生着很多事情。 ### IPv6 ``` ipv6 ``` 此过滤器显示所有 IPv6 流量。 我对捕获中出现的 IPv6 流量之多感到惊讶。在进行这次练习之前，我知道 IPv6 被广泛使用，但看到它占了我自己网络上三分之一的流量，让这一点变得更加明显。 ## 我学到了什么 从这个阶段得到的最大教训是，数据包分析实际上并不是要逐个查看数据包。 真正的技能是将捕获范围缩小到易于管理的范围，然后对你看到的内容提出问题。 使用过滤器使得快速专注于特定协议、识别模式以及理解不同类型的流量如何促成了整体网络活动成为可能。 这个阶段让我对使用 Wireshark、处理更大的捕获文件以及在继续进行恶意软件调查和事件响应风格的练习之前理解正常网络流量的样子有了更大的信心。 # 第三阶段 ## 可疑流量模式 在第二阶段花时间分析了正常流量之后，我想调查一个包含真正可疑活动的数据包捕获。 对于这个阶段，我使用了 Malware-Traffic-Analysis.net 提供的训练练习之一，该网站发布旨在模拟事件响应调查的真实数据包捕获。 训练练习可以在以下地址找到： https://www.malware-traffic-analysis.net/training-exercises.html 与前面的阶段不同，目标不再是理解协议是如何工作的，而是识别受感染的系统并确定是谁在使用它。 ## 调查 1 - Easy As 123 对于第一次调查，我选择了练习 **“Easy As 123”**。（见图 3.1） 场景始于安全运营中心 (SOC) 收到来自安全信息和事件管理 (SIEM) 平台的警报，指示可能存在 NetSupport Manager RAT（远程管理工具）活动。警报识别出在 **2026 年 2 月 28 日 19:55 UTC** 开始通过 TCP 端口 **443** 与外部 IP 地址 **45.131.214.85** 的通信。 练习提供了一个包含受影响网段流量的数据包捕获，并挑战分析师识别受感染的 Windows 主机以及与该活动相关的用户。 网络环境由一个在 **10.2.28.0/24** 网络上运行、名为 **EASYAS123** 的 Active Directory 域组成。 本次调查的目的是使用 Wireshark 分析数据包捕获，识别受感染的工作站，追踪其通信，并收集足够的证据来确定在感染时是谁在使用该系统。 练习要求识别： - 受感染的 Windows 客户端 IP 地址 - 受感染的 Windows 客户端 MAC 地址 - 主机名 - 用户帐户名 - 关联用户的全名 在调查恶意流量之前，我首先收集了有关数据包捕获的一些常规信息，以更好地了解环境和存在的协议类型。 ### 捕获概述 | 指标 | 数值 | |---|---| | 文件名 | 2026-02-28-traffic-analysis-exercise.pcap | | 捕获持续时间 | 04:21:29 | | 首个数据包时间 | 2026-02-28 19:55:06 | | 最后一个数据包时间 | 2026-03-01 00:16:35 | | 总数据包数 | 15512 | | 平均数据包数/秒 | 1.0 | | 平均数据包大小 | 408B | ### 协议层级 | 协议 | 百分比 | 数据包 | |---|---:|---:| | TCP | 80.9 | 12544 | | UDP | 13.6 | 2113| | DNS | 5.2 | 809 | | HTTP | 2.3 | 354 | | ARP | 5.4 | 836 | | ICMP | 0.1 | 19 | 时长超过四个小时并包含超过 15,000 个数据包，这比我之前阶段处理的捕获文件要大得多。 ### 了解环境 `局域网网段范围：10.2.28.0/24 (10.2.28.0 到 10.2.28.255)` - 任何以 10.2.28.x 开头的地址都很可能是内部的 - 任何在该范围之外的地址都很可能是外部的 - 受感染的机器应该在此范围内的某处，因为该练习要求我们识别受感染的内部工作站。 `域名：easyas123[.]tech` - 这是组织的 Windows/Active Directory 域名 - 它有助于识别属于受害者环境的流量 - 例如，“DESKTOP-TEYQ2NR.easyas123.tech”很可能意味着“加入 easyas123.tech 域的 Windows 工作站” `AD 环境名称：EASYAS123` - 这是简短的 Windows 域 / NetBIOS 风格的名称 - 告诉我们域帐户名 - 例如，“EASYAS123\jsmith”表示来自 EASYAS123 域的用户 jsmith `Active Directory (AD) 域控制器：10.2.28[.]2 - EASYAS123-DC` 由于 Domain Controller 负责处理身份验证和目录服务，我怀疑发往和来自 10.2.28.2 的流量可能会揭示有用的信息，例如： - 主机名 - 用户名 - 身份验证活动 - 域成员身份 `局域网网段网关：10.2.28[.]1` - 这很可能是网络的路由器/防火墙。 - 内部机器使用它来访问互联网 `局域网网段广播地址：10.2.28[.]255` - 网络的标准广播 ## 步骤 1 - 识别受感染的主机 练习已经提供了一个强有力的入侵指标 (IOC)： ``` 45.131.214.85 ``` 因此，我的第一步是确定哪个内部主机在与该地址进行通信。 ### 使用的过滤器 ``` ip.addr == 45.131.214.85 ``` ### 发现 此过滤器返回了大约 **550 个数据包**，约占捕获中所有流量的 **3.5%**。 大部分此类流量涉及内部主机： ``` 10.2.28.88 ``` 流量主要是： - TCP - HTTP 我还注意到，通信大约在捕获开始 45 秒时开始，然后以大约 60 秒的间隔重复出现，直到停止。 这种模式立刻引起了我的注意，因为周期性通信通常与 **beaconing 行为**相关，即恶意软件定期向命令与控制服务器签到。 此时我怀疑 **`10.2.28.88`** 就是受感染的工作站。 为了验证这一假设，我细化了过滤器： ``` ip.addr == 10.2.28.88 && ip.addr == 45.131.214.85 ``` 结果显示了相同的通信，证实了 **`10.2.28.88`** 就是应对可疑流量负责的系统的结论。 ### 追踪 TCP 流 在识别出可能的受感染主机后，我想了解通信的性质。 为此，我选择了一个数据包并使用了： ``` Follow → TCP Stream ``` 这重建了两个主机之间的完整对话。 在流中，我观察到了重复的请求，例如： ``` HTTP/1.1 200 OK Server: NetSupport Gateway/1.92 (Windows NT) POST http://45.131.214.85/fakeurl.htm HTTP/1.1 User-Agent: NetSupport Manager/1.3 Host: 45.131.214.85 ``` （见图 3.2） 从中可以得出几个重要的观察结果： - 流量明确引用了 **NetSupport Gateway** - User-Agent 将自身标识为 **NetSupport Manager** - 请求指向 SIEM 警报识别出的确切 IP - 通信模式是重复的，并且与 beaconing 行为一致 这是一个重要的发现，因为流量不再仅仅由于目标 IP 地址而变得可疑。数据包内容本身就直接引用了警报中识别出的软件。 在此阶段，我确信： | 证据 | 数值 | |---|---| | 疑似受感染主机 | **10.2.28.88** | | 外部 RAT 服务器 | **45.131.214.85** | | 恶意软件活动 | **NetSupport Manager / Gateway** | | 观察到的 URL | **http://45.131.214.85/fakeurl.htm** | | 行为 | **Beaconing / 周期性通信** | ## 步骤 2 - 识别 MAC 地址 下一个目标是识别受感染工作站的 MAC 地址。 我应用了过滤器： ``` ip.addr == 10.2.28.88 ``` 然后我选择了一个数据包并展开了 **Ethernet II** 头部。 源 MAC 地址是： ``` 00:19:d1:b2:4d:ad ``` 这为与受感染工作站关联的网络适配器提供了唯一的标识符。 ## 步骤 3 - 识别主机名 在 IP 地址和 MAC 地址之后，下一个目标是确定受感染机器的主机名。 ### 初步尝试 - DHCP 我的第一个想法是检查 DHCP 流量，因为在 DHCP 租约请求期间通常会包含主机名。 我应用了： ``` ip.addr == 10.2.28.88 && dhcp ``` 虽然这确认了 IP 与 MAC 的关系，但它没有揭示主机名。 尽管这种方法没有提供答案，但它仍然很有用，因为它验证了已经发现的信息。 ### 转向域控制器流量 由于 Windows 系统定期与 Domain Controller 进行身份验证和目录服务的通信，我决定将重点放在疑似主机和 Domain Controller 之间的流量上。 ``` ip.addr == 10.2.28.88 && ip.addr == 10.2.28.2 ``` 这揭示了多种协议类型，包括： - DNS - SMB - Kerberos DNS 和 SMB 流量有助于确认域活动，但没有立即揭示工作站名称。 结果证明最有用的协议是 **Kerberos**。 在一个 Kerberos **AS-REQ** 数据包中，我观察到了： ``` HostAddress: DESKTOP-TEYQ2NR<20> ``` 该数据包来源于： ``` Source IP: 10.2.28.88 Destination IP: 10.2.28.2 ``` 这表明在身份验证期间识别自己的工作站是： ``` DESKTOP-TEYQ2NR ``` 这使我能够识别出受感染工作站的主机名。 ## 步骤 4 - 识别用户帐户 下一步是识别与工作站关联的用户。 在检查相同的 Kerberos 身份验证流量时，我发现了 Kerberos **cname** 字段。 在 Kerberos 中，**cname** 代表 **Client Name**（客户端名称），用于标识请求身份验证的帐户。 其中包含的值为： ``` brolf ``` （见图 3.3） 这表明工作站正在使用以下帐户进行身份验证： ``` EASYAS123\brolf ``` 此时我已经确定了用户名，但还没有确定帐户背后的个人。 ## 步骤 5 - 识别用户的全名 我的第一次尝试是在捕获的其他地方搜索对 **brolf** 的引用。 我检查了数据包详情并审查了 LDAP 流量，期望找到与该帐户关联的目录信息。但是，这没有产生任何有用的结果。 此时，我研究了捕获中存在的 Windows 协议，并发现了 **SAMR (Security Account Manager Remote)** 流量。 SAMR 被 Windows 系统用来从 Domain Controller 查询帐户信息。 在审查 SAMR 流量时，我识别出了如下数据包： ``` 339 16.755086 10.2.28.2 10.2.28.88 SAMR QueryUserInfo Response ``` 打开数据包显示了与该用户名关联的帐户信息。 响应包含： ``` Account Name: brolf Full Name: Becka Rolf ``` （见图 3.4） 这明确地识别出了与受感染工作站关联的用户。 ## 证据链 ``` 45.131.214.85 (IOC from SIEM) ↓ 10.2.28.88 (Internal host communicating with IOC) ↓ 00:19:d1:b2:4d:ad (MAC Address) ↓ DESKTOP-TEYQ2NR (Hostname) ↓ EASYAS123\brolf (User Account) ↓ Becka Rolf (User Identity) ``` ## 最终发现 | 项目 | 数值 | |---|---| | 受感染的 IP 地址 | **10.2.28.88** | | MAC 地址 | **00:19:d1:b2:4d:ad** | | 主机名 | **DESKTOP-TEYQ2NR** | | 用户帐户 | **brolf** | | 全名 | **Becka Rolf** | 本次调查成功地将 SIEM 警报从恶意外部 IP 地址追踪到了受影响的工作站、关联的用户帐户，并最终追踪到在发生该活动时使用该系统的个人。 ## 经验教训 这是我第一次尝试完成结构化的恶意软件流量分析练习。 调查中最有趣的部分是看到如何将跨多个协议的信息拼凑在一起。我们不是在单个数据包中找到答案，而是每一步都揭示了一小部分证据，这些证据帮助构建了整体图景。 调查还强调了在某种方法行不通时进行方向转换的重要性。我最初尝试通过 DHCP 流量识别主机名并没有提供答案，但它帮助验证了之前的发现，并引导我转向 Kerberos 流量，最终揭示了工作站名称和用户帐户。 通过这次练习，我获得了以下方面的实践经验： - IOC 驱动的调查 - TCP 流重建 - Kerberos 分析 - Windows 身份验证流量 - 用户和主机归属 - 根据网络数据建立证据追踪 最重要的是，这项练习展示了如何通过数据包捕获追踪 SIEM 警报，并将其关联回特定的设备和用户。

标签：PCAP, Terraform 安全, Wireshark, 协议分析, 句柄查看, 学习资源, 权限提升, 网络安全, 防御绕过, 隐私保护