Part1 前言

大家好，我是ABC_123，公众号正式更名为”希潭实验室”，敬请关注。本期分享一个堪称史上影响最大、危害最大的供应链攻击APT案例——Solarwinds供应链攻击事件，SolarWinds的旗下有数万家客户公司，包括了”财富美国500强“企业、美国所有前十大电信业者、美军所有五大部队、美国国务院、国家安全局，以及美国总统办公室，美国多家顶级网络安全公司等，最终有大约1万8千家公司安装了含有后门的Orion网管软件更新包，APT组织挑选了50多家主要公司单位进行内网横向渗透。

注：攻击者入侵美国Solarwinds公司，属于上游软件供应链攻击范畴，而通过Solarwinds转而入侵美国关键基础设施OEM制造商，属于产业供应链攻击范畴，因而此APT攻击事件影响深远，危害巨大。

此次APT供应链攻击事件异常复杂，ABC_123重新整理国内外英文报告，结合自己的网络安全实战经验，一字一句对各种分析文章反复校勘，力图还原整个入侵事件的真实全貌，给广大的网络安全从业人员提供一个参考，更好地为祖国的网络安全事业做出贡献。

Part2 前置知识介绍

APT流程图及攻击过程简介

首先放出一张ABC_123绘制的关于Solarwinds供应链攻击美国关键基础设施的流程图，是从大量的国内外关于此次攻击事件的报道中归纳整理出来的，接下来依据此流程图，详细讲解整个入侵流程。

攻击过程：攻击者首先入侵了美国Solarwinds网络管理软件公司内网，接着获取了所有源码编译服务器的权限，通过编写的Sunspot工具（一款后门投递及源码修改工具）监视旗下Orion网管软件更新包的源码编译过程，从源码层面植入Sunburst后门程序，编译后自带Solarwinds合法数字签名Solarwinds Worldwide，LLC，这种方式自带白名单效果，完美绕过各种防护措施。等到Solarwinds官方下发软件更新包后，导致旗下数万家Orion客户公司内网沦陷。

攻击武器及后门介绍

接下来，ABC_123介绍一下此次APT供应链攻击过程中，攻击者所使用的各种攻击武器，以免大家阅读文章时，被这些工具的英文名称弄得云里雾里的。

1 第一阶段武器：

分发工具：这个工具没有具体命名，用于将Sunspot攻击工具，批量投放到100多台编译虚拟机中。

Sunspot：用于监控Orion源码编译过程，通过一系列复杂操作，在Orion更新包源码中植入Sunburst后门代码。

Sunburst：这是一款极其复杂且隐蔽的后门，当用户运行Orion安装包之后，这款后门会等待12到14天后触发，然后使用DGA域名通信方式，将受控服务器的域名、计算机名等初始信息发送给C2服务端。

2 第二阶段武器：

Teardrop：Loader程序，由SUNBUSRT提供，从隐写图片中提取恶意shellcode并加载执行，最终上线Cobalt Strike。

Raindrop：Loader程序，与Teardrop不同的是，它主要用于内网横向传播，攻击者为了隐藏攻击行为，通过修改7-zip源码将Raindrop编译为7-zip.dll文件，用于后续加载执行自定义CS的shellcode。

3 第三阶段武器：

通过第二阶段的Loader程序，植入Cobaltstrike、GoldMax、SiBot、Goldfinder等适用于不同场景的后门程序。

经过国外安全公司的分析，攻击者刻意地隔离Sunburst与CobaltStrike这两阶段后门，是为了便于受害者在发现并应急清除Cobalt Strike后门之后，仍能保护Sunburst后门的存在，做好权限维持工作。

Part3 APT供应链攻击全过程

获取外网服务器权限

经过国外安全公司评估，组织如此庞大规模的供应链攻击行动，涉及制定方案、模拟演练、准备攻击基础设施、前期侦察、定制化开发武器和指挥控制平台、获取目标网络初始权限、后期渗透拓展等一系列工作，需要动用超过1000名的工程师支持，后期为了排查溯源此次APT攻击事件，微软就动用了500多名安全工程师来排查。

自2020年12月12日，此APT攻击事件被曝光之后，该APT组织是如何获取solarwinds外网权限的，一直没有一个让大家信服的调查结果，目前普遍认为有以下几种可能：

