网络安全解析：无文件Powershell恶意程序使用DNS作为隐蔽信道

网络安全解析：无文件Powershell恶意程序使用DNS作为隐蔽信道。思科Talos安全团队最近发现一款Powershell恶意程序，用DNS进行双向通信。

前言

DNS是企业网络中最常用的Internet应用层协议。DNS提供域名解析，这样用户就可以通过域名而非IP地址来访问网络资源。许多企业会严格监控web流量，但对基于DNS的威胁的防护就比较少。攻击者也注意到了这点，经常将其他协议封装进DNS协议中来躲避安全监测。

攻击者利用DNS协议一般都是要获取信息。思科Talos团队最近分析了一个很有趣的恶意程序样本，利用DNS TXT记录查询和响应来创建双向的C2通道。攻击者可以通过DNS通信来向感染设备提交命令，并将命令执行结果返回给攻击者。这在远程访问工具中相当罕见，而且隐蔽性较高。此恶意程序中使用了多阶段Powershell脚本，其中许多阶段都是完全无文件的，这就说明攻击者为了避开检测也是很努力的。

讽刺的是，这款恶意程序的作者在代码中高调叫板SourceFire，于是就被思科的Talos团队揪出来了。

正传

说起来，这个故事缘起于一条推特。

推特用户@Simpo13在2月24号发布了一则推文，文中提到他正在分析的一段Powershell恶意脚本，其中包含一段base64编码的字符串“SourceFireSux”(SourceFire sucks的谐音，意为SourceFire烂暴了)。

Simpo的推特图片

SourceFire正是思科于2013年用27亿美元收购的。因此“SourceFireSux”的字眼引起了思科威胁情报团队Talos的注意，而Talos团队中也刚好有SourceFire漏洞研究团队的原班人马，于是他们决定深挖这段恶意脚本。

他们搜索了推文中提到的base64编码值“UwBvAHUAcgBjAGUARgBpAHIAZQBTAHUAeAA=”，发现在公共恶意程序分析沙盒Hybrid Analysis中有一个样本。另外，他们在对编码字符串搜索的过程中还定位到了一条Pastebin条目，其中列出了一写哈希，根据这些，他们找到了一个公共沙盒中的一个恶意Word文件，由此揭开了一个名为“DNSMessenger” 的多阶段感染过程。

在这个特殊案例中，团队先分析了那段被当作VBScript文件提交到公共沙盒中的Powershell文件，他们将之称为为“第三阶段”。他们发现，前面提到的“SourceFireSux”字符串被用作互斥量，如图1所示。

第一阶段恶意Word文档

前面提到Talos团队找到了感染链的源头，也就是那个恶意Word文档。这个文档是通过钓鱼邮件传播的。有趣的是，这个Word文档会伪装成被McAfee保护的“受保护文件”。因为McAfee的名气，受害者打开文件并启用宏的概率也就有所提升。打开后，该文档便诱使用户启用内容。

文档用Document_Open()调用另一个VBA函数。这个VBA函数就会设置一个长字符串，其中包含一个Powershell命令和将执行的代码。然后调用Windows管理界面(WMI)的Win32_Process对象的Create方法，执行上述命令。

通过命令行传递给Powershell的代码基本上是base64编码的，并用gzip压缩的，只有尾部一小部分没有编码。没有编码的这段会被用于解压缩该代码，并传递给Invoke-Expression Powershell cmdlet(IEX)执行。通过这一步骤，代码不需要被写入受感染设备的文件系统，就可以执行。

团队还发现防病毒软件对这个样本的检测率比较低，为6/54，其中ClamAV能够成功检测这个样本。

第二阶段Powershell

第一阶段中的IEX执行Powershell脚本后，Talos团队开始观察到感染设备上出现了一写比较有趣的活动。第一阶段中描述的Powershell脚本末端有一个函数，定义了第二阶段的指令和三阶的相关特性。第二阶段中的代码经过了混淆处理，团队将这个阶段中用到的主函数称为“pre_logic”，将第三阶段中的函数称为“logic”。

“pre_logic”函数支持两个switch参数。第一个用于决定在下一个感染步骤中是否要实现持久性。如果选择实现持久性，第二个switch就会决定第三阶段代码要不要执行。

