一、小序

2010年7月，“震网”（Stuxnet）蠕虫攻击事件浮出水面，引发了国际主流安全厂商和安全研究者的全面关注，安天、卡巴斯基、赛门铁克等安全厂商，Ralph Langne等著名安全研究者，以及多国的应急组织和研究机构，都投入到了全面的分析接力中。最终使这场攻击的大量细节被呈现出来：这是一起经过长期规划准备和入侵潜伏作业；借助高度复杂的恶意代码和多个零日漏洞作为攻击武器；以铀离心机为攻击目标；以造成超压导致离心机批量损坏和改变离心机转数导致铀无法满足武器要求为致效机理，以阻断伊朗核武器进程为目的的攻击。

9年的时间过去了，这一安全事件依然在我们的研究视野中。我们从2010年7月15日展开对震网的分析工作，搭建了模拟环境，在9月27日发布了《对Stuxnet蠕虫攻击工业控制系统事件的综合分析报告》[1]，在后续形成了对其传播机理进行分析的《对Stuxnet蠕虫的后续分析报告》[2]，以及分析其对工业生产过程作用机理的《WinCC后发生了什么》[3]系列分析报告。

安天提出了震网与毒曲（Duqu）同源的猜测，并先后发表了两篇验证性报告，并启动了对火焰（Flame）恶意代码的马拉松式的模块分析。在工作推进中，我们逐步认识到震网、毒曲、高斯（Gauss）、火焰，这些高度复杂的恶意代码间存在着同样的背景联系。这些研究工作对我们后续展开对方程式组织（Equation）的深度分析起到了非常重要的作用。

由于历史原因，其中部分研究文献并未公开，而一些分析进展是碎片化的，虽然在我们的对外技术演讲中有所提及，但并未作为文献发布。这是我们编写这篇文献的原因之一。震网的整体运行框架、USB摆渡机理和传播失控分析，以及图解Tilded框架与Flamer框架的关联，将震网、火焰、毒曲、高斯、Fanny、Flowershop之间的关系进行串接的相关章节，是对这些成果的整理。

今天看来，在前期分析震网系列事件的过程中，我们缺少一种真正意义上的框架化方法。依然更多的是从自身习惯的反恶意代码视角来看待整个攻击过程。尽管我们给震网这样的复杂攻击提出了一个A2PT（即高级的高级可持续性威胁）的命名，但分析中始终缺乏作业到作战视角的思考。在相关专家的指导下，我们对网空博弈、敌情想定有了新的体悟，逐渐从威胁框架视角进行方法论切换，实现自我能力完善。也希望通过威胁框架这一视角来解读“震网”这场看起来依然高度复杂的“昨天的战争”。

本文也详细解读了一个值得思考的问题，震网作为一种没有感染属性的蠕虫，为何会有大量的样本存在。这个原理我们在早期的分析工作中已经发现，即震网的载荷投放程序，在每落地一台机器时，会有一个内嵌配置数据的自我更新，从而导致震网的每次落地形成的主执行体的HASH均不同，同时其实际攻击载荷多数均被包裹在主DLL之中，并不落地。而震网的相关域名则是在其已经达成其主体作业效果的情况下才被曝光的。这从某种意义上也昭示了面对更高级、隐蔽的攻击行动，以HASH、域名等为主体的威胁情报实际上早就面对着无效的危机。

图 1-1 震网事件时间轴

二、为什么是震网

在信息技术发展历史上，出现过大量典型的安全事件，但为什么“震网”被视为具有威胁里程碑意义？震网被认为是第一个以现实世界中的关键工业基础设施为目标的恶意代码，并达到了预设的攻击目标，或者说，这是第一个“网络空间”意义上的重大攻击事件，而非传统的网络攻击事件。尽管此前也存在着一些通过信息攻击手段影响工业设施的传闻，但基本都缺乏技术层面的实证支撑。

从我们此前提出的观点来看，震网的里程碑意义并不是在于其相对其他简单的网络攻击的复杂性和高级性，而在于其证实了通过网络空间手段进行攻击，可以达成与传统物理空间攻击（甚至是火力打击）的等效性。在2016年的报告中，我们研究人员将上世纪70、80年代的“凋谢利刃与巴比伦行动”（在1977年~1981年间发生的以、美联合，在两伊战争期间针对伊拉克核反应堆进行军事打击的事件）与震网事件进行对比分析看出，通过大量复杂的军事情报和成本投入才能达成的物理攻击效果仅通过网络空间作业就可以达成，而且成本也大大降低。正如美国陆军参谋长前高级顾问Maren Leed所讲的——网络武器可以有许多适应环境的属性，从生命周期的成本角度看，它们比其他的武器系统更为优越[4]。

表 2 1 两次针对中东国家核计划所采用的军事行动与准军事行动的对比分析

表 2-2 伊朗基础工业体系遭遇渗透的情况

三、震网整体结构和运行逻辑

