翻译：Identifying Encrypted Malware Traffic with Contextual Flow Data利用上下文流数据识别加密恶意软件流量

                     利用上下文流数据识别加密恶意软件流量

 

blake anderson思科[email protected]

摘要

识别加密网络流量中包含的威胁是一组独特的挑战。监视此通信量以防威胁和恶意软件非常重要，但这样做的方式必须保持加密的完整性。由于pat-tern匹配不能对加密数据进行操作，因此以前的方法利用了从流中收集的可观测元数据，例如流的包长度和到达间隔时间。在这项工作中，我们通过考虑数据全知方法来扩展当前的最新技术为此，我们开发了有监督的机器学习模型，该模型利用了一组独特而多样的网络流数据特性。这些数据特性包括TLS握手元数据、链接到加密流的DNS上下文流，以及在5分钟的窗口内来自同一源IP地址的HTTP上下文流的HTTP头。

我们首先展示了恶意流量和良性流量在数百万个唯一流上使用TLS、DNS和HTTP之间的区别本研究旨在设计最具辨别力的特徵集。然后，我们证明，将这些上下文信息合并到一个超级监督学习系统中，对于加密恶意流的分类问题，可以显著提高0.00%的错误发现率。我们在一个独立的真实数据集上进一步验证了我们的假阳性率。

关键词

加密；恶意软件；机器学习；传输层安全；网络监控

一导言一

随着加密网络流量的不断增加，对大多数事件响应团队来说，确定其可信度的负担变得过于繁重。传统的识别威胁的方法，如深度包检测和签名，不适用于加密通信解密网络流量的解决方案会削弱用户的隐私，不适用于所有加密，并且

 

奥地利维也纳，2016年10月28日，AISec'16

版权所有2016 ACM。ISBN 978-1-4503-4573-6/16/10

doi:http://dx.doi.org/10.1145/2996758.2996768

大卫·麦格雷夫

思科[email protected]

计算密集型此外，这些解决方案对协作端点配置的依赖性使得部署具有挑战性，并限制了其适用性。

在本文中，我们不建议解密网络流量。相反，我们专注于通过被动监控、相关数据特征提取和基于大量沙盒恶意软件样本和大型企业网络收集的数据的监督机器学习来识别加密通信中的恶意软件通信。我们做出了以下新的贡献：

1.     我们提供了利用上下文信息（即DNS响应和HTTP报头）来识别加密通信中的威胁的第一个结果。

2.     对于0.00%的错误发现率，我们展示了对这些数据进行操作的机器学习算法的高度精确性。

3.     最后，我们对我们开发的方法进行了实际验证，证明我们的结果不仅仅是由于过度拟合。

考虑到对加密流量进行威胁检测所面临的独特挑战，以及我们希望开发尽可能健壮的机器学习模型，自然要考虑包含与加密流相关联的所有可能的数据视图。我们把这种观点称为数据全知方法。从概念上讲，这可以通过扩展流记录来实现，以包含有关流的所有元数据，例如未加密的tls握手信息，以及指向“上下文”流的指针。我们将DNS上下文流定义为与基于目标IP地址的TLS流相关联的DNS响应，上下文HTTP流定义为在5分钟的窗口内来自同一源IP地址的HTTP流，这种方法与现有的多流技术不同，因为它使用关于流和上下文流的详细信息，而不仅仅是流元数据。例如，图1演示了如何将DNS流与TLS流链接，以及这种方法提供的附加信息的类型。

我们对tls握手元数据和两种上下文流类型进行了深入分析，我们发现这两种类型与识别加密通信中的威胁特别相关。与之前的工作不同，我们详细分析了恶意和良性流量之间的协议特性值。我们公开这些观察的动机是，任何有动机的威胁行为体，考虑到在大多数情况下已在公开文献中发表的特征类型，都可以观察到良性的流量，并尝试修改其服务器和客户端，以模仿观察到的

 

图1:TLS流和DNS内容流的图示，显示用于链接流的数据元素（红色）、作为上下文引入的数据元素（绿色）和作为元数据收集的TLS未加密头信息（未标记）。

 

行为。另一方面，通过混淆特征值，我们增加了事件响应者编写和部署妥协指标的难度。

我们分析的第一种上下文流是DNS响应，它提供加密流使用的地址，以及与名称相关联的TTL拥有一个IP地址的域名本身就提供了很多有意义的信息在tls流中，有时可以从服务器名称指示扩展或服务器证书的主题收集此信息。但是，sni扩展是可选的，在tls恢复的情况下将没有服务器证书。在这些情况下，上下文dns流有可能提供原本不可用的信息。此外，正如我们在本文中概述的，恶意dns响应具有区别于良性dns响应的特征，并且我们可以使用这些信息更准确地对相应的tls加密流进行分类。

除了可以与TLS加密流直接相关的DNS流之外，我们还分析了HTTP上下文流的HTTP头已经有很多基于规则的系统和基于http数据的机器学习分类器[29，33]，我们在这些研究的基础上利用http报头信息帮助对加密流进行分类。还有一些有趣的基于规则的推论，可以通过将http数据与未加密的tls握手元数据关联起来来实现。例如，TLS提供的ciphersuite列表和扩展可用于推断正在使用的加密库和版本，进而可用于推断启动流的用户代理查找流在其http字段中播发的用户代理与从相邻加密流的tls参数推断的用户代理之间的差异是一个有用的折衷指标。

我们编写了一个自定义的基于libpcap的工具[25，26]，以根据实时通信量限制我们的数据功能，并处理恶意软件包捕获文件该工具在2016年1月至2016年4月期间运行于从ThreatGrid[2]收集的恶意数据包捕获文件上，ThreatGrid[2]是一个商业沙箱环境。该工具还于2016年4月在大型企业网络的DMZ上运行了5天。这个过程导致了数以千万计的恶意和良性流我们意识到dmz流量确实包含少量恶意软件流量，但在本文中，我们将此流量称为良性流量。我们的分析工具基于python和scikit learn[32]。

