群晖 DSM+Gitlab CE 遭 C3RB3R 勒索软件攻击！救灾直播贴

目前的分析把入侵根因指向 DSM 的 CVE-2024-10441 ，而不是 Gitlab 。很多运行 Redpill 的黑群基本上不会随便更新 dsm 最新版本，导致漏洞未修复暴露给了公网。请大家自查相关新闻： https://mp.weixin.qq.com/s/9rjeNvYt7R4ybMphsjCKMA?scene=1&click_id=2083410843本次攻击有汇报称最新版 dsm 也遭到了攻击，应该是有未公布的 0day 漏洞，和是否开了 ssh/qc 没有关系
最最重要的事情如果不幸和我一样中招，不要慌乱的拔电源！断开公网连接，打开本地 SSH ，交给 AI 保留现场，隔离保存加密二进制文件和内存 dump ，由希望可以逆向出主密钥帮助文件恢复。
救灾仓库已上线，包含攻击路径文档，给 ai 读取的提示词，skills 以及工具脚本（燃烧 token 持续更新中，感觉有用记得点个 star ，可以让更多人看见）
https://github.com/soimy/c3rb3r-rescue
===== 原文 =====
我的 dsm 主机，container manager 运行 gitlab ce 19.3 ，上午被勒索软件袭击了，很多重要文件后缀名变成.L0CK3D , 还有 read-me3.txt … 目前还在让 ai 排查和救灾中。
Gemini 搜索了下：
根据加密后缀 .L0CK3D （含数字 0 和 3 ）以及勒索信文件名 read-me3.txt ，可以明确判定您的群晖（ DSM ）遭遇了 C3RB3R 勒索软件（即老牌 Cerber 勒索家族的现代跨平台/Linux 变种） 攻击。结合您正在运行或最近运行过 GitLab CE 19.3 的环境，这次攻击极大概率是通过 2026 年 10 月中下旬刚刚爆发的 GitLab 满分远程代码执行（ RCE ）漏洞 自动化入侵的。
发上来给大家提个醒，尽快升级排查下自己的 gitlab
===== 以下是排查救灾后的更新 =====
排查结果出来了，基本没恢复的可能。更正一下描述，其实我的容器 gitlab-ce 已经更新到了最新的 19.5.1 ，这个漏洞已经修补，但是在 19.3 版本曾经停留了 1 个月左右，攻击脚本是放在 linux 系统的 crond 中的计划任务，升级到最新版不代表就没问题。请大家排查
我过去 5 年的私有仓库数据已经完了，只有最近在本机上的代码还能迁移一下，是时候向过去做个告别……
===== 二更 ========
发现被攻击的时候加密进程和二进制文件被我暂停并封锁了现场，进程被 codex 暂停并取样，现在手上有解包后的加密二进制文件和当时的内存 dump 。正在让 gpt6 astra 想办法解密…… 希望能成功
===== 三更 ======
astra 号称已定位加密算法为 chacha8, 已经从内存 dump 中分析出了 48 字节的 AES-256-CBC 主密钥测试了一个 PSD 文件和 png 文件说成功解密了
===== 4 更 ========DSM 勒索事件：REA 与内存辅助解密验证核实时间：2026-10-28 20:05 +08:00结论已经从仍暂停的 libgld 进程所处的虚拟机内存中恢复可用密钥，实际解密成功。这证明已验证文件可恢复；尚未完成全盘解密或 GitLab 实例恢复。方法与证据

• 原始样本 libgld.bin SHA-256:802ac85d19dc6db2b1849bb3499877280544d04a0ae94d4c408b6c321669903dREA/Ghidra 分析脱壳副本；未运行样本，也未恢复恶意进程执行。
  
• 反编译确认数据算法为 ChaCha8, 32 字节文件密钥、8 字节 nonce, 64 位计数器。文件末尾 588 字节内包含 48 字节 AES-256-CBC 加密的文件密钥记录。运行时模式为 0x20 ；记录解开后为 key32 + nonce8 + 相同 nonce8
  
• 读取 PVE 的 VM102 RAM 映射得到 16 GiB 副本:PVE:/root/codex-rea-20261028/guest-ram-live.rawSHA-256:0f72eb4f7c65ed868ceffcf69b06c1b97bcc49b13323b947f08ba09da6d73883采集历时约 90 秒，未暂停虚拟机；它不是单时点一致快照。4.依据样本代码页定位页表，转换进程虚拟地址 0x5427f8;其指针指向0x130fa00 ，读取 IV16 + AES key32 。密钥已保存在私有目录，未写进聊天。内存中另保全 23 个符合文件对象布局的候选对象；尚未用它们恢复中途加密文件。
  
• 对密钥的正确性使用文件内容验证，不仅依赖重复 nonce 。已完成验证Gemfile 、README.md 、LICENSE 、LOGO.psd (约 13 MB)、logo.png (约 1.47MB):5/5 与已知原件 SHA-256 及逐字节内容完全一致，覆盖全文件、前 1 MiB 、分段三种模式。68 份已保全的日志密文均产生恢复正文; 23 份 XZ 全部完整解压且通过 CRC64 。44 份文本严格 UTF-8 与结构检查通过； 1 份 nginx 日志存在单个非 UTF-8 字节，虽然所有 3,963 行都有正确的时间前缀，仍不宣称与原文逐字节一致。3 份日志在加密尾部后还有新追加内容，已单独保存，未丢弃或覆盖密文。GitLab 备份 1793127682_2026_10_27_19.5.1_gitlab_backup.tar:恢复 173,926,400 字节，tar 头部检查通过，5 个 gzip 成员全部完整解压并校验通过。db/database.sql.gz 解压为 622,741,468 字节；未导入或执行其中的 SQL 。恢复 tar SHA-256:8fcf592a0d9eabf9c7018c91b0d763068a666b867c97e74ef50c2f8fc3c4765f配套取样的 gitlab-secrets.json 恢复 16,343 字节并通过 JSON 解析。尚未验证其与数据库中全部加密字段的匹配关系。解密原型通过两个公开 ChaCha8 向量，以及分块、计数进位、拒绝覆盖等 4 组自检。司仅向新文件写入；不允许覆盖原件。详见 decrypt_copy.README.txt 。===== 5 更 =======
  

喜报，隔离环境的 gitlab 容器已经起来了，解密的周备份和日备份已经恢复出了整个 repo验证一下会出个 repo ，c3rb3r 解密指南。希望能帮到中招佬友。最最核心的是发现中招不要慌，开 ssh 让 ai 暂停可疑进程，dump 内存封锁现场，关闭外部连接。只要开始时候做到这些都有希望恢复。


⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