震网的结构非常复杂。其中又经历了从0.5到1.x的版本更迭，其破坏机理从以干扰离心机阀门、造成超压导致离心机批量损坏调整为修改离心机转数。同时其开发框架也发生了变化。我们以流行更为广泛的1.x版本为对象，进行整体结构和运行逻辑梳理。震网的核心是仅在内存中解密存在的DLL文件（以下简称主DLL文件）。DLL文件包含32种不同的导出函数以及15种不同的资源，每一个导出函数都有不同的控制功能，其中主要涉及导出函数15（初始入口点）、导出函数16（安装）、导出函数32（感染连接的移动设备，启动RPC服务）、导出函数2（钩挂API以感染Step7工程文件）等；每个资源也分别执行不同的功能，主要涉及资源250、资源201、资源242等；导出函数正是利用这些不同功能的资源来控制震网执行不同的分支操作。

表 3 1 Stuxnet Dropper资源列表

        Stuxnet Dropper的资源在安装执行过程中会释放载荷，震网落地文件如表3-2所示。

按资源类型，对照其编译时间戳，获得PE类型资源版本迭代，如图3-1所示，由图能够看出资源202、210都存在3个可能的版本，资源208存在2个可能的版本，其余各资源都仅有1个版本。另外资源207、231仅存在少数样本，在后续版本的Stuxnet中已经删除。

图 3-1 PE类型资源版本迭代

ANTIY CERT基于对震网样本集及已有数据的分析，绘制了震网整体运行框架，它包含传播和安装执行。

图 3-2 震网整体运行框架图

震网的传播主要包括两种方式，一种是移动设备感染，利用LNK漏洞或者通过autorun.inf文件进行传播；另一种是网络传播，涉及WinCC数据库感染、网络共享传播、打印机后台处理程序漏洞传播、Windows服务器漏洞传播等多种方式。这两种传播方式虽然不同，但最终都会释放主DLL文件，进行后续的安装和执行操作。震网感染目标系统后，会启动RPC服务器监听网络，将网络上其他感染计算机都连接到RPC服务器，并查询远程计算机安装的震网版本，以执行对等通信和更新，如果远程计算机上的震网版本较新，则本地计算机就会请求新版本并自我更新，如果远程机器上的震网版本较旧，则本地计算机上的震网就将自身副本发送给远程机器。这样，震网可以在任何感染机器上更新并最终传播到所有机器。

在安装执行中，传播释放的主DLL文件首次加载时调用导出函数15执行一系列检查工作，包括检查配置数据是否为最新、检查操作系统是否为64位、检查操作系统版本是否匹配，如果不符合其安装执行要求，则退出；此外，检查目标系统是否具备管理员权限，如果不具备，则利用资源250中两个当时的零日漏洞进行提权以获取最高权限；之后，检查目标系统安装了哪些反病毒软件以及哪个进程适合注入；导出函数15完成上述规定的检查后，震网就会调用导出函数16。

导出函数16是震网的主安装程序。首先，检查目标系统配置是否匹配、注册表键值是否为特定值、当前时间是否小于终止时间，如果不符合这些安装执行要求，则退出；继续执行，震网通过创建全局互斥量与不同的组件通信，并再次检查目标系统当前时间，确保只在小于终止时间的目标系统上执行；从磁盘中读取其加密版本，解密、加载到内存中，从新加载的文件中调用导出函数6，获取自身配置数据的版本信息，如果与磁盘文件的版本相同，则继续执行；震网提取、解密资源201和资源242，并将两个驱动文件写入磁盘，分别用于持久化和隐藏恶意文件，为了规避检测，震网会修改这两个文件的时间以匹配目标系统目录下的其他文件时间；创建rootkit服务和注册表，以实现震网的持久化，并再次创建全局互斥量；为了继续安装和传播，震网将控制权传递给其他导出函数，一种是将主DLL文件注入service.exe进程，并调用导出函数32，以感染新连接的移动设备，以及启动RPC服务器，另一种是将主DLL文件注入Step7进程，并调用导出函数2，以感染所有指定的Step7文件。

四、威胁框架视角下的震网解读

能够研发类似震网的复杂高级的恶意代码，是源自高级网空威胁行为体具有充足资源和成本支撑能力。其作业过程具有庞大的工程体系和人员团队为支撑条件，是一系列复杂的动作组合。与此同时，复杂的过程并不必然全部由“高级”攻击手段和“高级”装备支撑。防御方的一些低级配置错误和未及时修补的漏洞会成为威胁行为体攻击的入口；高级网空威胁行为体也会劫持和利用低级网空威胁行为体所掌控的僵尸网络等资源，这些都使局面更为复杂。

