Part1 前言

大家好，我是ABC_123。本期继续分享Solarwinds供应链攻击事件的第4篇文章，就是美国FireEye火眼安全公司在遭受攻击者入侵之后，是如何一步步地将史上最严重的Solarwinds供应链攻击事件溯源出来的。

注：Mandiant安全公司已被FireEye收购，但是仍然可以独立运营，严格地说的，这次攻击事件是Mandiant公司溯源出来的，当然也可以说FireEye公司溯源出来的。

Part2 部分美国单位遭到入侵

• 美国智库遭受入侵
  

2019年底，一家美国智库内部网络遭受入侵，美国安全公司Volexity帮忙做应急处理，很快将攻击者踢出网络，但是攻击者技术明显高超很多，很快又出现在内部网络中。此后每周都多次往返于内部网络中，窃取特定高管、专家和IT员工的邮件，将邮件内容发送到外部服务器。随后安全公司又花了一周的时间将攻击者踢出网络，但是不知道为啥，在2020年6月下旬，攻击者又卷土重来，又从相同的账号中窃取邮件信息。

Volexity安全公司的安全人员花了数天的时间尝试弄清楚攻击入口，最终他们将注意力集中在一台网管服务器上，上面安装了Solarwinds公司的网管软件Orion。安全团队认为攻击者一定是在该服务器上留下了后门，但是经过大量调查发现，他们找不到后门，最后他们再次将攻击者踢出网络。为了安全起见，他们建议客户将此服务器与互联网断开，禁止外网通信，至此攻击停止。但是攻击者是如何入侵智库网络的，并没有调查清楚，还是个谜。

• 美国司法部遭受入侵
  

在2020年5月下旬，美国司法部发现自己遭到了入侵，他们的网络中的Solarwinds软件试用版服务器出现了问题，有传输到互联网的异常流量。于是他们请了Mandiant安全公司（已被FireEye收购）帮忙调查，后来还请了微软公司参与调查，但是最终都没弄清楚攻击者是如何进入内部网络的。据消息人士称，当时调查人员怀疑攻击者可能是通过Solarwinds软件漏洞直接入侵了司法部的服务器，但是后来没有找到相关的证据，此事就作罢了。

这两起公布出来的事件实际上都是Solarwinds供应链后门入侵事件造成的，但是都没有被溯源分析到，直到FireEye公司发现入侵痕迹，并且进行了深入调查，才逐步揭开该事件的真相。

Part3 FireEye公司处理过程

• FireEye公司发现安全告警
  

2020年11月10日，FireEye公司（收购了Mandiant）的内部安全日志审计中，一名分析师发现了一条安全告警：一位员工注册了一个新的三星手机接收双因素认证验证码（每当员工在多重身份验证系统中注册新手机的时候，都会触发此类告警），但是分析师发现了这个三星手机有点不同寻常，在系统中没有相关联的手机号码。

分析师仔细查看了手机的活动日志，又观察到另一个奇怪的细节：该员工使用手机从佛罗里达州的一个ip地址登录了他的VPN账号，但是这名员工不在佛罗里达州，他在多重身份验证系统上旧的iphone手机仍然处于可用状态。然后同一时间，该名员工使用三星手机在佛罗里达州的ip地址登录，同时该名员工使用iphone手机在自己所在的州登录了vpn账号。经过询问，当事员工反馈这段时间他并没有在系统中注册新的手机号码，这是一个非常明显的网络遭到侵入的信号。

FireEye的安全团队很快阻止了这个三星手机的访问，然后花了一周的时间去调查入侵者是如何获取员工的vpn账号密码的。他们很快意识到这个问题已经不是某个员工的账户失陷了，可能FireEye的内网已经被入侵了。通过日志分析来看，攻击者实施了Golden SAML攻击，这是一种用于劫持公司任意员工身份验证系统的复杂技术，他们可以夺取任意员工账户的控制权，授予这些账户更多权限，甚至可以创建具有无限访问权限的新账户。有了这种能力，攻击者可以深入访问到公司内部的任何网络和资产。

• FireEye公司初步调查
  

2020年11月17日，Mandiant公司组织了一个大约10人的顶级调查团队，专门负责调查此次攻击事件，由于高层担心调查不一定会发现什么重大事件，因此需要控制知情人范围，起初并没有派很多人参与调查。他们发现过去几周，攻击者利用网络中已有的网络工具实施入侵行为，这是为了避免留下自己的常用工具，然后还使用了无文件落地攻击技术，同时，他们在入侵过程中，还避免留下日志和其它痕迹。

与此同时，多个受害客户都要求Mandiant公司协助他们去追踪攻击者的的对外通信，他们发现，对于每个受害者，攻击者都会建立一个C2服务器专门与之通信，而且这几起安全事故有很多相似之处。同时Mandiant的安全团队由于疫情原因在家里工作，每天连接电话会议，持续了18个小时，一边梳理日志和系统，一边绘制黑客走过的每一个步骤。

• 发现Solarwinds服务器异常通信
  

于是FireEyey公司开始组织大量人员参与调查，安全团队提出了一连串的假设，并花费数周的时间追踪每一条线索，但是最终什么也没找到。在他们几乎已经失去了希望的时候，他们在流量日志中无意中发现了一个重要的线索：一台服务器曾经与互联网的一个系统短暂通信过，而这台服务器正在运行着Solarwinds的Orion软件。这个Orion软件只应该偶尔与SolarWinds的网络通信以获取更新，但实际上它正在与一个未知的系统通信，很可能是黑客的C2控制服务器。

• 发现Orion软件后门
  

安全团队怀疑入侵者在Orion服务器上安装了后门，然后派了一名技术总监和两名安全人员来寻找后门，这个任务非常繁重，因为Orion软件套件由超过18000个文件和14GB的代码和数据组成。然而在2020年12月11日，他们只花了24小时就找到了隐藏的后门，这个后门文件是一个dll动态链接库文件，也是其它程序共享的代码组件。

这个dll文件非常大，包含约46000行代码，执行了4000多个合法的操作，它原先的主要工作是告诉SolarWinds公司有关客户Orion软件使用情况的信息。在他们分析了一个小时后，这个dll文件还执行了一个非法的操作。经过继续的分析发现，攻击者在此dll文件中嵌入了大量的恶意代码，将受害者网络数据传输到他们的C2服务器，而且代码的命名规范刻意模范了原有研发人员的习惯，看起来和正常的代码相差无几。

• 发现Orion官方更新包存在后门
  

现在他们必须弄清楚入侵者是如何将它偷偷嵌入到Orion软件的.dll中的，这远非易事，因为这个Orion的dll文件是用SolarWinds数字证书签名的，这个数字证书验证该文件是合法的公司代码。一个可能性是攻击者窃取了数字证书，创建了一个后门版本的Orion文件，签名该文件以使其看起来是正常的，然后安装了恶意的.dll文件在Mandiant公司（FireEye公司）的服务器上。第二个可能性是，他们可能已经入侵了SolarWinds的网络，在SolarWinds将代码编译为软件并签名之前，修改了合法的Orion.dll源代码。

Mandiant公司的团队起初认为第二种情况不太可能，以至于在溯源分析过程没有认真对待它。直到后来，一名调查员从SolarWinds网站上下载了一个Orion软件更新包，发现其中有相同的后门，这才发现是攻击者在Solarwinds的官方Orion软件更新包中植入了后门。

这个发现是惊人的！Orion软件套件在全球有大约有33000个客户，其中一些客户从3月份开始就收到了被黑客篡改过的软件更新，这意味着一些客户可能已经被攻击者入侵了八个月。攻击者这一举动可以感染数千台机器，甚至可能是数百万台。Mandiant安全团队意识到自己正在处理一个，可能是有史以来影响最大的软件供应链攻击案例，攻击者对可信软件的源头进行了恶意修改，植入了后门代码。

• FireEye公布Solarwinds后门情况
  

2020 年 12 月 8 日，FireEye 在其官方博客发布了一篇文章，文中提到，“一个具备顶级网络攻击能力的国家”正在针对 FireEye 进行网络攻击，并且已经成功窃取了FireEye的一批安全研究工具软件。随后，FireEye 的研究人员开始分析内部的 SolarWinds 软件服务器，但并没有发现服务器上有任何恶意软件的安装痕迹。研究团队于是决定对服务器上的SolarWinds 软件进行逆向分析，在其中的一个模块中发现了具有 SolarWinds 公司数字签名的恶意代码。

