wireshark 导出二进制文件_使用 Wireshark 完整分析最新的Ursnif恶意软件

Ursnif是一种银行恶意软件，有时也称为Gozi或IFSB ，Ursnif恶意软件家族已经活跃了很多年。

本文将回顾使用Wireshark捕获Ursnif流量的数据包捕获(pcaps)，在检测和调查Ursnif感染时，了解新的流量模式对于安全专业人员至关重要。

   Ursnif分配方法

Ursnif可以通过基于Web的感染链和恶意垃圾邮件(malspam)进行传播，在某些情况下，Ursnif是由不同的恶意软件家族(如Hancitor)引起的后续感染。

我们经常在基于垃圾邮件的传播活动中找到Ursnif的示例，例如图1中的示例：

最常见传播流程图

   Ursnif流量的类别

本文涵盖了两类Ursnif感染流量：

1. 没有HTTPS感染后流量的Ursnif；

2. 具有HTTPS感染后流量的Ursnif。

来自这两个类别的恶意软件样本在受感染的Windows主机上创建了相同类型的对象，例如，这两种类型的Ursnif通过更新Windows注册表在Windows主机上保持持久性，如图2所示：

由Ursnif样本引起的Windows注册表更新示例，无论是否使用HTTPS后感染流量

   示例1：没有HTTPS的Ursnif

本文的第一个pcap是 Ursnif-traffic-example-1.pcap，你可以点此https://www.malware-traffic-analysis.net/training/examining-ursnif.html下载。在Wireshark中打开pcap，然后对http.request进行过滤，如图3所示：

在此示例中，受Ursnif感染的主机使用各种以.at结尾的域名在 8.208.24[.]139 中生成流量。此类Ursnif导致以下流量：

1. 由最初的Ursnif二进制文件引起的HTTP GET请求；

2. 后续数据的HTTP GET请求，URL以.dat结尾；

3. Ursnif之后在Windows注册表中持续存在的HTTP GET和POST请求。

在我们的第一个示例中，在流量期间使用了以下HTTP数据：

1. 初始GET请求的域：w8.wensa[.]at；

2. 请求后续数据：hxxp://api2.casys[.]at/jvassets/xI/t64.dat；

3. 在Ursnif持久化后用于获取和发布请求的域：h1.wensa[.]at。

在20:13:09 UTC跟随TCP流进行第一个HTTP GET请求，TCP流窗口显示完整的URL。请注意，GET请求如何以/ api1 /开头，后跟一长串带反斜杠和下划线的字母数字字符。图4突出显示了GET请求。

由我们的第一个Ursnif示例引起的HTTP GET请求示例

我们可以从2019年12月10日的Hancitor感染引起的Ursnif活动中找到相同的模式，此pcap可以点击这里https://www.malware-traffic-analysis.net/2019/12/10/index.html下载。12月10日的示例与其他恶意软件活动混合在一起，包含有关Ursnif的以下指标：

1. 用于初始GET请求的域：foo.fulldin[.]at；

2. 要求提供后续数据：hxxp://one.ahah100[.]at/jvassets/o1/s64.dat；

3. Ursnif之后用于GET和POST请求的域是持久的：api.ahah100[.]at。

请注意，12月10日示例中来自Ursnif流量的模式与我们在示例1中发现的模式如何相似。这些模式通常可以从不使用HTTPS流量的Ursnif样本中看到。

示例2：带有HTTPS的Ursnif

本文的第二个pcap是 Ursnif-traffic-example-2.pcap，你可以点此下载。第二个pcap与第一个pcap一样。

如图5所示，在Wireshark中打开pcap并在http.request或ssl.handshake.type == 1上进行过滤。如果使用的是Wireshark 3.0或更高版本，则对http.request或tls.handshake.type == 1进行过滤，以表示正确的结果。

第二个示例的pcap在Wireshark中过滤

本示例具有以下事件序列：

1. 返回初始Ursnif二进制文件的HTTP GET请求；

2. 由初始Ursnif二进制文件引起的HTTP GET请求；

3. Ursnif之后的HTTPS流量在Windows注册表中保持不变。

按照TCP流对ghinatronx[.]com的第一个HTTP GET请求，该TCP流显示了Windows可执行文件或DLL文件，如图6所示。我们可以按照上一文中的说明从pcap导出Ursnif二进制文件。

第一个HTTP GET请求返回Ursnif的二进制文件

接下来的四个对bjanicki[.]com 的HTTP请求是由Ursnif二进制文件引起的，在18:46:21 UTC，这些请求向bjanicki[.]com 发送第一个HTTP GET请求。此TCP流显示完整的URL，请注意，GET请求如何以/ images /开头，后跟一串长字母数字字符，带有反斜杠和下划线，然后以.avi结尾。此网址格式与我们第一个pcap中的Ursnif流量有些相似。图7突出显示了来自第二个pcap的GET请求。

第二个Ursnif示例中的HTTP GET请求示例

