IfanClarke1/Malware-PCAP-Analysis
GitHub: IfanClarke1/Malware-PCAP-Analysis
使用 Wireshark 对恶意软件 PCAP 文件进行逐步网络流量取证分析，识别 C2 通信并产出包含 IOC 和修复建议的完整 SOC 报告。
Stars: 0 | Forks: 0
# 恶意软件 PCAP 分析
**概述**
我从 malware-traffic-analysis.net 下载了附件中的 PCAP 并在 Wireshark 中打开它。我的目标是对这个 PCAP 进行分析，看看能从中发现什么。我保留了我所采取的所有步骤，即使有些并没有实质进展，以此来展示我思考和解决问题的过程。
**采取的步骤**
我做的第一件事是转到 Statistics > Endpoints > IPv4，找到了数据包数量最多的 IP 地址，因为这可能是恶意活动的证据。该 IP 地址是 10.2.28.88。
接下来，我想了解这个地址的性质。
然后我使用 Wireshark 搜索了 10.2.28.88，查看涉及该 IP 地址的事件，并弄清楚它到底是什么。
看起来 10.2.28.88 有大量的传入和传出流量，其中大部分是 DNS 协议，因此我将 DNS 添加到过滤器中：'ip.addr == 10.2.28.88 && dns'。
接下来，我开始更深入地查看一些查询。我点击的第一个查询显示如下：
这是一个 DNS 查询。10.2.28.88 可能是某种工作站，而 10.2.28.2 是一个 DNS 服务器。由此我意识到我需要跳过 10.2.28.88 继续往下看——仅仅因为它的数据包传输量最大，并不意味着它在任何形式上是恶意的。
从这里开始，我决定改变我的方法，因为到目前为止我得到的都只是背景噪音。我想查找从内部到外部的流量，因此我进行了这样的过滤：'ip.src == 10.2.28.0/24 && !(ip.dst == 10.2.28.0/24)'。
然后我转到 Statistics > Conversations > IPv4 并按 Bytes 排序，试图寻找可疑的活动。
我发现 150.171.28.11 这个 IP 地址交换了大量的字节，因此决定将其作为下一个调查目标。
我前往 VirusTotal 查询了该 IP 地址，结果显示这是一个由 Microsoft 拥有的、干净的 IP 地址。
接着，我开始逐一排查上面截图列表中的其他外部 IP 地址，下一个地址 (45.131.214.85) 在 VirusTotal 上被 11 家安全厂商标记为可疑，因此我决定将其作为下一个调查目标。
我查看了涉及 45.131.214.85 的 Conversations，发现发送到 45.131.214.85 的数据远多于从它发出的数据，这让我怀疑可能正在发生数据泄露。
接下来，我更详细地查看了涉及 45.131.214.85 的流量。
我按 45.131.214.85 进行了过滤，发现了一些看起来很奇怪的 POST 请求。
根据我的调查，45.131.214.85 是位于荷兰的一个命令与控制服务器。对我来说很明显，45.131.214.85 已经攻陷了 10.2.28.88，并且双方正在进行命令/数据的交互。当我看到往返于 10.2.28.88 的数据包数量时，我的怀疑是正确的，但它是一台被感染的机器，而不是恶意的源头。
从那时起，我的目标是弄清楚它是在何时以及如何被感染的，并尽可能多地获取关于 10.2.28.88 的信息。
首先，我按时间进行了过滤，发现涉及 45.131.214.85 的第一次通信发生在 2026 年 2 月 28 日 19:55:51。发生了一次 TCP 握手，接着是一个 HTTP 请求。当我跟踪这个 HTTP 请求时，我发现了以下内容：
```
POST http://45.131.214.85/fakeurl.htm HTTP/1.1
User-Agent: NetSupport Manager/1.3
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Host: 45.131.214.85
Connection: Keep-Alive
CMD=POLL
INFO=1
ACK=1
```
NetSupport Manager 是一款合法的远程工具，但也可以被用作远控木马来接管系统。我相信这就是攻击者用来接管的工具。
# SOC 报告
**总结**
使用 Wireshark 对一个 PCAP 进行分析，以识别恶意活动。初始分析由于数据包数量较高而集中在 10.2.28.88 上，随后确认其为主机设备。进一步分析发现了通往外部机器 45.131.214.85 的可疑活动，VirusTotal 将其归类为恶意地址。
**发现**
对 IPv4 Conversations 的分析显示，从 10.2.28.88 到 44.131.214.85 有大量的出站流量，引发了对可能存在数据泄露的担忧。对流量的检查发现了指向 ```http://45.131.214.85/fakeurl.htm``` 的 POST 请求。
其中一个请求包含以下信息：
```
POST http://45.131.214.85/fakeurl.htm HTTP/1.1
User-Agent: NetSupport Manager/1.3
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Host: 45.131.214.85
Connection: Keep-Alive
CMD=POLL
INFO=1
ACK=1
```
我研究了 NetSupport Manager，确认它是一款远程管理工具，但经常被威胁行为者滥用。
时间线分析表明，受感染主机与外部地址之间的首次通信发生在 2026 年 2 月 28 日 19:55:51。它以 TCP 握手开始，随后是 HTTP 通信。
**结论**
证据表明，主机 10.2.28.88 已被攻陷，并与 45.131.214.85 建立了通信。45.131.214.85 是位于荷兰的一个与恶意活动相关的命令与控制中心。流量模式和 NetSupport Manager/1.3 的出现表明，攻击者利用 NetSupport 作为 RAT 建立了对系统的远程访问。
**妥协指标 (IOC)**
| 类型 | 值 |
|--------|--------|
| 受感染的主机 | 10.2.28.88 |
| DNS 服务器 | 10.2.28.2 |
| 命令与控制 IP | 45.131.214.85 |
| 协议 | HTTP |
| URI | `/fakeurl.htm` |
| User-Agent | `NetSupport Manager/1.3` |
| 首次观察到的活动 | 28 Feb 2026 19:55:51 |
| 观察到的命令 | `CMD=POLL`, `INFO=1`, `ACK=1` |
**建议**
1. 隔离受感染的主机 —— 将其从网络中移除以防止进一步通信
2. 封禁恶意地址 —— 将恶意 IP 添加到防火墙阻止列表中，并检查是否有其他主机与此 IP 进行过通信
3. 调查持久化机制 —— 在系统中搜索安装项、计划任务等
4. 执行端点修复 —— 运行防病毒扫描并删除恶意文件
5. 重置凭据 —— 更改密码，考虑启用 MFA
接下来，我想了解这个地址的性质。
然后我使用 Wireshark 搜索了 10.2.28.88，查看涉及该 IP 地址的事件，并弄清楚它到底是什么。
看起来 10.2.28.88 有大量的传入和传出流量，其中大部分是 DNS 协议，因此我将 DNS 添加到过滤器中：'ip.addr == 10.2.28.88 && dns'。
接下来，我开始更深入地查看一些查询。我点击的第一个查询显示如下：
这是一个 DNS 查询。10.2.28.88 可能是某种工作站，而 10.2.28.2 是一个 DNS 服务器。由此我意识到我需要跳过 10.2.28.88 继续往下看——仅仅因为它的数据包传输量最大，并不意味着它在任何形式上是恶意的。
从这里开始，我决定改变我的方法，因为到目前为止我得到的都只是背景噪音。我想查找从内部到外部的流量，因此我进行了这样的过滤：'ip.src == 10.2.28.0/24 && !(ip.dst == 10.2.28.0/24)'。
然后我转到 Statistics > Conversations > IPv4 并按 Bytes 排序，试图寻找可疑的活动。
我发现 150.171.28.11 这个 IP 地址交换了大量的字节，因此决定将其作为下一个调查目标。
我前往 VirusTotal 查询了该 IP 地址，结果显示这是一个由 Microsoft 拥有的、干净的 IP 地址。
接着，我开始逐一排查上面截图列表中的其他外部 IP 地址，下一个地址 (45.131.214.85) 在 VirusTotal 上被 11 家安全厂商标记为可疑，因此我决定将其作为下一个调查目标。
我查看了涉及 45.131.214.85 的 Conversations，发现发送到 45.131.214.85 的数据远多于从它发出的数据，这让我怀疑可能正在发生数据泄露。
接下来，我更详细地查看了涉及 45.131.214.85 的流量。
我按 45.131.214.85 进行了过滤，发现了一些看起来很奇怪的 POST 请求。
根据我的调查，45.131.214.85 是位于荷兰的一个命令与控制服务器。对我来说很明显，45.131.214.85 已经攻陷了 10.2.28.88，并且双方正在进行命令/数据的交互。当我看到往返于 10.2.28.88 的数据包数量时，我的怀疑是正确的，但它是一台被感染的机器，而不是恶意的源头。
从那时起，我的目标是弄清楚它是在何时以及如何被感染的，并尽可能多地获取关于 10.2.28.88 的信息。
首先，我按时间进行了过滤，发现涉及 45.131.214.85 的第一次通信发生在 2026 年 2 月 28 日 19:55:51。发生了一次 TCP 握手，接着是一个 HTTP 请求。当我跟踪这个 HTTP 请求时，我发现了以下内容：
```
POST http://45.131.214.85/fakeurl.htm HTTP/1.1
User-Agent: NetSupport Manager/1.3
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Host: 45.131.214.85
Connection: Keep-Alive
CMD=POLL
INFO=1
ACK=1
```
NetSupport Manager 是一款合法的远程工具，但也可以被用作远控木马来接管系统。我相信这就是攻击者用来接管的工具。
# SOC 报告
**总结**
使用 Wireshark 对一个 PCAP 进行分析，以识别恶意活动。初始分析由于数据包数量较高而集中在 10.2.28.88 上，随后确认其为主机设备。进一步分析发现了通往外部机器 45.131.214.85 的可疑活动，VirusTotal 将其归类为恶意地址。
**发现**
对 IPv4 Conversations 的分析显示，从 10.2.28.88 到 44.131.214.85 有大量的出站流量，引发了对可能存在数据泄露的担忧。对流量的检查发现了指向 ```http://45.131.214.85/fakeurl.htm``` 的 POST 请求。
其中一个请求包含以下信息：
```
POST http://45.131.214.85/fakeurl.htm HTTP/1.1
User-Agent: NetSupport Manager/1.3
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Host: 45.131.214.85
Connection: Keep-Alive
CMD=POLL
INFO=1
ACK=1
```
我研究了 NetSupport Manager，确认它是一款远程管理工具，但经常被威胁行为者滥用。
时间线分析表明，受感染主机与外部地址之间的首次通信发生在 2026 年 2 月 28 日 19:55:51。它以 TCP 握手开始，随后是 HTTP 通信。
**结论**
证据表明，主机 10.2.28.88 已被攻陷，并与 45.131.214.85 建立了通信。45.131.214.85 是位于荷兰的一个与恶意活动相关的命令与控制中心。流量模式和 NetSupport Manager/1.3 的出现表明，攻击者利用 NetSupport 作为 RAT 建立了对系统的远程访问。
**妥协指标 (IOC)**
| 类型 | 值 |
|--------|--------|
| 受感染的主机 | 10.2.28.88 |
| DNS 服务器 | 10.2.28.2 |
| 命令与控制 IP | 45.131.214.85 |
| 协议 | HTTP |
| URI | `/fakeurl.htm` |
| User-Agent | `NetSupport Manager/1.3` |
| 首次观察到的活动 | 28 Feb 2026 19:55:51 |
| 观察到的命令 | `CMD=POLL`, `INFO=1`, `ACK=1` |
**建议**
1. 隔离受感染的主机 —— 将其从网络中移除以防止进一步通信
2. 封禁恶意地址 —— 将恶意 IP 添加到防火墙阻止列表中，并检查是否有其他主机与此 IP 进行过通信
3. 调查持久化机制 —— 在系统中搜索安装项、计划任务等
4. 执行端点修复 —— 运行防病毒扫描并删除恶意文件
5. 重置凭据 —— 更改密码，考虑启用 MFA标签：DAST, IP 地址批量处理, PCAP分析, Wireshark, 句柄查看, 恶意软件分析, 网络流量分析