NAS Synology bị mã hóa C3RB3R: phòng tránh thế nào?

Cuối tháng 10/2026, một đợt ransomware đang mã hóa hàng loạt NAS Synology lộ ra Internet. File bị đổi đuôi thành .L0CK3D, mỗi thư mục xuất hiện một thư đòi tiền chuộc, và hiện chưa có công cụ giải mã miễn phí nào. Bài này tổng hợp chuyện gì đang xảy ra, kẻ tấn công vào bằng đường nào, và quan trọng nhất là danh sách nên làm và không nên làm để NAS của bạn không trở thành nạn nhân tiếp theo. Nội dung đối chiếu các cố vấn bảo mật của Synology và báo cáo ứng cứu sự cố tính tới ngày 30/10/2026; phần nào chưa ngã ngũ mình sẽ nói rõ là chưa ngã ngũ.

Chuyện gì đang xảy ra

Từ đầu tháng 10/2026, đội chống ransomware của hãng bảo mật 360 (Trung Quốc) đã tiếp nhận nhiều ca NAS Synology bị mã hóa. Cộng đồng báo cáo bùng lên ngày 28–29/10, tới ngày 30/10 thì Hàn Quốc cũng ghi nhận hàng loạt ca, cơ quan ứng cứu KISA nhận nhiều báo cáo thiệt hại.

Dấu hiệu nhận biết thống nhất ở mọi nguồn. File bị đổi đuôi thành .L0CK3D (một số báo cáo ghi .LOCK3D), mỗi thư mục xuất hiện thư đòi tiền chuộc read-me3.txt với dòng “C3RB3R INSTRUCTIONS” dẫn tới một trang Tor bán “C3RB3R DECRYPTOR”. Tiền chuộc là 0,036960 BTC (khoảng 2.950 USD), sau 5 ngày tăng gấp đôi lên 0,073920 BTC. Mã độc quét từ gốc hệ thống Linux, mã hóa cả /volume1, /volume2, thư mục chia sẻ, tài liệu phát triển, ảnh database và cả file backup trên cùng máy.

C3RB3R được 360 nhận định là biến thể của Cerber, dòng ransomware hoạt động từ năm 2016 theo mô hình cho thuê (RaaS), có bản cho cả Windows và Linux. Một số nhà nghiên cứu khác thấy dấu vết mã Conti bị rò rỉ, nên nguồn gốc của nó vẫn còn tranh cãi. Cách mã hóa các nguồn mô tả chưa thống nhất: có nơi nói ChaCha8 + RSA-2048, có nơi nói RSA-4096 + AES/ChaCha20. Điểm chung chắc chắn duy nhất là hiện chưa có công cụ giải mã miễn phí, và trả tiền cũng không có gì bảo đảm sẽ nhận được key.

Kẻ tấn công vào bằng đường nào

Đây là phần cần nói cẩn thận, vì tới nay chưa có bên nào kết luận dứt khoát một cửa duy nhất. Có bốn cửa được nêu tên, và phòng tránh đúng nghĩa là bịt cả bốn.

Cửa thứ nhất: lỗ hổng DSM CVE-2026-13639 và CVE-2026-13684. Đây là giả thuyết chính của 360. Hai lỗ hổng này nằm trong cố vấn Synology-SA-26:13, công bố ngày 18/9/2026, cùng đạt CVSS 9.8. Một cái là lỗi thiếu entropy trong logic đăng nhập, một cái là lỗi mã hóa đầu ra trong thành phần SCGI. Cả hai đều cho phép kẻ tấn công từ xa, không cần đăng nhập, đọc và ghi file tùy ý, đồng thời gây từ chối dịch vụ. Synology không đưa ra cách khắc phục tạm thời nào — cài bản vá là cách sửa duy nhất. Các bản DSM đã vá: 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 và 7.2.1-69057-12 trở lên. Cố vấn SA-26:13 thực ra bao quát 8 lỗ hổng, nhưng hai lỗ này là nghiêm trọng nhất.

