在分析恶意样本时，样本可能包含网络行为，比如样本从C2服务器上请求下载后续病毒文件。所以对于在病毒分析的角度，对恶意流量的分析也是不可避免的。在这里通过恶意流量习题（malware-traffic-analysis）对恶意流量进行入门分析，本次分析：

该习题题目：

翻译下来就是：

你有一个pcap，你需要弄清楚发生了什么。这里发生了什么？

首先，必须列出来自pcap的流量（HTTPGET请求、SSL流量等）。

1. 沙箱分析

将解压的pcap包上传到VT查看分析结果，可以观察到有exploit-kit、malware、shellcode等标签

2. DNS协议分析

将下载好的pcap包解压后使用Wireshark打开后首先看到两条DNS协议报文：

可以观察到DNS协议的下层协议为UDP传输协议，UDP与TCP二者最大区别就是：UDP只管发送，不用考虑是否发送成功；TCP则考虑，在发送失败时进行重发。DNS报文格式如下：

 Wireshark中抓包如下：

 网上关于DNS协议的解析文章很多，比如WireShark实战笔记之DNS协议分析，在这里不做赘述。

3. 回顾HTTP的链接到关闭

向下分析：

在上一篇TCP协议分析中没写到的知识点：

SYN：同步标志

FIN：关闭标志

ACK：响应标志

PSH：DATA传输标志

RST：链接重置标志

Seq：序列号

Ack：确认号

Len：携带数据长度

可以看出HTTP从链接到关闭的全过程：首先进行三次握手（No.3-No.5），随后客户端发起一次TCP请求（实际就是HTTP请求），No.6中的GET请求属于No.5的TCP中，在GET请求中Len=593。

在No.7中，服务器返回一次TCP，其中确认号Ack=594，就是No.6的GET请求Len+1得出的。No.8即为HTTP的响应报文：

在响应报文中自身携带Len=762长度的data。No.9-No.12进行四次挥手：

No.9：客户端在收到HTTP响应数据后，发送一个关闭请求，其中序列号Seq=594，确认号Ack=服务器之前返回的（No.8）Len+1 = 763；

No.10：服务器发送Seq=763、Ack=服务端之前返回的（No.9）Seq+1 = 595 的确认关闭包；

No.11：服务器再发送一次关闭连接的包；

No.12：最后客户端发送一个Seq=595、Ack=764的确认包。

至此，一次HTTP结束。实际上HTTP就是被封装在一次TCP中，因此可以看出TCP协议主要是用于链接通信过程（传输层协议），而发送的数据主要被封装在HTTP协议中，便于客户端和服务器打包和解析（应用层协议）。

4. HTTP中的恶意行为分析

大部分恶意软件以及C2服务器多使用HTTP流量交互，因此在手动流量包分析时，可以先从HTTP流量行为分析入手，在Wireshark中过滤响应报文http.response：

在这里仅分析恶意服务返回的数据报文里面是否携带相关恶意代码，由此尝试有没有恶意的js代码。在上图结果选中第一行，右键追踪HTTP流：

可以发现其创造了一个flash object、iframe同时设置了一个恶意src，继续分析下一行响应报文，可以观察出一个flash：

将包含flash的响应报文导出：

上传到VT查看结果：

能够看到CVE-2015-0311漏洞的标签，该漏洞为Adobe Flash Player拒绝服务漏洞，关于该漏洞的分析：Flash严重漏洞（CVE-2015-0311）详细技术分析。这里不再对漏洞进行赘述，继续分析下一行响应报文：

这里我们已经拿到了恶意请求的参数，继续追踪一下以b51开头的参数：

在第四行发现该响应报文的请求RUI为....b51，继续分析该行的HTTP流：

可知该响应报文携带一个PE文件，提取出并上传VT分析：

对于携带的PE文件在这里不作为分析重点。

5. HTTP恶意行为总结

上述分析过程中，可以简单总结出一些规律，提取出恶意HTTP行为的特征：

1. 奇怪的URL，但并不是所有这些URL都指向恶意站点，我们可以使用微步、VT等对URL进行查询；

2. 响应返回数据里携带的恶意参数，如恶意js脚本、恶意文件等。

参考

https://www.anquanke.com/post/id/200312#h2-1

教你学木马攻防 | 隧道木马 | DNS反弹shell