Trực tiếp: Synology bị mã hoá .LOCK3D: xử lý, cứu dữ liệu

Cập nhật trực tiếp

Tình hình hiện tại: Synology quy đợt tấn công cho lỗ hổng SA-24:20 trên DSM cũ; 5 trong 6 hồ sơ điều tra số công khai là máy DSM 7.2 hoặc 7.2.1 chưa vá. Số máy bị mã hoá chưa được thống kê, máy chủ phát tán vẫn hoạt động. Không có khoá thì không giải mã được, nhưng file trên 1 MB chỉ bị mã hoá một phần; trên ổ Btrfs, dữ liệu gốc của các đoạn bị mã hoá có thể vẫn còn. Kiểm tra mỗi file còn cứu được bao nhiêu bằng công cụ cứu dữ liệu .L0CK3D . Khuyến cáo: cập nhật DSM, tắt truy cập từ Internet (kể cả IPv6), tắt telnet và SSH, không xoá file .L0CK3D và không ghi thêm dữ liệu vào ổ bị nhiễm.

• 07:35 30/10 · Thêm ca lấy được khoá: tiến trình mã hoá vẫn chạy sau khoảng 37 giờ (chưa xác nhận). Chủ một máy DS920+ (DSM 7.2.2 chưa cài bản cập nhật, mở cổng ra Internet) phát hiện tiến trình mã hoá vẫn đang chạy khoảng 37 giờ sau khi bắt đầu, đóng băng nó và lấy được khoá từ bộ nhớ; các file giải mã khớp từng byte với bản gốc. Như vậy thời gian mã hoá tuỳ lượng dữ liệu và có thể kéo dài hơn một ngày: trước khi tắt máy, nên kiểm tra tiến trình còn chạy hay không. Ở ca này tiến trình mang tên /root/libgittcb.bat. Nguồn: GitHub (nạn nhân tự báo)
• 00:18 30/10 · Nạn nhân thứ hai khôi phục được ảnh trên ổ Btrfs mà không cần khoá. Một nạn nhân khác áp dụng cách đọc lại khối dữ liệu gốc còn trên ổ Btrfs: 386 trong 684 ảnh được khôi phục trọn vẹn và mở được đầy đủ; 298 ảnh còn lại là file nhỏ bị mã hoá toàn bộ nên không cứu được. Đây là xác nhận độc lập thứ hai cho cách khôi phục này. Nguồn: GitHub (nạn nhân tự báo)
• 23:52 29/10 · Ổ Btrfs: nạn nhân khôi phục gần trọn file bị mã hoá một phần mà không cần khoá (chưa xác nhận). Theo hồ sơ của một nạn nhân (DSM 7.2.1, ổ Btrfs, khoá đã mất), dữ liệu gốc của các đoạn bị mã hoá vẫn còn trên ổ do cơ chế copy-on-write của Btrfs, nên khôi phục được khoảng 99,9% file chỉ bị mã hoá 1 MB đầu và 99% file bị mã hoá theo đoạn; file từ 1 MB trở xuống thì không. Cách làm cần thao tác kỹ thuật trên ổ. Nếu NAS dùng Btrfs: không xoá file .L0CK3D, không ghi thêm dữ liệu, không chạy balance, chống phân mảnh hay xoá snapshot trên ổ bị nhiễm. Nguồn: GitHub (hồ sơ nạn nhân)
• 22:58 29/10 · Nashub.vn ra mắt công cụ miễn phí kiểm tra và cứu dữ liệu file .L0CK3D . Công cụ cho biết mỗi file còn bao nhiêu dữ liệu nguyên vẹn và lấy lại phần đó. File từ 1 MB trở xuống bị mã hoá toàn bộ nên không cứu được.
• 22:46 29/10 · Nạn nhân báo NAS QNAP cùng mạng nội bộ cũng bị mã hoá một phần (chưa xác nhận). Một nạn nhân cho biết sau khi máy Synology bị nhiễm, một NAS QNAP trong cùng mạng nội bộ cũng bị mã hoá một phần; chưa rõ mã độc lây sang bằng cách nào (thư mục chia sẻ được gắn vào, mật khẩu dùng chung hay đường khác). Nếu một NAS bị nhiễm, cần ngắt mạng và kiểm tra cả các thiết bị lưu trữ khác trong mạng. Nguồn: GitHub (nạn nhân tự báo)
• 22:27 29/10 · Tổng hợp 22h: file từ 1 MB trở xuống bị mã hoá toàn bộ; file lớn còn phần lớn dữ liệu (chưa xác nhận). Theo phân tích định dạng của cộng đồng nạn nhân, cách mã hoá phụ thuộc kích thước file: từ 1 MB trở xuống bị mã hoá toàn bộ và không cứu được; 1–5 MB chỉ bị mã hoá 1 MB đầu; trên 5 MB bị mã hoá 3 đoạn, mỗi đoạn 4%, còn khoảng 88% dữ liệu. Âm thanh và video cứu được phần lớn; ảnh thường chỉ cứu được ảnh xem trước nhúng trong file. Một hồ sơ điều tra số khác cũng tìm thấy địa chỉ tải mã độc 46.8.78.122 trùng với hồ sơ Ericality, củng cố nhận định đây là cùng một chiến dịch. Nguồn: GitHub (hồ sơ nạn nhân)
• 21:28 29/10 · Tổng hợp 21h: thêm ca mất khoá dù không tắt máy; máy chủ phát tán vẫn đang quét Internet (chưa xác nhận). Thêm một nạn nhân cho biết máy không khởi động lại, phát hiện khoảng 8 giờ sau khi bị mã hoá nhưng không còn khoá; cùng hồ sơ máy chạy liên tục 149 ngày, đã có 2 trường hợp cho thấy khoá chỉ lấy được khi tiến trình mã hoá còn chạy. Máy chủ phát tán 95.182.96.97 được GreyNoise ghi nhận quét Internet ngày 29/10, cho thấy chiến dịch chưa dừng. Hồ sơ điều tra số công khai trên GitHub tăng lên 5. Ở châu Âu mới có IT-Connect (Pháp) đưa tin; báo chí và cơ quan ứng cứu ở Đức, Anh, Mỹ, Nhật, Hàn, Việt Nam chưa có bài hay cảnh báo; CISA chưa đưa các lỗ hổng Synology vào danh mục KEV. Synology chưa có thông báo mới sau thông cáo sáng 29/10. Nguồn: GitHub soimy/c3rb3r-rescue (phản hồi của nạn nhân)
• 20:48 29/10 · Hồ sơ mới: máy chạy liên tục 149 ngày vẫn không còn khoá vì mã hoá đã xong (chưa xác nhận). Một nạn nhân dùng DSM 7.2-64570 Update 3 (chưa vá SA-24:20) chụp toàn bộ bộ nhớ khi máy chưa từng khởi động lại, nhưng không tìm thấy khoá: tiến trình mã hoá tự xoá khoá khi kết thúc. 892.384 file bị mã hoá trong khoảng 1 giờ 42 phút; tính theo dung lượng, 87,1% dữ liệu chưa bị mã hoá. Script phát tán tải mã độc từ IP 95.182.96.97, có bản cho cả chip x86 và ARM, và các tác vụ cron tự tạo lại để tải tiếp. Nhận định: chỉ lấy được khoá khi tiến trình mã hoá còn chạy; đã mã hoá xong thì ngắt mạng ngay, giữ máy chạy không còn giúp lấy khoá. Nguồn: GitHub (nạn nhân tự công bố)
• 20:29 29/10 · Pháp: IT-Connect đưa tin, cho biết Synology đã gửi email cảnh báo người dùng. Trang tin công nghệ IT-Connect (Pháp) cho biết Synology đã gửi email cảnh báo người dùng sáng 29/10, nội dung trùng thông cáo: kẻ tấn công khai thác lỗ hổng đã vá từ tháng 12/2024 để nhắm vào máy chạy DSM cũ, kèm đường dẫn tới Synology-SA-24:20. Bài cũng nhắc lại đánh giá của 360 về hai lỗ hổng SA-26:13 và khuyến cáo cập nhật DSM. Tính đến tối 29/10, đây là trang tin công nghệ đầu tiên ở châu Âu đưa tin về đợt tấn công. Nguồn: IT-Connect (Pháp)
• 20:13 29/10 · Tổng hợp 20h: file lớn chỉ bị mã hoá một phần, có thể cứu dữ liệu không cần khoá (chưa xác nhận). Theo phân tích của một nạn nhân trên diễn đàn BleepingComputer, với file lớn, C3RB3R chỉ mã hoá 3 đoạn, mỗi đoạn khoảng 4% dung lượng (đầu, giữa, cuối file), khoảng 88% nội dung còn nguyên; file nhỏ (khoảng 880 KB) bị mã hoá toàn bộ. Người này dựng lại được 42/50 trang của một file PDF; hồ sơ Creeper-OF cũng trích xuất được dữ liệu từ vùng chưa mã hoá, nên không nên xoá file .L0CK3D. Các diễn biến khác từ 19h: Synology Trung Quốc đăng thông cáo tiếng Trung; CISA chưa đưa CVE-2024-10441, CVE-2026-13639, CVE-2026-13684 vào danh mục lỗ hổng đang bị khai thác (KEV); chưa có hồ sơ điều tra số mới; báo chí và cơ quan ứng cứu ở châu Âu, Mỹ, Nhật, Hàn, Việt Nam chưa đưa tin. Nguồn: Diễn đàn BleepingComputer (phân tích của nạn nhân)
• 19:40 29/10 · Synology Trung Quốc đăng thông cáo tiếng Trung, cùng nội dung với bản toàn cầu. Thông cáo ghi Thượng Hải, 29/10: Synology phát hiện kẻ tấn công khai thác lỗ hổng đã vá từ tháng 12/2024 để tấn công thiết bị chạy DSM cũ, có thể dẫn tới mã hoá dữ liệu và tống tiền; khuyến cáo cập nhật DSM ngay, bật cập nhật bảo mật tự động và dẫn tới Synology-SA-24:20. Đây là văn bản đầu tiên về đợt tấn công trên trang của Synology Trung Quốc, nơi phần lớn ca bị mã hoá được báo cáo. Thông cáo không đề cập các ca máy chạy bản DSM mới nhất. Nguồn: Synology Trung Quốc
• 19:08 29/10 · Thêm hồ sơ: DSM 7.2.1 chưa vá, mã hoá xong trước khi phát hiện, chỉ cứu được một phần (chưa xác nhận). Máy x86 chạy DSM 7.2.1-69057 Update 1, thấp hơn mốc vá SA-24:20; dấu vết trong bộ nhớ khớp với khai thác CVE-2024-10441. Mã hoá kéo dài từ 4h09 đến 9h24 sáng 29/10 (giờ Việt Nam); khi phát hiện, tiến trình đã kết thúc nên không lấy được khoá, máy cũng không có snapshot dùng được. Chủ máy chỉ trích xuất được dữ liệu còn sót và cho biết nhiều file không còn dùng được, trái với các ca phát hiện sớm hoặc có snapshot. Nguồn: GitHub Creeper-OF (nạn nhân tự công bố)
• 18:55 29/10 · Tổng hợp tối 29/10: các hồ sơ điều tra số công khai chưa cho thấy lỗ hổng mới. Số máy bị mã hoá chưa được thống kê. Trong số đó, ba nạn nhân đã công khai kết quả điều tra số trên GitHub: hai máy chạy DSM 7.2 chưa vá SA-24:20, khớp với thông cáo của Synology; máy còn lại bị truy cập qua telnet lộ trên IPv6. Ca máy chạy DSM 7.4.1-90080 Update 1 do Solar ghi nhận vẫn chưa có thông tin kỹ thuật công khai. Về giải mã: hai nạn nhân lấy được khoá trong bộ nhớ khi mã hoá còn chạy; khoá không dùng được cho máy khác (một nạn nhân thử trên 3 mẫu file đều thất bại), chưa có công cụ giải mã dùng chung. Mức tiền chuộc của đợt này chưa được công bố. Đến tối 29/10 chưa thấy báo chí lớn hay cơ quan chức năng Việt Nam cảnh báo. Khuyến cáo bổ sung: kiểm tra IPv6, tắt telnet. Nguồn: GitHub soimy/c3rb3r-rescue (phản hồi của nạn nhân)
• 18:48 29/10 · Thêm hồ sơ điều tra số: DS1821+ chạy DSM 7.2 chưa vá, dữ liệu cứu được nhờ snapshot (chưa xác nhận). Máy DS1821+ chạy DSM 7.2-64570-1, thấp hơn bản vá SA-24:20 (7.2-64570-4). Sau 3 lần đăng nhập thất bại vào dịch vụ xác thực DSM, khoảng 7 phút sau mã độc bắt đầu mã hoá; 4.184 file bị mã hoá trước khi tiến trình bị hệ thống dừng do hết bộ nhớ, snapshot còn nguyên nên dữ liệu được khôi phục. Mã độc tải từ IP 46.8.78.122, cùng cách đặt tên file với hồ sơ của soimy nhưng khác máy chủ, cho thấy cùng chiến dịch dùng nhiều hạ tầng. Nguồn: GitHub Ericality (nạn nhân tự công bố)
• 18:25 29/10 · Synology ra thông cáo: tin tặc khai thác lỗ hổng đã vá từ 12/2024 trên máy chạy DSM cũ. Thông cáo ngày 29/10 của Synology viết rằng hãng đã xác định tin tặc khai thác một lỗ hổng được vá từ tháng 12/2024 để tấn công thiết bị chạy DSM lỗi thời, mã hoá dữ liệu và đòi tiền chuộc. Hãng khuyến cáo cập nhật DSM ngay, bật cập nhật tự động và dẫn tới Synology-SA-24:20 (CVE-2024-10441, RCE 9.8, lỗi từ Pwn2Own 2024). Nhận định này khớp với ca điều tra số DSM 7.2 chưa vá, nhưng khác với 360 (hai CVE vá tháng 9/2026) và chưa giải thích các báo cáo máy chạy 7.4.1-90080 Update 1 vẫn bị mã hoá. Nguồn: Synology Newsroom
• 17:33 29/10 · Hồ sơ của một nạn nhân khác: NAS lộ telnet, SSH qua IPv6; giải mã toàn bộ nhờ khoá trong RAM (chưa xác nhận). Máy vật lý chạy DSM 7.2 nhận địa chỉ IPv6 công khai, router không bật tường lửa IPv6, nên telnet (cho đăng nhập root), SSH và cổng 5000/5001 truy cập được từ Internet; nạn nhân không thấy dấu hiệu khai thác lỗ hổng DSM. Phát hiện khi mã hoá còn chạy, nạn nhân đóng băng tiến trình bằng kill -STOP, lấy khoá từ bộ nhớ và giải mã toàn bộ. Nhiều nhà mạng tại Việt Nam cấp IPv6 cho thuê bao gia đình, nên cần kiểm tra tường lửa IPv6 trên router. Nguồn: GitHub Benjamin-zlt (nạn nhân tự công bố)
• 17:10 29/10 · 360: đây là tấn công "1-day" qua hai lỗ hổng DSM đã vá tháng 9. Hãng bảo mật 360 công bố phân tích: C3RB3R mã hoá bằng ChaCha8 + RSA-2048, bỏ qua 27 thư mục hệ thống, kèm mã băm mẫu mã độc để dò quét. Nhận định: máy chưa lên bản vá SA-26:13 là mục tiêu chính, nhưng cập nhật vẫn chưa thay được việc tắt truy cập Internet. Nguồn: 360
• 16:59 29/10 · Solar: máy chạy bản mới nhất DSM 7.4.1-90080 Update 1 vẫn bị mã hoá. Đội ứng cứu Solar xử lý nhiều ca, có máy đã bật 2FA, tắt SSH vẫn mất 8TB dữ liệu. Đường vào chưa xác định, chưa thể kết luận DSM có lỗ hổng 0-day. Nhận định: tắt truy cập từ Internet là bước quan trọng nhất lúc này. Nguồn: Solar trên Kanxue
• 14:36 29/10 · Nạn nhân công khai bộ công cụ khôi phục C3RB3R bằng khoá lấy từ RAM trên GitHub (chưa xác nhận). Kho soimy/c3rb3r-rescue (commit ngày 29/10) đăng quy trình giữ bằng chứng, trích khoá phiên 48 byte từ RAM và bộ giải mã chạy trên bản sao. Tác giả nói rõ đây không phải công cụ giải mã cho mọi nạn nhân. Công cụ mới chỉ thử thành công trên file của chính vụ này. Khoá cũng chỉ lấy được từ máy ảo PVE, chưa thử trên NAS vật lý. Chỉ chạy công cụ trên bản sao, không chạy trên ổ gốc. (Cập nhật 20:55: khoá bị xoá khi mã hoá kết thúc, xem mục xử lý trong bài.) Nguồn: GitHub – soimy/c3rb3r-rescue
• 14:36 29/10 · Điều tra số một ca: NAS chạy DSM 7.2 chưa vá, đường vào nghi lỗi cũ CVE-2024-10441 (chưa xác nhận). Tài liệu attack-path của nạn nhân cho thấy máy chạy DSM 7.2-64561, bản 2023 chưa vá, mở cổng 80/443 và SSH ra Internet. Nhật ký trong RAM chỉ tới lỗi chèn biến môi trường vào plugin đăng nhập DSM, khớp với CVE-2024-10441 (SA-24:20, tháng 11/2024). Tài liệu cũng bác giả thuyết GitLab là đường vào. Mã độc chạy dưới dạng /bin/libgld, có file /bin/l0ck.enc và cron /etc/cron.d/synotgkk.*. Từ lúc đăng nhập lỗi tới lúc mã hoá chỉ khoảng 7 phút. Nhận định: đây mới là kết luận của một người, chưa ai xác nhận. Nhưng nó cho thấy kẻ tấn công dùng cả lỗ hổng rất cũ, nên bảng phiên bản SA-24:20 vẫn đáng dùng để đối chiếu nếu NAS đã lâu không cập nhật. Ca này không trả lời được vì sao máy chạy bản mới nhất Nguồn: GitHub – soimy/c3rb3r-rescue (docs/attack-path.md)