Cửa thứ hai: lỗ hổng cũ CVE-2024-10441. Lỗi thực thi mã từ xa không cần xác thực này được phát hiện tại Pwn2Own 2024 và vá từ tháng 11/2024, cũng đạt CVSS 9.8. Ca Synology DS918+ được một người dùng Reddit kể lại ngày 28/10 khớp rất sát kỹ thuật này: máy chạy DSM 7.2.1-69057 Update 5, giao diện web mở ra Internet, gần 18 tháng không cập nhật bảo mật. Chủ máy thoát nạn một phần nhờ tắt máy kịp lúc cắt ngang quá trình mã hóa, cộng với sao lưu 3-2-1 có sẵn.

Cửa thứ ba: container Docker lộ ra ngoài. Một số nạn nhân chạy GitLab, Confluence hoặc dịch vụ web khác trong Container Manager và map cổng ra mạng ngoài. Các lỗ hổng RCE gần đây trên GitLab (CVE-2026-110264, CVE-2026-97229) cộng với mount đặc quyền có thể giúp kẻ tấn công thoát container, ghi script độc vào tác vụ định kỳ crond của host và từ đó chiếm toàn bộ NAS.

Cửa thứ tư: PHP2Shell. Cố vấn Synology-SA-26:14 xác nhận hai lỗ hổng thực thi mã từ xa trong PHP core, CVE-2026-109618 và CVE-2026-109619, ảnh hưởng MailStation, Synology Calendar và các gói native khác. Điểm đáng chú ý là bản vá cho nhóm này nằm ở gói ứng dụng, không nằm trong DSM — nghĩa là cập nhật DSM thôi vẫn chưa đủ nếu gói còn cũ.

Và còn một đuôi chưa giải quyết: một đội ứng cứu (Solar) xử lý nạn nhân đã chạy DSM 7.4.1-90080 Update 1 mà vẫn bị, nên chưa loại trừ được lỗ hổng DSM mới, gói bên thứ ba hay credential bị lộ. Theo mình, chính đuôi này mới là lý do phải phòng thủ theo chiều sâu thay vì chỉ vá một chỗ rồi yên tâm.

Vì sao đợt này lan nhanh

Theo mình, đợt này không phải câu chuyện zero-day mà là câu chuyện trễ vá. Bản vá cho hai lỗ DSM đã có từ 18/9, tức khoảng 6 tuần trước khi tấn công bùng lên — kẻ tấn công chỉ việc quét tự động những máy chưa cập nhật. Đây là mẫu “1-day” kinh điển: khoảng trống giữa ngày công bố bản vá và ngày máy được vá chính là cửa sổ tấn công.

Sai lầm thứ hai là coi NAS là backup trong khi nó vẫn online và ghi được. Mã độc mã hóa luôn cả thư mục Hyper Backup trên cùng máy nếu bản backup đó không bật khóa phiên bản đa thế hệ và không có bản sao off-site. RAID cũng không cứu được ở đây: RAID chống hỏng ổ, không chống mã hóa — ransomware mã hóa mọi volume ghi được mà nó chạm tới.

Sai lầm thứ ba là bề mặt tấn công dạng chùm. DSM lộ Internet, gói ứng dụng cũ, container map cổng — ba cửa độc lập, bịt một cửa vẫn vào được bằng hai cửa còn lại. Và một điểm nữa đáng ghi nhận: báo chí Hàn Quốc chỉ trích Synology cảnh báo chậm, khi thiệt hại đã lan ở nước ngoài và các hãng bảo mật đã công bố phân tích mà hãng vẫn chưa có cảnh báo riêng, mãi sau mới công bố và chỉ hướng dẫn khôi phục từ backup, không có công cụ giải mã hay kế hoạch bồi thường. Dù đánh giá thế nào về tốc độ truyền thông của hãng, bài học cho người quản trị vẫn như cũ: đừng chờ hãng nhắc mới vá.

