24 giờ đầu sau khi phát hiện ransomware: kịch bản xử lý theo từng bước

Ba nguyên tắc trước khi làm bất cứ điều gì

Khi màn hình đầu tiên hiện thông báo đòi tiền chuộc, áp lực lớn nhất là phải làm gì đó ngay. Đó cũng là lúc dễ gây thiệt hại không đảo ngược được nhất.

Cách ly, đừng vội tắt. Phản xạ tự nhiên là rút điện máy chủ để dừng mã hóa. Nhưng RAM chứa những thứ không tồn tại ở nơi khác: tiến trình đang chạy, kết nối đang mở, đôi khi cả khóa mã hóa hoặc mã độc chỉ nằm trong bộ nhớ, và tắt nguồn xóa sạch chúng. Hãy ưu tiên cách ly ở tầng mạng: ngắt cổng switch, gỡ quy tắc security group, tách VLAN, ngắt VPN site-to-site, khóa tài khoản bị lợi dụng. Đây là đánh đổi thật chứ không phải quy tắc tuyệt đối: nếu mã hóa lan nhanh và không thể cách ly ở tầng mạng, tắt máy có thể là quyết định đúng, miễn là được đưa ra có ý thức, bởi người có thẩm quyền, và ghi lại kèm thời điểm.

Đừng phá bằng chứng. Trong giờ đầu, mọi hành động dọn dẹp đều là phá hủy dữ liệu điều tra: không cài lại hệ điều hành, không xóa file lạ, không chạy công cụ diệt mã độc, không format ổ, không xóa snapshot. Bằng chứng là thứ trả lời câu hỏi quan trọng nhất: kẻ tấn công vào bằng đường nào. Không trả lời được, bạn sẽ khôi phục vào lỗ hổng cũ.

Đây không phải sự cố kỹ thuật thuần túy. Ransomware kéo theo nghĩa vụ pháp lý, quan hệ với bảo hiểm, khách hàng và đối tác, cùng các quyết định thuộc thẩm quyền ban lãnh đạo. Hãy đưa họ vào cuộc sớm.

Giờ 0 đến 1: xác nhận và cách ly

Việc đầu tiên là xác nhận đây thực sự là sự cố mã hóa dữ liệu chứ không phải sự cố lưu trữ, lỗi ứng dụng hay cảnh báo sai. Dấu hiệu điển hình: hàng loạt file đổi phần mở rộng, file ghi chú đòi tiền chuộc xuất hiện trong nhiều thư mục, tiến trình lạ ghi đĩa liên tục, dịch vụ dừng bất thường.

Ngay khi xác nhận, làm những việc sau theo thứ tự:

• Cách ly hệ thống bị ảnh hưởng khỏi mạng nhưng giữ máy đang bật.
• Chặn đường lan: ngắt kết nối giữa các phân vùng mạng, tạm dừng đồng bộ giữa các site và kết nối tới hệ thống đối tác.
• Bảo vệ hệ thống backup ngay: ngắt khỏi mạng chung và đổi thông tin đăng nhập quản trị. Trong nhiều sự cố, backup là mục tiêu bị tấn công trước tiên.
• Vô hiệu hóa tài khoản đặc quyền nghi bị chiếm dụng, tạm dừng các cơ chế tự động có thể lan rộng như công cụ triển khai phần mềm tập trung.
• Chuyển liên lạc nội bộ sang kênh ngoài luồng. Nếu email hoặc chat công ty có thể đã bị xâm nhập, mọi trao đổi trên đó đang được kẻ tấn công đọc.

Song song, mở nhật ký sự cố ngay từ dòng đầu: thời điểm phát hiện, ai phát hiện, dấu hiệu gì, hành động nào và vào lúc mấy giờ. Bản ghi này phục vụ cả điều tra kỹ thuật lẫn yêu cầu từ pháp chế và bảo hiểm.

Giờ 1 đến 3: huy động đúng người

Trong khoảng thời gian này, việc quan trọng nhất không nằm ở bàn phím.

• Ban lãnh đạo. Một người đủ thẩm quyền quyết việc dừng sản xuất, thông báo cho khách hàng hay chi tiền thuê đơn vị ứng cứu, kèm một người phụ trách truyền thông nội bộ.
• Pháp chế. Cần được thông báo trong những giờ đầu. Họ xác định nghĩa vụ nào phát sinh, thông tin nào được chia sẻ ra ngoài và cách lưu giữ tài liệu.
• Bảo hiểm. Nếu có bảo hiểm an ninh mạng, hãy đọc lại hợp đồng ngay trong ngày đầu. Nhiều hợp đồng yêu cầu thời điểm thông báo và chỉ dùng đơn vị ứng cứu được chấp thuận; tự thuê bên ngoài trước có thể ảnh hưởng tới phạm vi chi trả.
• Chuyên gia điều tra số. Nếu không có năng lực nội bộ, hãy huy động bên ngoài sớm.
• Cơ quan chức năng. Việc trình báo do pháp chế và ban lãnh đạo quyết định.

