首页 > 安全 > 网络安全 > 正文
针对利用DNS的TXT记录查询进行通信绕过杀软检测的木马分析
2017-03-21 09:36:00       个评论      
收藏    我要投稿

针对利用DNS的TXT记录查询进行通信绕过杀软检测的木马分析。域名系统(DNS)是企业网络上最常用的Internet应用协议之一。它负责提供名称解析,以便可以通过名称访问网络资源,而不是要求用户记住IP地址。虽然许多组织进行严格的出口过滤,但是因为其涉及web流量,防火墙规则等,许多组织没有严格的控制能防止基于DNS的威胁。攻击者已经认识到这一点,并且通常在DNS内封装不同的网络协议以逃避安全设备的检测。

通常,DNS的使用与信息泄漏相关。Talos最近分析了一个有趣的恶意软件样本,该样本利用DNS的TXT记录查询和响应创建了一个双向命令和控制(C2)通道。这允许攻击者使用DNS通信提交要在受感染的计算机上运行的新命令,并将命令执行的结果返回给攻击者。这是一种非常罕见和逃避的管理RAT的方式。使用Powershell的多个阶段,其中各个阶段是完全无文件的,表示攻击者采取了有效措施来规避检测。

讽刺的是,在我们发布了思科保护伞(一款特别设计的安防产品,专门用来保护组织免受DNS和基于Web的威胁)后不久,被称为Sourcefire的恶意软件作者放出了自身的恶意代码。

细节

最初引起我们对这个特定恶意软件样本感兴趣的是安全研究员在Twitter上发布的一个推文(感谢simpo!)是关于他正在分析的Powershell脚本,该脚本包含经过base64编码的字符串“SourceFireSux”。有趣的是,Sourcefire是Powershell脚本中唯一直接引用的安全供应商。我们搜索了在推文中引用的base64编码值“UwBvAHUAcgBjAGUARgBpAHIAZQBTAHUAeAA =”,就能找到已上传到公共恶意软件分析沙箱(混合分析)的样本。此外,当我们搜索解码的字符串值时,我们发现了一个指向Pastebin 页面的搜索引擎结果。在Pastebin列出的哈希值引导我们找到一个恶意的Word文档,也被上传到一个公共沙箱。Word文档启动了和我们先前发现的混合分析报告中的文件相同的多阶段感染过程,并允许我们重建更完整的感染过程。分析我们的监控数据,最终能够找出其他的样本,列在本帖的“危害指示”部分。

作为安全供应商,我们知道自己正在做一些正确的事情,因为恶意软件作者开始在恶意软件中专门引用到我们。当然,我们便决定仔细看看这个特别的样本。

\

在这种特殊情况下,我们开始分析错以VBScript文件名提交到公共沙箱的Powershell文件,我们先将其称为“阶段3”。原来,之前引用的字符串是用作互斥体,您可以在下面的图1中的去混淆Powershell中看到。

\

图1:Mutex创建

阶段1:恶意Word文档

如前所述,我们确定了此感染链的来源,这是通过钓鱼电子邮件传递给受害者的恶意微软Word文档。有趣的是,Word文档被看起来好像与一个由McAfee保护的安全电子邮件服务相关联。这可能是增加受害者打开文件和启用宏的可能性的有效方法,因为McAfee是一个著名的安全供应商,可能立即被受害者所信任。该文档通知用户它是安全的,并引导用户启用该内容。

\

图2:恶意Word文档

该文档使用Document_Open()函数调用另一个VBA函数。被调用函数设置了一个定义Powershell命令的长字符串,包含了要执行的代码。然后使用Windows管理界面(WMI)Win32_Process对象的Create方法执行该命令。

通过命令行传递到Powershell的代码大多数使用Base64编码和gzip压缩,其中尾部的一小部分未编码,是为了用于解包代码并将其传递给Invoke-Expression Powershell cmdlet( IEX)执行。这允许代码执行起来,而不需要将其写入受感染系统的文件系统。总的来说,这是我们看到在野外传播的非常典型的恶意Word文档。我们注意到,虽然有一个VBA流引用了从Pastebin的下载功能,但是我们分析的样本似乎没有使用这个功能。

我们还观察到这个特定样本的杀软检出率相当低(6/54),并且ClamAV能够成功检测这个特殊样本。

\

图3:VirusTotal结果

阶段2 Powershell

执行通过阶段1 Word文档传递给IEX的Powershell是我们开始观察在受感染系统上发生的几个有趣活动的地方。在阶段1中描述的Powershell脚本结尾处的函数,定义了阶段2的操作以及与阶段3相关的特性。阶段2中的代码已经被混淆处理,并且我们将引用此阶段使用的主函数‘pre_logic’而阶段3使用的主函数被引用为“logic”。

在这个阶段中存在的'pre_logic'函数支持两个开关参数。一个用于确定在目标系统上的感染过程是否能持久到下一阶段。如果可以持久,则另一个参数定义阶段3代码是否应该立即执行。

\

图4:反混淆后的“pre-logic”函数

除了这两个开关,'pre_logic'函数还支持四个参数,它们随后在感染过程的下一阶段传递到“Logic”函数。这些参数用于确定在感染进程的下一阶段发送DNS TXT记录查询时要使用的子域。

然后,该函数从Powershell脚本里的base64编码blob解包将在下一个阶段(阶段3)用到的Powershell脚本。它还定义了稍后将要使用的一些代码,包括在执行感染的下一阶段时使用的函数调用和参数。

如果在调用'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 \”

\

图5:注册表活动

然后,脚本将确定受感染系统上使用的Powershell版本。如果受感染的系统使用Powershell 3.0或更高版本,则已解码的阶段3的有效内容将写入位于“%PROGRAMDATA%\ Windows \”且名为“kernel32.dll”的备用数据流(ADS)。

如果系统运行较早版本的Powershell,则阶段3有效载荷被编码并写入注册表位置,该位置由早期的键名为“kernel32”的$ reg_win_path分配。用于解包和执行阶段3有效载荷的代码随后也被写入到键名称为“Part”的$ reg_win_path的注册表位置。

\

图6:powershell版本检查与持续性

一旦上述工作完成,脚本将再次检查以确定运行恶意软件的用户访问权限级别。如果恶意软件已使用管理员权限执行,则“_eventFilter”,“CommandLineEventConsumer”和“_filtertoconsumerbinding”的WMI事件服务将从受感染的系统中删除。然后,恶意软件会建立自己的永久WMI事件服务,过滤“Win32_LogonSession”事件,并绑定到“CommandLineEventConsumer”。这是每当在受感染的系统上创建一个新的登录会话时用于读取和执行先前存储在ADS中的第3阶段有效载荷。从持久性角度看本质上这是基于注册表运行键的WMI等效项。第3阶段恶意软件默认设置为在30分钟后运行“onidle”。如果与阶段3的执行相关联的开关在该阶段开始时被传递到“pre_logic”函数,则阶段3的有效载荷将立即被执行。

\

图7:持久机制

如上所述,恶意软件还在名为“kernel32”的受感染系统上创建计划任务,该计划任务与存储在ADS或注册表中的阶段3有效载荷相关联,具体取决于受感染系统上运行的powershell的版本。在分析与此活动相关的其他样本时,我们观察到计划任务可能会随样本而变化。

点击复制链接 与好友分享!回本站首页
上一篇:浅析Kerberos 约束委派SPN的安全漏洞
下一篇:Python如何防止sql注入
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做实用的IT技术学习网站