--- title: "群晖 NAS 突发 C3RB3R 勒索病毒，最新 DSM 7.4.1 中招真相与内存提取密钥自救指南" url: "https://afengblog.com/blog/synology-nas-c3rb3r-ransomware-rescue-guide.html" author: "AFeng" published: "2026-10-29T12:06:12.150Z" updated: "2026-10-29T14:14:05.704Z" category: "工具与效率" tags: ["PHP2Shell","网络安全","群晖 NAS","勒索软件","数据恢复"] reading_time: "21 分钟阅读" description: "2026年10月群晖NAS突发C3RB3R（.L0CK3D）勒索病毒大规模攻击。深度拆解CVE-2024-10441、CVE-2026-13684与PHP2Shell三大高危入口，揭秘最新DSM 7.4.1与开启两步验证仍中招的原因，并提供不断电从内存提取密钥免费恢复数据及防御加固指南。" --- # 群晖 NAS 突发 C3RB3R 勒索病毒，最新 DSM 7.4.1 中招真相与内存提取密钥自救指南 > 2026 年 10 月底，全球多地群晖 NAS 遭遇 C3RB3R 勒索病毒集中攻击，文件被加密为 .L0CK3D 后缀并留下 read-me3.txt 勒索信。结合安全团队报告与 LINUX DO 社区一线救灾实录，完整拆解三大无须认证的漏洞入侵入口、最新 DSM 7.4.1 中招背后的定时任务潜伏机制，以及刚发现中招时不断电从运行内存提取 48 字节主密钥实现 100% 免费无损恢复数据的实操指南。 ## TL;DR（太长不看） - 刚中招千万别拔电源或重启，解密所需的 48 字节主密钥就在运行内存里，立刻断外网、用 SSH 暂停加密进程并导出内存，已有用户靠开源工具 100% 免费救回全部数据 - 开两步验证和改端口防不住，黑客利用的是无需登录的认证前高危漏洞（如 CVE-2024-10441 与 CVE-2026-13684），只要把群晖 Web 界面暴露在 IPv4 或 IPv6 公网就会被直接拿走 root 权限 - 升到最新 DSM 7.4.1 依然中招，多是因为升级前已被植入 /etc/cron.d/ 定时任务后门，或者忽略了升级套件中心里的 PHP、日历等高危套件 - 今晚必做四步保命操作，立刻在路由器关闭端口转发、UPnP 与 IPv6 入站，改用 Tailscale 或 WireGuard 组网，排查系统定时任务，手动升级补丁并开启 Btrfs 不可变快照与离线冷备 ![群晖 NAS 遭遇 C3RB3R 勒索病毒安全预警与内存提取密钥自救指南封面图](https://afengblog.com/uploads/2026/10/40abc4de2b1a7fab934508db.webp) ## 一夜沦陷，当群晖 NAS 风扇狂转且所有文件变成 .L0CK3D 2026 年 10 月 28 日下午至 29 日凌晨，国内外各大技术社区突然涌现大量群晖 NAS 用户的受灾求助。无论是个人家庭相册、企业备份服务器，还是运行了数年的私有代码库，都在毫无征兆的情况下被批量加密锁定。 在 [LINUX DO 社区的预警讨论帖](https://linux.do/t/topic/3089697)中，有用户深夜听到床边的 DS918+ 风扇异常狂转，打开后台才发现 Cloud Sync 正在向异地网盘疯狂同步名为 `read-me3.txt` 的文件。还有用户发现 NAS 里的 Docker（Container Manager）被直接卸载，8TB 乃至数十 TB 的文档、照片与同机备份全部被追加了 `.L0CK3D`（部分显示为 `.LOCK3D`，含数字 0 和 3）扩展名。 根据 [360 反勒索团队](https://360.cn/n/13055.html)与 [Solar 应急响应团队](https://bbs.kanxue.com/thread-293361.htm)的样本分析，本次肆虐的真凶是老牌勒索软件家族 Cerber 的现代 Linux 变种 **C3RB3R**。每个被加密目录下生成的 `read-me3.txt` 勒索信中均带有 `C3RB3R INSTRUCTIONS` 标识与 6 位专属设备 ID，引导受害者通过 Tor 浏览器访问暗网自助站点。 该暗网站点已实现高度自动化运营，允许受害者免费上传 1 个小于 1024 KB 的 `.L0CK3D` 文件进行试解密，以此证明攻击者手握解密能力。页面会自动生成专属比特币收款地址，索要赎金 **0.085 BTC**（若超过 5 天未支付则翻倍至 **0.17 BTC**），并宣称在区块链交易完成 6 次确认后即可刷新下载解密器。 ![C3RB3R 勒索软件加密群晖 NAS 文件为 .L0CK3D 后缀及自动化暗网赎金流程示意图](https://afengblog.com/uploads/2026/10/af24e2a9b1b4c9383deb7b3b.webp) --- ## 黄金一小时自救，如果刚中招千万不要慌乱拔电源 在以往的勒索病毒处置中，许多人的第一反应是“立刻拔掉电源线或强制关机”。但在本次群晖 C3RB3R 事件中，**盲目断电重启反而会亲手毁掉唯一免费恢复全部数据的机会**。 根据受灾现场的只读取证，攻击脚本会从 `hxxp://46[.]8[.]78[.]122/xdy5.sh` 拉取针对不同 CPU 架构（支持 `x86_64`、`aarch64`、`armv7l`）的 UPX 加壳 ELF 二进制程序。程序通常伪装成 `/bin/libgld`（带参数 `-n 308` 启动）或 `/bin/qnetd`（带参数 `153` 启动），并在扫描时跳过 27 个系统关键目录以防系统崩溃中断加密，对 187 种常见扩展名实施全文件加密。 逆向工程显示，C3RB3R 对每个文件生成独立的 32 字节密钥与 8 字节 nonce 进行 **ChaCha8** 对称加密，并在文件末尾固定追加 **588 字节**的尾部数据（Footer）。这 588 字节中包含一段 48 字节的密钥记录，它是由当前加密会话生成的 **AES-256-CBC 主密钥**加密保护的，而这把最关键的会话主密钥在加密过程中就明文驻留在系统内存（RAM）里。 ![C3RB3R 勒索病毒 ChaCha8 文件尾部 588 字节结构与运行内存驻留 48 字节 AES-256-CBC 主密钥解密原理图](https://afengblog.com/uploads/2026/10/8587f98c2355f3300ca9dd94.webp) 来自 LINUX DO 社区的开发者 `@soimy`（V2EX ID `Mayday9421`）在[群晖 DSM+GitLab CE 救灾直播贴](https://linux.do/t/topic/3085082)中完成了一场教科书级的绝地自救。他在发现 PVE 虚拟机中的群晖遭遇加密后，第一时间切断公网但**没有关机**，而是通过本地 SSH 挂起（暂停）了正在运行的 `libgld` 加密进程，并导出了 16 GiB 的完整内存镜像（RAM Dump）。 随后他借助 AI 辅助与 Ghidra 反编译，顺着虚拟地址 `0x5427f8` 指向的 `0x130fa00` 内存区域，成功提取出 16 字节 IV 与 32 字节 AES-256-CBC 主密钥（共 48 字节会话材料）。利用这把从内存中抢救出的主密钥，他直接解开了文件尾部 588 字节里的 ChaCha8 文件密钥，**100% 逐字节无损恢复**了过去 5 年积累的 49 GiB GitLab 代码仓库备份与设计文档。 目前 `@soimy` 已将完整的取证流程、AI 提示词与解密脚本开源至 GitHub 仓库 [soimy/c3rb3r-rescue](https://github.com/soimy/c3rb3r-rescue)，在 LINUX DO 社区与 GitHub Issues 中已有其他未关机的受害者（如 `@xkkk_er`、`Benajaminzm`）借此成功解开数据。如果你发现设备正在被加密或刚刚加密完成，请严格按照以下顺序操作： 1. **立刻拔掉外网网线或在路由器端阻断该 NAS 的所有外网连接**，防止脚本回传或二次破坏，但务必保留局域网连接与设备电源。 2. **切勿重启、切勿关机、切勿直接 `kill -9` 杀死可疑进程**，一旦进程终止或断电，内存中的易失性密钥将永久丢失。 3. **打开本地 SSH 登录群晖**，使用 `kill -STOP ` 冻结可疑加密进程（如 `libgld` 或 `qnetd`），阻止其继续加密剩余文件并锁死进程内存空间。 4. **立即导出内存与二进制样本**：虚拟机用户可直接在宿主机（如 PVE / ESXi）对虚拟机执行内存转储，物理机用户可通过 `/proc//mem`、AVML 或 LiME 采集进程与整机内存，再参照 [soimy/c3rb3r-rescue](https://github.com/soimy/c3rb3r-rescue) 提取密钥。 ![群晖 NAS 遭遇勒索软件攻击后的黄金一小时不断电自救四步流程图](https://afengblog.com/uploads/2026/10/bbc0a95dc491707a646386b9.webp) 如果设备已经不幸断电重启，内存密钥路径便已失效，此时请立即停机避免任何磁盘写入或数据擦除（Data Scrubbing）。用户可尝试将硬盘挂载为只读模式，检查是否有残存的 Btrfs 历史快照，或寻求专业救援机构尝试通过 Btrfs 写时复制（CoW）历史元数据树（B-Tree）扫描未被覆盖的旧数据块。 --- ## 深度溯源，黑客到底是怎么进来的 围绕本次大规模攻击的入侵入口，安全厂商与一线极客给出了不同维度的分析，综合多方取证事实来看，这是一场利用**多漏洞武器库（Exploit Kit）对公网暴露群晖进行的无差别收割**。 ![群晖 NAS 遭遇 C3RB3R 勒索攻击的三大高危漏洞入口对比解析图](https://afengblog.com/uploads/2026/10/114493d9b216faa68128dead.webp) ### 入口一，CVE-2024-10441（底层日志证实的头号元凶） 尽管这是一个 2024 年底修补、2025 年 3 月公开细节的漏洞（详见官方公告 [Synology-SA-24:20](https://www.synology.com/ja-jp/security/advisory/Synology_SA_24_20)），但它在本次事件中被证实遭到了最广泛的自动化利用。包括 LINUX DO 社区的 `@soimy`、V2EX 受灾用户以及海外 Reddit `/r/synology` 用户 `u/NakamuraHwang` 在对残留的 `/var/log/auth.log.L0CK3D` 与内存日志取证时，均发现了完全一致的攻击痕迹。 该漏洞（CVSS 评分 9.8 分）存在于 DSM 系统插件守护进程 `synoplugind` 中，属于无需登录认证的远程代码执行漏洞。攻击者只需向群晖 WebAPI 登录接口（`/webapi/entry.cgi`）发送一条包含 `PLUGIN_VALUE_END`、`LD_PRELOAD` 与 `LD_DEBUG_OUTPUT` 环境变量注入的恶意登录请求。 哪怕页面返回“密码错误、登录失败”，注入的指令依然会以 `root` 权限在后台被解析执行，直接向 `/etc/cron.d/` 写入形如 `synotade.` 的恶意计划任务。大量长期不更新系统的 Redpill“黑群晖”用户，以及停留在旧版 DSM 6.2、7.1、7.2 的正版用户，只要将 Web 界面暴露在公网，就会被瞬间秒杀。 ### 入口二，CVE-2026-13684 与 CVE-2026-13639（2026 年 9 月高危漏洞） [360 反勒索团队](https://360.cn/n/13055.html)与蓝点网的预警报告指出，攻击者还利用了群晖于 2026 年 9 月 18 日在 [Synology-SA-26:13](https://www.synology.com/ja-jp/security/advisory/Synology_SA_26_13) 中披露的两个满分（CVSS 9.8）远程漏洞。其中 **CVE-2026-13684** 涉及 DSM SCGI 组件输出编码或转义不当，**CVE-2026-13639** 涉及登录逻辑中随机数熵不足。 这两个漏洞同样**不需要任何账号密码认证**，即可允许远程攻击者直接读取或写入系统任意文件。由于群晖 DSM 的自动更新采用分阶段推送（Staged Rollout）机制，不少白群晖用户在过去一个月内并未收到自动升级推送，从而沦为 1day 漏洞的受害者。 ### 入口三，PHP2Shell 套件漏洞与容器潜伏 就在本次事件爆发前夕的 2026 年 10 月 22 日，群晖刚刚发布了 [Synology-SA-26:14 "PHP2Shell"](https://www.synology.com/ja-jp/security/advisory/Synology_SA_26_14) 安全公告，修复了 PHP 内存分配远程代码执行漏洞 **CVE-2026-109618** 和 **CVE-2026-109619**（CVSS 9.8 分）。虽然 DSM 底层内置 PHP 不对外暴露，但安装了 `Web Station`、`Synology Calendar`、`Mail Station`、`phpMyAdmin`、`WordPress` 及 `PHP 7.4–8.4` 套件的设备若未更新套件，同样面临未授权远程代码执行风险。 此外，部分用户在高权限 Docker 容器中运行了存在漏洞的服务（如未及时更新的 GitLab CE 19.3 或开放注册的 Gitea）。攻击者通过容器突破后将恶意拉取脚本写入宿主机的 `/etc/crontab` 定时任务中，最后在 10 月 28 日统一触发加密并卸载 Docker 毁灭证据。 --- ## 破除三大安全错觉，为何最新 DSM 7.4.1 和开两步验证也中招 在蓝点网公众号评论区与 LINUX DO 社区中，最让用户感到恐慌的是“为什么有人升到了最新的 DSM 7.4.1、开了两步验证（2FA）、改了 5000/5001 端口，依然被加密了？”。结合 [Solar 应急响应团队](https://bbs.kanxue.com/thread-293361.htm)的现场排查与一线取证记录，我们可以清晰还原背后的真相。 ![群晖 NAS 用户常见三大安全防护误区与真实攻击原因对比图](https://afengblog.com/uploads/2026/10/9d9304284d8ad4f3855043f2.webp) ### 错觉一，“我已经升到了最新 DSM 7.4.1，肯定是因为有未公开 0day” Solar 团队确实排查到一台受灾设备运行着 2026 年 10 月 12 日发布的最新版 `DSM 7.4.1-90080 Update 1`，但安全团队明确强调，**最新版中招不等于 DSM 7.4.1 存在 0day 漏洞**。最核心的原因在于**入侵时间（Time-of-Compromise）与加密时间（Time-of-Encryption）存在时间差**。 许多设备在升级到最新版本之前，就已经通过旧版本漏洞或容器漏洞被攻击者植入了 `/etc/crontab` 或 `/etc/cron.d/` 计划任务后门。升级 DSM 系统版本或更新 Docker 容器镜像，并不会清除系统计划任务里的恶意脚本，一旦到了预设时间，潜伏的后门依然会拉取加密载荷完成收割。 同时，许多用户只升级了 DSM 系统，却忽略了“套件中心”里待更新的 PHP、Calendar 等高危套件，或者内网 Windows 电脑中毒后通过挂载的管理员权限 SMB 共享将 NAS 连坐加密。 ### 错觉二，“我开了两步验证（2FA）、强密码、禁了 SSH、改了默认端口” 在本次受灾名单中，大量技术玩家都配置了 20 位复杂密码、开启了 OTP 两步验证、关闭了 SSH，并将默认的 5000/5001 端口改成了五位数的冷门端口。然而面对 CVE-2024-10441 和 CVE-2026-13684 这类**认证前（Pre-auth）漏洞**，密码强度与两步验证形同虚设。 因为漏洞触发点位于身份校验完成之前，攻击者根本不需要知道你的密码，更不需要走到输入两步验证码的那一步，只要能访问到登录接口就能直接拿走 `root` 权限。至于修改默认端口，如今全网自动化资产测绘引擎（如 Shodan、Censys、FOFA）与高频扫描器可以在几分钟内扫遍全端口并识别出群晖 WebUI 指纹，改端口早已无法实现隐身。 ### 错觉三，“我没有 IPv4 公网，只开了 IPv6，应该很安全” 不少移动或电信宽带用户认为自己没有 IPv4 公网 IP，便放心大胆地开启了 IPv6 DDNS 外网访问。事实上，V2EX 与 LINUX DO 社区的多位受灾用户通过排查日志确认，攻击者正是顺着暴露在公网的 **IPv6 地址**完成扫描与漏洞注入的。 一旦你的 IPv6 域名绑定过公开的证书透明度日志（CT Logs，如申请过 Let's Encrypt 证书）或存在 DNS 解析记录，黑客扫描器就能精准定位你的 IPv6 地址与端口。 --- ## 群晖 NAS 紧急自查与防御加固清单（白群与黑群必看） 无论你的群晖目前是否正常，只要曾连接过互联网，建议今晚立即按照以下四步完成自查与加固。 ![群晖 NAS 防御加固与防勒索备份四项操作清单信息图](https://afengblog.com/uploads/2026/10/65329b172a2d25d6e5ee71f0.webp) ### 第一步，立即切断所有公网暴露面，改用虚拟局域网 1. 登录路由器后台，**立即删除所有指向群晖 NAS 的端口转发（Port Forwarding）规则**，关闭路由器的 **UPnP** 与 **DMZ** 功能。 2. 如果开启了 IPv6，请在路由器防火墙中开启 IPv6 入站阻断，或在群晖“控制面板 -> 网络 -> 网络界面”中暂时关闭 IPv6，切勿将 DSM 的 HTTP/HTTPS 端口直接暴露在公网。 3. 将远程访问方式全面切换为 **Tailscale**、**WireGuard** 或 **ZeroTier** 等内网组网工具，实现“端口零暴露”的安全远程访问。 ### 第二步，排查系统是否存在潜伏的恶意计划任务 对于曾经暴露在公网、近期才更新系统或关闭端口的用户，务必通过本地 SSH 登录群晖排查是否有潜伏后门： * 检查 `/etc/crontab` 以及 `/etc/cron.d/` 目录下是否存在未知的定时任务（重点排查带有 `synot*` 前缀或包含 `curl`、`wget`、`sh`、陌生 IP 的异常条目）。 * 检查 `/bin/` 目录下是否存在 `/bin/l0ck.enc`、`/bin/libgld`、`/bin/qnetd` 等异常文件。 * 打开群晖内置的“日志中心”，查看近期是否有异常的外部 IP 登录失败记录或 `root` 权限配置变更记录。 ### 第三步，核对并手动安装最新安全补丁 不要盲目相信 DSM 控制面板里的“您的 DSM 版本已是最新”，由于分阶段推送机制，许多设备需前往[群晖官方下载中心](https://www.synology.com/zh-cn/support/download)手动下载 `.pat` 补丁包升级。请确保你的 DSM 版本不低于以下修复基线（参考 [SA-26:13](https://www.synology.com/ja-jp/security/advisory/Synology_SA_26_13) 与 [SA-24:20](https://www.synology.com/ja-jp/security/advisory/Synology_SA_24_20)）： * **DSM 7.4 分支**：需升级至 `7.4-90075` 或最新的 `7.4.1-90080 Update 1` 及以上。 * **DSM 7.3 分支**：需升级至 `7.3.2-86009-4` 及以上。 * **DSM 7.2.2 分支**：需升级至 `7.2.2-72806-9` 及以上。 * **DSM 7.2.1 分支**：需升级至 `7.2.1-69057-12` 及以上。 * **DSM 7.1 / 7.0 / 6.2 旧分支**：需确保已安装 `7.1.1-42962-7` / `6.2.4-25556-8` 补丁，并在“套件中心”更新群晖于 2026 年 10 月 28 日至 29 日专门为 EOL 旧系统下发的 **PHP 安全更新**。 * **套件全面升级**：立即打开套件中心，将 `Synology Calendar`（升至 `3.0.4-21435`+）、`Mail Station`、`Web Station` 及所有 `PHP 7.4–8.4` 套件升至最新，已停更的 `PHP 7.3` 建议直接卸载。 ### 第四步，重构“防勒索”备份体系 本次事件中，有用户配置了 RAID 6 阵列加每日同机备份，结果所有本机备份与原文件被一锅端；还有用户开启了网盘双向同步，差点用加密后的 `.L0CK3D` 文件把云端正常文件全部覆盖。真正能抵御勒索软件的备份策略必须满足以下条件： * **启用 Btrfs 不可变快照（Immutable Snapshots）**：在群晖 Snapshot Replication 套件中开启基于 WORM（一次写入，多次读取）技术的不可变快照，设定 7 至 14 天的锁定期，在此期间即便是获取了 `root` 权限的黑客也无法删除或加密快照数据。 * **网盘同步开启“单向”或“历史版本”**：使用 Cloud Sync 同步至 OneDrive 或公有云时，务必确认云端开启了文件历史版本控制（Versioning），或改用 Hyper Backup 进行带多版本保留的加密备份。 * **严格落实冷备份（离线备份）**：重要核心数据定期备份至外置移动硬盘，备份完成后物理拔除电源与数据线（或使用智能插座仅在定时备份窗口通电），实现彻底的物理隔离。 --- ## 常见问题解答（FAQ） ### Q1，发现中招时已经把群晖关机或重启了，还能用 GitHub 上的开源工具解密吗？ 基本无法直接通过该工具恢复。因为 `soimy/c3rb3r-rescue` 的原理是从尚未断电的运行内存（RAM）中提取 48 字节的 AES-256-CBC 会话主密钥，一旦关机、重启或重装固件，内存中的易失性数据便已清空，且目前在断电后的 Swap 交换分区中也未能找到残留密钥。已重启的用户建议立即停机保护磁盘现场，优先检查是否残留 Btrfs 快照，或尝试通过专业数据恢复软件（如 UFS Explorer）及 Btrfs 底层元数据扫描抢救未被覆盖的文件块。 ### Q2，我的设备停留在 DSM 6.2、7.0 或 7.1（或使用黑群晖），受这次漏洞影响吗？ 受严重影响，而且是本次被攻破的重灾区。本次被证实遭大规模利用的 **CVE-2024-10441** 以及近期爆发的 **PHP2Shell（SA-26:14）** 均明确影响 DSM 6.2、7.0 和 7.1。群晖官方已于 2026 年 10 月 28 日至 29 日破例为已结束生命周期（EOL）的 DSM 7.2、7.1、7.0 和 6.2 推送了 PHP 安全补丁，无法升级最新系统的黑群晖或老机型用户**绝对不要将 NAS 暴露在公网**。 ### Q3，不映射公网端口，只开 QuickConnect（QC）、Cloudflare Tunnel 或 FRP 内网穿透安全吗？ 任何将群晖 Web 登录界面直接暴露给外部未授权访问的通道都存在风险。如果你通过 FRP 或 Cloudflare Tunnel 将群晖的 5000/5001 端口映射到了公网域名，且没有在隧道前端加装额外的访问鉴权（如 Cloudflare Access 零信任验证），攻击者同样可以通过域名直接触发 DSM 的未授权漏洞。至于 QuickConnect，虽然目前尚无底层证据表明 QC 协议本身被直接攻破，但社区中有个别自称仅开启 QC 的用户中招（不排除路由器开启了 UPnP 或遗漏了 IPv6），在官方完成全面归因前建议暂时关闭 QC，优先使用 Tailscale 等 VPN 访问。 ### Q4，在群晖前面挂了雷池（SafeLine）等 WAF，或者用 Lucky 反向代理能防住吗？ 不能保证 100% 防御。通用 WAF 的默认规则主要针对常见 Web 攻击（如 SQL 注入、常规 XSS），未必能精准识别针对群晖私有 WebAPI（如 `/webapi/entry.cgi` 插件分隔符注入或 SCGI 协议）的特制载荷，海外 Reddit 也有配置了多层反向代理与防火墙规则依然被攻破的案例。如果必须使用反向代理对外提供服务，建议开启严格的客户端证书校验（mTLS）或前置 HTTP Basic Auth 认证，避免让外部流量直接触达群晖原生登录接口。 ### Q5，如果数据极其重要且已经重启，向黑客支付 0.085 BTC 赎金能拿回数据吗？ 网络安全机构与社区强烈建议**不要支付赎金**。一方面，支付高昂的比特币赎金无法获得任何商业信誉保障，存在付款后拿不到解密器、解密器损坏大体积文件或遭遇二次敲诈的风险；另一方面，即便解密成功，设备底层也已被植入后门，必须在导出数据后彻底格式化重装系统。 --- ## 参考来源与延伸阅读 1. [Synology Security Advisory Synology-SA-26:13 DSM（CVE-2026-13684 / CVE-2026-13639 官方安全公告）](https://www.synology.com/ja-jp/security/advisory/Synology_SA_26_13) 2. [Synology Security Advisory Synology-SA-24:20 DSM（Pwn2Own 2024 CVE-2024-10441 官方安全公告）](https://www.synology.com/ja-jp/security/advisory/Synology_SA_24_20) 3. [Synology Security Advisory Synology-SA-26:14 PHP2Shell（CVE-2026-109618 / CVE-2026-109619 套件安全公告）](https://www.synology.com/ja-jp/security/advisory/Synology_SA_26_14) 4. [360 反勒索团队《Cerber 勒索攻击群晖 NAS 事件预警》](https://360.cn/n/13055.html) 5. [看雪安全社区 Solar 应急响应团队《【勒索预警】群晖 NAS 最新版遭勒索病毒攻击，疑似涉及 0day 漏洞》](https://bbs.kanxue.com/thread-293361.htm) 6. [GitHub 开源救援仓库 soimy/c3rb3r-rescue（Evidence-based DSM ransomware recovery）](https://github.com/soimy/c3rb3r-rescue) 7. [LINUX DO 社区《群晖 DSM+GitLab CE 遭 C3RB3R 勒索软件攻击！救灾直播贴》](https://linux.do/t/topic/3085082) 8. [LINUX DO 社区《【勒索预警】群晖 NAS 最新版遭勒索病毒攻击，疑似涉及 0day 漏洞！》](https://linux.do/t/topic/3089697) 9. [Reddit /r/synology 一线日志取证分析《Well, it finally happened. My first real ransomware incident.》](https://www.reddit.com/r/synology/comments/1xhqgov/well_it_finally_happened_my_first_real_ransomware/) 标签：[PHP2Shell](https://afengblog.com/tag/php2shell)、[网络安全](https://afengblog.com/tag/cybersecurity)、[群晖 NAS](https://afengblog.com/tag/synology-nas)、[勒索软件](https://afengblog.com/tag/ransomware)、[数据恢复](https://afengblog.com/tag/data-recovery) --- 原文：https://afengblog.com/blog/synology-nas-c3rb3r-ransomware-rescue-guide.html 其他页面同样支持在 URL 后追加 `.md` 获取 Markdown，站点索引见 https://afengblog.com/llms.txt