Giờ 3 đến 6: xác định phạm vi và giữ bằng chứng

Song song, đội kỹ thuật xác định phạm vi: hệ thống nào bị mã hóa, hệ thống nào bị truy cập nhưng chưa mã hóa, hệ thống nào chưa bị chạm tới. Đừng cho rằng hệ thống chưa mã hóa là an toàn, vì kẻ tấn công thường đã có mặt trong mạng một thời gian trước khi kích hoạt mã hóa.

Việc giữ bằng chứng phải làm ngay trong giai đoạn này vì log có vòng đời hữu hạn:

• Kéo dài thời gian lưu trữ log ngay ở tầng hệ điều hành, ứng dụng, mạng và cloud. Log xoay vòng theo dung lượng có thể mất trong vài giờ.
• Xuất log ra nơi lưu trữ riêng mà tài khoản bị nghi ngờ không truy cập được.
• Tạo snapshot volume bị ảnh hưởng trước khi thao tác lên chúng.

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 \
  --description ir-evidence-2026-08-10-web01

• Nếu có năng lực, thu thập ảnh bộ nhớ của máy còn bật trước khi cách ly hoàn toàn.
• Ghi lại chuỗi bảo quản: ai thu thập, lúc nào, lưu ở đâu.

Cũng trong giai đoạn này, hãy tìm dấu hiệu dữ liệu bị lấy ra ngoài: lưu lượng đi ra bất thường, tài khoản lưu trữ đám mây lạ, kết nối tới dịch vụ chia sẻ file. Điều này chuyển sự cố từ vấn đề sẵn sàng hệ thống sang vấn đề bảo mật dữ liệu, và ảnh hưởng trực tiếp tới nghĩa vụ mà pháp chế phải đánh giá.

Giờ 6 đến 12: backup là tài sản quan trọng nhất lúc này

Trước khi nghĩ tới khôi phục, phải trả lời ba câu hỏi về backup.

Backup còn nguyên vẹn không? Kiểm tra các bản sao lưu có bị xóa, mã hóa hoặc đổi chính sách lưu trữ không, và soát nhật ký hệ thống backup xem có thao tác quản trị bất thường gần đây.

Backup có sạch không? Câu hỏi khó hơn. Nếu kẻ tấn công đã hiện diện nhiều tuần trước khi kích hoạt mã hóa, các bản backup gần nhất nhiều khả năng đã chứa sẵn công cụ truy cập từ xa của họ, và khôi phục từ đó đưa kẻ tấn công quay lại cùng dữ liệu. Hãy xác định thời điểm xâm nhập ban đầu càng chính xác càng tốt, chọn bản backup trước đó, và quét dữ liệu trong môi trường cách ly trước khi đưa về mạng sản xuất.

Khôi phục mất bao lâu? Đo bằng thử nghiệm thật chứ không bằng con số trong tài liệu. Khôi phục vài terabyte từ lưu trữ lạnh có thể mất nhiều ngày.

Giờ 12 đến 24: đường vào, rồi mới đến khôi phục

Đây là phần dễ bị bỏ qua nhất dưới áp lực khôi phục dịch vụ, và quyết định bạn có bị mã hóa lần hai hay không. Nhiều tổ chức khôi phục nhanh, chạy lại vài ngày, rồi bị tấn công lại bằng đúng con đường cũ.

Trước khi đưa hệ thống trở lại, hãy trả lời được bốn câu hỏi, kể cả khi chưa đầy đủ: kẻ tấn công vào bằng đâu, đã có mặt bao lâu, chiếm được tài khoản nào, và cài cắm cơ chế duy trì truy cập nào. Đường vào thường gặp gồm dịch vụ truy cập từ xa mở ra Internet, lỗ hổng chưa vá trên thiết bị biên, thông tin đăng nhập bị lộ, và truy cập qua tài khoản nhà cung cấp dịch vụ.

Trình tự khôi phục hợp lý:

