2021Datacon_Polaris_wp

流量赛道考察数据分析、流量分析、机器学习。

2021年的题目设计包括Cobalt Strike流量分析（TeamServer特征、命令特征）和代理识别（代理app与隧道网页）两个方面。

一、恶意流量分析

题目描述为：

给出hint为：

整体的解题思路：

0．流量数据筛选

给定pcap包的时间跨度为40分钟，统计得到TCP流为11957条，服务端提供通信的端口为：80、443。对服务内容进行聚类得到两大类通信行为，一类是走http的门户网站浏览，一类是CDN资源请求。因此希望从网络行为的角度，识别通信过程中的恶意流量。

参考提示，从题目给的stage1.pcap中筛选可疑流量。

1．恶意域名提取

最简单的可疑流量筛选手段是看访问频率，统计失陷主机的请求域名（client_hello报文）统计如下：

由于加密流量载荷不可读的特点，，无法直接发现隐藏在正常域名后的可疑通信。访问频率高的10个域名为常用域名，优先关注可疑域名d28e，其所在的二级域cloudfront是CDN服务提供商，可能被攻击者用于隐藏与反溯源。跟进发现与d28e 域名的通信存在可疑的心跳行为，心跳间隔为45s：

结合题目描述，猜测d28e可能是Cobalt Strike渗透框架的TeamServer服务器。CS框架中，失陷主机上的Stager会向CS Server上的一个路径发起请求，拉取一个被称为Beacon的后续样本。

提取流量数据中与CloudFront建连的通信域：

d3noow75xz96w4.cloudfront.net
d2lj8kjjwt8rn6.cloudfront.net
d32jqjeqo1vb2n.cloudfront.net
d28ef1bm70qsi.cloudfront.net
dku6bh98adktv.cloudfront.net
d2og948cy5uxtu.cloudfront.net
d1yr5tm734gi1r.cloudfront.net

通过Beacon扫描脚本grab_beacon_config.nse，对可疑主机的80、443端口进行beacon探测，结果如下：

[*].cloudfront.net的beacon扫描结果与正常域名的区别明显：

确定[*].cloudfront.com为恶意通信域名。

2. 获取Beacon

检索相关资料得到：为了规避侦测，红队往往会对CS采用一些隐匿手段，常见方式有云函数和CDN等。这些隐匿手段隐匿了CS的真实IP。以Stager型Beacon为例，CS的上线流程如下图所示：

其中红框部分是受控主机在Exploit阶段后已被注入了Stage，Stage会向CS Server上一个符合checksum8规则的路径发起请求，Server随后会响应Beacon内容，Stage拉取该后续样本后解密并解析Beacon配置信息。

访问符合校验和路径的URL下载攻击者放置在CDN节点上的Beacon文件：

解析Beacon文件获取Profile内容，在C2Server字段得到key1：

3．彩蛋

从除d32jqjeqo1vb2n.cloudfront.net外6个可疑域名下载的样本均解析成功，部分样本C2Server字段填充为: this.is.the.fake.c2.XD,/jquery-3.3.1.min.js，唯独该样本解析失败。猜测该样本在构造时使用了自定义配置，导致样本解析出错。

单独对d32j下载的样本进行分析。经比较发现，正常样本中存在大量0x2E的padding字符，而该解析异常样本相同偏移位置的padding是0x28。

结合搜索引擎：

修改stager异或密钥是Beacon staging server去特征的一种方法，而0x2E是默认配置信息的xor密钥，分析得该样本的xor密钥改为了0x28。对d32jqjeqo1vb2n_x86样本进行全局xor，得到彩蛋， Bingo!

4. 总结

彩蛋环节需要关注报错和细心，一开始解析beacon发现有报错的时候，我们以为就是坏了。其他样本可以得到输出，就没有深入研究。打开解析失败的样本内容，会发现与可解析样本存在差异，把这个差异原因搞清楚了彩蛋就出来了。
是C2服务端的攻防：后门C2是如果不考虑操作安全性，随意使用长连接直连服务器，很容易就被追踪发现。于是出现了Beacon（信标）后门，它是以定期发送信标到C2服务器获取指令的方式进行命令控制。提起Beacon大家大多都想到的是Cobalt Strike，但其实Beacon后门的技术细节可能不是Cobalt Strike原创，CIA可能才是鼻祖。从CIA泄漏的资料可以发现，他们研发的后门几乎都使用了Beacon标准。

这道题对于实际应用的启发在于，怎样从大流量中快速的进行白流量筛选，这是一个值得研究的课题；同时，有些样本为了隐藏心跳行为，可能会引入抖动，恶意心跳行为的发现，对于自动识别可疑流量也是十分有价值的。

