一、事件概要

image.png

二、事件描述

近日,深信服威胁情报检测到有攻击者通过投递Tellyouthepass勒索病毒对企业实施攻击,攻击活动导致Tellyouthepass勒索病毒事件呈上升趋势,多家企事业单位受到影响。

本次Tellyouthepass勒索病毒主要通过某OA系统框架的Log4j2漏洞以及某企业管理软件反序列化漏洞进行入侵攻击,在5月7日-9日持续发起批量攻击。

Tellyouthepass勒索病毒最早出现于2020年7月,因其使用RSA+AES的方式对受害服务器文件进行加密,目前该勒索家族暂无公开的解密工具,加密后数据无法直接解密,用户将面临高额的勒索赎金和业务影响,建议政企单位尽早做好相关的加固防护措施。

Windows平台勒索内容:

Linux平台勒索内容:

加密后的文件如下,会修改文件后缀为.locked

三、情报分析

本次Tellyouthepass勒索病毒主要利用某OA系统框架的Log4j2漏洞以及某企业管理软件反序列化漏洞进行入侵攻击,在5月7日-9日持续发起批量攻击,通过远程执行命令下载执行勒索病毒。该勒索病毒家族通常通过漏洞利用批量扫描进行攻击,受影响较大的是存在漏洞且对外网映射的服务器,暂不具有内网自动横向的功能。

Log4j2

早在2020年12月威胁情报就监控到Tellyouthepass团伙将Apache Log4j2远程代码执行高危漏洞武器化,用于进行批量攻击。本次攻击特征如下:

某企业管理软件反序列化漏洞

在深信服安全团队的溯源中发现,勒索的入侵路径中包括某系统平台反序列化漏洞。排查入侵痕迹时,在Web访问日志中会记录访问“ServiceDispatcherServlet”接口的日志。

另外/nclogs/server目录下对应加密时间的日志文件中会包含C2地址

如果上述Web日志均被加密,可查看主机对应加密时间的应用程序日志,筛选事件ID为1040日志,可看到C2地址记录。


四、解决方案

处置建议

值得注意的是,该勒索不会删除卷影副本和清空回收站,中招该勒索的主机可从卷影副本中还原系统。

该勒索目前使用的传播手段为利用log4j2漏洞进行传播,针对比较多的框架为某OA框架,相关补丁链接如下。

https://service.seeyon.com/patchtools/tp.html#/patchList?type=%E5%AE%89%E5%85%A8%E8%A1%A5%E4%B8%81&id=94

解决方案如下:

Log4j2建议受影响的用户及时更新升级到最新版本。链接如下:

https://github.com/apache/logging-log4j2/tags

一、事件概要

image.png

二、事件描述

近日,深信服威胁情报检测到有攻击者通过投递Tellyouthepass勒索病毒对企业实施攻击,攻击活动导致Tellyouthepass勒索病毒事件呈上升趋势,多家企事业单位受到影响。

本次Tellyouthepass勒索病毒主要通过某OA系统框架的Log4j2漏洞以及某企业管理软件反序列化漏洞进行入侵攻击,在5月7日-9日持续发起批量攻击。

Tellyouthepass勒索病毒最早出现于2020年7月,因其使用RSA+AES的方式对受害服务器文件进行加密,目前该勒索家族暂无公开的解密工具,加密后数据无法直接解密,用户将面临高额的勒索赎金和业务影响,建议政企单位尽早做好相关的加固防护措施。

Windows平台勒索内容:

Linux平台勒索内容:

加密后的文件如下,会修改文件后缀为.locked

三、情报分析

本次Tellyouthepass勒索病毒主要利用某OA系统框架的Log4j2漏洞以及某企业管理软件反序列化漏洞进行入侵攻击,在5月7日-9日持续发起批量攻击,通过远程执行命令下载执行勒索病毒。该勒索病毒家族通常通过漏洞利用批量扫描进行攻击,受影响较大的是存在漏洞且对外网映射的服务器,暂不具有内网自动横向的功能。

Log4j2

早在2020年12月威胁情报就监控到Tellyouthepass团伙将Apache Log4j2远程代码执行高危漏洞武器化,用于进行批量攻击。本次攻击特征如下:

某企业管理软件反序列化漏洞

在深信服安全团队的溯源中发现,勒索的入侵路径中包括某系统平台反序列化漏洞。排查入侵痕迹时,在Web访问日志中会记录访问“ServiceDispatcherServlet”接口的日志。

另外/nclogs/server目录下对应加密时间的日志文件中会包含C2地址

如果上述Web日志均被加密,可查看主机对应加密时间的应用程序日志,筛选事件ID为1040日志,可看到C2地址记录。


四、解决方案

处置建议

值得注意的是,该勒索不会删除卷影副本和清空回收站,中招该勒索的主机可从卷影副本中还原系统。

该勒索目前使用的传播手段为利用log4j2漏洞进行传播,针对比较多的框架为某OA框架,相关补丁链接如下。

https://service.seeyon.com/patchtools/tp.html#/patchList?type=%E5%AE%89%E5%85%A8%E8%A1%A5%E4%B8%81&id=94

解决方案如下:

Log4j2建议受影响的用户及时更新升级到最新版本。链接如下:

https://github.com/apache/logging-log4j2/tags

序言

从西方APT组织的攻击历史及已经泄露的网络攻击武器来看,高隐藏、高持久化(Low&Slow)是已经成为区分威胁等级的关键特征,而Rookit则是达成此目的重要的技术手段之一。

在之前的文章中,“序章:悬顶的达摩克利斯之剑”,带我们领略了Rootkit的前世今生,隐匿于Rootkit背后的影子以及针对Rootkit的基本检测思想。“Windows平台高隐匿、高持久化威胁”和“Linux平台高隐匿、高持久化威胁”各自从宏观角度讲述Windows平台和linux平台下,Rootkit技术原理、应用和发展现状以及攻防角度的总结。“Rootkit检测技术发展现状”让我们见识到了防御方对抗Rootkit的技术。

本文则是在“Windows平台高隐匿、高持久化威胁”的基础上,结合攻击者在攻击中利用到的技术手段,对Windows平台上的rootkit的运行效果及应用方面进行介绍。

Rootkit威胁情报-战火从未停止

2015年4月,安全研究团队发表了关于Turla组织的Rootkit分析报告。2016年8月,安全研究团队发布了索伦之眼(ProjectSauron)相关的技术细节。2018年10月,安全研究人员披露有驱动护体的挖矿病毒ProtectionX。2019年4月,安全研究团队发布关于跨平台间谍Rootkit Scranos的文章。2021年10月,安全研究团队披露了DirtyMoe Rootkit 驱动程序。2021年12月,安全研究团队披露了方程式组织(Equation Group)的攻击框架DanderSpritz。2022年1月,安全研究团队披露了紫狐(Purple Fox)僵尸网络通过伪装Telegram安装程序释放Rootkit的攻击事件。

紫狐-黑产中Rootkit技术应用的代表

紫狐是已经持续多年的、以营利为目的的网络黑产组织,他们历来每次出现在视野中,都会变化一种攻击方式或技术。攻击者控制大量受害终端,通过刷量、推广用户不需要的软件来获利,这会拖慢设备性能,严重影响受害者的正常使用。其恶意程序使用了Rootkit技术,以至于具有很高的隐蔽性,很难被受害者发掘和清除。

在紫狐病毒释放器下载最终Purple Fox Rootkit载荷之前,我们注意到释放程序会安装一个名为“Driver.sys”的驱动程序,用于注销名为“360FsFlt”的Minifilter,并关闭名为“ZhuDongFangYu.exe”的进程,来规避安全软件检测。“ZhuDongFangYu.exe”的进程是从驱动启动的,用常规手段是无法关闭的。

驱动服务运行后,通过一个独立的命令行工具进行调用,通过I\O 通讯传递指令,具有四种命令,对应四种功能。

实际运行效果如下:

关闭指定文件过滤器

拷贝文件

删除文件

结束进程

在分析过程中我们发现,该驱动程序为了避免被检测,在文件拷贝和删除文件的过程中没有使用常规的API函数,而是通过IofCallDriver函数向文件设备发送带有操作的IRP数据,以此达到文件操作的目的。

而在关闭进程功能上,更是提供了两种结束进程的方法,来规避检测。而且我们发现,该驱动目前仍是半成品的状态,也就是说,攻击者仍在进行功能的迭代升级。在完成安全软件进程关闭后,释放文件才会继续下载最后的Purple Fox Rootkit,经分析,该Rookit是基于开源Rookit项目“Hidden”修改,具有隐藏注册表项和值、隐藏文件和目录、隐藏进程、保护指定进程等功能。

文件隐藏运行效果:

注册表隐藏运行效果:

进程保护运行效果:

由此可见,学习开源项目也是攻击者提升攻击能力的有效方式,他们也在不断吸取新的技术,应用与攻击活动之中。

APT组织的高对抗利器

Turla组织最早可以追溯到2004年,已经超过45个国家受到相关攻击,涉及政府、大使馆、军事、教育、研究和制药公司等多个行业。其攻击使用的技战术一直都有着较高的技术水平,对于国家和行业机密有着极大的威胁。

本事件中使用的Rootkit主要功能是通过HOOK一系列系统调用函数,隐藏和保护其用户态组件。然后通过修改Ntoskrnl.exe和Ndis.sys的内存数据,在0xc3处创建一个新的IDT条目并重定向所有的被HOOK的函数到一个简单的中断句柄(ISR),每个被HOOK的函数都有一个唯一的标识符与ISR中的派遣函数相对应。

由于能够该方法能够禁用任何主机内的HOOK机制,因此传统的针对Rookit的监测能力都受到了限制。

Turla rootkit还使用了两个虚拟文件系统,一个NTFS文件系统和一个FAT文件系统,也就是说,受害者主机上有一个承载了文件系统的加密文件,攻击者将其作为工作空间使用。

这里突出了Turla组织攻击活动所使用的工具非常具有高对抗性,能够做到从系统层面避免安全软件的检测和查杀。除了Rootkit部分,还有一点值得注意,Turla在攻击过程中会使用一个名为“VBoxDrv.sys”的驱动程序,该驱动程序存在CVE-2008-3431漏洞,攻击者能够利用该漏洞完成权限提升。

这里就要说到一个概念“VulnDriver”,也就是带有漏洞的驱动程序,比较常见的VulnDriver还有GDRV.sys (CVE-2018-19320),Novell (CVE-2013-3956), CPU-Z (CVE-2017-15302), ASUS (CVE-2018-18537)。挖矿木马常用的矿机所使用的WinRing0.sys也是一个非常常见的VulnDriver,这个驱动是一个名为NZXT CAM的计算机硬件性能监控产品内的一个便于程序访问Windows内核的组件。这个看起来不大的驱动程序上存在着多达11个CVE漏洞,其中CVE-2020-13516可以越权直接从USB和PCI设备查询信息;CVE-2020-13515可以越权将数据写入I/O总线,可能会更改PCI配置信息或特定于供应商的数据寄存器,帮助其他程序完成提权;CVE-2020-13518可以越权直接访问rdmsr,任意读取MSR内数据;CVE-2020-13519可以越权直接访问writemsr,向MSR内写入数据。

因此,利用这个驱动程序做很多事情,其利用成本低,很受以营利为目的网络攻击者欢迎。

在前段时间Log4j 曝出存在RCE漏洞的时候,该漏洞被大量的黑产攻击者利用,这个驱动程序也连带着出现在了大众的视野之中。

这些VulnDriver带着官方的签名,而且本身没有什么恶意行为,因此很多安全厂商都不会告警。

在不久前被曝光的方程式组织的后渗透框架DanderSpritz中,也存在VulnDriver的利用,在其名为DoubleFeature的插件中,存在名为hidsvc.sys的驱动程序,该驱动程序存在 CVE-2017-0005 漏洞,能够让攻击者通过用户层代码指定名称和参数来调用内核功能。

说到这,我们来简单了解一些方程式这个组织吧。

方程式组织被称为世界上最尖端的网络攻击组织之一,和恶名昭彰的震网(Stuxnet)和火焰(Flame)有着很深的联系。

震网是一个全球性质的工业病毒,是世界上首个网络“超级破坏性武器”,曾被用来攻击伊朗核设施,手法极其阴险。同时,我国的工业设施也受到了一定的影响。

因此他们的存在,是国家机密和关键基础设施巨大的威胁。

在这次被曝光的项目中存在一个远程访问工具,其下有一个名为MSNDSRV.sys的驱动程序。

该驱动程序曾在2015年的EquationDrug 组件中被提到,可以隐藏用户侧组件,另外可以在注册表遍历所有网卡,调用NdisRegisterProtocol函数注册一个NDIS流量监听器,可以接收到受害主机所有流量,实现通讯流量监控。

在两个庞大的项目中,这个驱动程序显得微不足道,和之前提到的Rootkit程序相比,方程式组织的Rootkit技术没有核心组件的地位,只是整个项目下某一个插件下的一个组件,是一个“随取随用”的地位。

但就是这样一个看起来不值一提的组件,在两个程序中都出现了。

足以说明,Rookit是方程式组织在攻击组件开发的过程中非常常用的技术,而对于这类常用的组件,攻击者也不会花太多心思进行二次开发。

然而就算是这样,安全厂商仍旧鲜有捕获到方程式组织的活动痕迹,该组织的高隐匿技术之强,可想而知。

检测——这是一场与攻击者的军备竞赛

业界对反Rootkit软件使用的技术进行了分类。签名的检测(Signature-based detection)、文件完整性监测(File integrity monitoring)、Rootkit Hook检测(Rootkit hooking detection)、交叉视图分析(Cross-view analysis)以及基于网络的检测(Network-based detection)。

基于签名的检测就是匹配rootkit软件字节特征,缺点是无法匹配新的rootkit,而且特征容易更改,对于已安装rootkit的系统再实施检测不理想。

文件完整性监测,该方法计算关键的、不变的操作系统文件的哈希,并将其与存储在数据库中的已知值进行比较。这项技术对于在磁盘上修改系统二进制文件的rootkit很有效,但rootkit的作者很快使用hooking或DKOM技术,以此篡改执行结果,使得检测效果不理想。

Rootkit Hook检测,SSDT、IAT和IDT都有一组用于每个服务或中断的函数指针,它们都在内存中的特定范围内。当rootkit修改Hook指向恶意服务或中断例程时,函数指针所指向的位置几乎总是位于特定内存地址范围之外。在这期间还发展了Inline Hook形式,来规避这些关键表的检测,后来发展了FSD Hook、FSD Inline Hook。

交叉视图分析,交叉视图分析涉及从“用户”或“API”视图查看系统,并将其与低级视图进行比较,交叉视图方法可以检测基于DKOM和系统例程补丁的Rootkit,不能检测基于HOOK的Rootkit。

基于网络的检测,理论上,rootkit可能会试图隐藏其网络通信,以逃避操作系统或用户的检测,但是从系统外部还是能看到流量的,这方面成了C2隐藏通信和网络检测的较量。

Windows也引进了一些防御技术,PatchGuard和DSE。PatchGuard用于内核完整性检测,守护容易被HOOK的地方。DSE用于检测驱动签名,限制未签名驱动加载。上文提到的Turla则绕过了这种限制,通过引入VulnDriver间接绕过。通过修改内存中的特殊变量就能关闭DSE功能,此时,加载第二个未签名的恶意驱动,直接HOOK PatchGuard告警的关键函数,在下一个内核完整性校验过程中不让异常表现出来,从而完成了PatchGuard功能的绕过。

总结

说了这么多,其实只想说明一个问题,那就是Rootkit技术一直都没有过时,它一直都是攻击者青睐的攻击技术。虽然他的热度被各式各样的新型网络威胁所掩盖,但在那些网络攻击的事件中,我们又常常能见到它的影子。

在我们忙于研究处理其他网络威胁技术的时候,它也在以某种的方式存在,并不断成长着。在安全厂商不断提升己方检测能力的同时,攻击者也在不断提升对抗能力,传统的检测方式不断的承受着一轮又一轮的攻击。

对于高对抗的Rookit技术的检测,对于传统的检测技术是一个很大的挑战,安全厂商还有很多的工作要去完成。

参考链接

1.https://decoded.avast.io/martinchlumecky/dirtymoe-rootkit-driver/

2.https://blog.talosintelligence.com/2020/12/vuln-spotlight-NZXT-CAM-.html

3.https://blog.minerva-labs.com/malicious-telegram-installer-drops-purple-fox-rootkit

4.https://www.lastline.com/labsblog/dissecting-turla-rootkit-malware-using-dynamic-analysis/

5.https://mp.weixin.qq.com/s/a1LgQqmkGFYYq7JQLQKmMQ

6.《Eset-Turla-Outlook-Backdoor》

7.https://securelist.com/operation-tunnelsnake-and-moriya-rootkit/101831/

8.https://unit42.paloaltonetworks.com/acidbox-rare-malware/

序言

从西方APT组织的攻击历史及已经泄露的网络攻击武器来看,高隐藏、高持久化(Low&Slow)是已经成为区分威胁等级的关键特征,而Rookit则是达成此目的重要的技术手段之一。

在之前的文章中,“序章:悬顶的达摩克利斯之剑”,带我们领略了Rootkit的前世今生,隐匿于Rootkit背后的影子以及针对Rootkit的基本检测思想。“Windows平台高隐匿、高持久化威胁”和“Linux平台高隐匿、高持久化威胁”各自从宏观角度讲述Windows平台和linux平台下,Rootkit技术原理、应用和发展现状以及攻防角度的总结。“Rootkit检测技术发展现状”让我们见识到了防御方对抗Rootkit的技术。

本文则是在“Windows平台高隐匿、高持久化威胁”的基础上,结合攻击者在攻击中利用到的技术手段,对Windows平台上的rootkit的运行效果及应用方面进行介绍。

Rootkit威胁情报-战火从未停止

2015年4月,安全研究团队发表了关于Turla组织的Rootkit分析报告。2016年8月,安全研究团队发布了索伦之眼(ProjectSauron)相关的技术细节。2018年10月,安全研究人员披露有驱动护体的挖矿病毒ProtectionX。2019年4月,安全研究团队发布关于跨平台间谍Rootkit Scranos的文章。2021年10月,安全研究团队披露了DirtyMoe Rootkit 驱动程序。2021年12月,安全研究团队披露了方程式组织(Equation Group)的攻击框架DanderSpritz。2022年1月,安全研究团队披露了紫狐(Purple Fox)僵尸网络通过伪装Telegram安装程序释放Rootkit的攻击事件。

紫狐-黑产中Rootkit技术应用的代表

紫狐是已经持续多年的、以营利为目的的网络黑产组织,他们历来每次出现在视野中,都会变化一种攻击方式或技术。攻击者控制大量受害终端,通过刷量、推广用户不需要的软件来获利,这会拖慢设备性能,严重影响受害者的正常使用。其恶意程序使用了Rootkit技术,以至于具有很高的隐蔽性,很难被受害者发掘和清除。

在紫狐病毒释放器下载最终Purple Fox Rootkit载荷之前,我们注意到释放程序会安装一个名为“Driver.sys”的驱动程序,用于注销名为“360FsFlt”的Minifilter,并关闭名为“ZhuDongFangYu.exe”的进程,来规避安全软件检测。“ZhuDongFangYu.exe”的进程是从驱动启动的,用常规手段是无法关闭的。

驱动服务运行后,通过一个独立的命令行工具进行调用,通过I\O 通讯传递指令,具有四种命令,对应四种功能。

实际运行效果如下:

关闭指定文件过滤器

拷贝文件

删除文件

结束进程

在分析过程中我们发现,该驱动程序为了避免被检测,在文件拷贝和删除文件的过程中没有使用常规的API函数,而是通过IofCallDriver函数向文件设备发送带有操作的IRP数据,以此达到文件操作的目的。

而在关闭进程功能上,更是提供了两种结束进程的方法,来规避检测。而且我们发现,该驱动目前仍是半成品的状态,也就是说,攻击者仍在进行功能的迭代升级。在完成安全软件进程关闭后,释放文件才会继续下载最后的Purple Fox Rootkit,经分析,该Rookit是基于开源Rookit项目“Hidden”修改,具有隐藏注册表项和值、隐藏文件和目录、隐藏进程、保护指定进程等功能。

文件隐藏运行效果:

注册表隐藏运行效果:

进程保护运行效果:

由此可见,学习开源项目也是攻击者提升攻击能力的有效方式,他们也在不断吸取新的技术,应用与攻击活动之中。