1 Github密码泄露。在2019年，一名安全人员在github上发现了泄露的服务器弱密码solarwinds123，经过调查，Solarwinds公司一名实习生于2017年在个人的github贴出了自己的密码solarwinds123，使用该密码可以登录外网的solarwinds的更新服务器。

2 暴力猜解弱口令。solarwinds123是弱密码，攻击者也可能是通过暴力破解方法猜解成功的，而solarwinds123这个弱密码至少在2017年就已经在用了。

3 Office365服务漏洞。2019年2月，发现攻击者窃取了Solarwinds公司员工的Office365账号，疑似通过微软的Office365服务的漏洞获取了相关权限，但是微软官方坚决否认。

在Orion网管软件源码编译过程中植入测试后门代码

在获取外网权限之后，该APT组织进行了非常隐蔽的内网横向渗透，花费很长时间和精力，对内网网络拓扑及源码编译服务器进行了充分的信息收集，最终获取到了Solarwinds源码构建服务器的全部权限。

经过长达几个月的评估和分析，该APT组织制定了一个疯狂的计划：在Solarwinds网管软件Orion的源码中植入后门代码，这样生成的更新包由于带有Solarwinds的正常的数字签名，可以绕过各种杀软防护，等到Solarwinds公司给客户下发Orion软件更新包时，就可以获取旗下数万家客户公司的全部权限，这就是上游供应链攻击的巨大威力。

计划听起来很炫酷，但是实施起来难度非常大，为了使这个计划能够实施成功，该APT组织耗时整整一年多的时间进行准备。接下来ABC_123就列举出几个关键的时间节点，让大家对APT组织的严密工作计划有个直观的认识。

2019年1月30日，该APT组织登录了一个员工的VPN账号，猜测是寻找并分析SVN源码服务器。

2019年1月31日，也就是第2天，攻击者再次登录此VPN，下载了超过129套Solarwinds产品的源代码，并获取了大量的用户信息，推测是为了分析Solarwinds公司哪些客户使用了哪些产品，为后续供应链攻击做准备。之后攻击者消失了2个月，在这段时间内，该APT组织深入分析这些源代码，并且分析客户对不同Solarwinds软件产品的使用情况，争取最大化地利用这些源码。最终他们发现Solarwinds公司旗下的Orion软件是实施供应链攻击最完美的选择，因为这款软件用户群体大，在客户网络中占据了特权位置，而且与许多其他服务器连接和通信，非常便于横向渗透。

2019年3月12日，攻击者重新访问了软件构建环境，然后又消失了6个月。Orion软件的构建环境非常复杂，一个新招聘的程序员需要花费数月时间才能掌握。在随后的6个月时间里，攻击者创建了Orion源码构建环境的副本，然后编写后门代码，后门代码的编码方式及命名规则特意模仿了Solarwinds原公司程序员的习惯，以至于后期安全人员多次排查，都没发现是异常代码。随后不断尝试在源码编译过程中，插入后门代码，不断地测试，解决各种可能出现的意外情况，争取生产环境中可以一次成功。

2019年9月04日，也就是在6个月后，攻击者再次访问了源码构建环境，此时从记录的操作日志来看，攻击者的操作已经显示出源码方面专业的技能，说明他们花费巨大的时间和精力对源码进行深入研究与测试。

2019年9月12日，攻击者在Orion网管软件的源码构建中植入了无害的测试代码，推测是在进行“无损”测试，也就是为了测试是否能在生产环境中完成源码替换操作而不被注意，然后他们静静等待Orion软件更新。在这段时间里，他们利用获取到的几十个关键高管和安全人员的邮箱账号，秘密跟踪监视Solarwinds公司是否发现此次入侵行动。

2019年10月26日，攻击者对Orion更新包源码进行了小幅度修改，添加了空类代码，但不含后门代码，测试是否可以通过Orion源码编译服务器，并且成功发布。终于Solarwinds公司发布了攻击者第一个修改的Orion软件版本2019.4.5200.8890版本，攻击者发现被自己修改的无害的Orion源码被成功编译，说明一切准备就绪。

2019年11月04日，攻击者正式完成所有测试工作，这时候已经过去差不多一年的时间，可见攻击者的充分准备和打持久战的决心。

