在“十年：STUXNET、SUNBURST对比分析（一）”中，我们对STUXNET、SUNBURST的攻击技战术进行了对比分析。在本文中，我们将对STUXNET、SUNBURST的调查过程进行解读。

调查过程

1. STUXNET的调查过程

1）发现

2010年1月，国际原子能机构在对伊朗纳坦兹核设施进行检查的时候发现，该设施的部分铀浓缩离心机不能正常工作，原因不明。

五个月后，白俄罗斯的一家计算机安全公司VirusBlockAda，被其伊朗客户请去查找该公司多台电脑反复出现崩溃和重启的原因，STUXNET因此而浮出水面。

这并不是STUXNET暴露的最早时间。早在2009年7月22日，Siemens的一个客户论坛上，用户名为Behrooz的工程师的贴子，就已经揭示了STUXNET的存在。在Behrooz的贴子中，描述了他们公司遇到的问题：电脑上只要有Siemens Step7 .DLL这个文件，都会不断出现报同一错误的故障。他怀疑是感染了某种计算机病毒，而且病毒是通过U盘扩散的，因为当他用光盘向干净电脑拷贝文件时，一切正常；但当他用U盘拷贝文件时，原本干净的电脑会出现跟这些电脑相同的问题。可惜，该帖子并未引起关注。

2）样本分析

经过VirusBlockAda的调查，发现造起电脑崩溃和重启的程序拥有合法的数字签名，这给参与调查的安全分析人员带来了很大困惑，于是将一情况反馈到了安全社区。因为当时很多安全公司的自动检测程序都不能处理这种情况，因此引起了多家公司的关注，并促使Symantec、Kaspersky等安全公司也参与到了这一事件的调查中。

经过对恶意样本长达数月的逆向分析，安全分析人员最终揭开了STUXNET的神秘面纱。

3）追踪溯源

跟其它许多APT调查报告不同，关于STUXNET的调查报告主要集中在STUXNET样本的功能分析方面，并没有太多追踪溯源方面的内容。认为美国是这次攻击发起方的消息，最初来源于纽约时报的一篇文章，依据是一些美要员对伊发展核项目的威胁讲话，并不能与STUXNET本身直接挂上钩。

能够与STUXNET挂上钩的追踪溯源线索主要有：

2009年6月23日，Foolad技术公司就已经感染STUXNET，这被认为是最早感染STUXNET的时间。

2009年6月29日，Behpajooh公司的计算机被感染。因为该公司位于Esfahan—该地方与伊朗铀矿石加工相关，而且Behpajooh还为一家钢铁公司安装Siemens S7-400 PLC以及Step 7和WinCC软件，因此被认为是STUXNET的攻击目标。

2009年7月7日，Neda工业集团公司和ControlGostar Jahed公司的计算机被感染。由于涉及为伊朗的石油天燃气公司、发电厂等提供控制系统、精密仪器及电子系统的设计与安装，Neda被认定为STUXNET的攻击目标。Control Gostar Jahed则因为STUXNET日志文件中有CGJ这一项，也被认定为STUXNET的攻击目标。

相关材料中，以上目标只在感染时间上存在先后关系，但它们到底是如何感染上STUXNET的，并没有相关证据予以支持。至于它们与纳坦兹核设施出现故障之间是如何关联的，也没有明确的说法。

2. SUNBURST调查过程

1）发现

2020年12月8日，FireEye发布公告，称其遭遇黑客攻击，红队工具代码被窃。

2020年12月13日，FireEye和Microsoft先后发布“SolarWinds供应链攻击事件分析报告”。12月14日，SolarWinds发布公告予以确认。

虽然现在仍不清楚FireEye、Microsoft具体是如何将FireEye受攻击与SUNBURST联系起来的，但根据Microsoft Azure的CTO Mark Russionovich的说法“X国人害怕Sysinternals：如果你安装了Sysmon，或者运行了Procmon、Procexp、Autoruns等工具，Sunburst将离你而去”，可以推断Sysinternals工具集在发现SUNBURST的过程中发挥了重要作用。

2）样本分析

与分析STUXNET相同，分析SUNBURST也是用的逆向分析的方法。

稍微有点区别的是，在STUXNET样本的分析过程中，参与的只有少数几家安全公司。而在SUNBURST样本的分析过程中，由于恶意样本被公布到了网上，所有感兴趣的机构或个人都可以参与，并且各家的分析情况也是及时发布，全部分析过程几乎都是透明的。