解读复杂的攻击行动，并驱动防御的改善，需要有更理想的结构化方法。杀伤链等模型用于解构震网式的复杂攻击，依然显得不足，需要进一步改善。威胁框架作为一种对攻击过程更为结构化和数据化的描述方法，开始成为改善防御能力的威胁认知基础。当前较为流行的威胁框架主要有MITRE提出的ATT&CK，和NSA提出的《NSA/CSS技术网空威胁框架》（NSA/CSS Technical Cyber Threat Framework）。后者对前者做了一定的借鉴工作。鉴于NSA/CSS技术网空威胁框架，更具有情报机构的背景，因此更适合推演类似震网级别的A2PT攻击。

从威胁框架出发，针对威胁每个阶段、逐个行为推演，无论对评估当前防御体系及相关安全产品能力的有效性和合理性，还是对形成体系化的防御规划与建设目标，都是一种有益的工作。2019年6月，我们发布的“方程式组织”攻击SWIFT服务提供商EastNets事件复盘分析报告中[5]，将事件涉及的威胁行为映射到了“NSA/CSS威胁框架”V2版本中。

将震网事件涉及到的威胁行为映射到威胁框架的类别与动作，如图4-1所示。

图 4-1 震网事件映射到威胁框架

在震网行动中共涉及21个目标中的83种行为，其中包括推测的和确定执行的行为。

表 4-1 震网事件中涉及的类别与动作

针对震网级别的攻击，需要重点关注的是其决策和准备过程，类似如此复杂精密的攻击，如果不搭建一个完全等效的模拟靶场环境，是很难达成效果的。如果仅仅把目光放在恶意代码和漏洞利用工具本身，而不能就行动管理与资源保障、目标勘察与环境整备等前期环节进行深入的分析，就一定程度上失去了引入威胁框架的意义。但无疑，这一部分的分析更为困难和复杂。

从威胁框架视角重新梳理震网，也让我们可以解开“Michael之问”。2014年3月，洛克希德•马丁公司的高级研究员Michael在博客上对震网事件的意图和能力两个方面进行了分析，提出了“Why Stuxnet Isn't APT？” [6] 这一设问。在这篇文献中，Michael 以震网的传播失控和明显的物理空间后果不符合APT的高度定向性和隐蔽性、震网比常见的APT攻击更为高级等方面进行了论述，其更倾向于震网是一种作战行动，而非APT攻击。Michael关于震网是一种比APT更高级的观点，与我们将震网级别的攻击命名为A2PT观点是相近的。但从Michael的根本观念是将APT与CNE（网络情报利用）相映射的，因此当震网以达成CNA（网络攻击、作战）为目的的情况下，则提出这种质疑是有道理的。但在现实场景下，很难生硬的把CNE与CNA割裂开，CNE通常是CNA的基础。CNE转化为CNA可能只是指令与策略的调整。在威胁框架体系中，CNA的动作是致效能力运用中的中的若干动作环节，这就将CNE与CNA良好的统合到一个框架体系中，从而能更好的推动分析与防御改善的体系的改善。

五、震网的USB摆渡与传播“失控”的原因

震网是针对非常特殊的工业场景进行攻击的恶意代码，2019年，有相关媒体报道，震网病毒进入到伊朗相关物理隔离的工业网，是依靠荷兰情报人员在攻击方的要求下招募了“内鬼”[7]。而在内网中，震网主要的传播方式为借助USB摆渡+基于漏洞的横向移动。其预设的攻击场景是与互联网隔离的内部网络。我们在最早的分析报告[1]中，对于其传播机理，以图5-1进行了说明：

图 5-1 样本的多种传播方式

整体的传播思路是：染毒U盘利用快捷方式文件解析漏洞，传播到内部网络；在内网中，通过快捷方式解析漏洞、RPC远程执行漏洞、打印机后台程序服务漏洞，实现联网主机之间的传播；最后抵达安装了WinCC软件的主机，展开攻击。在这一过程中，亦存在染毒主机对插入的U盘进行感染的过程，但经过我们分析这一动作并非是无条件的。

图 5-2 U盘感染过程中配置文件解析

感染震网的计算机会监控接入的设备，一旦发现U盘插入且满足条件即开始写入U盘摆渡文件，具体条件如下：

当前时间的U盘没有被感染；

根据配置标记（不是默认设置）来感染磁盘，如果默认配置不感染，那么感染的发生取决于日期；

感染当前计算机少于21天；

U盘至少有5MB的剩余空间；

U盘至少有3个文件。

USB文件和加载攻击逻辑如图5-3所示，含4个适用于不同Windows版本的LNK快捷方式漏洞（CVE-2010-2568）文件和2个TMP文件（~WTR4141.tmp是USB Loader，~WTR4132.tmp是Dropper，均为DLL格式，文件属性为隐藏、系统），震网通过rootkit隐藏这6个文件，因此被震网感染的计算机上并不能看到U盘里的这些文件。

