前言
这是一个新的系列文章，作者会四处收录一些来自生产环境的综合案例，案例主体内容是有相对完整攻击链路的恶意通讯数据包（包括主动扫描、暴力破解、漏洞利用、木马通讯等）。并且我会提供案例数据包和恶意数据包分析平台，供读者实践。
读者只需要安装wireshark，配合作者提供的平台就可以完整复现攻击链路。非常适合希望学习恶意数据包分析技术的读者来阅读和实践。
恶意数据包分析平台地址如下，可以先简单看看平台其中包含使用介绍。
分析平台地址：
http://47.108.150.136:8080/IDS/
文章配套案例数据包获取：
https://www.123pan.com/s/3BsPjv-P5hnd.html
背景
往期文章《入侵检测之流量分析–恶意数据包分析平台》详细介绍了分析平台的基本及其使用和检测结果分析，平台是一个基于SURICATA的威胁流量分析WEB应用，后端用基于GO语言的WEB框架GIN编写，我个人维护了包括ET/PRO库在内的8个规则库10万量级的检测规则库，就特征规则来说是企业级的，免费供大家使用（对ET/PRO感兴趣也可以联系我）。
文章内容和思路模拟真实生产环境，在海量通讯流量中，以检测引擎告警信息作为线索出发点，做威胁溯源、扩线，目的是梳理清楚整个攻击链路以及关键技术环节。
附带一个目录，让读者清晰文章结构和思路。
一、告警信息概览
这是经过平台检测并输出的案例数据包的告警信息。
我们在对现有各厂商流量产品做分析时，几乎不能避免会遇到大量的告警信息，如何在大量告警信息中去做有威胁挖掘就比较考研分析人员能力了。
可以自己上案例传数据包分析得到上图中的告警信息。
也可以通过访问此链接直接获取，都阔以。
http://47.108.150.136:8080/uploads/2024-03-14_02-52-43/log/fast.log这是SURICATA原生的告警输出日志，如果感到陌生可以先看一下文章往期《入侵检测之流量分析–恶意数据包分析平台》，后面对此输出格式有详细说明。
二、案例入侵全链路、涉及通讯流量告警分析
这是分析结果，分析受阻或结束可以来对比参考。
使用如下wireshark过滤规则即可看到全流程。
tls.handshake.type eq 1||http.request
2.1 从网站下载恶意资源
受害者访问合法的网站（https://psiewdr.org），但其受到恶意资源污染，被第三方嵌入了软件更新下载提示，并有一个下载链接（retraining.allstardriving.org），下载了恶意的、经过混淆压缩的“.js”文件。
合法但受到第三方嵌入的恶意资源网站如下。（目前已修复）
下载的恶意压缩包解压混淆“.js”文件如下。
2.2 初始恶意载荷执行，下载后Async木马载荷
受害者执行恶意“.js”文件，“.js”经过其复杂的执行逻辑，下载了三个恶意的、经过混淆的powershell脚本文件，陆续下载了包含密文的Async木马本体、持久化程序等恶意载荷。
此流程触发规则告警信息如下。
-
Windows Powershell Request UserAgent，（告警说明：powershell出现在http.user-agent中，表明相关http请求是powerhsell发起的，并非人为访问网站） -
ETPRO ATTACK_RESPONSE Malicious Obfuscated Powershell Loadert，（告警说明：在http响应中匹配到恶意混淆的 Powershell 加载程序。） -
ET DNS Query to a .top domain – Likely Hostile，（告警说明：此域名匹配DNS解析目标顶级域名为“.top”的请求，这是狩猎思路的规则，以往经验此顶级域名的网站常见于搭载恶意载荷。）
2.3 powershell解密码、执行恶意载荷
powershell脚本执行，解密了Async木马本体，并且创建了计划任务做持久化，不涉及通讯流量层面。
2.4 Async木马客户端程序外连C2
Async木马客户端运行，回连木马服务端，Async RAT是开源的远控软件，使用TLS加密流量通讯。
从通讯流量可见，木马客户端与服务端多次完成TLS交互流程，存在多次会话连接。
此流程触发规则告警信息如下。
-
ETPRO JA3 Hash – Suspected ASYNCRAT Server Cert (ja3s)，（告警说明：匹配到确切的Async木马服务端指纹信息，说明存在ASYNCRAT受控行为。） -
ET MALWARE Generic AsyncRAT Style SSL Cert，（告警说明：匹配到AsyncRAT风格的TLS证书字段特征，说明存在ASYNCRAT受控行为）
三、告警数据包定位和研判
现在很多流量产品都有一个问题，就是基于数据包的告警信息，只能通过五元组信息定位到会话，但却不能定位到告警数据包。举一个比较笼统的例子，一个TCP会话由1000个数据包组成，触发告警的数据包是其中1个，对通讯协议和告警原理不太熟悉的人就很难根据告警对数据包做定位和研判。
3.1 HTTP请求中出现Powershell User-Agent
-
定位
按照如下过滤规则和字符搜索即可定位触发告警信息的数据包。
追踪流可以看到HTTP请求中出现Powershell User-Agent
-
研判
内网资产IP 10.2.21.101通过powershell进程对IP 167.71.107.109发起http请求下载资源，人工研判下载的资源为恶意powershell脚本，说明拉起此powershell进程的实体为恶意，内网资产IP 10.2.21.101疑似中下载者木马。
3.2 HTTP响应中出现经过混淆的恶意载荷
-
定位
此条规则稍微复杂一点，实际匹配载荷如下,这是powershell脚本混淆的一些特征。
|20 3d 20|New|2d|Object|20|System|2e|IO|2e|MemoryStream|28 20 2c 20 24|
|20 3d 20|New|2d|Object|20|System|2e|IO|2e|MemoryStream
可以直接依据告警五元组信息去定位会话。
49.13.65.235:80 -> 10.2.21.101:64066
过滤规则
ip.src==49.13.65.235&&tcp.srcport==80&&ip.dst == 10.2.21.101&&tcp.dstport==64066
再追踪此流就可以看到经过混淆的powershell恶意载荷了。
-
研判
通常在互联网中名文传输的经过混淆的脚本类资源，大概率是恶意载荷。内网资产IP 10.2.21.101对外请求恶意载荷，内网资产IP 10.2.21.101疑似中下载者木马。
3.3 检测到到Async RAT的TLS服务端指纹hash值（JA3S）
JA3S、JA3是TLS的一种指纹识别技术，将TLS交互流程基于一系列算法生成的一个唯一的哈希字符串，JA3指纹用于标识特定客户端、JA3S指纹用于标识特定服务端。
-
定位
既然是TLS服务端指纹信息，直接过滤tls交互中的server hello通讯数据包，源IP即服务端。多次会话的话就可能有多个，为了再准确一点你可以加上客户端的端口。
过滤规则：
ip.src==5.161.113.150&&tls.handshake.type == 2&&tcp.dstport==64070
匹配的JA3S指纹如下，如果有兴趣可以找计算方法算一下。
b74704234e6128f33bff9865696e31b3
-
研判
JA3S值作为一种hash值标注了Async RAT远控木马软件的服务端，非常准确。内网资产IP 10.2.21.101外连Async木马控制端IP 5.161.113.150:25658，有确切证据说明内网资产IP 10.2.21.101木马受控行为。
3.4 匹配到Async RAT通用风格的SSL证书
-
定位
此特征Async RAT与Quaser RAT通用，一定程度说明了此两块开源木马的同源性。实际匹配的是证书信息中的一段hex流，如果不知道规则原理简单匹配五元组信息即可定位
hex流
0f 39 39 39 39 31 32 33 31 32 33 35 39 35 39 5a
-
研判
通讯流量中匹配到Async RAT的证书特征，说明存在Async木马通讯流量，内网资产IP 10.2.21.101外连Async木马控制端IP 5.161.113.150:25658。
对这些告警信息做研判分析，从时间维度、恶意资源执行流程等，就可以梳理到完整链路。
感谢靓仔你有耐心读完，这个系列都会以类似方式记录和整理，案例驱动学习是很高效的，如果你觉得有用，点个关注吧~
原文始发于微信公众号（帅仔回忆录）：恶意通讯流量案例分析，恶意下载链路最终导致Async RAT木马受控