除了两个switch外，“pre_logic”函数还支持四个参数，这四个参数随后将传递给下一阶段的“logic”函数。这些参数决定，下一个感染阶段发送DNS TXT记录查询时，要使用哪些子域。

随后，“pre_logic”函数会解压第三阶段中用到的Powershell脚本，就是包含在该脚本当中的一个base64编码的blob。该函数还会定义后续阶段将用到的一些代码，包括函数调用和参数。

如果 “pre_logic”函数被调用时，选择了实现持久性，函数将会查询感染系统，决定如何最好地实现持久性。根据恶意程序运行时使用的用户账户相应的访问权限，恶意程序将查询恶意程序实现持久性最常用的注册路径。

如果使用的是管理员权限账户，那么脚本会查询并设置：

$reg_win_path: “HKLM:Software\Microsoft\Windows\CurrentVersion”

$reg_run_path: “HKLM:Software\Microsoft\Windows\CurrentVersion\Run\”

如果使用的是一般用户帐户，脚本则会查询并设置：

$reg_win_path: “HKCU:Software\Microsoft\Windows”

$reg_run_path: “HKCU:Software\Microsoft\Windows\CurrentVersion\Run\”

然后根据系统所用的Powershell版本，第三阶段payload将写至不同位置。如果受感染系统用的是Powershell 3.0或者更高版本，第三阶段payload将写至“%PROGRAMDATA%\Windows\”中的ADS流文件中，并命名为“kernel32.dll”。

如果系统用的是较早的Powershell，第三阶段payload将被编码并写至$reg_win_path指定的位置，键名为“kernel32”。随后，用来解压并执行第三阶段payload的代码也会被写至$reg_win_path分配的注册表位置，键名为“Part”。

这个步骤完成之后，攻击脚本会再次检查并确定用户访问权限。如果是管理员权限，那么被感染系统中的“_eventFilter”、“CommandLineEventConsumer”和“_filtertoconsumerbinding”等WMI事件订阅将会被移除。然后该恶意程序会创建自己的WMI永久事件订阅，筛选出“Win32_LogonSession”事件，并锁定“CommandLineEventConsumer”。受感染系统中每创建一个新的登录会话，之前储存在ADS中的第三阶段payload就会被读取并执行。第三阶段payload默认在30分钟后运行“onidle”。如果在这个阶段开始时，与其执行相关的switch参数被传递至“pre_logic”函数，那么payload就会立即执行。

如上图所示，该恶意程序还在系统中创建了一个预定任务，任务名为“kernel32”，该任务关系到第三阶段payload储存于ADS还是注册表。Talos团队在分析其他与此攻击有关的样本发现，不同样本当中该预定任务可能会有相应的调整。

第三阶段Powershell

第二阶段中执行的第三阶段Powershell，主要是用一些略显傻气的函数名和变量名进行混淆的(比如${script:/==\/\/\/==\__/==}，而不是$domains)。整个脚本从头到尾也都是base64编码的。Talos团队反混淆之后发现，脚本中包含许多硬编码域名，然后将随机选出其中一个，用于后续的DNS查询。有点必须要注意的是，第三、四阶段的Powershell脚本，都包含两组域，只有在样本使用第二组域名出现问题时才会使用第一组域名。

第三阶段Powershell脚本中的“Logic”函数会从脚本中的第二组域中随机选择一个C2域，并用这个域进行初始查找。如果这个初始DNS TXT记录请求的返回值为空，或者说查找失败，那么将调用“do_lookup”函数，并从第一组域中随即选取一个域。

第三阶段脚本还会使用一些特定的子域，与初始DNS TXT记录查询中使用的域相结合。恶意程序用响应的TXT记录内容，来决定下一步动作。比如说，第一个子域为“www”，并且TXT记录查询响应结果包含“www”，就会指示脚本继续。其他指令则会被认为“空”或者“停止”。

