Memory forensics với Volatility 3: case ransomware thực tế đã xử lý

5:40 sáng, một máy chủ file trong mạng nội bộ bắt đầu đổi tên hàng loạt file thành đuôi lạ, kèm một file README_DECRYPT.txt trong mỗi thư mục. Phản xạ đầu tiên của nhiều người là tắt máy ngay — đó cũng là cách chắc chắn nhất để mất toàn bộ bằng chứng đang nằm trong RAM.

Thu thập ảnh RAM trước khi cách ly

winpmem.exe E:\evidence\fileserver01_mem.raw

Sau khi có ảnh RAM, mới rút cáp mạng để ngăn ransomware lan tiếp hoặc tiếp tục exfiltrate dữ liệu.

Bước 1: Tìm tiến trình đáng ngờ bằng cách so sánh hai góc nhìn

python vol.py -f fileserver01_mem.raw windows.pslist
python vol.py -f fileserver01_mem.raw windows.psscan

Trong case này, cả hai lệnh đều thấy cùng một tiến trình lạ: svchost32.exe (chú ý số "32" — svchost.exe thật không có đuôi số, đây là kỹ thuật nguỵ trang tên phổ biến). Việc nó xuất hiện ở cả hai danh sách nghĩa là nó không cố giấu mình khỏi danh sách tiến trình (không dùng kỹ thuật DKOM) — ransomware thường không cần giấu vì chúng hoạt động công khai, ồn ào, không giống backdoor cần âm thầm tồn tại lâu dài.

Bước 2: Dòng lệnh khởi chạy — thường lộ ngay ý đồ

python vol.py -f fileserver01_mem.raw windows.cmdline --pid 4192

Process: svchost32.exe   PID: 4192
Args: svchost32.exe -path C:\Shares\ -ext .locked1337 -delete-shadow

Ba tham số này kể toàn bộ câu chuyện: mã hoá đường dẫn C:\Shares\ (đúng nơi dữ liệu bị ảnh hưởng), đổi đuôi thành .locked1337, và xoá shadow copy — bước ransomware luôn làm để ngăn khôi phục bằng Windows System Restore. Đây cũng là chi tiết quan trọng nhất cho phase khắc phục: nếu shadow copy đã bị xoá thành công, phương án khôi phục phải chuyển hẳn sang backup ngoài máy.

Bước 3: Tìm điểm vào — process nào đã sinh ra nó

python vol.py -f fileserver01_mem.raw windows.pstree

explorer.exe (2044)
├─ outlook.exe (3316)
│   └─ svchost32.exe (4192)

Đây là mảnh ghép quan trọng: ransomware được sinh ra từ Outlook, không phải từ một exploit trên máy chủ. Nghĩa là gần như chắc chắn điểm vào là một file đính kèm độc hại đã được mở trên máy này (máy chủ file này cũng được dùng để check mail — một sai lầm về mặt kiến trúc mạng, đáng ghi vào phần "cần sửa" của report), không phải lỗ hổng dịch vụ mạng bị khai thác trực tiếp.

Bước 4: Tìm kết nối mạng — có exfiltration không?

python vol.py -f fileserver01_mem.raw windows.netscan | grep 4192

TCP  10.20.4.30:51022 → 91.<redacted>:443  ESTABLISHED  svchost32.exe  4192

Một kết nối HTTPS đang mở tới một IP ngoài — cần điều tra thêm liệu đây là kênh C2 để nhận lệnh, hay là kênh exfiltration dữ liệu trước khi mã hoá (double extortion — kỹ thuật ngày càng phổ biến: đánh cắp dữ liệu trước, mã hoá sau, đe doạ công khai dữ liệu nếu không trả tiền). Log firewall/proxy tại thời điểm đó xác nhận có khoảng 2GB dữ liệu đã được gửi ra ngoài trong 40 phút trước khi mã hoá bắt đầu — xác nhận đây là case double extortion, không chỉ mã hoá đơn thuần.

Tổng hợp IOC thu được từ RAM

Bài học rút ra cho lần sau

1. Cách ly mạng ngay khi phát hiện, nhưng dump RAM trước khi tắt máy — thứ tự này quyết định có bằng chứng hay không.
2. Máy chủ dữ liệu quan trọng không nên có ứng dụng mail client — điểm vào của case này hoàn toàn có thể tránh được bằng cách tách vai trò máy.
3. Shadow copy protection cần thêm lớp bảo vệ (immutable backup ngoài máy) — vì vssadmin delete shadows là lệnh gần như mọi ransomware hiện đại đều chạy, không thể coi shadow copy là tuyến phòng thủ chính.
4. Nếu có dấu hiệu exfiltration, phải coi đây là sự cố rò rỉ dữ liệu, không chỉ là sự cố mã hoá — kéo theo nghĩa vụ thông báo khác nhau tuỳ quy định của tổ chức.

Ransomware là một trong ít loại sự cố mà RAM tại đúng thời điểm quý hơn ổ đĩa rất nhiều — vì phần lớn câu chuyện chỉ tồn tại ở đó trong vài giờ ngắn ngủi.