Gần đây, có những khung giờ chúng tôi nhận nhiều yêu cầu Ransomware gần như đồng thời. Một tin nhắn báo NAS của khách hàng bị mã độc mã hóa. Một tin khác hỏi hệ thống đang dính ransomware .PIZ và liệu dữ liệu có thể lấy lại được hay không. Khi lịch xử lý đang kín, câu trả lời đôi khi chỉ có thể là: “Cho em một chút thời gian, em nhắn lại sớm.”
Điều cần nói ngay: việc TUNGTEK “quá tải Case Ransomware” không phải thành tích để khoe. Với chúng tôi, mỗi Case mới đồng nghĩa với một doanh nghiệp đang ngừng việc, một hệ thống có thể đang mất quyền truy cập dữ liệu, một đội IT chịu áp lực và một bài toán phục hồi mà thời gian thường được tính bằng giờ.
1. Một buổi trưa, nhiều Case cùng lúc
Những ảnh chụp màn hình đi kèm bài viết này khá đơn giản: hai cuộc trao đổi khác nhau, hai tình huống khác nhau, nhưng cùng một chủ đề. Một bên là NAS bị mã hóa. Một bên là ransomware có đuôi .PIZ. Cả hai đều hỏi câu rất quen thuộc: “Có hỗ trợ cứu dữ liệu lại được không?”
Câu hỏi chỉ mất vài giây để gửi đi, nhưng phía sau câu trả lời lại là cả một chuỗi công việc: xác minh tình trạng, phân loại mức độ khẩn cấp, kiểm tra môi trường, xác định tài sản nào quan trọng nhất, xem còn Backup hay Snapshot nào sống sót, đánh giá cấu trúc dữ liệu bị tác động, rồi mới quyết định hướng khôi phục / trích xuất dữ liệu mã hóa phù hợp.
Với dữ liệu doanh nghiệp, đặc biệt là SQL Server, ERP, file server, máy ảo, NAS hay SAN, chúng tôi không muốn trả lời theo kiểu “được” hoặc “không được” chỉ dựa vào phần mở rộng của file. Một đuôi file có thể gợi ý, nhưng không đủ để kết luận toàn bộ tình trạng. Hai máy cùng đuôi ransomware vẫn có thể có cấu trúc hư hại, lịch sử ghi đè, dung lượng, Backup và khả năng phục hồi rất khác nhau.
2. “Quá tải” không phải là tin vui
Trong ngành Recovery, nhiều Case không có nghĩa thị trường “tốt”. Ngược lại, nó thường phản ánh một điều: Backup và phòng thủ ở đâu đó đã không hoạt động đúng vào thời điểm cần nhất.
Chúng tôi hiểu cảm giác khi một doanh nghiệp phải gọi hỗ trợ Ransomware. Đây hiếm khi là một yêu cầu IT thông thường. Có thể kế toán đang dừng, ERP không mở được, phòng khám không truy cập hồ sơ, nhà máy không chạy phần mềm sản xuất, hoặc toàn bộ thư mục dùng chung trên NAS đã đổi tên trong vài chục phút.
Lúc đó, người quản trị không chỉ chịu áp lực kỹ thuật. Họ còn phải trả lời Ban Giám Đốc, các phòng ban, khách hàng và đôi khi là đối tác. Vì vậy chúng tôi càng không muốn biến Ransomware Recovery thành một thông điệp quảng cáo kiểu “cứ bị rồi mang qua”.
Recovery là tuyến cuối.
Backup và Defense mới phải là tuyến đầu.
3. Ransomware Recovery không phải một nút bấm
Khi số lượng yêu cầu tăng, điểm nghẽn không chỉ nằm ở “máy có đủ mạnh không”. Recovery là công việc tiêu tốn cả tài nguyên lưu trữ, thời gian I/O lẫn con người. Có Case cần hàng chục terabyte dung lượng tạm để tạo bản sao làm việc. Có Case phải ưu tiên một vài file database trước rồi mới đến phần còn lại. Có Case cần giữ nguyên chứng cứ để phục vụ điều tra.
🔎 Triage ban đầuXác định loại hệ thống, phạm vi bị ảnh hưởng, thời điểm sự cố, ransomware note, extension, backup/snapshot và dữ liệu nào là ưu tiên số 1.
🧪 RFC – Ransomware Fast CheckĐánh giá nhanh mẫu dữ liệu và khả năng tiếp cận. RFC giúp định hướng kỹ thuật, không phải lời hứa chắc chắn về kết quả cuối.
💾 Bảo toàn nguồnHạn chế ghi thêm lên ổ đĩa/NAS/VM bị ảnh hưởng. Khi cần, tạo bản sao làm việc thay vì thử nghiệm trực tiếp trên dữ liệu gốc.
✅ Xác minh dữ liệu dùng đượcFile “mở được” chưa chắc đã đủ. Database cần kiểm tra logic, ứng dụng cần test, và dữ liệu ưu tiên phải được xác nhận theo nhu cầu thực tế của khách hàng.
Chính vì vậy, khi nhiều Case cùng đến, chúng tôi phải triage theo mức độ ảnh hưởng thực tế: hệ thống nào đang dừng hoàn toàn, dữ liệu nào phục vụ vận hành chính, có Backup thay thế hay không, và khách hàng cần khôi phục phần nào trước.
4. Vì sao các Case thường dồn vào cùng lúc?
Ransomware không “đặt lịch” với đội IT. Nhiều cuộc tấn công được kích hoạt ngoài giờ, vào cuối tuần hoặc trong khung thời gian ít người giám sát. Đến khi người dùng bắt đầu làm việc, các triệu chứng mới lộ rõ và hàng loạt yêu cầu hỗ trợ xuất hiện.
Một điểm chúng tôi gặp khá thường xuyên là doanh nghiệp có Backup nhưng Backup vẫn nằm trong cùng miền rủi ro: cùng hệ thống quyền, cùng mạng, cùng tài khoản quản trị, cùng NAS, hoặc repository luôn online. Khi kẻ tấn công đã có quyền đủ cao, Backup có thể trở thành mục tiêu tiếp theo.
Vì thế, câu “có Backup” cần được đổi thành những câu cụ thể hơn: Backup có offline hoặc immutable không? Tài khoản Backup có tách khỏi tài khoản Domain/Admin thường ngày không? Bản sao gần nhất đã từng restore thử chưa? Nếu toàn bộ máy chủ chính mất, đội IT có biết phải dựng lại dịch vụ theo thứ tự nào không?
5. Nếu đang bị Ransomware và phải chờ tiếp nhận: làm gì trước?
Trong thời điểm đội Recovery đang xử lý nhiều Case, vài hành động ban đầu của khách hàng có thể giúp bảo toàn thêm cơ hội phục hồi. Mục tiêu là ngăn lan rộng và giảm ghi đè, không phải tự thử mọi công cụ tìm thấy trên Internet.
Nên làm
Cách ly hệ thống bị ảnh hưởng khỏi mạng nếu vẫn còn nguy cơ lây lan hoặc mã hóa tiếp.
Ngừng các tác vụ ghi không cần thiết lên NAS, volume, datastore hoặc ổ đĩa chứa dữ liệu bị ảnh hưởng.
Giữ lại ransom note, tên file lạ, extension, log và thông tin thời điểm phát hiện.
Ghi lại máy nào bị trước, máy nào bị sau và các tài khoản quản trị/remote access có liên quan.
Xác định ngay dữ liệu ưu tiên: database nào, thư mục nào, VM nào, dung lượng khoảng bao nhiêu.
Kiểm tra Backup theo hướng an toàn: có bản offline, immutable, snapshot hoặc offsite còn nguyên không.
Nếu hệ thống ảo hóa/phức tạp, trao đổi trước khi tắt hàng loạt host hoặc xóa snapshot.
Không nên làm
Không Format, Initialize hoặc tạo lại filesystem trên thiết bị nguồn chỉ để “thử cho nhận lại ổ”.
Không cài lại Windows lên chính ổ đang chứa dữ liệu cần Recovery.
Không xóa ransom note, log hay các artefact chỉ vì “trông nguy hiểm”.
Không chạy hàng loạt decryptor/repair tool không rõ nguồn trực tiếp trên dữ liệu gốc.
Không chép thêm nhiều dữ liệu mới vào volume đang cần trích xuất.
Không dựa duy nhất vào phần mở rộng file để kết luận ransomware family hay khả năng phục hồi.
Nếu dữ liệu là SQL/ERP hoặc dịch vụ lõi, hãy nói rõ ngay từ đầu: file nào quan trọng nhất, ứng dụng nào cần chạy trước, dung lượng bao nhiêu và deadline vận hành là gì. Điều đó giúp đội xử lý ưu tiên đúng mục tiêu thay vì cố “cứu tất cả” theo thứ tự không cần thiết.
6. Backup 3-2-1-1-0: đừng chỉ có “một bản copy”
Một trong những lý do chúng tôi liên tục nhắc về Backup là vì Recovery từ thiết bị đã bị mã hóa luôn có yếu tố bất định. Bản Backup sạch, đã kiểm thử Restore, gần như luôn là con đường tốt hơn so với phải phục hồi dữ liệu sau sự cố.
Nguyên tắcÝ nghĩa thực tế3 bản dữ liệu1 bản production + ít nhất 2 bản sao.2 loại lưu trữKhông để mọi bản sao phụ thuộc vào cùng một hệ thống/phần cứng.1 bản offsiteMột bản ở vị trí/hạ tầng khác với site chính.1 bản offline/immutableKhông thể bị mã hóa/xóa dễ dàng bằng cùng tài khoản hoặc cùng đường tấn công.0 lỗi chưa biếtBackup phải được verify và định kỳ restore thử. “Job Success” chưa đủ.
Quan trọng hơn cả công thức là tư duy: Backup phải sống sót khi Production bị chiếm quyền. Nếu ransomware có thể dùng chính tài khoản Admin để xóa cả production lẫn backup, thì số lượng job “Success” trước đó không còn nhiều ý nghĩa.
7. Phòng thủ tối thiểu cho NAS, Server và dữ liệu doanh nghiệp
Không có cấu hình nào bảo đảm “không bao giờ bị”. Nhưng có rất nhiều biện pháp cơ bản giúp giảm đáng kể khả năng một sự cố trở thành thảm họa toàn hệ thống.
Bật MFA cho các điểm truy cập từ xa và tài khoản quản trị quan trọng.
Không mở RDP/SMB/NAS management trực tiếp ra Internet nếu không thật sự cần.
Tách tài khoản Backup khỏi tài khoản quản trị vận hành hằng ngày.
Áp dụng least privilege: người dùng chỉ có quyền đúng với công việc.
Phân đoạn mạng giữa user, server, backup, hypervisor và thiết bị quản trị.
Vá sớm các dịch vụ Internet-facing, VPN, firewall, NAS và hypervisor.
Giám sát đăng nhập bất thường, tạo tài khoản mới, tắt AV/EDR, xóa snapshot và xóa backup.
Duy trì inventory: biết mình có máy nào, dịch vụ nào, dữ liệu nào và ai chịu trách nhiệm.
Diễn tập Restore định kỳ thay vì chờ đến khi ransomware mới mở tài liệu hướng dẫn.
Đặc biệt với doanh nghiệp vừa và nhỏ, không nhất thiết phải mua ngay một hệ thống phòng thủ cực kỳ phức tạp. Làm đúng những thứ cơ bản, quản trị quyền chặt, có Backup thật sự tách biệt và biết cách Restore đã tốt hơn rất nhiều so với một hệ thống có nhiều sản phẩm nhưng không ai kiểm tra chúng còn hoạt động hay không.
8. TUNGTEK cũng phải thay đổi cách tiếp nhận Case
Khi lượng yêu cầu tăng, phía Recovery cũng phải có kỷ luật vận hành tốt hơn. Chúng tôi đang chuẩn hóa việc tiếp nhận để giảm thời gian hỏi đi hỏi lại và giúp khách hàng cung cấp đúng thông tin ngay từ đầu.
Quy trình mà chúng tôi ưu tiên gồm: ghi nhận Case, yêu cầu mô tả phạm vi, xác định dữ liệu ưu tiên, thu thập mẫu an toàn cho RFC khi phù hợp, xác định thiết bị/hệ thống nguồn, tình trạng Backup và deadline vận hành. Với Case lớn, việc này quan trọng hơn rất nhiều so với việc nhắn một câu “gửi file qua xem thử”.
Chúng tôi cũng cố gắng minh bạch một điều: khi đang kín lịch, khách hàng có thể phải chờ một khoảng thời gian ngắn để được đánh giá đúng. Thà nói rõ “đang xử lý Case, sẽ phản hồi vào khung giờ cụ thể” còn hơn trả lời vội rồi đưa ra kỳ vọng không chính xác.
9. Vì sao chúng tôi làm No.Ransomware.VN?
Nếu chỉ tập trung vào Recovery, chúng tôi sẽ luôn đứng ở cuối chuỗi sự cố. Vì vậy No.Ransomware.VN được dùng như một nơi chia sẻ ngược lại những gì rút ra từ các Case: cảnh báo, Backup, phòng thủ, dấu hiệu cần chú ý và các bài học có thể áp dụng trước khi ransomware xảy ra.
Mục tiêu rất đơn giản: nếu một bài viết về Backup khiến một doanh nghiệp tạo thêm bản immutable; nếu một bài về MFA khiến một quản trị viên khóa lại remote access; nếu một checklist khiến ai đó thử Restore trước khi cần đến nó — thì giá trị đó lớn hơn việc chúng tôi nhận thêm một Case Recovery.
Đề nghị rất thực tế: dành một buổi để vào No.Ransomware.VN, rà lại Backup và các điểm phòng thủ của hệ thống. Đừng đợi đến lúc file đã đổi đuôi mới bắt đầu hỏi: “Backup của mình đang nằm ở đâu?”
10. Kết: Đừng biến Recovery thành chiến lược Backup
Chúng tôi vẫn sẽ tiếp tục làm Ransomware Recovery, vẫn phân tích những Case khó, vẫn tìm cách trích xuất dữ liệu mã hóa khi còn cơ hội. Nhưng nếu phải chọn một thông điệp cho bài viết này, nó không phải là “TUNGTEK đang rất nhiều Case”.
Thông điệp là: Ransomware đang tạo ra quá nhiều tình huống mà lẽ ra có thể giảm thiệt hại đáng kể nếu Backup và Defense được chuẩn bị trước.
Một bản Backup không kiểm tra Restore chưa phải là sự bảo đảm. Một NAS có snapshot nhưng snapshot dùng chung quyền quản trị vẫn chưa đủ. Một firewall có MFA nhưng tài khoản local cũ vẫn mở cũng chưa thể yên tâm. Và một dịch vụ Recovery, dù có kinh nghiệm đến đâu, cũng không nên là kế hoạch dự phòng duy nhất.
Backup trước. Phòng thủ trước.
Recovery chỉ nên xuất hiện khi mọi lớp trước đó đã không còn lựa chọn tốt hơn.
Tùng TEK — ghi chép từ thực tế tiếp nhận và xử lý Ransomware tại TUNGTEK.
Bài viết tập trung vào Backup, phòng thủ và quy trình Recovery; không dùng phần mở rộng file như căn cứ duy nhất để attribution ransomware family.