APT组织的高对抗利器

Turla组织最早可以追溯到2004年,已经超过45个国家受到相关攻击,涉及政府、大使馆、军事、教育、研究和制药公司等多个行业。其攻击使用的技战术一直都有着较高的技术水平,对于国家和行业机密有着极大的威胁。

本事件中使用的Rootkit主要功能是通过HOOK一系列系统调用函数,隐藏和保护其用户态组件。然后通过修改Ntoskrnl.exe和Ndis.sys的内存数据,在0xc3处创建一个新的IDT条目并重定向所有的被HOOK的函数到一个简单的中断句柄(ISR),每个被HOOK的函数都有一个唯一的标识符与ISR中的派遣函数相对应。

由于能够该方法能够禁用任何主机内的HOOK机制,因此传统的针对Rookit的监测能力都受到了限制。

Turla rootkit还使用了两个虚拟文件系统,一个NTFS文件系统和一个FAT文件系统,也就是说,受害者主机上有一个承载了文件系统的加密文件,攻击者将其作为工作空间使用。

这里突出了Turla组织攻击活动所使用的工具非常具有高对抗性,能够做到从系统层面避免安全软件的检测和查杀。除了Rootkit部分,还有一点值得注意,Turla在攻击过程中会使用一个名为“VBoxDrv.sys”的驱动程序,该驱动程序存在CVE-2008-3431漏洞,攻击者能够利用该漏洞完成权限提升。

这里就要说到一个概念“VulnDriver”,也就是带有漏洞的驱动程序,比较常见的VulnDriver还有GDRV.sys (CVE-2018-19320),Novell (CVE-2013-3956), CPU-Z (CVE-2017-15302), ASUS (CVE-2018-18537)。挖矿木马常用的矿机所使用的WinRing0.sys也是一个非常常见的VulnDriver,这个驱动是一个名为NZXT CAM的计算机硬件性能监控产品内的一个便于程序访问Windows内核的组件。这个看起来不大的驱动程序上存在着多达11个CVE漏洞,其中CVE-2020-13516可以越权直接从USB和PCI设备查询信息;CVE-2020-13515可以越权将数据写入I/O总线,可能会更改PCI配置信息或特定于供应商的数据寄存器,帮助其他程序完成提权;CVE-2020-13518可以越权直接访问rdmsr,任意读取MSR内数据;CVE-2020-13519可以越权直接访问writemsr,向MSR内写入数据。

因此,利用这个驱动程序做很多事情,其利用成本低,很受以营利为目的网络攻击者欢迎。

在前段时间Log4j 曝出存在RCE漏洞的时候,该漏洞被大量的黑产攻击者利用,这个驱动程序也连带着出现在了大众的视野之中。

这些VulnDriver带着官方的签名,而且本身没有什么恶意行为,因此很多安全厂商都不会告警。

在不久前被曝光的方程式组织的后渗透框架DanderSpritz中,也存在VulnDriver的利用,在其名为DoubleFeature的插件中,存在名为hidsvc.sys的驱动程序,该驱动程序存在 CVE-2017-0005 漏洞,能够让攻击者通过用户层代码指定名称和参数来调用内核功能。

说到这,我们来简单了解一些方程式这个组织吧。

方程式组织被称为世界上最尖端的网络攻击组织之一,和恶名昭彰的震网(Stuxnet)和火焰(Flame)有着很深的联系。

震网是一个全球性质的工业病毒,是世界上首个网络“超级破坏性武器”,曾被用来攻击伊朗核设施,手法极其阴险。同时,我国的工业设施也受到了一定的影响。

因此他们的存在,是国家机密和关键基础设施巨大的威胁。

在这次被曝光的项目中存在一个远程访问工具,其下有一个名为MSNDSRV.sys的驱动程序。

该驱动程序曾在2015年的EquationDrug 组件中被提到,可以隐藏用户侧组件,另外可以在注册表遍历所有网卡,调用NdisRegisterProtocol函数注册一个NDIS流量监听器,可以接收到受害主机所有流量,实现通讯流量监控。

在两个庞大的项目中,这个驱动程序显得微不足道,和之前提到的Rootkit程序相比,方程式组织的Rootkit技术没有核心组件的地位,只是整个项目下某一个插件下的一个组件,是一个“随取随用”的地位。

但就是这样一个看起来不值一提的组件,在两个程序中都出现了。

足以说明,Rookit是方程式组织在攻击组件开发的过程中非常常用的技术,而对于这类常用的组件,攻击者也不会花太多心思进行二次开发。

然而就算是这样,安全厂商仍旧鲜有捕获到方程式组织的活动痕迹,该组织的高隐匿技术之强,可想而知。

检测——这是一场与攻击者的军备竞赛

业界对反Rootkit软件使用的技术进行了分类。签名的检测(Signature-based detection)、文件完整性监测(File integrity monitoring)、Rootkit Hook检测(Rootkit hooking detection)、交叉视图分析(Cross-view analysis)以及基于网络的检测(Network-based detection)。

基于签名的检测就是匹配rootkit软件字节特征,缺点是无法匹配新的rootkit,而且特征容易更改,对于已安装rootkit的系统再实施检测不理想。

文件完整性监测,该方法计算关键的、不变的操作系统文件的哈希,并将其与存储在数据库中的已知值进行比较。这项技术对于在磁盘上修改系统二进制文件的rootkit很有效,但rootkit的作者很快使用hooking或DKOM技术,以此篡改执行结果,使得检测效果不理想。

Rootkit Hook检测,SSDT、IAT和IDT都有一组用于每个服务或中断的函数指针,它们都在内存中的特定范围内。当rootkit修改Hook指向恶意服务或中断例程时,函数指针所指向的位置几乎总是位于特定内存地址范围之外。在这期间还发展了Inline Hook形式,来规避这些关键表的检测,后来发展了FSD Hook、FSD Inline Hook。

交叉视图分析,交叉视图分析涉及从“用户”或“API”视图查看系统,并将其与低级视图进行比较,交叉视图方法可以检测基于DKOM和系统例程补丁的Rootkit,不能检测基于HOOK的Rootkit。

基于网络的检测,理论上,rootkit可能会试图隐藏其网络通信,以逃避操作系统或用户的检测,但是从系统外部还是能看到流量的,这方面成了C2隐藏通信和网络检测的较量。

Windows也引进了一些防御技术,PatchGuard和DSE。PatchGuard用于内核完整性检测,守护容易被HOOK的地方。DSE用于检测驱动签名,限制未签名驱动加载。上文提到的Turla则绕过了这种限制,通过引入VulnDriver间接绕过。通过修改内存中的特殊变量就能关闭DSE功能,此时,加载第二个未签名的恶意驱动,直接HOOK PatchGuard告警的关键函数,在下一个内核完整性校验过程中不让异常表现出来,从而完成了PatchGuard功能的绕过。

总结

说了这么多,其实只想说明一个问题,那就是Rootkit技术一直都没有过时,它一直都是攻击者青睐的攻击技术。虽然他的热度被各式各样的新型网络威胁所掩盖,但在那些网络攻击的事件中,我们又常常能见到它的影子。

在我们忙于研究处理其他网络威胁技术的时候,它也在以某种的方式存在,并不断成长着。在安全厂商不断提升己方检测能力的同时,攻击者也在不断提升对抗能力,传统的检测方式不断的承受着一轮又一轮的攻击。

对于高对抗的Rookit技术的检测,对于传统的检测技术是一个很大的挑战,安全厂商还有很多的工作要去完成。

参考链接

1.https://decoded.avast.io/martinchlumecky/dirtymoe-rootkit-driver/

2.https://blog.talosintelligence.com/2020/12/vuln-spotlight-NZXT-CAM-.html

3.https://blog.minerva-labs.com/malicious-telegram-installer-drops-purple-fox-rootkit

4.https://www.lastline.com/labsblog/dissecting-turla-rootkit-malware-using-dynamic-analysis/

5.https://mp.weixin.qq.com/s/a1LgQqmkGFYYq7JQLQKmMQ

6.《Eset-Turla-Outlook-Backdoor》

7.https://securelist.com/operation-tunnelsnake-and-moriya-rootkit/101831/

8.https://unit42.paloaltonetworks.com/acidbox-rare-malware/

摘要

Rootkit 这一概念最早出现于上个世纪九十年代初期,CERT Coordination Center(CERT/CC) 于1994年在 CA-1994-01 这篇安全咨询报告中使用了 Rootkit 这个词汇。在这之后 Rootkit 技术发展迅速,这种快速发展的态势在 2000 年达到了顶峰。2000年后,Rootkit 技术的发展也进入了低潮期,但是对于 Rootkit 技术的研究却并未停滞。在 APT 攻击日益流行的趋势下,Rootkit 攻击和检测技术也同样会迎来新的发展高潮。

在往期的Rootkit系列文章里面,我们分别介绍了 Rootkit 技术的发展历程WindowsLinux平台下的 Rootkit 攻击技术。本期 Rootkit 系列文章将会给大家介绍当前主流的 Rootkit 防御技术以及一些非常规 Rootkit 的可实施检测方案。

被滥用的Rootkit技术

长期以来,Rootkit 检测一直是一个非常大的痛点,这些具有高度定制化的恶意程序集合隐藏在服务器上,以高权限访问计算机和网络。虽然 Rootkit 并没有成为大新闻中的主角,但是它们一直都过得很安逸,并且持续性的造成损害。对于安全从业者而言,这不应该是一个被忽视的地方。

APT 通常和 Rootkit 齐头并进。从西方 APT 组织的攻击历史及已经泄露的网络武器看,高隐匿、高持久化(Low&Slow)是其关键特征,而 Rootkit 则是达成此目的的重要技术之一,因此 Rootkit 一直以来和 APT 配合的很好。

让人遗憾的是,几乎任何脚本小子都可以轻易在被攻击成功的目标主机上植入 Rootkit。比起这个,更让人痛心的是,一些挖矿木马和广告木马都开始使用 Rootkit 技术了,黑产都卷成这个样子了吗?H2Miner 挖矿家族开始使用新的 Rootkit 样本,该Rootkit 使用 LD_PRELOAD 技术劫持动态链接过程。LD_PRELOAD 是一个非常古老的C 库技巧,但它今天仍然被成功使用和滥用。

当前主流Rookit检测技术分析