Nên làm ngay

Danh sách này xếp theo thứ tự ưu tiên: làm từ trên xuống, và làm trong hôm nay nếu NAS của bạn đang lộ ra Internet.

1. Cập nhật DSM lên bản đã vá. Vào Control Panel → Update & Restore, lên 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 hoặc 7.2.1-69057-12 trở lên tùy nhánh DSM của máy. Bật cập nhật tự động nếu máy hỗ trợ, để lần sau không lặp lại khoảng trống 6 tuần như đợt này.

2. Cập nhật tất cả gói ứng dụng trong Package Center. Đây là bước hay bị bỏ sót nhất mà lại quyết định: bản vá PHP2Shell nằm ở gói, và một NAS chạy DSM mới nhưng gói cũ vẫn mở cửa cho kẻ tấn công. Gỡ luôn những gói không dùng tới — MailStation, Calendar hay bất kỳ gói nào không còn phục vụ ai thì không có lý do gì để tồn tại trên máy lộ Internet.

3. Đóng hết port forward ra NAS. Vào router gỡ các rule trỏ tới NAS: cổng DSM 5000/5001, SSH 22, SMB 445 và mọi cổng Docker map ra ngoài. Truy cập từ xa chỉ đi qua VPN. Tắt QuickConnect nếu không thật sự cần, vì đó cũng là một đường vào từ Internet.

4. Giữ backup 3-2-1 thật, không phải backup trên giấy. Ít nhất một bản sao off-site (máy khác, cloud hoặc ổ rời cất riêng), bật khóa phiên bản cho Hyper Backup để ransomware không xóa hay sửa được bản cũ, bật snapshot Btrfs với thời gian lưu giữ đủ dài. Sau đó kiểm tra hai thứ: lần backup thành công gần nhất là khi nào, và lần test khôi phục gần nhất là khi nào. Chưa từng test restore thì chưa thể gọi là có backup.

5. Siết tài khoản và quyền truy cập. Tắt tài khoản admin mặc định, đặt mật khẩu mạnh và riêng cho từng tài khoản, bật xác thực hai lớp, bật auto-block sau nhiều lần đăng nhập sai. Nói rõ để khỏi ảo tưởng: mấy biện pháp này chặn được brute-force, nhưng không chặn được khai thác lỗ hổng — vì đợt này kẻ tấn công không cần đăng nhập. Chúng vẫn phải có, chỉ là không đủ một mình.

6. Bật tường lửa DSM và giới hạn IP quản trị. Chỉ cho phép dải IP nội bộ hoặc IP VPN truy cập trang quản trị, bật thông báo và theo dõi đăng nhập lạ. Rà soát luôn các container đang chạy: container nào map cổng ra ngoài mà không ai nhớ mục đích thì dừng lại và xem xét.

7. Rà soát toàn bộ NAS trong hệ thống. Không chỉ con NAS chính mà cả mấy con “chìm” ở phòng ban, chi nhánh, phòng lab — một con quên vá, lộ Internet là đủ thành cửa vào. Lập danh sách, ghi rõ phiên bản DSM và ngày vá của từng con, con nào chưa đạt thì xử lý có thời hạn.

Ngoài phòng tránh bị động, chủ động kiểm tra hệ thống bằng pentest cũng giúp phát hiện cửa hở trước kẻ tấn công — mình đã viết riêng về Shannon, AI pentester khai thác thật rồi mới báo cáo cho ai muốn gắn kiểm tra bảo mật vào quy trình.

Không nên làm

Đừng mở trang quản trị DSM trực tiếp ra Internet. Đây là mẫu số chung của gần như mọi nạn nhân đợt này. Tiện một lúc, trả giá bằng toàn bộ dữ liệu.

