JFrancisSOC/Case-File-02-DNS-Analysis

# 案件档案 02：DNS 分析 ## 案件概述 | 字段 | 详细信息 | |---|---| | 案件 ID | CF-02 | | 调查日期 | 2026年7月21日 | | 调查类型 | DNS 性能主动审查 | | 分析师 | Jamaal Francis | | 告警来源 | 无安全告警 — 家庭实验室用户报告 | | 严重程度 | 信息 | | 状态 | 已关闭 | | 受影响主机 | `FrancisHP` | | 受影响 IP | `192.168.1.155` | | DNS 服务器 | `CR200A.mynetworksettings.com` (`192.168.1.1`) | | 捕获接口 | Wi-Fi | | 分析工具 | Wireshark 4.6.7 | | 操作系统 | Windows 11 | | 最终判定 | 良性 DNS 活动 | ## 案件摘要 用户报告网站加载时间比平时长。我在 `FrancisHP` 上进行了一次家庭实验室 DNS 调查，以确定 DNS 解析是否导致了报告的延迟。 我捕获了最新的网络流量，对 `youtube.com` 进行了一次查询，审查了相关的 DNS 查询和响应，并比较了 A、AAAA 和 HTTPS 记录的响应时间。DNS 响应在约 37-43 毫秒内无错误完成。证据没有显示测试期间存在缓慢、可疑或恶意的 DNS 活动。 ## 调查目标 - 从 Wi-Fi 接口捕获新的 DNS 流量。 - 确定通信中涉及的计算机和 DNS 服务器。 - 审查 `youtube.com` 的查询和响应。 - 确定返回的 IPv4 和 IPv6 地址。 - 检查 A、AAAA 和 HTTPS DNS 记录的详细信息。 - 比较 DNS 响应时间与 TTL 缓存值。 - 检查是否存在错误、异常域名、重复请求或意外结果。 - 确定是否需要遏制或升级。 ## 收集的证据 | 证据 | 描述 | |---|---| | `01 Wireshark Wi-Fi Interface.png` | 活动的 Wi-Fi 捕获接口 | | `02 DNS Capture Started.png` | 过滤前的实时数据包捕获 | | `03 DNS Traffic Filter.png` | DNS 显示过滤器及过滤后的数据包 | | `04 YouTube DNS Lookup Results.png` | `nslookup youtube.com` 结果 | | `05 DNS Query Analysis.png` | YouTube A 记录查询详细信息 | | `06 DNS Response Analysis.png` | YouTube A 记录响应详细信息 | | `07 DNS Record Details.png` | YouTube AAAA 记录响应详细信息 | | `08 HTTPS DNS Record Analysis.png` | YouTube HTTPS 记录响应详细信息 | | `Case File 02 DNS Analysis.pcapng` | 保存的 Wireshark 数据包捕获 | ## 网络指标 | 类型 | 值 | 上下文 | |---|---|---| | 主机名 | `FrancisHP` | 受调查计算机 | | 内部 IPv4 地址 | `192.168.1.155` | 受调查计算机 | | DNS 服务器主机名 | `CR200A.mynetworksettings.com` | 本地 DNS 解析器 | | DNS 服务器 IPv4 地址 | `192.168.1.1` | DNS 响应来源 | | 域名 | `youtube.com` | 受调查域名 | | 返回的 IPv4 地址 | `142.251.211.238` | YouTube A 记录 | | 返回的 IPv6 地址 | `2607:f8b0:4008:80f::200e` | YouTube AAAA 记录 | | 端口 | UDP `53` | DNS 查询和响应流量 | | 协议 | DNS, UDP, IPv4, IPv6 | 调查期间审查的协议 | ## 调查时间线 | 步骤 | 分析师操作 | 结果 | |---|---|---| | 1 | 查看了可用的捕获接口 | 确定 Wi-Fi 为活动接口 | | 2 | 启动了实时捕获 | 确认有数据包正通过接口传输 | | 3 | 应用了 `dns` 显示过滤器 | 将 DNS 流量与其余捕获内容隔离 | | 4 | 运行了 `nslookup youtube.com` | 从 `192.168.1.1` 收到了有效的 IPv4 和 IPv6 结果 | | 5 | 应用了 `dns.qry.name == "youtube.com"` | 隔离了 YouTube 的 DNS 事务 | | 6 | 检查了 A 记录查询和响应 | 验证了 IPv4 答案、TTL、状态和响应时间 | | 7 | 检查了 AAAA 记录响应 | 验证了 IPv6 答案、TTL、状态和响应时间 | | 8 | 检查了 HTTPS 记录响应 | 验证了另一个成功的 DNS 响应 | | 9 | 停止并保存了数据包捕获 | 将调查保存为 `.pcapng` 文件 | | 10 | 审查了证据中是否存在可疑指标 | 未发现 DNS 错误或明显的恶意指标 | ## 证据与分析 ### 证据 01 — Wi-Fi 接口 我打开了 Wireshark 并在开始调查之前审查了可用的接口。Wi-Fi 活动图表显示了实时流量，因此我选择了 Wi-Fi 作为正确的捕获接口。  ### 证据 02 — DNS 捕获开始 我在 Wi-Fi 接口上启动了实时捕获，并确认数据包正在屏幕上移动。我从未过滤的流量开始，以便验证接口是否正常捕获。  ### 证据 03 — DNS 流量过滤器 我输入了以下 Wireshark 显示过滤器来隔离 DNS 流量： ``` dns ``` 绿色的过滤栏确认了过滤器是有效的。Wireshark 随后显示了 DNS 数据包，而数据包列表中不再充满不相关的流量。  ### 证据 04 — YouTube DNS 查找 我使用命令提示符生成了新的 DNS 流量： ``` nslookup youtube.com ``` 该查找从本地 DNS 服务器返回了非权威应答。 | 查找字段 | 观察到的值 | |---|---| | DNS 服务器 | `CR200A.mynetworksettings.com` | | DNS 服务器地址 | `192.168.1.1` | | 请求的域名 | `youtube.com` | | 返回的 IPv4 地址 | `142.251.211.238` | | 返回的 IPv6 地址 | `2607:f8b0:4008:80f::200e` | | 应答类型 | 非权威应答 | 我的第一次尝试包含一个拼写错误：`nslookuo`。命令提示符返回了无法识别的错误。我将命令更正为 `nslookup` 并成功完成了查找。  ### 证据 05 — DNS 查询分析 我使用了以下显示过滤器来隔离与 YouTube 相关的 DNS 流量： ``` dns.qry.name == "youtube.com" ``` 我选择了 A 记录查询并展开了 DNS 查询详细信息。该查询请求与 `youtube.com` 关联的 IPv4 地址。查询从位于 `192.168.1.155` 的 `FrancisHP` 发往位于 `192.168.1.1` 的 DNS 服务器，使用目的端口 `53`。  ### 证据 06 — A 记录响应分析 我选择了匹配的 A 记录响应并展开了其应答详细信息。 | A 记录字段 | 观察到的值 | |---|---| | 响应数据包 | `1353` | | 请求数据包 | `1351` | | 源 | `192.168.1.1` | | 目的地 | `192.168.1.155` | | 源端口 | `53` | | 目的端口 | `50896` | | 事务 ID | `0x9ebe` | | 记录类型 | A | | 类别 | IN | | 返回的 IPv4 地址 | `142.251.211.238` | | TTL | `250 秒` — 4 分钟 10 秒 | | 响应状态 | 无错误 | | 响应时间 | `37.397300 毫秒` | | 返回的应答数 | `1` | 该响应来自源端口 `53` 的 DNS 服务器并返回给 `FrancisHP`。YouTube IP 地址包含在 DNS 应答中；YouTube 并不是该 DNS 响应的来源。  ### 证据 07 — AAAA 记录响应分析 我选择了 AAAA 记录响应并展开了应答详细信息。 | AAAA 记录字段 | 观察到的值 | |---|---| | 响应数据包 | `1354` | | 请求数据包 | `1350` | | 事务 ID | `0x1a59` | | 源端口 | `53` | | 目的端口 | `54666` | | 记录类型 | AAAA (`28`) | | 类别 | IN | | 返回的 IPv6 地址 | `2607:f8b0:4008:80f::200e` | | TTL | `73 秒` — 1 分钟 13 秒 | | 数据长度 | `16 字节` | | 响应状态 | 无错误 | | 响应时间 | `37.198700 毫秒` | AAAA 记录返回了有效的 IPv6 地址。其 TTL 低于 A 记录的 TTL，因此此缓存的应答将更快过期。TTL 并不衡量页面加载速度；它显示了在需要新的查找之前，DNS 应答可以保持缓存的时间。  ### 证据 08 — HTTPS DNS 记录分析 我审查了 `youtube.com` 的一个 HTTPS DNS 记录。这是与 A 和 AAAA 记录不同的独立 DNS 事务。 | HTTPS 记录字段 | 观察到的值 | |---|---| | 记录类型 | HTTPS (`65`) | | TTL | `289 秒` | | 响应状态 | 无错误 | | 响应时间 | `42.829100 毫秒` | 此响应也无错误地完成。其响应时间低于 43 毫秒，没有显示测试期间存在缓慢的 DNS 解析。  ## 调查发现 1. `FrancisHP` 使用了本地 IPv4 地址 `192.168.1.155`。 2. 本地 DNS 解析器是位于 `192.168.1.1` 的 `CR200A.mynetworksettings.com`。 3. DNS 流量使用了 UDP 端口 `53`。 4. A 记录返回了 IPv4 地址 `142.251.211.238`。 5. AAAA 记录返回了 IPv6 地址 `2607:f8b0:4008:80f::200e`。 6. A、AAAA 和 HTTPS 响应均无错误地返回。 7. 观察到的响应时间范围大约在 37 到 43 毫秒之间。 8. TTL 值为 A 记录 `250 秒`，AAAA 记录 `73 秒`，HTTPS 记录 `289 秒`。 9. 响应时间证据不支持关于本次测试期间 DNS 解析缓慢的报告。 10. 在审查的流量中，我没有观察到拼写错误的域名、意外的返回地址、重复失败的查找或其他明显的恶意指标。 ## 分析师评估 DNS 活动表现正常。本地 DNS 服务器为 `youtube.com` 返回了有效的 A、AAAA 和 HTTPS 记录，所有审查的响应均显示无错误状态，且响应时间保持在 43 毫秒以下。 TTL 值是缓存持续时间，而不是网络延迟的衡量标准。根据审查的流量，在此测试期间，DNS 解析似乎不是导致报告的网页加载缓慢的原因。如果用户继续遇到浏览缓慢的问题，将需要进行更广泛的性能调查。 ## 已采取的行动 - 从活动的 Wi-Fi 接口捕获了新的 DNS 流量。 - 对 `youtube.com` 进行了受控的 DNS 查找。 - 使用 Wireshark 显示过滤器隔离了域名流量。 - 将 DNS 查询与匹配的响应进行了比较。 - 审查了 A、AAAA 和 HTTPS 记录的详细信息。 - 记录了返回的地址、TTL 值、响应状态和响应时间。 - 将数据包捕获保留为 `Case File 02 DNS Analysis.pcapng`。 - 记录了命令拼写错误成功的更正。 - 未采取任何遏制行动，因为未发现恶意活动。 - 无需升级。 ## 最终判定 | 关闭字段 | 结果 | |---|---| | 最终判定 | 良性 | | DNS 性能发现 | 测试期间未观察到缓慢的 DNS 响应 | | 安全发现 | 未发现明显的恶意 DNS 活动 | | 遏制 | 无 | | 升级 | 不需要 | | 案件状态 | 已关闭 | ## 案件关闭备注 在审查了保存的数据包捕获和八张辅助屏幕截图后，我将该案件作为良性关闭。证据显示 `youtube.com` 的 DNS 响应成功，耗时约 37-43 毫秒，没有错误。 该测试未重现缓慢的 DNS 解析。如果缓慢的浏览继续存在，下一步将是调查其他可能的原因，例如 Wi-Fi 质量、浏览器性能、系统资源使用情况或与目标服务的连接。

标签：DEF CON 演示, DNS分析, Docker 部署, VX技术, Wireshark, 句柄查看, 系统分析, 网络分析, 网络性能监控, 网络运维