解密恶意软件使用的TLS (CISCO)(二)

前提和假设

本文主要关注的是对恶意的TLS加密流进行分类。虽然我们确实使用serverHello和certificate信息来发掘有关恶意软件样本连接服务器的一些有用特征,但我们的主要重点是面向client。我们的分类算法在很大程度上取决于基于客户端的特征,这使我们的算法可以正确地将连接到http://google.com的恶意流量与连接到http://google.com的正常流量正确分类。因此,我们不会过滤恶意软件的TLS流量,并且还允许其他类型的TLS加密流量,例如点击欺诈等等。

在本文中,我们将重点放在使用443端口的TLS加密流上,以使企业TLS与恶意TLS之间的比较尽可能地公正。表I列出了2015年8月至2016年5月收集的恶意软件样本中TLS的5个最常用端口。为了确定流是否为TLS,我们使用了深度数据包检查和基于TLS版本的自定义签名和clientHello和serverHello消息的消息类型。我们研究了229端口的共203364个TLS流样本,发现其中443端口是迄今为止恶意TLS最常用的端口,使用其他端口的情况相对来说并不常见。

解密恶意软件使用的TLS (CISCO)(二)

由于我们的非恶意软件数据是在企业网络上收集的,因此本文提出的分类和分类结果最适用于企业环境,我们不声称这些结果适用于一般类别的网络,例如服务提供商数据。本文使用的企业网络数据最初是使用IP黑名单过滤的,这消除了约0.05%的初始流量,我们知道此数据集中很有可能还会包含恶意流量,但是出于实用性考虑,此事实仅作为基本假设。

数据

本文的数据是从企业沙盒环境中收集的,用户可以在沙盒提交可疑的可执行文件,每个提交的样本可以运行5分钟。为每个样本收集并存储完整的数据包捕获。由于沙盒环境的限制,在沙箱中观察到的所有网络流量都被认为是原始提交的样本的流量。例如,如果样本A下载并安装了B和C,则从B和C产生的流量将被视为A的流量。

这种数据收集方法简单明了,尽管它忽略了有关端点上发生事情的一些细节,但与我们仅基于其网络通信来理解每个样本的目标相一致。这种方法也引入了一些偏差。首先,为了减少误报的数量,我们仅考虑已知为不良的样本,即VirusTotal中被四个或四个以上杀毒引擎所标记为恶意样本。其次,由于硬件限制,这些示例只能在基于Windows XP的虚拟机中运行5分钟。在此5分钟内发生的任何加密都会被捕获。

企业数据是从约500个活跃用户和约4,000个唯一IP地址的企业网络中收集的。该网络上的大多数计算机都运行Windows 7,第二流行的操作系统是OS X El Capitan。

3.1 数据集和样本收集

本文使用的恶意软件流量是从2015年8月到2016年5月收集的,而企业流量是在2016年5月的4天和2016年6月的4天期间收集的。在这项工作中,我们对这些数据不同的子集进行了多次实验。

我们分析企业网络上常见的TLS参数与一般恶意软件使用的TLS参数之间的差异。我们首先删除了所有提供有序密码套件列表的TLS流,这些密码套件列表与默认Windows XP SChannel实现中的列表相匹配,这样做是为了确保我们观察到的TLS客户端代表恶意软件的行为,而不是底层操作系统提供的TLS库的行为。这消除了约40%的恶意TLS流和约0.4%的企业TLS流。在此过滤阶段之后,我们使用了数据集中的所有TLS流。从2015年8月到2016年5月,我们收集了133,744个由恶意软件产生的TLS流。在2016年5月和6月的4天中,我们从企业网络收集了1,500,005个TLS流。所有这些TLS流都成功协商了完整的TLS握手过程并发送了应用程序数据。

