JFrancisSOC/Case-File-01-Investigating-Network-Traffic-with-WireShark

# 案件档案 01：网络流量调查 ## 案件概述 | 案件详情 | 信息 | |---|---| | 案件 ID | CF-01 | | 调查类型 | 网络流量审查 | | 分析师 | Jamaal Francis | | 告警来源 | 无告警 — 家庭实验室调查 | | 严重程度 | 信息 | | 状态 | 已关闭 | | 操作系统 | Windows 11 | | 分析工具 | Wireshark 4.6.7 | | 捕获接口 | Wi-Fi | | 本地 IP 地址 | `192.168.1.155` | | 路由器/DNS 服务器 | `192.168.1.1` | | 最终结论 | 正常网络活动 | ## 案件总结 我使用 Wireshark 完成了一次实时网络流量调查。此案件并非由安全告警引起。我进行此次调查是为了练习 SOC 分析师如何捕获流量、审查数据包、过滤协议以及记录发现。 我捕获了 Wi-Fi 连接的流量，并审查了 IP 地址、域名、端口、协议、TCP 标志和数据包详情。我还追踪了一个 TCP stream，以检查我的计算机与外部服务器之间的通信。 ## 调查目标 我的目标是： - 识别活动的网络接口。 - 捕获实时网络流量。 - 识别我计算机的本地 IP 地址。 - 审查源 IP 地址和目标 IP 地址。 - 识别正在使用的协议。 - 过滤 DNS 和 TCP 流量。 - 检查 DNS 请求。 - 审查 TCP 端口、标志和 header 信息。 - 追踪一个 TCP 对话。 - 确定审查的流量是正常还是可疑的。 ## 收集的证据 调查期间捕获了以下证据： 1. Wireshark 网络接口 2. 实时数据包捕获 3. 捕获的流量及识别出的协议 4. 过滤出的 DNS 流量 5. TCP 数据包详情 6. TCP header 详情 7. 追踪 TCP Stream 对话 ## 网络指标 ### 内部网络信息 | 指标 | 值 | 用途 | |---|---|---| | 本地 IP 地址 | `192.168.1.155` | 正在调查的计算机 | | 路由器/DNS 服务器 | `192.168.1.1` | 用于处理 DNS 请求的本地路由器 | | DNS 端口 | `53` | 域名请求 | | HTTP 端口 | `80` | 未加密的 Web 通信 | | HTTPS 端口 | `443` | 加密的 Web 通信 | ### 观察到的外部 IP 地址 - `20.59.128.9` - `72.154.7.114` - `172.183.7.192` - `20.184.175.19` - `20.184.175.23` - `13.89.179.15` ### 观察到的域名和主机名 - `history.google.com` - `settings-win.data.microsoft.com` - `v10.events.data.microsoft.com` - `img-s-msn-com.akamaized.net` ### 观察到的协议 - DNS - UDP - TCP - HTTP - TLS 1.2 - QUIC - IPv4 - IPv6 # 调查时间线 ## 步骤 1 — 识别活动的网络接口 我打开了 Wireshark 并审查了可用的网络接口。该列表包括 Wi-Fi、Ethernet、loopback 流量、Bluetooth 以及多个本地网络连接。 我选择了 Wi-Fi 接口，因为活动图表显示它正在积极发送和接收网络流量。 ### 证据 01 — Wireshark 接口  ## 步骤 2 — 开始实时数据包捕获 我在 Wi-Fi 接口上开始了实时捕获。Wireshark 开始显示进出我计算机的网络流量。 数据包列表显示了： - 数据包编号 - 时间戳 - 源地址 - 目标地址 - 协议 - 数据包长度 - 数据包信息 一个选定的数据包显示了从外部 IP 地址 `20.59.128.9` 发往我计算机 `192.168.1.155` 的 TCP 流量。 | 数据包详情 | 观察到的值 | |---|---| | 源 IP | `20.59.128.9` | | 目标 IP | `192.168.1.155` | | 协议 | TCP | | 源端口 | `80` | | 目标端口 | `62946` | | TCP 标志 | PSH, ACK | | 帧大小 | 2,778 字节 | | TCP payload | 2,712 字节 | 源端口是 `80`，通常用于 HTTP 流量。PSH 和 ACK 标志表明数据正通过已建立的连接发送，并且之前接收到的数据正在被确认。 ### 证据 02 — 实时数据包捕获  ## 步骤 3 — 识别网络协议 我审查了协议列，并识别出几种不同类型的网络流量。 这些协议包括： - DNS - TCP - HTTP - QUIC - UDP - IPv4 - IPv6 数据包捕获显示了涉及 `history.google.com` 的 DNS 请求。我还观察到我计算机 `192.168.1.155` 与外部 IP 地址 `20.59.128.9` 之间的 HTTP 通信。 一个选定的 DNS 数据包显示我的计算机正在向本地路由器发送请求。 | 数据包详情 | 观察到的值 | |---|---| | 源 IP | `192.168.1.155` | | 目标 IP | `192.168.1.1` | | 传输协议 | UDP | | 目标端口 | `53` | | 应用层协议 | DNS | ### 证据 03 — 捕获的网络流量及识别出的协议  ## 步骤 4 — 过滤 DNS 流量 我输入了以下 Wireshark 显示过滤器： `dns` 此过滤器移除了无关的数据包，仅显示 DNS 流量。 我观察到位于 `192.168.1.155` 的计算机正在向位于 `192.168.1.1` 的路由器和 DNS 服务器发送 DNS 请求。 其中一个选定的请求是针对 `settings-win.data.microsoft.com` 的。 | DNS 详情 | 观察到的值 | |---|---| | 源 IP | `192.168.1.155` | | 目标 IP | `192.168.1.1` | | 源端口 | `49876` | | 目标端口 | `53` | | 请求的域名 | `settings-win.data.microsoft.com` | | DNS 记录类型 | A 和 AAAA | A 请求用于查找 IPv4 地址。AAAA 请求用于查找 IPv6 地址。 响应还显示了与 Microsoft 流量管理服务相关的 CNAME 信息。 ### 证据 04 — DNS 流量过滤器  ## 步骤 5 — 分析 TCP 连接 我输入了以下显示过滤器： `tcp` 此过滤器使我能够专注于 TCP 流量。 我选择了数据包 `1203`，它显示了我的计算机试图与一台外部服务器启动 HTTPS 连接。 | TCP 详情 | 观察到的值 | |---|---| | 数据包编号 | `1203` | | 源 IP | `192.168.1.155` | | 目标 IP | `20.184.175.19` | | 源端口 | `61126` | | 目标端口 | `443` | | TCP 标志 | SYN | | 帧大小 | 66 字节 | SYN 标志表明我的计算机正在请求启动 TCP 连接。 随后的数据包包括 SYN-ACK 和 ACK 数据包。这展示了用于建立连接的 TCP 三次握手。 随后流量显示了针对 `v10.events.data.microsoft.com` 的 TLS 1.2 Client Hello。目标端口是 `443`，表明这是加密的 HTTPS 通信。 ### 证据 05 — TCP 数据包分析  ## 步骤 6 — 检查 TCP Header 我选择了数据包 `358` 并展开了 Transmission Control Protocol 部分。 这使我能够审查存储在 TCP header 内部的信息。 | TCP Header 详情 | 观察到的值 | |---|---| | 数据包编号 | `358` | | 源 IP | `192.168.1.155` | | 目标 IP | `13.89.179.15` | | 源端口 | `60896` | | 目标端口 | `443` | | 序列号 | `10544` | | 确认号 | `4679` | | TCP 标志 | ACK | | TCP header 长度 | 20 字节 | | TCP 段长度 | 0 字节 | | Window 值 | `254` | | 计算出的 Window 大小 | `65024` | | Window 缩放因子 | `256` | | 对话状态 | 完成，包含数据 | ACK 标志表明我的计算机正在确认在已建立的 TCP 连接期间接收到的数据。 TCP 段长度为零，意味着选定的数据包正在确认流量，而没有携带额外的应用数据。 目标端口是 `443`，这表明该连接正在使用 HTTPS。周围的数据包还显示了涉及 `v10.events.data.microsoft.com` 的 TLS 1.2 通信。 ### 证据 06 — TCP Header 分析  ## 步骤 7 — 追踪 TCP Stream 我使用 Wireshark 的 Follow TCP Stream 功能将一个 TCP 对话从其余捕获内容中分离出来。 | TCP Stream 详情 | 观察到的值 | |---|---| | Stream 编号 | `5` | | 客户端数据包 | `3` | | 服务器数据包 | `6` | | 通信轮次 | `3` | | 对话总大小 | 5,717 字节 | | 显示格式 | ASCII | | 可见主机名 | `img-s-msn-com.akamaized.net` | 大部分信息显得不可读，因为应用数据已被加密。 不同的颜色代表了客户端和服务器之间相反方向传输的流量。追踪这个 stream 帮助我专注于一个对话，而结果中不会出现无关的数据包。 ### 证据 07 — 追踪 TCP Stream 对话  # 调查发现 在调查过程中，我确认了以下内容： 1. 我的计算机使用了本地 IPv4 地址 `192.168.1.155`。 2. 我的路由器和 DNS 服务器使用了 IP 地址 `192.168.1.1`。 3. DNS 请求通过 UDP 端口 `53` 发送。 4. 在 TCP 端口 `80` 上观察到了 HTTP 流量。 5. 在 TCP 端口 `443` 上观察到了 HTTPS 和 TLS 流量。 6. 存在涉及 Google 和 Microsoft 服务的 DNS 请求。 7. TCP 流量包括 SYN、SYN-ACK、ACK 和 PSH-ACK 数据包。 8. SYN、SYN-ACK 和 ACK 数据包展示了 TCP 三次握手。 9. 数据包捕获包括 DNS、UDP、TCP、HTTP、TLS 1.2、QUIC、IPv4 和 IPv6 流量。 10. TCP stream 包含加密的应用数据。 11. 在 TCP stream 内可以看到主机名 `img-s-msn-com.akamaized.net`。 12. 在我审查的数据包中，我没有发现明显的恶意网络活动迹象。 # 分析师评估 我审查的流量似乎与正常的 Web 浏览、Windows 服务、Microsoft 后台通信和其他常规网络活动一致。 外部 IP 地址通过常见的 Web 端口（例如 `80` 和 `443`）进行通信。DNS 请求连接到可识别的 Google、Microsoft 以及与 MSN 相关的服务。 加密的 TCP stream 是预期的，因为 HTTPS 流量可以保护应用数据不被作为纯文本读取。 我没有找到足够的证据将此流量归类为恶意流量。 # 已采取的行动 - 从 Wi-Fi 接口捕获实时流量。 - 保留了调查的截图。 - 识别了本地 IP 地址和 DNS 服务器。 - 记录了外部 IP 地址和域名。 - 使用 `dns` 过滤 DNS 流量。 - 使用 `tcp` 过滤 TCP 流量。 - 审查了 DNS 请求和响应。 - 检查了 TCP 标志和 header 值。 - 识别了 TCP 三次握手。 - 追踪并审查了一个 TCP stream。 - 记录了发现和最终结论。 由于未识别出恶意活动，因此无需采取遏制或修复措施。 # 最终结论 | 结案 | 结果 | |---|---| | 案件状态 | 已关闭 | | 严重程度 | 信息 | | 活动分类 | 正常网络活动 | | 是否识别出恶意活动 | 否 | | 是否需要遏制 | 否 | | 已审查的证据 | 七张截图 | | 分析师 | Jamaal Francis | 在审查了数据包捕获、记录了网络指标、分析了 DNS 和 TCP 流量并追踪了一个 TCP stream 之后，我完成了此次调查。 证据显示了正常的网络通信，未发现明显的恶意活动。案件档案 01 作为信息级别被关闭。

标签：TCP/IP, VX技术, Wireshark, 句柄查看, 安全演练, 安全运营中心(SOC), 底层编程, 网络协议分析, 网络流量分析