针对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后门总体流程

　　总体流程图：

　　

　　（Sunburst的供应链攻击各阶段-图源:微软官网）

　　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提取与分析

　　1 代码执行/Execution

　　1.1 红队视角

　　无论是红队后渗透还是真实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文件。优点是跳过了静态文件查杀，不会明显产生进程间调用关系和进程调用参数，缺点是需要自己开发内存加载执行的代码，很多常规的命令需要自己重新实现。

　　1.2 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处，下图是进程名检测部分:

　　

　　2 环境检测/Discovery

　　2.1 红队视角

　　红队技术传统技术往往高度关注进程列表检测、驱动列表检测的技巧：

　　2.1.1 进程检测

　　对于杀软和安全软件的检测，我们通常使用taskllist /v和tasklist /svc来检查进程和服务，可以认为这是一种手工判断+LotL的 *** 。这里推荐两款自动化的检测脚本和工具，大家可以根据自己的需求进行改造，结合内存加载实现BYOL的方式来检查安全软件。

　　(1)ProcessColor.cna，一款Cobalt Strike的插件脚本，可以帮助我们标记出常见的安全软件、监控软件、分析软件。

　　

　　(2)Seatbelt的InterestingProcesses命令，C#开发的多功能信息搜集工具，可单独使用，可结合其他程序实现内存加载。

　　

　　

　　2.1.2 驱动检测

　　既然进程和服务都检测了，那么检测这些驱动有什么意义吗？

　　

　　在常规的情况下，检查进程和服务名称就可以了解当前系统的安全软件运行情况，但是一些高级系统管理员会修改进程和服务的名称，我们就没办法判断了。Sunburst后门在环境检测中还检查了系统驱动，这些驱动大部分都是杀软和EDR产品使用的。这一点是值得红队人员借鉴的，下面以sy *** on为例进行说明。

　　

　　图中左侧为常规的sy *** on安装，我们可以在进程和服务中找到sy *** on。右侧只是简单地把sy *** on进行重命名，安装之后我们在进程和服务的名字中已经找不到sy *** on了，只能找到修改后的名称。这个时候查看驱动就很必要了，因为sy *** on默认安装的驱动路径和名字并没有改变，如下图：

　　

　　即使管理员在安装sy *** on的时候将默认的驱动名称也改了，但是每个驱动都有一个唯一的altitude，要修改这个成本就很高了。sy *** on的altitude是385201，如下图，可以对比上图，这个是不变的：

　　

　　2.2 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地址

　　3 C2通信/Command and Control

　　代码运行起来，检测环境上下文是安全的，最后的一步就是和C2服务器进行通信了。Sunburst后门通过自定义的DGA算法生成C2域名，通过自定义DNS通道进行上线通知，通过自定义HTTP通道进行指令下发与数据回传。

　　3.1 红队视角

　　对于红队来说，最常规的出网协议是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服务器就会收到告警。

　　

　　告警信息如下：

　　

　　3.2 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的了解的确十分深入。

　　

　　最后组成了一个 *** ON文本，在其中添加了前面描述的userID，sessionID和一组其他不相关的数据字段。然后它将此 *** ON文档发送到C2服务器。

　　(5)高度迷惑性的C2服务器响应：如果C2通信成功，C2服务器将回复编码压缩后的数据，该数据中包含后门要执行的命令。C2服务器可能还会回复有关要报告的其他C2地址的信息：

　　

　　实际的服务器控制执行代码在Job.ExecuteEngine函数中。以下是黑客C2服务器对远端受害主机控制命令的类型和功能：

　　命令

　　值

　　详细描述

　　空闲

　　0

　　无

　　退出

　　1

　　结束当前进程

　　设置延迟时间

　　2

　　设置主事件循环执行的延迟时间

　　收集系统信息

　　3

　　解析本地系统信息，包括主机名、用户名、操作系统版本、MAC地址、IP地址、DHCP配置和域信息

　　上传系统信息

　　4

　　向指定的URL发送HTTP请求，并把系统信息以特殊格式发送到C2服务器

　　启动新任务

　　5

　　根据文件路径和参数启动新进程

　　枚举进程信息

　　6

　　获取进程列表，并根据参数决定是否获取父进程ID、用户名、域名

　　结束任务

　　7

　　根据PID结束指定进程

　　枚举文件信息

　　8

　　根据文件路径枚举文件和目录

　　写入文件

　　9

　　根据文件路径和Base64编码字符串，将Base64解密字符串的内容以追加模式写入文件，写入后延迟1-2秒

　　判断文件是否存在

　　10

　　判断文件路径是否存在

　　删除文件

　　11

　　根据文件路径删除文件

　　获取文件哈希

　　12

　　获取文件的MD5哈希信息

　　读注册表值

　　13

　　读取注册表值

　　设置注册表值

　　14

　　设置注册表值

　　删除注册表值

　　15

　　删除注册表值

　　获取注册表子项和值

　　16

　　获取注册表路径下的子项和值名称的列表

　　重启

　　17

　　尝试使系统重启

　　(6)高度迷惑性的DGA算法：

　　如果样本通过上述阶段，则样本将在while循环中通过DGA算法开始生成域。样本会延迟域生成之间的随机间隔；此时间间隔可以是1到3分钟，30到120分钟或在错误条件下最长420到540分钟（9小时）范围内的任意随机值。

　　总共用四种 *** 来生成url，分别为GetCurrentString，GetPreviousString，GetNextStringEx和GetNextString函数。

　　