• FireEye将后门情况通报给Solarwinds公司
  

2020 年 12 月 12 日，FireEye 将相关情况通报给SolarWinds公司。同一天，SolarWinds 向美国证监会和公众披露了攻击事件，此次供应链攻击事件由此浮出水面。之后，新的受害者陆续被发现，其中最引人关注的是美国商务部、国土安全部、国务院、财政部、核安全委员会等联邦机构，甚至微软公司的部分源代码也被攻击者窃取。SolarWinds公司承认，约1.8万名该公司客户遭到网络攻击。

• 微软OWA Duo MFA绕过
  

会议中有一名微软员工，告诉大家在某些情况下，黑客正在系统地入侵微软Office 365电子邮件账户和Azure云账户，黑客还能够绕过多因素身份认证。

Volexity的调查给出了攻击者绕过Duo MFA保护的OWA服务器的一些技术细节。从Exchange 服务器的日志来看，攻击者使用了用户名和密码进行登录，但是没有输入Duo的第二认证因子，从Duo服务器的日志来看，也没有发起需要使用Duo进行二次认证的请求。Volexity 公司通过OWA服务器导出的内存，可以确定用户的会话并没被劫持，但是攻击者直接使用了合法的Duo MFA的Cookie参数duo-sid。

这是怎么做到的呢？首先，攻击者在OWA服务器中获得了Duo集成身份认证的秘钥（akey）。然后，攻击者利用这个秘钥构造了一个计算好的Cookie参数duo-sid。最后，攻击者使用用户名和密码进行登录，使用duo-sid来认证Duo MFA的检查，最终实现了登录。攻击者利用的就是MFA本身的机制，并不是一个漏洞，所以没有触发任何安全防护机制。

Part4 SolarWinds公司处理过程

• 禁止使用电子邮件沟通
  

接下来就是Solarwinds公司来处理这件事情。在最初的几天里，团队成员们被要求只能通过电话和外部账户进行沟通，直到CrowdStrike批准他们再次使用公司电子邮件。这个要求后续被证明是非常明智的，因为后续调查发现，攻击者已经入侵了至少71个SolarWinds的电子邮件账户，并且一直在暗处监视Solarwinds公司的邮件内容，查看是否有任何迹象表明他们被发现了。

• 分析日志和查看入侵痕迹和分析日志
  

团队的首要任务之一是收集可能揭示黑客活动的数据和日志。他们很快发现，他们需要的一些日志并不存在，SolarWinds无法追踪所有内容，并且一些日志已被攻击者删除或随着时间的推移被新的日志数据覆盖。他们还想查看公司近100个其他产品是否受到了攻击，他们只找到了Orion受到攻击的证据。

• 遗留的编译虚拟机快照成为突破口
  

随后SolarWinds公司一直在想办法查找入侵者是如何将Orion的恶意dll文件放入编译服务器的，最终在2021年1月5日，一个SolarWinds工程师发现了一个旧的虚拟机快照留存。这个虚拟机是由名为TeamCity的软件构建管理工具创建的，TeamCity会启动大约100个编译虚拟机来完成它的软件编译工作。通常这些虚拟机是短暂存在的，只存在于编译软件所需的时间内。但是，如果构建过程的某个部分因某种原因失败，TeamCity会创建一个“内存转储”快照在发生故障的虚拟机中，该快照包含故障发生时虚拟机的所有内容。

这个快照是在2020年2月的软件构建中留下的，通常SolarWinds工程师会在后续的清理过程中删除这些快照，但是幸运的是，他们没有删除这个快照。所以天网恢恢疏而不漏，如果不是因为它的不可思议的存在，很可能最终的调查取证会一无所获。

• 发现后门投递工具Sunspot
  

在这个编译虚拟机快照中，调查人员发现了一份恶意文件，调查人员称其为“Sunspot”。这个文件有大约3500行代码，这些代码成为了解关于攻击者入侵行为的关键。

调查人员通过分析Sunspot相关的活动发现，攻击者在2月19日或20日将其植入了软件构建服务器，然后一直潜伏在那里。直到3月份，当SolarWinds的开发人员通过TeamCity开始构建Orion软件更新并创建了一组虚拟机时，攻击者不知道哪个虚拟机将编译Orion .dll代码，因此设计了一个工具将Sunspot部署到每个虚拟机中。

