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

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

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

• 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供应链攻击。

1.  该APT组织编写的Sunspot工具、Sunburst后门，所使用的技术是非常高超的，对应着APT攻击事件的Advanced，高级的技术。

2.  APT攻击者为了实施此次APT供应链攻击，在搭建源码编译测试环境及编写后门代码方面，准备了长达一年的时间，对应着APT攻击事件的P，持久性及绕过各种防护。

3.  该攻击事件影响了1万8千家Orion客户公司，成功入侵了美国100个左右的核心单位，对应着APT攻击事件的T，危害性。

4.  如果Oriaon客户公司事先按照Solarwinds的安全操作规范，将Orion网管软件服务器配置为只与SolarWinds官网通信，或者放在防火墙后面隔离，那么Sunburst后门由于无法外连的原因而攻击失败，但是包括微软公司、Mandiant安全公司在内的许多数受害者没有这样做。

5.  在此次攻击事件溯源的最初的几天里，团队们被要求只能通过电话和外部账户进行沟通，防止攻击者通过监视邮件往来得知溯源工作的最新情况。

6.  后续ABC_123会专门写文章介绍Sunburst后门的设计思路，如何绕过层层流量监控以及美国网络安全公司如何将此次攻击事件溯源出来的，敬请期待。

公众号专注于网络安全技术分享，包括APT事件分析、红队攻防、蓝队分析、渗透测试、代码审计等，每周一篇，99%原创，敬请关注。

Contact me: 0day123abc#gmail.com(replace # with @)