本文证明了数据omnia方法的实用性和实用性。对于我们的机器学习应用，我们采用自下而上的方法。从我们收集的数据中，我们首先确定具有区分能力的tls、dns和http的数据特性。然后，我们展示了可以使用这些数据特征来定义机器学习算法，这些数据特征可以正确地分类它们各自的流类型最后，我们利用http和dns流提供的上下文来帮助对tls加密的网络流进行分类。当每天处理数以千万计的流量时，高的总准确度甚至适度的错误发现率都会让分析师不知所措。由于这个原因，我们将结果集中在0.00%的错误发现率的准确性上，也就是说，一个具有四个有效数字的零FDR。为了进一步保护本文中的假阳性率，并确认由于初始数据集和特征集的过度拟合，我们的结果不是模拟的，我们还对初始良性数据集后~4周收集的额外验证数据集进行了实验。

我们将有监督的机器学习视为使用先前观察到的恶意软件通信来检测加密恶意软件通信的最佳方法。机器学习分类器提供了构建检测器的最直接的方法，它还可以提供概率估计与异常检测不同，监督学习提供了可靠且易于解释的结果[36]。重要的是，在分类器训练过程中，可以使用规则化来选择具有最大区分能力的数据特征[21]，这对于我们的数据全知方法至关重要最后，还有一些分类器能够很好地防止过度拟合[23]；通过使用这些分类器，我们可以避免这种陷阱。在第6节中，我们通过证明有效算法（其结果易于解释）在这些数据上具有与效率低下的黑箱模型同等的性能，进一步证明了这些观点。

本文的其余部分安排如下：第2节详细介绍了我们深入的tls研究，第3节详细介绍了我们深入的dns研究，第4节详细介绍了我们深入的http研究。第5节回顾了我们的数据集和提取的特征，第6节介绍了我们的分类结果。最后，第7节回顾了背景材料和相关工作，我们在第8节中总结。

2.恶意软件和TLS

恶意软件和良性流量对TLS的使用是相当不明显的。在这一节中，我们从客户机的角度出发，通过检查提供的密码套件、公布的TLS扩展和客户机的公开密钥长度来详细说明这些差异。我们还通过检查所选的密码套件和从服务器证书收集的信息来查看服务器tls实现的差异。我们在2016年1月至2016年4月期间从Threatgrid[2]收集了21417个恶意TLS流，并在2016年4月的5天期间使用相同标准收集了1130386个良性TLS流。我们的工具用于分析tls流。它收集了未加密的tls握手消息中包含的所有信息。

clien-thello和clientkeyeexchange消息中包含的未加密tls元数据包含有价值的信息，可用于推断客户机的tls库。我们还观察到，这些特征在恶意软件和良性数据集中有很大不同；这意味着恶意软件作者使用一组不同的tls库和/或配置。图2说明了两个客户端TLS特性的区别：提供的CI-phersuites和公布的扩展。使用标准指南和行业建议[39]，TLS密码套件可以分为可接受和过时的类别我们可以看到，恶意软件通常在clienthello消息中提供一组三个过时的密码套件，包括0x0004（tls_rsa_with_rc4_128_md5）。在我们收集的良性通信量中，0x002f（TLS_rsau WITH_AES_128_CBC_SHA）密码套件的报价最高恶意软件在客户端支持的tls扩展中似乎也没有什么差异。0x000D（签名算法）是大多数TLS流中唯一支持的TLS扩展。~50%的DMZ流量还公布了以下异常情况，这些情况在恶意软件数据集中很少出现：

•0x0005（状态请求）

•0x3374（下一个协议协商）

•0xFF01（重新谈判信息）

尽管没有显示，客户机的公钥长度是另一个基于客户机的数据特性，具有显著的差异大多数dmz流量使用256位椭圆曲线密码作为公钥，但大多数恶意流量使用2048位rsa公钥。

服务器hello和证书消息可用于获取有关服务器的信息。服务器hello消息包含选定的密码套件和支持的扩展。鉴于提供的密码套件和公布的扩展的类型和多样性，正如人们所期望的那样，恶意流量通常选择过时的密码套件dmz通信量包含服务器支持的各种tls扩展。

证书消息将服务器的证书链传递给客户端。我们观察到恶意软件和DMZ数据链中的证书数量大致相同。但是，如果我们只关注长度为-1的链，~70%是恶意软件的自签名，~1%是DMZ流量的自签名。SubjectAltName（SAN）X.509扩展名中的名称数量在两个数据集中也有所不同对于DMZ流量，列表的长度为1~45%的时间。这在一定程度上是因为许多内容分发网络（CDN）提供商（例如，Akamai）只有一个条目由于一些广告服务，10/12长度列表在DMZ流量中也很常见。

图2还显示了证书有效性的分布，四舍五入到最近的一天。与其他数据特征类似，服务器证书的有效期在恶意流量和dmz流量上有显著差异。将证书信息与来自

从签名的角度来看，dns提供的域名比相关的ip地址动态性低，这使得黑名单更加健壮。此信息还提供了在许多情况下丢失的加密流的可见性。在某些情况下，服务器证书中的服务器名称指示（SNI）TLS扩展名和主题/主题替代名称（SAN）可以提供这种信息。在TLS会话恢复的情况下，证书将不存在，并且随着TLS 1.3的发布，服务器证书将很可能被加密。此外，在我们的研究中，我们发现恶意软件只利用了所观察到的TLS流中~ 27%的SNI扩展，另一方面，dns响应可用于我们数据集中~78%的恶意tls流，可用于缺少sni扩展的~73%的恶意tls流。
客户端可以帮助提高分类器性能，并帮助将加密流归因于特定的恶意软件系列[6]。

