C3RB3R / .L0CK3D trên NAS: TUNGTEK phân tích Ticket #1377 và cảnh báo bảo toàn dữ liệu

Ticket #1377: điều hồ sơ cho biết và điều còn thiếu

Khi NAS vẫn hiện đủ ổ và RAID chưa báo lỗi, người quản trị dễ kỳ vọng rằng chỉ cần sửa quyền hoặc đổi lại đuôi là mở được file. Nhưng tính sẵn sàng của mảng đĩa và nội dung dữ liệu là hai lớp khác nhau. Một hệ thống lưu trữ hoạt động bình thường vẫn có thể lưu những file đã bị thay đổi bằng thao tác hợp lệ dưới tài khoản bị chiếm quyền.

Theo tài liệu TUNGTEK cung cấp cho kỳ biên tập TEKLink218, ca #1377 được tiếp nhận ngày 28/10. Khoảng 5 TB là dung lượng ước tính được mô tả trong hồ sơ, chưa phải số byte ciphertext đã kiểm đếm. Không thể từ con số này suy ra mọi file đều bị mã hóa, đã bị lấy ra ngoài hoặc có cùng khả năng phục hồi.

Hồ sơ còn nêu 05 lượt tiếp nhận Ransomware Recovery trong tháng 10/2026. Đây là số tự ghi nhận trong vận hành của TUNGTEK, không phải 05 ca C3RB3R và không đại diện cho tình hình ransomware tại Việt Nam.

Mẫu tài liệu và chênh lệch 588 byte nói được điều gì?

Bản mô tả phân tích tĩnh của TUNGTEK ghi một mẫu tài liệu có kích thước 91.641 byte, entropy khoảng 7,9964/8 và không còn chữ ký DOCX/ZIP thường gặp ở đầu file. Cách diễn giải tám byte cuối cho giá trị kích thước gốc ứng viên 91.053 byte; hiệu số là 588 byte. Ransomware.VN dùng số liệu đã làm sạch trong hồ sơ, không công khai file gốc, tên tài liệu hoặc hash riêng tư.

Đây là quan sát trên một mẫu. Entropy cao phù hợp với dữ liệu ngẫu nhiên hoặc đã được biến đổi, nhưng riêng chỉ số đó không xác định thuật toán, khóa hay mức mã hóa của toàn NAS. Muốn củng cố giả thuyết cấu trúc file, cần nhiều mẫu đại diện theo kích thước, định dạng và thời điểm, tốt nhất có bản trước sự cố để đối chiếu.

Tường thuật cộng đồng được dẫn bên dưới cũng mô tả chênh lệch 588 byte trên một mẫu khác. Sự tương đồng gợi ý hướng kiểm tra định dạng; chưa chứng minh cùng payload, cùng khóa hoặc cùng người vận hành. Cắt 588 byte không biến ciphertext trở lại DOCX. Mọi thử nghiệm phải diễn ra trên bản sao và được kiểm tra bằng ứng dụng thực tế.

C3RB3R, Cerber và giới hạn của việc nhận diện từ tên

Nghiên cứu SentinelOne và Huntress mô tả các chiến dịch khai thác Confluence CVE-2023-22518 trong bối cảnh năm 2023. Mẫu Windows được nghiên cứu dùng đuôi .L0CK3D, note read-me3.txt và có thể tác động SMB share mà máy đó truy cập được. Đây là tài liệu tham chiếu lịch sử, không phải một chiến dịch Confluence mới được xác nhận ở #1377.

Vì thế, dữ liệu trên NAS bị mã hóa chưa đủ chứng minh mã độc đã chạy trong hệ điều hành NAS. Cần phân biệt ít nhất hai hướng điều tra: thực thi trực tiếp trên thiết bị lưu trữ, hoặc thao tác từ endpoint/máy chủ có quyền ghi share. Log NAS, SMB, endpoint, xác thực và mạng phải được nối với nhau trước khi chọn một hướng làm kết luận.