使用Sunspot在生产环境植入后门

Sunspot工具一旦被运行，会提升自身调试权限，通过添加计划任务，每11分钟执行一次，监视Orion软件的编译程序MSBuild.exe的编译过程，通过获取MSBuild.exe的命令行参数，获取Orion代码包中core.sh解决方案文件的绝对路径，进一步找到InventoryManager.cs源代码的路径，将此源代码文件备份为InventoryManager.bk。

然后Sunspot从自身解密出含有SunBurst后门的经过APT组织修改的InventoryManager源码文件副本，把即将正式发布的Orion源码中的原始InventoryManager.cs代码给替换掉，该后门代码最终会被编译在SolarWinds.Orion.Core.BusinessLayer.dll文件中，而且自带Solarwinds数字签名，最后被打包在更新补丁安装文件CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220Hotfix5.msp中。

当Orion网管软件的用户安装补丁包时，一旦SolarWinds.BusinessLayerHost.exe或SolarWinds.BusinessLayerHostx64.exe运行，就会调用SolarWinds.Orion.Core.BusinessLayer.dll中的Sunburst后门代码，从而导致安装更新包的用户被种植后门。

植入后门过程遇到难题

2020年2月20日，攻击者向软件构建服务器植入了Sunspot工具，然后一直潜伏在软件构建服务器中。

2020年3月份，Solarwinds开发人员开始使用JetBrains公司出品的TeamCity（TeamCity是捷克软件开发公司提供的构建管理和持续集成服务器）构建Orion的软件更新包，该编译软件启动了100多个编译虚拟机，这些虚拟机是临时创建的，一旦编译工作结束就会自我销毁。此时攻击者遇到了麻烦，每台编译虚拟机各自负责编译Orion网管软件的不同模块的代码，他们不知道哪一台编译虚拟机会编译SolarWinds.Orion.Core.BusinessLayer.dll文件或者打包此dll文件。

批量投递Sunspot工具

于是攻击者专门设计编写了一个工具，向100多个编译虚拟机投放Sunspot工具。在每一台编译虚拟机上，Sunspot会创建计划任务，监视MSBuild.exe编译过程。

一旦发现SolarWinds.Orion.Core.BusinessLayer.dll出现在服务器上，立即将合法源码文件重命名，替换成含有后门Sunburst版本的dll文件，整个过程只有几秒钟的时间，实现难度非常大，同时也说明攻击者事先做了多么充足的准备，也间接理解了该APT组织为何耗时一年的时间来测试。然后Sunspot会将原有合法的dll文件恢复，从所有虚拟机中将自身删除，清理痕迹。

借助Orion更新包入侵下游客户公司

Solarwinds官网每隔一段时间，都会向旗下客户分发Orion软件的更新补丁安装包，自2020年春季以来，Solarwinds官网已经向多达18,000名Orion客户发布了更新补丁安装包，如果这些客户的Orion服务器对外网开放访问，就会导致安装包内置的Sunburst后门程序被触发。（以下这张图来源于网络）

当受害者安装该补丁包期间，会运行SolarWinds.BusinessLayerHost.exe或SolarWinds.BusinessLayerHostx64.exe程序，接着调用SolarWinds.Orion.Core.BusinessLayer.dll文件，然后隐藏在此dll文件中的后门Sunburst会被触发，从而导致客户的Orion网管服务器被控。

这样的结果会导致18,000家客户公司被感染Sunburst后门，对18,000家公司的内网进行渗透，显然是不现实的，而且动作太大，容易暴露APT攻击计划，于是该APT组织选了50个左右的重要目标进行横向攻击，包括美国财政部、司法部、微软公司等。如上图所示，这些是被公布出来的所有被入侵的厂商列表，对于其它价值不大的入侵目标，该APT组织会发送终止指令，使Sunburt后门永久退出和自我销毁。

值得注意的是，谷歌公司也使用了Orion网管软件，但是由于其内部严格的安全防护措施，谷歌相关负责人很有信心地表示，谷歌没有遭受Solarwinds供应链攻击，后续也证明确实如此。

Sunburst后门启动