3.恶意软件和DNS

在本节中，我们系统地比较了恶意软件使用DNS和良性DNS的情况。使用与上一节相同的数据源，我们收集了6906627个恶意DNS响应和8060064个良性DNS响应我们的工具用于对恶意软件包捕获文件和实时DMZ数据进行DNS解析。

域生成算法（dga）生成大量域供恶意软件尝试与之通信。这个过程为恶意软件提供了一种更健壮的方法来联系其命令和控制服务器。通常情况下，这些算法具有隐式或显式的偏差，使得检测dga域成为可能。我们检查了一些关于域名和完全限定域名（fqdn）的简单统计数据，以帮助进行这些推断，并且更一般地，确定良性域名和恶意域名之间的差异。

图3显示了数据集中域名中字符数的直方图此分析也在FQDN上进行就域名长度而言，良性域名的形状大致呈高斯型，约为6/7。恶意域名和fqdns的峰值分别为6和10。在手动检查名称和相关的PCAP之后，很明显，这种现象是由于DGA活动造成的，也就是说，每个具有相同长度的样本都有许多这样随机查找的DNS响应与我们最初的直觉相反，似乎良性域对于fqdn中的字符数有一个较长的尾部。这是因为基于云的服务如何构造它们的fqdn。

我们研究了FQDNs上的另外两个指标：数字字符的百分比和非字母数字字符的百分比与之前的工作[9]相比，我们发现良性dns响应具有更高的
数字字符百分比，13.44%对0.85%，非字母数字字符百分比较高，16.36%对9.61%。非字母数字字符包括通配符和句点我们观察到大量访问云服务和cdn的良性流量，这可能导致先前工作之间的这种差异。

除了fqdn，dns响应还提供了其他有趣的数据元素。图3显示了返回的不同IP地址的数目对于恶意和良性响应，大多数DNS响应都返回1个IP地址。除此之外，还有一些有趣的结构，我们可以看到返回2和8个IP地址的良性响应显著增加，返回4和11个IP地址的恶意响应显著增加。

图3还显示了恶意软件和良性DNS响应之间不同TTL值的流行情况。良性dns响应最常见的四个ttl值依次是60、300、20和30。TTL值300是恶意软件的第二大常见值，但很少观察到TTL值20和30值得注意的是，22%的恶意DNS响应使用的TTL值为100，这个值在我们的DMZ数据中没有观察到。

Alexa[1]根据页面浏览量和唯一IP地址的数量对网站进行排名。我们在2016年4月记录了Alexa的前100万个网站。我们使用这个列表为域名创建了6个类别：目标域名是否在Alexa列表中的前100名、前1000名、前10000名、前100000名、前1000000名中。每个域名都被选为最有声望的类别，即一个域名属于前100名，而不是前100名和前1000名图3显示了有关恶意软件和DMZ流量的Alexa列表的域名分布。不出所料，在Alexa Top-1000000列表中，搜索到的恶意软件样本中，大约有86%的域名没有找到。另一方面，图3显示DMZ流量的大部分域名在前1000000个。

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

4.恶意软件和http

最后，我们将介绍在dmz和恶意软件流量中发现的与http头相关的差异。我们再次使用相同的数据源，并对端口80 http流量进行过滤。我们收集了来自dmz的1743842个http流和来自threatgrid的1004798个http流[2]。我们的工具解析了流中所有可用的头字段和值，从而留下完整的信息，这些信息将被web代理日志分解。这些日志只报告所有头的固定子集，并且它们规范化所报告的值，从而丢弃有价值的数据。例如，导出的iis 6.0web服务器日志中唯一可用的http特定数据功能是方法、uri、代码、用户代理、referer、cookie和主机。其中，默认情况下只有前四个被启用[4]。我们的工具还维护http字段的资本化和排序。

http字段或一组http字段的出现可以很好地指示恶意活动。图4列出了一些有趣的入站http字段的流行情况。例如，恶意http更可能使用服务器、set cookie和location字段，而dmz http通信更可能使用connec tion、expires和last modified字段。对于出站HTTP字段，dmzhttp更可能使用用户代理、接受编码和接受语言字段。