当前主要的 Rootkit 检测的方法包括但不限于以下几种类型。

1.基于 Rootkit 运行的效果进行检测

如: 发现隐藏的端口、进程、内核模块、网络连接、被篡改的内核代码。

缺陷: 该检测方案对预设的检测场景的依赖程度较高,一旦恶意软件出现检测场景之外的行为,则难以做到有效检测。

2.静态文件特征检测

例如: 扫描磁盘上的文件,将文件与特征库进行匹配,通过该方式检测可能存在的Rootkit。

缺陷: 该检测方案对特征库依赖程度较高,能够有效发现已知特征的 Rootkit,难以发现未知特征的 Rootkit。

3. 动态行为分析检测

例如: 对系统运行过程中的行为进行审计,通过行为规则匹配的方式发现系统中的异常行为,通过该方式发现可能存在的 Rootkit。

缺陷: 对行为规则的依赖程度较高,只能匹配已知行为特征的 Rootkit,难以匹配未知行为特征的 Rootkit。

4.数据完整性检测

例如: 对系统关键的数据结构进行监控,通过监控关键数据结构的异常篡改,以发现系统中的恶意行为。

缺陷: 完整性检测依赖于受信任的源数据,如果源数据被篡改或者不可信的情况下,则完整性检测也很难奏效。

当前的开源社区的 Rootkit 检测技术主要以 Rootkit 运行效果检测和静态文件特征检测为主,动态行为分析和数据完整性保护的 Rootkit 检测项目相对较少。

当前主流Rookit检测项目分析

Chkrootkit: 检测 /proc/kallsyms 的内容并匹配相对应的文件名和目录来检测是否存在Rootkit,通过该方式,chkrootkit 能够在一定程度上发现 Rootkit 执行的恶意行为,诸如文件隐藏,网络连接隐藏,进程信息隐藏。但是该检测方案对 Rootkit 指纹库依赖度较高,并且严重依赖于 /proc/ 目录下的文件,一旦该文件不可信任,则很容易被绕过。

Rkhunter: 这个 Rootkit 检测工具会扫描相应的文件目录、文件、符号表,通过该方式检测是否存在 Rootkit 恶意家族。同样的,该检测方案对特征库的依赖度较高,且难以发现指纹没有覆盖到的 Rootkit。

Kjackal: 该 Rootkit 检测工具通过遍历内核中的系统调用表 syscall_table,注意检查例程的入口是否存在内核空间,如果不存在,就意味着发生了 syscall 劫持。发现了存在syscall_table 的劫持之后,该工具会进行反向追踪,以确定劫持系统调用的是哪一个恶意LKM模块。Kjackal 会枚举 /proc/net/tcp 的读写句柄是否存在于内核态中,如果不存在,则发生了劫持。该工具还会枚举 modules kset 以检测隐藏的内核模块。该检测方案也同样存在被绕过的可能性,一旦 Rootkit 通过删除 kobject 数据结构的方式隐藏Rootkit,那么这将很难检测,不过这种删除 kobject 数据结构的方式也同样会影响 Rootkit 正常使用。

Tyton: 该项目检测 Rootkit 的方式和 kjackal 非常相似,通过枚举内核空间的module_list,中断向量表、网络连接读写句柄、系统调用表、netfilter hook 等方式发现可能存在的Rootkit,发现Rootkit之后,通过 get_module_from_addr 函数反向溯源恶意的内核模块。

Elkeid: 该项目是字节跳动的一个开源的 HIDS 项目,该 hids 检测 Rootkit 的方式继承自 tyton 的检测方案。除了这个之外,elkeid 还在行为检测方面做出了突破,使用kprobe对关键的系统调用进行 hook,持续监控系统运行过程中的进程行为,网络行为、文件行为等相关信息并保存到日志中,再使用字节跳动于近期开源的 Hlkeid Hub的行为日志检测引擎和规则集,能够对系统运行过程中的日志进行自动化分析,以发现可能存在的未知威胁。不得不说这是一个非常勇敢的突破,业界普遍都对 kprobe 持保留态度,敢于直接上车的并不多见。不过这种日志采集方式也存在一个缺陷,一旦攻击者控制了 /sys/kernel/debug/kprobes/enabled 文件,就可以使这种日志采集功能失效。再补充一句,该项目更新频率较高,并且社区支持非常友好。

stmichael-lkm:该项目能够为内核提供一定的完整性保护,能够在一定程度上发现针对内核的篡改,通过这种方式发现可能存在的 Rootkit。一旦检测到 Rootkit 篡改内核,StMichael 尝试通过将所做的更改回滚到先前已知的良好状态来恢复内核的完整性。不得不说这是一个非常大胆的尝试,比使用 kprobe 更加激进,这种方案的致命缺陷就是很容易为系统引入未知的问题,导致系统的不稳定。

Qiling: 该项目是一个高级二进制仿真框架,能够模拟多平台,多架构的运行环境,通过类似于沙箱的环境运行 Rootkit,并且记录 Rootkit 运行过程中的行为。这为恶意Rootkit 的检测和分析提供了一种全新的思路。传统沙箱对恶意软件的检测很难达到这种细粒度的监控效果。

非常规Rookit以及检测方案

1. 使用了命名空间技术的 HorsePILL

在讲述该 Rootkit 之前,有必要简单介绍一下命名空间的含义。命名空间是Linux的一个非常重要的系统特性,Linux 的命名空间机制提供了一种资源隔离的解决方案。PID,IPC,Network 等系统资源不再是全局性的,而是属于特定的Namespace,不同命名空间的资源是互相隔离的,在一个命名空间所做的事情不会影响另一个命名空间。各命名空间在 Linux 的引入版本如下:


由于命名空间的隔离特性,这给恶意文件的隐藏提供了新的思路。将恶意文件和恶意文件运行过程中的进程、网络置于一个与系统不同命名空间的环境中,可以非常有效的隐藏自身,在一定程度上来说,难以发现。

HorsePILL 这个 Rootkit 就利用了这种命名空间的特性,该 Rootkit 会感染系统的initramfs,被感染的系统在启动过程中加载 initramfs 就会执行 Rootkit 的恶意代码。恶意代码执行之后,会将整个系统置于一个新创建的子命名空间之中,而恶意代码本身运行于更上级的命名空间。这种 Rootkit 隐藏方式可谓是别具一格,对系统的性能影响可以说忽略不计,是一个非常棒的 Rootkit,美中不足的是该 Rootkit 需要重启系统才能够执行其恶意代码。

这种 Rootkit 也是非常有效的运行时检测方案,首先,该 Rootkit 需要感染initramfs,基于这一点可以修改 grub,给 grub 新增一个启动过程中校验 initramfs 和vmlinuz 文件完整性的功能,避免启动不受信任的系统。当系统不幸感染了这种基于命名空间的 Rootkit,整个系统用户空间的数据已经不在可信的情况下,可以从内核态中测绘各个命名空间的信息,并且从中发现异常的命名空间数据。

感染 horsepill,攻击者拿到了设备的 shell,攻击者视角下真实的1号进程的命名空间数据如下:


感染 horsepill之后设备管理员视角下,可以非常直观的看到命名空间信息已经出现了异常,而这种异常信息通常是被人忽略的。


对于这种 Rootkit,受害主机运行时可以通过命名空间测绘的方式发现 Rootkit 的存在。

2. 使用kprobe技术的Rootkit
在上文中讲 Elkeid 的时候提到了 kprobe 这个机制,这个机制可以用来采集系统的行为信息,当然也可以用来编写 Rootkit。Kprobe、jprobe 以及 kretprobe 可以在内核符号的函数序言和函数尾声插桩,一旦内核符号注册了 kprobe,就会修改函数序言,被修改的函数序言会执行一个跳转指令,跳转到一个新的内核符号trace_spurious_interrupt,然后由 trace 机制跳转到中断处理函数,中断处理函数再调用 kprobe 的回调函数,使用 kprobe 技术可以篡改部分内核符号的入参和返回值,这能够非常容易的达到隐藏恶意程序相关信息的目的,并且这种 Rootkit 隐蔽性也同样很强。

这类Rootkit的检测方法也是同样不同于前面的方案的。最简单的判断方法就是查看/sys/kernel/debug/kprobes/list 这个文件的内容。

但是该方案有一个非常致命的缺陷,系统感染了 kprobe 的 Rootkit 之后,/sys/kernel/debug/kprobes/list 文件的内容已经是不可信的了,因此需要从其他途径获取 Rootkit 检测的线索。内核中有这么一个数据结构 kprobe_table,该数据结构维护了所有注册的 kprobe 的表,遍历这张表,可以发现感染这类 Rootkit 的 kprobe 数据结构。内核符号在 vmlinuz、挂载 kprobe 之前和挂载 kprobe 之后其数据都是存在非常明显的差异性的。例如: 内核符号 SyS_ptrace 经过 kprobe 挂载前后的内存数据对比如下图:


左边是挂载 kprobe 之后的内存数据,右边是挂载 kprobe 之前的内存数据,根据两者对比,可以发现前4个字节存在差异。同样也是这个内核符号,在 /boot/vmlinuz 文件中的二进制数据也和上面两者不同,相关数据如下图所示:

其差异同样体现在符号的前4个字节。这三者之间的差异主要由两方面因素所导致。首先是vmlinuz 加载到内存时,会动态的修改其代码内容,这种修改主要通过 .altinstructions 这个段中的数据完成的。加载到内存之后,再对其挂载 kprobe,修改的同样是前4个字节,将这部分差异性较强的代码进行反汇编,可以得出其汇编代码。

Vmlinuz:

>>> disasm('\xe8\x8b\xd2\x5b\x00')'   0:   e8 8b d2 5b 00          call   0x5bd290'

Before kprobe:

>>> disasm('\x0f\x1f\x44\x00\x00')'   0:   0f 1f 44 00 00          nop    DWORD PTR [eax+eax*1+0x0]'

After kprobe:

>>> disasm('\xe8\xfb\xd2\x5b\x00')'   0:   e8 fb d2 5b 00          call   0x5bd300'

反汇编这部分数据,可以看到其具体的操作码也有较强差异。首先,符号 SyS_ptrace 的内存地址为 0xffffffff8108a1b0,挂载 kprobe 之后,其执行的第一个指令为 call   0x5bd300。因此可以计算,其跳转地址为: '0xffffffff816474b0' 。查询该地址对应的符号如下:


