maurynickelson/Wireshark-Traffic-Analysis

# Wireshark 网络流量分析 — Agent Tesla 凭据窃取 ## 目标 在云端托管 Windows VM 上部署并运行 Wireshark，以分析实时网络流量和恶意 PCAP 文件。通过对真实世界 Agent Tesla 信息窃取器感染的实际操作分析，展示在数据包捕获、协议过滤、流量基线建立、IOC 提取和 MITRE ATT&CK 映射方面的熟练程度。 ## 环境 | 组件 | 详情 | |---|| | 平台 | Microsoft Azure | | 虚拟机操作系统 | Windows 11 | | 工具 | Wireshark 4.6.4 | | 恶意 PCAP | 2025-01-31 VIP Recovery Data Exfil over SMTP | | PCAP 来源 | malware-traffic-analysis.net | ## 使用的工具 - Wireshark 4.6.4 - Npcap (数据包捕获驱动程序) - Windows PowerShell (`ipconfig /flushdns`) - nslookup (IP/域名解析) - base64decode.org (凭据解码) ## 实验概述 本实验分为两部分。第 1 部分涵盖 Azure Windows VM 上的实时流量捕获和分析，建立正常网络行为的基线。第 2 部分涵盖对包含已确认 Agent Tesla 凭据窃取器感染的恶意 PCAP 的取证分析，从而生成全套 IOC，供实验 2（事件响应）使用。 ## 第 1 部分 — 实时流量捕获和基线建立 ### 接口选择和捕获 Wireshark 安装在 Azure VM 上，通过查找具有实时活动图表的接口来识别活动的以太网接口。启动了 60 秒的捕获以观察环境流量。 **截图：Wireshark 接口选择**  **截图：实时数据包捕获 — RDP 和 TLS 流量**  初始捕获显示了两个主要 IP：VM 的内部地址 `10.1.0.174` 通过端口 3389 上的 TLSv1.2 与 `67.164.219.149` 通信 — 这是用于连接到 VM 的活动 RDP 会话。 ### DNS 过滤器分析 应用 `dns` 过滤器以隔离 DNS 查询流量。初始结果仅显示 `10.1.0.174` 和 `168.63.129.16`（Azure 的内部 DNS 解析器）之间的 Azure 基础设施查询，查询部分中看不到域名。 **截图：DNS 过滤器 — 初始看不到域名**  **故障排除：** 域名不存在是因为 VM 之前已解析过这些域并缓存了结果。Windows 缓存的 DNS 条目不会生成新查询，因此 Wireshark 没有捕获到任何内容。 **解决方案：** 在 PowerShell 中使用 `ipconfig /flushdns` 清除 DNS 解析器缓存，然后访问新站点以生成新查询。 **截图：DNS 缓存清除确认**  **截图：缓存清除后可见域名的 DNS 查询**  **关键观察：** `168.63.129.16` 是保留的 Microsoft Azure IP，用作所有 Azure VM 的内部 DNS 解析器。发往此 IP 的流量是预期的背景噪声，不是入侵指标。 ### HTTP 过滤器和流分析 应用了 `http` 过滤器，并识别出来自 Azure VM guest agent 的 GET 请求。使用 Follow > TCP Stream，重建了完整的未加密 HTTP 对话，显示 Azure guest agent 回连到 `168.63.129.16` 以 XML 格式检索 VM 配置数据。 **截图：HTTP GET 请求**  **截图：HTTP 流 — Azure guest agent XML 负载**  **关键观察：** 未加密的 HTTP 流量会暴露完整的请求和响应内容，包括标头、参数和响应主体。这种技术 — Follow > TCP Stream — 与第 2 部分中用于从恶意 PCAP 提取凭据的方法相同。 ### TCP 过滤器和 IP 隔离 应用过滤器 `tcp.flags.syn == 1` 以识别 TCP 连接握手。生成到 `github.com` 的浏览器流量以产生外部连接。使用 `nslookup` 解析目标 IP 并使用 `ip.addr ==` 过滤，隔离了到 Akamai CDN (`2.18.67.76`) 的流量，显示端口 443 上的 TLS — 预期的 HTTPS 流量。 **截图：TCP 流量分析 — SYN, SYN-ACK, ACK 序列和 TLS**  **关键观察：** GitHub 通过 Akamai 的 CDN 路由流量，而不是直接解析为 nslookup 返回的 IP。这是一个真实世界的例子，说明为什么基于 IP 的过滤需要 CDN 意识 — 仅 nslookup 结果是不够的。 ### 正常流量基线摘要 | 指标 | 正常值 | 备注 | |---|---|---| | DNS 解析器 | `168.63.129.16` | Azure 内部解析器 — 预期 | | RDP 流量 | `67.164.219.149` 端口 3389 TLSv1.2 | 活动 RDP 会话 | | HTTP | `168.63.129.16` 端口 80 | Azure guest agent 检入 | | HTTPS | 外部 IP 端口 443 TLSv1.3 | 通过 CDN 的浏览器流量 | | 临时端口 | 49152–65535 作为源 | 操作系统分配的正常返回端口 | ## 第 2 部分 — 恶意 PCAP 分析 (Agent Tesla) ### PCAP 概述 | 字段 | 值 | |---|| | 文件 | 2025-01-31-VIP-Recovery-data-exfil-over-SMTP.pcap | | 总数据包 | 426 | | 观察到的协议 | DNS, TCP, HTTP, TLS, SMTP | | 恶意软件家族 | Agent Tesla / VIP Recovery 凭据窃取器 | ### 步骤 1 — 识别受感染主机 使用 `Statistics > Conversations > IPv4` 识别捕获中对话最多的 IP。 `10.1.31.101` 出现在每个对话中，与多个外部 IP 通信 — 确认其为受感染主机。最活跃的外部连接是 `208.91.198.143`，有 210 个数据包和 114KB 传输。 ### 步骤 2 — 追踪窃取通道 通过 `ip.addr == 208.91.198.143` 过滤，显示端口 587 上有大量 SMTP 流量。识别出一个 AUTH 登录数据包，包含 Base64 编码的用户名：`ZGlyZWN0b3JAaWdha3Vpbi5jb20=` 解码后：`director@igakuin.com` 这证实了恶意软件正在向 SMTP 邮件服务器进行身份验证，以通过电子邮件窃取被盗数据。 ### 步骤 3 — 通过 TCP Stream 提取被盗凭据 对 SMTP 数据包使用 Follow > TCP Stream 显示了完整的凭据转储。电子邮件正文采用 Quoted-Printable 格式编码（`=0D=0A` = 换行符）。解码后，电子邮件包含： **电子邮件元数据：** - From: `director@igakuin.com` - To: `director@igakuin.com` (攻击者发送到自己的收件箱) - Subject: `Pc Name: david.miller | / VIP Recovery \` - 受害者主机名: `DESKTOP-WE9H2FM` - 受害者公网 IP: `34.205.4.78` (Ashburn, Virginia, US) **从浏览器保存的密码中窃取的凭据：** | 来源 | 平台 | 用户名 | 密码 | |---|---|---|---| | Google Chrome | Amazon | david.miller@millershomebrew.com | P@ssw0rd1! | | Edge Chromium | LinkedIn | david.miller@millershomebrew.com | P@ssw0rd! | | Edge Chromium | Facebook | 3841584372 | P@ssw0rd! | **攻击者 OPSEC 失误：** 恶意软件未使用 TLS 加密 SMTP 会话，导致完整凭据转储以明文形式暴露。这允许完全了解被窃取的数据。 ### 步骤 4 — 识别辅助 C2 通道 对恶意 PCAP 应用 `dns` 过滤器，显示了对 `api.telegram.org` 的 DNS 查询，解析为 `149.154.167.220`。Telegram 是威胁行为者已知的用于 C2 通信和数据窃取的平台，因为其在网络流量中看似合法，且不太可能被企业防火墙阻止。 **截图：Telegram C2 DNS 查询**  ### 步骤 5 — 表征窃取模式 到 `208.91.198.143` 的 SMTP 连接集中在短时间内，而不是按固定间隔分布。此模式与单次事件凭据窃取一致 — 恶意软件执行，收集所有可用的浏览器保存密码，一次性发送并终止。这与按固定计时器通信的持久信标植入不同。 ## IOC 摘要 | 类型 | 值 | 背景 | |---|---|---| | 受感染主机 IP | `10.1.31.101` | 受害机器的内部 IP | | 受感染主机名 | `DESKTOP-WE9H2FM` | 受害机器名称 | | 受害用户 | `david.miller` | 凭据转储主体 | | 受害者公网 IP | `34.205.4.78` | Ashburn, Virginia | | 窃取目标 IP | `208.91.198.143` | SMTP 邮件服务器 — 主要窃取目的地 | | 窃取端口 | 587 | SMTP 提交 — 未加密 | | 攻击者收件箱 | `director@igakuin.com` | 接收被盗凭据 | | C2 域名 | `api.telegram.org` | 辅助 C2 通道 | | C2 IP | `149.154.167.220` | Telegram API 服务器 | | 恶意软件 | Agent Tesla / VIP Recovery | 浏览器凭据窃取器 | ## MITRE ATT&CK 映射 | 技术 ID | 名称 | 观察到的行为 | |---|---|---| | T1555.003 | Credentials from Web Browsers | 从 Chrome 和 Edge 保存的密码存储中收集密码 | | T1048.003 | Exfiltration Over Unencrypted Non-C2 Protocol | 通过未加密的 SMTP 端口 587 窃取凭据 | | T1071.001 | Application Layer Protocol: Web Protocols | Telegram API 用作辅助 C2 通道 | | T1027 | Obfuscated Files or Information | Base64 编码用于 SMTP AUTH 凭据 | ## 挑战和观察 **DNS 缓存问题：** 初始 DNS 过滤器在查询数据包中未显示域名。根本原因被确定为 Windows DNS 缓存 — 以前解析的域不会生成新查询。通过运行 `ipconfig /flushdns` 并访问新站点解决。这与 SOC 工作相关：缓存的 DNS 意味着受感染的主机可能直接与恶意 IP 通信而不生成 DNS 查询，需要与连接日志进行交叉参考。 **CDN 路由：** 当按 `nslookup github.com` 返回的 IP 进行过滤时，GitHub 流量未出现。浏览器连接到 Akamai CDN 基础设施。这演示了为什么基于 IP 的 IOC 匹配需要 CDN 意识和威胁情报上下文。 **Quoted-Printable 编码：** 凭据转储电子邮件正文使用 Quoted-Printable 编码（`=0D=0A` 表示换行符，`=` 表示行连续）。识别并在脑海中解码这种编码是在 TCP 流中读取被盗凭据所必需的。 **攻击者 OPSEC 失误：** 恶意软件操作员未为 SMTP 窃取通道配置 TLS，导致完整凭据转储对任何网络观察者可见。这是商品恶意软件中的常见错误，也是网络监控能够捕获端点工具遗漏的信息窃取器的关键原因。 ## 展示的技能 `Network Traffic Analysis` `Wireshark` `Packet Capture` `Protocol Filtering` `IOC Extraction` `Credential Exfiltration Detection` `SMTP Analysis` `DNS Analysis` `TCP Stream Reconstruction` `MITRE ATT&CK Mapping` `Threat Hunting` `Traffic Baselining` `Base64 Decoding` `Incident Triage` ## 实验链 — 连接到实验 2 本实验中提取的 IOC 直接输入到实验 2（事件响应模拟）中。受感染主机 (`10.1.31.101`)、窃取目的地 (`208.91.198.143`)、攻击者收箱 (`director@igakuin.com`) 和 Telegram C2 通道 (`api.telegram.org`) 将作为下一个实验中 IR 场景、遏制步骤和补救建议的基础。

标签：Agent Tesla, Azure, Base64解码, Cloudflare, DAST, DNS分析, IOC提取, IP 地址批量处理, MITRE ATT&CK, PCAP分析, RDP流量, SMTP, TLP协议, Windows VM, Wireshark, 信息窃取程序, 包捕获, 协议过滤, 句柄查看, 基线分析, 恶意软件分析, 数据渗出, 红队防御, 网络安全, 隐私保护