如图4所示，DMZ流量的主要HTTP内容类型是image/*，而恶意软件流量主要是text/*。内容类型还可以作为不应规范化这些字段值的示例。第二和第三种最常见的恶意软件内容类型是text/html；charset=utf-8和text/html；charset=utf-8。这些细微的差异在检测和归因方面有着难以置信的价值，不应该被抛弃。

图4还显示了服务器和代码绑定http字段的值。恶意软件通常说它使用的是一个版本较少的nginx服务器，而良性的流量大多说它使用的是版本较少的apache或nginx服务器。在有趣的服务器方面，amazons3和nginx/1.4.7几乎完全由be nign服务器发布，litespeed和gws几乎完全由恶意服务器发布。

出站用户代理字段有一个很长的尾巴，两个数据集中有几千个唯一的字符串对于恶意软件数据，最常见的广告用户代理字符串是Opera/9.50（WindowsNT6.0；U；en），其次是Mozilla/5.0和Mozilla/4.0的几个变体dmz数据中的所有顶级用户代理字符串都是mozilla/5.0的windows和os x变体。这一领域的资本化也最为多样化，我们观察到：

•用户代理

•用户代理

•用户代理

•用户代理

•用户代理

用户代理字段也是这些字段在加密通信上下文中的强大功能的另一个有趣示例。找到端点上正在使用的软件与端点正在发布的软件之间的差异是一个有趣的折衷指标。通过关联http和tls数据，特别是用户代理字段和tls库，我们可以做出有用的推断。

例如，我们可以通过观察TLS元数据，推断TLS库，然后将TLS库与可能的浏览器或一组浏览器关联，从而对正在使用的浏览器进行合理的估计正如我们将在第6节中显示的，当tls浏览器估计值与http用户代理字段中的广告不同时，这是非常有趣的。

http+dns

良性：3.80%恶意：63.23%

图5：不同上下文数据的流行程度，显示了良性（DMZ）和恶意软件流中具有DNS和/或HTTP上下文的TLS流的百分比。

5数据

在本节中，我们将重申我们的数据收集策略。我们还描述了我们在前面章节中探索的每一个数据特征是如何表示为机器学习算法的。joy[26]用于将所有数据（从包捕获文件或实时收集的）转换为方便的json格式。

5.1恶意软件数据

恶意数据集是2016年1月至4月从接收用户提交的商业沙箱环境收集的每次提交允许运行5分钟，并收集所有网络活动进行分析从这个集合中，有21417个成功的tls流。每个流都完成了完整的握手，并收集了来自clientHello、serverHello、certificate和clien-tKeyExchange消息的TLS数据。

图5给出了还存在的其他上下文数据特性的百分比。16691个tls流具有关联的dns查找，18144在沙盒爆炸期间具有活动的http会话。13542，或～63%的恶意tls流拥有所有可用数据。为了准确比较基于不同数据视图的分类器，在第6节的结果中使用了这组13542个流。

5.2良性数据

良性数据集是2016年4月从一家大型企业网络的DMZ收集的，为期5天。我们再次收集了所有成功完成tls握手并拥有所有相关消息的tls流。有1130386个这样的流量。

如图5所示，746723或~66%的TLS流具有相关的DNS响应但是，在TLS流的5分钟窗口内，只有60285个或~5%的TLS流具有来自同一源IP地址的任何HTTP流。http上下文本身就是一个有趣的指示器，随着更多的alexa排名前1000000的网站向https过渡，它应该会保持有趣。有42927个tls流同时具有dns和http上下文，这些流用于第6节的结果。

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

5.3数据特征

5.3.1     可观测元数据

使用基于可观测元数据的特征，例如包长度的序列和到达间隔时间，并将其建模为马尔可夫链通过让工具跟踪TCP序列号，我们将TCP重新传输从数据中排除。数据包长度被认为是udp、tcp或icmp数据包有效负载的大小。如果数据包不是这三种类型之一，则将长度设置为IP数据包的大小。到达时间有毫秒的分辨率。

对于长度和时间，将值离散到大小相等的容器中。长度数据马尔可夫链有10个单元，每个单元150字节假设为1500字节的mtu，并且观察到的任何大小大于1350字节的包都被放入同一个bin中。时间数据马尔可夫链使用50毫秒的存储箱和10个存储箱来存储100个特征。任何超过450ms的包间时间都落入同一个bin中将转换概率作为机器学习算法的特征。

另一种形式的可观测元数据，字节分布，被表示为一个长度为256的数组，它为被分析流的数据包的有效负载中遇到的每个字节值保留一个计数给定字节分布，通过将字节分布计数除以包有效负载中找到的字节总数，可以很容易地计算出流的字节值概率。机器学习算法使用的特征是256字节的分布概率。

5.3.2     TLS数据

我们的分类算法中使用的基于客户端的TLS特定功能包括提供的密码套件列表、公布的扩展列表和客户端的公钥长度我们观察到176个在提供的密码套件列表中公布的唯一十六进制代码，并创建了一个长度为176的二进制向量，其中一个被分配给示例提供的密码套件列表中的每个十六进制代码。考虑到列表的顺序，考虑了更高级的表示，但并没有导致显著的改进结果，因此没有追求简单性。类似地，使用长度为21的二进制向量来表示tls扩展。最后，使用单个整数值表示公钥长度。

基于服务器的TLS特定功能包括选择的密码套件、支持的扩展、证书数量、SAN名称数量、有效期（天）以及是否有自签名证书。

5.3.3     DNS数据

从TLS流的相关DNS响应中，我们收集域名和FQDN的长度我们还收集了40个最常见后缀的列表，每个后缀都有一个二进制特征，而“其他”则有一个二进制特征。类似地，我们获得了32个最常见ttl值的列表和一个“其他”选项。我们还具有数字字符数、非字母数字字符数和dns响应返回的ip地址数的功能。最后，我们有六个二进制特性表示域名是否在Alexa列表中的前100、前1000、前10000、前100000、前1000000中。每一个域名都会选出最负盛名的类别，也就是说，排名前100的功能是一个，而不是排名前1000的功能。

5.3.4     HTTP数据

对于每个tls流，我们在tls流的5分钟窗口内从相同的源地址收集所有http流。有一个二进制变量的单一特征向量，表示观察到的所有http头。如果任何一个HTTP流都有一个特定的头值，那么不管其他HTTP流如何，该特性都将是1。

我们使用了来自http数据的七种特性。对于每个功能，我们选择了至少1%的恶意软件或良性样本和“其他”类别使用的所有特定值。这些类型包括出站和入站http字段、内容类型、用户代理、接受语言、服务器和代码。

6对加密流量进行分类

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

6.1分类结果

对于这些结果，我们使用包含dns和http上下文的13542个恶意tls流和42927个良性tls流，如第5节所述。所有结果均采用10倍交叉验证和l1 logistic回归。我们将展示这个分类器在我们的任务中表现得非常好，并且具有易于解释的附加好处。该模型还报告了一个概率输出，允许一个简单的改变阈值的分类器。我们将l1 logistic回归与支持向量机（高斯核，通过cv调整宽度）进行了比较，在5%显著性水平下，使用10倍配对t检验没有发现统计学上的显著改善[14]。由于训练支持向量机所需的计算资源增加和可解释性的丧失，我们只强调l1逻辑回归结果。最后，所有的数据特征被标准化为零均值和单位方差。

表1给出了不同特征集组合的10倍l1 logistic回归分类结果。splt/bd是分组长度、时间和字节分布的序列。tls、http和dns是不言而喻的。只有使用加密流本身的信息，splt+bd+tls，我们才能达到99.933%的总准确率。考虑到即使是在中等规模的网络上看到的加密流的数量，总精度也意味着很小，因为即使是总精度为99.99%的分类器也可能有几十个

成千上万的误报因此，我们关注0.00%的错误发现率。

在我们的数据集中有55000个样本，不可能给出一个真实、可靠的0%错误发现率。有了这个警告，我们确实报告了0%，或0.00%，我们的分类筛选错误发现率。相比之下，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-logistic回归分类器非常精确，并且具有易于解释的参数，可用于帮助向事件响应者解释分类器的决策此外，l1惩罚将大多数参数缩小为0，从而创建更容易解释和更好概括的稀疏模型。每个学习模型的参数数量，在交叉验证折叠中平均，如表1所示。值得注意的是，与数据特征较少的其他模型相比，具有所有可能数据特征的模型实际上具有较少的模型参数，例如，所有特征的平均值为189.7，splt+bd+tls的平均值为250.7。

表2显示了影响肯定恶意软件定罪的前5个参数和影响否定恶意软件定罪的前5个参数。这个l1逻辑回归分类器是使用所有可用的数据源构建的有趣的是，来自TLS、DNS和HTTP的数据特性都显示在前5个列表中的一个或两个列表中。

这些价值观中的大多数很容易理解。例如，dns的特性alexa:none是顶级的-

重量	特色
3.38	DNS后缀组织
2.99	DNS TTL 3600
2.62	TLS Ciphersuite TLS_rsau与RC4_128_SHA
2.28	HTTP字段接受编码
1.95	TLS密码套件 与CBC合作
1.78	HTTP字段位置
1.38	DNS Alexa:无
1.21	tls ciphersuite tls_rsau与rc4_128_md5
1.12	http服务器nginx
1.11	http代码404
-2.16	TLS扩展名
-1.65	HTTP内容类型应用程序/八位字节流
-1.61	http接受语言en-us，en；q=0.5
-1.35	TLS Ciphersuite TLS_DHE_rsau WITH_DES_CBC_SHA公司
-1.10	http内容类型text/plain；charset=utf-8
-0.97	HTTP服务器Microsoft IIS/8.5
-0.95	域名系统Alexa:Top-1000000
-0.91	HTTP用户代理Microsoft CryptoAPI/6.1
-0.88	TLS密码套件 带RC4_128_SHA的TLS_Ecdhe_Ecdsa_
-0.85	HTTP内容类型application/x-gzip

表2：与tls/dns/http分类器最相关的数据特性。

 

一个恶意定罪的十个贡献者，以及我们处理的恶意样本的主要内容没有与AlexaTop-1000000中的一个域对话。有趣的是，dns特性alexa:top-1000000是唯一一个基于alexa的特性，有助于良性分类，即alexa:top-100等的权重为0。这可能是前-

	全部	TLS公司 +高TTP	TLS公司 +域名服务器	TLS公司	全部 可用
0.0	35,699	51,113	655,906	988,105	988,105
.5	86	312	4,207	20,186	4,602
.9	25	130	982	4,718	2,004
.95	18	97	855	3,014	1,644
.99	4	67	621	465	1,056

表3：基于真实验证数据集上的不同功能集和阈值生成的警报。

 

有一个不小的百分比的恶意软件样本执行连接检查到流行的网站，如www.google.com，但相对较少的恶意软件样本连接到网站在100，00-1000000范围。

tls ciphersuite tls_rsau与rc4_128_sha相关的是恶意定罪。据观察，提供此信息套件的恶意软件流明显多于企业流[6]。同样，这些模型参数和样本的特征向量可以很容易地解释为什么分类器将流分类为恶意流或良性流。

6.3二阶相关性

除了创建机器学习模型外，我们收集的数据对于基于规则的承诺指标也很有用。当检测到恶意行为时，识别意外的差异是有用的。clien-tHello消息中提供了服务器名称标识（SNI）TLS扩展名[16]，该扩展名指示了客户端试图连接到的服务器的主机名SubjectAltName（SAN）X.509扩展名[35]在证书消息中可用，并允许服务器列出包括其他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提供的密码套件和播发扩展推断的用户代理之间的差异是另一个有用的折衷指标。例如，我们观察到125个恶意TLS流，它们将HTTP流与一个用户代理字符串（Firefox/31.0）相关联此集中的所有TLS流都提供了典型的Windows XP密码套件列表[27]。

我们还发现了97个dmz tls流，其中有一个与用户代理字符串（firefox/31.0）相关联的http上下文。这些tls流提供了一个有序的ciphersuite列表，该列表与firefox/31.0的真实版本相匹配。

[34]。这种思路并不能避免误报，但它确实提供了一种独特的方法来识别在关联不同类型数据时出现的承诺指标。

6.4现实世界的结果

在数据有限的研究环境中，通常很难避免对特定数据集过度拟合机器学习算法。即使使用正确的交叉验证方法，在元参数（如机器学习算法或数据特征的选择）中也可能出现隐式偏差[15]。除了交叉验证的结果之外，我们现在还将在其他验证数据集上显示结果。这些数据是在初始数据集之后4周内从同一企业DMZ收集的。机器学习算法只在原始数据集上进行训练，然后应用于新的数据集。没有对算法或功能进行任何更改。此验证集中有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个警报。

毫不奇怪，使用DNS和HTTP上下文信息的分类器在验证数据集上执行得最好。这个分类器总共有86个警报，29个唯一的目标IP地址和47个唯一的源IP地址。其中42个警报似乎是误报。在几乎所有这42个案例中，TLS流都与Google或akama服务器通信，但具有与可疑域通信的上下文HTTP流。“可疑”是通过提取主机HTTP字段，并检查VirusTotal[3]是否在源代码中找到了包含该域名的已定罪可执行文件来确定的。在这种情况下，定罪意味着超过50%的病毒检测程序将可执行文件标记为恶意。这些主机HTTP字段没有显示在Alexa列表中。

将TLS+HTTP+DNS分类器&apos；s阈值调整为0.95可将这四天内的警报数减少到18，并将唯一目标IP地址数减少到7。我们手动检查了每个IP地址。如果由VirusTotal判定为可执行文件的可执行文件在我们收集数据的同一日期内与目标IP地址通信，则这些加密流被认为是真正的积极因素。在阈值为0.95的TLS+HTTP+DNS分类程序&apos；s警报中，有16/18使用此方法确认为恶意警报。同样，我们无法将这些IP地址与AlexaTop-1000000中列出的域名关联起来，例如，没有解析到google.com的IP地址。

7．相关工作

基于网络的恶意软件检测研究主要有两个方向。第一种是垂直关联，使用单个主机的网络流量来查找恶意软件感染的证据。第二种是水平关联，使用两个或多个主机的通信量来查找恶意通信。在某些情况下，水平关联可以检测大规模的恶意通信图。有些技术与内容无关，而另一些则依赖于内容检查。我们的方法使用垂直关联，并且由于它使用了DNS、TLS和HTTP元数据，所以它不完全与内容无关，但是它不依赖于对加密有效负载的检查。7.1流元数据

传统上，流量监控系统被用来收集网络通信的元数据，如IP地址、端口、交换字节数和数据包数。然后使用IPFIX[12]或NetFlow[11]等协议将此数据导出到收集器。当流量被加密时，这些数据尤其有价值，因为深度包检查不再可行。最简单的流量数据分析利用了流量记录和黑名单中的IP地址。这种类型的数据融合应用广泛，但脆弱且难以维护。还研究了与协议无关的其他特性，如数据包长度和字节值分布[19]。

此数据还用于执行应用程序或恶意软件检测[18、19、30、40、41、42、43、44]。BotFinder[38]是一种重要的垂直相关技术，它只使用NetFlow特性。无监督机器学习用于识别从恶意软件沙盒收集的恶意软件通信的特征群集。它检测恶意软件通信中的周期性组件，检测率为0.8，误报率为0.0001。因为BotFinder是内容不可知的，所以它可以对加密的流量进行操作。通过利用更多的数据特征，我们的方法实现了更高的检测率，并且对恶意软件不是周期性的、不具有NetFlow数据中显示的通信特征的规避技术具有鲁棒性。此外，即使每个恶意软件实例只被观察到很短的时间（例如，5分钟），我们的方法仍然有效。这是一个重要的优势，因为大规模标记的恶意软件数据集往往受到沙盒资源的限制。相反，BotFinder所利用的行为不会出现在这些短窗口中。

另一个重要的垂直技术是僵尸猎人[19]。该算法跟踪内部资产和外部实体之间的通信，并开发与基于状态的感染序列模型匹配的通信事件的证据跟踪。僵尸猎人识别在恶意软件感染期间发生的感染和协调对话框。它依赖于内容，同时使用Snort签名和基于内容检测的异常检测，后者使用复杂的基于n-gram的统计有效载荷异常检测引擎（SLADE）。

Bot-Sniffer[20]是一种重要的水平相关技术，它检测网络流量中的时空相关性和相似模式，这是botnet命令和控制流量的特征。其他有趣的水平相关技术包括BotMiner[18]和[37]。这些技术的局限性在于不能高效地检测出单一的感染宿主。

7.2 DNS域名系统

域名系统（DNS）[28]是一种分层的、分散的方式，它提供有关域名的附加信息，特别是域名到IP地址的映射。最近，恶意软件利用DNS和域生成算法（DGA）[8]提供了一种健壮的方式来操作其命令和控制通道。以前有很多关于将DNS数据分类为恶意或良性的结果[7，9，24]。这些工作都没有利用DNS数据来推断加密流量。我们的工作也不同，因为我们说明了DNS不同数据特性的分布，例如TTL值。

7.3 HTTP协议

超文本传输协议（HTTP）[17]是一种应用级协议，用于在万维网上传输数据。与DNS类似，HTTP也被威胁参与者用作命令和控制通道[29，33]。有一些工作专门针对HTTP数据中的特性。在[33]中，作者使用统计信息，例如URL的平均长度，以及URL上的字符串匹配方法来对恶意软件进行集群。同样，恶意软件和良性HTTP会话的具体区别也没有突出显示。[22]具体分析了用户代理字段值。我们给出了更多HTTP字段的详细描述，并使用这些信息为加密流量创建机器学习分类器。

7.4 TLS

传输层安全（Transport Layer Security，TLS）[13]是一种为应用程序提供隐私的加密协议。TLS通常是在常见协议（如用于web浏览的HTTP或用于电子邮件的SMTP）的基础上实现的。HTTPS是在HTTP上使用TLS，这是web服务器和客户端之间最流行的通信方式，大多数主要web服务器都支持这种方式。在过去10个月里，我们观察到恶意软件使用TLS的情况有所增加，从2015年6月的活跃网络通信样本的～~7%增加到2016年4月的～~18%。

对恶意软件使用的证书的特性进行了研究[5]，但这项工作并没有检查良性证书或它们与恶意软件使用的证书的区别。虽然分析恶意软件&apos；使用TLS的工作很少，但仅分析流元数据对加密流同样有效。中间人（Man in-the-Mid-dle，MITM）解决方案[10]也被提出用于发现加密通信中的威胁。在MITM中，企业将解密通过安全设备的网络流量，并通常对未加密的流量应用签名。这种方法不尊重网络上用户的隐私，并不总是有效的，需要大量的资源来有效的部署和维护。基于这些原因，通常首选基于流的解决方案。

8.结论

识别加密网络流量中的威胁，并以不损害加密完整性的方式进行识别，是一个重要问题。在本文中，我们已经证明了数据omnia方法，特别是收集和关联TLS、DNS和HTTP元数据，可以在不破坏TLS协议的情况下，准确地分类恶意TLS网络流。

我们首先确定TLS协议的特征，以及上下文流的DNS和HTTP特征，这些特征具有有趣的歧视性信息。我们展示了如何使用查找未加密元数据中的差异来查找有意思的折衷指标，例如不匹配的SNI和SAN字段。我们提出一个l1 logistic回归模型，在0.00%FDR下，其准确率为99.978%。该模型还提供了易于解释的结果，这些结果在初始数据集之后~4周收集到的新数据集中得到了很好的推广。

有几个研究方向可以扩展和改进我们的工作。可以观察到更长期的行为，从而可以使用FFT数据特征来检测周期性通信模式[38]。训练数据可以扩展到包括蜜罐和野生恶意软件。在应用层加密的非TLS流上，利用SLADE[19]等附加的内容感知数据特性可能很有用。与所有垂直相关系统一样，它可以通过将其与水平相关系统（如分析通信图的系统）混合来扩展。

9．致谢

我们要感谢匿名评论者的建设性反馈。我们还要感谢格雷格·阿克斯对这项工作的支持。最后，我们要感谢Rich West、Dave Schwartzburg、Brandon Enright、Craig Brozefsky和ThreatGRID团队在促进数据收集方面的指导性、洞察力和支持。

10．参考文献

[1]亚历山大。http://www.alexa.com/，2016年。

[2]威胁网格。http://www.threatgrid.com，2016年。

[3]病毒总数。https://www.virustotal.com/，2016年。

[4]W3C扩展日志文件格式（IIS 6.0）。https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb，2016年。

[5]O.Alrawi和A.Mohaisen。不信任链：理解用于签署恶意应用程序的证书。在万维网上第25届国际会议纪要，第451-456页。国际万维网会议指导委员会，2016年。

[6]B.安德森、S.保罗和D.麦克格雷夫。解密恶意软件&apos；使用TLS（不解密）。ArXiv电子版，2016年7月。

[7]M.Antonakakis、R.Perdisci、W.Lee、N.Vasiloglou II和D.Dagon。正在检测较高DNS层次结构中的恶意软件域。USENIX安全研讨会，第16页，2011年。

[8]M.Antonakakis、R.Perdisci、Y.Nadji、N.Vasiloglou、S.Abu Nimeh、W.Lee和D.Dagon。从垃圾流量到机器人：检测基于DGA的恶意软件的增长。使用中的NIX安全页491-5062012年。研讨会，

[9]L.Bilge、E.Kirda、C.Kruegel和M.Balduzzi。暴露：使用被动DNS分析查找恶意域。网络与分布式系统安全研讨会，2011年。

[10]F.Callegati、W.Cerroni和M.Ramilli。中间人攻击HTTPS协议。IEEE安全7（1）：78-812009。&隐私，

[11]B.克莱斯。Cisco Systems NetFlow Services导出版本9，2013。RFC 3954号。

[12]B.克莱斯、B.特拉梅尔和P.艾特肯。流量信息交换用IP流量信息导出（IPFIX）协议规范，2013年。RFC 7011号。

[13]T.Dierks和E.Rescorla。传输层安全（TLS）协议版本1.2。2008年。RFC 5246号。

[14]T.G.迪特尔奇。监督分类学习算法比较的近似统计检验。神经计算，10（7），1998。

[15]C.德沃克，V.费尔德曼，M.哈特，T.皮塔西，

莱恩戈尔德和罗斯。可重用Holdout：在自适应数据分析中保持有效性。科学，349（6248）：636-6382015。

[16]D.伊斯特莱克。传输层安全（TLS）扩展：扩展定义。2011年。RFC 6125号。

[17]R.菲尔丁，J.盖蒂，J.莫古尔，H.弗莱斯蒂克，

L.Masinter，P.Leach和T.Berners Lee。超文本传输协议-HTTP/1.1。1999年。RFC 2616号。

[18]G.Gu，R.Perdisci，J.Zhang和W.Lee。BotMiner：用于协议和结构无关的Botnet检测的网络流量聚类分析。USENIX安全研讨会，第5卷，第139-154页，2008年。

[19]G.Gu，P.A.Porras，V.Yegneswaran，M.W.Fong和W.Lee。僵尸猎人：通过IDS驱动的对话关联检测恶意软件感染。USENIX安全研讨会，第7卷，第1-16页，2007年。

[20]顾先生，张先生，李先生。BotSniffer：检测网络流量中的僵尸网络命令和控制通道。二千零八

[21]T.黑斯特，R.蒂布什拉尼，J.弗里德曼和J.富兰克林。统计学习的要素：数据挖掘、推理和预测。27（2）：83-852005年。

[22]新凯尔。通过HTTP用户代理异常对恶意软件进行行为分类和检测。信息安全与应用杂志，18（1）：2-13，2013。

[23]K.Koh，S.-J.Kim和S.P.Boyd。大尺度l1正则Logistic回归的内点法。JMLR，8（8）：1519-15552007年。

[24]马杰，索尔，萨维奇和福克。超越黑名单：学习从可疑网址检测恶意网站。在第15届ACM SIGKDD国际知识发现和数据挖掘会议记录中，第1245-1254页。ACM，2009年。

[25]D.McGrew和B.Anderson。增强遥测加密威胁分析。计算机网络中机器学习的ICNP研讨会（NetworkML）。IEEE，2016年。

[26]D.McGrew和B.Anderson。快乐。https://github.com/davidmcgrew/joy，2016年。

[27]微软。在SChannel中选择正确的密码套件。https://www.ssl.com/how-to/在schannel dll/中选择正确的密码套件，2016年。

[28]P.莫卡佩特里斯。域名-概念和设施。1987年。RFC 1034号。

[29]A.莫海森。实现恶意网页内容的自动、轻量级检测和分类。在网络系统和技术（Hot Web）的热门话题中，第67-72页。IEEE，2015年。

[30]A.W.Moore和D.Zuev。基于贝叶斯分析技术的网络流量分类。在ACM SIGMETRICS性能评估评审中，第33卷，第50-60页。ACM，2005年。

[31]S.Nagaraja，P.Mittal，C.-Y.Hong，M.Caesar和

鲍里索夫。BotGrep：使用结构化图分析查找P2P机器人。使用中的Nix安全页95-1102010。研讨会，

[32]F.Pedregosa，G.Varoquaux，A.Gramfort，V.Michel，B.Thirion，O.Grisel，M.Blondel，P.Prettenhofer，R.Weiss，V.Dubourg，J.Vanderplas，A.Passos，

D.Cournapeau、M.Brucher、M.Perrot和

杜切斯内。Scikit学习：Python中的机器学习。JMLR，12:2825-2830，2011年。

[33]R.Perdisci、W.Lee和N.Feamster基于HTTP的恶意软件行为聚类及利用恶意网络跟踪生成特征码。在NSDI，第391-4042010页。

[34]奎利斯。Qualys SSL实验室。https://www.ssllabs.com/ssltest/clients.html，2016年。

[35]P.圣安德烈和J.霍奇斯。在传输层安全（TLS）环境下，使用X.509（PKIX）证书在Internet公钥基础设施中表示和验证基于域的应用程序服务标识，2011年。RFC 6125号。

[36]R.Sommer和V.Paxson。封闭世界之外：利用机器学习进行网络入侵检测。2010年IEEE安全与隐私研讨会，第305-316页。IEEE，2010年。

[37]W.T.Strayer，R.Walsh，C.Livadas和D.Lapsley。通过严密的命令和控制检测僵尸网络。在本地计算机网络中，2006年第31届IEEE会议论文集，第195-202页。IEEE，2006年。

[38]F.Tegeler、X.Fu、G.Vigna和C.Kruegel。Botfinder：在网络流量中查找bot而不进行深度包检查。在第八届新兴网络实验与技术国际会议上，第349-360页。ACM，2012年。

[39]瓦西里夫。附件A:FIPS PUB 140-2《密码模块安全要求》批准的安全功能。http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf，2016年。

[40]K.Wang，G.Cretu和S.J.Stolfo。基于异常负载的蠕虫检测与特征生成。入侵检测的最新进展，第227-246页。斯普林格，2006年。

[41]王L.王K.P.戴尔，A.阿克拉，T.里斯滕帕特和T.伯劳顿。看穿网络协议的模糊。在第22届ACM计算机和通信安全会议上，第57-69页，2015年。

[42]N.威廉姆斯、S.赞德和G.阿米蒂奇。五种机器学习算法在实际IP流量分类中的性能初步比较。计算机通信评论，2006年30月。

[43]P.Wurzinger、L.Bilge、T.Holz、J.Goebel、C.Kruegel和E.Kirda。自动生成僵尸网络检测模型。在计算机安全ESORICS 2009，第232-249页。斯普林格，2009年。

[44]S.Zander，T.Nguyen和G.Armitage。使用机器学习的自动交通分类和应用识别。在第30届IEEE会议上

本地计算机网络会议，第250-257页。IEEE，2005年。

附录

A.密码套件和扩展十六进制码

类型标记	西弗苏特
0x0004个	TLS_rsau与_RC4_128_MD5
0x0005个	TLS_rsau与_RC4_128_SHA
0x000a	与CBC合作
0x0013号	带CBC的TLS U DHE U DSS U
0x0015号	与CBCú
0x002f号	TLS_rsau与_AES_128_CBC_SHA
0x0035号	TLS_rsau与_AES_256_CBC_SHA
0x0064个	SSL_RSA_EXPORT1O24_与RC4_56_SHA
0xc007号	带RC4_128_SHA的TLS_ECDHE_ECDSA_
0xc009号	带AES_128_CBC_SHA的TLS_ECDHE_ECDSA_
0xc00a	带AES U 256 U CBC U SHA的TLS U ECDHE U ECDSA U
0xc013号	带AES U 128 U CBC U SHA的TLS U ECDHE U RSA U
0xc014号	带AES U 256 U CBC U SHA的TLS U ECDHE U RSA U
0xc02b型	TLS_ECDHE_ECDSA_与_AES_128_GCM_SHA256
0xc02f型	TLS_ECDHE_rsau与_AES_128_GCM_SHA256

表4：图中使用的密码套件的十六进制代码到密码套件的映射。

 

 

类型标记	西弗苏特
0x0000个	服务器名称
0x0005个	状态请求
0x000a	支持的组
0x000b	ec U点格式
0x000d个	签名算法
0x000华氏度	心跳
0x0015号	衬垫
0x0017号	扩展的大师秘密
0x0023号	会话包TLS
0x3374个	下一个协议谈判
0xff01型	重新谈判信息

表5：图中使用的扩展的十六进制代码到扩展映射。