恶意程序收到初始DNS响应后，就会迭代至下一个子域，即“mail”。恶意程序会在另一个DNS TXT记录查询中使用这个域，来尝试获取与当前阶段相关的第四阶段payload。这个DNS请求得到响应后，将获取第四阶段payload，储存在TXT记录中，如图10和图11所示。因为第四阶段payload比较大，这次传输过程用了TCP。

下图是Wireshark对上述payload的分析

与第四阶段相关的代码随后会被清理并传递至Invoke-Expression Powershell cmdlet (IEX)，并在第三阶段的语境中执行。第四阶段payload并不能自主执行，如果仅尝试执行第四段payload，就会失败，因为第四段payload依赖于第三段Powershell脚本中的解码函数。

这个函数还有其他几个功能。这个函数会用DNS查询响应结果中获得的代码，定义一个包含该代码的字符串变量。然后，第三阶段中的解码函数会被调用，并将解码的字符串传递给IEX，来扩展Powershell环境。这一步完成后，将调用新扩展环境中的一个函数，来执行第四阶段代码，并设置特定参数。这些参数包含后续将用到的第四阶段C2域名和将执行的程序，即Windows命令行处理器(cmd.exe)。这一步相当有意思，因为这样，第四阶段payload其实是从未被真正写至感染系统的文件系统中。[page]

第四阶段Powershell

如前文所述，四阶Powershell payload是由三阶中的“dec”函数解码。第四阶段payload尾部调用了其中的“cotte”函数，该函数提供了其他一些参数，包括将用到的C2域和将执行的程序(cmd.exe)。当执行cmd.exe时，函数会将STDIN、STDOUT和STDERR重定向，允许payload在命令行处理器中读写。

提供给这个函数调用的域将用来生成DNS查询，用于主要的C2操作。与前面的脚本一致，第四阶段payload当中也有两组硬编码域，但貌似只会用到第二组。

主C2服务器每发回301个DNS响应，样本就会单独发送一个DNS TXT解析请求到前面提到的第二组中随机选择的域。这个C2请求会决定此恶意程序应不应该在受感染系统上继续运行。跟前面步骤当中类似，这个请求也是发送给次级C2域中的“web”子域的。

如果次级C2服务器返回包含字符串“stop”的TXT记录，此恶意程序就会停止活动。

受感染系统向主C2服务器发送“SYN”消息，建立主C2通道。

这一步完成后，先前从Windows命令行处理器中捕获到的STDOUT和STDERR输出会通过“MSG”消息发出。借此，攻击者发送的命令能够被命令处理器直接执行，攻击者全靠DNS TXT请求和响应就能接收命令的输出结果。下文将详细描述此通信过程。

将DNS查询请求解码，我们就能看到发送给C2服务器的是命令行处理器的输出结果。

攻击者就这样建立了一个互动的C2信道，来执行系统命令，并获取命令的输出结果。

C2通信

恶意Word文档中与此感染链相关的C2域注册于2017年2月8日。与Hybrid Analysis中的Powershell样本相关的域注册于2017年2月18日。其中许多域注册时使用的邮箱地址如下：

valeriy[.]pagosyan[@]yandex[.]com

其他域时通过NameCheap代理注册服务注册的。

根据Umbrella的分析，与Powershell样本使用的域有关的大部分DNS活动集中出现于2017年2月22日至2月25日。Word文档使用的域则少有活动，其少量的活动集中于2月11日。

此恶意程序中的所有C2通信都是通过DNS TXT查询和响应完成的。要有互动的“MSG”查询，就必须要建立C2信道，而C2信道建立的先决条件是“SYN”查询。这些消息是由以下元素组成的：

$session_id – 感染设备产生的四位数字，这个数字一直保持不变，而且所有的后续DNS查询和响应中都包含了这个数字。

$sequence_num – 感染设备产生的四位数字，在C2通信过程中定期变化，变化后的新值会被添加至下一个查询中。

$acknowledgement_num – “SYN”消息响应中产生的四位数字，值似乎不会变化，而且必须包括在所有后续的“MSG”查询中。

DNS查询和响应中的第5和第6个字节决定了消息类型，可能是以下值中的任意一个：

00 – ‘SYN’ message

01 – ‘MSG’ message

02 – ‘FIN’ message

