在分析恶意样本时,样本可能包含网络行为,比如样本从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脚本、恶意文件等。