二、攻击指令识别

0．题目解读

HTTP、DNS、HTTPS三题，都需解决pcap包中流量与指令序列的映射问题。

1. C2通信特征

观察Beacon与Teamserver的通信特征，由于失陷主机与攻击者间通过 CS TeamServer间接通信，因此CS的命令控制信道中，存在心跳请求、拉取指令和回传响应的通信模式。如图所示是Beacon与Teamserver的通信特征，可以直观的看到Server下发任务，获取失陷主机POST响应的通信行为。

2. HTTP 指令隧道

在CS通信特征调研的过程中，发现HTTP指令流量中Referer字段为http://code.jquery.com：

据此推断攻击者在借助Cobalt Strike的Malleable-C2-Profiles配置文件自定义通信流量，来对抗流量检测。攻击者通过加载定制的配置文件（如此处使用到的jquery.profile模板）来改变目标主机与Server端的流量特征，将通信流量伪装、混淆成正常通信。

HTTP隧道的控制命令隐藏在JS脚本中的P变量，回传响应通过POST数据。

其中sleep指令的特征为：经过sleep秒数后会发起心跳GET请求。此图sleep时长为10s：

根据待识别指令的流量中，统计变量P字节与POST包载荷长度的分布，最终可以得到心跳包+50条指令与序列。

3. DNS 指令隧道

DNS指令的流量特征表现在TXT记录响应和带POST的A记录请求中，其中其中TXT记录是失陷主机拉取TeamServer上的指令后，服务端下发的命令；而失陷主机带POST的A记录请求，是命令执行后的回传信息。其中存在的上下行包分布统计如下图。统计待识别流量最后只得到48个指令，还需要根据心跳间隔的变化加入两个sleep指令。

4. HTTPS 指令隧道

HTTPS指令隧道上，失陷主机与beacon通过TLS会话进行加密通信，其指令的流量特征集中表现在上下行包的载荷长度上，具有下发指令(特定TLS载荷长)-应答(特定范围TLS载荷长)的字节分布特征，其分布如下图所示：

下图是File、Shell上下行载荷长手稿：

三、代理隧道分类

阶段一是代理隧道的软件分类，通过强特征形成代理软件的分类树，阶段二是隧道网页的识别，通过流量表征和网站访问行为形成多分类器模型。

0. 代理隧道识别任务概述

该任务旨在对11类加密代理流量进行分类。通过分析每一类有限的流量样本，统计样本的静态特征与时空特征，总结出每一类样本的匹配规则。然后设计了一种基于树模型的推导算法（强特征推理树），将多分类任务具体分解为多个二分类任务，最后将每一个测试样本归类到某个具体的类别上。推理树的每一个二叉结点都具有将当前类别二分类的强特征规则，因此该算法能够同时具有高准确度与高运行效率。

下面介绍该方法的分析步骤与推导算法的具体实现。

1. 代理隧道特征分析

1.1 协议总体分析

首先，我们分别对11类样本的高层通信协议进行了分析。如图 1所示，我们分析了每一类样本的协议组成，分别计数了UDP，TCP与TLS包的数量。可以看到，0,6,8类样本包含了UDP包，其中0,8类样本只包含了UDP包。同时1,2,3,6,10类样本包含了同时包含TCP与TLS包，4,5,7,9只包含了TCP包，并没有包含TLS包。

11种不同的代理软件分别通过UDP、标准TLS加密协议以及私有加密协议进行隧道通信。11类样本的通信协议分布如下图：

1.2 UDP-based流量分析

分析通过UDP进行隧道通信的样本流量（0,6,8类样本）。在图 2中，我们展示了这三类样本基于UDP协议的应用层协议。其中，0类样本无法识别具体的应用层协议，判断为UDP私有协议通信。6样本具有少量的OCSP包。8样本的UDP载荷为WireGuard包，该样本通过该协议进行隧道通信。UDP通信样本类别的协议如下图：

1.3 TCP-based流量分析

分析基于TCP的样本流量数据。由之前的分析可知，基于TCP的通信流量基本分为两类——TLS标准加密通信与TCP私有协议加密通信。分别对应1,2,3,10类样本与4,5,7,9类样本。

1.3.1 TCP-based TLS流量分析

对基于TLS标准加密通信的流量数据进行分析。图3展示了1,2,3,10类样本的TLS版本包含情况。可以看到，所有的类别的通信都使用TLS1.2进行加密通信，但其中包含的TLS通信包数量比例不尽相同。类别1的TLS数据包占比比较高。TLS版本分布如下图：

