STUXNET、SUNBURST对比分析 (三)：自动检测失效原因分析

我们在“十年：STUXNET、SUNBURST对比分析（二）”中曾提到过，检测设备在STUXNET、SUNBURST的发现过程中，出现了全部失灵的情况。本文我们将对出现这一情况的原因进行分析。

STUXNET和SUNBURST可用于捕捉的点

尽管STUXNET、SUNBURST在隐藏方面做的相当出色，但也并非无懈可击。因为作为恶意代码，其它恶意代码普遍具备的功能它们也得具备，其它恶意代码表现出来的特征它们也会表现，因此针对一般恶意代码的检测手段也能作用到它们身上。

下面，我们抛开STUXNET和SUNBURST被发现的真实场景，从恶意代码的普遍规律出发，看一下它们存在哪些可能会被检测设备捕捉到的点。

1. STUXNET可用于捕捉的点

作为一个可控“蠕虫”，STUXNET必须具备持续驻留、C2通信、传播扩散这三方面的能力。在这三方面，它都存在可被捕捉的点。

1) 启动项

任何一个需要持续驻留的恶意程序，不管是后门也好，木马也好，“蠕虫”也好，必须要有一个启动点，以保证每次机器重启后，它都能再次运行起来。

STUXNET的启动点对应的是注册表中的以下项：

LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\MRxCls\\

”ImagePath” = “%System%\\drivers\\mrxcls.sys

这是注册表中的普通一项，检测到它的存在还是很容易的。

2) C2通信

STUXNET的C2通信采用HTTP协议，其过程如下：

因为扩散过程中被感染机器有些是不联网的，所以在与C2通信之前，需要先判断一下被感染机器是否联网，STUXNET采用的方法是检查能不能访问以下两个站点：

www.windowsupdate.com

www.msn.com

这是STUXNET C2通信的一个明显特征。

后续与C2之间的交换数据经过了加密，但加密方式是简单的异或，密钥固定。其中，到C2的数据所用密钥是：

从C2出来的数据所用密钥是：

像这种简单的加密方式，统计特征应该很明显。站在后知者的角度，通过流量分析发现STUXNET是有机会的。

3) MS08-067漏洞利用

为了达到传播扩散的目的，STUXNET用到了3个漏洞：MS10-046、MS10-061、MS08-067。其中的一个0day漏洞MS10-046，因为实现上存在缺陷，成为了暴露其存在的关键。但从恶意代码检测的角度来看，MS10-046与MS10-061因为是0day，要实现对它们的检测并不容易。

对STUXNET构成最大威胁的是MS08-067。这是因为：其一，MS08-067是一个已曝光的漏洞，该漏洞产生的原因、漏洞利用的方式，对于当时的安全设备厂商来说并不陌生。其二，当时距MS08-067曝光的时间并不太久，它属于重点被监控对象。其三，漏洞利用只要发现，就能断定恶意行为存在，不存在误报的可能。

2. SUNBURST可用于捕捉的点

SUNBURST作为一个完美“融入”SolarWinds Orion系统的后门，其传播扩散、持续驻留功能都由Orion系统提供，要从这两方面入手检测到它的存在，是不太容易的事情。

SUNBURST后门有一个问题，就是它的部分代码借用自其它APT行动，但由于不是核心功能，通常不会有人将其作为检测依据。这一点主要适用于溯源，而不太适用于检测。

但是，SUNBURST要取得效果，终究要采取第二阶段行动。因此，作为第二阶段部署通道的第一阶段C2通信，以及第二阶段行动，这两方面存在的问题，都可能成为SUNBURST被发现的点。

1) 第一阶段C2通信

STUXNET第一阶段的C2，包含了两种类型的通信：

一是利用DNS协议的CNAME项传递控制信息，在知道它采用该策略之前，通过这一点发现SUNBURST还是很难的。

二是使用HTTP协议与C2间交换信息。根据后面分析的情况来看，数据具有很明显的特点，这一点是可以利用的。

2) 第二阶段行动

SUNBURST的最大问题还是在第二阶段。这一阶段的RAT需要有持续驻留、C2通信、任务执行等功能，这些不可避免地都会留有痕迹；攻击者在第二阶段执行的大量操作，比如窃取凭证、横向移动、转移数据等，更是会留下大量痕迹。

安全研究人员也正是通过这些痕迹，追溯到了SUNBURST。关于这个，可以从Mark Russionovich的“如果你安装了Sysmon，或者运行了Procmon、Procexp、Autoruns等工具，Sunburst将离你而去”中去体会。

检测设备失效原因分析

尽管我们依据STUXNET、SUNBURST的调查结果，“事后诸葛”般地列举了可用于发现它们的一些检测点，但最终导致STUXNET暴露却是我们认为很难检测的、造成了系统崩溃的0day漏洞MS10-046。而导致SUNBURST暴露的原因则是，FireEye意外发现假冒的职员登记信息，这是攻防双方先前都无法预料的。

为什么我们认为可以用来检测的点，在实际检测中就不能起作用呢？表面上看起来是：

