soimy

Synology NAS users are being targeted with the C3RB3R ransomware again synology.com soimy/c3rb3r-rescue reddit.com reddit.com reddit.com

Free CLI that checks a DSM 7 NAS against the C3RB3R (.L0CK3D) advisories, shows a plan, then applies the fixes I wrote a small tool during the C3RB3R wave this week, mostly so I'd stop clicking through Control Panel on every box. It's free, MIT licensed, and not affiliated with Synology. What it does: 1. nas incident only reads. It checks the DSM build against SA-26:13, packages named in SA-26:14, the firewall, QuickConnect, router port forwarding, AutoBlock, SMB minimum protocol, the built in admin account, snapshot schedules, and whether the immutable snapshot lock is on for a model that doesn't support it. It also looks for CVE-2024-10441 markers in the connection log. 2. nas incident fix --dry-run prints the plan. nas incident fix asks before it changes anything and reads every setting back afterwards. Before a firewall change it checks that you won't lock yourself out. 3. nas incident contain lists processes that look like the encryptor. With --yes it freezes them (SIGSTOP, not kill) so the keys stay in memory. 4. nas alert-deploy installs a small check on the NAS that runs every 10 minutes and posts to a webhook. What it does NOT do: it does not decrypt files that are already encrypted. As far as I know there is no universal public decryptor for .L0CK3D, and the Kaspersky, Emsisoft and Dr.Web decryptors don't work on it. The only recovery path in the tool is nas incident rescue, which wraps soimy/c3rb3r-rescue. It can only find key candidates in the memory of an encryptor that is still running, on a NAS that has not been rebooted. If you already rebooted, it can't help. One known gap: Synology added separate fixed builds for DSM 6.2, 7.0 and 7.1 to SA-26:14 on Oct 29 and Oct 31. The tool only knows the DSM 7.2 and newer builds so far, so on those older versions a patched Calendar, Mail Station or PHP package can show as FAIL. Check the advisory by hand there until I update it. Python 3.8 or newer, no dependencies, runs from macOS, Linux or Windows, or on the NAS itself. The demo GIF uses a simulated NAS, so please start with the read only audit and the dry run. Code: synology-nas-cli on GitHub Incident notes with sources: INCIDENT-C3RB3R.md If a check is wrong for your model or DSM version, tell me and I'll fix it.

@fuyunocafe soimy/c3rb3r-rescue 복호화 툴 공개중입니다 랜섬 감염 후 전원을 끄거나 DSM을 재설치하지 않았다면 사용해보세요

@leon7hao 群晖 NAS 近期出现大规模勒索加密（C3RB3R / .L0CK3D） github.com/soimy/c3rb3r-rescue/blob/main/README_C…

@weisenzcharles c3rb3r-rescue#12 这个方法帮我恢复了部分数据，供参考

今天群晖中招的用这个仓库，超级好用，文件已全部恢复。soimy/c3rb3r-rescue

Help needed recovering data after C3RB3R ransomware attack on Synology/Xpenology NAS — `.L0CK3D` files** Hi everyone, Unfortunately, my NAS has been hit by ransomware, and I'm trying to recover as much of my data as possible. **What happened** - System: Xpenology running DSM 7.2.2-72806, configured as a DS3622xs+. - Encrypted files have been renamed with the `.L0CK3D` extension. - The ransom note is called `read-me3.txt` and refers to “C3RB3R INSTRUCTIONS”, with instructions to use the attackers' decryptor. - Some Container Manager binaries were also renamed with `.L0CK3D`. - I haven't confirmed the initial entry point, and my priority right now is recovering my data rather than investigating how the attackers got in. **What I've done so far** - Isolated the NAS from internet access. - Checked for obvious ransomware-related processes, but haven't found one by name. - Confirmed I don't have usable snapshots to restore from. - Found no confirmed backup containing the affected data. - Captured a memory image using Microsoft's AVML 0.21.0, writing it to a separate NTFS USB drive. The memory capture is approximately 5.6 GB as reported on the NAS. I ran `sync` and calculated its SHA-256 checksum. I've transferred it to a separate CachyOS Linux PC and verified that the checksum matches. I'm preserving the original capture and intend to analyse a working copy. I'm also looking at the `c3rb3r-rescue` project: soimy/c3rb3r-rescue **I'm hoping someone with relevant experience can advise on the following:** 1. Has anyone successfully recovered files encrypted by this particular C3RB3R variant, especially files renamed `.L0CK3D`? 2. Is the `c3rb3r-rescue` project applicable to this variant, or does it only work with particular samples and recovered keys? 3. Has anyone analysed an AVML memory capture from a physical Synology/Xpenology DSM system to recover ransomware key material? 4. What's the safest way to analyse this compressed AVML capture and search for useful key material without modifying the original evidence? 5. Are there any known decryptors or recovery techniques for this specific file format? I'm not assuming the memory capture contains a key, and I understand recovery may not be possible. I just want to make the best possible attempt before giving up on the data. Please share any relevant experience, technical guidance or verified recovery tools. I'd particularly appreciate advice from anyone who has worked with this specific ransomware or memory-based key recovery. Thanks.

@weisenzcharles 如果还没关过机，可以尝试使用下面的项目挽救：soimy/c3rb3r-rescue

For victims of C3RB3R ransomware If you didn't panic and pulled the plugs, there is a way to decrypt your files while ransomeware libgld is still running. Follow the instructions ( AI can handle this ) of my repo: soimy/c3rb3r-rescue

Hit by .lock3d ransomware? Came across a recovery write-up that might help I haven’t run into this myself, but with all the vulnerability discussions lately, I came across this write-up and figured I’d share it for anyone who might need it. soimy/c3rb3r-rescue The author recovered key material from RAM and used it to decrypt copies of their files. There’s an AI-assisted workflow in the repo too, although calling it “AI cracking ransomware” would be a bit of a stretch. A few things to keep in mind: - It worked for a specific sample. The same file extension doesn’t necessarily mean the same recovery method will work. - The successful recovery was on a VM. Recovery on a physical NAS hasn’t been verified yet. - If your NAS is still running, read the preservation section before rebooting or cleaning things up. There could still be useful key material in memory. - Work on copies, keep the originals, and check that the recovered files actually work. - Don’t upload RAM dumps, keys, or private files to an AI service. Personally, even if I managed to get my files back, I’d still do a DSM hard reset and reinstall afterward to feel safer. That alone wouldn’t guarantee everything’s clean, but I wouldn’t feel comfortable just recovering the files and carrying on. Obviously, save that until after preserving evidence and finishing recovery. Can’t vouch for it myself, but hopefully it gives someone another option to look into.