统计流量样本中的握手信息。Client Hello数量纬度上，1类样本中不存在Client Hello报文。2,3,10类中均存在Client Hello包。Client Hello包长统计分布如下图：

统计剩余三类样本的Client Hello的包长，按顺序分别为类别2,3,10。发现，三类样本类间包长不同，且类内包长十分统一。2的Client Hello长度为334，3为330，10为571。

1.3.2 TCP-based 私有协议分析

在流量数据中只存在TCP流量包，而不能识别出具体应用层协议的流量样本类别，推断为私有协议加密的流量（4,5,7,9）。

首先，分析了这四类中TCP通信错误包的占比。如下图所示，分析TCP错误包与TCP控制包的占比（错误ACK序列号的响应包数量）。其中，类别4的样本包含了大量的Bad ACK包，而其他类别几乎不含此类通信包，因此可将其视为该类别的强特征。

对于类别5,7,9三类流量数据分析训练数据中的包长分布。下图从左到右依次为类别5,7,9。其中类别5的包长度基本小于1000，集中于300以下，类别7的最大包长为1514，类别9的最大包长为1478。

以上总结出每一个类的强特征规则，接下来介绍强特征推理算法。

1.4 基于强特征的推理树

我们设计了一种针对于该多分类任务的推理算法，将11类分类问题转化为多个二分类任务。每次二分类中，使用一组强特征规则，将类别划分为两种不同的子类。推理树算法的总体流程如下图所示。

Step1 ：首先将总类别划分为两种子类，基于UDP的流量样本与基于TCP的流量样本，在该步骤中，提取每一个PCAP中每一个分组的传输层协议，基于UDP的划分为0,6,8三个子类，基于TCP的划分为1,2,3,4,5,7,9,10八个子类。

Step2 ：对于 UDP-based 的流量数据，判断其具体的UDP载荷协议。具有WireGuard协议的通信，判定为0类通信软件产生的流量；包含OCSP协议的通信，为6类通信软件产生的流量；未能识别具体载荷协议的判定为8。

Step3 ：对于 TCP-based 的流量数据，进一步分为两大子类。通过分析PCAP中的通信协议，将包含了TLS标准加密的PCAP划分到TLS-based的子类中，将只包含TCP包的PCAP划分到私有协议的子类中。

Step4 ：对于 TLS-based 的标准协议流量，进一步使用强特征归类。在此，统计Client Hello的数量与包长度分布。不具有该类流量包的PCAP认为是1类通信软件产生的。Client Hello包长度大多为334的PCAP认为是2类通信软件产生的，同样的道理，330认为是3类软件产生的，571认为是10类软件产生的。

Step5 ：对于 私有协议加密 的通信流量，首先计算PCAP中Bad TCP包数量的占比，占比高于30%的PCAP，认为是4类通信软件产生的。剩下的流量归类到5,7,9的子类中。

Step6 ：提取包中 最大包长的分布 。对于最大包长集中在1478以下的PCAP，认为是5类通信软件产生的，最大包长大多为1478的，是7类软件产生的，1514的，认为是9类软件产生的。

2. 代理隧道识别总结

强特征的提取是代理软件识别任务的关键，在合适的推理算法下，可以克服训练样本不足的缺点，从而达到高识别率。我们分析了每一个类的强特征，把强特征应用于推理树，将多分类问题转化为更精准的多个二分类任务，获得了较好的分类效果。

3. 隧道网页识别任务概述

加密代理识别的第二阶段，需要分类100个网站的代理流量，首先联想到的是网站指纹，其次是通过流级统计特征去做多分类。网站内容的业务资源的差异会带来传递载荷的区别，这个资源传输量可以构成网页访问的基本指纹，相似的数据量序列可以作为识别网页访问行为的基准。

其中，每一个网站给出的样本不算太多，因此如何从少量样本中学习到正确的特征分布是该分类任务的关键点。借鉴集成学习的思想，提出了一种数据增强的方法，迭代拓展数据集，不断提高模型的泛化能力。使用流统计特征作为流量的表征方法，进一步分析了统计特征的重要程度，并且使用更重要的特征作为流量数据的更优表征形式，进一步提高模型的准确率。

4. 隧道网页流量表征

4.1 表征方法的考虑

机器学习方法与输入特征的选择高度相关，此外，数据集的大小也影响模型的选择。例如，当数据集很小的时候，深度学习方法是不合适的。常用的输入特征和相应的训练模型如下：

时间序列+报头

由于时间序列特性几乎不受加密的影响，因此被广泛应用于各种应用程序和数据集。前几个包(从10到30个包)足以在许多数据集中进行分类，经典的ML算法和MLP模型在表示输入维数的包数较小时表现得很好，对于数量较大的数据包，CNN和LSTM更准确。一般来说，深度模型的计算复杂度和训练时间都高于经典的机器学习算法。

