1. 事件背景与“紫狐”Rootkit的初次交锋那天下午监控平台的告警突然变得密集起来。几台核心业务服务器的CPU使用率曲线出现了诡异的“毛刺”时高时低同时网络流量监控显示在业务低峰期有服务器持续向一个陌生的境外IP发送加密数据包。直觉告诉我这不是一次普通的性能抖动。登录到其中一台服务器使用top命令查看进程一切似乎“正常”但ps aux命令输出的进程列表末尾有几个进程名看起来像是随机字符串其父进程IDPPID指向了init或systemd这本身就不太寻常。更奇怪的是使用ls -la /proc/[pid]/exe试图查看这些进程的可执行文件路径时竟然返回了“权限不足”或“文件不存在”的错误——对于一个拥有root权限的用户来说这几乎是不可能的。那一刻我心里咯噔一下大概率是碰上Rootkit了。结合告警服务器所在的网段和近期威胁情报一个名字浮出水面——“紫狐”Purple Fox。这不是一个单一的病毒而是一个模块化、持续进化的Rootkit家族近年来在Linux服务器上尤为活跃。它不像那些“大张旗鼓”的勒索病毒而是更倾向于隐蔽驻留、长期窃取数据。其典型特征就是深度隐藏自身进程、网络连接和文件常规命令如ps、netstat、ls甚至lsmod都可能被其劫持返回过滤后的、“干净”的结果这也是为什么我们一开始没从系统命令里直接看出异常。面对这种级别的入侵常规的杀毒软件往往失效必须进行手动的、深入的应急响应和根除。2. Rootkit检测绕过内核钩子与发现隐藏实体当系统命令本身可能不可信时我们的排查必须建立在更底层、更可靠的基础上。第一步就是绕过可能被Rootkit钩住Hook的系统调用和库函数。2.1 使用静态编译的信任工具集在应急响应中一个绝对干净、未被感染的工具集是基石。我立即从一台绝对安全的跳板机上下载了静态编译版本的busybox。静态编译意味着工具的所有运行依赖都打包在同一个二进制文件里运行时不需要加载可能已被篡改的系统动态链接库如libc。# 在安全环境下载静态编译的busybox wget https://busybox.net/downloads/binaries/1.35.0-x86_64-linux-musl/busybox chmod x busybox # 通过安全的SCP或物理介质拷贝到受害服务器 scp busybox root受害服务器IP:/tmp/登录受害服务器后所有后续诊断命令都通过/tmp/busybox来调用例如/tmp/busybox ps aux、/tmp/busybox netstat -tunlp。对比系统自带的ps和busybox的ps差异立刻显现busybox列出了好几个带有随机名、占用CPU但cmdline为空的进程。2.2 直接查询内核进程与网络信息Rootkit通常通过加载内核模块LKM来实现隐藏。因此检查已加载模块是关键。同样使用静态编译的工具/tmp/busybox lsmod在输出列表中我重点关注那些名称看起来无意义如snd_pcm_oss、floppy但服务器并无声卡和软驱、或与已知合法模块名称相似但略有不同的模块。同时直接读取/proc文件系统是另一种绕过钩子的方法。/proc是一个内存文件系统内核会直接将进程、网络等信息映射为文件。# 遍历/proc下的所有数字目录每个目录对应一个进程PID for pid in /proc/[0-9]*; do PID$(basename $pid) # 检查进程的可执行文件链接是否正常 if [ ! -e $pid/exe ]; then echo 可疑PID: $PID, exe链接异常 fi # 查看进程的命令行空或乱码的需警惕 CMDLINE$(cat $pid/cmdline 2/dev/null | tr \0 ) if [[ -z $CMDLINE || $CMDLINE ~ ^[[:space:]]*$ ]]; then echo 可疑PID: $PID, cmdline为空: $CMDLINE fi done对于网络连接直接读取/proc/net/tcp和/proc/net/udp文件。这些文件是纯文本格式固定Rootkit很难在不引起内核崩溃的情况下完全隐藏这里的连接。/tmp/busybox cat /proc/net/tcp | while read line; do # 解析本地地址端口和远程地址端口 # 本地地址是16进制需要转换 LOCAL_ADDR_HEX$(echo $line | awk {print $2} | cut -d: -f1) LOCAL_PORT_HEX$(echo $line | awk {print $2} | cut -d: -f2) REMOTE_ADDR_HEX$(echo $line | awk {print $3} | cut -d: -f1) REMOTE_PORT_HEX$(echo $line | awk {print $3} | cut -d: -f2) # 将16进制IP和端口转换为十进制 LOCAL_IP$(printf %d.%d.%d.%d 0x${LOCAL_ADDR_HEX:6:2} 0x${LOCAL_ADDR_HEX:4:2} 0x${LOCAL_ADDR_HEX:2:2} 0x${LOCAL_ADDR_HEX:0:2}) LOCAL_PORT$((0x$LOCAL_PORT_HEX)) REMOTE_IP$(printf %d.%d.%d.%d 0x${REMOTE_ADDR_HEX:6:2} 0x${REMOTE_ADDR_HEX:4:2} 0x${REMOTE_ADDR_HEX:2:2} 0x${REMOTE_ADDR_HEX:0:2}) REMOTE_PORT$((0x$REMOTE_PORT_HEX)) echo TCP连接: $LOCAL_IP:$LOCAL_PORT - $REMOTE_IP:$REMOTE_PORT done通过这个方法我发现了与告警IP匹配的、在netstat中看不到的TCP连接确认了恶意外联。2.3 文件系统排查与时间线分析Rootkit需要驻留在磁盘上。除了常见的/lib/modules/内核模块、/usr/lib、/bin、/sbin它还可能藏在/dev/shm、/tmp/.X11-unix等临时目录甚至利用mount --bind将自身目录挂载到/proc、/sys的某个子目录下进行隐藏。我使用busybox的find命令结合文件修改时间mtime、访问时间atime和创建时间ctime进行筛选。通常在入侵发生的时间点附近会有大量相关文件被创建或修改。# 查找最近3天内被修改且不属于常见包管理器的文件 /tmp/busybox find / -type f -mtime -3 ! -path /var/lib/dpkg/* ! -path /var/lib/rpm/* ! -path /var/cache/* 2/dev/null | head -50 # 特别关注具有隐藏属性的文件以.开头和目录 /tmp/busybox find / -name .* -type f -mtime -7 2/dev/null一个关键的发现是在/lib/modules/$(uname -r)/kernel/drivers/下多了一个名为video.ko的模块而服务器并没有安装显卡驱动。使用modinfo查看其信息描述字段为空且签名无效嫌疑极大。3. “紫狐”Rootkit的驻留机制与痕迹分析基于排查结果可以拼凑出这个“紫狐”变种的入侵链和驻留方式。3.1 入侵入口点推测检查系统日志/var/log/auth.log,secure发现在异常发生前有大量来自不同IP的SSH暴力破解尝试其中一次成功登录记录对应的源IP与初期外联IP不属于同一个C段但属于同一个已知的恶意IP池。攻击者很可能通过弱口令或未修复的漏洞如某个Web应用的RCE获得了初始立足点。3.2 Rootkit安装与隐藏攻击者获取root权限后通常会下载Rootkit安装包。在/var/tmp和/dev/shm目录下我发现了已被删除但通过lsof命令仍能看到被进程占用的.tgz文件残留句柄。安装脚本大致会执行以下操作编译内核模块根据当前内核版本动态编译隐藏模块如上述的video.ko。注入模块使用insmod加载模块。该模块会挂钩hook关键的sys_call_table中的函数如getdents64用于读取目录、read用于读取/proc文件、kill防止被杀死等。部署用户态后门将木马程序即那些随机名进程拷贝到隐藏目录如/etc/.cache并赋予可执行权限。设置持久化rc.local/systemd服务在/etc/rc.local或/etc/systemd/system下创建伪装的服务单元确保重启后能自动加载内核模块和启动后门。cron任务添加定时任务定期检查Rootkit状态如果被清除则重新下载安装。SSH后门可能修改sshd的PAM模块或直接替换ssh/sshd二进制文件留一个密码或密钥后门。3.3 发现的特定痕迹除了通用的Rootkit特征这个“紫狐”变种还留下了几个特殊痕迹进程名伪装其用户态进程会伪装成[kworker/uX:Y]或[migration/X]这样的内核线程名但在/proc/[pid]/stat中其进程状态字段是S睡眠或R运行而真正的内核线程通常是I空闲或D不可中断睡眠。这是一个重要的识别点。网络通信加密外联流量并非明文而是使用了简单的XOR或RC4流加密。通过分析/proc/[pid]/fd目录发现可疑进程打开了网络套接字并使用strace同样需静态编译版本附加到进程捕获到其对libssl或自定义加密函数的调用。配置文件隐藏在/etc目录下发现一个名为...三个点的目录常规ls命令不显示但ls -la可以看到。该目录内包含了C2服务器的配置和收集的数据缓存。4. 根除与恢复谨慎移除与系统加固在确认了所有恶意组件后根除行动必须迅速且谨慎避免触发Rootkit的自毁或反清除机制。4.1 清除步骤在单用户模式或救援模式下进行注意以下操作风险极高务必在已做好完整系统备份或快照的前提下进行。建议先在隔离的测试环境模拟。阻断网络首先断开服务器对外网络防止清除过程中数据继续外泄或C2服务器下发破坏指令。/tmp/busybox iptables -P INPUT DROP /tmp/busybox iptables -P OUTPUT DROP /tmp/busybox iptables -P FORWARD DROP终止恶意进程对于深度隐藏的进程直接向/proc/[pid]/status文件写入kill信号可能无效。最粗暴但有效的方法是使用kill -9 [pid]但需注意其可能关联了多个进程。更好的方法是先卸载其内核模块使其失去隐藏能力再用busybox ps找到并杀死。# 尝试卸载可疑内核模块需在模块未被占用时 /tmp/busybox rmmod video 2/dev/null || echo 模块可能正在使用需先杀进程 # 再次用busybox ps查看并杀死 for pid in $(/tmp/busybox ps aux | grep -E kworker/u|migration|随机字符串 | awk {print $2}); do /tmp/busybox kill -9 $pid done删除内核模块文件/tmp/busybox rm -f /lib/modules/$(uname -r)/kernel/drivers/video.ko # 更新模块依赖 /tmp/busybox depmod -a删除用户态文件根据之前find的结果删除所有相关的可执行文件、配置文件和临时文件。/tmp/busybox rm -rf /etc/... /etc/.cache /var/tmp/.xxx /dev/shm/.yyy # 特别注意检查并清理/tmp和/var/tmp下所有非常规文件清理持久化项目检查/etc/rc.local、/etc/rc.d/rc.local删除可疑的启动命令。检查/etc/systemd/system/和/usr/lib/systemd/system/下是否有新增的、描述可疑的.service文件。清理cron任务/tmp/busybox crontab -l查看当前用户并检查/etc/crontab、/etc/cron.d/、/etc/cron.hourly/daily/weekly/monthly/以及/var/spool/cron/目录下的所有文件。使用rpm -Va或dpkg --verify检查系统命令是否被篡改如果ssh、sshd、netstat、ps、ls等关键命令的哈希值不匹配应从干净的安装介质或同版本系统中恢复。重启并验证完成清理后重启服务器进入正常模式。再次使用静态编译的busybox或从干净介质启动进行全盘检查确认无残留进程、模块和网络连接。4.2 系统加固与后续监控根除不是终点防止再次入侵才是关键。漏洞修补立即更新操作系统和所有应用软件到最新版本修补SSH弱口令和Web应用漏洞。最小权限原则为应用和服务创建专用低权限用户禁用root的SSH直接登录使用密钥认证并限制可登录IP。文件完整性监控部署如AIDE、Tripwire等工具建立系统文件的基准哈希值定期检查变更。入侵检测系统部署网络IDS如Suricata和主机IDS如OSSEC监控异常网络流量和系统调用。加强日志审计确保所有认证日志、系统日志被完整记录并发送到远程安全的日志服务器SIEM避免本地日志被攻击者擦除。定期安全评估建立常态化的漏洞扫描和渗透测试机制。5. 从应急响应中提炼的实战心得这次与“紫狐”的交手让我对Linux Rootkit的应急响应有了更深的理解也积累了几条宝贵的经验。第一永远不要相信被入侵系统的输出。这是铁律。在怀疑系统被植入Rootkit的那一刻起所有基于该系统自身命令和库的检查结果都应被视为“可能被污染”。第一时间引入外部可信工具静态编译的busybox、从光盘或USB启动的救援系统是打破信息不对称的关键。第二/proc和/sys文件系统是宝库。内核为了向用户空间提供信息必须将这些信息映射成文件。Rootkit可以钩子系统调用但要完美地、无痕地篡改所有这些虚拟文件的内容难度极大成本很高。因此直接读取/proc/[pid]/下的各种文件、/proc/net/tcp、/sys/module/等往往能发现被隐藏的真相。例如通过对比/proc/[pid]/exe指向磁盘文件和/proc/[pid]/root进程的根目录视图有时能发现chroot隐藏的手法。第三关注时间线和异常行为而非仅仅静态特征。Rootkit的进程名、文件名可以随机变化但它的行为模式相对固定定时外联、隐藏自身、维持权限。因此在监控中除了看“有什么”更要看“在干什么”。异常的定时任务、在非业务时间出现的网络连接、与已知恶意IP的通信、/etc下目录的异常修改时间这些动态行为特征比一个具体的病毒文件名更有价值。第四清除工作务必在隔离环境下进行并准备好“回滚”方案。在线上环境直接操作如同排雷一步错可能导致系统无法启动或数据丢失。务必先做完整的磁盘快照。如果条件允许最好将受害磁盘挂载到干净的救援系统上进行离线查杀和文件删除这样能完全避免Rootkit在内存中的反制。第五应急响应报告要详细但根除后的加固更重要。很多团队在清除完恶意代码、业务恢复后应急响应就结束了。实际上找出入侵根源是弱口令、未授权访问还是漏洞、修补它、并实施一系列加固措施如上述的监控、审计、最小权限才能避免在同一个地方跌倒两次。这次事件最终推动我们完善了整个服务器的基线安全配置和主动监控体系可以说危机也带来了安全升级的契机。
