Bùng phát các báo cáo về mã độc tống tiền C3RB3R trong tháng 10/2026. Hai lỗ hổng DSM mức 9,8/10 đã có bản vá, nhưng nhiều NAS vẫn có nguy cơ mất dữ liệu nếu mở dịch vụ ra Internet hoặc thiếu bản sao lưu độc lập.

Hình 1. Minh họa nguy cơ dữ liệu trên NAS bị mã hóa bởi ransomware

Trong những ngày cuối tháng 10/2026, các cộng đồng quản trị NAS liên tục thảo luận về tình trạng tệp trên Synology bị đổi phần mở rộng, xuất hiện thư đòi tiền chuộc và không thể truy cập. Đáng chú ý, ngày 29/10, nhóm chống ransomware của hãng bảo mật 360 cho biết đã tiếp nhận nhiều ca sự cố trong tháng, xác định biến thể C3RB3R thuộc họ Cerber và liên hệ một số ca với hai lỗ hổng DSM công bố từ tháng 9 [1].

Tuy nhiên, hiện chưa có thống kê độc lập đầy đủ về số NAS bị ảnh hưởng trên toàn cầu; cũng chưa thể kết luận mọi trường hợp Synology hay XPEnology bị mã hóa đều do hai CVE này. Muốn xử lý đúng, trước hết phải xác định ransomware chạy trực tiếp trên NAS hay chạy trên một máy tính có quyền ghi vào thư mục chia sẻ.

1. Đợt tấn công tháng 10/2026: Điều gì đã được xác nhận?

• 360 công bố ngày 29/10 rằng nhóm ứng cứu đã phân tích các vụ tấn công C3RB3R nhằm vào NAS Synology; họ nhận định kẻ tấn công đã lợi dụng CVE-2026-13639 và CVE-2026-13684 trong các trường hợp điều tra [1].
• Synology công bố bản vá cho hai lỗ hổng trên từ 18/09/2026, trong cảnh báo Synology-SA-26:13. Cả hai có CVSS 9.8, cho phép kẻ tấn công từ xa đọc hoặc ghi tệp tùy ý và gây từ chối dịch vụ trong điều kiện được mô tả [2].
• Dấu hiệu nổi bật trong mẫu C3RB3R được 360 phân tích: tệp bị thêm đuôi “.L0CK3D” (ký tự thứ hai là số 0) và thư đòi tiền có tên “read-me3.txt”. Cùng dấu hiệu này không tự chứng minh được điểm xâm nhập [1].
• Những tin nói “mọi phiên bản DSM mới nhất đều bị zero-day” chưa đủ căn cứ để khẳng định. Vẫn có thể tồn tại những đường vào khác như ứng dụng cài thêm, mật khẩu lộ hoặc máy trạm nhiễm mã độc.

2. Vì sao NAS bị mã hóa? Ba đường tấn công thường bị nhầm lẫn

Hình 2. Ba kịch bản dẫn đến cùng triệu chứng: dữ liệu trên NAS bị thay đổi hoặc mã hóa.

2.1. Khai thác lỗ hổng trong DSM và dịch vụ mở Internet

Khi mở các cổng quản trị, dịch vụ web hay gói ứng dụng NAS ra Internet, kẻ tấn công có thêm bề mặt để quét phiên bản và tìm lỗ hổng. Với CVE-2026-13639 và CVE-2026-13684, khả năng thao tác tệp từ xa làm cho việc trì hoãn vá lỗi trở nên đặc biệt nguy hiểm. Không phải mọi hành vi đọc/ghi tệp đều tương đương thực thi mã từ xa; từng trường hợp cần chứng cứ kỹ thuật [2, 3].

2.2. Tài khoản quản trị, SSH và ứng dụng trên NAS bị chiếm

Mật khẩu dùng lại, tài khoản “admin” còn bật, dịch vụ SSH/WebDAV/FTP không cần thiết, gói ứng dụng lỗi thời, container hoặc ứng dụng web có lỗ hổng đều có thể là điểm bắt đầu. MFA và tự động chặn IP giúp giảm nguy cơ đăng nhập trái phép, nhưng không thể thay thế việc vá một lỗi không cần xác thực.

2.3. Máy tính Windows hoặc macOS mã hóa dữ liệu qua SMB

Không phải lúc nào NAS cũng bị nhiễm mã độc. Một PC trong mạng bị ransomware có thể dùng tài khoản SMB đã lưu để ghi đè, xóa hoặc mã hóa tệp trong thư mục mạng. Synology từng cảnh báo rõ rằng ransomware chỉ nhắm Windows vẫn có thể làm hỏng dữ liệu NAS khi ổ mạng được gắn với quyền ghi [4]. Vì vậy phải đối chiếu log SMB, địa chỉ IP máy trạm và thời điểm sửa tệp trước khi quy kết NAS bị khai thác.