一旦含有Sunbrust后门的dll文件被调用执行后，不会立即触发执行恶意操作，会随机等待12到14天，这样做的目的是让全球1万8千多家Orion软件用户的被控服务器逐步上线，避免集中上线被流量监控设备发现并告警，导致计划败露。

之后Sunburst后门会使用DGA域名与C2端通信，收集受害者主机环境及计算机信息发送给攻击者，攻击者会根据这些信息去判断该单位是否值得进行下一步的入侵。

如果目标很重要，会进一步投放Teardrop工具或者Teardrop工具，这两款工具是恶意代码加载器loader，其中Teardrop加载器会下载4种图片，并且结合图片隐写技术提取出隐藏的shellcode，然后由Teardrop加载执行。

如果目标不重要，攻击者会通过C2发出指令，使Sunburst退出或者永久禁用。尽管攻击者感染了成千上万台服务器，但他们只挑选了50个左右的重要单位进行深入渗透，这样可以集中精力搞重要目标，在搞少量且重要的目标时，也可以减少精力的分散，防止被安全防护系统捕捉到攻击行为。

无意中留下后门样本

攻击者在隐藏自身及过流量检测方面做到了极致，以至于安全团队在溯源这起攻击事件时耗费时间长达数月之久。攻击者通过监控Solarwinds的公司邮件，得知受害者已经察觉了攻击行为，所以果断删除了所有虚拟机的Sunspot工具，那么安全人员是如何发现APT组织遗留的攻击武器及样本呢？

正所谓天网恢恢，疏而不漏，这源于一次源码编译产生的意外。在大约2020年2月左右，一台编译虚拟机在软件构建过程中出现错误，接着TeamCity创建了一个虚拟机快照，该快照包含故障发生时虚拟机的所有内容，方便研发工程师分析故障。正常情况下，SolarWinds研发工程师会在后续删除这些快照，但是不知道为啥没有删除。幸运的是，这个虚拟机快照中正好保留了Sunspot工具，更幸运的是，软件工程师一直没有删除此快照。这个意外成了溯源出整个Solarwinds供应链攻击的唯一线索。

攻击者收手，清理痕迹

2020年6月4日前后，Solarwinds的客户发现了一些来自Orion网管服务器的异常流量，并联系了SolarWinds公司讨论此事。该APT组织通过监视Solarwinds公司的部分人员的邮件往来，发现自己的攻击行为有可能暴露，于是删除了在Orion软件构建环境中的Sunspot和Sunburst后门样本。

2020年11月26日，攻击者最后一次登录Solarwinds的VPN账号，然后持续监视Solarwinds高管和安全人员的邮件往来，猜测是为了得知攻击事件的溯源进展。

2020年12月12日，国外安全人员首次报告Solarwinds供应链后门事件，在安全圈引起轩然大波。但是大家需要注意的是，该APT组织入侵Solarwinds公司已经过去了至少两年的时间，而没有被发现。

2020年12月18日，FireEye、微软、GoDaddy 公司接管了Sunburst后门通信的C2域名，将相关域名的解析ip更换为20.140.0.1，根据后期对后门样本的逆向分析，根据其内置规则，当C2域名解析的IP地址为20.140.0.0/15时，Sunburst后门会永久终止运行（攻击者非常聪明，控制C2的域名解析到不同的IP，然后Sunburst后门会根据域名解析ip的情况去执行不同的操作，这个过程ABC_123会在下一篇文章详细讲解）。

APT攻击组织判定

究竟是哪一个APT组织实施的，目前官方仍然没有一个定论。卡巴斯基研究人员发现，在算法上面，SUNBURST后门与俄罗斯APT组织Turla使用的Kazuar恶意软件存在许多相似之处，因此判断与俄罗斯APT组织有关；国外相关知情人士认为是有俄罗斯背景的组织APT29，但没有任何确凿证据；还有报道说是由美国政府发起的，自己人打自己人。

个人看法：从后门的实现功能和设计理念上看，就不像是美国国家APT组织实施的。美国的网络武器库中，随便挑选一种后门程序都比第三阶段的后门要实用，实在没必要使用被安全人员分析透的CobaltStrike远控，当然我这里指的不是第二阶段的后门Sunburst。

综上所述，我个人更倾向于这个观点：俄罗斯APT29组织发起此次Solawinds供应链攻击。