Từ ngày 28/10/2026, nhiều người dùng NAS Synology phát hiện dữ liệu bị ransomware C3RB3R mã hoá: file bị đổi đuôi thành .LOCK3D, mỗi thư mục có file read-me3.txt đòi tiền chuộc. Có trường hợp máy chạy bản DSM mới nhất, đã bật xác thực 2 lớp và tắt SSH vẫn bị mã hoá 8TB dữ liệu.

Ngày 29/10/2026, Synology ra thông cáo chính thức : kẻ tấn công đang khai thác một lỗ hổng đã được vá từ tháng 12/2024 để nhắm vào các máy chạy DSM cũ, và khuyến cáo cập nhật DSM ngay.

Bài này tổng hợp các thông tin đã kiểm chứng tới thời điểm cập nhật: diễn biến, đặc điểm của mã độc, các đường tấn công đang bị nghi ngờ, các bước phòng ngừa và cách xử lý khi đã bị mã hoá.

Tóm tắt

• Đã bị mã hoá? Dùng công cụ cứu dữ liệu .L0CK3D của Nashub (miễn phí) để xem mỗi file còn bao nhiêu dữ liệu nguyên vẹn và trích phần đó ra. File trên 1 MB thường chỉ bị mã hoá một phần. Nếu ổ dùng Btrfs, một nạn nhân đã khôi phục gần như trọn vẹn các file trên 1 MB vì dữ liệu gốc vẫn còn trên ổ (xem mục "Khả năng giải mã"). Đừng xoá file .L0CK3D và đừng ghi thêm dữ liệu vào ổ bị nhiễm.
• Dấu hiệu: file có đuôi .LOCK3D hoặc .L0CK3D, thư mục có file read-me3.txt.
• Synology nói gì (thông cáo 29/10): kẻ tấn công khai thác lỗ hổng Synology-SA-24:20 (CVE-2024-10441, vá từ 12/2024) trên máy chạy DSM cũ; khuyến cáo cập nhật DSM ngay và bật cập nhật tự động.
• Đường vào: 4 trong 5 hồ sơ điều tra số công khai là máy DSM 7.2 hoặc 7.2.1 chưa vá SA-24:20; 1 máy bị truy cập qua telnet, SSH lộ ra Internet bằng IPv6. Đội ứng cứu Solar ghi nhận một máy chạy bản mới nhất 7.4.1-90080 Update 1 cũng bị mã hoá, chưa rõ đường vào.
• Quy mô: chưa có thống kê; nạn nhân báo cáo chủ yếu ở Trung Quốc, đã có ca ở Việt Nam. Máy chủ phát tán mã độc vẫn hoạt động ngày 29/10.
• Giải mã: chưa có công cụ giải mã. Khoá chỉ lấy được từ bộ nhớ khi tiến trình mã hoá còn chạy; mã hoá xong là khoá bị xoá. Thời gian chạy tuỳ lượng dữ liệu: có máy xong trong khoảng 2 giờ, có máy vẫn đang mã hoá sau hơn một ngày, nên cần kiểm tra tiến trình trước khi tắt máy.
• Cần làm ngay: tắt truy cập từ Internet (kể cả qua IPv6), tắt telnet và SSH, cập nhật DSM lên bản mới nhất của dòng máy (đa số là 7.4.1-90080 Update 1), sao lưu dữ liệu quan trọng ra ổ rời rồi ngắt ổ.