3. Hai lỗ hổng DSM nghiêm trọng và bản vá cần kiểm tra

Ngày 18/09/2026, Synology phát hành cảnh báo Synology-SA-26:13 cho DSM 7.2.1, 7.2.2, 7.3 và 7.4. Hai mã CVE được 360 nhắc đến là:

CVE-2026-13639 (CVSS 9.8): lỗi entropy không đủ trong logic đăng nhập, có thể cho phép truy cập và thao tác tệp từ xa theo điều kiện của cảnh báo.

CVE-2026-13684 (CVSS 9.8): lỗi mã hóa/escape đầu ra tại thành phần SCGI, cũng có thể dẫn tới đọc/ghi tệp tùy ý và DoS [2].

Lưu ý: đây là ngưỡng bản vá cho cảnh báo SA-26:13, không phải danh sách “phiên bản DSM mới nhất” tại ngày đăng bài. Quản trị viên phải kiểm tra Update & Restore, Security Advisory và từng gói trong Package Center trước khi đưa NAS hoạt động trở lại [2].

4. Synology và XPEnology có khác nhau về rủi ro?

Synology là thiết bị NAS và hệ sinh thái DSM chính hãng. XPEnology thường dùng bộ khởi động (loader) cộng đồng để chạy DSM trên máy tính, máy chủ hoặc máy ảo không phải phần cứng Synology. Chẳng hạn, dự án Arc tự mô tả là loader tùy biến dành cho DSM 7.x; chính tài liệu dự án nhấn mạnh bảo mật DSM do Synology quản lý, còn loader cần được cập nhật riêng và không có kiểm định an ninh chính thức [5].

Điều này KHÔNG chứng minh XPEnology là nguồn phát tán ransomware hay mặc định dễ bị mã hóa hơn. Vấn đề thực tế là các hệ thống XPEnology có thể trì hoãn cập nhật DSM vì lo tương thích kernel, driver, bộ loader, mã máy hoặc gói bổ sung; từ đó kéo dài thời gian phơi nhiễm trước các lỗ hổng đã có bản vá. Không nên tự động nâng cấp kernel hoặc thay loader khi chưa sao lưu độc lập và thử nghiệm trên môi trường thay thế.

Với môi trường doanh nghiệp, không nên xem hệ thống DSM cài không chính thức là nền tảng duy nhất giữ dữ liệu sản xuất quan trọng nếu chưa có kế hoạch kiểm thử, sao lưu và khôi phục độc lập. Đây là khuyến nghị quản trị rủi ro, không phải kết luận về nguyên nhân của chiến dịch C3RB3R.

5. Dấu hiệu nhận biết NAS có thể đang bị ransomware

• Tên tệp hàng loạt bị thêm đuôi lạ; với mẫu C3RB3R do 360 mô tả là “.L0CK3D”, chữ “O” được thay bằng số “0”.
• Thư đòi tiền xuất hiện trong nhiều thư mục, chẳng hạn “read-me3.txt”, kèm yêu cầu trả tiền hoặc địa chỉ website ẩn.
• Số lượng lớn tệp ảnh, tài liệu, kho mã nguồn hay file backup cùng mất khả năng mở trong thời gian ngắn.
• CPU/đĩa có hoạt động bất thường; thay đổi, xóa hoặc đổi tên hàng loạt; log đăng nhập hay phiên SMB phát sinh từ IP, tài khoản, máy trạm lạ.
• Snapshot, tác vụ backup, lịch chạy hoặc tài khoản quản trị bị thay đổi ngoài kế hoạch — có thể là dấu hiệu xâm nhập sâu hơn.

Các dấu hiệu trên cần được kết hợp với nhật ký và mẫu tệp. Chỉ nhìn thấy một phần mở rộng lạ chưa đủ để kết luận tên họ ransomware hoặc xác định khai thác CVE nào.

6. NAS đã bị mã hóa: Quy trình xử lý ưu tiên bảo toàn dữ liệu

Giai đoạn 1 — Ngăn lây lan ngay, không phá hủy chứng cứ