U盘摆渡攻击过程为：被感染的U盘插入新的计算机，用户打开此U盘，系统开始遍历U盘目录文件，当遍历到LNK文件时漏洞触发加载~WTR4141.tmp执行，~WTR4141.tmp首先会挂钩文件相关函数隐藏这6个文件（在打开U盘的一瞬间可以看到这4个LNK文件，如果开启了显示隐藏和系统文件选项，还可以看到2个TMP文件，但瞬间漏洞触发这6个文件全部隐藏在文件夹下看不到了），随后~WTR4141.tmp在内存中加载调用~WTR4132.tmp完成震网的主模块执行。

图 5-3 USB文件和加载攻击逻辑示意图

Stuxnet是否感染到U盘，取决于加密配置文件mdmcpq3.pnf中的多个值，包括：

偏移0x6c、0x70、0xc8处的标记位；

偏移0x78、0x7c处的时间戳；

偏移0x80、0x84处的数值。

只有当每个值对应的条件都满足时，才会感染U盘。其中，偏移0xc8处的位默认设置为不感染。

Stuxnet不会主动修改配置数据，配置的更新通过版本更新来完成。因此，我们认为它是尝试连接因特网来判断自己是否在内部网络中。如果是，就只通过其他途径传播；只有通过连接服务器或其他被感染主机更新之后，才感染U盘。

当Stuxnet感染U盘时，拷贝多个.lnk快捷方式文件和两个.tmp文件到根目录。这两个.tmp文件，一个是用于隐藏它们自身的驱动程序，带有数字签名；另一个是病毒体本身以及一个投放器，配置信息已经存在于病毒体中。

根据赛门铁克在2010年7月-10月监测的震网攻击数据，全球155个国家的计算机被感染，其中约60%的受害主机位于伊朗境内[8]。对于一次被认为是应具有高度定向性质的作业行动，却呈现出发散性传播效果的原因，目前各分析方给出了多种不同猜测：

第一种猜测是，各种原因导致了传播失控。尽管震网本身的USB摆渡+横向移动设计，使其只能在内网传播。但由于其本身的传播和攻击策略是基于隔离网络目标设计，要达成一种无实时远控作业，因此多数条件下只能以预设停止传播时间等因素，而无法像基于互联网的攻击作业一样，进行远程遥控和调整。由于蠕虫感染了供应商工程师带入现场的笔记本设备，之后又被带入到供应商自身的网络中和其他客户的内网中。内网的VPN互联也加剧了这种传播，最终导致震网的传播失控。这种观点与一些实际情况有一定冲突，比如震网0.5版本，作业周期较长，达成了攻击目的，但并未发生扩散传播。

第二种猜测是，这是作业方为获取更多信息有意为之。其目的是根据感染链条，进一步了解伊朗核工业体系供应商的情况。德国控制系统安全顾问Ralph Langner在《Stuxnet’s Secret Twin》（震网蠕虫的秘密变种）[9]中的一个推测是这种外部扩散，是因为攻击者希望借机获取到与伊朗相关设施的供应商的情报。他指出“鉴于Stuxnet将受感染系统的IP地址、主机名以及基本配置信息上报给其C&C服务器，看来攻击者显然预期（并接受）传播到非军用系统，且相当渴望密切监测它—攻击者最终将获取在纳坦兹工作的承包商以及其客户的信息，甚至伊朗秘密核设施的信息。”

第三种猜测是作业方为了掩盖定向攻击意图，以感染范围的扩大提升取证溯源的难度。包括干扰对真实攻击目标更准确的判断和定位。

第四种猜测是攻击方展示能力，达成对他国恐吓甚至讹诈的需要。如果事件单一的发生于伊朗，可能导致此事件最终不会浮出水面。而只有放任其“越狱”传播，才有可能更快达成此种效果。在《Stuxnet’s Secret Twin》（震网蠕虫的秘密变种）一文中，Ralph Langner同样猜想，“Stuxnet被发现意味着行动的终结，但是它的实用性并不一定结束，它将向世界展示网络武器在超级大国手中可以做什么。因为不同于实体军事装备的展示，阅兵时是无法展示U盘。攻击者也可能关注另一个国家，最坏的情况下是一个对手；而且将第一个证明其在数字领域的能力--这个场景简直可以说是超级大国历史上的另一个Sputnik（放卫星）的时刻。所有这些理由使得攻击者不必太过担心被检测到。”

震网的发散性传播到底是一种“失控”，还是攻击方有意所为，或者两者因素都存在。最终的效果可能并非是某个单一原因，而是多个因素的组合。

六、震网为何有数千个样本？

作为一种目标高度定向的攻击行动，一个曾令人费解的事实是，震网并不具备感染其他宿主文件的属性，但却有大量的样本存在。