Tên Cerber/C3RB3R trong một công cụ giải mã hoặc báo cáo cũ cũng không tự xác nhận khả năng tương thích với mẫu hiện tại. Phiên bản, cấu trúc file, khóa và phạm vi mà nhà phát hành hỗ trợ mới là căn cứ cho quyết định thử công cụ.

Ca Synology DS918+ công khai là một hồ sơ riêng

Trong bài tường thuật trên r/synology được đối chiếu ngày 29/10/2026, người đăng mô tả DS918+ chạy DSM 7.2.1-69057 Update 5, giao diện web truy cập được từ Internet và một phần file mang đuôi .L0CK3D. Họ cho rằng log còn lại phù hợp CVE-2024-10441, đồng thời nói rõ chưa được Synology xác nhận.

Người đăng chuyển ổ sang môi trường Proxmox để kiểm tra sau sự cố; Proxmox không được mô tả là đường vào. Họ chưa có kết quả khôi phục cuối cùng và không tạo đầy đủ forensic image cho mọi ổ. Những giới hạn đó quan trọng hơn việc gọi đây là một ca “đã điều tra xong”.

Mốc đăng nhập thất bại rồi dọn file dưới quyền root trong lời kể là đầu mối đối chiếu log, chưa chứng minh toàn bộ chuỗi khai thác. Bài cộng đồng cùng một hồ sơ tiếp nhận tại TUNGTEK cũng chưa đủ để gọi là tấn công Synology “hàng loạt”.

Ba khuyến cáo Synology cần đọc riêng

SA-24:20 công bố 05/11/2024, cập nhật 28/03/2025, gồm CVE-2024-10441 và các CVE khác. Riêng CVE-2024-10441 là RCE nghiêm trọng trong system plugin daemon; nhánh DSM 7.2.1 có mốc sửa 7.2.1-69057-6. Phiên bản thấp hơn mốc vá cho thấy cần xử lý phơi nhiễm, chưa chứng minh lỗi đã được khai thác trong một sự cố cụ thể.

SA-26:13 ngày 18/09/2026 là nhóm lỗi DSM khác, với điều kiện khai thác khác nhau. Không nên rút gọn cả advisory thành một lỗi RCE hoặc coi đó là nguyên nhân C3RB3R.

SA-26:14 ngày 22/10/2026 xử lý PHP2Shell, CVE-2026-109618/109619, ở các gói liên quan. Thông báo cập nhật 28/10 phân biệt PHP/gói phụ thuộc và PHP nội bộ DSM; Synology Drive không bị PHP2Shell ảnh hưởng. Bản cho DSM 6.2 mới được thông báo lịch 29/10, chưa thể từ đó khẳng định đã phát hành.

Các mốc trên không phải tuyên bố phiên bản mới nhất cho mọi model. Đối chiếu đúng thiết bị, nhánh DSM, gói và tình trạng hỗ trợ. Nếu thiết bị đang là nguồn chứng cứ, ưu tiên cô lập và thu thập trước; thực hiện cập nhật trong pha khôi phục sạch theo kế hoạch. Chưa có nguồn nào ở đây xác nhận ba advisory là đường vào của #1377.

Dấu hiệu săn tìm: giữ nguồn và ngữ cảnh

Về thực hành, hãy lập timeline từ DSM/auth/web log nếu áp dụng, SMB, VPN, SSH, firewall, reverse proxy, endpoint và job sao lưu. Ghi timezone, độ lệch đồng hồ, lần cuối file còn mở được và thời điểm đầu tiên ghi nhận note. Một đăng nhập thất bại không tự loại trừ lỗi ứng dụng; ngược lại, một tên tiến trình lạ cũng chưa tự chứng minh ransomware.

Ransomware.VN không công bố payload, lệnh khai thác, token nạn nhân, địa chỉ Tor cá nhân hóa hoặc hash mẫu riêng tư. Hash dùng nội bộ để kiểm tra tính toàn vẹn vẫn cần lưu trong biên bản; không cần đưa lên bài công khai.

Restore, extract và decrypt là ba công việc khác nhau