Nên cập nhật DSM lên bản nào?

Khuyến nghị: cập nhật lên bản mới nhất của dòng DSM mà máy hỗ trợ. Theo trang ghi chú phát hành của Synology, với đa số model hiện nay đó là DSM 7.4.1-90080 Update 1, phát hành ngày 12/10/2026, ghi chú "Fixed security vulnerabilities".

Lỗ hổng Synology xác nhận bị khai thác nằm trong Synology-SA-24:20 , công bố 11/2024 sau cuộc thi Pwn2Own. Lỗi nghiêm trọng nhất, CVE-2024-10441 (9,8/10), cho phép thực thi mã từ xa mà không cần đăng nhập. Máy chạy bản cũ hơn mốc ở cột "Đã vá SA-24:20" cần cập nhật ngay.

Nguồn: kho phát hành DSM của Synology , Synology-SA-26:13 , Synology-SA-24:20 .

Lưu ý khi cập nhật:

• Theo ghi chú phát hành, DSM 7.4.1-90080 Update 1 có thể không tự hiện thông báo cập nhật (phát hành dần theo khu vực). Kiểm tra tại Control Panel → Update & Restore hoặc tải bản cài thủ công từ Download Center của Synology.
• Một số model cũ chỉ hỗ trợ tới DSM 7.1 (ví dụ DS1515+, RS815, DS115j; bản cuối 7.1.1-42962 Update 9 phát hành 5/8/2025) hoặc DSM 6.2. Bản cuối của các dòng này đã có bản vá SA-24:20 nhưng không có trong danh sách vá SA-26:13, nên càng cần tắt truy cập từ Internet.
• Máy cài DSM trên phần cứng khác dùng cùng hệ điều hành, áp dụng cùng khuyến nghị.
• Solar ghi nhận ca bị mã hoá trên máy chạy 7.4.1-90080 Update 1. Cập nhật là cần thiết nhưng nên đi kèm việc tắt truy cập từ Internet cho tới khi rõ đường tấn công của các ca này.
• Synology khuyến nghị bật cập nhật tự động: Control Panel → Update & Restore → Update Settings.