与我们的第一个示例不同，Ursnif在第二个pcap中在被感染的Windows主机上变得持久后会生成HTTPS流量。使用前文所述的基本Web过滤器可以快速查看HTTPS流量。注意一下 prodrigo29lbkf20[.]com 的HTTPS流量，如图8所示：

在Wireshark中过滤Web流量，突出显示Ursnif生成的HTTPS流量

此Ursnif变体生成的HTTPS流量揭示了用于建立加密流量的证书中的独特特征，为了更仔细地观察，请对ssl.handshake.type == 11(或在Wireshark 3.0或更高版本中为tls.handshake.type == 11)进行过滤。选择结果中的第一框架，然后转到框架详细信息窗口。此时，我们可以扩展行并以自己的方式处理证书颁发者数据。

查找证书颁发者数据的方法

如图9所示，我们在框架详细信息窗口中展开“安全套接字层”的行。对于Wireshark 3.0，此行显示为传输层安全性。然后，我们扩展标记TLSv1.2 Record Layer: Handshake Protocol: Certificate。最后，我们再次扩展标记 Handshake Protocol: Certificate。

我们一直在扩展，直到找到通往证书颁发者数据的方式为止，如图10所示：

来自Ursnif导致的HTTPS流量中的证书颁发者数据

在“Handshake Protocol: Certificate ”行下显示的图10中，我们逐步完成以下各项：

1. 证书(615字节)；

2. 证书：30820260308201c9a003020102020900c692c94106d77dfc ...；

3. 签名证书；

4. 发布者：rdnSequence (6)；