此时，APT组织的攻击手段的美妙和简洁显露无遗，一旦dll文件出现在虚拟机上，Sunspot就会快速自动地将此合法文件重命名，并用含有Sunburst后门代码的文件替换它，后续编译完成之后，会自动将原有的合法文件恢复到原有位置，并将含有后门代码的副本文件删除。构建系统随后获取了经过攻击者修改的dll文件并将其编译到Orion软件更新包中，整个操作只需要几秒钟的时间。

但是在6月4日，攻击者突然从构建服务器中删除了Sunspot，并清理了许多痕迹。这个举动非常怪异，随后的调查揭示了原因，由此更让安全人员叹服此APT攻击组织的高超的技术和缜密的计划。

• 发现攻击者暗处监视邮件往来
  

在后来的安全讨论会上，一名男子透露，在2020年春季，该机构的人员发现了一些来自运行Orion的服务器的异常流量，并联系了SolarWinds公司的安全人员讨论此事。这位男子猜测，当时正在监视SolarWinds电子邮件账户的攻击者感受到了问题的严重性，并删除了Sunspot工具，因为他们担心攻击行为暴露，担心安全公司将会发现他们的入侵行为。

Part5 应急处置

2020 年 12 月 18日，FireEye、微软、GoDaddy 联合接管了Sunburst 后门通信使用的域名，并指向了受控域名，阻断了遭攻击网络中的恶意Sunburst后门与控制服务器之间的通信。

但是这几家公司是如何巧妙地让所有客户的Sunburst后门终止运行的，并没有公布。根据上一篇ABC_123的文章的介绍，我们可以做如此假设：若GoDaddy建立一个通配符的DNS解析方案，把所有avsvmcloud[.]com的子网域都解析至20.140.0.1，再把20.140.0.1列入黑名单，那么Sunburst在dga域名请求过程中，就会参考如下列表中20.140.0.1这个ip对应的指令，永久终止自己的后门活动。

Part6 总结

1. Solarwinds公司对于日志没有进行备份留存，导致溯源Sunburst后门事件的时候日志缺失或者被覆盖，极大地影响了溯源工作的进展。

2. 早期几家安全公司处理Solarwinds客户的Orion服务器被入侵事件时，并没有深入分析，导致相继错过发现Sunburst后门，险些造成此次供应链攻击事件被隐藏更长时间。

3. 在调查取证的初始阶段，禁止安全人员使用邮件通信来交流溯源工作进展，这个方法非常明智，值得推广。

4. 在后期，FireEye、微软、GoDaddy之间合作，通过控制dga域名解析ip的方式，使所有的Sunburst后门终止活动，这个应急处置方法非常及时，体现了这几家公司对于APT后门样本分析的能力。

5. FireEye公司对此攻击事件的不遗余力地深入追查，最终导致Solarwinds供应链攻击事件被揭露出来。

6. 天网恢恢疏而不漏，最终一个遗留的几乎是一定会被删除的编译虚拟机快照的留存，导致SunSpot后门投递工具被发现。所以我们广大网络安全工作人员，一定要遵纪守法，对自己的行为负责。

7. 按照标准做法，Orion服务器应该被配置只能与Solarwinds通信，但是多数客户都没有这样做，直接配置为允许外网通信。为了安全考虑，但只有20%到30%的Orion用户将服务器配置成允许与外网通信，因此只有这些客户才会遭到入侵。所以安全规范不是纸上谈兵，按照合规要求踏踏实实地去落实，就可以抵御这次顶级APT攻击。

8. 做应急响应，首先要画好时间轴，一点点补充攻击事件，这是非常有效的方法，在本次APT攻击事件中，几家安全公司都采用了这一方法。

9. 随后的分析发现，攻击者不仅仅是想窃取数据，他们还在对抗他们最大的敌人，进行反情报活动。因为当客户遇到安全事件时，他们最经常联系的安全公司是FireEye公司，所以攻击者把目标指向了它，如果FireEye公司被攻击者彻底攻下，那后果不堪设想。由此可见，该APT组织的目标，也在随着供应链攻击的成功逐步扩大。

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

原文始发于微信公众号（沃克学安全）：美国安全公司溯源分析Solarwinds供应链攻击事件全过程