C3RB3R / .L0CK3D trên NAS: Hướng trích xuất dữ liệu và quy trình RFC

1. Dấu hiệu C3RB3R cần đối chiếu với hiện trạng

.L0CK3D dùng số 0, không phải chữ O. Tên thư đòi tiền read-me3.txt là một dấu hiệu đối chiếu khác. Tuy nhiên, đuôi tệp và tên thư chưa đủ để xác định toàn bộ diễn biến một sự cố.

Phân tích của SentinelOne ghi nhận C3RB3R trên Windows/Linux, với tệp mang đuôi .L0CK3D và tác động tới các SMB share có thể truy cập. Từ đó, cần kiểm tra cả máy trạm, máy chủ và tài khoản có quyền ghi vào NAS; không mặc định mã độc đã chạy trong hệ điều hành NAS. Đây là hướng điều tra, không phải kết luận về Ticket #1377. [1]

Một lời đe dọa trong ransom note cũng chưa chứng minh dữ liệu đã bị lấy đi. Đánh giá mã hóa và đánh giá rò rỉ dữ liệu là hai công việc liên quan nhưng cần bằng chứng riêng.

2. Ba hướng xử lý phải phân biệt

Quét RAW hay đổi đuôi không tự biến dữ liệu đã mã hóa thành tài liệu đọc được. Xóa phần đuôi hoặc cắt vài trăm byte cuối tệp cũng không khôi phục phần nội dung đã bị mật mã hóa. Tệp mã hóa toàn bộ cần nguồn sạch hoặc điều kiện mật mã phù hợp; dữ liệu bị ghi đè làm mất thông tin lại là một vấn đề khác.

No More Ransom có mục công cụ cho CERBER V1; phạm vi đó không đồng nghĩa hỗ trợ mọi biến thể mang tên Cerber/C3RB3R. Với Ticket #1377, bài viết chưa xác nhận một decryptor phù hợp. Chỉ thử công cụ có nguồn rõ ràng sau khi bảo toàn nguồn. [2]

3. RFC: Sáu bước đánh giá trước khi trích xuất dữ liệu

Bước 1 — Cô lập có phối hợp

Trao đổi với người phụ trách IT để ngăn luồng ghi và quyền truy cập đáng ngờ, bảo vệ backup còn an toàn. Ghi thời điểm phát hiện, thông báo và những thao tác đã làm. Quyết định tắt máy hoặc thu thập bộ nhớ phụ thuộc hiện trạng; không áp dụng một công thức tắt nguồn cho mọi hệ thống.

Bước 2 — Ghi nhận RAID, volume và ổ đĩa

Kiểm kê số lượng, thứ tự ổ, cấu hình RAID, filesystem, mã hóa ổ đĩa hợp lệ và lỗi I/O nếu có. RAID khỏe không đồng nghĩa tệp còn nguyên. Đồng thời phải phân biệt file bị Ransomware tác động với lỗi ổ vật lý hoặc hỏng cấu trúc lưu trữ.

Bước 3 — Bảo toàn nguồn, tạo bản sao phù hợp

Khi phù hợp, tạo image/clone hoặc bản sao volume có kiểm soát, lưu thông tin bàn giao và nhật ký thao tác. Nguồn có lỗi vật lý cần cách đọc phù hợp để hạn chế đọc lặp. Không format, initialize, rebuild RAID, sửa filesystem hoặc thử công cụ trên bản gốc/bản duy nhất chỉ để xem có hiệu quả hay không.

Bước 4 — Lập danh mục nguồn còn khả dụng

Kiểm tra backup ngoại tuyến/bất biến, snapshot, version history, bản replication độc lập, máy trạm và bản lưu của ứng dụng. Dữ liệu cũ chỉ còn cơ hội trích xuất khi thông tin cần thiết vẫn tồn tại. Snapshot đã bị xóa, extent bị tái sử dụng, SSD TRIM và garbage collection có thể làm mất cơ hội; copy-on-write không phải lời bảo đảm phục hồi.

Bước 5 — Trích xuất có chọn lọc trên bản sao

Ưu tiên dữ liệu nghiệp vụ cần dùng trước, rồi lấy mẫu nhiều loại và kích thước. Kiểm tra cấu trúc tệp, vùng đọc được và độ đầy đủ, không chỉ nhìn tên hoặc phần mở rộng. Nếu nghi mã hóa một phần, đối chiếu file gốc hợp lệ với file bị tác động trên bản sao để đánh giá phạm vi.

