Kaiji僵尸网络相对老版本代码被重构，函数功能更加聚焦，函数名不再采用中式拼音命名。最新的版本驻留功能非常强大，增加了多种持久化手段，但是传播模块相对较弱，这里猜测一下，作者正在逐渐更新功能模块，该病毒很可能会随着时间的推移进一步变得更加复杂，未来Kaiji或许会成为一款强大的僵尸网络。

生成shell脚本/etc/32678（传播模块为32679），定时执行/etc/id.services.conf：

通信模块执行时，与C2服务器103.138.80.90:1111、dark1998.f3322.org:8080、156.96.156.105:8080进行通信，发送上线信息后，由main_receive函数等待接收并执行ipbegin、ipend、finish、unload、shell、reverse、remarks、http、ipspoof、tcp、udp、syn、tap等命令，包含执行shell命令、卸载自身、发动DDoS攻击等功能。

传播模块[main_Sshboom函数]

在老版本的Kaiji僵尸网络会窃取本地SSH密钥，进一步发起SSH爆破攻击，爆破成功后会下载执行相应CPU架构的驻留模块，例如：103.138.80.90:808/808/linux_amd64、linux_arm64、linux_mips。最新版本的Kaiji僵尸网络缺少传播模块功能，这里猜测作者正在逐一优化功能模块。

持久化模块[main_Initetc函数]

通过修改/etc/rc.local、/etc/rc.d/rc.local、/etc/init.d/boot.local文件实现自启动

利用chkconfig工具添加linux_kill服务，实现自启动

注册linux.service

安装SELinux策略模块

修改/etc/profile.d/bash_config.sh复制自身到/usr/lib/libdlrpcld.so添加定时任务，每隔一分钟执行/.img

替换dir、find、ls、lsof、netstat、ps、ss七个工具

尝试将自身进程名伪装为ksoftirqd/0

https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/

Kaiji僵尸网络相对老版本代码被重构，函数功能更加聚焦，函数名不再采用中式拼音命名。最新的版本驻留功能非常强大，增加了多种持久化手段，但是传播模块相对较弱，这里猜测一下，作者正在逐渐更新功能模块，该病毒很可能会随着时间的推移进一步变得更加复杂，未来Kaiji或许会成为一款强大的僵尸网络。

生成shell脚本/etc/32678（传播模块为32679），定时执行/etc/id.services.conf：

通信模块执行时，与C2服务器103.138.80.90:1111、dark1998.f3322.org:8080、156.96.156.105:8080进行通信，发送上线信息后，由main_receive函数等待接收并执行ipbegin、ipend、finish、unload、shell、reverse、remarks、http、ipspoof、tcp、udp、syn、tap等命令，包含执行shell命令、卸载自身、发动DDoS攻击等功能。

传播模块[main_Sshboom函数]

在老版本的Kaiji僵尸网络会窃取本地SSH密钥，进一步发起SSH爆破攻击，爆破成功后会下载执行相应CPU架构的驻留模块，例如：103.138.80.90:808/808/linux_amd64、linux_arm64、linux_mips。最新版本的Kaiji僵尸网络缺少传播模块功能，这里猜测作者正在逐一优化功能模块。

持久化模块[main_Initetc函数]

通过修改/etc/rc.local、/etc/rc.d/rc.local、/etc/init.d/boot.local文件实现自启动

利用chkconfig工具添加linux_kill服务，实现自启动

注册linux.service

安装SELinux策略模块

修改/etc/profile.d/bash_config.sh复制自身到/usr/lib/libdlrpcld.so添加定时任务，每隔一分钟执行/.img

替换dir、find、ls、lsof、netstat、ps、ss七个工具

尝试将自身进程名伪装为ksoftirqd/0

https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/

序言

从西方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 技术的发展历程和Windows、Linux平台下的 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 技术的发展历程和Windows、Linux平台下的 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/