Payload+报头

在当前加密流量中，包含握手信息的前几个数据包通常是未加密的，并且已经成功地用于分类。由于输入的高维性(负载中有大量字节)，传统的ML方法和MLP可能并不能很好地工作，但是通常CNN或LSTM却具有高精度。除了有效负载信息外，时间序列特性也有助于提高精度，但这几乎不会改变输入维度或模型的选择。

统计特征

如数据包的包长、时间间隔等，利用统计特征作为输入的维度是有限的，大多使用经典的ML方法，在极少数情况下也使用MLP来实现。一般来说，根据数据集和统计特征的选择，利用前10到180个数据包的统计特征可能就足以进行分类。虽然统计特征可以让我们基于经典的机器学习算法构建一个更简单的分类器，但它可能不适合在线快速分类，因为它需要捕获足够多的数据包才能从流中获得可靠的统计特征。

综上，方案以通信流为基本单位，提取了PCAP中每一个流的统计特征，这些统计特征大致包含每个流的最大包长，最小包长，平均包长，包间隔时间等静态特征。初始的流量表征中一共为80维的静态特征。由于过于高维的表征形式会使得模型的泛化能力不足（高维稀疏特征会产生Outlier），因此需要分析每一维特征的重要系数，筛选重要的特征重组流表征向量，以获得更好的泛化能力。

4.2 特征筛选

初版使用朴素的Random Forest与Decision Tree进行预训练，得到初始模型，然后，计算每一维特征的重要系数。如图所示，随机森林和决策树得出的重要系数排名中，前20位具有很高的重合率，雷达图中也能很好地反映了这一点。将其交集的前20维特征独立出来，重构流的表征向量。

重要系数排名：

重要系数分布雷达图：

4.3 基于集成学习的数据增强方法

为了解决数据样本不足的问题，我们使用集成学习的方法，迭代增强数据，并且预测数据的正确标签，在实际实施上，该方法取得了不错的分数。模型的大致方法如下，对于初始化的集成模型（集成模型由多个若分类器组成），我们进行迭代训练与预测，得到的每一个分类器的预测集合后，我们将具有共同预测标签的，具有较高置信度的测试样本（共性样本）加入到训练数据库中，增强训练样本后继续训练集成模型，最终达到预测所有待测样本的目标。

5. 模型与增强训练

5.1 初始化模型

在上一节中，我们选择了前20维作为每个流的表征向量。对于同一个PCAP中的每一个流，我们进一步筛选合法的流。我们认为，未完成握手的流为废弃流，在训练前应全部抛弃。这种做法可以排除无关变量对模型的污染。从初始的训练样本中提取的数据样本量较少，初始化的模型准确度不高，因此需要迭代训练。

5.2 模型预测方法

对于一个PCAP文件，我们首先提取其长度合法的通信流，然后，提取每一个流的主要特征（20维主要特征）作为表征方式。集成模型中的每一个分类器分别对PCAP中的每一个流进行预测，得到PCAP中每一个流的标签。接着，模型通过投票机制，得到该PCAP预测最多的类别作为该PCAP的预测类别。

5.3 数据增强

对于集成方法中的每一个分类器，我们得到了其预测集合。模型提取n个集合中的共性样本，作为高置信度的样本加入到原有的训练数据库中。增强的数据库作为新的训练用料，fine-tune现有的集成模型。

5.4 迭代增强与训练

此时，得到增强训练用例后更新训练，使用增强的数据库fine-tune已有参数，使得模型具有更强的泛化能力。

6. 隧道网页识别总结

克服该任务中训练数据量与测试类别量的不匹配问题是提高准确率的重要方法，本方案在给定的训练数据量上迭代增强训练样本，使模型获得更强的泛化能力，在我们多次提交的分数对比能看出，数据增强的集成迭代方法对分类准确率有显著提升（由0.762提升至0.845）。

总结

隐匿和检测是一个持续性的对抗过程。面对恶意通信高对抗性的隐蔽手段，攻击者伪装成正常通信，尽量模拟正常通信行为，检测与阻断就变得困难。

加密流量的检测，目前主流的方案仍然是提取数据包或流的统计特征，时序特征，来抽象表征不同种类的流量数据。这种侧信道的方法能有效地识别和分类不同种类的加密流量。

但实验室环境与在实际应用环境是有差距的，侧信道特征被证明在不同的网络环境中有着不同的特征分布，因此如何找到更稳定和可靠的流量行为表征方法，需要进一步研究。