根据上述分析内容,kprobe Rootkit 会在执行过程中修改内核符号的函数序言,因此要检测这种类型的 Rootkit,还可以对运行时的内核代码进行完整性检测。

3. 基于ebpf的    Rootkit

基于 bpf 的 Rootkit 并不是什么新鲜事物,bpf 技术于1993年就被提出,bpf 的指令集并非是一种图灵完全的指令集,因此使用 bpf 指令开发 Rootkit 似乎是一种天方夜谭。但是 APT 组织 Equation Group 做到了,在 shadow brokers 于2016年公开方程式的工具包中,有这么一个不太引人瞩目的 Rootkit DewDrops。这么长时间以来,大多数人眼里看到的可能只有永恒系列漏洞利用和 doublepulsar 后门,而对于其中的Dewdrops Rootkit,却是很少有人关注。尽管他的知名度并不高,但并不影响我对这个 Rootkit 设计者的佩服。

但是 DewDrops 并非此次的主要内容,这一段的主角 Rootkit 是 ebpfkit,这个 Rootkit于2021年在多个世界顶级安全会议上亮相。该 Rootkit 可以 hook 内核态函数,篡改内核态返回用户态缓冲区数据,达到用户态欺骗的目的。用户态进程拿到被篡改的数据,从而被骗通过认证。在此过程,不改变任何文件、进程、网络行为,不产生日志。常规 HIDS、HIPS 产品无法感知。eBPF 还支持 kprobe/kretprobe、uprobe/uretprobe、XDP、TC、socket、cgroup等程序类型,覆盖文件、网络、socket、syscall 等事件,都是可以被黑客利用的地方。面对这么复杂的威胁,从安全防御的视角,该怎样处理这种类型的威胁呢?这个 Rootkit的作者给出了这么一份答卷(业界良心啊)。作者开源了针对这种 Rootkit 的检测工具ebpfkit-monitor。该工具可用于静态分析 eBPF 字节码或在运行时监控可疑的eBPF 活动,尽管当前该检测工具仅仅针对 ebpfkit,但是这无疑给研究基于 ebpf 技术的 Rootkit 检测工具的人提供了良好的思路。

结语

在攻防对抗愈加激烈的时代,在 APT 攻击逐渐进入大众视野的当下,Rootkit 的攻防也将会愈加激烈,而安全从业者乃至安全企业,也需要重新审视一下,是否已经具备了针对未知威胁的检测能力,是否已经具备了针对新型攻击技术的检测防御能力。

参考链接

https://github.com/Gui774ume/ebpfkit-monitor

https://github.com/Gui774ume/ebpfkit

https://github.com/qilingframework/qiling

https://defcon.org/html/defcon-29/dc-29-speakers.html#fournier

https://github.com/bytedance/Elkeid

https://github.com/bytedance/Elkeid-HUB

https://github.com/qilingframework/qiling

https://www.cnxct.com/container-escape-in-linux-kernel-space-by-ebpf/

https://reverse.put.as/2021/12/17/knock-knock-whos-there/

摘要

Rootkit 这一概念最早出现于上个世纪九十年代初期,CERT Coordination Center(CERT/CC) 于1994年在 CA-1994-01 这篇安全咨询报告中使用了 Rootkit 这个词汇。在这之后 Rootkit 技术发展迅速,这种快速发展的态势在 2000 年达到了顶峰。2000年后,Rootkit 技术的发展也进入了低潮期,但是对于 Rootkit 技术的研究却并未停滞。在 APT 攻击日益流行的趋势下,Rootkit 攻击和检测技术也同样会迎来新的发展高潮。

在往期的Rootkit系列文章里面,我们分别介绍了 Rootkit 技术的发展历程WindowsLinux平台下的 Rootkit 攻击技术。本期 Rootkit 系列文章将会给大家介绍当前主流的 Rootkit 防御技术以及一些非常规 Rootkit 的可实施检测方案。

被滥用的Rootkit技术

长期以来,Rootkit 检测一直是一个非常大的痛点,这些具有高度定制化的恶意程序集合隐藏在服务器上,以高权限访问计算机和网络。虽然 Rootkit 并没有成为大新闻中的主角,但是它们一直都过得很安逸,并且持续性的造成损害。对于安全从业者而言,这不应该是一个被忽视的地方。

APT 通常和 Rootkit 齐头并进。从西方 APT 组织的攻击历史及已经泄露的网络武器看,高隐匿、高持久化(Low&Slow)是其关键特征,而 Rootkit 则是达成此目的的重要技术之一,因此 Rootkit 一直以来和 APT 配合的很好。

让人遗憾的是,几乎任何脚本小子都可以轻易在被攻击成功的目标主机上植入 Rootkit。比起这个,更让人痛心的是,一些挖矿木马和广告木马都开始使用 Rootkit 技术了,黑产都卷成这个样子了吗?H2Miner 挖矿家族开始使用新的 Rootkit 样本,该Rootkit 使用 LD_PRELOAD 技术劫持动态链接过程。LD_PRELOAD 是一个非常古老的C 库技巧,但它今天仍然被成功使用和滥用。

当前主流Rookit检测技术分析

当前主要的 Rootkit 检测的方法包括但不限于以下几种类型。

1.基于 Rootkit 运行的效果进行检测

如: 发现隐藏的端口、进程、内核模块、网络连接、被篡改的内核代码。

缺陷: 该检测方案对预设的检测场景的依赖程度较高,一旦恶意软件出现检测场景之外的行为,则难以做到有效检测。

2.静态文件特征检测

例如: 扫描磁盘上的文件,将文件与特征库进行匹配,通过该方式检测可能存在的Rootkit。

缺陷: 该检测方案对特征库依赖程度较高,能够有效发现已知特征的 Rootkit,难以发现未知特征的 Rootkit。

3. 动态行为分析检测

例如: 对系统运行过程中的行为进行审计,通过行为规则匹配的方式发现系统中的异常行为,通过该方式发现可能存在的 Rootkit。

缺陷: 对行为规则的依赖程度较高,只能匹配已知行为特征的 Rootkit,难以匹配未知行为特征的 Rootkit。

4.数据完整性检测

例如: 对系统关键的数据结构进行监控,通过监控关键数据结构的异常篡改,以发现系统中的恶意行为。

缺陷: 完整性检测依赖于受信任的源数据,如果源数据被篡改或者不可信的情况下,则完整性检测也很难奏效。

当前的开源社区的 Rootkit 检测技术主要以 Rootkit 运行效果检测和静态文件特征检测为主,动态行为分析和数据完整性保护的 Rootkit 检测项目相对较少。

当前主流Rookit检测项目分析

Chkrootkit: 检测 /proc/kallsyms 的内容并匹配相对应的文件名和目录来检测是否存在Rootkit,通过该方式,chkrootkit 能够在一定程度上发现 Rootkit 执行的恶意行为,诸如文件隐藏,网络连接隐藏,进程信息隐藏。但是该检测方案对 Rootkit 指纹库依赖度较高,并且严重依赖于 /proc/ 目录下的文件,一旦该文件不可信任,则很容易被绕过。

Rkhunter: 这个 Rootkit 检测工具会扫描相应的文件目录、文件、符号表,通过该方式检测是否存在 Rootkit 恶意家族。同样的,该检测方案对特征库的依赖度较高,且难以发现指纹没有覆盖到的 Rootkit。

Kjackal: 该 Rootkit 检测工具通过遍历内核中的系统调用表 syscall_table,注意检查例程的入口是否存在内核空间,如果不存在,就意味着发生了 syscall 劫持。发现了存在syscall_table 的劫持之后,该工具会进行反向追踪,以确定劫持系统调用的是哪一个恶意LKM模块。Kjackal 会枚举 /proc/net/tcp 的读写句柄是否存在于内核态中,如果不存在,则发生了劫持。该工具还会枚举 modules kset 以检测隐藏的内核模块。该检测方案也同样存在被绕过的可能性,一旦 Rootkit 通过删除 kobject 数据结构的方式隐藏Rootkit,那么这将很难检测,不过这种删除 kobject 数据结构的方式也同样会影响 Rootkit 正常使用。

Tyton: 该项目检测 Rootkit 的方式和 kjackal 非常相似,通过枚举内核空间的module_list,中断向量表、网络连接读写句柄、系统调用表、netfilter hook 等方式发现可能存在的Rootkit,发现Rootkit之后,通过 get_module_from_addr 函数反向溯源恶意的内核模块。

Elkeid: 该项目是字节跳动的一个开源的 HIDS 项目,该 hids 检测 Rootkit 的方式继承自 tyton 的检测方案。除了这个之外,elkeid 还在行为检测方面做出了突破,使用kprobe对关键的系统调用进行 hook,持续监控系统运行过程中的进程行为,网络行为、文件行为等相关信息并保存到日志中,再使用字节跳动于近期开源的 Hlkeid Hub的行为日志检测引擎和规则集,能够对系统运行过程中的日志进行自动化分析,以发现可能存在的未知威胁。不得不说这是一个非常勇敢的突破,业界普遍都对 kprobe 持保留态度,敢于直接上车的并不多见。不过这种日志采集方式也存在一个缺陷,一旦攻击者控制了 /sys/kernel/debug/kprobes/enabled 文件,就可以使这种日志采集功能失效。再补充一句,该项目更新频率较高,并且社区支持非常友好。

stmichael-lkm:该项目能够为内核提供一定的完整性保护,能够在一定程度上发现针对内核的篡改,通过这种方式发现可能存在的 Rootkit。一旦检测到 Rootkit 篡改内核,StMichael 尝试通过将所做的更改回滚到先前已知的良好状态来恢复内核的完整性。不得不说这是一个非常大胆的尝试,比使用 kprobe 更加激进,这种方案的致命缺陷就是很容易为系统引入未知的问题,导致系统的不稳定。

Qiling: 该项目是一个高级二进制仿真框架,能够模拟多平台,多架构的运行环境,通过类似于沙箱的环境运行 Rootkit,并且记录 Rootkit 运行过程中的行为。这为恶意Rootkit 的检测和分析提供了一种全新的思路。传统沙箱对恶意软件的检测很难达到这种细粒度的监控效果。

非常规Rookit以及检测方案

1. 使用了命名空间技术的 HorsePILL