3）追踪溯源

目前公开的权威报告中，关于SUNBURST的追踪溯源情况，只给出了较为含糊的结论，也没有提供多少证据。通过零零散散的各种分析报告、新闻报道来分析，应该是有较为可信的证据的，这主要源于以下两个事实：

一是有公司的分析报告指出，SUNBURST与其它APT行动在部分代码片段上雷同。

二是根据美网络空间司令部一些要员的只言片语可以知道，美网络空间司令部具备通过分析流量进行追踪溯源的能力，但由于受法律约束，它们只能对流向美境外的流量实施监控，而不能对美国内流量实施监控，因为SUNBURST攻击者是通过租用的美国内设施发起攻击的，这使得网络空间司令部由于缺乏完整的数据链条，影响到了其对SUNBURST的调查进度。

几点启示

纵观STUXNET和SUNBURST两次事件的调查过程，我们认为，以下经验特别值得汲取：

1. 基本的安全意识

无论是STUXNET事件，还是SUNBURST事件，最先发现异常的都是受害者自己。

SUNBURST的受害者FireEye自身就是顶级安全公司，抛开它不说。STUXNET事件中，那个用户名为Behrooz的工程师，在公司电脑出现莫名故障后，能够根据故障表现，准确找出故障原因，精准定位传播途径，特别值得称道。

2. 共享的威胁情报

威胁情报共享在当前已经是很常见的事，但通常能够共享的多是已经完成调查的、发生在别人身上的威胁情报。能把发生在自己身上的、或者自己正在调查的威胁情报共享出来，确实需要很大的勇气。毕竟网络威胁发生在自己身上，或者不能找出原因并不是一件好事，公布出来可能就意味着名誉受损、客源流失，甚至于遭受惩罚。

但是，STUXNET、SUNBURST事件说明，网络威胁事件发生在谁身上，并不能说明谁的安全意识就一定不强，谁的安全防护就一定不到位。STUXNET、SUNBURST事件还说明，一次网络威胁的目标常常是大范围的，鼓励“吹哨人”出现对于降低整体所受伤害是十分重要的。因此，无论是STUXNET事件中那个用户名为Behrooz的工程师、白俄罗斯那家不知名的安全公司VirusBlockAda以及邀请VirusBlockAda调查的那家伊朗公司，还是SUNBURST事件中的FireEye、Microsoft以及SolarWinds，都值得我们尊重。

3. 广泛的交流合作

网络威胁并没有一个固定的套路、一种固定的模式，对于STUXNET、SUNBURST这种特别复杂的网络威胁事件，需要不同的机构，利用掌握的不同资源，按照不同的思路，顺着不同的线索，从不同的角度进行分析，才能最终汇聚成一幅完整的调查画卷，因此，政府机构与政府机构之间、政府机构与私营企业之间、企业与企业之间，广泛的交流与合作必不可少。

这一点，在STUXNET的调查过程中，已经有比较好的体现。在SUNBURST的调查过程中，则更是前进了一大步。

4. 充分的资源利用

对资源的利用程度上，STUXNET和SUNBURST正好构成反例。

在STUXNET的调查中，没有见到对C2的调查，没有见到对失窃证书的公司的调查，也没有见到对流量数据的利用。所以STUXNET的溯源更多只能靠推测。

在SUNBURST的调查中，C2被接管，数字签名问题能有说法，流向境外的流量由网络空间司令部监控，国内流量网络空间司令部虽然不能监控但FBI可以接手。所以SUNBURST的溯源说有证据并不稀奇。

5. 丰富的专业经验

在STUXNET和SUNBURST的发现、分析和溯源过程中，各种安防检测设备几乎全部失灵，最终解决问题靠的还是人，有丰富经验的人。

能够说明这一问题的是，在“The Real Story of Stuxnet”中，很大一部分内容都是在介绍Kaspersky高级分析人员Schouwenberg的个人经历，包括他的丰富的工作经验，包括他在波士顿学习软件逆向方面的知识…

同样，在FireEye受攻击事件的相关报导中，也出现了FireEye高级职员的履历介绍，除了表明FireEye的人员对网络攻击十分熟悉以外，也有点向对手示威的意思。

关于对STUXNET、SUNBURST调查过程的解读，就先说到这儿。之后，我们将对自动检测设备为何失灵的问题进行解读。

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