为了分析不同恶意软件家族使用的TLS参数之间的差异,我们使用了2015年10月至2016年5月之间的具有可识别家族名称的恶意软件样本。表II总结了每个恶意软件家族的样本和流量数量。家族名由VirusTotal杀毒引擎以多数票产生。没有明确家族和流量少于100个的恶意软件样本将被丢弃,该过程将我们从最初的20,548个TLS样本归类为18个家族共5,623个样本。这些样本生成了25,793个TLS加密流,这些流成功地协商了TLS握手并发送了应用程序数据。

解密恶意软件使用的TLS (CISCO)(二)

在本文中,我们还在三个实验中使用了机器学习分类器。在此实验中,我们使用了2015年8月至2016年5月收集的所有恶意TLS流,以及从2016年5月和2016年6月在企业网络TLS流随机抽样的子集。此实验总共有225,740恶意和225,000企业流。为了解决基于Windows XP的沙箱可能带来的偏差,我们还展示了一些数据,这些数据提供密码套件列表,但该列表与默认Windows XP SChannel实现中找到的列表不匹配:133,744恶意和 135,000个企业TLS流量。

在下一组实验中,我们分析了分类器检测由不同恶意软件家族生成的TLS流的性能。为了训练分类器,我们将225,000个企业环境TLS流作为负样本,将76,760个恶意TLS流量作为正样本。测试数据由2015年10月至2016年5月期间收集的已知其家族的TLS流量组成。表II总结了每个恶意软件家族的样本和流程数量。尽管在本实验中我们不删除提供了有序密码套件列表且与在Windows XP SChannel实现相匹配的的流,但我们确实明确了具有此偏向的族。

最后,为了评估TLS握手元数据的恶意软件家族分类,我们对表II中列出的数据使用了10折交叉验证和多分类。同样,在本实验中,我们不会删除提供与该默认Windows XP SChannel实现中找到的列表相匹配的有序密码套件列表的示例,因为所有示例的偏差都相同。

3.2 特征提取

为了提取数据的特征,我们编写了软件工具来从实时流量或捕获的数据包文件中提取感兴趣的数据特征。开源工具将以方便的JSON格式导出所有数据。机器学习分类器是使用传统的流特征,包括传统的“单边通道”特征以及从未加密的TLS握手协议中收集的特征。具体如下:


1、流的元数据:这些特征包括前向字节数、后向字节数、前向数据包、后向数据包;源端口和目标端口;以及流的总持续时间(以秒为单位)。这些特征被标准化为具有零均值和单位方差。

2、包的分组长度和到达时间的序列:在我们的开源实现中,为流的前50个数据包收集包长和到达时间(SPLT)特征。零长度的有效负载(例如ACK)和重传将被忽略。

马尔可夫链用于对SPLT数据(数据包包长和包到达时间)进行建模。对于长度和时间,将值离散化为相等大小的bin,例如,对于长度数据,使用150字节的bin,其中范围为[0,150)的任何数据包都将进入第一个bin,范围[150,300]将进入第二个bin,依此类推。然后构造一个矩阵A,其中每个条目A[i,j]计算第i个bin到第j个bin之间的转移次数。最后,对A的行进行规范化以确保正确的马尔可夫链。然后将A的条目用作机器学习算法的特征。

3、字节分布:字节分布是一个长度为256的数组,该数组对流中每个数据包的有效载荷中的每个字节值进行计数。通过将字节分布计数除以数据包有效负载中的总字节数,可以轻松计算出字节值概率。 机器学习算法将256字节的分配概率用作特征,全字节分布提供了有关编码数据的许多信息。此外,字节分布可以提供有关报头与有效负载的比率、应用程序报头的组成以及是否填充了不当的信息。

4、未加密的TLS标头信息:TLS(传输层安全性)是一种加密协议,可为应用程序提供保密性。TLS通常是在常见协议之上实现的,例如用于Web浏览的HTTP或用于电子邮件的SMTP。HTTPS是HTTP附加TLS 来实现的,它是保护Web服务器和客户端之间通信的最流行方法,并且受到大多数主要Web服务器的支持。HTTPS通常使用443端口。