因为mrxcls.sys用窃取的合法证书进行了签名，看起来跟正常的驱动程序没有区别，所以检测设备即使发现注册表中增加了启动项也不会报警。
因为STUXNET采用进程注入技术，将通信模块注入到了正常的浏览器进程中，因为检测设备不对浏览器的上网行为进行监测，所以发现不了不联网机器却试图访问互联网这样的异常行为。
因为STUXNET的C2通信数据经过了加密处理、SUNBURST的C2通信数据经过了变形处理，所以分析起来比较困难。
……

但这些，并不是造成检测设备失效的根本原因。我们认为，造成检测设备失效的根本原因有：

1. 检测设备的数据分析深度不够

我们知道，人是通过分析数据，来确定恶意行为是否存在的。分析的内容，主要是程序代码和流量数据，其它如日志分析等，是建立在别人代码分析和流量分析基础上的，本质上也属于代码分析和流量分析的范畴。

通过分析数据发现恶意行为的工作，许多检测设备也在做。代码这一块儿，人工做的称作代码逆向分析，检测设备做的称作行为分析；流量这一块儿，人工做的和检测设备做的都称作网络流量分析。

检测设备的数据分析，其实是对人的数据分析的模仿，但由于缺乏人的认知能力，机器分析在深度上是远不及人工分析的。以代码分析为例，检测设备采取的方式主要就是对函数进行拦截，这实际上等同于逆向分析中的设置函数断点。我们知道，设置函数断点只是逆向分析工作的一部分内容，其作用主要是为分析人员提供一个切入点，真正起决定作用的是分析人员的分析、理解、归纳、推理。还没有听说过有哪个人，单凭设置几个函数断点，就能搞清楚某段代码功能的。流量分析同样如是。

因为缺乏分析、理解、归纳、推理等方面的能力，检测设备的数据分析能力，是远不能达到识别恶意行为的要求的。

2. 恶意行为识别（通用）模型难以建立

虽然机器在认知上达不到人那样的高度，但能不能采用机器学习等技术，使得检测设备的能力尽可能达到恶意行为识别的要求呢？答案是，很难。

机器学习，原来的名称叫模式识别。顾名思义，就是要想让机器做恶意行为识别这方面的工作，首先得为它提供一个恶意行为识别模型。但是，要建立这样的模型很难。

还是以恶意代码为例。恶意代码需要具备的特殊功能，一些正常程序也会具备；恶意代码采用的很多特殊技术，一些正常程序也会采用；恶意代码表现出来的特征，一些正常程序也会表现。甚至于，恶意代码跟与它对抗的防御系统，采用的根本就是同一套技术体系。这样的情况下，很难因为某段代码具备什么功能、采用什么技术、表现什么特征，就断定它是恶意的还是正常的。异常流量识别具有同样的问题，这是难以建立恶意行为识别（通用）模型的根本原因。

曾经有安全公司，弄出来一个恶意行为识别模型，并将其用在了产品中。应用效果是，能查出来的恶意代码类型确实是多了，但同时，许多正常程序也会被“杀”。其它安全公司的防护软件被“杀”，具有特殊保护功能的软件被“杀”，就是用户自己编写的程序都被“杀”，很难说这样的模型是好是坏。

3. 检测设备需要有案例作为支撑

检测设备的数据分析能力达不到识别恶意行为的要求，又缺乏有效模型来接近于满足要求，最终，检测设备还是以特征匹配作为恶意行为识别的主要手段。而这些特征的获得，主要靠的是人工对已有案例的分析。

如果没有案例作为支撑，自动检测就会失灵。比如， STUXNET事件里，不联网机器访问msn.com这样明显的异常行为，因为过去没有碰到过类似情况，所以就检测不出来。

而一旦有了案例作为支撑，自动检测就会十分高效。比如，通过人工分析澄清STUXNET、SUNBURST的工作机制并提供检测特征后，STUXNET感染的10多万台机器、SUNBURST攻陷的几十个机构很快就被识别了出来。

4. 检测设备判断恶意行为的依据不在根上

也不是有了案例作为支撑，自动检测就万无一失。比如出现在STUXNET里的MS08-067，漏洞产生的原因很清楚，漏洞利用的方式也很明白，还是没被检测设备识别出来，只能说检测设备在识别MS08-067的过程中，判断依据不在根上。

类似的情况还有很多，比如“永恒之蓝”，都出来这么多年了，漏洞产生的原因早为人所知，漏洞利用方法也早被研究人员掌握，现在不还是有人在用吗？

结束语

以上，我们对造成检测设备在STUXNET、SUNBURST发现过程中集体“失语”的原因进行了分析。归纳起来就是，STUXNET、SUNBURST都是“新生”事物，过去没有出现过相似案例，缺乏足够多与它们相关的信息，而机器的分析能力又不足以对“新生”事物属于什么类型做出判断，所以出现了“失灵”情况。

至于造成这些原因的原因，有些是因为工作没到位，比如MS08-067漏洞利用的检测问题。更多的还是因为人的认知尚未达到应有的高度，相关工作无法展开，比如代码和流量的自动分析问题，比如恶意行为识别模型的建立问题。

最后想说的是，这十年其实是网络安全领域进步最快的十年，出现了一系列重要成果。无论是在认知上，还是在实践上，无论是在理论研究上，还是在技术实现上，都取得了重大进展。关于这些，我们将在以后适当的时候，进行适当讨论。

声明：本文来自国家网络威胁情报共享开放平台，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。