在讲述该 Rootkit 之前,有必要简单介绍一下命名空间的含义。命名空间是Linux的一个非常重要的系统特性,Linux 的命名空间机制提供了一种资源隔离的解决方案。PID,IPC,Network 等系统资源不再是全局性的,而是属于特定的Namespace,不同命名空间的资源是互相隔离的,在一个命名空间所做的事情不会影响另一个命名空间。各命名空间在 Linux 的引入版本如下:


由于命名空间的隔离特性,这给恶意文件的隐藏提供了新的思路。将恶意文件和恶意文件运行过程中的进程、网络置于一个与系统不同命名空间的环境中,可以非常有效的隐藏自身,在一定程度上来说,难以发现。

HorsePILL 这个 Rootkit 就利用了这种命名空间的特性,该 Rootkit 会感染系统的initramfs,被感染的系统在启动过程中加载 initramfs 就会执行 Rootkit 的恶意代码。恶意代码执行之后,会将整个系统置于一个新创建的子命名空间之中,而恶意代码本身运行于更上级的命名空间。这种 Rootkit 隐藏方式可谓是别具一格,对系统的性能影响可以说忽略不计,是一个非常棒的 Rootkit,美中不足的是该 Rootkit 需要重启系统才能够执行其恶意代码。

这种 Rootkit 也是非常有效的运行时检测方案,首先,该 Rootkit 需要感染initramfs,基于这一点可以修改 grub,给 grub 新增一个启动过程中校验 initramfs 和vmlinuz 文件完整性的功能,避免启动不受信任的系统。当系统不幸感染了这种基于命名空间的 Rootkit,整个系统用户空间的数据已经不在可信的情况下,可以从内核态中测绘各个命名空间的信息,并且从中发现异常的命名空间数据。

感染 horsepill,攻击者拿到了设备的 shell,攻击者视角下真实的1号进程的命名空间数据如下:


感染 horsepill之后设备管理员视角下,可以非常直观的看到命名空间信息已经出现了异常,而这种异常信息通常是被人忽略的。


对于这种 Rootkit,受害主机运行时可以通过命名空间测绘的方式发现 Rootkit 的存在。

2. 使用kprobe技术的Rootkit
在上文中讲 Elkeid 的时候提到了 kprobe 这个机制,这个机制可以用来采集系统的行为信息,当然也可以用来编写 Rootkit。Kprobe、jprobe 以及 kretprobe 可以在内核符号的函数序言和函数尾声插桩,一旦内核符号注册了 kprobe,就会修改函数序言,被修改的函数序言会执行一个跳转指令,跳转到一个新的内核符号trace_spurious_interrupt,然后由 trace 机制跳转到中断处理函数,中断处理函数再调用 kprobe 的回调函数,使用 kprobe 技术可以篡改部分内核符号的入参和返回值,这能够非常容易的达到隐藏恶意程序相关信息的目的,并且这种 Rootkit 隐蔽性也同样很强。

这类Rootkit的检测方法也是同样不同于前面的方案的。最简单的判断方法就是查看/sys/kernel/debug/kprobes/list 这个文件的内容。

但是该方案有一个非常致命的缺陷,系统感染了 kprobe 的 Rootkit 之后,/sys/kernel/debug/kprobes/list 文件的内容已经是不可信的了,因此需要从其他途径获取 Rootkit 检测的线索。内核中有这么一个数据结构 kprobe_table,该数据结构维护了所有注册的 kprobe 的表,遍历这张表,可以发现感染这类 Rootkit 的 kprobe 数据结构。内核符号在 vmlinuz、挂载 kprobe 之前和挂载 kprobe 之后其数据都是存在非常明显的差异性的。例如: 内核符号 SyS_ptrace 经过 kprobe 挂载前后的内存数据对比如下图:


左边是挂载 kprobe 之后的内存数据,右边是挂载 kprobe 之前的内存数据,根据两者对比,可以发现前4个字节存在差异。同样也是这个内核符号,在 /boot/vmlinuz 文件中的二进制数据也和上面两者不同,相关数据如下图所示:

其差异同样体现在符号的前4个字节。这三者之间的差异主要由两方面因素所导致。首先是vmlinuz 加载到内存时,会动态的修改其代码内容,这种修改主要通过 .altinstructions 这个段中的数据完成的。加载到内存之后,再对其挂载 kprobe,修改的同样是前4个字节,将这部分差异性较强的代码进行反汇编,可以得出其汇编代码。

Vmlinuz:

>>> disasm('\xe8\x8b\xd2\x5b\x00')'   0:   e8 8b d2 5b 00          call   0x5bd290'

Before kprobe:

>>> disasm('\x0f\x1f\x44\x00\x00')'   0:   0f 1f 44 00 00          nop    DWORD PTR [eax+eax*1+0x0]'

After kprobe:

>>> disasm('\xe8\xfb\xd2\x5b\x00')'   0:   e8 fb d2 5b 00          call   0x5bd300'

反汇编这部分数据,可以看到其具体的操作码也有较强差异。首先,符号 SyS_ptrace 的内存地址为 0xffffffff8108a1b0,挂载 kprobe 之后,其执行的第一个指令为 call   0x5bd300。因此可以计算,其跳转地址为: '0xffffffff816474b0' 。查询该地址对应的符号如下:


根据上述分析内容,kprobe Rootkit 会在执行过程中修改内核符号的函数序言,因此要检测这种类型的 Rootkit,还可以对运行时的内核代码进行完整性检测。

3. 基于ebpf的    Rootkit

基于 bpf 的 Rootkit 并不是什么新鲜事物,bpf 技术于1993年就被提出,bpf 的指令集并非是一种图灵完全的指令集,因此使用 bpf 指令开发 Rootkit 似乎是一种天方夜谭。但是 APT 组织 Equation Group 做到了,在 shadow brokers 于2016年公开方程式的工具包中,有这么一个不太引人瞩目的 Rootkit DewDrops。这么长时间以来,大多数人眼里看到的可能只有永恒系列漏洞利用和 doublepulsar 后门,而对于其中的Dewdrops Rootkit,却是很少有人关注。尽管他的知名度并不高,但并不影响我对这个 Rootkit 设计者的佩服。

但是 DewDrops 并非此次的主要内容,这一段的主角 Rootkit 是 ebpfkit,这个 Rootkit于2021年在多个世界顶级安全会议上亮相。该 Rootkit 可以 hook 内核态函数,篡改内核态返回用户态缓冲区数据,达到用户态欺骗的目的。用户态进程拿到被篡改的数据,从而被骗通过认证。在此过程,不改变任何文件、进程、网络行为,不产生日志。常规 HIDS、HIPS 产品无法感知。eBPF 还支持 kprobe/kretprobe、uprobe/uretprobe、XDP、TC、socket、cgroup等程序类型,覆盖文件、网络、socket、syscall 等事件,都是可以被黑客利用的地方。面对这么复杂的威胁,从安全防御的视角,该怎样处理这种类型的威胁呢?这个 Rootkit的作者给出了这么一份答卷(业界良心啊)。作者开源了针对这种 Rootkit 的检测工具ebpfkit-monitor。该工具可用于静态分析 eBPF 字节码或在运行时监控可疑的eBPF 活动,尽管当前该检测工具仅仅针对 ebpfkit,但是这无疑给研究基于 ebpf 技术的 Rootkit 检测工具的人提供了良好的思路。

结语

在攻防对抗愈加激烈的时代,在 APT 攻击逐渐进入大众视野的当下,Rootkit 的攻防也将会愈加激烈,而安全从业者乃至安全企业,也需要重新审视一下,是否已经具备了针对未知威胁的检测能力,是否已经具备了针对新型攻击技术的检测防御能力。

参考链接

https://github.com/Gui774ume/ebpfkit-monitor

https://github.com/Gui774ume/ebpfkit

https://github.com/qilingframework/qiling

https://defcon.org/html/defcon-29/dc-29-speakers.html#fournier

https://github.com/bytedance/Elkeid

https://github.com/bytedance/Elkeid-HUB

https://github.com/qilingframework/qiling

https://www.cnxct.com/container-escape-in-linux-kernel-space-by-ebpf/

https://reverse.put.as/2021/12/17/knock-knock-whos-there/

久等了各位,虎年第一场沙龙带着满满干货来了!深信服千里目安全实验室与知道创宇404 实验室联手,为大家打造一场深度高质量的「目极千里 洞见安全」安全技术分享沙龙。

4月16日14:00-18:00「目极千里 洞见安全」第五期,正式开播,期待您的参与!

四位技术研究达人将围绕 Chrome V8 利用脚本Magnitude exploit kit 分析WebKit JSC 引擎与漏洞原理高隐藏持久化技术取证等议题进行分享,部分内容还会现场演示,让各位技术爱好者收获满满!更有多重好礼直播间抽奖赠送,知道创宇404实验室《404 Paper精粹》2021年套册知道创宇 404 实验室礼包(棒球帽、鼠标垫、贴纸)深信服 SRC 周边礼包(文化衫、帆布包、口罩) 等礼品等着你~

↓一张图了解本期精彩亮点↓

添加小千微信:Sangfor_Further_eye

进入「目极千里 洞见安全」线上沙龙活动群

报名参与直播吧!

久等了各位,虎年第一场沙龙带着满满干货来了!深信服千里目安全实验室与知道创宇404 实验室联手,为大家打造一场深度高质量的「目极千里 洞见安全」安全技术分享沙龙。

4月16日14:00-18:00「目极千里 洞见安全」第五期,正式开播,期待您的参与!

四位技术研究达人将围绕 Chrome V8 利用脚本Magnitude exploit kit 分析WebKit JSC 引擎与漏洞原理高隐藏持久化技术取证等议题进行分享,部分内容还会现场演示,让各位技术爱好者收获满满!更有多重好礼直播间抽奖赠送,知道创宇404实验室《404 Paper精粹》2021年套册知道创宇 404 实验室礼包(棒球帽、鼠标垫、贴纸)深信服 SRC 周边礼包(文化衫、帆布包、口罩) 等礼品等着你~

↓一张图了解本期精彩亮点↓

添加小千微信:Sangfor_Further_eye

进入「目极千里 洞见安全」线上沙龙活动群

报名参与直播吧!

序言

从西方APT组织的攻击历史及已经泄露的网络武器看,高隐匿、高持久化(Low&Slow)是其关键特征,而 Rootkit 则是达成此目的的重要技术之一。

