Một buổi tối nhìn lại những tệp không mở được
Có những lúc, chỉ nhìn một danh sách tệp thôi cũng đủ thấy lo.
Trong ảnh là báo cáo kiểm kê dữ liệu tôi đang xem. Những thư mục đã được che tên, những tệp đĩa máy ảo, những phần mở rộng .babyk nằm cạnh nhau. Với người ngoài, đó có thể là một màn hình kỹ thuật. Với người làm cứu dữ liệu, phía sau từng dòng ấy là câu hỏi: hệ thống nào đang nằm trong đó, công việc nào đang chờ, và còn con đường nào để đưa dữ liệu trở lại sử dụng?
Đó cũng là điều khiến tôi muốn viết những dòng này vào buổi tối 04/11/2026. Càng tiếp xúc với dữ liệu bị mã hóa, tôi càng thấy việc chuẩn bị trước sự cố đáng được doanh nghiệp dành thời gian nghiêm túc.
BabyK và nỗi lo ở tầng máy chủ ảo hóa
BabyK/Babuk là cái tên khiến tôi thận trọng khi tiếp nhận dữ liệu liên quan tới máy chủ ảo hóa. Khi nhiều dịch vụ cùng nằm trên một cụm hạ tầng, sự cố ở lớp lưu trữ hoặc máy chủ ảo hóa có thể khiến hàng loạt máy ảo không còn hoạt động. Quy mô thiệt hại phụ thuộc vào hệ thống thực tế, dữ liệu bị tác động và những đường phục hồi còn giữ được.
SentinelLABS ghi nhận nhiều họ ransomware dùng lại mã nguồn Babuk để xây công cụ mã hóa ESXi. Sự tái sử dụng đó cũng làm việc quy kết tác nhân khó hơn. Vì vậy, một đuôi .babyk là dấu hiệu cần phân tích, chưa đủ xác định băng nhóm đứng sau một vụ việc. [1]
Điều tôi quan tâm khi tiếp nhận không dừng ở tên ransomware. Tôi cần hiểu dữ liệu nào quan trọng, phạm vi ảnh hưởng đến đâu và nguồn nào còn có thể kiểm tra an toàn. Với doanh nghiệp, đó mới là những câu hỏi gắn trực tiếp với việc vận hành trở lại.
Điều tôi nhớ từ một ca ứng cứu Qilin
Tôi từng tham gia ứng cứu một ca được xác định trong quá trình làm việc là liên quan tới Qilin. Khi đó, tôi được chia sẻ rằng trước thời điểm mã hóa, phía tấn công đã hiện diện trong doanh nghiệp hơn hai tuần. Đơn vị truy vết là một công ty ở Singapore, được công ty mẹ chỉ định sang Việt Nam hỗ trợ ứng cứu.
Mốc “hơn hai tuần” ở đây là thông tin tôi được chia sẻ trong ca cụ thể ấy. Điều đọng lại với tôi là khoảng cách giữa lúc kẻ tấn công bắt đầu có mặt và lúc mọi người nhìn thấy dữ liệu bị mã hóa. Trong khoảng thời gian ấy, hệ thống vẫn có thể trông như đang vận hành bình thường.
Đến khi dữ liệu không mở được, câu chuyện có thể đã bắt đầu từ trước đó rất lâu.
Bởi vậy, một kế hoạch phục hồi cần tính tới cả việc kiểm tra môi trường và nguồn dữ liệu dùng để khôi phục. Đưa được máy ảo lên trở lại là một cột mốc; xác nhận dịch vụ có thể vận hành an toàn và sử dụng được mới là công việc cần đi đến cùng.
Những ổ cứng làm kỷ niệm ở 2A Phan Chu Trinh
Cứu dữ liệu vốn đã là một công việc thú vị. Còn cứu dữ liệu bị mã hóa, khi kể lại, đôi khi thành một câu chuyện khó tin đến mức người nghe ngờ vực.
Ở nơi làm việc tại 2A Phan Chu Trinh, tôi giữ những ổ cứng bị mã hóa đã xin lại khách hàng sau các ca ứng cứu để làm kỷ niệm. Có hàng tá ổ như vậy. Khi ai đó trực tiếp ghé qua và trò chuyện về nghề, chúng trở thành những vật gợi lại câu chuyện rất cụ thể.
Tôi cũng có hàng chục TB dữ liệu mã hóa để tiếp tục nghiền ngẫm, nghiên cứu và phục vụ niềm đam mê của mình. Nhìn một tệp không mở được, người làm nghề phải kiên nhẫn tìm hiểu cấu trúc, phần dữ liệu còn đọc được và những giới hạn của từng phương án.
Điều thú vị nằm ở quá trình hiểu ra vấn đề. Nhưng đối với doanh nghiệp đang chờ dữ liệu, mỗi ca là áp lực thật. Tôi quý những câu chuyện nghề ấy, đồng thời luôn mong mọi người có sự chuẩn bị để ít phải rơi vào tình huống cần đến chúng.
Dữ liệu là “trái tim”, vậy phần nào cần được giữ trước?
Trong công việc tiếp nhận, tôi gặp dữ liệu từ NAS, Server, VMware, Linux và nhiều kiểu hệ thống khác. Tên nền tảng thay đổi, nhưng điều doanh nghiệp lo vẫn rất gần nhau: phần mềm không chạy, hồ sơ không mở, người dùng không thể tiếp tục công việc.
“Trái tim” của một doanh nghiệp có thể là database kế toán. Với đơn vị khác, đó là dữ liệu sản xuất, bản thiết kế, hồ sơ dự án hoặc một ứng dụng quản trị. Nếu chưa gọi đúng tên phần ấy, rất dễ dành công sức sao lưu nhiều dữ liệu mà vẫn bỏ sót thứ cần nhất khi có sự cố.
Tôi nghĩ chủ doanh nghiệp và người phụ trách IT nên sớm ngồi lại, hỏi nhau vài câu thật cụ thể:
- Dịch vụ nào ngừng một buổi là công việc bị ảnh hưởng nghiêm trọng?
- Dữ liệu và các thành phần nào cần có để chạy lại dịch vụ ấy?
- Bản sao có thể dùng gần nhất đang ở đâu, ai lấy được và đã thử phục hồi tới bước nào?
Hãy bắt đầu với phần trọng yếu, rồi mở rộng ra những dữ liệu còn lại. Một thứ tự ưu tiên rõ ràng giúp việc sao lưu phù hợp hơn với nguồn lực của từng doanh nghiệp.
AI làm nỗi lo lớn hơn, chuẩn bị vẫn phải từ những việc cụ thể
Tôi lo khi nghĩ tới khả năng AI hỗ trợ những người đang tìm cách tấn công hệ thống. Trong đánh giá công bố ngày 03/11/2026, NCSC nhận định việc tội phạm sử dụng AI có khả năng làm tăng quy mô và hiệu quả của hoạt động ransomware, lừa đảo và khai thác lỗ hổng. [3]
Nhận định đó là bối cảnh để chuẩn bị tốt hơn; tôi không có bằng chứng để gắn việc sử dụng AI với những ca đang kể ở đây. Nỗi lo của tôi hướng vào tốc độ thay đổi và khoảng cách giữa những gì doanh nghiệp tin mình đã bảo vệ với những gì đã được kiểm tra thực sự.
Trong bối cảnh ấy, một lần rà lại quyền quản trị, cập nhật hệ thống, bảo vệ kho sao lưu và thử restore đều có giá trị thực tế. Việc cần làm có thể bắt đầu ngay từ hệ thống quan trọng nhất đang có.
Backup offline và bất biến cần được chứng minh bằng khả năng phục hồi
Ở thời điểm này, tôi rất mong các doanh nghiệp có những bản sao lưu offline thực sự dùng được. Khi dữ liệu chính và tài khoản quản trị cùng gặp sự cố, một bản sao được cách ly phù hợp có thể giữ lại một đường phục hồi quan trọng.
CISA khuyến nghị duy trì bản sao offline, được mã hóa và thường xuyên thử khả năng truy xuất, toàn vẹn khi phục hồi. Tài liệu cũng ghi nhận giá trị của lưu trữ bất biến, đồng thời lưu ý về cấu hình và chi phí. [2]
Backup bất biến có giá trị khi cơ chế bảo vệ, thời hạn giữ và quyền quản trị được thiết kế đúng. Backup offline cũng có rủi ro: bản quá cũ, thiết bị hỏng, thất lạc khóa giải mã hoặc chưa từng thử khôi phục. Khi kết nối trở lại, quy trình thao tác vẫn cần được kiểm soát.
Tôi muốn nhìn thấy những điều có thể kiểm tra được: bản sao còn truy xuất được khi hệ thống chính gián đoạn; người phụ trách biết cách lấy; dữ liệu được thử trên môi trường phù hợp; và ứng dụng thực hiện được công việc doanh nghiệp cần. Nhãn công nghệ chỉ có ý nghĩa khi đi cùng cách vận hành ấy.
Nếu cần bắt đầu, hãy chọn một dịch vụ, kiểm tra nguồn sao lưu và tổ chức một lần phục hồi thử. Bài kế hoạch backup doanh nghiệp cho NAS, Server và SQL có bảng phạm vi và mẫu ghi nhận để cùng IT triển khai.
Sao lưu dữ liệu đúng cách, phù hợp với từng doanh nghiệp, là một nền tảng quan trọng để phục hồi trước sự cố ransomware.
Sao lưu cần đi cùng phòng thủ và phát hiện xâm nhập. Còn lúc này, điều tôi muốn nhắn thật ngắn là: sớm ngồi lại, xác định “trái tim” của hệ thống, rồi bắt tay kiểm tra phần ấy trước.
Chúc mọi người may mắn 🍀
TUNGTEK Tùng.
Ghi chép lúc 22:00, ngày 04/11/2026.
Đang cảm thấy lo lắng, từ bàn cứu dữ liệu tại TUNGTEK.
Nguồn kỹ thuật và ghi chú biên tập
- SentinelLABS — Babuk-derived ESXi lockers and attribution limits
- CISA / NSA / FBI / MS-ISAC — #StopRansomware Guide
- NCSC — Annual Review 2026: The impact of AI on cyber threat
Ghi chép và hình do Tùng Nguyễn cung cấp, biên tập cho Blog. Mốc thời gian Qilin và chi tiết đơn vị ứng cứu Singapore là lời kể của tác giả về thông tin được chia sẻ trong ca đó. Các nguồn công khai dưới đây hỗ trợ phần bối cảnh kỹ thuật, không xác minh độc lập hồ sơ riêng hay kết quả khôi phục.
