Identifying Encrypted Malware Traffic with Contextual Flow Data

作者：Blake Anderson (Cisco), David McGrew (Cisco) 思科

出处：2016 ACM

摘要

识别出加密流量中潜藏的安全威胁具有很大挑战，监视此通信量以防威胁和恶意软件是很重要的，但这样做的方式必须保持加密的完整性。

由于模式匹配不适用于加密数据流，且传统的特征提取方式大多聚焦在流元数据数据包大小和一些与时间有关的参数，例如包长度和到达间隔时间等。

作者实现了一种有监督的机器学习模型来学习网络流的数据特征，进而对恶意加密流量进行分类，网络流数据特征包括5分钟时间窗口内的TLS握手元数据、DNS与加密流相关联的上下文流、HTTP上下文流的HTTP 头部。

作者首先展示了恶意流量和良性流量在数百万个不同流上使用TLS、DNS和HTTP之间的区别。本研究旨在设计最具辨别力的特征集。然后，作者证明，将此上下文信息合并到有监督的学习系统中，对于加密的恶意流分类问题，最终错误率可以降到0。作者在一个独立的真实数据集上进一步验证了假阳性率。

1. 简介

随着加密网络流量的不断增加，确定其可信度的负担变得过于繁重。

传统的威胁识别方法，如深度包检测和签名，不适用于加密流量。解密网络流量的解决方案会削弱用户的隐私，不适用于所有加密，而且计算密集。此外，这些解决方案对协作端点配置的依赖性使得部署具有挑战性，并限制了其适用性。

基于大量沙盒恶意软件样本和在大型企业网络上收集的数据训练有监督的机器学习算法，绕过对加密流量的解密，通过学习恶意加密流量的数据特征来识别恶意加密流量。

主要做到了以下几点：

• 利用上下文信息识别加密流量中的威胁
• 超高的准确率
• 真实环境下进行检测确认并非因为过拟合

data omnia：考虑与加密流相关联的所有可能的数据视图

contextual flow：同TLS握手数据包同一源IP地址的DNS数据流、5分钟窗口内同一源IP的HTTP数据流

SNI（Server Name Indication）是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是，在连接到服务器建立SSL链接之前先发送要访问站点的域名（Hostname），这样服务器根据这个域名返回一个合适的证书。

dns tls握手 域名

http头部 tls握手

ThreatGRID：一个基于libpcap的自定义工具来从实时流量中捕获我们的数据特性，并处理恶意软件包捕获文件

2. 恶意流量和TLS

恶意流量和良性流量的 TLS 使用差别很大，可以使用提供的密码套件，TLS 扩展和客户的公钥长度来简单说明这些差异

ClientHello

TLS 密码套件可以分为可接受和过时的两类，恶意软件通常提供一组三个过时的密码套件，包括 0x0004（TLS_RSA_WITH_RC4_128_MD5），而良性流量中 0x002f（TLS_RSA_WITH_AES_128_CBC_SHA）是最多的

客户端支持的 TLS 扩展中差别似乎不大，恶意流量与良性流量都选择使用 0x000d（signature_algorithms），而恶意软件通常更少选择 0x0005 (status request)、0x3374 (next protocol negotiation) 和 0xff01 (renegotiation info)

客户端的公钥长度是另一个区分点，大部分的 DMZ 流量使用 256 位的椭圆曲线密码作为公钥，但大多数恶意流量使用 2048 位 RSA 作为公钥

ServerHello

恶意流量通常选择已经过时的密码套件，DMZ 流量包含服务器支持的 TLS 扩展的大量变体

Certificate

恶意流量和 DMZ 的证书链数量大致相同，但长度为1的证书链中70%是自签名的恶意软件，1% 是自签名的 DMZ 流量。

SubjectAltName（SAN）

SAN数量在两个数据集中也有所不同。

证书有效期

证书有效期有显著差异

3. 恶意流量和DNS

6906627个恶意DNS响应和8060064个良性DNS响应

从签名的角度看，DNS提供的域名比IP动态性低