1. Dựng môi trường sạch tách biệt, ưu tiên cài mới từ nguồn tin cậy thay vì làm sạch máy cũ.
2. Vá lỗ hổng đã xác định là đường vào và đóng các đường tương tự.
3. Đổi toàn bộ thông tin 身份验证: mật khẩu người dùng, khóa dịch vụ, chứng thư, bí mật trong CI/CD. Nếu máy chủ điều khiển miền có thể đã bị chiếm, hãy coi như mọi thông tin xác thực trong miền đều đã lộ và xử lý theo hướng dẫn của nhà cung cấp.
4. Khôi phục dữ liệu vào môi trường cách ly, quét và xác minh toàn vẹn trước khi kết nối mạng.
5. Đưa dịch vụ trở lại theo nhóm, ưu tiên hệ thống thiết yếu, tăng cường giám sát sau đó.

Vấn đề tiền chuộc

Sớm muộn câu hỏi này cũng được đặt ra. Quyết định trả hay không trả tiền chuộc là quyết định kinh doanh và pháp lý thuộc thẩm quyền ban lãnh đạo, với tư vấn của luật sư và bên bảo hiểm. Bài viết này không khuyến nghị theo hướng nào, và đội kỹ thuật cũng không nên khuyến nghị.

Đội kỹ thuật cần cung cấp dữ kiện chính xác để người có thẩm quyền quyết định: hiện trạng và mức độ tin cậy của backup, thời gian khôi phục ước tính, phạm vi bị ảnh hưởng, và bằng chứng về việc dữ liệu có bị lấy ra ngoài hay không. Cần nêu rõ: có công cụ giải mã không đồng nghĩa với khôi phục nhanh hay đầy đủ; giải mã không loại bỏ nhu cầu tìm và đóng đường vào, và không thay đổi thực tế dữ liệu đã bị sao chép ra ngoài. Các giao dịch loại này còn có thể chịu ràng buộc pháp lý mà chỉ luật sư đánh giá được.

通知义务

Một sự cố ransomware có thể làm phát sinh nghĩa vụ thông báo cho cơ quan quản lý, khách hàng, đối tác theo hợp đồng hoặc theo quy định của ngành. Xác định nghĩa vụ nào áp dụng, phạm vi và trình tự ra sao là công việc của luật sư, dựa trên loại dữ liệu, đối tượng dữ liệu, lĩnh vực hoạt động và cam kết hợp đồng. Nếu có khách hàng hoặc dữ liệu ở nước ngoài, có thể còn quy định khác.

Đội kỹ thuật cần cung cấp cho pháp chế bức tranh chính xác và cập nhật: hệ thống nào bị ảnh hưởng, dữ liệu nào nằm trên đó, bằng chứng nào về việc dữ liệu bị truy cập hay lấy ra, và khoảng thời gian sự cố. Đừng đưa tuyên bố dứt khoát ra bên ngoài khi chưa đủ dữ liệu.

Những sai lầm hay gặp trong ngày đầu

• Tắt nguồn hàng loạt máy chủ trước khi thu thập bằng chứng.
• Cài lại máy bị nhiễm rồi mới nhận ra không còn gì để điều tra.
• Khôi phục ngay khi có backup, trước khi biết đường vào.
• Trao đổi về sự cố qua email công ty có thể đã bị xâm nhập.
• Không ghi lại mốc thời gian, nên không dựng lại được diễn biến.
• Chỉ đổi mật khẩu người dùng mà quên khóa dịch vụ, token và chứng thư.

Sau 24 giờ

Hết ngày đầu, mục tiêu hợp lý là đã ngăn được lây lan, giữ được bằng chứng, biết sơ bộ phạm vi, xác minh tình trạng backup và có các bên liên quan tham gia. Khôi phục toàn bộ thường mất nhiều ngày tới nhiều tuần và nên theo thứ tự ưu tiên nghiệp vụ. Duy trì giám sát tăng cường vài tuần, rồi rà soát sau sự cố theo hướng tìm nguyên nhân hệ thống chứ không tìm người chịu lỗi; phát hiện giá trị nhất thường là quy trình: cảnh báo không ai đọc, backup chưa từng thử khôi phục, danh sách liên hệ đã cũ.

HiTechCloud có thể hỗ trợ gì

HiTechCloud hỗ trợ doanh nghiệp tại Việt Nam chuẩn bị trước khi tình huống này xảy ra: kiến trúc sao lưu có bản sao tách biệt và bất biến, kiểm thử khôi phục định kỳ, phân vùng mạng hạn chế lây lan, cấu hình lưu trữ và tập trung log phục vụ điều tra, xây dựng kịch bản ứng phó. Chúng tôi vận hành hạ tầng đặt trong nước, đồng thời là đối tác của AWS và Google Premier Partner. Với điều tra số chuyên sâu và tư vấn pháp lý, doanh nghiệp nên làm việc với đơn vị chuyên trách và luật sư.