Diễn biến

Quy mô và thiệt hại

Số máy bị mã hoá chưa được thống kê. Báo cáo của nạn nhân xuất hiện dày đặc từ chiều 28/10, chủ yếu ở cộng đồng Trung Quốc (linux.do, V2EX, Kanxue, Bilibili, Xiaohongshu), ngoài ra có trên Reddit và diễn đàn BleepingComputer; đội ứng cứu Solar cho biết đã xử lý nhiều ca từ đầu tháng 10. Trên diễn đàn BleepingComputer , một thành viên báo NAS Zyxel NAS326 bị C3RB3R mã hoá ngày 17/10, nghĩa là mã độc không chỉ nhắm vào Synology; ngày 28/10 có thêm người dùng Synology báo bị mã hoá, và Emsisoft trả lời chưa có cách giải mã. Báo chí bắt đầu đưa tin từ chiều 29/10: Tom's Hardware (Mỹ) thuật lại ca một máy DS918+ bỏ cập nhật khoảng 18 tháng, IT-Connect (Pháp) và CyberQ (Đài Loan) có bài phân tích; thông tin kỹ thuật chủ yếu vẫn đến từ các hãng bảo mật Trung Quốc, diễn đàn và hồ sơ nạn nhân trên GitHub. Cơ quan chức năng Việt Nam chưa ra cảnh báo.

Hồ sơ điều tra số đã công khai: chỉ một phần nhỏ nạn nhân công bố chi tiết kỹ thuật, nhưng đây là nguồn cho biết đường vào cụ thể.

Bốn trong năm hồ sơ khớp với thông cáo của Synology (DSM cũ chưa vá). Hồ sơ của Benjamin-zlt cho thấy NAS có thể lộ ra Internet qua IPv6 dù không mở cổng trên router. Ca máy chạy bản mới nhất do Solar ghi nhận chưa có thông tin kỹ thuật công khai để đối chiếu.

Tiền chuộc: mức đòi trong đợt tấn công NAS chưa được công bố. Với mẫu C3RB3R trên Windows năm 2023, PCrisk ghi mức 0,085 BTC, tăng lên 0,17 BTC nếu không trả trong 5 ngày. Chưa có thông tin về số tiền đã được trả.

Số liệu theo dõi (đo lúc 22:25 ngày 29/10, giờ Việt Nam). Đây là các chỉ báo gián tiếp từ nguồn công khai, không phải số nạn nhân:

C3RB3R là gì?

Các hãng bảo mật như 360 và SentinelOne xếp C3RB3R vào họ ransomware Cerber (xuất hiện từ năm 2016). Theo các nhà phân tích trên diễn đàn BleepingComputer, dựa trên đánh giá của Red Canary, mã nguồn C3RB3R nhiều khả năng được dựng lại từ mã rò rỉ của nhóm Conti chứ không phải Cerber gốc. Năm 2023, C3RB3R từng khai thác lỗ hổng Confluence CVE-2023-22518. Phiên bản tấn công NAS chạy trên Linux, nền tảng của DSM.

Đặc điểm kỹ thuật (theo phân tích của 360):

• Mã hoá từng file bằng ChaCha8 với khoá và nonce riêng; các khoá file được mã hoá tiếp bằng RSA-2048.
• Bỏ qua 27 thư mục hệ thống, file thực thi và file đã mã hoá, để hệ thống vẫn hoạt động.
• Thư read-me3.txt kèm mã nhận dạng nạn nhân 6 ký tự.
• Mẫu mã độc được ghi nhận có MD5 a1375e0f82ae86df528876c049b5a23c.