Khi rà soát No More Ransom, chưa xác minh được công cụ công khai tương thích với mẫu của #1377. Công cụ CERBER V1 trong danh mục không phải xác nhận cho .L0CK3D. Đây là giới hạn kiểm chứng tại thời điểm biên tập, không phải khẳng định tuyệt đối rằng không tồn tại công cụ.

Việc trích xuất một tài liệu chưa bị mã hóa hoặc khôi phục từ backup không đồng nghĩa đã phá được thuật toán. Dữ liệu bị mã hóa, xóa, ghi đè và đánh cắp cũng cần được đánh giá riêng. Mở lại được file không giải quyết hậu quả nếu trước đó dữ liệu đã bị sao chép ra ngoài; ở #1377, điều đó hiện chưa có kết luận.

Năm bước bảo toàn khả năng phục hồi

1. Cô lập có phối hợp. Ngăn hoạt động ghi hoặc mã hóa tiếp qua mạng, SMB, endpoint và tài khoản liên quan; kiểm soát job đồng bộ. Người phụ trách ứng cứu cân nhắc trạng thái mã hóa, RAM, log và hoạt động kinh doanh trước khi quyết định tắt nguồn. Không áp một quy tắc tắt máy cho mọi ca.
2. Giữ nguyên nguồn. Không format, reset, rebuild RAID, sửa filesystem hoặc chạy công cụ thử trên bản duy nhất. Ghi nhãn vị trí ổ/serial, cấu hình mảng, tình trạng thiết bị và các thao tác đã làm. Tạo ảnh đĩa/bản sao theo phương án phù hợp với sức khỏe thiết bị, giữ log thao tác.
3. Bảo quản chứng cứ. Giữ note nguyên bản, metadata, mẫu file mã hóa và bản trước sự cố nếu có. Tính SHA-256 cho bản thu thập, ghi nguồn, người bàn giao, thời điểm, công cụ và đích lưu. SHA-256 kiểm tra tính toàn vẹn, không tự chứng minh tác giả hay tính hợp pháp của một file.
4. Tìm điểm khôi phục sạch. Kiểm kê backup, snapshot, phiên bản cloud, replica và máy khác có bản sao. Giữ lại các mốc trước sự cố; tránh để job tự động ghi đè bản tốt. Ghi rõ bản nào cùng quyền quản trị với hệ thống nghi bị chiếm và bản nào độc lập.
5. Phân tích trên bản sao rồi nghiệm thu. Chọn mẫu đại diện, ghi kết quả theo loại dữ liệu, mở bằng ứng dụng nghiệp vụ và giữ đầu ra kiểm tra. Chỉ đưa dữ liệu đã đánh giá sang môi trường sạch; xử lý quyền truy cập, bản vá và giám sát trước khi nối lại dịch vụ.

NIST SP 800-86 là tài liệu nền tảng cho hoạt động forensic trong ứng cứu. Quy trình cụ thể còn phụ thuộc tình trạng ổ, kiến trúc, nhân sự và yêu cầu của tổ chức. Có thể chuẩn bị hồ sơ trình báo song song với cứu dữ liệu; xem hướng dẫn PA05 và bảo toàn chứng cứ số.

Sao lưu 3-2-1-1-0: thiết kế cho cả tình huống mất quyền quản trị

Quy tắc 3-2-1-1-0 gợi ý ít nhất ba bản dữ liệu, hai loại phương tiện, một bản offsite, một bản offline/bất biến và kiểm tra phục hồi để xử lý lỗi. Đối với NAS, câu hỏi thực tế là: nếu tài khoản quản trị bị chiếm, kẻ tấn công có xóa được mọi bản hay không?

RAID giúp chịu một số lỗi đĩa trong giới hạn cấu hình; nó không giữ lịch sử file trước mã hóa. Sync hai chiều thuận tiện cho cộng tác nhưng có thể lan truyền trạng thái xóa hoặc mã hóa. Snapshot trên cùng thiết bị giúp quay lại nhanh trong điều kiện phù hợp, song vẫn chung rủi ro vật lý và có thể chịu tác động của quyền cao nếu thiếu bảo vệ.

