群晖 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 实例恢复。
方法与证据

1. 原始样本 libgld.bin SHA-256:
   802ac85d19dc6db2b1849bb3499877280544d04a0ae94d4c408b6c321669903dREA/Ghidra 分析脱壳副本；未运行样本，也未恢复恶意进程执行。


2. 反编译确认数据算法为 ChaCha8, 32 字节文件密钥、8 字节 nonce, 64 位计数器。
   文件末尾 588 字节内包含 48 字节 AES-256-CBC 加密的文件密钥记录。
   运行时模式为 0x20 ；记录解开后为 key32 + nonce8 + 相同 nonce8


3. 读取 PVE 的 VM102 RAM 映射得到 16 GiB 副本:
   PVE:/root/codex-rea-20261028/guest-ram-live.raw
   SHA-256:
   0f72eb4f7c65ed868ceffcf69b06c1b97bcc49b13323b947f08ba09da6d73883
   采集历时约 90 秒，未暂停虚拟机；它不是单时点一致快照。
   4.依据样本代码页定位页表，转换进程虚拟地址 0x5427f8;其指针指向
   0x130fa00 ，读取 IV16 + AES key32 。密钥已保存在私有目录，未写进聊天。
   内存中另保全 23 个符合文件对象布局的候选对象；尚未用它们恢复中途加密文件。


4. 对密钥的正确性使用文件内容验证，不仅依赖重复 nonce 。
   已完成验证
   Gemfile 、README.md 、LICENSE 、LOGO.psd (约 13 MB)、logo.png (约 1.47
   MB):
   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 内存封锁现场，关闭外部连接。只要开始时候做到这些都有希望恢复。