Trang thanh toán (theo Solar): cho giải mã thử 1 file không quá 1024KB, tạo ví tiền mã hoá riêng cho từng nạn nhân và tự gửi công cụ giải mã sau 6 lần xác nhận trên blockchain.

Tốc độ: một nạn nhân cho biết khoảng 1TB dữ liệu bị mã hoá trong 5 phút. Theo một bản điều tra số được công bố, mã độc bắt đầu mã hoá khoảng 7 phút sau lần đăng nhập thất bại đầu tiên.

Khả năng giải mã: chưa có công cụ giải mã dùng chung. Mỗi lần chạy, mã độc tạo một khoá phiên 48 byte nằm trong bộ nhớ. Hai nạn nhân đã giải mã được toàn bộ dữ liệu bằng cách lấy khoá này khi tiến trình mã hoá còn sống. Khoá của máy này không dùng được cho máy khác: một nạn nhân thử khoá đã công khai trên 3 mẫu file và đều thất bại . Cách này chỉ áp dụng được khi tiến trình mã hoá còn đang chạy: khi mã hoá xong, tiến trình tự xoá khoá. Một nạn nhân có máy chạy liên tục 149 ngày, không khởi động lại, đã chụp toàn bộ bộ nhớ nhưng không tìm thấy khoá . Ở hồ sơ này, gần 900.000 file bị mã hoá trong khoảng 1 giờ 42 phút, nên nếu phát hiện muộn thì có thể đã mất cơ hội lấy khoá. Ngược lại, NAS có nhiều dữ liệu có thể bị mã hoá rất lâu: ở một máy DS920+ , tiến trình vẫn đang chạy sau khoảng 37 giờ và chủ máy lấy được khoá, giải mã file khớp từng byte với bản gốc. Một nạn nhân khác phát hiện khoảng 8 giờ sau khi bị mã hoá , máy cũng chưa khởi động lại, và cũng không còn khoá.

Mã hoá một phần: theo phân tích của một nạn nhân trên diễn đàn BleepingComputer , với file lớn, mã độc chỉ mã hoá 3 đoạn, mỗi đoạn khoảng 4% dung lượng file (ở đầu, khoảng giữa và cuối), nên khoảng 88% nội dung còn nguyên; file nhỏ (khoảng 880 KB trong mẫu thử) bị mã hoá toàn bộ. Mỗi file bị mã hoá dài thêm đúng 588 byte. Người này dựng lại được 42 trên 50 trang của một file PDF. Hồ sơ Creeper-OF cũng trích xuất được dữ liệu từ các vùng chưa bị mã hoá. Video, ảnh dung lượng lớn, file nén và ảnh đĩa máy ảo có khả năng cứu được một phần; tài liệu nhỏ thì khó.

Khôi phục trên ổ Btrfs: theo hồ sơ của một nạn nhân (DSM 7.2.1, ổ Btrfs, khoá đã mất), các file chỉ bị mã hoá một phần có thể khôi phục gần như trọn vẹn mà không cần khoá. Mã độc ghi đè lên một phần file; với cơ chế ghi mới (copy-on-write) của Btrfs, đoạn bị ghi đè được lưu sang chỗ khác, còn khối dữ liệu gốc vẫn được giữ trên ổ vì phần chưa mã hoá của file vẫn trỏ tới nó. Đọc lại khối gốc và ghép với phần còn nguyên sẽ được file ban đầu. Người này khôi phục được khoảng 99,9% số file chỉ bị mã hoá 1 MB đầu và khoảng 99% số file bị mã hoá theo đoạn; file từ 1 MB trở xuống (mã hoá toàn bộ) thì không. Cách làm cần thao tác kỹ thuật trên ổ (công cụ btrfs ở chế độ chỉ đọc), nên nhờ người có chuyên môn. Điều kiện tiên quyết: không xoá file .L0CK3D, không ghi thêm dữ liệu, không chạy chống phân mảnh, cân bằng (balance) hay xoá snapshot trên ổ đó, vì các thao tác này có thể giải phóng hoặc ghi đè dữ liệu gốc.

Ba chế độ mã hoá: theo phân tích mã độc trong các kho của nạn nhân, mỗi file được xử lý theo một trong ba cách tuỳ kích thước: file từ 1 MB trở xuống bị mã hoá toàn bộ; file 1–5 MB chỉ bị mã hoá 1 MB đầu; file trên 5 MB bị mã hoá 3 đoạn, mỗi đoạn khoảng 4% dung lượng (theo phân tích định dạng của cộng đồng nạn nhân). 588 byte cuối mỗi file ghi chế độ đã dùng và kích thước gốc, nên có thể đo trước mỗi file còn bao nhiêu dữ liệu nguyên vẹn mà không cần giải mã; công cụ của Nashub làm việc này cho nhiều file cùng lúc. Về giải mã khi không có khoá: mỗi lần chạy, mã độc tạo khoá phiên mới từ bộ sinh số ngẫu nhiên của hệ thống, rồi gói khoá này bằng khoá công khai của kẻ tấn công; chưa tìm thấy điểm yếu nào trong cách gói khoá, và khoá của nạn nhân này không mở được file của nạn nhân khác.

Đối tượng bị ảnh hưởng

Theo báo cáo của Solar và các nạn nhân trên linux.do, V2EX, Kanxue:

• Phiên bản DSM của nạn nhân được báo cáo trải từ 7.2 tới 7.4.1-90080 Update 1. Synology chỉ đề cập máy chạy DSM cũ.
• Hình thức truy cập từ Internet gồm mở cổng 5000/5001, QuickConnect, Cloudflare Tunnel, reverse proxy. Có trường hợp chỉ bật QuickConnect hoặc chỉ dùng Synology Drive.
• Có nạn nhân đã bật xác thực 2 lớp, đổi cổng SSH và tắt SSH.
• Chưa có báo cáo nạn nhân dùng máy chip ARM, nhưng script phát tán mà một nạn nhân thu được có bản tải riêng cho chip ARM (aarch64, armv7l) bên cạnh x86_64. Không nên coi máy ARM là an toàn.
• Một nạn nhân cho biết NAS QNAP cùng mạng nội bộ với máy Synology bị nhiễm cũng bị mã hoá một phần, nên các thiết bị lưu trữ khác trong mạng cũng cần kiểm tra.
• Chưa có báo cáo NAS chỉ dùng trong mạng nội bộ bị tấn công trực tiếp. Lưu ý: NAS có địa chỉ IPv6 công khai có thể truy cập được từ Internet dù không mở cổng IPv4 trên router (theo một hồ sơ điều tra số công khai).

Đường tấn công