在恶意代码对抗工作中，样本被视为一种重要的基础资源。样本被视为恶意代码所对应的一种实体文件形态，包括带有感染式病毒的宿主文件、非感染式恶意代码的文件、以及恶意代码所存在的扇区或内存的文件镜像。在威胁对抗的深度从最初的检测、查杀，逐渐扩展到响应，深度机理分析和溯源中，我们也发现对样本的需求和定义开始发生一些变化。调查/猎杀意义上的样本和传统检测意义上的样本存在着差异，传统检测意义的样本既包含在现场场景中所采集的文件，同时也包含了为了测试反病毒引擎的能力以及分析中所二次构造出的样本变换结果。对于检测和清除能力来说，进行这种样本构造是必须完成的，例如在样本规范中，特别是对于感染式病毒来说，为保证检测和清除效果的检验，相关业内标准在DOS时代就提出过根据DOS_COM、DOS_MZ等文件大小，被感染文件要达到规定的数量，对于变形病毒的样本，还有需要构造出更多数量的样本的要求。而对调查/猎杀意义来说，在攻击场景中客观存在则成为一种重要的需要被标识出的样本属性。

我们捕获的震网样本**是数以千计的，但这些样本可以分成几个不同的标识维度，基于U盘摆渡的原始载荷形态、在主机上落地的文件、不落地的模块（需要静态拆离或动态Dump）等等。一类是从其中拆解出的最终攻击载荷（在实际的攻击中多数是不落地的）和一些辅助的驱动等。从磁盘介质提取的实体文件数量较多的主要分为三种：攻击载荷释放器Dropper（原始文件名为~WTR4132.tmp）、移动介质载荷加载器USB Loader（~WTR4141.tmp）和LNK漏洞利用文件，其中Dropper样本数量呈现发散态，从我们所掌握的数量来看，在千数量级别。而最终的攻击功能模块载荷和辅助驱动在百数量级，总数呈现收敛态。

震网样本集的分类情况如图6-1所示。

图 6-1 震网样本集分类

ANTIY CERT分析发现，造成震网样本集基数较大的原因是：

1. Dropper样本在落地时写入目标配置导致文件变化

攻击载荷释放器Dropper存在一个名为stub的资源段，攻击载荷（即主DLL）即存在于这个字段中。而在病毒落地时，stub段中存储的配置数据会被当前感染节点的相关信息数据更新，这是导致震网样本集数量多的一个最主要原因。也就是说，每次落地震网都会再形成一个HASH不同的Dropper。这就导致了震网的样本集从HASH数量上看，呈现发散状态。而样本集中Dropper功能的真实“版本”是有限的，Dropper中98.84%的导入表相同，有91%的样本text段单独拆离出的文件是完全一致的，MD5值均为17e2270d82d774b7f06902fa7d630c74，这是一个发生规模感染的Dropper主力版本。

图 6-2 Dropper导入表统计

stub段作为主DLL存放的位置，其布局解析如表6-1所示。

表 6 1 stub段布局解析

解密主DLL的函数如下：

图 6-3 主DLL函数解密

主DLL之后的数据中存在加密的配置信息，能够在感染过程中控制震网的具体行为，使得震网具备在无法远程控制的情况下，依然可以按照预设策略工作，确保其复杂的作业可以成功。其配置文件也记录了被感染机器信息和时间等特征，这样做的目的可能是攻击者希望这些信息在感染时被提取记录，一旦联网时可以直接将相关信息提交给C2，而不用做二次提取操作，减少对主机环境操作，以减少暴露的机会。

部分解密后的配置信息如下：

图 6-4 部分解密后的配置信息

表6-2是部分配置内容的解析，这些值能够控制震网在受害主机上的行为，具体内容包括：通过+A4值控制开始感染时间，如果这个值不能满足感染要求，则退出；通过+78值控制控制终止感染USB的时间，以及涉及控制震网传播、版本更新等值。在解密后的配置信息中这种控制震网行为的值有近百个，正是这些值来控制震网的复杂行为。

表 6 2 部分配置内容解析

Dropper的配置文件校验函数：

图 6-5 Dropper的配置文件校验函数

配置块的一些关键信息：如感染路径、感染时间、配置块长度，通过提取配置数据分析后发现，由于在每次感染新的设备后，其自身都会更新数据配置块，致使每感染一台设备，Stuxnet就会多出一个含有新配置的Dropper样本，图6-6为震网开始感染时间的数量分布图，其中2008年-2010年为可信度较高的感染时间，而2000年-2007年为可信度较低的感染时间。

图 6-6 开始感染时间数量分布图（由于内网主机可能的存在时钟不同步问题导致错误的启示时间）

在震网的安装执行过程中会多次检查目标系统当前时间，如果目标系统时间大于终止时间，震网就会退出安装执行过程。图6-7是震网1.x版本终止U盘感染时间的统计，它有三个终止U盘感染时间：2010年7月31日、2010年8月31日、2010年12月31日，其中绝大多数的终止U盘感染时间为2010年12月31日。

图 6-7 终止U盘感染时间统计

2. 分析提取工作导致的

