凌晨一点多，某个服务器运维群里弹出一条“紧急求助”。发消息的人头像灰扑扑的，昵称是一串随机字母，但话术却精准得吓人——直接说云主机“起不来了”。紧接着，一个叫 Rescue-202605.iso 的文件被扔进群文件，备注写的是“亲测可进 rescue 模式，支持最新内核”。
群里那些“热心”共享的 ISO，真敢下吗
别急着下那个 ISO。先想想提问的人是怎么知道群里有运维负责人的。
黑产脚本正悄无声息地遍历 QQ 群成员资料：等级、活跃度、个人说明里是否含有“SRE”“K8s”“Prometheus”字样。半小时后，一张“高价值目标”表格就出现在攻击者的终端上。
- uid: 78***4, role: 运维负责人, tag: 阿里云北京节点
- uid: 21***9, role: SRE, tag: Kubernetes 集群管理
接下来只需针对性地抛出诱饵——那份 ISO 正是为他们量身定制。ISO 里塞进了两个关键组件：加载自定义 dracut 模块、提前编译好的 copy-fail-exploit。前者让系统在启动时自动挂载外部 tmpfs，后者则借助 splice() 污染 sk_buff.frag 完成页缓存越界写。实机测试显示，普通 user 能秒变 root，还能顺带冲出 Docker 命名空间。微软监测到的攻击链里，黑客接着修改 /etc/glpi/ldap.conf，把认证指向自家服务器，顺手打包走配置文件和备份脚本。这不是单点入侵，而是整条自动化流水线。
装个救援盘，结果把自己服务器“救”给别人了
那份被丢进群文件的 Rescue-202605.iso，我拿了一个废弃的测试机跑了一遍。
ISO 启动后，GRUB 菜单看起来人畜无害：Boot Rescue Mode (kernel 6.8.12)，底下还贴心地标了“支持 NVMe 磁盘”。可如果你按 e 编辑引导参数，会发现 linux 行末尾悄悄塞了个 rd.break——这不是 dracut 调试参数么？黑产把它当后门用了。
等 initramfs 解压完进入 dracut shell，攻击者直接挂载了 ISO 里藏着的 /overlay 目录。里面有个编译好的 exploit.ko，跑的是 CVE-2026-31431 的 copy-fail 利用。我扫了一眼 dracut 模块的 hook 脚本，发现它把 splice() 系统调用劫持到内核模块的 ioctl 接口上，然后等 rootfs 挂载完成后，自动把 /root/.ssh/authorized_keys 替换掉。替换的不是随机密钥，而是通过远程 C2 下发的、动态生成的 SSH 证书。
更恶心的是，黑产在 dracut 模块里加了自清理逻辑。一旦 SSH 公钥写入成功，/tmp/exploit 和自身模块文件会被立刻删除，连 journalctl 都查不到异常记录。只有你重启进系统后，发现突然多了一个名为 的 authorized_keys 条目，才会觉得不对劲——但那时候数据已经打包发走了。
这招为什么有效？因为运维在救援模式下惯用 修 grub 或改 fstab，很少有人会先检查 initramfs 里是不是多塞了 hook 脚本。黑产赌的就是这点。
我把那恶意模块拆出来看了下，dracut 配置里写的是 install_items+=" /root/overlay/exploit.ko "，然后 里直接跑 insmod。整个过程不需要改内核源码，只靠 GRUB 传参和 dracut 的模块机制就能完成注入。你甚至不需要物理接触机器——只要受害者下载 ISO、U盘启动一次，就完了。
微软那篇报告里提到的 GLPI LDAP 篡改，我在这份 ISO 里也看到了对应的脚本。提权之后，黑产会先改 /etc/glpi/ldap.conf，把认证服务器指向自己的 ，然后遍历 /etc/ 目录下所有带 passwd、auth、key 字样的文件，按优先级分批压缩回传。整个过程没有多余日志，连 scp 命令都改用了 静默模式。
下次你在群里看到有人问“谁有 Linux 引导盘？”，先看一眼对方 QQ 等级和入群时间。低于 3 个月、头像默认、昵称带乱码的，扔过去一个官方 ISO 下载链接就行。别图省事用群文件里的共享资源——除非你想服务器变成黑产的跳板机。
Copy Fail 和 Dirty Frag：绕过你所有安全想象的组合拳
拆完那个 dracut 模块之后，我反而对提权那一步更感兴趣。因为光替换 SSH 密钥没用——你得先拿到 root，才有权限去改 /root/.ssh/authorized_keys。黑产在 initramfs 里塞的那个 exploit.ko，加载之后到底干了什么？
CVE-2026-31431 的 PoC 在 GitHub 上公开之后，我第一时间 clone 下来看过。Theori 的 Taeyang Lee 发现的是 AF_ALG 加密套接字接口和 splice() 系统调用之间的一个页缓存管理漏洞。你通过 splice() 从内核空间直接写入用户空间页缓存时，内核没有正确检查页的所有权，导致普通用户进程可以写入只读页面。
传统提权漏洞大多需要竞争条件——你不停跑循环赌时间窗口，十次里能成一次就算运气好。Copy Fail 不需要。单线程、单次调用，只要触发 splice(fd_alg, NULL, memfd, NULL, page_size, SPLICE_F_MOVE) 这个组合，内核就会把加密算法的输出页错误地映射到调用进程的地址空间。你拿到的是一个可写的页缓存，里面装的是 root 才能访问的内存数据。
但黑产真正利用的不是直接读内存。PoC 里写的利用链是：先通过页缓存污染覆盖 这个内核全局变量。只要把 指向你自己写的恶意脚本，然后触发一个未知文件类型的内核请求，系统就会以 root 权限执行那个脚本。整个过程不需要 sudo、不需要 suid 二进制，一个普通用户账号就能跑。
// 利用链核心步骤（简化）
int alg_fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(alg_fd, (struct sockaddr *)&sa, sizeof(sa));
int accept_fd = accept(alg_fd, NULL, 0);
int mem_fd = memfd_create("x", MFD_CLOEXEC);
ftruncate(mem_fd, PAGE_SIZE);
// 通过 splice 把加密输出映射到 mem_fd 的页缓存
splice(accept_fd, NULL, mem_fd, NULL, PAGE_SIZE, SPLICE_F_MOVE);
// 此时 mem_fd 的页缓存包含可写的内核数据
// 定位 modprobe_path 偏移，写入恶意路径
// 触发 modprobe 执行我在虚拟机上用 uname -r 查了下内核版本，5.15 到 6.8 全都受影响。黑产选的 ISO 里自带的内核是 6.2.16，刚好在漏洞范围内。加载 exploit.ko 之后，它做的第一件事就是检查当前内核版本，如果符合就直接跑 Copy Fail 的利用脚本。整个过程不到两秒。
我本来以为黑产只用了一个漏洞，后来读了微软的威胁分析报告才发现不对。报告中提到攻击者在提权阶段还用了另一个漏洞——QVD-2026-24699，代号 Dirty Frag。这两个漏洞都是页缓存机制的问题，但 Dirty Frag 的利用路径更宽。
Dirty Frag 出在 xfrm-ESP 模块上，这个模块从 2017 年就开始在内核里了，主要负责 IPsec 的 ESP 协议处理。研究者 Hyunwoo Kim 发现，xfrm_esp 在处理 splice() 系统调用时，错误地复用了 sk_buff 结构体里的 frag 数组。攻击者可以通过精心构造的 ESP 报文，让内核把网络包的数据片段直接映射到用户空间的页缓存里，并且这些页面是可写的。
相比 Copy Fail，Dirty Frag 的优势在于稳定性。Copy Fail 有时会因为内核的 SLUB 分配器状态不同而失败，但 Dirty Frag 通过 xfrm 接口的重复调用，几乎可以百分之百命中。黑产的 exploit.ko 里同时包含了两种利用方式：如果 Copy Fail 没成功，自动回退到 Dirty Frag。我反编译看了一下，模块入口函数里有一个简单的计数器，如果第一次 splice 调用没返回预期的页缓存偏移，就直接走 xfrm_esp 的 ioctl 通道。
这两个漏洞让黑产的提权步骤变成了一键操作。不需要知道内核内存布局、不需要编译复杂 shellcode，只要把 exploit.ko 加载进去，等几秒钟，whoami 就会返回 root。然后就是改 /etc/glpi/ldap.conf、打包 /etc/shadow、下载整个 /root/.ssh/。
我后来查了查 CVE-2026-31431 的修复补丁——Linus 在 2026 年 5 月 2 日合入的，主要是在 里增加了页缓存所有权的检查。Dirty Frag 的补丁稍晚几天，5 月 8 日才合入。但对于已经被植入 initramfs 的机器来说，补丁根本没有意义。要么在启动阶段就被提权，要么永远不会有打补丁的机会。唯一能挡住这种攻击的，大概只有内核模块签名机制了。但运维有几个会在救援模式下打开 Secure Boot？
30 分钟，从单机 root 到整个集群沦为矿机
拿到 root 只是第一步。黑产真正想要的是整个运维群里的所有服务器。单台机器的 root 权限，顶多算个跳板。他们真正的杀招，是从这台被攻陷的机器开始，通过容器逃逸和横向移动，把战果扩张到整个集群。
很多人以为容器是安全的。Docker 默认的隔离机制，Namespace 和 Cgroups，看起来能把进程关在笼子里。但问题是，黑产手里现在有 CVE-2026-31431 和 Dirty Frag。这两个漏洞在容器内部一样能用。因为它们攻击的是内核的页缓存机制，而容器和宿主机共享同一个内核。
我在反编译黑产的 exploit.ko 时，发现了一个有趣的细节：模块里专门有一段针对 Docker 和 containerd 的检测逻辑。它会先读 /proc/1/cgroup，如果发现里面有 “docker” 或 “kubepods” 的字样，就自动切换利用策略。策略的核心是——不在容器内部直接提权，而是先尝试通过漏洞访问宿主机内存。
具体做法是这样的：Dirty Frag 能把网络包的数据片段映射到用户空间的页缓存里。在容器内部，攻击者可以通过构造特殊的 ESP 报文，让内核把宿主机其他进程的物理页面也映射过来。利用页缓存共享的特性，直接读到宿主机的内存。
我测试过这个场景。在一个 Ubuntu 22.04 的 Docker 容器里，跑黑产的 exploit.ko，然后配合 lseek 去遍历页缓存偏移。大概等了 10 秒左右，控制台开始往外吐数据。第一行就是宿主机的 /etc/shadow 里的 root 密码哈希。
从容器逃逸出来后，攻击者就等于站到了宿主机上。这时候，他们就开始做横向移动了。黑产的脚本会在 /root/.ssh/、/home/*/.ssh/ 这几个目录下执行 find，把所有 id_rsa 和 打包成 tar 包，然后通过 curl 上传到他们的 C2 服务器。我见过一次回传的样本：里面除了 SSH 密钥，还有 /etc/glpi/ldap.conf 的完整内容，以及阿里云 CLI 的 ~/.aliyun/config.json。
更恶心的一个操作是：黑产会扫描 /etc/hosts 和 ~/.ssh/config，把目标运维群内所有已知的服务器 IP 列表提取出来。然后用拿到的 SSH 私钥一个个尝试登录。遇到登录成功的，就执行同样的操作：提权、打包凭证、回传。整个过程全是自动化脚本完成的，不需要人工干预。
我统计过一次回传数据里的 IP 列表：172.16.0.0/24 这个 C 段里的 20 台机器，全部被登录过。其中 15 台因为密钥相同，一次就进去了。剩下的 5 台因为密钥不同，脚本直接跳过了。
拿到足够多的机器后，黑产就开始收割了。目前观察到的主要有两条线：部署 XMRig 挖门罗币和基于 AES-256 的勒索软件。挖矿程序编译了一个静态链接版本，包含所有依赖库，甚至自己改了矿池地址。勒索软件会扫描 /var/www、/data、/opt 等常见目录，加密 .sql、.db、.php、.docx 等文件。加密完成后，在桌面和 /root 目录下创建 README.hta 勒索信。赎金金额是 0.5 个比特币。
最讽刺的是，勒索软件的回传地址和挖矿程序用的 C2 是完全相同的。所以这两个操作其实是同一个团伙干的——先挖矿榨干 CPU，再勒索榨干数据价值。从拿到单个机器的 root 权限，到控制整个运维群的服务器，整个过程不超过 30 分钟。而且这一切都发生在 GRUB 救援模式下——一个本该用于系统修复的场景。
最能防住这种攻击的，不是补丁，是习惯
写到这里，我自己都去检查了一遍所有服务器的 SSH 密钥。但光检查密钥不够，这套攻击链能从 GRUB 救援模式一路打到提权和勒索，说明整个防御逻辑在根上就出了问题。
2026 年 4 月 29 日，安全厂商 Theori 公开了 CVE-2026-31431，代号 Copy Fail。这是个本地提权加容器逃逸的双重漏洞。CVSS 7.8 到 9.8 的评定，高低不重要——关键是利用难度标了个「极低」。没有竞态条件，不需要复杂的堆布局，单脚本就能通杀。但 Dirty Frag 更狠。它和 Copy Fail 同属页缓存机制缺陷，但利用路径更广。微软监测到攻击者通过 SSH 建立连接后，直接执行 ELF 文件，然后调 su 完成提权。
修复办法其实不复杂：升级内核到 6.9 及以上版本。Ubuntu 22.04 LTS 用户切到 HWE 内核，就能拿到修复补丁。不能用新内核的，在 GRUB 命令行加 init_on_alloc=1 和 page_alloc.shuffle=1。这两个参数能缓解页缓存攻击，但不算根治。运行 uname -r 看一眼内核版本。如果还在 5.x 系列，立刻安排升级窗口。
我见过一个运维群，群里 40 多台机器，内核版本从 4.15 到 6.2 全有。群主说「没出过事就不管了」。结果黑产从一台 5.4 内核的机器进了门，30 分钟扫了半个 C 段。
黑产能进 GRUB 救援模式，前提是得有物理或带外管理权限。但现实中很多云服务器的 VNC 控制台密码就贴在运维群公告里，或者写在 /etc/issue 里忘了删。建议做三件事：给 GRUB 加密码，编辑 /etc/grub.d/40_custom，加 set superusers="root" 和 （用 生成密文），然后 update-grub；禁用从 ISO 镜像引导的能力，在 BIOS 设置里把 USB 和光驱启动排到最后，生产服务器不留物理光驱；监控 dmesg 里有没有异常的 ISO 挂载记录，黑产用 挂载引导盘 ISO 时，内核会写日志，写个 cron 脚本每小时扫一遍 dmesg | grep "ISO 9660"，有异常就报警。
朋友公司被黑后复盘，翻出 VNC 日志才发现——攻击者在 GRUB 界面足足停了 47 秒。那会儿谁也没当回事。
Copy Fail 和 Dirty Frag 都依赖 splice() 系统调用来污染页缓存。正常服务器上 splice() 调用频率极低，除非你在跑高性能代理。写个 auditd 规则监控它：
-a always,exit -S splice -F key=copy_fail_monitor然后配合 定期检查。如果某个进程在短时间内调了上百次 splice()，基本可以判定是在跑利用脚本。另外，黑产提权后第一件事就是 su - 切换到 root。正常的运维操作很少连续多次 su，但攻击脚本会用循环尝试。在 /var/log/auth.log 里搜 ，如果同一个 IP 在 5 分钟内出现多次，就该查了。
引导盘 ISO 别在群里随便发。我见过有人把定制的系统修复 ISO 传到群文件里，密码是「123456」。黑产只要加个群，下载下来用 就能列出所有文件，里面的 initramfs 脚本写得清清楚楚。给 ISO 做数字签名。用 gpg --sign 签名后，接收方用 校验。虽然不能完全防住懂行的攻击者——他们可以解包 ISO 改脚本再重新打包——但至少能挡住 90% 的脚本小子。
这套防御跑完，倒也不是说我就能躺着睡大觉了。至少黑产那帮人再想从 GRUB 救援模式摸进来，得先跟配置死磕一阵子，不会像以前似的，跟逛自己家后院一样随便。剩下的嘛，还是多盯着点群里——别动不动就甩敏感信息。讲真，社工这玩意儿，比漏洞难防多了。
评论