Synology xác nhận một đường tấn công là lỗ hổng SA-24:20 trên máy chạy DSM cũ. Các trường hợp máy chạy bản mới nhất bị mã hoá chưa được giải thích; Solar cho rằng chừng đó chưa đủ để kết luận DSM có lỗ hổng 0-day. Các đường tấn công được các bên nêu:

1. SA-24:20 (Synology xác nhận): CVE-2024-10441 (9,8/10), lỗi trong system plugin daemon của DSM cho phép thực thi mã từ xa không cần đăng nhập; được nhóm DEVCORE trình diễn tại Pwn2Own 2024 và vá từ 11–12/2024. Kết quả điều tra số của một nạn nhân cũng chỉ tới lỗ hổng này trên máy chạy DSM 7.2-64561 chưa vá.
2. SA-26:13 (vá 18/9/2026): CVE-2026-13639 (lỗi tạo số ngẫu nhiên trong khâu đăng nhập) và CVE-2026-13684 (thành phần SCGI), cùng 9,8/10, cho phép đọc, ghi file tuỳ ý mà không cần đăng nhập. 360 đánh giá đây là đường vào trong các ca đã phân tích.
3. PHP2Shell (SA-26:14): CVE-2026-109618 và CVE-2026-109619 (9,8/10), cho phép thực thi mã từ xa qua các gói dùng PHP như Web Station, WordPress, phpMyAdmin, Calendar, Mail Station, MediaWiki, Joomla. Theo Synology, PHP tích hợp trong DSM không mở ra bên ngoài nên rủi ro thấp.
4. Ứng dụng trong Docker: nạn nhân ngày 28/10 chạy GitLab CE trong Container Manager, trong khi GitLab vừa công bố lỗ hổng 10/10 CVE-2026-110264 có mã khai thác công khai. Mã độc được cài vào lịch chạy của hệ thống nên cập nhật GitLab không loại bỏ được.
5. Dịch vụ lộ ra Internet qua IPv6: telnet, SSH, DSM truy cập được trực tiếp khi router không bật tường lửa IPv6 (theo một hồ sơ điều tra số công khai).
6. Mật khẩu bị lộ hoặc yếu, hoặc xâm nhập từ một thiết bị khác trong cùng mạng.
7. Lỗ hổng 0-day trong DSM: chưa được xác nhận; thông cáo của Synology chỉ nêu lỗ hổng đã vá.

Có thể tồn tại nhiều đường tấn công cùng lúc. Vì vậy cần áp dụng đồng thời các biện pháp bên dưới thay vì chỉ dựa vào bản vá.

Các bước phòng ngừa

Áp dụng cho mọi NAS Synology, kể cả khi chưa có dấu hiệu bất thường. Bước 1 và 2 cần làm trước.

Bước 1. Tắt truy cập từ Internet

• Trên router: xoá các quy tắc chuyển tiếp cổng (port forwarding) tới NAS, nhất là cổng 5000, 5001, 22, 443, 80, 6690; tắt UPnP.
• Trong DSM: Control Panel → External Access → QuickConnect, bỏ chọn Enable QuickConnect, bấm Apply.
• Tạm tắt Cloudflare Tunnel, reverse proxy, DDNS đang trỏ vào DSM.
• Kiểm tra IPv6: nhiều nhà mạng tại Việt Nam cấp địa chỉ IPv6 công khai cho thiết bị trong nhà. Bật tường lửa IPv6 trên router, hoặc tắt IPv6 trên NAS nếu không dùng (Control Panel → Network → Network Interface → Edit → IPv6, chọn Off).

Nhu cầu truy cập từ xa xem phần "Truy cập từ xa an toàn" bên dưới.

Bước 2. Sao lưu ra ổ rời và ngắt ổ

Chép dữ liệu quan trọng ra ổ USB hoặc HDD box, hoặc dùng Hyper Backup . Sau khi chép xong, tháo ổ khỏi NAS. Bản sao lưu nằm trên cùng NAS hoặc ổ đang kết nối có thể bị mã hoá cùng dữ liệu gốc.

Bước 3. Kiểm tra dấu hiệu xâm nhập

• File Station: tìm file có đuôi .LOCK3D, .L0CK3D hoặc file read-me3.txt.
• Control Panel → Task Scheduler: tìm tác vụ không rõ nguồn gốc, nhất là tác vụ chạy script với quyền root.
• Control Panel → User & Group: tìm tài khoản lạ hoặc tài khoản có quyền quản trị bất thường.
• Log Center: kiểm tra đăng nhập từ IP lạ (xem cách kiểm tra log trên NAS Synology ).
• Resource Monitor: CPU, ổ cứng hoạt động cao bất thường khi không có người dùng.

Dấu hiệu kỹ thuật (kiểm tra qua SSH) của mẫu đã được phân tích: file /bin/libgld, /bin/l0ck.enc, các file lịch chạy /etc/cron.d/synotgkk.*, file init-rsysd.lo, 0init-ld.lo; file /bin/qnetd, tiến trình /root/libgittcb.bat; nhiều file /etc/cron.d/synot* chứa lệnh dạng echo <base64> | base64 -d | sh; script tải từ IP 104.253.175.125, 46.8.78.122 hoặc 95.182.96.97; SHA-256 mẫu mã độc 802ac85d19dc6db2b1849bb3499877280544d04a0ae94d4c408b6c321669903d; MD5 theo 360 a1375e0f82ae86df528876c049b5a23c. Phát hiện một trong các dấu hiệu này thì xử lý như máy đã nhiễm.

Bước 4. Cập nhật DSM và các gói

Cập nhật DSM tại Control Panel → Update & Restore lên bản mới nhất của dòng DSM đang dùng (xem bảng ở mục "Nên cập nhật DSM lên bản nào?"); với đa số máy là DSM 7.4.1-90080 Update 1. Bật cập nhật tự động trong Update Settings theo khuyến nghị của Synology.

Trong Package Center, cập nhật mọi gói, đặc biệt PHP, Web Station, WordPress, phpMyAdmin, Calendar; Mail Station cần cập nhật thủ công; PHP 7.3 không còn được vá. GitLab trong Docker cần lên 19.5.1, 19.4.3 hoặc 19.3.6 tuỳ nhánh. Không mở ra Internet các ứng dụng không cần thiết.

Bước 5. Bảo vệ tài khoản

• Đổi mật khẩu các tài khoản quản trị; dùng mật khẩu dài, không dùng lại.
• Vô hiệu hoá tài khoản admin mặc định.
• Bật xác thực 2 lớp (2FA) cho tài khoản quản trị.
• Tắt SSH, Telnet, SMB1, FTP nếu không dùng (Control Panel → Terminal & SNMP, File Services).

Bước 6. Bật Auto Block và tường lửa

Control Panel → Security → Protection: bật Auto Block. Thẻ Firewall: bật tường lửa, chỉ cho phép dải IP nội bộ (ví dụ 192.168.1.0/24) truy cập dịch vụ quản trị.

Danh sách đầy đủ: checklist bảo mật NAS Synology .

Bước 7. Bật snapshot bất biến

Trong Snapshot Replication, đặt lịch chụp snapshot cho các thư mục quan trọng (mỗi giờ hoặc mỗi ngày), giữ tối thiểu 7–14 ngày. Snapshot thường có thể bị xoá nếu kẻ tấn công có quyền quản trị; từ DSM 7.2 có tuỳ chọn snapshot bất biến (immutable), không xoá được trong thời gian khoá. Nên kết hợp với một bản sao lưu nằm ngoài NAS. Chi tiết: Snapshot Replication chống ransomware .

Xử lý khi NAS đã bị mã hoá

Các hướng dẫn chính thức khác nhau tuỳ bối cảnh:

• CISA : cô lập thiết bị khỏi mạng, chụp bộ nhớ trước khi xử lý; chỉ tắt nguồn khi không thể cô lập. Mục tiêu chính là ngăn lây lan sang thiết bị khác.
• Synology (SynoLocker, 2014): tắt máy ngay để tránh thêm file bị mã hoá, sau đó liên hệ hỗ trợ.
• QNAP (Qlocker, 2021): không tắt máy, vì công cụ Malware Remover có thể dừng mã hoá và lấy lại mật khẩu khi máy đang chạy.

Với C3RB3R trên NAS, ngắt mạng không dừng được quá trình mã hoá vì tiến trình chạy trên chính thiết bị. Khoá chỉ còn trong bộ nhớ khi tiến trình mã hoá còn chạy; mã hoá xong là khoá bị xoá. Nguyên tắc: ưu tiên dừng mã hoá; chỉ cố lấy khoá khi tiến trình còn sống.

Bước 1. Xác định mã hoá còn đang diễn ra hay không

Dấu hiệu còn đang mã hoá: số file .LOCK3D tiếp tục tăng, CPU và ổ cứng hoạt động ở mức cao trong Resource Monitor, đèn ổ cứng nháy liên tục.

Bước 2. Dừng mã hoá

• Tạm dừng tiến trình: qua SSH, chạy sudo -i, xác định tiến trình chiếm CPU bằng top (tên libgld ở mẫu đã phân tích), rồi chạy kill -STOP <PID>. Cách này dừng mã hoá nhưng giữ khoá trong bộ nhớ. Không dùng kill -9. Quy trình chụp bộ nhớ: c3rb3r-rescue .
• Tắt nguồn: nếu không thể tạm dừng tiến trình trong 1–2 phút. Giữ nút nguồn hoặc ngắt điện nhanh hơn tắt máy qua DSM. Cách này làm mất khả năng lấy khoá từ RAM, file đang mã hoá dở có thể hỏng, RAID có thể cần kiểm tra lại, nhưng ngăn được việc mã hoá thêm dữ liệu và xoá snapshot.
• Đã có snapshot hoặc bản sao lưu: ưu tiên dừng mã hoá ngay, không cần giữ khoá trong RAM.
• Mã hoá đã kết thúc: ngắt mạng ngay. Tiến trình đã tự xoá khoá khi kết thúc, nên giữ máy chạy không còn giúp lấy khoá ( một nạn nhân chạy máy liên tục 149 ngày vẫn không còn khoá ). Nếu cần điều tra nguyên nhân, nhờ chuyên gia sao lưu nhật ký và ổ đĩa trước khi cài lại.

Bước 3. Bảo toàn hiện trạng

• Không xoá file .L0CK3D, không ghi thêm dữ liệu, không chạy chống phân mảnh, balance hay xoá snapshot trên ổ bị nhiễm: trên ổ Btrfs, dữ liệu gốc của các đoạn bị mã hoá có thể vẫn còn và cứu lại được.
• Không reset, cài lại DSM hay format ổ trước khi cứu xong dữ liệu. Synology lưu ý việc reset sẽ xoá thông tin phục vụ giải mã.
• Giữ lại các file bị mã hoá và read-me3.txt: phần lớn nội dung file lớn vẫn còn nguyên, và công cụ giải mã có thể được phát hành sau.
• Ghi lại thời điểm phát hiện và các thao tác đã thực hiện.
• Không kết nối ổ sao lưu vào NAS đang nhiễm.

Bước 4. Khôi phục dữ liệu

• Cứu phần chưa bị mã hoá: file lớn chỉ bị mã hoá vài đoạn, nên có thể trích xuất phần còn nguyên bằng công cụ cứu dữ liệu .L0CK3D của Nashub . Âm thanh và video thường cứu được phần lớn, ảnh thường chỉ cứu được ảnh xem trước nhúng trong file, file từ 1 MB trở xuống không cứu được. Chỉ làm trên bản sao, không làm trên ổ gốc.
• Snapshot: Snapshot Replication → Recovery, chọn điểm khôi phục trước thời điểm bị mã hoá. Nên chép dữ liệu từ snapshot ra ổ rời trước khi khôi phục đè, do hệ thống vẫn còn mã độc.
• Bản sao lưu ngoại tuyến hoặc cloud: kiểm tra trên một máy tính sạch.
• Xác định ransomware: gửi read-me3.txt và một file mẫu lên ID Ransomware , kiểm tra công cụ giải mã trên No More Ransom .

Bước 5. Làm sạch hệ thống

Sau khi cứu dữ liệu, cài lại DSM theo hướng dẫn reset của Synology, cập nhật bản mới nhất rồi khôi phục dữ liệu. Mã độc cài sẵn tác vụ tự chạy lại (/etc/cron.d/synot*); các tác vụ này tự tạo lại và tải mã độc về tiếp, đã có trường hợp bị tạo lại một ngày sau khi mã hoá. Vì vậy chỉ cập nhật DSM hay xoá file là không đủ; cần ngắt mạng và cài lại DSM. Sau đó đổi toàn bộ mật khẩu, bật 2FA và không mở NAS ra Internet.

Tiền chuộc và báo cáo

• CISA và FBI khuyến cáo không trả tiền chuộc: không có bảo đảm nhận được khoá giải mã.
• Thận trọng với các dịch vụ "mở khoá" xuất hiện sau đợt tấn công.
• Báo cáo Cục An ninh mạng và phòng, chống tội phạm sử dụng công nghệ cao (A05), Bộ Công an. Doanh nghiệp cần thông báo cho khách hàng có dữ liệu liên quan.

Hướng dẫn khôi phục chi tiết: ransomware tấn công Synology: nhận biết và cứu dữ liệu .

Truy cập từ xa an toàn

Không nên để giao diện quản trị NAS truy cập được trực tiếp từ Internet, dù qua mở cổng, QuickConnect hay tunnel. Khi cần truy cập từ xa:

• Dùng VPN (Tailscale, WireGuard, ZeroTier) để chỉ thiết bị được cấp phép vào được mạng nội bộ. Tailscale có gói cài đặt cho Synology.
• Nếu dùng VPN Server trên NAS, cần cập nhật đầy đủ và bật 2FA; đặt VPN trên router là lựa chọn tốt hơn.
• Chỉ mở các dịch vụ thật sự cần thiết.

So sánh các phương án: 7 cách truy cập NAS từ xa , QuickConnect hay VPN .

Khuyến nghị dài hạn

• Sao lưu theo quy tắc 3-2-1: 3 bản dữ liệu, 2 loại thiết bị, 1 bản đặt ở nơi khác và không kết nối thường trực. RAID và bản sao trên cùng NAS không thay thế sao lưu ( quy tắc 3-2-1 ).
• Hạn chế tối đa dịch vụ mở ra Internet.
• Đồng bộ không phải sao lưu: Cloud Sync, Synology Drive hay OneDrive sẽ chép cả file đã bị mã hoá sang bản sao. Giữ ít nhất một bản sao lưu có phiên bản (versioning) hoặc ngoại tuyến, không tham gia đồng bộ thời gian thực.
• Bật cập nhật tự động cho bản vá bảo mật quan trọng; theo dõi trang thông báo bảo mật của Synology.
• Cập nhật cả các ứng dụng tự cài (GitLab, WordPress, Nextcloud…) như với DSM.
• Bật thông báo cho đăng nhập bất thường và hoạt động ổ cứng bất thường.

Câu hỏi thường gặp

NAS chỉ dùng trong mạng nội bộ có bị ảnh hưởng không?

Chưa có báo cáo NAS chỉ dùng nội bộ bị tấn công trực tiếp. Cần kiểm tra IPv6: NAS có địa chỉ IPv6 công khai mà router không bật tường lửa IPv6 thì vẫn truy cập được từ Internet. Rủi ro còn lại là lây từ thiết bị khác trong mạng; nên thực hiện bước 2, 4, 5 và 7.

Chỉ bật QuickConnect, không mở cổng, có an toàn không?

Không chắc chắn. Đã có nạn nhân chỉ dùng QuickConnect hoặc Synology Drive. Nên tạm tắt QuickConnect cho tới khi đường tấn công được xác định.

Đã cập nhật DSM 7.4.1-90080 Update 1 thì sao?

Bản này không bị ảnh hưởng bởi lỗ hổng SA-24:20 mà Synology xác nhận bị khai thác. Tuy vậy, Solar ghi nhận máy bị mã hoá đang chạy đúng phiên bản này và thông cáo của Synology không đề cập trường hợp đó, nên vẫn nên tắt truy cập từ Internet.

File .LOCK3D có giải mã được không?

Chưa có công cụ giải mã dùng chung. Hai nạn nhân đã giải mã được nhờ lấy khoá trong bộ nhớ khi tiến trình mã hoá còn chạy; khoá chỉ dùng được cho đúng máy đó. Ngoài ra, khả năng khôi phục phụ thuộc vào snapshot và bản sao lưu ngoại tuyến.

Phát hiện đang bị mã hoá thì có nên tắt nguồn?

Có, nếu không thể tạm dừng tiến trình trong 1–2 phút; đây cũng là hướng dẫn của Synology trong vụ SynoLocker năm 2014. Ngắt mạng không dừng được mã hoá. Nếu mã hoá đã kết thúc thì khoá đã bị xoá; ngắt mạng ngay, sau đó tắt máy hay giữ máy để điều tra đều được.

Có nên trả tiền chuộc?

Không nên. Không có bảo đảm nhận được khoá giải mã.

Snapshot có giúp khôi phục được không?

Có, nếu snapshot còn nguyên. Snapshot thường có thể bị xoá bởi tài khoản quản trị bị chiếm; snapshot bất biến (immutable) không xoá được trong thời gian khoá.

Synology nói gì về đợt tấn công?

Theo thông cáo ngày 29/10/2026 , kẻ tấn công khai thác một lỗ hổng đã vá từ tháng 12/2024 (SA-24:20) để nhắm vào máy chạy DSM cũ. Synology khuyến cáo cập nhật DSM ngay và bật cập nhật tự động. Máy chạy bản mới hơn các mốc ở cột "Đã vá SA-24:20" đã có bản vá cho lỗ hổng này. Synology chưa phát hành thông báo bảo mật mới cho đợt tấn công.

NAS chip ARM có bị ảnh hưởng không?

Chưa có báo cáo nạn nhân dùng máy ARM, nhưng script phát tán có bản tải riêng cho chip ARM (aarch64, armv7l). Không nên coi máy ARM là an toàn; áp dụng đầy đủ các bước phòng ngừa.

Khách hàng mua NAS tại Nashub cần hỗ trợ liên hệ ở đâu?

Nhắn shop trên Shopee hoặc gửi email về ndphuong.mail@gmail.com để được hướng dẫn tắt truy cập Internet, cập nhật và kiểm tra máy.

Nguồn tham khảo

• Synology: thông cáo về các vụ tấn công ransomware nhắm vào DSM cũ (29/10/2026)
• Synology Trung Quốc: thông cáo tiếng Trung cùng nội dung (29/10/2026)
• Synology-SA-26:13 DSM (18/9/2026)
• Kho phát hành DSM của Synology và ghi chú phát hành DSM 7.4.1-90080 Update 1 (12/10/2026)
• Synology-SA-26:14 PHP2Shell và tuyên bố của Synology về PHP2Shell (22/10, cập nhật 29/10/2026)
• Cảnh báo của đội ứng cứu Solar trên Kanxue (29/10/2026)
• Cảnh báo của 360 về Cerber tấn công NAS Synology (29/10/2026)
• Synology-SA-24:20 DSM (Pwn2Own 2024) (11/2024, vá xong 5/12/2024; CVE-2024-10441)
• Diễn đàn BleepingComputer, chủ đề C3RB3R (trang 4) : báo cáo của nạn nhân Synology và phân tích mã hoá một phần (28–29/10/2026)
• BleepingComputer: C3RB3R dựa trên Conti v3 và SentinelOne: C3RB3R khai thác Confluence (2023)
• Nạn nhân DSM và GitLab CE trên V2EX
• PBX Science: C3RB3R tấn công NAS chưa vá
• Bản vá GitLab CVE-2026-110264
• CISA #StopRansomware Guide , Synology: hướng dẫn xử lý SynoLocker , QNAP: hỏi đáp Qlocker
• Ericality/c3rb3r-dsm-case-20261028 , Benjamin-zlt/c3rb3r-baremetal-rescue và Creeper-OF/synology-c3rb3r-nas-case-study : hồ sơ điều tra số của các nạn nhân khác (29/10/2026)
• soimy/c3rb3r-rescue : kết quả điều tra số và công cụ khôi phục của một nạn nhân (chỉ áp dụng cho mẫu đã phân tích)