1. Khoanh vùng ngay: chặn truy cập Internet vào NAS (tắt port forwarding, UPnP, quy tắc NAT liên quan), ngắt kết nối các máy trạm nghi nhiễm và hạn chế kết nối LAN tới các share bị ảnh hưởng. Nếu hệ thống đang bị mã hóa liên tục, ưu tiên dừng tổn thất bằng cách cô lập mạng; trường hợp không thể chặn quá trình mã hóa và cần bảo toàn dữ liệu, quyết định tắt máy có kiểm soát với chuyên gia ứng cứu.
2. Không vội reset NAS, nâng cấp firmware, format volume, xóa tập tin khả nghi hay “dọn sạch” log trước khi sao lưu chứng cứ. Nếu có năng lực pháp chứng, ghi nhận hiện trạng, tiến trình, kết nối, thời gian sự kiện rồi tạo bản sao phù hợp.
3. Lưu một vài tệp bị mã hóa, thư đòi tiền, log DSM/Log Center, SMB/File Station, nhật ký firewall/VPN và danh sách phiên đăng nhập. Lưu mẫu vào kho cách ly; không mở hoặc chạy file khả nghi trên máy làm việc.

Giai đoạn 2 — Xác định ransomware chạy ở đâu

4. Đối chiếu thời gian file bắt đầu đổi tên với log đăng nhập DSM, Task Scheduler, gói ứng dụng, container, SSH và thay đổi cấu hình. Nếu có log SMB, xác định tài khoản, địa chỉ IP và tên máy tạo thao tác ghi/xóa hàng loạt.
5. Kiểm tra các PC/máy chủ đang gắn ổ mạng có quyền ghi, đặc biệt những máy sử dụng chung tài khoản SMB. Quét bằng công cụ EDR/antivirus đáng tin cậy từ môi trường sạch; thu thập chứng cứ trước khi xử lý sâu.
6. Kiểm tra phiên bản DSM và gói đã cài, đặc biệt dịch vụ được công bố trên Internet; với XPEnology còn phải ghi lại bản loader và các addon đang dùng. Không kết luận hệ thống “an toàn” chỉ vì đã cài DSM mới nhất.

Giai đoạn 3 — Phục hồi từ nguồn sạch

7. Rà soát snapshot trước thời điểm mã hóa và các bản sao lưu offline/offsite. Ưu tiên khôi phục thử vào thư mục, thiết bị hoặc hệ thống cách ly để kiểm tra tính toàn vẹn, thay vì ghi đè trực tiếp lên nguồn đang cần điều tra.
8. Synology có hướng dẫn khôi phục tệp từ Snapshot Replication > Recovery > Shared Folder, chọn bản snapshot trước sự cố rồi Browse/Copy/Download; thao tác và tên menu có thể thay đổi tùy DSM, model và quyền người dùng [6].
9. Sau khi tìm được đường xâm nhập và loại bỏ nguyên nhân, dựng lại NAS/hệ thống từ ảnh cài đặt tin cậy; vá DSM và package, thay toàn bộ mật khẩu, thu hồi token, kiểm tra khóa SSH, phiên đăng nhập và cấu hình NAT, phân quyền share theo nguyên tắc tối thiểu.
10. Chỉ mở lại kết nối người dùng theo từng nhóm sau khi xác nhận bản sao sạch, giám sát log không có hành vi lạ và đã kiểm thử khôi phục dữ liệu nghiệp vụ. Không nhập bản backup nghi nhiễm vào hệ thống sản xuất.

Không có công cụ giải mã “vạn năng” bảo đảm giải được C3RB3R. Không gửi dữ liệu nhạy cảm hoặc dữ liệu khách hàng lên website giải mã không rõ danh tính. Trả tiền chuộc không bảo đảm được cấp khóa hợp lệ hay ngăn rò rỉ dữ liệu.

7. Checklist 10 điểm phòng chống mất dữ liệu NAS

01. Vá DSM và toàn bộ gói ứng dụng; với XPEnology kiểm tra tính tương thích loader/addon trước khi cập nhật, có bản backup đã thử khôi phục.

02. Không public DSM 5000/5001, SSH 22, SMB 445 hoặc dịch vụ không cần thiết trực tiếp ra Internet; rà soát NAT, UPnP, IPv6 và reverse proxy.

03. Dùng VPN hoặc truy cập hạn chế IP cho quản trị từ xa; MFA cho quản trị, tắt tài khoản admin mặc định và tài khoản không còn dùng.

04. Bật DSM Firewall, Auto Block, Account Protection và Security Advisor; thiết lập cảnh báo qua email/ứng dụng độc lập.

05. Phân tách VLAN quản trị NAS, máy trạm, camera, IoT; hạn chế SMB đến đúng nhóm máy có nhu cầu.

06. Mỗi người dùng và ứng dụng dùng tài khoản riêng; cấm dùng chung tài khoản admin để truy cập share, giới hạn quyền ghi và xóa.

07. Bật Snapshot Replication trên Btrfs (nếu hệ thống hỗ trợ), cân nhắc immutable snapshot và kiểm tra dung lượng/chu kỳ giữ bản [7].