Tài liệu Synology về immutable backup nhấn mạnh bản sao được bảo vệ khỏi sửa/xóa và đích ngoài hệ thống chính. Khả năng snapshot bất biến phụ thuộc model, filesystem, phiên bản và cấu hình. Đừng mặc định mọi NAS hỗ trợ cùng tính năng hoặc “immutable” tự động bao phủ mọi rủi ro.

Đặt lịch theo RPO — mức mất dữ liệu chấp nhận được — và RTO — thời gian mục tiêu đưa dịch vụ trở lại. Chẳng hạn, mục tiêu RPO 4 giờ đòi hỏi phương án lưu đủ thường xuyên và có điểm sạch phù hợp; RTO 24 giờ phải được kiểm thử với số file, đường truyền và ứng dụng thực tế. Hai con số là mục tiêu thiết kế, không phải lời hứa cho mọi NAS 5 TB.

Checklist vận hành sau khi đã bảo toàn chứng cứ

• Kiểm kê model, firmware/DSM, gói PHP, tài khoản quản trị, VPN, SSH và bề mặt truy cập Internet. Chỉ vá theo nhánh đúng thiết bị và kế hoạch đã duyệt.
• Giảm công khai giao diện quản trị; áp dụng phân đoạn mạng, MFA khi có và quyền tối thiểu. VPN vẫn cần vá, giám sát và kiểm soát tài khoản.
• Tách danh tính quản trị backup khỏi nguồn; bảo vệ khóa phục hồi; đặt cảnh báo job, dung lượng, thay đổi hàng loạt và lần restore thất bại.
• Kiểm thử mẫu file định kỳ và diễn tập dịch vụ sau thay đổi lớn. Với SQL, VM hay ERP, cần phương án nhất quán ở mức ứng dụng và quy trình nghiệm thu tương ứng.
• Giao một người chịu trách nhiệm theo dõi các câu hỏi còn mở: đường vào, phạm vi tác động, trạng thái backup và bằng chứng về truyền dữ liệu ra ngoài.

Câu hỏi thực tế

Đổi đuôi .L0CK3D về .docx có mở lại được không?

Đổi tên không đảo ngược dữ liệu đã bị mã hóa. Giữ file nguyên bản; kiểm tra cấu trúc và thử trên bản sao trước khi kết luận khả năng sử dụng.

RAID vẫn khỏe thì vì sao file hỏng?

RAID bảo vệ khả năng chịu lỗi ổ trong giới hạn cấu hình. Nó không ngăn một tài khoản hoặc tiến trình có quyền ghi thay đổi nội dung file trên volume.

Có thể cắt 588 byte cuối để lấy lại tài liệu?

Không có căn cứ làm vậy. Hiệu số quan sát trên một mẫu gợi ý metadata; cắt phần đuôi không khôi phục các byte đã mã hóa và có thể làm mất dấu vết cần phân tích.

Có thể kết luận #1377 bị lỗi Synology không?

Chưa. Hãng/model và đường vào của #1377 chưa được xác nhận; tường thuật DS918+ và các advisory là những phạm vi riêng.

Snapshot có đủ thay backup độc lập?

Cần xét quyền xóa, tính bất biến, thiết bị vật lý và khả năng restore. Snapshot thông thường cùng NAS không giải quyết mọi rủi ro của một bản sao độc lập.

Chưa có decryptor tương thích thì còn hướng phục hồi nào?

Có thể đánh giá backup sạch, phiên bản cũ, file còn nguyên và trích xuất forensic. Mỗi hướng phải được kiểm tra theo dữ liệu thực tế; chưa có tỷ lệ phục hồi được xác nhận cho #1377.

Ransomware.VN by TUNGTEK

Ransomware.VN trình bày thông tin và phân tích theo phạm vi chứng cứ. Nếu cần trao đổi về dữ liệu bị mã hóa, kênh tiếp nhận của TUNGTEK là CuuDuLieuMaHoa.com · 0963509115. RFC bắt đầu bằng đánh giá; không phải cam kết giải mã hoặc cứu thành công toàn bộ dữ liệu.