Đừng trì hoãn vá. Khoảng trống giữa ngày có bản vá và ngày máy được vá chính là thời gian kẻ tấn công làm việc. Lịch vá nên có ngày cố định, và NAS lộ Internet phải nằm trong nhóm vá ưu tiên cao nhất.

Đừng coi RAID là backup, và đừng chỉ backup trên cùng một máy. RAID chống hỏng ổ đĩa, không chống mã hóa, không chống xóa nhầm, không chống cháy nổ. Backup trên cùng NAS mà không khóa phiên bản thì mã độc mã hóa luôn cả bản backup đó.

Đừng tưởng mật khẩu mạnh hay 2FA là đủ. Đợt này tấn công qua lỗ hổng, không qua đăng nhập. Mật khẩu và 2FA là lớp cần thiết nhưng không phải lớp quyết định ở đây.

Đừng trả tiền chuộc. Không có công cụ giải mã công khai, không có gì bảo đảm trả tiền sẽ nhận được key, và tiền đó nuôi tiếp mô hình ransomware cho thuê để tấn công người khác.

Nếu đã nhiễm thì xử lý theo thứ tự nào

Phát hiện file đổi đuôi .L0CK3D và thư read-me3.txt thì bình tĩnh làm theo thứ tự sau:

1. Ngắt mạng ngay: gỡ port forward, tắt QuickConnect và mọi đường truy cập ngoài, nhưng đừng vội tắt nguồn, reboot hay cài lại nếu quá trình mã hóa còn đang chạy. Từng có ca chuyên gia tạm dừng tiến trình mã hóa và khôi phục được khóa từ bộ nhớ — tắt máy vội có thể xóa luôn cơ hội đó. Trường hợp không ngắt mạng được thì mới tính tới tắt nguồn, theo đúng khuyến cáo của Synology.
2. Giữ nguyên hiện trường: đừng format, đừng khởi tạo lại ổ, đừng xóa snapshot hay log. Mọi thứ còn lại đều là chứng cứ và là cơ hội khôi phục.
3. Kiểm tra snapshot Btrfs và bản backup off-site sạch, khôi phục từ đó thay vì nghĩ tới chuyện trả tiền.
4. Ghi lại thời gian phát hiện, thông tin hệ thống, log đăng nhập và liên hệ bộ phận hỗ trợ của Synology cũng như đội ứng cứu nội bộ.

Kết luận

Theo mình, đợt C3RB3R này không có gì bí ẩn về kỹ thuật, và đó chính là điều đáng sợ của nó: toàn bộ chuỗi tấn công đều dựa trên những việc quản trị cơ bản bị bỏ qua — vá chậm, lộ cổng, backup cùng máy, không test khôi phục. Bốn việc quyết định vẫn là: đóng cửa ngoài, vá đủ cả DSM lẫn gói, backup off-site có khóa phiên bản, và test khôi phục định kỳ. Làm đủ bốn việc đó thì đợt tấn công này gần như không chạm được vào mình.

Có một đuôi chưa khép lại cần nhớ: ca máy đã chạy DSM 7.4.1 mới nhất mà vẫn bị cho thấy vá DSM thôi có thể chưa đủ, nên lớp phòng thủ phải bao gồm cả gói ứng dụng, container và credential. Bài này đối chiếu tới ngày 30/10/2026; diễn biến mới về cửa vào sẽ còn được cập nhật khi các đội ứng cứu công bố kết luận.

Tham khảo

• Cố vấn Synology-SA-26:13 (18/9/2026) và Synology-SA-26:14 về các lỗ hổng DSM và PHP2Shell.
• Phân tích của đội chống ransomware 360 về C3RB3R, qua PBXScience.
• Hướng dẫn nhận biết và khôi phục của NoRansom.
• Tổng hợp chiến dịch L0CK3D của Guru3D.
• Báo cáo thiệt hại tại Hàn Quốc của Chosun.