　　下图是四种 *** 的调用条件，以及会组成的URL的之一段格式如上图。这里需要了解一个变量和两个算法，才能对DGA的算法生成过程更加了解。一个变量是GUID,两个加密算法即CryptoHelper.Base64Encode和CryptoHelper.Base64Decode。

　　其中GetCurrentString/GetPreviousString可以认为是之一阶段DGA，包含可以完整解析的域名，GetNextStringEx/GetNextString可以认为是第二阶段DGA，包含了有效的服务器时间戳等信息。

　　

　　不管哪种生成方式，在OrionImprovementBusinessLayer.GetOrCreateUserID中，HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptography的 MachineGuid值和之一个 *** 适配器的物理地址MAC组成了UID，并通过计算UID的MD5哈希，再用ComputeHash类的 *** 将 MD5 哈希值作为16字节的数组返回，异或之后最终输出64位哈希值这样得到目标GUID。GUID通过CreateSecureString函数进行加密，CreateSecureString函数中使用了CryptoHelper.Base64Encode算法加密。所以整个加密过程全是CryptoHelper.Base64Encode函数和CryptoHelper.Base64Decode函数实现的，研究的重点就是CryptoHelper.Base64Encode函数和CryptoHelper.Base64Decode函数。然而这两个函数都并不是名称表示的常见的Base64编解码函数。

　　

　　CryptoHelper.Base64Decode其实是自定义的加密算法。

　　

　　CryptoHelper.Base64Encode其实是自定义映射表的Base32算法。

　　

　　下图是GetCurrentString/GetPreviousString函数加密方式中以CryptoHelper.Base64Decode加密域名的方式生成的URL。蓝色的表示会随机变化，黑色表示固定不变。紫色00带有下划线代表是此种加密方式的标志位。

　　一、前15个字节是GUID被加密过后的编码0fn7oe4cegrf933

　　二、中间一个字节是通过CreatString生成的“c”

　　三、后面的mudofi75f4tjvh则是AD域被编码后的字符串。

　　因为这里十六个字节过后有“00”开头的标志，所以可以断定应该调用OrionImprovementBusinessLayer.CryptoHelper.Base64Decode对应的解码算法。解码后可以得到域名称：WASHO。

　　

　　下图就是通过GetNextStringEx和GetNextString函数加密的方式生成的URL。对照上图其实如果没有“00”标志，这种URL形式和GetCurrentString/GetPreviousString函数加密方式中以CryptoHelper.Base64Encode加密域名的方式是很像的，所以这种直接使用CryptoHelper.Base64Encode对应的解码算法即可，最终得到spsd.sk.ca域名。

　　

　　安全研究员@bambenek在其Github上公布了1722个疑似与此次攻击事件相关的DGA域名:

　　

　　通过上述DGA域名格式解析，我们仅提取最有价值的以“.”分隔的之一段看起来杂乱无序的编码尝试进行逆向解密，如下是解密结果的部分展示，可以发现此次黑客攻击目标的组织数量巨大，包括多数大型美国 *** 和企业的常见域名。

　　

　　因为GUID是通过MD5计算出来的，所以要想还原MAC地址是不可能的，但这并不代表GUID就没有价值。FireEye在其GitHub上发布的DNS请求内部包含以下加密的GUID：

　　

　　我们在解密出的文档中搜索发现同样的规律：

　　r1q6arhpujcf6jb6ervisu10odohu0it.appsync-api.us-west-2.avsvmcloud.com

　　domain name part GUID (0x2956497EB4DD0BF9) offset 0 = central.pima.g

　　0oni12r13ficnkqb2w.appsync-api.us-west-2.avsvmcloud.com

　　domain name part GUID (0x2956497EB4DD0BF9) offset 35 = ov

　　r8stkst71ebqgj66ervisu10bdohu0gt.appsync-api.us-west-2.avsvmcloud.com

　　domain name part GUID (0x683D2C991E01711D) offset 0 = central.pima.g

　　ulfmcf44qd58t9e82w.appsync-api.us-west-2.avsvmcloud.com

　　domain name part GUID (0x683D2C991E01711D) offset 35 = ov

　　617stsr6ntep0auho2v60be2h.appsync-api.us-east-2.avsvmcloud.com

　　domain name part GUID (0x92EB3D64B8A03CB) offset 35 = ions.com

　　由此可见相同GUID可以作为域名长度过长时进行分割的子串，逆向拼接即可形成完整的域名。

　　总结

　　本文从红队的视角分析了Sunburst后门中的TTPs，其后门实现逻辑可以看出攻击者把安全隐蔽(OpSec)放在了之一位，虽然其中很多技术是恶意软件本身的技巧，但是涉及的一些思想和TTPs对红队建设仍有很大参考价值，也透露出现阶段红队技巧和之一梯队APT组织实战攻击技巧的差距。红队行动首先就要制定策略，是隐蔽优先还是速度优先。但是无论哪种策略，OpSec始终是红队人员的必修课。

　　参考文献

　　[1] Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With Sunburst Backdoor

　　[2] Sunburst Additional Technical Details

　　[3] Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers

　　[4] 从Solarwinds供应链攻击（金链熊）看APT行动中的隐蔽作战,

　　[5] Sunburst Cracked,

　　[6] Sunburst DGA decoder,

　　[7] Living Off The Land Binaries and Scripts (and also Libraries)

　　[8] Bring Your Own Land (BYOL) – A Novel Red Teaming Technique

　　[9] ProcessColor.cna

　　[10] Seatbelt InterestingProcessesCommand

　　[11] Sliver