TLS版本,提供的密码套件的排序列表以及受支持的TLS扩展列表是从client hello消息中收集的。 从server hello消息中收集所选用密码套件和所选TLS扩展。服务器的证书是从证书消息中收集的。 客户的公钥长度是从客户密钥交换消息中收集的,并且是RSA密文或DH/ECDH公钥的长度,具体取决于密码套件。与数据包长度和时间类似,记录长度,时间和类型的是从TLS会话中收集的。

在我们的分类算法中,使用了提供的密码套件列表扩展列表以及客户的公钥长度。在我们的完整数据集中观察到176种密码套件十六进制代码,并创建了一个长度为176的二进制向量,其中将出现在加密套件中的代码所表示的特征值为1,,同样,我们观察到21个唯一的扩展名,并创建了一个长度为21的二进制向量,将出现在扩展列表中的扩展名所表示的特征置为1。最后,客户的公钥长度表示为单个整数值。在分类算法中,总共使用了198个基于TLS客户端的特征。在某些实验中,我们也使用了基于TLS服务器的二进制特征:证书是否是自签名的


恶意软件家族和TLS

尽管恶意软件使用TLS来保护其通信安全,但我们的数据表明,对于我们分析的大多数家庭,恶意软件对TLS的使用与企业网络流量的使用有很大不同。在本节中,我们将从TLS客户端和TLS服务器的角度分析这些差异。

为了比较一般恶意软件和企业流量,我们首先从完整数据集中删除了所有提供与默认Windows XP SChannel实现相同的密码套件列表的TLS流,我们发现,约40%的恶意软件样本的TLS流提供了此列表。为了确保我们分析的TLS流是捕获至恶意软件,而不是底层操作系统的,我们删除了所有这些流。 在此过滤阶段之后,我们使用了数据集中的所有TLS流,从2015年8月到2016年5月,我们收集了由恶意程序生成的133,744个TLS流,这些程序成功地协商了完整的TLS握手并发送了应用程序数据。在2016年5月和2016年6月,我们使用相同的标准从企业网络收集了1,500,005个TLS流。

恶意软件数据收集过程可能会引入偏差。为了解决这个问题,我们还按家族分析了恶意软件使用的TLS客户端和恶意软件连接的TLS服务器。此分析中,我们重点介绍使用默认Windows TLS库的家族以及包括其自己的TLS客户端的家族。该实验的数据如表II。

4.1 TLS客户端

4.1.1 恶意软件与企业软件

解密恶意软件使用的TLS (CISCO)(二)

图1显示在过滤了典型的Windows XP密码套件列表之后,从TLS客户端角分析恶意软件和企业使用TLS之间的差异。几乎100%企业TLS会话提供了0x002f
TLS_RSA_WITH_AES_128_CBC_SHA)密码套件和
0x0035
TLS_RSA_WITH_AES_256_CBC_SHA)密码套件。另一方面,观察到的将近100%的恶意TLS会话提供:

  • 0x000a (TLS_RSA_WITH_3DES_EDE_CBC_SHA)
  • 0x0005 (TLS_RSA_WITH_RC4_128_SHA)
  • 0x0004 (TLS_RSA_WITH_RC4_128_MD5)
  • 这三个密码套件被认为是弱密码,尽管我们观察到的企业通信确实提供了这些密码套件,但它提供的密码套件的频率与恶意流量是不同的。

    当将TLS扩展考虑进来以后,恶意软件和企业TLS client hello消息中的差异变得更加明显。我们观察到企业客户端所使用的TLS扩展具有更大的多样性。几乎一半的企业客户端最多附加9个扩展,但是恶意客户端只能持久地使用一个:0x000d(signature_algorithms),在大多数情况下必须使用RFC。在大约50%的企业流量中观察到以下四个扩展,而在恶意流量中很少观察到:

  • 0x0005 (status_request)
  • 0x0010 (supported_groups)
  • 0x3374 (next_protocol_negotiation)
  • 0x0017 (extended_master_secret)
  • 从客户密钥交换消息中获取的客户的公钥长度。如图1所示,大多数企业流量使用512位(ECDHE_RSA)公钥。相比之下,恶意软件几乎只使用2048位(DHE_RSA)公钥。

    最后,我们将TLS客户端参数映射到使用特定TLS库和配置的知名客户端程序。如图1所示,用于恶意软件和企业TLS连接的最受欢迎的客户端差异非常大。在企业环境中,我们发现四种最常见的客户端配置类似于四种最受欢迎的浏览器的最新版本:Firefox 47,Chrome 51,Internet Explorer 11和Safari9。另一方面,恶意软件是最常用的TLS客户端程序与Opera 12,Firefox 46和Tor 0.2.x客户端参数匹配。

    4.1.2 恶意软件家族

    表III列出了我们可以访问的18个恶意软件家族中最受欢迎的TLS客户端参数。最受欢迎的TLS客户端是Internet Explorer 8,在18个家族中有10个家族使用频率很高。Tor客户端和浏览器在恶意软件家族中非常流行,在Deshacop,Dynamer,Razy,Skeeyah和Toga中最受欢迎。Dynamer,Skeeyah和Symmi都使用了512位(ECDHE_RSA)公钥,而不是恶意软件最常使用的公钥:2048位(RSA),这很可能是基于Windows环境的产物。

    表III还列出了针对每个恶意软件家族观察到的不同密码套件的数量。在这种情况下,如果客户端具有一组不同密码套件和使用的扩展名,则认为该客户端是唯一的。有些家庭的唯一客户端很少,例如Bergat。另一方面,Sality具有大量不同的密码套件。尽管Sality最常用的TLS客户端提供的参数类似于Internet Explorer 8,但它具有数百种密码套件和扩展名的组合。

    解密恶意软件使用的TLS (CISCO)(二)

    4.2 TLS服务端

    4.2.1 恶意软件与企业软件

    图2显示了在过滤使用典型Windows XP密码套件列表的客户端之后,恶意软件连接的服务器与企业TLS客户端之间的差异。过滤是针对服务器统计信息完成的,因为这些客户端会对服务器问候消息中发送的内容产生重大影响。

    如图2所示,针对企业和恶意TLS会话的主要性质,对服务器问候消息的选定密码套件进行了严格划分。约有90%的与恶意软件通信的服务器选择了以下四个密码套件:

  • 0x000a (TLS_RSA_WITH_3DES_EDE_CBC_SHA)
  • 0x0004 (TLS_RSA_WITH_RC4_128_MD5)
  • 0x006b (TLS_DHE_RSA_WITH_AES_256_CBC_SHA256)
  • 0x0005 (TLS_RSA_WITH_RC4_128_SHA)
  • 与企业主机通信的服务器很少选择这些密码套件。 TLS_RSA_WITH _RC4_128_MD5和TLS_RSA_WITH_RC4_128_SHA被认为是弱加密。正如人们所期望的那样,由于恶意软件客户端缺乏TLS扩展,与恶意软件通信的服务器很少选择TLS扩展。另一方面,与企业主机通信的服务器在选定的TLS扩展具有更大的多样性,其中0xff01(renegotiation_info)和0x000b(ec_point_formats)最为频繁。

    我们还分析了来自服务器证书的信息。如预期的那样,我们发现企业端最常通过以下证书主题(Subject)连接到服务器:

  • *http://google.com
  • *http://api.twitter.com
  • *.http://icloud.com
  • *.http://g.doubleclick.net
  • *.http://facebook.com
  • 证书主题的分布具有长尾效应,与恶意软件样本通信的服务器的证书主题也有长尾效应。这些证书主要由具有域生成算法(DGA)生成的,例如http://www.33mhwt2j.net。尽管恶意软件通常与具有可疑证书主题的服务器通信,但是很明显,恶意软件还与许多固有的正常服务器通信,例如,用于连接检查的http://google.com或用于命令和控制的http://twitter.com。下列证书主题是恶意软件的TLS流使用最频繁的主题,由于类似DGA证书主题被视为唯一的,因此它们不会显示在此列表中。

  • http://block.io
  • *.http://wpengine.com
  • *.http://criteo.com
  • http://baidu.com
  • *.http://google.com
  • 图2突出显示了与服务器证书相关的另外两个有趣的特征:证书的有效期(以天为单位)和subjectAltName条目的数量。有趣的是,与比特币钱包与http://block.io的连接很高,严重影响了恶意软件所连接服务器证书的有效期(375天)和subjectAltName条目的数量(3)。

    解密恶意软件使用的TLS (CISCO)(二)

    值得注意的是TLS服务器使用自签名证书的频率。在企业数据中,1,500,005个TLS会话中有1,352个(约占0.09%)使用了自签名证书。在恶意软件数据中,133,744个TLS会话中有947个(约占0.7%)使用了自签名证书,该证书比企业案例的使用频率大约高一个数量级。

    4.2.2 恶意软件家族

    表IV列出了有关恶意软件最常连接的服务器的一些有趣统计信息。 一些恶意家族连接到大量唯一IP地址,例如Symmi和Dynamer。流量最多的系列Virlock仅连接到http://block.io拥有的1个唯一IP地址。

    我们观察了10个使用自签名证书的家庭。ZBot是使用最频繁的家族,这些证书的主题为http://tridayacipta.com,该域名在VirusTotal上有很多引擎标记为恶意域名。

    通用证书主题还允许人们推断恶意软件家族使用的工具以及家族支持的功能。例如,Deshacop和Tescrypt使用* .onion.to作为最常见的认证主题,并且正如预期的那样,它们都具有许多具有TLS客户端配置的实例,这些示例指示它们使用Tor浏览器。 Tor浏览器是Deshacop最流行的客户端,也是Tescrypt的第二流行的客户端。Symmi最常见的证书主题是* .http://criteo.com,这是一个广告服务器,这可能表明Symmi打算执行点击欺诈。

    解密恶意软件使用的TLS (CISCO)(二)

    加密流量分类

    我们对所有分类结果都使用了带l1正则项的Logistics Regression分类器。对于最初的二分类,我们使用收集数据的不同特征子集训练了四个机器学习分类器。第一个分类器使用流元数据(Meta),数据包长度和到达时间间隔(SPLT)的顺序以及字节分布(BD)。第二个分类器仅使用TLS信息(TLS)。 第三个分类器使用与第一个分类器相同的特征进行了训练,并增加了TLS客户端信息,特别是提供的密码套件、扩展名和客户端的公钥长度。第四个分类器使用了所有特征,还有一个附加的特征:服务器证书是否为自签名(SS)。

    5.1.1 恶意软件与企业环境

    此实验总共有225,740恶意TLS流和225,000企业TLS流。表V显示了10折交叉验证结果(测试数据包含正样本和负样本)。我们看到,使用所有可用的特征都会大大改善结果。将1 1/10,000的错检率(FDR)被定义为,在正样本中每10,000个正样本只允许有1个假阳性(错分)。如这些结果所示,不使用TLS标头信息会导致性能显着下降,尤其是在固定的10,000分之一固定FDR的重要情况下(调节阈值)。删除Windows XP SChannel TLS流不会影响TLS标头信息的总准确性。分类器基于所有数据,但确实在10,000分之一的FDR中将性能降低了5%。

    解密恶意软件使用的TLS (CISCO)(二)

    解密恶意软件使用的TLS (CISCO)(二)

    为了测试分类器对不同恶意软件家族生成的TLS流的检测能力,我们使用225,000个企业TLS流作为负样本,2015年8月和9月期间收集的76,760个恶意TLS流作为正样本,以此来训练4个分类器。用2015年10月至2016年5月收集的TLS流量作为测试数据,如表II。

    表VI列出了四个分类器对每个家庭的的分类准确性(只测试正样本,即恶意软件TLS流)。由于仅使用恶意软件数据来测试经过训练的分类器,因此该实验的误报是不确定的,因此不会报告。在2015年8月和9月的恶意软件训练数据中,没有任何SHA1匹配项。代表如下:Bergat, Yakes, Razy, Dridex。

    在大多数情况下,将传统的流元数据,典型的单边通道信息以及TLS典型的特征相结合,可以得到性能最佳的机器学习模型。在所有家族中,使用所有特征训练的分类器在Deshacop上的表现最差,真阳性率为96.1%。仅针对主要使用与Windows XP SChannel客户端使用的密码套件类似的密码套件的恶意软件系列,我们使用所有特征训练的分类器在Tescrypt上的表现最差,真实阳性率为97.6%。这两个家族最常访问服务器证书主题为* .onion.to的服务器,并使用TLS客户端配置来指示Tor浏览器进行某些TLS连接。 这特别有趣,因为Tor浏览器的目标是保护用户的隐私,但在这种情况下,它的用户是恶意软件家族。

    仅基于TLS特征的分类器在配置与基于Windows XP SChannel的客户端相匹配的TLS客户端的恶意软件家族中能够表现良好,但是如果该恶意软件在另一个操作系统上运行,则不能保证保持这种结果。对于仅使用TLS客户端配置且与基于Windows XP SChannel的客户端不匹配的TLS客户端配置的大多数系列而言,仅使用TLS特征的分类器表现最差,但Toga和Virlock除外,这两个系列在更改数据集中的TLS客户端参数方面都做得很差,并且都使用了指示客户端较旧版本的TLS客户端参数:Toga→Tor 0.2.2和Virlock→Opera 12。

    机器学习分类器能够对大多数恶意软件家族正确分类,但Dridex除外。Dridex是在训练数据中没有使用的四个家族之一,分类器对其他三个家族Bergat,Yakes和Razy的分类总准确率约为96%-100.0%。在Bergat和Yakes的情况下,可以期望达到良好的性能,因为这些家族提供了与默认Windows XP SChannel实现中找到的列表匹配的有序密码套件列表。

    解密恶意软件使用的TLS (CISCO)(二)

    图3从客户端的角度显示了Dridex对TLS的使用情况。与其他大多数家族不同,Dridex最常选择:

    · 0x002f (TLS_RSA_WITH_AES_128_CBC_SHA)

    图2表明,这种密码套件在企业TLS会话中并不罕见。Dridex还使用一些TLS扩展,并在client hello消息中提供许多当前的密码套件。

    图3还比较了Dridex的TLS使用情况和Virlock的TLS使用情况。 Virlock就是一个恶意家族的例子,该恶意家族对我们观察到的每个样本都使用相同的TLS客户端,并且能够轻松进行分类,即所有四个分类器均达到100%的准确性。 Dridex提供了各种强大的密码套件,而Virlock提供了一套较小的过时密码套件。 Virlock还仅播发signature_algorithms TLS扩展。 这两个系列之间的另一个重要区别是,Virlock一次都没有在整个数据集中更改其TLS客户端的行为。 Virlock始终使用与Opera 12相同的客户端参数。Virlock缺乏适应性,因此对于机器学习或基于规则的系统进行分类非常简单。 Dridex使用多个TLS客户端在检测功效方面产生了显著差异。

    来源:白面葫芦娃A

    声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

    上一篇 2020年6月17日
    下一篇 2020年6月17日

    相关推荐