Bước 6 — Kiểm tra sử dụng và bàn giao

Lập danh mục tệp đã lấy được, các lỗi còn lại và kết quả kiểm tra. Khách hàng nghiệm thu theo tiêu chí đã thống nhất. Một con số dung lượng, tỷ lệ byte hay thông báo “copy thành công” chưa chứng minh dữ liệu nghiệp vụ đã dùng được.

4. File lấy ra phải qua kiểm tra thực tế

• DOCX/XLSX: kiểm tra cấu trúc container, mở tài liệu và đối chiếu nội dung, sheet hoặc công thức cần thiết.
• PDF, ảnh, video: kiểm tra trang, vùng hình ảnh và khả năng đọc/phát nội dung, không chỉ tên tệp.
• SQL Server: kiểm tra tính nhất quán trên môi trường phù hợp và đối chiếu dữ liệu bằng ứng dụng nghiệp vụ.
• VM/backup: kiểm tra chuỗi phụ thuộc, khả năng đọc và thử khôi phục/khởi động trong lab cô lập khi phù hợp.

Với NAS ước tính 5 TB, nên xác định trước thư mục kế toán, ERP, hồ sơ dự án hoặc bộ dữ liệu cần ưu tiên. Dung lượng lớn không có nghĩa mọi tệp đều cùng mức quan trọng; kết quả một ticket khác không thể dùng để cam kết cho hệ thống hiện tại.

5. Sau sự cố: Sao lưu phải có khả năng phục hồi

RAID hỗ trợ khả năng chịu lỗi ổ đĩa theo cấu hình. Snapshot có thể giúp trở lại phiên bản cũ nếu còn nguyên. Đồng bộ có thể chuyển tiếp cả thay đổi không mong muốn. Các cơ chế này cần được đánh giá trong một thiết kế sao lưu có bản độc lập, quyền quản trị tách biệt và kiểm thử restore.

Tham khảo nguyên tắc 3-2-1-1-0: ba bản dữ liệu tính cả bản đang dùng, trên hai loại phương tiện, có một bản ngoài địa điểm chính, một bản offline/air-gapped hoặc bất biến, và kiểm thử hướng tới không có lỗi phục hồi. Thời gian giữ, RPO/RTO và dung lượng phải tính theo nhu cầu thực tế. [3]

Đội ứng cứu cần khoanh vùng và xử lý quyền truy cập còn bị chiếm trước khi đưa dữ liệu trở lại sản xuất. Trích xuất dữ liệu là một phần công việc; không thay thế toàn bộ xử lý sự cố an ninh.

6. Cần chuẩn bị gì khi liên hệ TUNGTEK?

• Loại hệ thống, thời điểm phát hiện và đuôi tệp quan sát được.
• Ảnh thông báo đã che thông tin riêng; danh sách thao tác đã thực hiện.
• Tình trạng backup/snapshot và dữ liệu cần ưu tiên.
• Người có thẩm quyền thống nhất phạm vi bàn giao và tiếp nhận kết quả.

Chưa cần gửi tài liệu nhạy cảm, mật khẩu, khóa riêng hoặc đường dẫn truy cập. Tùng TEK cùng bạn làm rõ hiện trạng, phạm vi RFC, phương án, chi phí và cách kiểm tra dữ liệu trước khi triển khai. Không hứa tỷ lệ phục hồi khi chưa có cơ sở kiểm chứng.

Chuẩn bị yêu cầu RFC · Bảo mật và tiếp nhận dữ liệu · Hướng dẫn ứng phó và phối hợp trình báo.

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

Nguồn tham khảo và phạm vi bài viết

1. SentinelOne — Phân tích C3RB3R, .L0CK3D, ransom note và SMB share. Nghiên cứu chiến dịch bên ngoài, không xác định nguyên nhân Ticket #1377.
2. No More Ransom — Danh mục công cụ và phạm vi hỗ trợ.
3. Veeam Best Practice Guide — Nguyên tắc 3-2-1-1-0.

Biên tập từ bộ TEKLink218 do TUNGTEK cung cấp, rà soát ngày 29/10/2026. Ca đã ẩn danh và đang đánh giá; không công bố mẫu, log, hash riêng, liên kết có token hoặc kết quả chưa được kiểm chứng. Hình trong bài là minh họa biên tập, không phải ảnh hệ thống khách hàng.