通过选取和目的IP地址相关的包含DNS响应信息的数据流作为研究对象，提取响应的域名信息进行分析。

DNS域名信息也可以从SNI扩展和SAN中得知，但由于TLS版本信息、在TLS会话恢复的情况下等原因，这些字段有时候是不存在的。

此外，在我们的研究中，我们发现恶意软件仅在观察到的27%的TLS流中利用SNI扩展。另一方面，DNS响应信息可用于我们数据集中78%的恶意TLS流，并可用于缺少SNI扩展的73%的恶意TLS流。

许多恶意软件使用域名生成算法来随机生成域名，这是一个明显区别于普通流量的行为。因此这便是我们识别恶意流量的突破口。

FQDN 包括两部分：主机名和域名。例如 mycomputer.mydomain.com

• 域名的长度：正常流量的域名长度分布为均值为6或7的高斯分布（正态分布）；而恶意流量的域名（FQDN全称域名）长度多为6（10）。

很明显，这种现象是由于DGA活动造成的，即每个样本具有相同长度的许多这样随机看起来的DNS响应。与我们最初的直觉相反，对于FQDN中的字符数，良性域似乎有一个较长的尾部。这是因为基于云的服务如何构造它们的fqdn。

• 数字字符及非字母数字(non-alphanumericcharacter)的字符占比：正常流量的DNS响应中全称域名的数字字符的占比和非字母数字字符的占比要大。

我们观察到大量访问云服务和内容分发网络的良性流量，这可能导致先前工作之间的这种差异。

• DNS解析出的IP数量：大多数恶意流量和正常流量只返回一个IP地址；其它情况，大部分正常流量返回2-8个IP地址，恶意流量返回4或者11个IP地址。

• TTL值：正常流量的TTL值一般为60、300、20、30；而恶意流量多为300，大约22%的DNS响应汇总TTL为100，而这在正常流量中很罕见。

• 域名是否收录在Alexa网站：恶意流量域名信息很少收录在Alexatop-1,000,000中，而正常流量域名多收录在其中。

Alexa根据页面浏览量和唯一IP地址的数量对网站进行排名。

鉴于图3所示的结果，很明显，DNS提供了有价值的、有区别的信息，这些信息可以与加密流相关，以提供额外的文本以提高可见性，并且可以用于创建高度精确的机器学习分类器

4. 恶意流量和HTTP

我们在 DMZ 收集了 1743842 条 HTTP 流记录，在 ThreatGRID 收集了 1004798 条 HTTP 流记录