其中，用于发送执行命令和返回命令输出的“MSG”查询是十六进制编码的，每30个字节用点分隔。

下图就是整个C2通信的过程。注意在通信过程中，可能有许多个“MSG”查询和响应，这取决于攻击者想要在感染设备上执行的命令。

下图展示了不同的消息及其响应是如何形成的。

结论

从本文的例子中，我们可以看出，攻击者为了躲避检测，可以做到这种地步。本文的例子还说明，除了需要监测和过滤HTTP/HTTPS、SMTP/POC3等网络协议，DNS协议也应该得到应有的重视。企业网络中的DNS流量可以被攻击者利用，来建立双向的C2通信通道，而DNS监控和过滤类产品可有效拦截此类攻击。

IoC

哈希：

f9e54609f1f4136da71dbab8f57c2e68e84bcdc32a58cc12ad5f86334ac0eacf (SHA256)

f82baa39ba44d9b356eb5d904917ad36446083f29dced8c5b34454955da89174 (SHA256)

340795d1f2c2bdab1f2382188a7b5c838e0a79d3f059d2db9eb274b0205f6981 (SHA256)

7f0a314f15a6f20ca6dced545fbc9ef8c1634f9ff8eb736deab73e46ae131458 (SHA256)

be5f4bfa35fc1b350d38d8ddc8e88d2dd357b84f254318b1f3b07160c3900750 (SHA256)

9b955d9d7f62d405da9cf05425c9b6dd3738ce09160c8a75d396a6de229d9dd7 (SHA256)

fd6e7fc11a325c498d73cf683ecbe90ddbf0e1ae1d540b811012bd6980eed882 (SHA256)

6bf9d311ed16e059f9538b4c24c836cf421cf5c0c1f756fdfdeb9e1792ada8ba (SHA256)

C2域

algew[.]me

aloqd[.]pw

bpee[.]pw

bvyv[.]club

bwuk[.]club

cgqy[.]us

cihr[.]site

ckwl[.]pw

cnmah[.]pw

coec[.]club

cuuo[.]us

daskd[.]me

dbxa[.]pw

dlex[.]pw

doof[.]pw

dtxf[.]pw

dvso[.]pw

dyiud[.]com

eady[.]club

enuv[.]club

eter[.]pw

fbjz[.]pw

fhyi[.]club

futh[.]pw

gjcu[.]pw

gjuc[.]pw

gnoa[.]pw

grij[.]us

gxhp[.]top

hvzr[.]info

idjb[.]us

ihrs[.]pw

jimw[.]club

jomp[.]site

jxhv[.]site

kjke[.]pw

kshv[.]site

kwoe[.]us

ldzp[.]pw

lhlv[.]club

lnoy[.]site

lvrm[.]pw

lvxf[.]pw

mewt[.]us

mfka[.]pw

mjet[.]pw

mjut[.]pw

mvze[.]pw

mxfg[.]pw

nroq[.]pw

nwrr[.]pw

nxpu[.]site

oaax[.]site

odwf[.]pw

odyr[.]us

okiq[.]pw

oknz[.]club

ooep[.]pw

ooyh[.]us

otzd[.]pw

oxrp[.]info

oyaw[.]club

pafk[.]us

palj[.]us

pbbk[.]us

ppdx[.]pw

pvze[.]club

qefg[.]info

qlpa[.]club

qznm[.]pw

reld[.]info

rnkj[.]pw

rzzc[.]pw

sgvt[.]pw

soru[.]pw

swio[.]pw

tijm[.]pw

tsrs[.]pw

turp[.]pw

ueox[.]club

ufyb[.]club

utca[.]site

vdfe[.]site

vjro[.]club

vkpo[.]us

vpua[.]pw

vqba[.]info

vwcq[.]us

vxqt[.]us

vxwy[.]pw

wfsv[.]us

wqiy[.]info

wvzu[.]pw

xhqd[.]pw

yamd[.]pw

yedq[.]pw

yqox[.]pw

ysxy[.]pw

zcnt[.]pw

zdqp[.]pw

zjav[.]us

zjvz[.]pw

zmyo[.]club

zody[.]pw

zugh[.]us

cspg[.]pw