将震网的各个功能载荷从主DLL中剥离出来，是震网分析中的重要工作，这带来了一种新的样本统计上需要考虑的因素，即何为原始样本，何为处理中的过程数据。震网主DLL文件在Dropper中采用UPX压缩的方式进行存储，防止样本大小过大，减少传播机会。在实际感染过程中主DLL不会落地，在样本集中有UPX加壳的主DLL文件，在实际样本集中存在，因Dump导致的不同版本，未脱壳版本，不同脱壳方式生成的版本等情况。

在A2PT组织作业使用落地的样本中，很少看到使用壳的情况，这可能与一些杀毒软件会对壳报警、或输出日志相关。但震网主DLL文件在Dropper是采用UPX壳压缩的（毒曲也是如此），究其原因，应是出于减小文件体积的考虑。

图 6-8 未完全脱壳文件

3. 干扰数据

在震网的USB Loader样本集中，有数以百计的样本文件签名损坏，且大量该类文件的尾部还追加了其他的LNK文件和某种反病毒产品的报警日志，从目前分析来看，这是某款反病毒产品的产品Bug导致的，其某版本在扫描样本时，会错误的样本后面追加数据，从而引入数百被破坏的样本。

图 6-9 USB Loader尾部追加LNK文件

七、恶意代码框架与多起A2PT的事件关联

在震网事件曝光前后，包括毒曲、高斯、火焰等高级恶意代码被陆续曝光，由于这些恶意代码都空前复杂，且往往多在中东国家被发现，因此怀疑其相互间存在某种意义的关联，也成为了一种比较自然的猜想。

ANTIY CERT在2011初提出了震网和毒曲可能存在某种关联关系的猜测，但直到次年初，才完成比较系统的验证。发布了《探索Duqu木马的身世之谜》[10]、《从Duqu病毒与Stuxnet蠕虫的同源性看工业控制系统安全》[11]两篇文献，分别从模块结构相似性分析、编译器架构相似性分析、关键功能实现相似性分析、密钥与其他关键数据相似性分析、编码心理特点分析、相同的程序Bug分析等角度，证实了两者存在同源关联关系。

图 7-1 毒曲病毒与震网蠕虫的代码片断比较

图 7-2 毒曲病毒与震网蠕虫使用相同密钥

我们在当时做出的结论是“通过对毒曲病毒与震网蠕虫关键代码结构、密钥使用方法和代码逻辑等的比较，我们发现了大量相同或相似的代码片断，这说明两者间存在代码复用关系，或者两者基于相同的代码框架开发。”但对于是复用关系，还是同框架开发这一问题，当时并未给出定论。而融合其他机构的后期分析成果和进展，可以形成的结论是，相关A2PT攻击组织至少维护了Tilded和Flamer两个恶意代码框架。震网、毒曲与火焰、高斯分别是基于Tilded和Flamer框架开发的。2012年6月11日，卡巴斯基发布报告称2009年早期版本的（即0.5版）Stuxnet模块（称为“Resource 207”）实际上是一个Flame插件。而这一成果也将Flamer和Tilded这两个完全不同的框架串接了起来。基于这两个框架的恶意代码在感染目标系统和执行主要任务方面具有独特的技巧，均用来开发不同的网空攻击装备。卡巴斯基提出的结论是：两个框架背后的团队曾经共享过至少一个模块的源代码，表明他们至少有一次团队合作，是属于同一机构的两个平行项目[12]。基于更多的线索，还可以把Fanny和Flowershop与上述事件串接到一起，它们的关系如图7-3所示。

图 7-3 震网和毒曲、火焰、高斯、Fanny、Flowershop关系图

7.1 Flamer框架

Flamer框架的开发时间可以追溯至2006年12月，火焰和高斯是基于Flamer框架开发的。我们于2012年5月28日起陆续捕获到火焰蠕虫的样本[13]，并成立了专门的分析小组进行持续分析，发现火焰是采用多模块化复杂结构实现的信息窃取类型的恶意软件。其主模块文件大小超过6MB，包含了大量加密数据、内嵌脚本（如Lua等）、漏洞攻击代码、模块配置文件、多种加密压缩算法，信息盗取等多种模块。

火焰的两个主要版本为Flame 1.0和Flame 2.0，两个版本均由依赖于嵌入式Lua VM的主协调器指示的多个子模块组成。火焰和高斯之间包含一些相同代码，同时共享MiniFlame恶意软件插件。

7.2 Tilded框架

震网和毒曲是基于Tilded框架开发的。Tilded框架感染方式一般可以归纳为利用驱动程序文件，加载一个设计为加密库的主模块。同时，整个恶意复合体有一个单独的配置文件，系统注册表中有一个加密块，用于定义正在加载的模块的位置和注入过程的名称。

震网已知的版本包括Stuxnet0.5、Stuxnet1.001和Stuxnet1.100。Stuxnet0.5是震网的早期版本，但是后被发现曝光，该变种在2009年7月4日停止了对计算机的攻击。Stuxnet0.5与Stuxnet1.x版本的主要区别包括：Stuxnet1.x版本显著增加了传播和漏洞利用能力；Stuxnet0.5是部分基于Flamer框架的，而Stuxnet1.x版本主要基于Tilded框架；Stuxnet0.5采用导致超压的方式，大规模破坏离心机，而Stuxnet1.x版本采取了新的攻击策略，从铀浓缩阀破坏变成对离心机速度的修改。