指标	正常	恶意
常见字段	Connection, Expires, Last-Modified	Server, Set-Cookie, Location
常见内容类型	image/*	text/*; text/html; charset=UTF-8 and text/html; charset=utf-8
服务器端	Apache/Nginx，几乎所有的 AmazonS3 与 Nginx 1.4.7	Nginx，几乎所有的 LiteSpeed 和 gws
User-Agent	一般为Windows或OS X版本的Mozilla／5.0	较为常见的值为Opera/9.50(WindowsNT6.0;U;en)，次之的为一些版本的Mozilla／5.0或Mozilla／4.0

• User-Agent
• user-agent
• User-agent
• USER-AGENT
• User-AgEnt

通过将 User-Agent 与 TLS 库相关联，可以得到有用的推论。可以通过 TLS 元数据推断 TLS 库信息，然后根据 TLS 库信息推断浏览器

5. 数据

Joy是一款可以从实时网络流量中提取数据或直接捕捉到数据包文件（pcap文件）。Joy使用的是一种指向数据流的模型，其工作机制跟IPFIX或Netflow有些类似，在捕捉到数据之后，Joy将以JSON格式呈现出这些数据。

5.1 恶意流量数据

采集环境：ThreatGRID[4]，一种商业的沙箱环境，提供恶意软件分析功能

采集时间：2016年1月-2016年4月

采集数据：

• 21417 个恶意流量，每个都有完整的 TLS 握手信息
• TLS 数据：clientHello, serverHello, certificate 和 clientKeyExchange 信息
• 16691个TLS流具有关联的DNS查询，18144个在沙盒爆炸期间具有活动的HTTP会话。13542个/63%的恶意TLS流二者兼有，这些用于第六节。

说明： 沙箱环境接受用户提交（usersubmissions），每个用户提交允许运行5min，所有的网络活动被记录用于分析。

5.2 正常流量数据

采集环境：某大型企业网络的DMZ（隔离区）某5天的数据量

采集时间：2016年4月

说明：DMZ区流量，本文认为该区域包含少量的恶意流量

总数1130386个完成TLS握手并拥有所有相关消息的TLS流

746723或66%的TLS流具有相关的DNS响应。但是，在TLS流的5分钟窗口内，只有60285个或5%的TLS流具有来自同一源IP地址的任何HTTP流。有42927个TLS流同时具有DNS和HTTP上下文，这些流用于第6节的结果。

结果的额外验证，2016年5月从同一企业DMZ收集了一个其他数据集：在收集初始数据集4周后。采用相同的数据采集和过滤策略。在此期间，共有35699个TLS流同时具有DNS和HTTP context。

5.3 数据特征

5.3.1 可观测元数据

基于元数据的特征，比如包长和到达时间的序列，用马尔科夫链进行建模。

跟踪 TCP 序列号，排除 TCP 重传的影响。

数据包长选择 UDP、TCP和ICMP的有效载荷大小，如果这三种类型都没有，包长会被设置为 IP 数据包的长度。

到达时间精确到毫秒。

时间和长度都被离散化为“箱子”，对长度来说，马尔科夫链有 10 个箱子，每个箱子 150 字节。对时间来说，马尔科夫链有 10 个箱子，每个箱子 50 毫秒。这样总共有一百个特征 转换概率被用于机器学习算法的特征

在被分析的流的分组的有效载荷中遇到的每个字节值的计数除以在分组有效载荷中找到的总字节数得到字节分布，可以简单地计算流的字节值概率。256字节的分布概率也是机器学习算法使用的特征

5.3.2 TLS数据

基于客户端的 TLS 数据使用密码套件列表、客户端公钥列表和客户端公钥长度

我们在密码套件列表中观察到了 176 个独特的十六进制代码，组成了一个长度为 176 的二进制向量

同理，使用长度为 21 的二进制向量表示 TLS 扩展，使用一个整数值表示公钥长度

基于服务器的 TLS 数据使用密码套件列表、支持的扩展、证书数量、SAN 名称数量，有效天数以及是否存在自签名证书

5.3.3 DNS数据

收集域名和 FQDN 的长度

40个最常见后缀列表，每个后缀都有一个二进制向量，之外的为other

32个最常见的 TTL 值列表，之外的为other

数字字符数、非字母字符数、DNS 响应返回的 IP 地址数

六个二进制向量，表示域名在Alexa的前100/1000/10000/100000/1000000/还是未找到（每个域名选择最好的那个类别）

5.3.4 HTTP数据

对于每个 TLS 流，我们在 TLS 流的 5 分钟窗口内收集来自相同源地址的所有 HTTP 流

我们使用了 HTTP 数据中的七种类型的字段。 对于每个字段，我们选择了恶意软件或良性样本和“other”类别中至少1％使用的所有特定值。这些字段包括出站和入站HTTP字段，Content-Type，User-Agent，AcceptLanguage，Server 和 Code

6. 加密流量分类

在本节中，我们概述了从数据全知的角度看加密数据时可以实现的结果类型。我们不仅展示了使用所有可用的数据可以以0.00%的错误发现率获得令人难以置信的准确分类器，还展示了这些机器学习模型是如何解释的。我们提供证据证明，关联未加密的元数据可以为加密流分类带来有用效果。最后，我们在更多真实数据上验证了我们的方法，这些数据是从模型和特征的初始训练和调整中获得的。

6.1 分类结果

数据集：包含DNS和HTTP上下文的13542个恶意TLS流量和42927个良性TLS流量

l1-logistic regression （L1正则对数几率回归）

10-fold cross-validation （十折交叉验证）

L1范数正则化有助于降低过拟合风险，L1正则化（左图）倾向于使参数变为0，因此能产生稀疏解，即它求得得w会有更少的非0分量。

我们将L1正则对数几率回归与SVM（高斯核，通过CV调整宽度）进行了比较，没有什么大区别，使用10-fold paired t-test没有发现统计学上显著的改善。由于训练支持向量机所需的计算资源的增加和可解释性的丧失，我们只强调L1正则化回归结果。最后，将所有数据特征归一化为零均值和单位方差。

考虑到即使是在中等规模的网络上看到的加密流的数量，总准确率意味着非常少，因为即使是总准确率为99.99%的分类器也可能有上万个误报。因此，我们关注0.00%的错误发现率FDR。

相比之下，SPLT+BD+TLS分类器在该指标下的性能下降了77.881%。但是，一旦我们利用了额外的HTTP和DNS上下文，0.00%的错误发现率就变成了99.978%，这是一个显著的改进。

表1中的结果清楚地显示了利用上下文DNS和HTTP信息对TLS加密流进行分类的好处。虽然从DMZ收集的许多TLS流中都没有HTTP上下文，但66%的TLS流确实有DNS信息。只有TLS和DNS数据在0.00%FDR下仍然提供98.666%的精度。

6.2 模型可解释性

在操作设置中，具有返回0/1响应的黑盒分类器是次优的。能够将上下文添加到分类决策中对于执行适当的响应是非常有价值的。我们使用的L1正则化回归分类器具有很高的准确性，并且具有易于解释的参数，可用于帮助向事件响应者解释分类器的决策。此外，l1惩罚将大多数参数缩减为0，从而创建更易于解释和更好地泛化的稀疏模型。如表1所示，每个学习模型的参数数量在交叉验证折叠中平均。值得注意的是，与数据特征较少的其他模型相比，具有所有可能数据特征的模型实际上具有较少的模型参数，例如，所有特征的平均值为189.7，SPLT+BD+TLS的平均值为250.7。

图3，DNS特性Alexa，TLS ciphersuite TLS_rsau与RC4_128_SHA

这些模型参数和样本的特征向量可以很容易解释什么网络流是恶意的或者是正常的，

6.3 二次相关

除了创建机器学习模型外，我们收集的数据对于基于规则的IOC也很有用。

1. Client端的client-hello中的SNI与sever端的certificate中包含的SAN都表示服务器主机名，两者的差异性可以用于恶意流量检测；

2. HTTP流中的User-Agent和从TLS流中ciphersuites和advertisedextensions推测出的User-Agent的差异性也可以用于恶意流量检测。

当检测到恶意行为时，识别意外的差异是有用的。服务器名称指示（SNI）TLS扩展名在clientHello消息中可用，并指示客户端尝试连接到的服务器的主机名。subjectAltName（SAN）X.509扩展名在证书消息中可用，并允许服务器列出包括其他DNS名称在内的其他名称。

我们分析了21417个恶意TLS会话和1130386个良性TLS会话，这些会话具有服务器证书，查找SAN和SNI存在的实例，具有相关信息，并且不同意。0.01%的良性流和8.25%的恶意流存在差异。良性病例主要是SNI和*.what-sap.net中列出的IP地址以及SANs中列出的变体。这种差异不仅在恶意数据集中更为突出，在许多情况下，它也是一种与良性差异截然不同的差异类型。大多数恶意软件差异的格式包括SNI和SAN中类似DGA的行为，例如SNI:“bbostybfmaa.org”和SAN:“giviklorted.at”。

更高级的差异也可以通过我们收集的数据源进行分析查找TLS相邻HTTP流播发的用户代理与从TLS提供的密码套件和播发扩展推断的用户代理之间的差异是另一个有用的IOC。例如，我们观察到125个恶意TLS流，它们将HTTP流与一个用户代理字符串（Firefox/31.0）相关联。此集中的所有TLS流都提供了典型的Windows XP密码套件列表。

我们还发现了97个DMZ TLS流都有一个User-Agent =（Firefox/31.0）相关联的HTTP context。这些TLS流提供了一个有序的ciphersuite列表，与Firefox/31.0的真实版本相匹配。这种思路并不能避免误报，但它确实提供了一种独特的方法，在关联不同类型的数据时识别IOC。

6.4 真实环境测试结果

为了防止过拟合，除了上面提到的交叉验证方法之外

2016年5月从同一企业DMZ收集了一个其他数据集：在收集初始数据集4周后。用第五章节训练形成的模型来进行验证。

此验证集中有35699个具有DNS/HTTP上下文的TLS流、51113个仅具有HTTP上下文的TLS流、655906个仅具有DNS上下文的TLS流和988105个TLS流。

表3列出了在不同阈值下每组数据特征的报警数。“All”分类器对具有HTTP和DNS上下文信息的TLS流进行分类。“All Available”分类器对所有TLS流进行分类，但使用任何可用的上下文流信息。通过调整l1逻辑回归分类器的阈值来调整发出多少警报。例如，在默认的0.5阈值下，仅限TLS的分类器有20186个警报。将阈值调整为0.99时，在这4天内只有465个警报。

选择0.5作为阈值是一个一般的做法，实际应用时特定的情况可以选择不同阈值，
如果对正例的判别准确率要求高，可以选择阈值大一些，对正例的召回率要求高，则可以选择阈值小一些。

VirusTotal，是一个提供免费的可疑文件分析服务的网站

从Table 3中可以看到，结合TLS流的背景流量信息DNS响应和HTTP头部信息进行分类的效果最好，即报警数最少。当l1-logistic regression classifier的阈值为0.95时，该分类器只有86个报警（包括29个独立目的IP地址和47个独立的源IP地址），其中有42个报警看似是“误报”。经过分析发现，这些“误报”中，主机是一直和Goolge和Akamai服务器通信，但是从该TLS流的背景流量HTTP流（contexualHTTP）中发现，其与可疑域名进行通信（HTTP中的Host字段），经VirusTotal确认，有50%的反病毒引擎认为和该域名相关的可执行程序是恶意的，这也进一步说明了该模型的有效性。这些主机HTTP字段没有显示在Alexa列表中。

将TLS+HTTP+DNS分类器的阈值调整为0.95可将这四天内的警报数减少到18，并将唯一目标IP地址数减少到7。我们手动检查了每个IP地址。如果被VirusTotal记录的可执行文件在我们收集数据的同一日期与目标IP地址通信，则这些加密流被认为是真恶意流量。在阈值为0.95的TLS+HTTP+DNS分类器中，有16/18的警报被证实是恶意的。同样，我们无法将这些IP地址与AlexaTop-1000000中列出的域名关联起来。

7. 相关工作

基于网络的恶意软件检测研究主要有两个方向。

• 垂直关联，使用单个主机的网络流量来查找恶意软件感染的证据。
• 水平关联，使用两个或多个主机的通信量来查找恶意通信。

使用 TLS 的恶意软件在过去的十个月（2015年6月到2016年4月）里从 7% 增长到 18%

8. 结论

在本文中，我们已经证明了data omnia方法可以在不解密的情况下，准确地分类恶意TLS网络流。

特征：TLS, DNS and HTTP contextual flows

易于解释的分类模型，真实环境验证结果极好

数据对于基于规则的IOC也很有用

扩展&改进：

可以观察到更长的时间行为，使得使用FFT数据特征来检测周期性通信模式成为可能。

训练数据可以扩展到包括在可观测的蜜罐和恶意软件的在野恶意样本

在应用层加密的非TLS流上，利用SLADE等附加的内容感知数据特性可能很有用。

与所有垂直相关系统一样，它可以通过将其与水平相关系统（如分析通信图的系统）结合来扩展。