Threat Hunting: What It Is and How It Works

Threat hunting là hoạt động tìm kiếm chủ động trên các mạng và endpoint để phát hiện những kẻ tấn công đã vượt qua các biện pháp phát hiện hiện có của bạn. Nó bắt đầu từ một giả định đơn giản nhưng khó chịu: có thể cái gì đó xấu đã ở bên trong, nhưng không có cảnh báo nào được kích hoạt. Thay vì chờ một quy tắc SIEM được kích hoạt, một nhà săn tìm sẽ hình thành một giả thuyết và tìm kiếm bằng chứng để xác nhận hoặc bác bỏ nó.

Tại sao chỉ phát hiện là không đủ

Phát hiện dựa trên chữ ký và dựa trên quy tắc có thể bắt được các mẫu đã biết. Những kẻ tấn công sử dụng living-off-the-land binaries (LOLBins), thông tin xác thực hợp lệ, hoặc các kỹ thuật chậm, thấp cấp có thể nằm dưới những ngưỡng đó trong nhiều tuần. Threat hunting lấp khoảng trống này bằng cách có một con người chủ động đặt câu hỏi về dữ liệu: việc gọi PowerShell này từ một workstation tài chính lúc 2 giờ sáng có hợp lý không? Tại sao svchost.exe lại tạo kết nối outbound tới một IP không có reverse DNS?

Đây không phải là incident response. IR bắt đầu sau khi bạn biết có chuyện gì đó đã xảy ra. Hunting bắt đầu khi bạn chưa biết, và mục tiêu là phát hiện điều đó trước khi một sự kiện lớn hơn buộc phải đặt câu hỏi.

Ba điểm khởi đầu phổ biến

Hầu hết các cuộc săn tìm bắt đầu từ một trong ba góc độ:

• Intelligence-driven: một báo cáo mối đe dọa mới mô tả một TTP (chẳng hạn, lạm dụng scheduled task để duy trì), và bạn kiểm tra xem nó có có trong môi trường của bạn không.
• Situational awareness: bạn nhìn vào những gì thực sự bất thường cho tổ chức của bạn — một tài khoản dịch vụ xác thực từ một quốc gia mà nó không bao giờ xác thực trước, hoặc sự tăng đột biến lưu lượng SMB giữa các workstation thường chỉ giao tiếp với các máy chủ.
• Analytics-driven: bạn xây dựng một đường cơ sở của hành vi bình thường (process trees, login times, DNS query volume) và săn tìm các ngoại lệ thống kê đối với nó.

MITRE ATT&CK là tài liệu tham khảo mà hầu hết các nhóm sử dụng để cấu trúc các giả thuyết. Thay vì "tìm kiếm malware", bạn chọn một kỹ thuật như T1053 (Scheduled Task/Job) và hỏi: điều đó sẽ trông như thế nào trong Windows Event Logs hoặc EDR telemetry của chúng tôi, và tôi có thể truy vấn nó ngay bây giờ không?

Workflow thực tế trông như thế nào

Một cuộc săn tìm thường tuân theo vòng lặp này:

1. Hình thành một giả thuyết cụ thể, có thể kiểm tra được (không phải "kiểm tra xem có xâm nhập không" mà là "kiểm tra các scheduled task mới được tạo ngoài cửa sổ patch trong 30 ngày qua").
2. Xác định các nguồn dữ liệu cần thiết — Sysmon Event ID 1 để tạo quy trình, Windows Security Event ID 4698 để tạo scheduled task, EDR process trees, hoặc Zeek conn logs để có ngữ cảnh mạng.
3. Truy vấn và pivot. Trong thực tế, điều này có nghĩa là viết KQL trong Microsoft Sentinel, SPL trong Splunk, hoặc các truy vấn thô đối với chỉ mục Elastic.
4. Triage kết quả — hầu hết sẽ là false positives hoặc hoạt động admin lành tính, và công việc là thu hẹp tiếng ồn đó xuống những gì thực sự bất thường.
5. Ghi lại các phát hiện, cho dù đó là một vụ compromise được xác nhận, một khoảng trống phát hiện, hoặc chỉ là