表 7 1 震网0.5与1.x版本技术细节全面对比

 毒曲的主要版本包括Duqu1.0、Duqu1.5和Duqu2.0。Duqu与Duqu2.0之间使用统一算法以及复用大量相同代码，Duqu1.0和Duqu2.0之间攻击目标有很多重合，Duqu1.5和Duqu2.0之间均使用了Pipe Backdoor插件。

震网和毒曲之间在模块结构、编译器结构、关键功能、数据结构、病毒作者心理等方面具有同源性[14]，此外，震网和Duqu1.0、Duqu2.0均采用窃取自中国台湾IT厂商的数字证书。

7.3 震网与Fanny、Flowershop的关联

从图7-3中能够看出，震网除了与毒曲、火焰具有一定关联之外，其与Fanny、Flowershop也具有一定的关联。

Stuxshop是震网的早期组件，用于管理早期C2。Stuxshop与Flowershop（活跃于2002年至2013年的恶意软件平台）之间存在代码重叠或共享。

方程式早期组件Fanny，其使用了两个震网的0day漏洞，即LNK漏洞（CVE-2010-2568）以及嵌入在“Resource 207”中的提权漏洞。此外，震网和方程式开发者之间共享编码风格，或者使用同样的开发规范手册。

八、直面检测引擎与威胁情报的挑战

在我们此前的分析报告中，针对A2PT带来的防御挑战，进行过一些论述和探讨，而针对震网的复盘，我们希望聚焦一个具体的问题，高级恶意代码对检测引擎和威胁情报的挑战。

作为攻击载荷的恶意代码是网空攻击的“战斗部”，几乎绝大多数的网空攻击事件中都会出现恶意代码的身影，在高能力网空威胁行为体的攻击活动中更是如此。从威胁框架的视角来看，高能力网空威胁行为体要针对目标完成接触目标与进攻突防、持久化驻留潜伏、全程持续支撑作业，并进一步达成各种致效能力运用，在整个过程中，既需要针对业务场景达成作业意图，又要绕开体系化的防护，达成深度持久化和隐蔽通讯等动作，其必然要完成高度复杂的逻辑功能执行。这导致了APT攻击对恶意代码的依赖程度在不断加深，高级恶意代码呈现出框架日趋庞大、模块众多和指令体系原子化等趋势。

在过去对网空威胁的分析和对网空威胁行为体的追踪中，我们对震网、火焰、毒曲、方程式等拥有完整、严密的作业框架与方法体系的攻击活动，以及其自研使用的的高级恶意代码进行了持续关注分析；同时也分析了一些组合使用“商业军火”、开源免费工具即较低水平的自研恶意代码的定向攻击活动。这些分析工作是长期的、高代价的，但这些工作是实现更有效地防御和猎杀的基础。赋能客户建设动态综合防御体系是我们的目标；而针对攻击装备（恶意代码、漏洞利用程序和其他的工具）的斗争一直是其中的焦点。

在这种对抗中，传统的反病毒引擎和威胁情报成为两个具有互补作用的机制，前者针对海量的恶意代码的检测、辨识能力，并且通过深度预处理、虚拟执行等机制来应对恶意代码的变种、变换，因此在载荷检测方面，有无以伦比的识别与解析深度，而且对海量载荷对象提供了精准的判定机制。但传统病毒引擎在威胁对抗中的短板也很明显，其是最容易被攻击方获得的安全资源，绝大多数反病毒软件都可以公开的下载或低成本的购买、同时Virustotal等公开的多引擎扫描机制也会成为攻击方的测试资源。因此反病毒引擎面对自动化构造的免杀测试等方法，有被绕过的必然性。同时其本地检测定期升级库的机制，或者是云引擎对远程的依赖，对内网用户也都带来了一定的部署成本。另一个问题是，传统反病毒引擎的工作视角是基于样本检出率为核心指标的，其信息输出缺少从威胁对抗方面更明确的指向性。这些短板都需要威胁情报进行弥补。在威胁情报金字塔中，HASH、IP、域名等“狭义情报”被列入底层，即获取难度低、应用成本低。较为容易的被分析防御方提取为攻击指示器（信标），同时可以与多种安全设备、管理设备、防护软件等现有扩展接口实现对接。

图 8-1 威胁情报金字塔模型

