开源检测rootkit工具Linux篇--发现隐藏文件、进程和端口

threatexpert

已于 2025-01-22 11:01:53 修改

阅读量848

点赞数 15

文章标签： linux

于 2025-01-21 21:57:22 首次发布

本文链接：https://blog.csdn.net/2504_90382760/article/details/145291229

版权

1.前言

在安全应急响应中，我们接触过Linux系统高级的rootkit木马，常规的终端取证通常不容易检测到它的进程和文件等，因为rootkit在内核的一些位置过滤了一些关于它的信息，并且还防止他人也进去内核去对它取证，如果我们安装驱动模块有可能还触发一些rootkit自毁。但在实践中，我们发现过一些技巧，很多情况下可以不用安装驱动模块，在应用层也能检测出这些高级rootkit隐藏的信息，在这篇文章中，我将分享一些纯粹在应用层检测Linux下被rootkit隐藏的进程、端口、文件的技巧，以及开发完成的工具和完整源代码（见文章底部链接），希望对应急响应同行的小伙伴有帮助。

2.检测原理

2.1 检测隐藏进程

周所周知吧，Linux的进程信息都在/proc/目录下，检测的思路就是在/proc/下，用多种方法盲猜pid，例如，在/proc/下，你ls看不到某个PID，但是通过以下几种方法测试发现似乎存在PID，那么就提示该PID很可能是隐藏进程，以及下可以尝试的一些方法：

kill -0 PID //表示不发送任何信号，仅检查进程是否存在。通过判断返回值可以知道存活状态，如果rootkit没有过滤这种访问方式，它就会暴露。
访问/proc/PID/fd //fd是文件描述符，每个进程都有的目录，或者用cmdline也可以，直接访问判断是否存在。如果rootkit只过滤/proc/目录下它的PID，没考虑你直接访问它的子路径，它就会暴露。
在/proc/下建立一个目录，假如ls时是看不到800这个PID目录的，然后我执行mkdir 800命令，被创建时却被系统提示错误File exists，那它就暴露了。
在/proc/通过cd进去的方式，如果ls时看不到，却能cd进去，那它就暴露了。

等等

rootkit在底层通过过滤各种接口实现隐蔽，但我们在应用层通过暴力枚举pid并各种探测，乱拳打死老师傅。对于rootkit来说，它可能会感觉防不胜防，如果有个地方疏忽了，它就会暴露。

2.2 检测隐藏文件

思路就是自己解析磁盘数据，常见的文件系统类型是ext和xfs。但是我们要尽可能是从底层设备去读取磁盘目录信息，在linux下，以典型的分区情况为例，例如磁盘/dev/sda下有个分区是/dev/sda1，如果要检查的目录是挂载在/dev/sda1分区上的，我们应该从/dev/sda去读取数据来解析目录信息，而不是从/dev/sda1，这样可靠性相对更高。

#lsblk
sda    252:0    0    40G  0 disk
└─sda1 252:1    0    40G  0 part /

例如我们接触过一个rootkit还挺高级的，当在/dev/sda1上解析ext2目录信息时，是找不到这个隐藏文件的，分析发现有一个文件的ext2_dir_entry_2的rec_len被篡改了，

struct ext2_dir_entry_2 {
    __le32  inode;          /* Inode number */
    __le16  rec_len;        /* Directory entry length */
    __u8    name_len;       /* Name length */
    __u8    file_type;
    char    name[];         /* File name, up to EXT2_NAME_LEN */
};

rec_len正常是指向下一个文件的entry结构的，然而被篡改为下下个文件的ext2_dir_entry_2，这样目录信息中就把恶意文件跳过了，然而我们从/dev/sda去找那块扇区的数据时，却可以看到真实的磁盘数据，从/dev/sda才能解析发现这个隐藏文件。如果rootkit作者再花点时间，把从/dev/sda读取的数据也欺骗了，我可能暂时没招了，就看他愿不愿意花这个时间成本了。

虽然上面的思路很清晰，但是实现这块的代码并没用什么捷径，老老实实的写c代码各种解析，感兴趣的请翻阅代码，这里将不展开。

注意，目前分享的工具代码实现不是全盘目录检查，只是检测根目录下的一些关键目录，以及一些bin目录。