Cuối tháng 10/2026, trên V2EX xuất hiện một thread "livestream cứu hộ" rất đáng đọc: chủ thread chạy GitLab CE trong Container Manager trên NAS Synology (DSM) và bị ransomware mã hoá dữ liệu. File bị đổi đuôi thành .L0CK3D, kèm thư tống tiền read-me3.txt, và dòng họ được nhận diện là C3RB3R (biến thể Linux/đa nền tảng của họ Cerber cũ). Điều làm thread này khác các bài "than trời" thông thường là: nhờ giữ nguyên hiện trường và dump bộ nhớ khi tiến trình mã hoá còn sống, chủ thread đã lấy lại được khoá và giải mã thành công cả bản backup GitLab.
Bài này tổng hợp lại diễn biến, cách họ làm, và những bài học mà các reply trong thread đưa ra. Với dev Việt hay tự host GitLab, Gitea, camera, ảnh gia đình trên NAS ở nhà và mở port ra Internet cho tiện, đây là câu chuyện rất gần.
Diễn biến: tưởng do GitLab, hoá ra nghi do DSM
Ban đầu chủ thread nghi do lỗ hổng RCE của GitLab vừa được công bố, vì instance của họ từng nằm ở bản 19.3 khoảng một tháng trước khi lên 19.5.1. Một chi tiết quan trọng họ nhấn mạnh: script tấn công được cài vào crond của hệ thống, nên việc nâng cấp lên bản đã vá không có nghĩa là máy sạch. Nếu kẻ tấn công đã vào được từ trước, cron job vẫn ở đó chờ chạy.
Sau khi phân tích thêm, thread chuyển hướng: nguyên nhân gốc được nghi là lỗ hổng của chính DSM (chủ thread nêu CVE-2024-10441), không phải GitLab. Nhiều người reply xác nhận họ không chạy GitLab mà vẫn dính. Điểm chung gần như duy nhất mà mọi người thấy là: giao diện đăng nhập DSM (port 5000/5001) hoặc các dịch vụ dùng trang login của DSM bị lộ ra Internet. Có người chỉ mở Synology Drive, có người chỉ dùng QuickConnect, cũng dính. Một số người còn báo bản DSM mới nhất cũng bị, nên có nghi vấn về 0day chưa công bố. Tới thời điểm thread được cập nhật, nguyên nhân chính xác vẫn chưa được kết luận chắc chắn, nên hãy coi đây là thông tin đang tiến triển.
Một nhóm bị ảnh hưởng nặng là người dùng "黑群" (Synology không chính hãng, chạy bootloader Redpill trên phần cứng tự lắp). Nhóm này thường ngại cập nhật DSM vì sợ hỏng hệ thống, nên lỗ hổng cũ nằm im trên máy phơi ra Internet.
Điều quan trọng nhất: đừng rút điện
Lời khuyên được chủ thread in đậm và nhiều người cảm ơn nhất là: khi phát hiện bị mã hoá, đừng hoảng loạn rút điện. Thay vào đó:
- Ngắt kết nối Internet (rút WAN, tắt port forwarding), nhưng giữ máy chạy.
- Vào máy qua SSH trong mạng LAN.
- Tạm dừng (không kill) tiến trình đáng ngờ, ví dụ bằng
kill -STOP, để khoá vẫn nằm trong RAM. - Sao lưu binary mã độc, dump bộ nhớ, và vài cặp file "bản gốc / bản đã mã hoá" để đối chiếu.
Lý do rất đơn giản: ransomware phải giữ khoá trong bộ nhớ trong lúc mã hoá. Rút điện là xoá sạch bằng chứng đó. Một người reply kể họ đã tắt máy rồi mới copy file mã hoá ra cho AI phân tích, và không giải mã được. Người khác đáp lại đúng ý trên: sau khi tắt máy thì khả năng cao là hết cách.
Ví dụ thao tác tối thiểu (tuỳ môi trường, tên tiến trình trong thread là libgld):
# tìm tiến trình lạ đang ngốn CPU / ghi đĩa
ps aux --sort=-%cpu | head -20
# tạm dừng thay vì kill, để giữ nguyên bộ nhớ
kill -STOP <PID>
# copy binary đang chạy ra chỗ an toàn
cp /proc/<PID>/exe /volumeX/forensics/sample.bin
sha256sum /volumeX/forensics/sample.bin
# xem cron đã bị cài gì
crontab -l; ls -la /etc/cron*
Trong trường hợp của chủ thread, DSM chạy trong một VM trên Proxmox, nên họ đọc được toàn bộ RAM của VM (16 GiB) từ phía host mà không cần chạm vào guest. Đây là một lợi thế lớn của việc chạy NAS ảo hoá.
Họ đã giải mã thế nào
Theo các cập nhật trong thread, họ dùng AI coding agent (Codex và một model GPT) để hỗ trợ reverse engineering cùng Ghidra trên bản đã giải nén của mã độc, không chạy lại mẫu. Kết quả phân tích họ công bố:
- Dữ liệu file được mã hoá bằng ChaCha8, mỗi file có khoá 32 byte và nonce 8 byte riêng.
- Ở cuối mỗi file có một bản ghi 48 byte chứa khoá file, bản ghi này được mã hoá bằng AES-256-CBC với một khoá chủ.
- Khoá chủ (cùng IV) nằm trong bộ nhớ tiến trình. Họ lần theo page table của VM để chuyển địa chỉ ảo của tiến trình sang địa chỉ vật lý trong bản dump RAM, rồi đọc ra IV và khoá.
Cách họ kiểm chứng là điểm đáng học. Họ không tin vào việc "AI nói đã giải mã được", mà so SHA-256 của file giải mã với bản gốc đã biết (Gemfile, README, file PSD, PNG), kiểm tra CRC của file .xz, kiểm tra cấu trúc tar và gzip của bản backup GitLab. Công cụ giải mã chỉ ghi ra file mới, không bao giờ ghi đè file gốc. Với một file log có một byte không phải UTF-8, họ ghi rõ là không dám khẳng định khớp từng byte. Cuối cùng họ dựng được container GitLab trong môi trường cách ly từ bản backup ngày và tuần đã giải mã, khôi phục toàn bộ repo.
Chủ thread đã đưa tài liệu, prompt cho AI và script lên một repo GitHub công khai (soimy/c3rb3r-rescue) cho những người cùng cảnh. Một số người reply báo đã khôi phục được file nhờ hướng dẫn này, và mã độc trên máy họ có cùng hash.
Một lưu ý thực tế: cách này chỉ khả thi vì mã độc giữ khoá chủ trong RAM và nạn nhân bắt được nó khi đang chạy. Không phải ransomware nào cũng mắc lỗi đó, nên đừng coi đây là phương án dự phòng.
Các bài học phòng thủ từ phần reply
Đừng phơi giao diện quản trị ra Internet
Đây là ý được lặp lại nhiều nhất. Các lựa chọn mọi người đang dùng: Tailscale, WireGuard, EasyTier, OpenVPN, frp. Một người nhắc rằng chính Tailscale cũng vừa có lỗ hổng nghiêm trọng, nên VPN không phải bùa hộ mệnh, nhưng giảm bề mặt tấn công rất nhiều so với mở thẳng 5000/5001.
Cẩn thận IPv6
Một reply rất đáng chú ý: kể cả khi đã tắt port forwarding trên router, nếu nhà bạn có IPv6 và firewall của NAS không cấu hình, máy vẫn có thể bị truy cập trực tiếp qua địa chỉ v6. Nhiều ISP ở Việt Nam đã cấp IPv6 cho cáp quang gia đình, nên hãy kiểm tra cả firewall router lẫn firewall trong DSM, đồng thời tắt UPnP.
Nếu bắt buộc mở public
Một người chia sẻ cấu hình reverse proxy "tàng hình": chỉ mở một port cao cho reverse proxy, đóng hẳn 5000/5001, dùng wildcard certificate và subdomain ngẫu nhiên để tên thật không lộ qua Certificate Transparency log, và cấu hình nginx từ chối handshake khi truy cập bằng IP hoặc sai domain:
server {
listen 443 ssl default_server;
ssl_reject_handshake on; # sai domain thì cắt ngay, không lộ certificate
}
server {
listen 80 default_server;
return 444; # đóng kết nối, không trả trang 404
}
Người khác bổ sung: wildcard cert không phải tuỳ chọn, vì CT log được quét liên tục và subdomain của bạn sẽ bị liệt kê công khai. Các cách khác được nhắc: whitelist IP qua reverse proxy, geo-block theo quốc gia trong firewall DSM, giữ DSM và các package (đặc biệt PHP) luôn cập nhật.
RAID không phải backup
Một người tỏ ra thất vọng vì RAID mirror cũng bị mã hoá theo. Các phản hồi rất thẳng: NAS là thiết bị lưu trữ qua mạng, không phải giải pháp an toàn dữ liệu. Để chống ransomware bạn cần snapshot chỉ đọc (Btrfs snapshot có khoá bất biến) và bản backup tách rời theo nguyên tắc 3-2-1: snapshot nằm cùng volume với dữ liệu thì vẫn có thể bị phá. Một người còn phát hiện bản Hyper Backup lên cloud của mình không khôi phục được khi cần, đó là lời nhắc phải thử restore định kỳ, không chỉ tin vào job báo "thành công".
Checklist cho người đang tự host trên NAS
- Kiểm tra ngay có port nào của DSM, Drive, Photos đang mở ra Internet, cả IPv4 lẫn IPv6.
- Chuyển truy cập từ xa sang VPN mesh; tắt QuickConnect nếu không thật cần.
- Cập nhật DSM và package; nếu dùng bản không chính hãng không cập nhật được, tuyệt đối không mở ra public.
- Rà
crontab,/etc/cron*, tiến trình lạ, kể cả khi đã vá phần mềm. - Bật snapshot bất biến, có ít nhất một bản backup offline hoặc ở nơi khác, và thử restore.
- Chuẩn bị sẵn quy trình sự cố: ngắt mạng, giữ máy chạy, SSH vào, dừng tiến trình, dump bộ nhớ. Ghi ra giấy trước, vì lúc hoảng sẽ không nhớ.
Thread này cũng cho thấy một mặt tích cực của AI agent trong forensic: với người không chuyên reverse engineering, agent giúp đi nhanh qua những bước rất khó như lần page table hay nhận diện thuật toán. Nhưng phần giá trị nhất vẫn là kỷ luật của con người: giữ hiện trường, không ghi đè bản gốc, và kiểm chứng bằng hash thay vì tin lời agent.
Bài viết được AI của DevViet viết lại bằng tiếng Việt từ một thảo luận/bài viết tiếng Trung trên V2EX, có thể chưa chính xác tuyệt đối. Nguồn: 群晖 DSM+Gitlab CE 遭 C3RB3R 勒索软件攻击！救灾直播贴