在“【Rootkit 系列研究】Windows平台的高隐匿、高持久化威胁”里,我们介绍了Windows Rootkit的生存期,可达成的效果,运用这项技术展开攻击的可行性以及这项技术的发展现状。除了Windows操作系统,Linux、Mac OS等同样受Rootkit关注。在本文中,我们将目光投向Linux操作系统。我们首先对近年来用户态Rootkit在黑产组织中的广泛使用进行讨论,接着介绍内核态Rootkit的高度定制化需求和Linux系统上存在的其他类型Rootkit,最后从攻防视角对Rootkit进行总结。

难以检测的Linux Rootkit

想象以下场景:由于业务需要,你们公司稳定运行多年的某台Linux服务器需要进行系统升级,在完成升级后,你偶然注意到服务器上多了几个看起来像系统文件的文件(夹),你的第一反应是什么?这是新版本引入的系统文件,pass?有点可疑,去搜索引擎查询这些文件名是否正常?小心!任何一丝异常的背后都可能潜藏着巨大的危险。

Rootkit在几乎所有操作系统上都是最具挑战性的恶意软件类型,它利用操作系统代码中的疏忽,隐藏它的存在和恶意行为。制作精良的Rootkit可以在受害主机长期驻留,让主机在用户视角和部分内核视角没有任何感知,进而很难通过系统提供的检测工具以及常规的防病毒软件进行检测和清除。

用户态倍受黑产青睐

Linux Rootkit运行时所处的层次分用户层和内核层两种。对于运行于用户层的用户态Rootkit,它所涉及的技术简单且成熟,例如替换系统文件,动态链接库劫持等。对近两年曝光的黑产组织攻击样本进行分析,我们发现越来越多的黑产组织以某些开源Rootkit为基础,将用户态Rootkit技术加入自己的技术栈。

进一步讲,黑产组织喜欢将用户态Rootkit作为其攻击链中multi-stage-malware的一部分,即他们没有将Rootkit功能集成在原本的挖矿或僵尸网络样本中,而是在原有恶意软件的基础上新增Rootkit,用于实现隐藏文件等新的功能,以规避安全公司提出的感染检测方案:“通过检查某些路径、文件的存在与否,判断某主机是否受到某恶意软件的影响”。

根据某海外安全厂商2020年底的报告,H2Miner挖矿家族开始使用新的Rootkit样本。该Rootkit修改自开源项目“beurk”,它使用LD_PRELOAD技术劫持动态链接过程,将磁盘上的挖矿文件“kinsing”以及正在运行的相关进程隐藏。这使得IT管理员在感知到系统运行速度无故变慢后,无法通过“top”命令看到占用大量CPU资源的挖矿进程。值得一提的是,H2Miner家族目前仍十分活跃,我们发现2021年底该家族使用Log4j漏洞进行挖矿软件传播。(链接:12.12 Log4j RCE 黑产从业者的狂欢)

2021年我们还观测到活跃的TeamT/N/T挖矿家族使用的Rootkit样本(链接:1.10 2021挖矿木马趋势报告)。该家族除了利用修改自开源项目“Diamorphine”的内核态Rootkit之外,还在用户层替换了ps、top等系统命令文件,当使用这些命令进行排查时,挖矿的相关痕迹会被隐藏。具体代码如图:

2021年4月,某海外安全厂商曝光了一种新型远控程序Facefish,他们怀疑攻击者正在进行僵尸网络组网,并计划在组网完成后,以“访问权限即服务”(access-as-a-service)的方式出售该网络的访问权限。Facefish远控通过第一阶段的dropper释放出一个Rootkit,Rootkit利用用户态常用的动态链接库劫持技术,实现ssh、sshd的运行时链接程序劫持,最终在受害主机上放置一个后门。事实上,对于一个Rootkit程序,Facefish的这种用法十分原始,因为它仅利用了Rootkit的触发机制,恶意so文件中还可以增加一系列隐藏功能。动态链接库劫持效果如图:

为了降低被怀疑的概率,上述组织使用的恶意动态链接库分别命名为libsystem.so、libs.so,它们刻意模仿Linux的系统自带程序文件名,并驻留在系统文件路径下,企图蒙蔽服务器管理员。

试想如果你在包含上百个so文件,并且这些文件的文件名均以“lib”开头的文件夹/lib64中看到了libs.so,这会引起你的怀疑吗?不过对于防御的一方,上述场景并不会让人夜不能寐,因为针对用户态Rootkit,有诸如文件完整性检测、交叉视图等十分成熟的检测技术。归根结底,这些Rootkit都只运行在用户层,当防御措施深入进操作系统内核,从底向上看,他们通通无处遁形。

内核态的高度定制化

防御方可以深入Linux操作系统内核进行防守,攻击的一方当然也可以进入内核层进行攻击。越接近Linux操作系统底层内核代码,Rootkit的开发难度越大,对其进行检测的难度也越高。对攻击者来说,高投入通常意味着更有价值的攻击目标和更高的回报,如果开发得当,Rootkit可以长期藏匿在目标机器中,所以内核态Rootkit也是攻击者关注的重点。

传统的内核态Rootkit使用可加载内核模块(LKM)技术进入内核层后,在内核层进行“hook”。从执行在用户态的程序调用“int 0x80”陷入内核开始,整个系统调用流程中的任何一个位置,都可能成为内核态Rootkit进行hook的目标,围绕“hook什么”,“如何hook”这两个问题,出现了近十种内核态Rootkit技术。

与用户态Rootkit不同,由于内核态Rootkit直接对Linux内核源代码进行操纵,所以对Rootkit有极高的定制化要求。这是因为经过多年的发展,Linux的内核版本众多,每个版本的内核代码都有或多或少的修改,攻击者开发的某个内核态Rootkit可以在A版本上正常运行,很可能在B版本上完全失效,这就可能出现文章开头提到的那一幕。

前文提到的TeamT/N/T挖矿家族除了在用户态替换系统命令文件外,还使用内核态Rootkit技术,将恶意内核模块diamorphine.ko加载进内核,实现进程、模块、文件目录的隐藏以及用户权限的提升。该挖矿家族以云主机为目标,Rootkit只能在2.6.x、3.x、4.x内核版本上正常运行,具体实现如图:

除了黑产,APT组织发起的定向攻击中也用到了内核态Rootkit。APT组织对隐蔽性有更高的要求,这也给信息收集环节提出了更大的挑战,APT组织需要清楚的知道某次定向攻击的目标所使用Linux服务器的内核版本号。在必要条件下,APT组织可以拿到与目标服务器完全相同的实体,并直接在其上进行Rootkit开发。例如震网病毒事件中,攻击者对目标设备了如指掌,而后在恶意代码中加入了严苛的环境判断。再例如2020年曝光,据称由APT28开发的内核态Rootkit Drovorub,它针对3.7以下版本的Linux内核,特别是Red Hat发行版进行攻击。

内核态攻防进入深水区

Rootkit最关键的要点是隐藏,而隐藏意味着攻击者清楚的知道为什么某个文件(夹)会显示,为什么某个网络连接可被观测,然后对这些显示的机制进行绕过,以达到隐藏的效果。攻击者知道的这些机制,防御方当然也知道,并且对其开展检测,而攻击者进一步进行绕过,随后便产生了攻防双方的猫鼠游戏。Linux内核态Rootkit攻防的本质,是双方谁对操作系统底层技术更加了解。继续深入Linux内核,有没有更加底层的Rootkit技术?答案当然是有,而且近年来越来越多。

2015年,Ryan利用Linux内核中的kprobe机制实现了Rootkit。Kprobe是Linux内核开发者用于内核函数跟踪的一种轻量级内核调试技术,这个Rootkit展示了利用基于kprobe机制进行hook,实现Rootkit功能的可行性。

2016年,Michael在Blackhat上提出了一种基于命名空间的新型Linux Rootkit——Horse Pill,它在操作系统启动过程中劫持虚拟根文件系统initrd(boot loader initialized RAM disk),使受攻击的服务器进入另一个由攻击者创建的“楚门的世界”(即一个子命名空间)。在这个子命名空间中,用户所有的操作都能正常执行,但完全意识不到还存在另一个并行运行的,由攻击者所控制的“真实世界”。

在kprobe的基础上,Linux 4.0以上版本增加了eBPF技术,该技术可以在不加载内核模块的前提下,在Linux内核中运行用户编写的程序。Guillaume在2021年Blackhat上公开了基于eBPF的Rootkit。

总结

虽然kprobe、Horse Pill、eBPF在内核更加底层的位置完成了Rootkit的隐藏功能,但是痕迹是否真的隐藏,会根据观测的视角而大不相同。理论上不存在没有任何痕迹的Rootkit,总有某些角度可以观测到系统出现了异常,因为如果一个程序在所有视角都隐藏,那么攻击者也无法对它进行控制。上述这些技术可以被攻击者所利用,而防御方同样可以利用它们。现在各安全公司已利用它们设计功能更强大的安全软件,对系统进行监控。

我们已经深入Linux内核深处,是否还存在更加底层的Rootkit?2021年12月28日,海外某安全公司给出了突破操作系统的答案。他们发现了固件Rootkit“iLOBleed”,其隐藏在惠普固件HP iLO 上,同时可以以最高权限访问和修改设备上所有的软硬件资源。

事实上,对于现有的高级Rootkit,安全软件已经非常难以检测,通常需要安全专家人工介入分析,可以想象某些由APT组织定向投递的Rootkit正在受害机器中潜伏。对Rootkit技术进行研究,不是去解决想象中的问题,而是回应真实的ring0世界。

参考资料

https://www.4hou.com/posts/vLmm

https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html

https://therecord.media/malware-campaign-targets-server-hosting-software-cwp/

https://documents.trendmicro.com/assets/white_papers/wp-tracking-the-activities-of-teamT/N/T.pdf

https://www.blackhat.com/docs/us-16/materials/us-16-Leibowitz-Horse-Pill-A-New-Type-Of-Linux-Rootkit.pdf

https://github.com/elfmaster/kprobe_rootkit

https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-With-Friends-Like-EBPF-Who-Needs-Enemies.pdf

https://www.secureworld.io/industry-news/access-as-a-service-rising-in-popularity

https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/

https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/

序言

