Tóm tắt nhanh
- Ngày 28/10/2026, một người dùng Reddit (u/NakamuraHwang) kể lại việc chiếc Synology DS918+ của mình bị ransomware C3RB3R mã hóa một phần dữ liệu. Các tệp bị đổi đuôi thành
.L0CK3D, kèm thư đòi tiền chuộcread-me3.txt.- Máy chạy DSM 7.2.1-69057 Update 5, và giao diện quản trị web mở ra Internet.
- Nhật ký còn sót lại khớp rất sát với kỹ thuật khai thác lỗ hổng CVE-2024-10441 (điểm nguy hiểm 9.8/10). Đây là lỗi cho phép kẻ tấn công chạy lệnh với quyền cao nhất mà không cần mật khẩu. Bản vá đã có từ tháng 11/2024, tức gần hai năm trước.
- Mật khẩu mạnh, xác thực hai lớp (2FA) hay chặn IP sau nhiều lần đăng nhập sai đều không chặn được kiểu tấn công này.
- Chủ máy thoát nạn nhờ ba điều: tắt máy kịp lúc, có sẵn sao lưu theo quy tắc 3-2-1, và xử lý ổ cứng ở chế độ chỉ đọc khi điều tra.
- Tháng 10/2026 cũng là thời điểm nhạy cảm: lỗ hổng PHP2Shell vừa được công bố và ảnh hưởng một số gói ứng dụng trên Synology.
1. Chuyện gì đã xảy ra?
Chủ máy kể rằng anh đã nhiều lần tập dượt tình huống bị tấn công giả định, và lần này buộc phải làm thật trên chính NAS của mình. Anh phát hiện một số tệp đã bị đổi đuôi thành .L0CK3D, trong các thư mục xuất hiện tệp read-me3.txt tự nhận là C3RB3R. Anh lập tức tắt NAS.
Kết quả kiểm tra ban đầu cho thấy một phần dữ liệu đã bị mã hóa, phần còn lại vẫn đọc được. Có vẻ việc tắt máy đã cắt ngang quá trình mã hóa trước khi nó chạy xong. Đến thời điểm đăng bài, anh vẫn chưa có con số thiệt hại cuối cùng.
Thay vì bật lại NAS, anh tháo ổ cứng, gắn sang một máy chủ khác (chạy Proxmox) và chỉ đọc, không ghi để điều tra. Theo nhật ký hệ thống, chuỗi sự kiện diễn ra rất nhanh:
| Thời điểm (giờ máy) | Sự kiện |
|---|---|
| ~13:45 | Một yêu cầu đăng nhập “lạ” gửi tới giao diện web DSM. Nhật ký ghi nhận đăng nhập thất bại. |
| ~13:47 | Tài khoản root (quyền cao nhất) xóa các tệp tạm có tên dạng synotade.<số>. Đây là dấu vết dọn dẹp sau khai thác. |
| Sau đó | Thư đòi tiền chuộc xuất hiện, tệp bắt đầu bị đổi đuôi .L0CK3D. |
Chỉ khoảng hai phút từ lúc yêu cầu độc hại gửi tới đến lúc mã độc chạy với quyền cao nhất.
2. Giải nghĩa nhanh các thuật ngữ
| Thuật ngữ | Hiểu đơn giản |
|---|---|
| Ransomware | Mã độc mã hóa (khóa) tệp của bạn rồi đòi tiền chuộc để đưa “chìa khóa” giải mã. |
| DSM | Hệ điều hành của NAS Synology, chính là giao diện web bạn đăng nhập để quản lý máy. |
| CVE | Mã số định danh quốc tế cho một lỗ hổng bảo mật, ví dụ CVE-2024-10441. |
| CVSS 9.8 | Thang điểm mức độ nguy hiểm từ 0 đến 10. Từ 9.0 trở lên là “Nghiêm trọng” (Critical). |
| RCE không cần xác thực | Kẻ tấn công có thể ra lệnh cho máy của bạn từ xa mà không cần biết mật khẩu. Đây là loại lỗ hổng nguy hiểm nhất. |
| Root | Tài khoản có toàn quyền trên hệ thống, cao hơn cả tài khoản admin bạn thường dùng. |
| Snapshot | “Ảnh chụp” trạng thái thư mục tại một thời điểm, giúp quay lại phiên bản cũ. Lưu ngay trên NAS. |
| Sao lưu 3-2-1 | 3 bản dữ liệu, trên 2 loại phương tiện khác nhau, trong đó 1 bản để ở nơi khác (ngoại vi). |
| IOC | Dấu hiệu nhận biết bị xâm nhập: tên tệp, địa chỉ IP, đường dẫn mà mã độc để lại. |
3. Kẻ tấn công vào bằng cách nào?
3.1. Lỗ hổng bị nghi ngờ: CVE-2024-10441
Theo khuyến cáo bảo mật Synology-SA-24:20 (công bố ngày 05/11/2024), CVE-2024-10441 là lỗi trong tiến trình plugin hệ thống của DSM, được chấm 9.8 – Critical, không cần quyền và không cần người dùng thao tác gì. Lỗi này được phát hiện tại cuộc thi hack Pwn2Own 2024. Với nhánh DSM 7.2.1, bản sửa là 7.2.1-69057 Update 6, phát hành ngày 12/11/2024. Máy của nạn nhân đang ở Update 5, tức chậm đúng một bản cập nhật quan trọng.
Synology ghi mục “Biện pháp giảm thiểu” (Mitigation) là “None”. Nói cách khác, không có cách tạm thời nào: chỉ có cập nhật mới vá được.
Vào tháng 8/2025, nhà nghiên cứu Ryan Emmons của hãng bảo mật Rapid7 công bố chi tiết kỹ thuật tại hội nghị DEF CON 33. Từ đó, cách khai thác lỗi này trở thành kiến thức công khai.
3.2. Giải thích bằng ví dụ đời thường
Hãy hình dung trang đăng nhập DSM như một quầy lễ tân. Bạn điền tên vào phiếu, lễ tân chuyển phiếu vào cho một “bộ phận nội bộ” có quyền rất cao để xử lý.
Phiếu nội bộ có quy ước: mỗi mục bắt đầu và kết thúc bằng một dấu hiệu phân cách đặc biệt. Lỗi nằm ở chỗ lễ tân không kiểm tra xem tên bạn điền có chứa chính các dấu hiệu phân cách đó hay không.
Kẻ tấn công lợi dụng điều này: trong ô “Tên tài khoản”, hắn viết admin, rồi chèn dấu kết thúc, rồi tự viết thêm vài “mục mới” vào phiếu. Đó là những thiết lập môi trường chạy chương trình (như LD_PRELOAD, LD_DEBUG_OUTPUT) khiến hệ thống ghi một dòng lệnh vào lịch chạy tự động (/etc/cron.d/). Bộ phận nội bộ đọc phiếu, tưởng mọi mục đều hợp lệ và làm theo, với quyền root.
Kết quả: lễ tân trả lời “Đăng nhập thất bại”, nhưng lệnh độc hại đã được cài vào hệ thống và chạy ngay sau đó.
Đây là chi tiết quan trọng nhất của vụ việc: thông báo “sai mật khẩu” không có nghĩa là bạn an toàn. Chủ máy nhấn mạnh rằng đây không phải mật khẩu bị đánh cắp; kẻ tấn công không cần mật khẩu.
3.3. Vì sao tường lửa không cứu được?
Chủ máy có cấu hình tường lửa và proxy nhiều lớp. Nhưng để chính anh truy cập được từ xa, cổng web DSM vẫn được cho phép đi qua. Yêu cầu độc hại đi đúng con đường hợp lệ đó và đến thẳng ứng dụng có lỗi. Như anh nhận xét, đó là lỗ hổng thực sự, và thêm một lớp hỏi mật khẩu cũng không giải quyết được.
3.4. Mức độ chắc chắn
Chủ máy khá thận trọng: các dấu vết (ký tự phân cách, biến môi trường, đường dẫn cron, việc root xóa tệp tạm) khớp với kỹ thuật khai thác đã công bố, nên anh khá tự tin. Tuy nhiên anh chưa tái hiện lại, chưa so sánh với bản vá và chưa được Synology xác nhận.
Ngoài ra, máy còn dính hai lỗ hổng mới hơn, cũng 9.8 điểm, trong khuyến cáo Synology-SA-26:13 (18/09/2026). Chưa có bằng chứng chúng được dùng trong vụ này, nhưng điều đó cho thấy một máy chậm cập nhật thường không chỉ hở một cửa.
4. Mã độc đã làm gì sau khi vào được?
Lệnh được cài vào là một đoạn mã hóa Base64. Khi giải mã, đó là một trình tải (downloader): nó tải một kịch bản từ máy chủ của kẻ tấn công rồi chạy. Chủ máy đã tải mẫu về phân tích trong môi trường cách ly, không chạy thử. Theo phân tích của anh, kịch bản này:
- Tìm và tắt các phần mềm diệt virus phổ biến (Avast, AVG, McAfee, Symantec…).
- Nhận diện loại vi xử lý (Intel/AMD x86-64 hay ARM) để tải đúng phiên bản mã độc. Nghĩa là nó nhắm vào nhiều dòng NAS, không riêng DS918+.
- Tạo tệp đánh dấu
/bin/l0ck.encđể tránh chạy trùng. - Tải mã độc chính về
/bin/qnetdvà chạy. Nếu thất bại, tải bản dự phòng/bin/libgld. - Tải thêm các kịch bản khác tùy kết quả (chưa thu thập được nên chưa rõ chúng làm gì).
- Tự xóa dấu vết: xóa tệp mã độc, tệp cron và tệp đánh dấu.
Mẫu libgld chứa các chuỗi C3RB3R, read-me3.txt và .L0CK3D, trùng khớp với những gì xuất hiện trên NAS. Chủ máy lưu ý mẫu được tải sau vụ tấn công nên không chắc giống hệt bản đã chạy.
Dấu hiệu nhận biết (IOC) từ vụ này
| Loại | Giá trị |
|---|---|
| Đuôi tệp bị mã hóa | .L0CK3D (số 0) – có biến thể .LOCK3D (chữ O) |
| Thư đòi tiền chuộc | read-me3.txt |
| Tệp mã độc | /bin/qnetd, /bin/libgld |
| Tệp đánh dấu | /bin/l0ck.enc, /tmp/log.0 |
| Lịch chạy tự động | /etc/cron.d/synot* |
| Tệp tạm khai thác | synotade.<PID> (xuất hiện trong nhật ký xóa rm.log) |
| Máy chủ phát tán (đã “vô hiệu hóa” để không bấm nhầm) | hxxp://46[.]8[.]78[.]122/xdy5.sh |
| Dấu vết trong nhật ký đăng nhập | Tên tài khoản chứa PLUGIN_VALUE_END, LD_PRELOAD, LD_DEBUG_OUTPUT |
Không truy cập địa chỉ trên và không chạy bất kỳ đoạn mã nào trong bài gốc. Quản trị viên diễn đàn r/synology cũng đã ghim cảnh báo tương tự.
5. C3RB3R là ai?
C3RB3R là tên mới của dòng ransomware Cerber, hoạt động từ năm 2016. Nhóm này vận hành theo mô hình “ransomware cho thuê” (RaaS), nghĩa là nhiều nhóm tội phạm khác nhau có thể thuê mã độc để đi tấn công. Cerber có phiên bản cho cả Windows và Linux. Cuối năm 2023, nó từng được phát tán qua lỗ hổng trên máy chủ Confluence chưa vá, cũng dùng một tệp tên qnetd để tải mã độc chính, giống với vụ việc lần này.
Dòng mã độc này thường dùng kết hợp mã hóa AES và RSA. Về lý thuyết, nếu được thực hiện đúng, không thể giải mã nếu không có khóa của kẻ tấn công. Chủ máy đã thử dò tìm khóa còn sót trong bộ nhớ hoán đổi (swap) của DSM bằng nhiều công cụ, nhưng không thành công. Hiện chưa có công cụ giải mã miễn phí nào được biết đến cho biến thể này.
Một người bình luận làm nghiên cứu bảo mật cho biết C3RB3R đã liên tục nhắm vào các máy QNAP và Synology đời cũ suốt năm nay.
6. Vì sao một chiếc NAS “có bảo vệ” vẫn bị hạ?
Nhìn lại mốc thời gian, lỗ hổng không phải là bí mật:
| Thời điểm | Sự kiện |
|---|---|
| 05/11/2024 | Synology công bố SA-24:20 (CVE-2024-10441, 9.8 điểm) |
| 12/11/2024 | Có bản vá cho DSM 7.2.1 (Update 6) |
| 03/2025 | Chi tiết lỗ hổng được công bố rộng rãi |
| 08/2025 | Rapid7 trình bày kỹ thuật khai thác tại DEF CON 33 |
| 18/09/2026 | Synology công bố SA-26:13 với thêm hai lỗi 9.8 điểm (DSM 7.2.1 cần Update 12) |
| 28/10/2026 | NAS chạy DSM 7.2.1 Update 5 bị tấn công |
Khi được hỏi vì sao để NAS chậm cập nhật như vậy, chủ máy giải thích: vài năm trước một bản cập nhật từng làm hỏng hệ thống container của anh, nên anh chuyển sang cập nhật thủ công, rồi chiếc máy cứ thế “đứng yên” ở Update 5 mà anh không để ý. Anh thừa nhận hoàn toàn là lỗi của mình.
Đây là kịch bản rất phổ biến: tắt tự động cập nhật vì một lần gặp sự cố, rồi quên bật lại. Một khi kỹ thuật khai thác đã được công bố, các công cụ quét tự động trên Internet sẽ lần lượt tìm mọi máy chưa vá. Không cần ai “để ý” riêng đến bạn.
Bình luận được nhiều người đồng tình nhất (142 điểm) tóm gọn: đưa trang đăng nhập DSM ra Internet là sai lầm số một, và kể cả có reverse proxy hay chặn theo quốc gia, nếu cổng 5000/5001 vẫn truy cập được từ ngoài thì một lỗi RCE không cần xác thực vẫn đi xuyên qua. Người này gợi ý dùng Tailscale hoặc WireGuard, chỉ mất khoảng 10 phút cài đặt.
7. Điều gì đã cứu dữ liệu?
- Tắt máy sớm. Quá trình mã hóa bị dừng giữa chừng, phần lớn dữ liệu có thể vẫn nguyên.
- Sao lưu 3-2-1 có sẵn từ trước. Đây là điều quyết định: một ngày tồi tệ không trở thành mất trắng.
- Snapshot vẫn còn — nhưng là may mắn. Chủ máy cho biết lần này mã độc chỉ duyệt và mã hóa tệp, không xóa snapshot, nên snapshot trên ổ thứ hai vẫn nguyên vẹn. Tuy vậy, vì kẻ tấn công có quyền root, snapshot thông thường hoàn toàn có thể bị xóa. Không nên coi snapshot trên cùng máy là bản sao lưu.
- Không “sửa” ổ cứng vội. Anh không bật lại DSM, không chạy công cụ sửa lỗi hệ thống tệp, chỉ đọc. Nhờ vậy bằng chứng và dữ liệu còn sót không bị ghi đè.
Một trường hợp khác được hãng cứu dữ liệu Recoveo ghi nhận cho thấy kịch bản tệ hơn nhiều: kẻ tấn công xóa sạch RAID, định dạng ổ USB sao lưu và phá hỏng tệp Hyper Backup để nạn nhân không còn đường lui. Điều này nhấn mạnh rằng bản sao lưu cắm thường trực vào NAS cũng có thể bị phá.
8. Nếu bạn đang bị tấn công: làm gì ngay?
Giai đoạn 1 – Cô lập (vài phút đầu)
- Rút dây mạng hoặc tắt NAS ngay. Mỗi phút trôi qua là thêm tệp bị mã hóa. Trong vụ này, tắt máy đã chặn được quá trình mã hóa.
- Rút mạng giữ lại trạng thái bộ nhớ (hữu ích nếu thuê chuyên gia điều tra), nhưng mã độc có thể vẫn tiếp tục mã hóa dữ liệu trên máy.
- Tắt nguồn dừng mã hóa ngay lập tức. Với người dùng thông thường, ưu tiên dừng thiệt hại.
- Ngắt kết nối mọi ổ sao lưu đang cắm vào NAS (USB, ổ ngoài), tạm dừng tác vụ đồng bộ sang đám mây/NAS khác để bản sao lưu không bị ghi đè bằng tệp đã mã hóa.
- Kiểm tra máy tính trong mạng có ánh xạ ổ mạng tới NAS: rút mạng nếu thấy tệp bị đổi đuôi.
- Chụp ảnh màn hình thư đòi tiền chuộc, ghi lại thời điểm phát hiện.
Giai đoạn 2 – Bảo toàn
- Không bật lại NAS theo cách thông thường, không cài lại DSM, không định dạng, không chạy “sửa lỗi” ổ đĩa.
- Nếu cần tháo ổ, đánh số thứ tự khe cắm cho từng ổ.
- Không vội trả tiền chuộc. Không có gì bảo đảm bạn nhận được khóa, và tiền sẽ nuôi thêm các vụ tấn công khác. Hãy kiểm tra bản sao lưu trước.
- Kiểm tra trang No More Ransom xem có công cụ giải mã miễn phí cho loại mã độc của bạn không.
- Nếu dữ liệu quan trọng mà không có sao lưu, liên hệ dịch vụ cứu dữ liệu chuyên nghiệp trước khi tự thử bất cứ điều gì.
Giai đoạn 3 – Khôi phục
- Coi toàn bộ NAS là đã bị xâm nhập, kể cả khi dữ liệu nhìn có vẻ ổn. Mã độc có quyền root có thể để lại “cửa hậu”.
- Xóa sạch và cài lại DSM bản mới nhất hỗ trợ cho mẫu máy, cập nhật đầy đủ trước khi nối mạng ra ngoài.
- Chọn điểm khôi phục sạch: bản sao lưu trước thời điểm bị tấn công, và kiểm tra lại không có tệp
.L0CK3Dhayread-me3.txt. - Đổi toàn bộ mật khẩu liên quan (tài khoản DSM, tài khoản lưu trong NAS, tài khoản đám mây đồng bộ, Wi-Fi nếu từng lưu trên NAS).
- Không đưa giao diện quản trị ra Internet lần nữa (xem mục 9).
Giai đoạn 4 – Báo cáo
- Báo cho bộ phận hỗ trợ Synology kèm thông tin phiên bản DSM và dấu hiệu nhận biết.
- Với doanh nghiệp tại Việt Nam, có thể thông báo cho Trung tâm Giám sát an toàn không gian mạng quốc gia / VNCERT/CC hoặc cơ quan Công an có thẩm quyền về tội phạm công nghệ cao. Nếu dữ liệu khách hàng có thể bị lộ, cần xem xét nghĩa vụ thông báo theo quy định về bảo vệ dữ liệu cá nhân.
Dành cho người có kỹ thuật: nguyên tắc điều tra “chỉ đọc”
Bài gốc mô tả chi tiết quy trình điều tra trên Linux. Các nguyên tắc chính:
- Xác định đúng ổ của NAS (theo số serial), đặt chế độ chỉ đọc ở mọi tầng: ổ vật lý (
blockdev --setro), mảng RAID (mdadm --assemble --readonly), LVM, máy ảo, và tùy chọn mount. - Khi mount, dùng tùy chọn không phát lại nhật ký (
noloadvới ext4,nologreplay/norecoveryvới Btrfs), vì kể cả mount chỉ đọc vẫn có thể ghi vào đĩa. - Btrfs của Synology có cờ riêng mà kernel mới có thể từ chối. Chủ máy dùng máy ảo cách ly, không mạng với kernel cũ hơn, thay vì “sửa” hệ thống tệp.
- Sao chép nhật ký ra nơi lưu riêng, tính mã băm SHA-256 để bảo toàn bằng chứng. Nhật ký bị đổi đuôi
.L0CK3Dcó thể chỉ bị mã hóa một phần, vẫn tìm được dấu vết. - Giải mã lệnh Base64 ra tệp văn bản để đọc, tuyệt đối không chuyển thẳng vào shell.
- Một người bình luận lưu ý thêm: tắt tự động lắp ráp RAID/LVM (ví dụ khởi động với
rd.md=0 rd.lvm=0) trước khi cắm ổ, vì một số hệ thống tự ghép mảng ở chế độ ghi ngay khi nhận ổ.
9. Nếu bạn chưa bị tấn công: kiểm tra ngay hôm nay
Bảng nhanh: biện pháp nào chặn được kiểu tấn công này?
| Biện pháp | Chặn được lỗi RCE không cần mật khẩu? | Ghi chú |
|---|---|---|
| Mật khẩu mạnh |  Không |
Kẻ tấn công không cần mật khẩu |
| Xác thực 2 lớp (2FA) | Không |
Lệnh chạy trước bước kiểm tra đăng nhập |
| Auto Block (chặn IP sau nhiều lần sai) | Không |
Chỉ cần một yêu cầu |
| Chặn theo quốc gia (geo-block) | Giảm một phần |
Kẻ tấn công dễ dàng dùng máy chủ ở nước khác |
| Reverse proxy / tường lửa cho phép cổng DSM | Không |
Yêu cầu vẫn đi đúng đường hợp lệ |
| Cập nhật DSM kịp thời |  Có |
Vá tận gốc lỗi đã biết |
| Không mở DSM ra Internet, chỉ truy cập qua VPN | Có |
Kẻ tấn công không tiếp cận được trang đăng nhập |
| Sao lưu ngoại tuyến / bất biến | Không chặn, nhưng cứu dữ liệu | Tuyến phòng thủ cuối cùng |
Các biện pháp như mật khẩu mạnh, 2FA, Auto Block vẫn rất cần để chống dò mật khẩu và đánh cắp tài khoản. Chỉ là chúng không đủ khi phần mềm có lỗi.
Danh sách việc cần làm (theo thứ tự ưu tiên)
1. Kiểm tra phiên bản DSM (5 phút)
Vào Bảng điều khiển (Control Panel) → Trung tâm thông tin (Info Center) để xem phiên bản. So với bảng sau (theo khuyến cáo SA-26:13, mới nhất cho DSM tính đến 10/2026):
| Nhánh DSM | Phiên bản an toàn tối thiểu |
|---|---|
| DSM 7.4 | 7.4-90075 trở lên |
| DSM 7.3 | 7.3.2-86009-4 trở lên |
| DSM 7.2.2 | 7.2.2-72806-9 trở lên |
| DSM 7.2.1 | 7.2.1-69057-12 trở lên |
Nếu thấp hơn: cập nhật ngay. Lưu ý Synology đã ghi DSM 7.2 là hết vòng đời (end of life) trong thông báo tháng 10/2026; nếu máy của bạn hỗ trợ DSM 7.3 hoặc 7.4, nên lên phiên bản mới hơn. Kiểm tra phiên bản tối đa cho mẫu máy tại Trung tâm tải về của Synology.
2. Bật cập nhật tự động
Bảng điều khiển → Cập nhật & Khôi phục (Update & Restore) → Cài đặt cập nhật: chọn tự động cài ít nhất các bản cập nhật quan trọng/bảo mật. Nếu từng gặp sự cố khi cập nhật (như chủ máy trong vụ này), hãy chọn “thông báo rồi cài thủ công” nhưng đặt lịch nhắc kiểm tra mỗi tháng — đừng tắt hẳn rồi quên.
3. Đóng cửa DSM với Internet
- Vào trang quản trị router (modem), tìm mục Port Forwarding / NAT / Virtual Server: xóa các luật chuyển tiếp cổng 5000, 5001 hay bất kỳ cổng nào trỏ về NAS mà bạn không thực sự cần.
- Tắt UPnP trên router, và trong DSM vào Bảng điều khiển → Truy cập bên ngoài (External Access) → Cấu hình router để xóa các luật NAS tự tạo.
- Tự kiểm tra từ bên ngoài: tắt Wi-Fi điện thoại, dùng 4G/5G truy cập
https://<IP công cộng nhà bạn>:5001. Nếu thấy trang đăng nhập DSM → bạn đang bị lộ. - QuickConnect cũng đưa trang đăng nhập ra ngoài qua máy chủ trung gian của Synology. Nếu không thực sự cần, hãy tắt.
- Truy cập từ xa bằng VPN thay thế: Tailscale (có gói cài sẵn trong Package Center), VPN Server của Synology, hoặc WireGuard trên router. Với VPN, trang đăng nhập DSM chỉ “nhìn thấy” được khi bạn đã ở trong mạng riêng.
- Nếu bắt buộc phải công khai một dịch vụ (ví dụ chia sẻ ảnh), chỉ mở đúng dịch vụ đó, không mở trang quản trị DSM.
4. Sao lưu đúng cách: 3-2-1, tốt hơn nữa là 3-2-1-1-0
- 3 bản dữ liệu, 2 loại phương tiện, 1 bản ở nơi khác, 1 bản ngoại tuyến hoặc bất biến (không thể sửa/xóa), 0 lỗi khi kiểm tra khôi phục.
- Dùng Hyper Backup sao lưu sang NAS khác, Synology C2 hoặc dịch vụ đám mây, bật lưu nhiều phiên bản để có thể quay về trước thời điểm bị mã hóa.
- Ổ USB sao lưu: rút ra sau khi sao lưu xong, luân phiên hai ổ nếu được. Ổ cắm thường trực có thể bị mã hóa hoặc định dạng cùng NAS.
- Thử khôi phục một vài tệp định kỳ. Bản sao lưu chưa từng được thử khôi phục thì chưa chắc dùng được.
5. Bật snapshot – và snapshot bất biến nếu máy hỗ trợ
- Cài Snapshot Replication, đặt lịch chụp snapshot cho các thư mục chia sẻ quan trọng (ổ phải dùng Btrfs).
- Từ DSM 7.2, Synology có Immutable Snapshots (snapshot bất biến) và thư mục WriteOnce, được thiết kế để chống cả trường hợp tài khoản quản trị bị chiếm. Tính năng này chỉ có trên một số mẫu máy; hãy kiểm tra danh sách hỗ trợ.
- Nhớ rằng snapshot thường không thay thế được sao lưu khi kẻ tấn công có quyền root.
6. Gọn gàng tài khoản và dịch vụ
- Vô hiệu hóa tài khoản
adminmặc định, dùng tài khoản quản trị riêng có tên khác, bật 2FA. - Bật Auto Block (Bảng điều khiển → Bảo mật → Bảo vệ) và tường lửa của DSM: chỉ cho phép dải mạng nội bộ và mạng VPN truy cập cổng quản trị.
- Gỡ hoặc tắt các gói không dùng: Web Station, PHP, WordPress, phpMyAdmin, SSH, Telnet… Mỗi gói là một “cửa” tiềm năng.
- Tài khoản người dùng thường chỉ được cấp quyền đúng các thư mục cần thiết. Máy tính bị nhiễm mã độc sẽ chỉ mã hóa được những gì tài khoản đó có quyền ghi.
7. Giám sát và cảnh báo
- Chạy Security Advisor định kỳ để quét cấu hình yếu và mã độc đã biết.
- Dùng Active Insight để nhận cảnh báo hoạt động tệp bất thường (ví dụ hàng loạt tệp bị đổi tên).
- Bật thông báo đẩy về điện thoại (ứng dụng DS finder hoặc Synology Secure SignIn) để nhận tin khi có sự cố.
- Theo dõi trang Khuyến cáo bảo mật Synology — có thể đăng ký nhận tin qua RSS.
Chủ máy tự nhận xét: cảnh báo không phải là bảo đảm, vì mã độc có quyền root có thể tắt chính công cụ giám sát. Nhưng nhận cảnh báo sớm có thể là khác biệt giữa “một số tệp bị mã hóa” và “mất cả ổ”.
8. Máy đời cũ: đặc biệt cẩn thận
Mẫu máy không còn nhận bản DSM mới nghĩa là các lỗ hổng phát hiện sau này sẽ không bao giờ được vá. Với những máy này, tuyệt đối không mở ra Internet, và cân nhắc thay thế nếu chứa dữ liệu quan trọng.
10. Bức tranh rộng hơn: tháng 10/2026 không yên ả cho người dùng NAS
PHP2Shell – lỗ hổng mới nhất
Ngày 21/10/2026, nhóm phát triển PHP vá hai lỗ hổng nghiêm trọng được gọi chung là PHP2Shell (CVE-2026-109618 và CVE-2026-109619), cho phép chạy mã từ xa không cần xác thực. Theo báo cáo của Amazon, hệ thống bẫy (honeypot) của họ ghi nhận các nỗ lực khai thác từ 17/10, tức bốn ngày trước khi lỗ hổng được công bố. Cơ quan an ninh mạng Mỹ (CISA) cũng khuyến nghị cập nhật gấp.
Ngày 22/10/2026, Synology xác nhận ảnh hưởng chỉ giới hạn ở một số gói dùng PHP: Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station và WordPress. Hãng đã phát hành bản cập nhật PHP cho DSM 7.4, 7.3 và 7.2, khuyên người dùng các gói này cập nhật PHP qua Package Center ngay (riêng MailStation phải cập nhật thủ công). Với DSM cũ hơn 7.2, Synology khuyên tạm tắt các gói bị ảnh hưởng. Thành phần PHP nội bộ của DSM được Synology đánh giá rủi ro rất thấp vì không tiếp xúc trực tiếp với bên ngoài. Chi tiết trong khuyến cáo Synology-SA-26:14.
Việc cần làm: nếu bạn chạy website, WordPress hay bất kỳ gói nào kể trên, vào Package Center cập nhật PHP ngay, và đừng để website trên NAS mở ra Internet nếu không cần thiết.
SA-26:13 – hai lỗi 9.8 điểm mới
Khuyến cáo ngày 18/09/2026 vá hai lỗi nghiêm trọng, không cần xác thực (trong thành phần SCGI và logic đăng nhập) cho phép đọc/ghi tệp tùy ý, cùng nhiều lỗi khác. Synology lại ghi mục giảm thiểu là “None”: chỉ có cập nhật mới vá được. Đáng chú ý, trong danh sách ghi công phát hiện lỗi có các nhà nghiên cứu từ Viettel Cyber Security.
NAS Synology – mục tiêu lâu năm
- 2014: ransomware SynoLocker tấn công các máy DSM chưa cập nhật, đòi khoảng 0,6 Bitcoin.
- 2019: làn sóng tấn công dò mật khẩu hàng loạt vào NAS Synology mở ra Internet, rồi mã hóa dữ liệu.
- 07/2025: cảnh sát Ý phối hợp Pháp và Romania, dưới điều phối của Europol, triệt phá nhóm ransomware “Diskstation” chuyên tấn công NAS Synology, khiến nhiều doanh nghiệp phải ngừng sản xuất.
- 10/2026: vụ C3RB3R trong bài này, khai thác lỗi đã có bản vá gần hai năm.
Điểm chung: thiết bị mở ra Internet và chậm cập nhật.
11. Chủ máy mong Synology làm gì?
Chủ máy cho rằng với lỗi nghiêm trọng cỡ này, Synology nên:
- Gửi email cảnh báo trực tiếp tới khách hàng đã đăng ký, tiêu đề rõ ràng kiểu “Cập nhật bảo mật khẩn cấp: thực thi mã từ xa không cần xác thực”, nói rõ bản DSM nào bị ảnh hưởng và bản nào đã vá — thay vì để lẫn trong tin sản phẩm.
- Hiển thị cảnh báo nổi bật ngay trong DSM khi máy đang chạy bản có lỗ hổng nghiêm trọng.
- Gửi cảnh báo khẩn về điện thoại khi phát hiện hoạt động tệp đáng ngờ (hàng loạt tệp đổi đuôi, thư đòi tiền chuộc xuất hiện ở nhiều thư mục).
Anh cũng thừa nhận Synology đã có Security Advisor và Active Insight, nhưng mong hãng giải thích rõ hơn cho người dùng phổ thông về phạm vi, cách thiết lập và cách nhận cảnh báo của các công cụ này.
Kết luận
Vụ việc này không có “hacker thiên tài” hay kỹ thuật bí ẩn. Đó là một lỗ hổng đã được công bố, đã có bản vá từ gần hai năm, trên một trang đăng nhập không nên mở ra Internet ngay từ đầu. Mật khẩu mạnh và 2FA không giúp gì, vì kẻ tấn công không bao giờ cần đăng nhập thành công.
Ba điều rút ra, cũng chính là những bài học chủ máy tự tổng kết:
- Đừng đưa trang quản trị DSM ra Internet. Dùng VPN.
- Đừng để DSM tụt hậu. Bật cập nhật tự động hoặc ít nhất kiểm tra hằng tháng.
- Có sao lưu độc lập và đã thử khôi phục. Đó là thứ biến thảm họa thành một ngày tồi tệ.
Hãy dành 30 phút tối nay: kiểm tra phiên bản DSM, kiểm tra router, kiểm tra bản sao lưu. Đó là khoản đầu tư rẻ nhất bạn có thể làm cho dữ liệu của mình.
Nguồn tham khảo
- Bài gốc trên Reddit r/synology: Well, it finally happened. My first real ransomware incident – u/NakamuraHwang, 28/10/2026
- Synology-SA-24:20 (CVE-2024-10441)
- Synology-SA-26:13
- Rapid7 – Disguise Delimit: Exploiting Synology NAS with Delimiters and Novel Tricks (DEF CON 33)
- Synology Statement on PHP2Shell Vulnerabilities
- TechRadar – PHP security issues could also threaten your NAS device
- XenoSpectrum – PHP2Shell: NAS patch gap
- SentinelOne – Cerber (C3RB3R) Ransomware
- CYFIRMA – Weekly Intelligence Report, 24/11/2023 (C3RB3R)
- PCrisk – C3RB3R ransomware
- GBHackers – Authorities Take Down “Diskstation” Ransomware Gang
- Recoveo – Data recovery after ransomware attack on Synology NAS
- Synology – DSM 7.2 (Immutable Snapshots, WriteOnce)
- No More Ransom
, diễn biến như sau: