针对SolarWinds供应链攻击简介
最近FireEye披露的UNC2452黑客组织入侵SolarWinds的供应链攻击让安全从业人员印象深刻。一是影响规模大,SolarWinds官方称受影响的客户数量可能有18000家。二是攻击者留下的后门程序-Sunburst,十分隐蔽和具有迷惑性,分析认为攻击者对SolarWinds Orion产品理解程度很深。
有证据表明,早在2019年10月,UNC2452黑客组织就一直在研究通过添加空类来插入代码的能力。因此将恶意代码插入原始SolarWinds.Orion.Core.BusinessLayer.dll的时间可能很早,甚至可能是在软件构建编译之前。这就导致SolarWinds官方无意间对包含4000行恶意代码的DLL进行了数字签名,这样容易让恶意代码提升权限,并且很难被人发现。感染的Origin软件第一个版本是2019.4.5200.9083,在此几个月的时间内,用户通过下载受到感染的产品版本被感染。目前原始dll文件中没有发现存在动态拓展、也不存在横向移动等后渗透阶段的相关能力支持。
Sunburst后门总体流程
总体流程图
<cernter>(Sunburst的供应链攻击各阶段-图源:微软)</cernter>
Sunburst后门总体流程可以简单地概括为以下几个阶段:
(1)SolarWinds.BusinessLayerHost.exe加载SolarWinds.Orion.Core.BusinessLayer.dll,并执行其中的恶意代码。
(2)代码通过9层环境检查,来判断当前环境上下文是否安全,是否应该继续执行。
(3)如果检查通过,尝试使用DGA算法生成的域名发送DNS上线通知,并检查DNS解析结果是否满足自身运行要求。
(4)DNS上线通知成功,则会尝试使用两种User-Agent和3种代理模式,与C2服务器建立起HTTP控制通道。
(5)Sunburst后门本身能处理的控制指令并不多,攻击者可以下载自定义的Payload,例如Cobalt Strike beacon,即TEARDROP进行进一步操作。
Sunburst后门的代码都在SolarWinds.Orion.Core.BusinessLayer.dll这个文件中,这是个C#编写的.NET assembly,可以直接反编译查看源代码,分析其运行逻辑。主要涉及的三项技术为代码执行(Execution)、环境检测(Discovery)和C2通信(Command and Control)。
TTPs提取与分析
代码执行/Execution
红队视角
无论是红队后渗透还是真实APT攻击,第一步要在受害者的机器上运行起来控制程序(agent/implant/artifact)。Windows系统上的代码执行的方法有很多,也可以从多种角度进行分类和总结。这里作者将之分为以下三类:
(1)BYOB: Bring Your Own Binary,就是把后门、工具、武器编译成exe文件,上传到目标主机上并运行。这也是最直接的执行方式。缺点是需要不断的编译和上传、要处理杀软和EDR的静态检测等等。
(2)LotL: Living off the Land,可以理解为就地取材,利用Windows系统和应用程序来加载执行恶意代码,典型的案例就是利用powershell的攻击。这种方式利用白名单程序来加载,会有一定规避检查的优点,但会产生明显的父子进程关系和进程参数,容易被猎捕。
(3)BYOL: Bring Your Own Land,这也是FireEye提出的一种方法,在使用前两种方法建立了基本的代码执行能力后,在内存中加载并运行Windows的PE文件、.NET assembly文件。优点是跳过了静态文件查杀,不会明显产生进程间调用关系和进程调用参数,缺点是需要自己开发内存加载执行的代码,很多常规的命令需要自己重新实现。
Surburst实际攻击技巧
本次供应链攻击的Sunburst后门存在于SolarWinds.Orion.Core.BusinessLayer.dll文件中,它的运行需要SolarWinds.BusinessLayerHost.exe这个合法的进程来加载,可以理解为是一种变形的Living off the Land执行方法。类似于DLL劫持,但相比于常规的DLL劫持,这类修改原始DLL的供应链攻击后门显得更加隐蔽。往往有以下特点:
(1)修改原有的DLL,不会产生多余的DLL文件落地
(2)程序加载DLL运行,不会产生子进程和进程参数
(3)供应商的信任进程不在常规进程检测名单,已知Windows lolbins检测规则无效
本次的DLL后门,可以看到作者很注重隐蔽(OpSec),代码中透露着检测对抗的思想,其隐蔽技巧表现为:
(1)DLL合法的数字签名,很大程度上规避了静态文件查杀:
(2)代码通过创建新线程,执行SolarWinds.Orion.Core.BusinessLayer.dll.OrionImprovementBusinessLayer库目录下的Initialize函数开始恶意动作。DLL入口函数调用栈较深,通过6层的调用才开始执行代码,动态跟踪需要花费更多精力:
(3)代码使用自定义hash算法,常量字符串都进行hash处理,避免敏感字符串在传输流量和本地文件扫描时发现。实际使用的地方有9处,下图是进程名检测部分:
环境检测/Discovery
红队视角
红队技术传统技术往往高度关注进程列表检测、驱动列表检测的技巧:
进程检测
对于杀软和安全软件的检测,我们通常使用taskllist /v和tasklist /svc来检查进程和服务,可以认为这是一种手工判断+LotL的方法。这里推荐两款自动化的检测脚本和工具,大家可以根据自己的需求进行改造,结合内存加载实现BYOL的方式来检查安全软件。
(1)ProcessColor.cna,一款Cobalt Strike的插件脚本,可以帮助我们标记出常见的安全软件、监控软件、分析软件。
(2)Seatbelt的InterestingProcesses命令,C#开发的多功能信息搜集工具,可单独使用,可结合其他程序实现内存加载。
驱动检测
既然进程和服务都检测了,那么检测这些驱动有什么意义吗?
在常规的情况下,检查进程和服务名称就可以了解当前系统的安全软件运行情况,但是一些高级系统管理员会修改进程和服务的名称,我们就没办法判断了。Sunburst后门在环境检测中还检查了系统驱动,这些驱动大部分都是杀软和EDR产品使用的。这一点是值得红队人员借鉴的,下面以sysmon为例进行说明。
图中左侧为常规的sysmon安装,我们可以在进程和服务中找到sysmon。右侧只是简单地把sysmon进行重命名,安装之后我们在进程和服务的名字中已经找不到sysmon了,只能找到修改后的名称。这个时候查看驱动就很必要了,因为sysmon默认安装的驱动路径和名字并没有改变,如下图:
即使管理员在安装sysmon的时候将默认的驱动名称也改了,但是每个驱动都有一个唯一的altitude,要修改这个成本就很高了。sysmon的altitude是385201,如下图,可以对比上图,这个是不变的:
Sunburst实现的机制
SolarWinds.Orion.Core.BusinessLayer.dll中的恶意代码对于运行环境的检查十分严格,一共有9层检测机制,只有当所有检测条件都通过时,其才会执行上线操作。
| 序号 | 检测机制 |
| ------------ | ------------ |
|1|通过哈希判断当前加载恶意DLL的进程名字是solarwinds.businesslayerhost.exe|
|2|恶意DLL的最后写入时间比当前时间至少提前12到14天,说明其会潜伏半个月左右才会执行|
|3|检查硬编码的命名管道583da945-62af-10e8-4902-a8f205c72b2e,避免多进程重复执行|
|4|检查恶意复用的配置选项ReportWatcherRetry,ReportStatus项不能为3,即Truncate退出状态|
|5|检查当前设备所在域,域名中不能包含哈希值校验的黑名单patternHashes中的一些字符串;域名不能匹配到正则表达式“(?i)([^a-z]|^)(test)([^a-z]|$)”,该表达式主要用来检查当前域名是不是测试用的域名;"(?i)(solarwinds)",猜测该表达式主要用来检测是否处于sloarwinds公司办公环境|
|6|检查第一个非回环启用网卡,不在IP黑名单中|
|7|检测进程Hash黑名单(含137个进程),确保当前环境中没有安全相关软件和服务程序,如:Windbg、 Autoruns、 Wireshark,并尝试关闭服务名单中的服务|
|8|检查当前环境中是否存在13个安全软件的驱动程序,如:groundling32.sys|
|9|主机解析“api.solarwinds.com”为指令的IP地址|
C2通信/Command and Control
代码运行起来,检测环境上下文是安全的,最后的一步就是和C2服务器进行通信了。Sunburst后门通过自定义的DGA算法生成C2域名,通过自定义DNS通道进行上线通知,通过自定义HTTP通道进行指令下发与数据回传。
红队视角
对于红队来说,最常规的出网协议是HTTP[S]和DNS协议,但是大多数情况是手动判断目标的网络环境后来选择C2通信的方式。虽然能够修改和自定义C2通信协议,无疑是规避流量检测的好方法,但是相对的成本会比较高,需要同时兼顾客户端和服务端,还需要保证通信质量。简易的做法是利用后渗透框架自身的配置来修改C2流量特征,比如Cobalt Strike、Empire、Covenant等工具都支持Malleable C2 profile的配置。
Sunburst后门这种使用DNS和HTTP协议结合的方式,让作者想起了Sliver C2这款工具的DNS Canary功能。虽然DNS Canary不是用来进行C2通信的,但是提供了一种红队监测蓝队是否分析了自己implant的思路。
Sliver C2生成的implant默认会使用符号混淆来避免杀软查杀,不会出现敏感字符串。但是当使用--canary/-c参数时,会将指定的DNS域名以常量字符串的形式嵌入implant中。并生成一个独一无二的DNS域名,如果蓝队人员分析我们的implant,发现这个域名,只要逆行了DNS解析,我们的C2服务器就会收到DNS查询请求,这说明我们的行动已经被发现。
如下图,红队人员在创建implant的时候,设置DNS canary为mews.cs.local,在生成的implant中,嵌入了mqrrzkj.news.cs.local.和kvn3g0-.news.cs.local两个域名。
当蓝队分析样本,尝试解析域名时,C2服务器就会收到告警。
告警信息如下:
Sunburst后门在该阶段的亮点
(1)很具有迷惑性的DnsRecords代码,用常规的变量名表达其他实际意义。
(2)对DGA生成的域名解析的IP地址,进行白名单、黑名单、等待名单的判断,确定网络解析环境是否安全才会继续执行。
(3)HTTP协议的一种User-Agent会采用SolarWinds产品的User-Agent,更加接近真实可信的流量。
(4)出网会检测代理设置,通过无代理、系统代理和SolarWinds本身配置的代理三种方式是尝试出网,连接C2服务器。
(5)高度迷惑性的C2服务器响应。
(6)高度迷惑性的DGA算法。
上述动作的具体表现为:
(1)具有高度迷惑性的DNS上线请求:恶意代码发送DNS请求并将返回的CNAME信息将保存至DnsRecords对象。
DNS查询如果请求失败,则设置随机7-9小时的休眠时间(代码如下图),进行休眠后再进行下一次尝试。
如请求成功,则首先判断是否存在CNAME信息,如不存在,则处理IP的最后两个字节,修改DnsRecords对象对应的字段:
length字段,此字段用于保存控制阶段应用的代理类型;
_type
字段,此字段决定控制阶段使用的url以及对返回数据的解码方式;
A字段,此字段决定DNS请求查询阶段每次DNS请求之间的延时。
(2)对DGA生成的域名解析的IP地址,进行白名单、黑名单、等待名单的判断:检测到IP处于任一黑名单,将导致状态更改为Truncate,从而导致后续操作全部终止,并作标记此后不再尝试。IP黑名单列表:
IP地址 | 子网掩码 | AddressFamilyEx类型 |
---|---|---|
10.0.0.0 | 255.0.0.0 | Atm内网IP黑名单 |
172.16.0.0 | 255.240.0.0 | Atm内网IP黑名单 |
192.168.0.0 | 255.255.0.0 | Atm内网IP黑名单 |
224.0.0.0 | 240.0.0.0 | Atm内网IP黑名单 |
fc00:: fe00:: | Atm内网IP黑名单 | |
fec0:: ffc0:: | Atm内网IP黑名单 | |
ff00:: ff00:: | Atm内网IP黑名单 | |
41.84.159.0 | 255.255.255.0 | Ipx外网黑名单 |
74.114.24.0 | 255.255.248.0 | Ipx外网黑名单 |
154.118.140.0 | 255.255.255.0 | Ipx外网黑名单 |
217.163.7.0 | 255.255.255.0 | Ipx外网黑名单 |
20.140.0.0 | 255.254.0.0 | ImpLink等待名单 |
96.31.172.0 | 255.255.255.0 | ImpLink等待名单 |
131.228.12.0 | 255.255.252.0 | ImpLink等待名单 |
144.86.226.0 | 255.255.255.0 | ImpLink等待名单 |
8.18.144.0 | 255.255.254.0 | NetBios白名单 |
18.130.0.0 | 255.255.0.0 | NetBios白名单 |
71.152.53.0 | 255.255.255.0 | NetBios白名单 |
99.79.0.0 | 255.255.0.0 | NetBios白名单 |
87.238.80.0 | 255.255.248.0 | NetBios白名单 |
199.201.117.0 | 255.255.255.0 | NetBios白名单 |
184.72.0.0 | 255.254.0.0 | NetBios白名单 |
上述表格中Atm代表内网IP黑名单,ImpLink代表外网IP黑名单,Ipx代表等待名单,NetBios代表白名单。如果返回的IP处于任一黑名单,则恶意代码退出并且设置标记永不再上线。
在进行进程、服务、驱动状态检查通过后,然后还会解析官方域名“api.solarwinds.com”判断是否为指定IP地址,如检验通过则进入后续的感染逻辑,整个逻辑可以用下图表示:
(3)高度迷惑性的User-Agent:当恶意代码从C2域名的CNAME DNS响应中成功检索到域,将产生一个新的执行线程,调用HttpHelper.Initialize方法来与C2服务器通信。
HttpHelper的构造函数会处理由DNS请求查询阶段决定的请求类型与代理类型,两种User-Agent,在正常情况下,第一种会用于Windows检查证书吊销列表。
第二种用于SolarWinds本身的通信过程,将伪装为SolarWinds正常请求链接或静态资源。
(4)高度迷惑性的代理配置:出网代理主要分为三类,无代理、系统代理和红色箭头标明的SolarWinds本身配置的代理,从这点也可以看出黑客组织对于SolarWins的了解的确十分深入。
最后组成了一个JSON文本,在其中添加了前面描述的userID,sessionID和一组其他不相关的数据字段。然后它将此JSON文档发送到C2服务器。
(5)高度迷惑性的C2服务器响应:如果C2通信成功,C2服务器将回复编码压缩后的数据,该数据中包含后门要执行的命令。C2服务器可能还会回复有关要报告的其他C2地址的信息: