1. 背景

2020 年，一场重大网络攻击渗透到全球数千个组织，包括美国联邦政府的多个部门，导致一系列数据泄露事件。据报道，由于目标的敏感性和高知名度以及持续时间长（八到九个月），网络攻击和数据泄露事件是美国有史以来遭受的最严重的网络间谍事件之一) 黑客可以访问的地方。在其被发现后的几天内，据报道全球至少有 200 个组织受到了攻击的影响，其中一些可能还遭受了数据泄露。全球受影响的组织包括北约、英国政府、欧洲议会、微软等。

该攻击数月未被发现，于 2020 年 12 月 13 日首次公开报道，最初只知道影响了美国财政部和国家电信和信息管理局(NTIA)，部分美国商务部的。在接下来的几天里，更多的部门和私人组织报告了违规行为。

2. SolarWinds 攻击的三个主要阶段

攻击阶段 1：入侵控制 Orion

• 虽然尚不清楚攻击者最初是如何入侵 SolarWinds Orion的，但据报道他们在发起攻击前，学习了很多该公司的代码结构和术语，对该公司非常了解；因此他们一旦进入内网便快速蔓延（对资源充足的攻击者来说，几乎总能找到进入内部的方法；这也是为什么我们需要[[Assume Breach]]）。
• 为了在组织中站稳脚跟，攻击者入侵了 CI/CD 的pipeline（包括DevOps过程中的测试、打包、构建和签名），从而成功更改了 SolarWinds 的源代码。之后攻击者部署了“SunSpot”恶意软件，它以高权限运行，扫描 Orion 版本。

攻击阶段 2：瞄准 SolarWinds 客户

• 在大约两周的休眠期后（故意暂停帮助攻击者掩盖踪迹），恶意有效载荷开始进行一些侦察和操作安全检查（如果在环境中识别出此“清单”上的代理或工具，则恶意软件会尝试终止代理或自行挂起）。
• 然而，如果恶意软件没有找到这些特定的哈希值，它就会进入下一个阶段：从 C&C 服务器分派命令并禁用任何易受攻击的终端agent。
• 由于 Orion 作为受信任的第三方应用程序连接到客户的 Office 365 帐户，因此攻击者能够访问电子邮件和其他机密文档。

攻击阶段 3：向高价值目标提权

• 根据报道，攻击者很可能获取了存储在 Orion 数据库中的凭据，例如 Active Directory、防火墙、基础设施和网络管理软件等传统 Tier0 的资产。这将实现特权的快速升级。有了这些强大的凭据，攻击者就可以立即控制目标网络。

3. Fireeye发布分析报告和检测规则

2020 年 12 月 8 日，网络安全公司FireEye宣布红队工具被它认为是国家资助的攻击者窃取。FireEye 被认为是俄罗斯外国情报局SVR的目标。FireEye 表示，它在调查 FireEye 自身的漏洞和工具盗窃的过程中发现了 SolarWinds 供应链攻击。

分析报告见

• https://www.mandiant.com/resources/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor

公开检测规则见

• https://github.com/mandiant/sunburst_countermeasures

4. 转载：吐槽国内对SolarWinds事件的分析

• 来源
  • https://mp.weixin.qq.com/s/ytm62hJ59XIDi-QRlZTfEg
• FireEye在自己的博客里面给了几个检测建议，我觉得非常好，做甲方安全的同胞们好好看看，是不是对待这种狂酷炫拽吊炸天的供应链，我们就完全没辙了么？其实还是有机会搞一搞的，就看你认不认真了。
  • 攻击者的后门用的是合法的SolarWinds的数字签名，没辙。
  • 攻击者的通信协议模仿的是SolarWinds的API调用，没辙。
  • 从进程树上看来，就是SolarWinds进程的操作，没辙。
  • 攻击者把他们的C2的hostname改成受害者环境里面的hostname，更容易迷惑处置人员。这个地方可以事后进行Hunting，没法事中进行检测。 可以据此使用网络测绘数据进行Hunting。例如使用zoomeye 或者 shodan ，查看全网里面RDP的证书是否有你们公司的。如果有的话，确认下是否真实是你们公司的资产。如果不是，十有八九被用来干你们的。（此处需@heige）
  • 攻击者的C2 IP为了躲避检测，都用的跟受害公司同一个国家的VPS。如果攻击者使用C2 IP来访问被搞的账户，企业可以通过账户异常来检测到这个攻击。 这个地方搞黑产的好像都是共识了，使用被攻击账户的同一个省市的拨号IP，连账号异常都很难触发。实际检测中要结合设备环境信息和账户操作习惯信息来更好的判定。
  • 攻击者通过获取的凭证进入网络后，他们会使用多个不同的账户凭证进行横向移动。用来横向移动的凭证不会和进入网络的账户凭证一致。避免横向移动被发现后，网络权限也被干掉了。 这里可以通过检测是否有一个系统对多个系统使用多个不同账号进行批量登录尝试的行为。
  • 攻击者先把被控机器上合法的文件替换成他们的恶意文件，然后执行恶意文件，之后再把合法文件替换回去。例如，把你电脑上的notepad替换成他的恶意notepad，然后他执行下恶意notepad，执行完恶意notepad，再恢复到合法的notepad。 这个地方做检测的人应该会很有感触，如果EDR的日志里面只记录了进程调用信息，但没记录进程的MD5，光看日志，是识别不出来这次的恶意操作的。当然，如果替换的恶意notepad本身做的事情比较明显，也会被告警。如果做的动作没那么大，这个告警百分百会被忽略掉。即使记录了进程MD5，处置人员很可能也会忽略。没有几个人想到还去对比下前后MD5是否一致。这里FireEye给的建议是对这种短时间内创建执行删除再创建的行为进行告警。（敲黑板，这个地方其实是让大家在检测里面多增加一种异常行为维度）
  • 攻击者把原来合法的计划任务替换成他们要执行的文件，执行完再恢复到原始计划任务。 这里FireEye给出的建议是监控这种临时的计划任务修改，通过频率分析来识别这种异常计划任务更改。
  • 上线使用DGA域名，这个地方大家可以深入看下。人工智能来解决安全问题前几年不是炒的很热么？检验你们成果的时刻到了。
  • 攻击者通过先前获取的管理员权限进一步获取被攻击的组织的 可信SAML token签名证书，通过这个他们可以伪造成组织内任何一个高权限账户的SAML token（可以理解成搞定了一个accesskey的生成证书）。
  • 使用这个可信的SAML token签名证书创建的SAML token，可以对信任该证书的任意云环境资源进行访问。因为该token是用他们的可信证书签名的，即使有告警，该异常也会被忽略（随意创建具备高权限的accesskey）。 对待SAML token这种类似于云的api key，统统需要当成账户一样的资源来认认真真做下异常的“账户登录识别”，就是api key的使用异常识别（敲黑板）。
  • 通过上述方法搞定的高权限账户可以给已有的任意应用服务添加攻击者的凭证，这样他们就能直接访问这些应用服务了（通过该accesskey访问任意资源）。 对添加凭证这种操作，要记录整个链路，谁通过什么方法，添加了一个怎样的key。这个操作是否异常。这样才能在响应的时候进行上下文关联。

5. 参考资料

• https://www.cyberark.com/resources/blog/the-anatomy-of-the-solarwinds-attack-chain
• https://www.fireeye.com/content/dam/fireeye-www/current-threats/pdfs/wbnr-unc2452-presentation-slides.pdf