5. rdnSequence: 6 items (id-at-commonName=*,id-at-organizationalUnitN…；

rdnSequence行下的各个项目显示证书颁发者的属性，这些特点包括：

countryName = XX 

stateOrProvinceName = 1 

localityName = 1 

OrganizationName = 1 

organizationUnitName = 1 

commonName = *。

这个发布者的数据是无效的，这些模式在Ursnif感染中很常见。但是合法的证书数据是什么样的呢?图11显示了来自DigiCert颁发的证书的有效数据。

有效的证书颁发者数据

关于Ursnif的最后一件事是由受Ursnif感染的主机检查IP地址，这是通过DNS使用opendns[.]com上的解析器进行的。与其他IP地址标识符一样，这是一项合法服务。但是，这些服务通常被恶意软件使用。

要查看此IP地址检查，请对dns.qry.name进行过滤，其中包含opendns.com并查看结果，如图12所示：

由受Ursnif感染的Windows主机检查IP地址

如图12所示，Window主机生成了对resolver1.opendns[.]com 的dns查询，然后是对myip.opendns [.] com的208.67.222 [.] 222的DNS查询。对myip.opendns [.] com的DNS查询返回了受感染Windows主机的公共IP地址。

示例3：带有后续恶意软件的Ursnif

我们的第三个pcap 是Ursnif-traffic-example-3.pcap，可点此https://www.malware-traffic-analysis.net/training/examining-ursnif.html下载。这个pcap也从流量中剥离了无关的活动，但是它建立在我们的上一个示例的基础上。我们的第三个pcap包括看似诱骗的流量，还包括针对后续恶意软件的HTTP GET请求。事件顺序为：

1. 返回初始Ursnif二进制文件的HTTP GET请求；

2. 由最初的Ursnif二进制文件(包括诱骗URL)引起的HTTP GET请求；

3. Windows注册表中Ursnif之后的HTTPS流量持续存在；

4. 后续恶意软件的HTTP GET请求。

使用上文中描述的基本Web过滤器，可以快速查看基于Web的流量，如图13所示：

在Wireshark中过滤第三个pcap后的Web流量。

在图13中，对sinicaleer [.] com的初始HTTP请求返回了Ursnif的Windows可执行文件。图13中可见的剩余流量是由Ursnif可执行文件引起的，直到它变得持久为止。

对google [.] com的三个HTTP请求都遵循与Ursnif流量相似的URL模式，即与ghdy656262oe [.] com的实际恶意域的流量。这些对google [.] com的HTTP GET请求似乎是诱饵流量，因为它们无法帮助感染。通过TCP端口443到gmail [.] com和www.google [.] com的HTTPS流量也没有直接的感染目的，该活动也可以归类为诱骗流量。图14显示了对google [.] com的诱骗HTTP GET请求的示例。

受Ursnif感染的主机向谷歌域发出HTTP GET请求

请注意ghdy656262oe [.] com的HTTP流量，对ghdy656262oe [.] com的前两个GET请求返回404 Not Found响应，如图15所示。第三个HTTP GET请求返回200 OK响应，并且感染继续，如图16所示：

对恶意Ursnif域的前两个HTTP GET请求返回404 Not Found响应

在Ursnif感染继续之前，就已经出现错误运行了

由于对ghdy656262oe [.] com的第一个HTTP GET请求不是200 OK，因此受感染的Windows主机循环遍历其他恶意域以继续感染。这两个域是tnzf3380au [.] top和xijamaalj [.] com。但是，针对这些域的DNS查询返回“ No such name”(无此名称)作为响应，因此受感染的Windows主机又返回尝试ghdy656262oe [.] com。

使用以下Wireshark筛选器可以更好地查看此事件序列：

((http.request or http.response) and ip.addr eq 194.1.236.191) or dns.qry.name contains tnzf3380au or dns.qry.name contains xijamaalj

结果应该类似于图17中显示的列：

过滤以显示受感染的Windows主机如何在HTTP流量达到200 OK之前尝试与Ursnif相关的域

要查看感染的其余部分，请使用基本的web过滤器并滚动到结果的最后，图18显示了Ursnif变为持续性感染后的流量。

Ursnif在受害者的Windows主机上持续存在后的感染后流量

在图18中，在对ghdy656262oe [.] com进行了五个HTTP GET请求之后，我们发现在Ursnif变得持久之后，被感染的Windows主机生成的流量。这包括到google [.] com和gmail [.] com的HTTPS流量。

到vnt69tnjacynthe [.] com的流量应与我们在第二个pcap中看到的类型相同的证书颁发者数据。但是，此流量包括对以.rar结尾的carresqautomotive [.] com的HTTP GET请求。

以.rar结尾的URL返回了后续恶意软件，然而，这个后续的恶意软件在通过网络发送时被编码或以其他方式加密。在受感染的Windows主机上解码的二进制文件，在感染流量中看不到。按照TCP流对carresqautomotive [.] com的HTTP GET请求进行操作，你应该看到与图19相同的数据。

发送到受Ursnif感染的Windows主机的后续恶意软件。

由于此数据已加密，因此我们无法从pcap导出后续恶意软件的副本。因此，我们必须依靠其他感染后流量来确定将哪种类型的恶意软件发送给受Ursnif感染的主机。

我们已经看到来自Ursnif感染的各种后续恶意软件，包括Dridex，IcedID，Nymain，Pushdo和Trickbot。

示例4：用Dridex感染Ursnif

第四个pcap 是Ursnif-traffic-example-4.pcap，你可以点此https://www.malware-traffic-analysis.net/training/examining-ursnif.html了解。与前三个示例不同，此pcap不会从流量中剥离无关的活动。

使用基本的Web过滤器可以更好地了解流量，结果应类似于图20。

来自第四个pcap的流量在Wireshark中进行了过滤

这个pcap的事件序列与我们之前的示例相同，但是它增加了后续恶意软件的感染后活动：

1. 返回初始Ursnif二进制文件的HTTP GET请求；

2. 由最初的Ursnif二进制文件(包括诱骗URL)引起的HTTP GET请求；

3. Windows注册表中Ursnif之后的HTTPS流量持续存在；

4. 后续恶意软件的HTTP GET请求；

5. 后续恶意软件的感染后活动。

在第四个示例中，初始Ursnif二进制文件的HTTP GET请求是oklogallem [.] com。在感染持续存在之前，Ursnif导致对kh2714ldb [.] com的HTTP GET请求。

图21显示了Ursnif持久后的活动，其中Ursnif导致到s9971kbjjessie [.] com的HTTPS流量。然后，我们看到对startuptshirt [.] my的HTTP GET请求，以获取后续恶意软件。最后，我们发现了由后续恶意软件引起的感染后流量。

Ursnif感染后的活动持续存在

第四个示例遵循与第三个pcap相同的感染模式，但是现在我们还具有到94.140.114 [.] 6和5.61.34 [.] 51的HTTPS / SSL / TLS流量，而没有任何关联的域名。Dridex的证书颁发者数据与Ursnif的证书颁发者数据不同。使用以下过滤器来查看我们的第四个pcap中的Dridex证书数据：

(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and ssl.handshake.type eq 11

注意：如果使用的是Wireshark 3.0或更高版本，请使用tls.handshake.type而不是ssl.handshake.type。

选择结果中的第一框架，转到框架详细信息窗口，并展开与证书相关的行，如图9和10中的第二个示例所示。从我们的第四个pcap中检查证书颁发者数据应类似于图22和23。

在Dridex流量中处理证书颁发者数据的方式

从一个Dridex IP地址获取证书颁发者数据

在rdnSequence行下，我们找到证书颁发者的属性。以下是94.140.114 [.] 6的HTTPS / SSL / TLS流量的证书颁发者特征：

· countryName=NP

· localityName=Kathmandu

· organizationName=Buvecoww Fftaites O.V.E.E.

· organizationalUnitName=Olfo Dusar Latha

· commonName=ndltman-dsamutb.spiegel

证书颁发者数据是不同于5.61.34 [.] 51的，但是它遵循以下方式：

· countryName=MU

· localityName=Port Louis

· organizationName=Ppoffi Sourinop Cooperative

· organizationalUnitName=ipeepstha and thicioi

· commonName=plledsaprell.Byargt9wailen.voting

对于Dridex感染后流量，通常会看到这种类型的颁发者数据。在我们的下一个示例中，你可以进一步练习查看Dridex的证书颁发者数据。

注：本文翻译自：https://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/