从西方APT组织的攻击历史及已经泄露的网络武器看,高隐匿、高持久化(Low&Slow)是其关键特征,而 Rootkit 则是达成此目的的重要技术之一。

在“【Rootkit 系列研究】Windows平台的高隐匿、高持久化威胁”里,我们介绍了Windows Rootkit的生存期,可达成的效果,运用这项技术展开攻击的可行性以及这项技术的发展现状。除了Windows操作系统,Linux、Mac OS等同样受Rootkit关注。在本文中,我们将目光投向Linux操作系统。我们首先对近年来用户态Rootkit在黑产组织中的广泛使用进行讨论,接着介绍内核态Rootkit的高度定制化需求和Linux系统上存在的其他类型Rootkit,最后从攻防视角对Rootkit进行总结。

难以检测的Linux Rootkit

想象以下场景:由于业务需要,你们公司稳定运行多年的某台Linux服务器需要进行系统升级,在完成升级后,你偶然注意到服务器上多了几个看起来像系统文件的文件(夹),你的第一反应是什么?这是新版本引入的系统文件,pass?有点可疑,去搜索引擎查询这些文件名是否正常?小心!任何一丝异常的背后都可能潜藏着巨大的危险。

Rootkit在几乎所有操作系统上都是最具挑战性的恶意软件类型,它利用操作系统代码中的疏忽,隐藏它的存在和恶意行为。制作精良的Rootkit可以在受害主机长期驻留,让主机在用户视角和部分内核视角没有任何感知,进而很难通过系统提供的检测工具以及常规的防病毒软件进行检测和清除。

用户态倍受黑产青睐

Linux Rootkit运行时所处的层次分用户层和内核层两种。对于运行于用户层的用户态Rootkit,它所涉及的技术简单且成熟,例如替换系统文件,动态链接库劫持等。对近两年曝光的黑产组织攻击样本进行分析,我们发现越来越多的黑产组织以某些开源Rootkit为基础,将用户态Rootkit技术加入自己的技术栈。

进一步讲,黑产组织喜欢将用户态Rootkit作为其攻击链中multi-stage-malware的一部分,即他们没有将Rootkit功能集成在原本的挖矿或僵尸网络样本中,而是在原有恶意软件的基础上新增Rootkit,用于实现隐藏文件等新的功能,以规避安全公司提出的感染检测方案:“通过检查某些路径、文件的存在与否,判断某主机是否受到某恶意软件的影响”。

根据某海外安全厂商2020年底的报告,H2Miner挖矿家族开始使用新的Rootkit样本。该Rootkit修改自开源项目“beurk”,它使用LD_PRELOAD技术劫持动态链接过程,将磁盘上的挖矿文件“kinsing”以及正在运行的相关进程隐藏。这使得IT管理员在感知到系统运行速度无故变慢后,无法通过“top”命令看到占用大量CPU资源的挖矿进程。值得一提的是,H2Miner家族目前仍十分活跃,我们发现2021年底该家族使用Log4j漏洞进行挖矿软件传播。(链接:12.12 Log4j RCE 黑产从业者的狂欢)

2021年我们还观测到活跃的TeamT/N/T挖矿家族使用的Rootkit样本(链接:1.10 2021挖矿木马趋势报告)。该家族除了利用修改自开源项目“Diamorphine”的内核态Rootkit之外,还在用户层替换了ps、top等系统命令文件,当使用这些命令进行排查时,挖矿的相关痕迹会被隐藏。具体代码如图:

2021年4月,某海外安全厂商曝光了一种新型远控程序Facefish,他们怀疑攻击者正在进行僵尸网络组网,并计划在组网完成后,以“访问权限即服务”(access-as-a-service)的方式出售该网络的访问权限。Facefish远控通过第一阶段的dropper释放出一个Rootkit,Rootkit利用用户态常用的动态链接库劫持技术,实现ssh、sshd的运行时链接程序劫持,最终在受害主机上放置一个后门。事实上,对于一个Rootkit程序,Facefish的这种用法十分原始,因为它仅利用了Rootkit的触发机制,恶意so文件中还可以增加一系列隐藏功能。动态链接库劫持效果如图:

为了降低被怀疑的概率,上述组织使用的恶意动态链接库分别命名为libsystem.so、libs.so,它们刻意模仿Linux的系统自带程序文件名,并驻留在系统文件路径下,企图蒙蔽服务器管理员。

试想如果你在包含上百个so文件,并且这些文件的文件名均以“lib”开头的文件夹/lib64中看到了libs.so,这会引起你的怀疑吗?不过对于防御的一方,上述场景并不会让人夜不能寐,因为针对用户态Rootkit,有诸如文件完整性检测、交叉视图等十分成熟的检测技术。归根结底,这些Rootkit都只运行在用户层,当防御措施深入进操作系统内核,从底向上看,他们通通无处遁形。

内核态的高度定制化

防御方可以深入Linux操作系统内核进行防守,攻击的一方当然也可以进入内核层进行攻击。越接近Linux操作系统底层内核代码,Rootkit的开发难度越大,对其进行检测的难度也越高。对攻击者来说,高投入通常意味着更有价值的攻击目标和更高的回报,如果开发得当,Rootkit可以长期藏匿在目标机器中,所以内核态Rootkit也是攻击者关注的重点。

传统的内核态Rootkit使用可加载内核模块(LKM)技术进入内核层后,在内核层进行“hook”。从执行在用户态的程序调用“int 0x80”陷入内核开始,整个系统调用流程中的任何一个位置,都可能成为内核态Rootkit进行hook的目标,围绕“hook什么”,“如何hook”这两个问题,出现了近十种内核态Rootkit技术。

与用户态Rootkit不同,由于内核态Rootkit直接对Linux内核源代码进行操纵,所以对Rootkit有极高的定制化要求。这是因为经过多年的发展,Linux的内核版本众多,每个版本的内核代码都有或多或少的修改,攻击者开发的某个内核态Rootkit可以在A版本上正常运行,很可能在B版本上完全失效,这就可能出现文章开头提到的那一幕。

前文提到的TeamT/N/T挖矿家族除了在用户态替换系统命令文件外,还使用内核态Rootkit技术,将恶意内核模块diamorphine.ko加载进内核,实现进程、模块、文件目录的隐藏以及用户权限的提升。该挖矿家族以云主机为目标,Rootkit只能在2.6.x、3.x、4.x内核版本上正常运行,具体实现如图:

除了黑产,APT组织发起的定向攻击中也用到了内核态Rootkit。APT组织对隐蔽性有更高的要求,这也给信息收集环节提出了更大的挑战,APT组织需要清楚的知道某次定向攻击的目标所使用Linux服务器的内核版本号。在必要条件下,APT组织可以拿到与目标服务器完全相同的实体,并直接在其上进行Rootkit开发。例如震网病毒事件中,攻击者对目标设备了如指掌,而后在恶意代码中加入了严苛的环境判断。再例如2020年曝光,据称由APT28开发的内核态Rootkit Drovorub,它针对3.7以下版本的Linux内核,特别是Red Hat发行版进行攻击。

内核态攻防进入深水区

Rootkit最关键的要点是隐藏,而隐藏意味着攻击者清楚的知道为什么某个文件(夹)会显示,为什么某个网络连接可被观测,然后对这些显示的机制进行绕过,以达到隐藏的效果。攻击者知道的这些机制,防御方当然也知道,并且对其开展检测,而攻击者进一步进行绕过,随后便产生了攻防双方的猫鼠游戏。Linux内核态Rootkit攻防的本质,是双方谁对操作系统底层技术更加了解。继续深入Linux内核,有没有更加底层的Rootkit技术?答案当然是有,而且近年来越来越多。

2015年,Ryan利用Linux内核中的kprobe机制实现了Rootkit。Kprobe是Linux内核开发者用于内核函数跟踪的一种轻量级内核调试技术,这个Rootkit展示了利用基于kprobe机制进行hook,实现Rootkit功能的可行性。

2016年,Michael在Blackhat上提出了一种基于命名空间的新型Linux Rootkit——Horse Pill,它在操作系统启动过程中劫持虚拟根文件系统initrd(boot loader initialized RAM disk),使受攻击的服务器进入另一个由攻击者创建的“楚门的世界”(即一个子命名空间)。在这个子命名空间中,用户所有的操作都能正常执行,但完全意识不到还存在另一个并行运行的,由攻击者所控制的“真实世界”。

在kprobe的基础上,Linux 4.0以上版本增加了eBPF技术,该技术可以在不加载内核模块的前提下,在Linux内核中运行用户编写的程序。Guillaume在2021年Blackhat上公开了基于eBPF的Rootkit。

总结

虽然kprobe、Horse Pill、eBPF在内核更加底层的位置完成了Rootkit的隐藏功能,但是痕迹是否真的隐藏,会根据观测的视角而大不相同。理论上不存在没有任何痕迹的Rootkit,总有某些角度可以观测到系统出现了异常,因为如果一个程序在所有视角都隐藏,那么攻击者也无法对它进行控制。上述这些技术可以被攻击者所利用,而防御方同样可以利用它们。现在各安全公司已利用它们设计功能更强大的安全软件,对系统进行监控。

我们已经深入Linux内核深处,是否还存在更加底层的Rootkit?2021年12月28日,海外某安全公司给出了突破操作系统的答案。他们发现了固件Rootkit“iLOBleed”,其隐藏在惠普固件HP iLO 上,同时可以以最高权限访问和修改设备上所有的软硬件资源。

事实上,对于现有的高级Rootkit,安全软件已经非常难以检测,通常需要安全专家人工介入分析,可以想象某些由APT组织定向投递的Rootkit正在受害机器中潜伏。对Rootkit技术进行研究,不是去解决想象中的问题,而是回应真实的ring0世界。

参考资料

https://www.4hou.com/posts/vLmm

https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html

https://therecord.media/malware-campaign-targets-server-hosting-software-cwp/

https://documents.trendmicro.com/assets/white_papers/wp-tracking-the-activities-of-teamT/N/T.pdf

https://www.blackhat.com/docs/us-16/materials/us-16-Leibowitz-Horse-Pill-A-New-Type-Of-Linux-Rootkit.pdf

https://github.com/elfmaster/kprobe_rootkit

https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-With-Friends-Like-EBPF-Who-Needs-Enemies.pdf

https://www.secureworld.io/industry-news/access-as-a-service-rising-in-popularity

https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/

https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/