尽管与传统的反病毒检测引擎相比，HASH检测机制毫无鲁棒性可言，但由于HASH的唯一性，其在可靠的知识运营支撑的情况下，可以建立起对攻击组织的精准的指向性。例如两个不同的攻击组织，分别定制了同一个版本的商用木马，在文件尾部附着了各自的C2配置。对于反病毒引擎来说，这是同一种样本，而对于HASH情报在分析支撑下输出，反而能将其区别出来。但HASH情报其可用前提也很明显，那就是存在着二进制形态不变的样本复用。对IP和域名规则也是如此，当情报供给方能将恶意活动指向某个确定的通讯基础设施（C2），来完成心跳、控制、升级、回传等操作，并将这个恶意活动指向某个攻击组织时，那么相应的网络IoC就可以命中在其他攻击活动中的行为，从而建立起攻击行为和组织的关联。这种低层次的攻击指向器，尽管效用机理比反病毒引擎和流量检测引擎都要简单，但基于其可以快速发布，广泛扩展，精准定义，一定程度上带了一种快速的、更为普适的监测和普查能力。因此传统检测引擎+IoC情报可以形成一定的互补组合的效果。这种组合模式也是过去数年我们所推动的模式。

但通过复盘9年前的震网事件就可以看到，这个层面的情报对于A2PT攻击近乎无效。每一台主机上提取到Dropper文件的HASH都不可能命中另一台主机上的等效文件。我们不能认为震网Dropper的落地自写更新机制，主要目的是为了对抗HASH检测机制，但其客观上构成了这样的效果。而更需要看到的是，尽管在分析过程中，可以看到震网攻击的相关域名从2005年已经被注册。但在分析方将相关通讯特性作为规则时，震网的攻击效果已经达成，而在毒曲等的攻击中，我们亦广泛看到内网C2等机制的存在。如果反病毒引擎是一种会被攻击者重点绕过的重载机制，而攻击指示器（信标）又作为一种稳定性极低的情报机制的话，这对双保险的效果就会大打折扣。

我们基于传统检测引擎在威胁对抗中，是攻击方重点绕过环节的特点，自2016年起开始研发下一代威胁检测引擎。安天下一代引擎延续并深化了安天传统引擎格式识别、深度解析等特点，继承对海量恶意代码精准的分类到变种的识别能力。同时，以没有可信的格式和对象为前提，形成对检测对象全格式识别，对更多重点格式形成深度解析能力。不止为调用环节输出判定结果，同时也可以将检测对象的向量拆解结果结构化输出，形成支撑产品场景和态势感知场景研判分析、关联与追溯的数据资源。

探索检测引擎与威胁情报更好的结合，建立起更可靠的基础标识能力与响应机制，更有效的支撑TTP，乃至人员组织相关的情报，建立起更完善的知识工程运营体系，这对我们来说，将是一个需要长期努力的方向。

附录一：参考资料

[1] 对Stuxnet蠕虫攻击工业控制系统事件的综合分析报告

https://www.antiy.com/response/stuxnet/Report_on_the_Worm_Stuxnet_Attack.html

[2] 对Stuxnet蠕虫的后续分析报告

ANTIY技术文章汇编（五）工控系统安全分册

[3] WinCC后发生了什么

ANTIY技术文章汇编（五）工控系统安全分册

[4] 《Offensive Cyber Capabilities at the Operation Level》

https://csis-prod.s3.amazonaws.com/s3fs-public/legacy_files/files/publication/130916_Leed_OffensiveCyberCapabilities_Web.pdf

[5] “方程式组织”攻击SWIFT服务提供商EastNets事件复盘分析报告

https://www.antiy.com/response/20190601.html

[6] Why Stuxnet Isn't APT

https://digital-forensics.sans.org/blog/2011/03/24/digital-forensics-stuxnet-apt

[7] Revealed: How a secret Dutch mole aided the U.S.-Israeli Stuxnet cyberattack on Iran

https://news.yahoo.com/revealed-how-a-secret-dutch-mole-aided-the-us-israeli-stuxnet-cyber-attack-on-iran-160026018.html

[8] W32.Stuxnet

https://www.symantec.com/security-center/writeup/2010-071400-3123-99

[9] Stuxnet’s Secret Twin

http://www.foreignpolicy.com/articles/2013/11/19/stuxnets_secret_twin_iran_nukes_cyber_attack#sthash.ENqwTV0K.dpbs

[10] 探索Duqu木马的身世之谜——Duqu和Stuxnet同源性分析

http://blog.sina.com.cn/s/blog_64a6dc1501016sed.html

[11] 从Duqu病毒与Stuxnet蠕虫的同源性看工业控制系统安全

ANTIY技术文章汇编（五）工控系统安全分册

[12] Resource 207: Kaspersky Lab Research Proves that Stuxnet and Flame Developers are Connected

https://www.kaspersky.com/about/press-releases/2012_resource-207-kaspersky-lab-research-proves-that-stuxnet-and-flame-developers-are-connected

[13] Flame蠕虫样本集分析报告

https://www.antiy.com/response/flame/Analysis_on_the_Flame.html

[14] Duqu和Stuxnet同源性分析系列报告

ANTIY技术文章汇编（五）工控系统安全分册

*本文作者：antiylab，转载请注明来自FreeBuf.COM