08. Áp dụng 3-2-1-1-0: 3 bản dữ liệu, 2 môi trường lưu trữ, 1 bản ngoài địa điểm, 1 bản offline/immutable và 0 lỗi sau kiểm thử restore.

09. Giám sát biến động file hàng loạt, dung lượng, đăng nhập bất thường; duy trì nhật ký ở hệ thống tập trung để tránh bị xóa khi NAS bị chiếm.

10. Mỗi quý thực hành kịch bản khôi phục từ snapshot và backup độc lập; định nghĩa RPO/RTO cho dữ liệu sản xuất.

8. PHP2Shell có phải thủ phạm của đợt tấn công này?

Không nên đánh đồng. Ngày 22/10 và trong các cập nhật đến 29/10/2026, Synology xác nhận PHP2Shell (CVE-2026-109618, CVE-2026-109619) có thể ảnh hưởng một số gói phụ thuộc PHP như Web Station, WordPress, phpMyAdmin, MailStation... Nhà sản xuất phát hành cập nhật PHP qua Package Center và khuyến cáo người dùng gói bị ảnh hưởng cài đặt ngay [8].

Đó là một rủi ro riêng cần xử lý. Hiện không có đủ căn cứ để quy toàn bộ các vụ C3RB3R tháng 10 cho PHP2Shell, hoặc kết luận chỉ cần tắt PHP là NAS được bảo vệ trước ransomware. Riêng Synology Drive không nằm trong danh sách gói bị PHP2Shell ảnh hưởng theo thông cáo của hãng [8].

9. Kết luận: Cập nhật bản vá là điều kiện cần, backup độc lập mới là đường lui

Điểm chung của nhiều vụ NAS mất dữ liệu không nhất thiết là một lỗ hổng duy nhất, mà là sự kết hợp của dịch vụ bị phơi Internet, vá lỗi chậm, đặc quyền rộng và bản sao lưu còn nằm trong cùng miền tin cậy với NAS. Chiến dịch C3RB3R được công bố ngày 29/10 nhấn mạnh tính cấp bách của việc rà soát các thiết bị DSM chưa vá [1, 2].

Nếu đang quản trị Synology hoặc XPEnology, hãy ưu tiên ba hành động: kiểm tra version DSM và các gói, rà soát mọi cổng đang public, xác minh có thể khôi phục bản sao lưu offline/immutable. Nếu đã có dấu hiệu bị mã hóa, hãy cô lập trước, giữ chứng cứ rồi mới tiến hành sửa chữa. Việc xử lý đúng trong giờ đầu có thể quyết định khả năng cứu được dữ liệu.

Góc dành cho quản trị viên: Câu hỏi thường gặp

NAS không mở Internet thì có bị mã hóa không? Có. Một máy tính trong LAN có quyền ghi qua SMB vẫn có thể mã hóa dữ liệu trên NAS, kể cả khi DSM không có IP công cộng [4].

Có RAID 5/6/SHR là đủ không? Không. RAID phục vụ tính sẵn sàng khi ổ đĩa lỗi; ransomware có thể mã hóa dữ liệu hợp lệ trên toàn bộ volume. Phải có snapshot và backup độc lập.

Tắt port 5000/5001 là hết nguy cơ? Không. Các dịch vụ khác, VPN lỗi thời, gói web/SSH, tài khoản lộ hoặc client SMB vẫn có thể tạo đường vào.

XPEnology có thể cập nhật DSM như máy chính hãng? Phải kiểm tra loader, model giả lập, driver và tương thích từng bản; nên sao lưu và thử restore trước, không cập nhật mù trên hệ thống sản xuất [5].

Nguồn tham khảo

1. 360 Security, “Cerber ransomware attack warning for Synology NAS”, 29/10/2026  Xem nguồn gốc

2. Synology, Security Advisory SA-26:13, 18/09/2026  Xem nguồn gốc

3. Cyber Security Agency of Singapore, cảnh báo DSM, 23/09/2026  Xem nguồn gốc

4. Synology, “How can I protect my Synology NAS against WannaCry?”  Xem nguồn gốc

5. Arc Loader, “Security Policy” (XPEnology)  Xem nguồn gốc

6. Synology, “How do I recover individual files using snapshots?”, 20/01/2026  Xem nguồn gốc

7. Synology, “What is an immutable snapshot?”, 16/09/2026  Xem nguồn gốc

8. Synology, cập nhật chính thức về PHP2Shell, đến 29/10/2026  Xem nguồn gốc

9. Synology, “How can I back up my Synology NAS?”, 08/05/2026  Xem nguồn gốc

• • 30/10/2026