2.1 Kỹ năng cần thiết để làm Threat Hunting

Săn tìm mối đe dọa (Threat Hunting) đòi hỏi một nhóm kỹ năng khác với SOC, IR, Pentest và Red Team. SOC cần năng lực giám sát cảnh báo, phân loại sự kiện và xử lý theo playbook. IR cần năng lực điều tra sự cố, cô lập hệ thống, thu thập bằng chứng và khôi phục vận hành. Pentest và Red Team cần năng lực mô phỏng tấn công để kiểm tra điểm yếu. Threat Hunting cần năng lực đặt giả thuyết, tìm kiếm dấu vết yếu, phân tích dữ liệu lịch sử và chuyển kết quả điều tra thành năng lực phát hiện mới.

Kỹ năng đầu tiên là tư duy giả thuyết (hypothesis driven thinking). Threat Hunter phải biết bắt đầu từ một câu hỏi có thể kiểm chứng. Câu hỏi đó cần nêu rõ kỹ thuật tấn công, phạm vi hệ thống, nguồn dữ liệu cần kiểm tra và dấu hiệu kỳ vọng. Một giả thuyết tốt không chỉ nêu điều cần tìm, mà còn chỉ ra dữ liệu nào có thể chứng minh hoặc bác bỏ giả thuyết đó.

Kỹ năng thứ hai là hiểu hành vi tấn công (attacker behavior). Threat Hunter cần hiểu cách đối thủ xâm nhập, duy trì truy cập, leo thang đặc quyền, di chuyển ngang, thu thập thông tin và rút dữ liệu. MITRE ATT&CK là khung tham chiếu quan trọng, nhưng Hunter không nên chỉ nhớ tên kỹ thuật. Điều quan trọng là hiểu mỗi kỹ thuật sẽ để lại dấu vết gì trên endpoint, network, identity, cloud và log ứng dụng.

Kỹ năng thứ ba là phân tích dữ liệu bảo mật (security data analysis). Threat Hunting thường làm việc với dữ liệu lớn, nhiều nguồn và nhiều nhiễu. Hunter cần biết truy vấn SIEM, EDR, DNS log, proxy log, firewall log, Windows Event Log, Sysmon, Zeek, Suricata và cloud audit log. Các kỹ thuật như thống kê tần suất, phát hiện outlier, phân tích chuỗi thời gian, phân tích graph và dựng timeline đều cần thiết.

Kỹ năng thứ tư là viết truy vấn và tự động hóa. Threat Hunter cần thành thạo KQL, SPL, SQL, Sigma, YARA, regex và Python. Truy vấn tốt giúp thu hẹp không gian điều tra. Python giúp xử lý dữ liệu, chuẩn hóa log, tính toán đặc trưng, dựng notebook và tái sử dụng quy trình hunt cho các lần sau.

Kỹ năng thứ năm là điều tra liên nguồn (cross source investigation). Một dấu hiệu riêng lẻ thường chưa đủ kết luận. Hunter cần biết pivot từ DNS sang proxy, từ proxy sang EDR, từ EDR sang Windows Event Log, từ tài khoản sang máy trạm, từ máy trạm sang cloud activity. Kỹ năng này giúp phân biệt nhiễu vận hành với dấu hiệu tấn công thật.

Kỹ năng thứ sáu là detection engineering. Threat Hunting không dừng ở việc tìm thấy dấu hiệu đáng ngờ. Kết quả hunt cần được chuyển thành rule, dashboard, playbook, test case hoặc yêu cầu bổ sung telemetry. Đây là điểm làm Threat Hunting khác với điều tra thủ công thông thường. Một hunt tốt phải làm cho hệ thống phát hiện tốt hơn trong tương lai.

2.2 Kỹ năng AI cần bổ sung cho Threat Hunting

Trí tuệ nhân tạo (Artificial Intelligence, AI) đang trở thành năng lực hỗ trợ quan trọng trong Threat Hunting. AI không thay thế Threat Hunter, nhưng giúp tăng tốc phân tích, mở rộng khả năng xử lý dữ liệu và hỗ trợ sinh giả thuyết.

Kỹ năng đầu tiên là sử dụng mô hình ngôn ngữ lớn (Large Language Model, LLM) cho phân tích bảo mật. Threat Hunter có thể dùng LLM để tóm tắt log dài, giải thích command line đáng ngờ, phân loại hành vi tiến trình, đọc nhanh báo cáo Threat Intelligence, chuyển đổi rule giữa các nền tảng và hỗ trợ viết báo cáo hunt. Tuy nhiên, mọi kết quả từ LLM phải được kiểm chứng bằng dữ liệu gốc.

Kỹ năng thứ hai là prompt engineering cho security. Hunter cần biết đặt yêu cầu rõ ràng, cung cấp ngữ cảnh hệ thống, mô tả nguồn log, yêu cầu đầu ra có cấu trúc và buộc mô hình phân biệt giữa bằng chứng, giả định và kết luận. Prompt dùng cho Threat Hunting không nên chỉ hỏi chung chung. Nó cần hướng mô hình vào nhiệm vụ cụ thể như sinh giả thuyết, gợi ý pivot, phân tích command line, hoặc đề xuất detection logic.

Kỹ năng thứ ba là hiểu học máy (Machine Learning, ML) ở mức ứng dụng. Threat Hunter không nhất thiết phải là chuyên gia ML, nhưng cần hiểu anomaly detection, clustering, classification, embedding và time series analysis. Kiến thức này giúp Hunter biết khi nào nên tin kết quả mô hình, khi nào phải nghi ngờ false positive và khi nào dữ liệu đầu vào chưa đủ chất lượng.

Kỹ năng thứ tư là phân tích hành vi bằng AI. AI có thể hỗ trợ phát hiện user bất thường, endpoint bất thường, domain bất thường, beaconing, DNS tunneling, lateral movement và misuse tài khoản hợp lệ. Tuy nhiên, Hunter phải hiểu baseline vận hành của tổ chức. Nếu không hiểu hành vi bình thường, AI rất dễ tạo ra danh sách bất thường nhưng không có giá trị điều tra.

Kỹ năng thứ năm là xây dựng AI assisted hunt workflow. Một workflow phù hợp có thể gồm các bước: lấy dữ liệu từ SIEM hoặc EDR, chuẩn hóa dữ liệu, dùng AI để tóm tắt mẫu hành vi, dùng script để kiểm chứng, dùng Hunter để đánh giá ngữ cảnh, sau đó chuyển kết quả thành detection rule. Trong workflow này, AI chỉ là thành phần hỗ trợ phân tích. Quyết định cuối cùng vẫn thuộc về Hunter.

Kỹ năng thứ sáu là nhận diện tấn công có sử dụng AI. Đối thủ có thể dùng AI để tạo phishing, sinh mã độc biến thể, viết script tự động, tạo nội dung đánh lừa người dùng, giả mạo giọng nói hoặc tăng tốc reconnaissance. Vì vậy, Threat Hunter cần bổ sung các hunt use case liên quan đến AI generated phishing, bất thường trong nội dung email, automation bất thường trong đăng nhập, hành vi reconnaissance tốc độ cao và misuse các công cụ AI nội bộ.

Kỹ năng thứ bảy là bảo vệ AI agent trong security workflow. Khi tổ chức dùng AI agent để hỗ trợ SOC hoặc Threat Hunting, Hunter cần hiểu nguy cơ prompt injection, data leakage, tool abuse và hành động tự động ngoài phạm vi. AI agent không nên được cấp quyền truy cập rộng vào dữ liệu nhạy cảm hoặc quyền thực thi hành động phản hồi nếu không có cơ chế kiểm soát rõ ràng.

Kỹ năng thứ tám là đánh giá độ tin cậy của AI output. AI có thể tạo ra kết luận nghe hợp lý nhưng sai. Threat Hunter cần luôn kiểm tra ba điểm: dữ liệu gốc có đủ không, lập luận có dựa trên bằng chứng không, và kết luận có thể tái lập bằng truy vấn hoặc log không. Trong Threat Hunting, một nhận định chỉ có giá trị khi có evidence đi kèm.

2.3 Điểm khác biệt cốt lõi về kỹ năng

SOC Analyst giỏi cần phản ứng nhanh với alert và xử lý đúng quy trình.

IR Analyst giỏi cần điều tra sâu sau khi sự cố đã rõ hoặc có dấu hiệu mạnh.

Pentester và Red Teamer giỏi cần hiểu cách tấn công để kiểm tra khả năng phòng thủ.

Threat Hunter giỏi cần kết hợp cả bốn nhóm năng lực trên, nhưng dùng chúng theo hướng khác. Hunter không đợi alert, không chỉ xử lý sự cố đã biết, không chỉ mô phỏng tấn công và không chỉ vận hành công cụ. Hunter đặt giả thuyết, tìm bằng chứng, kiểm tra dữ liệu, loại bỏ nhiễu, phát hiện khoảng trống và chuyển tri thức điều tra thành năng lực phát hiện lâu dài.

Trong bối cảnh AI, Threat Hunter cần thêm một lớp năng lực mới. Đó là biết dùng AI để tăng tốc phân tích, nhưng không để AI thay thế phán đoán chuyên môn. AI giúp mở rộng khả năng xử lý dữ liệu. Con người vẫn chịu trách nhiệm về giả thuyết, ngữ cảnh, bằng chứng và kết luận.

4. Vòng đời của một Threat Hunt

Một Threat Hunt không nên được hiểu là một lần tìm kiếm rời rạc trong SIEM hoặc EDR. Về bản chất, đây là một cuộc điều tra có cấu trúc, bắt đầu từ giả thuyết, đi qua quá trình kiểm chứng bằng dữ liệu, sau đó kết thúc bằng một kết luận có bằng chứng. Giá trị của Threat Hunt không chỉ nằm ở việc phát hiện xâm phạm, mà còn nằm ở việc làm rõ khả năng quan sát của tổ chức, tìm ra khoảng trống dữ liệu và cải thiện năng lực phát hiện trong tương lai.

Một vòng đời Threat Hunt tốt cần có năm giai đoạn chính. Mỗi giai đoạn có mục tiêu, dữ liệu đầu vào, công việc phân tích và sản phẩm đầu ra riêng. Nếu thiếu một trong các giai đoạn này, hoạt động hunting dễ trở thành truy vấn thủ công không có phương pháp, khó tái lập và khó chuyển hóa thành năng lực vận hành lâu dài.

4.1 Bước 1. Xác định mục tiêu và hình thành giả thuyết

Giai đoạn đầu tiên là xác định mục tiêu của hunt và xây dựng giả thuyết có thể kiểm chứng. Đây là bước quyết định chất lượng của toàn bộ quá trình. Một giả thuyết mơ hồ sẽ tạo ra kết quả mơ hồ. Một giả thuyết cụ thể sẽ giúp Hunter biết cần tìm gì, tìm ở đâu, dùng dữ liệu nào và kết luận theo tiêu chí nào.

Giả thuyết trong Threat Hunting cần có bốn đặc điểm. Thứ nhất, giả thuyết phải cụ thể về kỹ thuật hoặc hành vi tấn công. Thứ hai, giả thuyết phải gắn với một phạm vi hệ thống rõ ràng. Thứ ba, giả thuyết phải kiểm chứng được bằng dữ liệu hiện có. Thứ tư, giả thuyết phải có giá trị rủi ro đủ lớn để ưu tiên điều tra.

Ví dụ, giả thuyết không nên dừng ở mức có kẻ tấn công trong hệ thống hay không. Cách viết này quá rộng và không thể triển khai thành hành động cụ thể. Một giả thuyết tốt hơn là có dấu hiệu nào cho thấy WMI Subscription đang được sử dụng để duy trì truy cập trên các máy chủ Windows quan trọng trong ba mươi ngày gần nhất hay không. Với cách viết này, Hunter biết rõ kỹ thuật cần kiểm tra là WMI Subscription, phạm vi là máy chủ Windows quan trọng, thời gian là ba mươi ngày và dữ liệu cần xem là Windows Event Log, Sysmon, EDR telemetry và thông tin cấu hình WMI.

Nguồn hình thành giả thuyết có thể đến từ Threat Intelligence, MITRE ATT&CK, kết quả IR trước đó, cảnh báo SOC lặp lại nhiều lần, thay đổi kiến trúc hệ thống, sự kiện nghiệp vụ quan trọng, hoặc trực giác chuyên môn của Hunter. Trong môi trường trưởng thành hơn, tổ chức nên duy trì một hypothesis backlog. Đây là danh sách các giả thuyết đang chờ kiểm tra, có mức ưu tiên, người phụ trách, phạm vi dữ liệu, trạng thái và kết quả xử lý.

Sản phẩm đầu ra của bước này là một hunt plan ngắn gọn. Hunt plan nên nêu rõ mục tiêu, giả thuyết, phạm vi hệ thống, khoảng thời gian điều tra, nguồn dữ liệu dự kiến, tiêu chí xác nhận, tiêu chí bác bỏ và mức độ ưu tiên. Nếu có sử dụng MITRE ATT&CK, cần ghi rõ tactic, technique và sub technique tương ứng.

4.2 Bước 2. Xác định và đánh giá nguồn dữ liệu

Sau khi có giả thuyết, Hunter cần xác định nguồn dữ liệu phù hợp để kiểm chứng. Đây là bước thường bị xem nhẹ, nhưng lại quyết định hunt có thể thực hiện được hay không. Một giả thuyết dù tốt cũng không có giá trị nếu tổ chức không có dữ liệu để kiểm tra.

Nguồn dữ liệu có thể gồm Windows Event Log, Sysmon, EDR telemetry, DNS log, proxy log, firewall log, Zeek log, Suricata alert, VPN log, Active Directory log, IAM log, CloudTrail, Azure Activity Log, Kubernetes audit log, CI/CD log và log ứng dụng. Với mỗi nguồn dữ liệu, Hunter cần kiểm tra ba vấn đề: coverage, retention và quality.

Coverage cho biết dữ liệu có bao phủ đúng tài sản cần điều tra hay không. Ví dụ, nếu giả thuyết liên quan đến máy chủ quan trọng nhưng EDR chỉ được cài trên máy trạm, dữ liệu không đủ để kết luận. Retention cho biết dữ liệu còn lưu trong khoảng thời gian cần kiểm tra hay không. Nếu giả thuyết yêu cầu xem ba mươi ngày nhưng log chỉ lưu bảy ngày, kết luận sẽ bị giới hạn. Quality cho biết dữ liệu có đủ trường thông tin cần thiết hay không. Ví dụ, log tiến trình không có command line sẽ làm giảm mạnh khả năng phát hiện hành vi lạm dụng PowerShell hoặc LOLBin.

Ở bước này, Hunter không chỉ thu thập dữ liệu. Hunter còn phải đánh giá khả năng quan sát của tổ chức. Nếu thiếu log, thiếu trường dữ liệu, thiếu đồng bộ thời gian, thiếu mapping giữa IP và hostname, hoặc thiếu thông tin người dùng, đó cũng là một phát hiện quan trọng. Nhiều hunt không tìm thấy tấn công, nhưng lại phát hiện tổ chức không có đủ telemetry để xác nhận an toàn. Đây là một kết quả có giá trị quản trị rất lớn.

Sản phẩm đầu ra của bước này là data readiness note. Tài liệu này cần ghi rõ nguồn dữ liệu đã dùng, phạm vi bao phủ, thời gian lưu trữ, trường dữ liệu quan trọng, giới hạn dữ liệu và tác động của giới hạn đó đến kết luận hunt.

4.3 Bước 3. Thực hiện điều tra và kiểm chứng giả thuyết

Đây là giai đoạn Hunter trực tiếp làm việc với dữ liệu. Công việc không chỉ là chạy một truy vấn rồi đọc kết quả. Hunter phải đi theo chuỗi suy luận có kiểm soát: truy vấn ban đầu, lọc nhiễu, tìm điểm bất thường, pivot sang nguồn dữ liệu khác, dựng timeline, liên kết thực thể và đánh giá bằng chứng.

Truy vấn ban đầu thường được viết theo giả thuyết. Nếu hunt liên quan đến persistence, Hunter có thể tìm scheduled task mới, service mới, registry autorun key, WMI event subscription hoặc binary được đặt trong thư mục bất thường. Nếu hunt liên quan đến lateral movement, Hunter có thể tìm đăng nhập từ xa, sử dụng SMB, RDP, WinRM, PsExec, tài khoản quản trị đăng nhập vào nhiều máy trong thời gian ngắn hoặc xác thực bất thường giữa các vùng mạng.

Sau truy vấn ban đầu, Hunter cần giảm nhiễu. Không phải mọi dấu hiệu bất thường đều là tấn công. Một số tiến trình lạ có thể thuộc phần mềm quản trị, script vận hành, backup agent hoặc công cụ giám sát. Vì vậy, Hunter cần so sánh với baseline vận hành, danh sách tài sản hợp lệ, tài khoản dịch vụ, lịch bảo trì và hành vi thường ngày của hệ thống.

Pivot là kỹ năng trung tâm của giai đoạn này. Một dấu hiệu trên DNS log cần được kiểm tra tiếp trên proxy log. Một kết nối mạng đáng ngờ cần được truy ngược về endpoint. Một tiến trình đáng ngờ cần được xem parent process, command line, user context, file path, hash, network connection và thời điểm thực thi. Một tài khoản bất thường cần được kiểm tra lịch sử đăng nhập, quyền hiện có, thiết bị đã dùng, vị trí truy cập và hoạt động sau đăng nhập.

Trong quá trình điều tra, Hunter cần phân biệt ba mức kết quả. Mức thứ nhất là noise, tức là dữ liệu nhiễu hoặc hành vi hợp lệ. Mức thứ hai là suspicious, tức là dấu hiệu đáng ngờ nhưng chưa đủ bằng chứng để kết luận. Mức thứ ba là confirmed, tức là có bằng chứng đủ mạnh để chuyển sang IR hoặc tạo detection rule. Cách phân loại này giúp tránh hai lỗi phổ biến: bỏ sót tín hiệu quan trọng hoặc thổi phồng một dấu hiệu chưa đủ căn cứ.

Sản phẩm đầu ra của bước này là investigation record. Tài liệu này cần ghi lại truy vấn đã chạy, kết quả chính, cách lọc false positive, các bước pivot, timeline, thực thể liên quan, bằng chứng ủng hộ, bằng chứng phản bác và nhận định tạm thời.

4.4 Bước 4. Kết luận và phản hồi

Khi quá trình điều tra đã đủ dữ liệu, Hunter cần đưa ra kết luận rõ ràng. Kết luận của một Threat Hunt không nên viết chung chung. Cần nêu rõ giả thuyết được xác nhận, bị bác bỏ, hay chưa thể kết luận do thiếu dữ liệu.

Nếu phát hiện dấu hiệu xâm phạm, kết quả phải được chuyển sang IR theo playbook. Khi chuyển giao, Hunter cần cung cấp bằng chứng đã xác minh, phạm vi ảnh hưởng ban đầu, tài khoản liên quan, máy liên quan, thời gian bắt đầu, kỹ thuật nghi ngờ, dữ liệu đã kiểm tra và khuyến nghị hành động khẩn cấp. Việc chuyển giao thiếu ngữ cảnh sẽ làm IR mất thời gian điều tra lại từ đầu.

Nếu không phát hiện bằng chứng xâm phạm, hunt vẫn cần được đóng chính thức. Một kết luận sạch chỉ có giá trị khi nó đi kèm phạm vi đã kiểm tra và giới hạn dữ liệu. Ví dụ, có thể kết luận rằng trong nhóm máy chủ đã cài EDR và có log đầy đủ trong ba mươi ngày, không tìm thấy bằng chứng WMI Subscription persistence theo tiêu chí đã định. Cách kết luận này chính xác hơn nhiều so với nói rằng hệ thống không bị tấn công.

Nếu chưa thể kết luận, Hunter cần ghi rõ nguyên nhân. Nguyên nhân có thể là thiếu log, retention quá ngắn, dữ liệu không có command line, không mapping được IP với hostname, hoặc thiếu audit log trên cloud. Trường hợp này không phải thất bại. Nó chỉ ra một khoảng trống quan sát cần được khắc phục.

Sản phẩm đầu ra của bước này là hunt report. Báo cáo nên có cấu trúc ổn định gồm mục tiêu, giả thuyết, phạm vi, nguồn dữ liệu, phương pháp, phát hiện, kết luận, giới hạn, mức độ tin cậy và hành động tiếp theo.

4.5 Bước 5. Cải thiện năng lực phát hiện

Đây là bước tạo giá trị dài hạn của Threat Hunting. Một hunt không nên kết thúc ở báo cáo. Kết quả điều tra cần được chuyển hóa thành năng lực phát hiện, năng lực phản hồi hoặc năng lực quan sát mới.

Nếu hunt phát hiện hành vi có giá trị, Hunter và Detection Engineer cần chuyển logic điều tra thành rule. Rule có thể ở dạng Sigma, YARA, KQL, SPL, Elastic query hoặc rule gốc của EDR. Nếu hành vi phù hợp để giám sát liên tục, cần đưa vào SIEM hoặc EDR. Nếu hành vi chỉ phù hợp để kiểm tra định kỳ, có thể đưa vào scheduled query hoặc hunt notebook. Nếu cần hành động phản hồi, có thể bổ sung playbook cho SOC hoặc SOAR.

Nếu hunt không phát hiện xâm phạm nhưng phát hiện thiếu dữ liệu, kết quả cần được chuyển thành yêu cầu bổ sung telemetry. Ví dụ, bật PowerShell Script Block Logging, triển khai Sysmon, tăng thời gian lưu log DNS, bổ sung audit log cho cloud, chuẩn hóa schema log, hoặc đồng bộ thời gian bằng NTP. Những cải tiến này giúp hunt sau chính xác hơn.

Nếu hunt tạo ra nhiều false positive, cần cập nhật baseline, whitelist có kiểm soát, asset inventory và logic loại trừ. Tuy nhiên, whitelist không nên dùng tùy tiện. Mỗi ngoại lệ cần có chủ sở hữu, lý do, thời hạn rà soát và bằng chứng hợp lệ. Nếu không kiểm soát, whitelist sẽ trở thành nơi che giấu tấn công.

Sản phẩm đầu ra của bước này có thể là detection rule, dashboard, notebook, playbook, yêu cầu cải thiện log, cập nhật ATT&CK coverage, test case cho Red Team, hoặc bài học kinh nghiệm cho SOC. Đây là điểm biến Threat Hunting thành một vòng học tập liên tục.

4.6 Đánh giá chất lượng một Threat Hunt

Một Threat Hunt tốt cần được đánh giá bằng chất lượng phương pháp, không chỉ bằng việc có tìm thấy tấn công hay không. Một hunt không phát hiện xâm phạm vẫn có thể thành công nếu nó kiểm chứng được giả thuyết, có dữ liệu đầy đủ, kết luận rõ ràng và tạo ra cải tiến cho detection hoặc telemetry.

Có thể đánh giá chất lượng hunt theo sáu tiêu chí. Một là giả thuyết có rõ và kiểm chứng được hay không. Hai là dữ liệu có đủ coverage, retention và quality hay không. Ba là quy trình điều tra có tái lập được hay không. Bốn là kết luận có dựa trên bằng chứng hay không. Năm là kết quả có được chuyển thành detection, playbook hoặc cải tiến vận hành hay không. Sáu là bài học từ hunt có được đưa lại vào hypothesis backlog hay không.

Theo cách này, Threat Hunting không phải hoạt động tìm kiếm may rủi. Nó là một cơ chế học tập có kiểm soát của đội ngũ phòng thủ.

4.7 Vai trò của AI trong vòng đời Threat Hunt

AI có thể hỗ trợ nhiều bước trong vòng đời Threat Hunt, nhưng không thay thế quyết định chuyên môn của Hunter. Ở bước hình thành giả thuyết, AI có thể tóm tắt Threat Intelligence, trích xuất TTP và gợi ý câu hỏi điều tra. Ở bước chuẩn bị dữ liệu, AI có thể hỗ trợ ánh xạ kỹ thuật ATT&CK với nguồn log cần kiểm tra. Ở bước điều tra, AI có thể tóm tắt chuỗi sự kiện, giải thích command line, gợi ý pivot và hỗ trợ phân loại kết quả ban đầu.

Tuy nhiên, Hunter phải luôn kiểm chứng lại bằng dữ liệu gốc. AI có thể suy luận sai, thiếu ngữ cảnh vận hành hoặc tạo ra kết luận không có bằng chứng. Vì vậy, AI nên được dùng như công cụ tăng tốc phân tích, không phải cơ quan kết luận. Mọi nhận định quan trọng trong Threat Hunting vẫn phải dựa trên log, telemetry, timeline và bằng chứng có thể tái lập.

Trong các tổ chức sử dụng AI agent cho SOC hoặc Threat Hunting, cần kiểm soát thêm quyền truy cập dữ liệu, phạm vi hành động, nguy cơ prompt injection, rò rỉ dữ liệu nhạy cảm và khả năng agent thực thi hành động ngoài ý muốn. Nếu AI được đưa vào hunting workflow mà không kiểm soát, chính công cụ hỗ trợ phòng thủ có thể trở thành bề mặt tấn công mới.

5. Điều kiện tiền đề để triển khai Threat Hunting

Threat Hunting chỉ hiệu quả khi tổ chức có đủ dữ liệu, quy trình và năng lực phân tích. Nếu thiếu các điều kiện này, hoạt động hunting dễ biến thành tìm kiếm thủ công trong log mà không có kết luận đáng tin cậy.

Điều kiện đầu tiên là khả năng quan sát (observability). Tổ chức cần có log và telemetry từ endpoint, network, identity, cloud và application. Với endpoint, cần có dữ liệu về process, command line, file, registry, service, scheduled task và network connection. Với network, cần có DNS log, proxy log, firewall log, NetFlow, Zeek hoặc Suricata. Với identity, cần có log xác thực, đăng nhập thất bại, đăng nhập thành công, thay đổi quyền, MFA và hoạt động của tài khoản đặc quyền. Với cloud, cần có audit log, IAM log, storage access log và workload log. Với application, cần có API log, access log, transaction log và log hành vi nghiệp vụ.

Điều kiện thứ hai là thời gian lưu trữ dữ liệu (retention). Threat Hunting thường cần nhìn lại dữ liệu lịch sử. Nếu log chỉ lưu vài ngày, Hunter khó phát hiện dwell time dài, lateral movement chậm hoặc hoạt động rút dữ liệu được chia nhỏ. Với các hệ thống quan trọng, thời gian lưu log nên đủ dài để phục vụ điều tra hồi cứu, tối thiểu theo chu kỳ đánh giá rủi ro của tổ chức.

Điều kiện thứ ba là chất lượng dữ liệu (data quality). Log cần có thời gian chuẩn, định danh người dùng rõ, hostname rõ, địa chỉ IP rõ, command line đầy đủ và khả năng liên kết giữa các nguồn. Một log thiếu command line sẽ làm giảm khả năng phát hiện lạm dụng PowerShell. Một hệ thống không mapping được IP với hostname sẽ làm chậm quá trình pivot. Một môi trường không đồng bộ thời gian sẽ làm timeline thiếu chính xác.

Điều kiện thứ tư là hiểu biết về tài sản (asset context). Hunter cần biết máy nào là domain controller, máy nào là database server, tài khoản nào là service account, subnet nào là vùng người dùng, vùng nào là server, hệ thống nào chứa dữ liệu nhạy cảm. Không có asset context, Hunter rất khó phân biệt hành vi hợp lệ với hành vi bất thường.

Điều kiện thứ năm là baseline vận hành. Threat Hunting cần biết điều gì là bình thường để nhận ra điều bất thường. Ví dụ, tài khoản quản trị đăng nhập vào nhiều máy có thể là hành vi hợp lệ trong giờ bảo trì, nhưng có thể là dấu hiệu lateral movement nếu xảy ra lúc nửa đêm từ một máy trạm không thuộc bộ phận IT.

6. Sản phẩm đầu ra của Threat Hunting

Một điểm cần làm rõ là Threat Hunting không chỉ tạo ra báo cáo. Nếu chỉ dừng ở báo cáo, giá trị của hunt sẽ bị giới hạn. Một hunt tốt cần tạo ra các artifact có thể tái sử dụng cho SOC, IR, Detection Engineering và quản trị rủi ro.

Artifact đầu tiên là hunt plan. Hunt plan mô tả mục tiêu, giả thuyết, phạm vi, nguồn dữ liệu, thời gian điều tra, kỹ thuật ATT&CK liên quan, tiêu chí xác nhận và tiêu chí bác bỏ. Đây là tài liệu giúp hunt có cấu trúc ngay từ đầu.

Artifact thứ hai là investigation notebook. Notebook ghi lại truy vấn, kết quả, bước pivot, biểu đồ, timeline, thực thể liên quan và nhận định trung gian. Notebook giúp tái lập quá trình điều tra, hỗ trợ đào tạo Hunter mới và làm bằng chứng cho kết luận.

Artifact thứ ba là detection logic. Đây có thể là Sigma rule, YARA rule, KQL query, SPL query, Elastic query hoặc rule gốc trong EDR. Detection logic là cách chuyển kết quả hunt thành năng lực phát hiện liên tục.

Artifact thứ tư là telemetry gap report. Nếu hunt không thể kết luận do thiếu dữ liệu, kết quả đó cần được ghi nhận thành yêu cầu cải thiện logging. Ví dụ, bật PowerShell Script Block Logging, bổ sung Sysmon, tăng retention DNS log, bật audit log trong cloud hoặc chuẩn hóa schema log.

Artifact thứ năm là hunt report. Báo cáo cần nêu rõ giả thuyết, phạm vi, dữ liệu đã kiểm tra, phương pháp, phát hiện, kết luận, giới hạn, mức độ tin cậy và khuyến nghị. Báo cáo tốt phải giúp người đọc hiểu được vì sao Hunter đưa ra kết luận đó.

Artifact thứ sáu là playbook cập nhật cho SOC hoặc IR. Nếu hunt phát hiện một hành vi có thể tái diễn, SOC cần biết cách triage alert tương ứng. Nếu hunt phát hiện dấu hiệu xâm phạm rõ, IR cần có thông tin để cô lập, điều tra và xử lý.

7. Các use case Threat Hunting tiêu biểu

Use case thứ nhất là săn tìm persistence. Hunter kiểm tra các cơ chế duy trì truy cập như scheduled task mới, service mới, registry autorun key, WMI event subscription, startup folder và script lạ. Nguồn dữ liệu chính gồm Windows Event Log, Sysmon, EDR telemetry và registry event.

Use case thứ hai là săn tìm lateral movement. Hunter kiểm tra đăng nhập từ xa, RDP, WinRM, SMB, PsExec, admin share, tài khoản quản trị đăng nhập vào nhiều máy trong thời gian ngắn và xác thực bất thường giữa các vùng mạng. Nguồn dữ liệu chính gồm Windows Security Log, EDR, firewall log, NetFlow và Active Directory log.

Use case thứ ba là săn tìm credential access. Hunter kiểm tra dấu hiệu truy cập LSASS, tạo dump file, Kerberoasting, password spraying, brute force phân tán, truy cập bất thường vào secret store và sử dụng công cụ lấy thông tin xác thực. Nguồn dữ liệu chính gồm EDR, Windows Event Log, Active Directory, IAM log và SIEM.

Use case thứ tư là săn tìm C2 beaconing. Hunter phân tích kết nối định kỳ, DNS request có entropy cao, domain mới đăng ký, User Agent lạ, JA3 fingerprint bất thường và lưu lượng nhỏ nhưng lặp lại đều. Nguồn dữ liệu chính gồm DNS log, proxy log, firewall log, Zeek, Suricata và EDR.

Use case thứ năm là săn tìm exfiltration. Hunter kiểm tra upload dữ liệu lớn, lưu lượng ra ngoài bất thường, truy cập cloud storage không thuộc danh sách cho phép, DNS tunneling, nén dữ liệu bất thường và truy cập file hàng loạt. Nguồn dữ liệu chính gồm proxy log, firewall log, DLP log, file server log, cloud storage log và application log.

Use case thứ sáu là săn tìm misuse tài khoản hợp lệ. Hunter kiểm tra đăng nhập từ vị trí lạ, impossible travel, thay đổi thiết bị, truy cập ngoài giờ, MFA fatigue, tài khoản service hoạt động như tài khoản người dùng và quyền được cấp vượt nhu cầu. Nguồn dữ liệu chính gồm IAM log, VPN log, Active Directory log, Azure AD sign in log và cloud audit log.

Use case thứ bảy là săn tìm tấn công vào ứng dụng. Hunter kiểm tra truy cập API bất thường, IDOR, scraping, tăng quyền theo logic nghiệp vụ, thay đổi cấu hình nhạy cảm, truy vấn dữ liệu hàng loạt và hành vi automation. Nguồn dữ liệu chính gồm API gateway log, web server log, application log, database audit log và transaction log.

8. Đo lường hiệu quả Threat Hunting

Một chương trình Threat Hunting cần được đo lường. Nếu không có chỉ số, tổ chức khó biết hoạt động hunting có tạo ra giá trị hay không.

Chỉ số đầu tiên là số lượng giả thuyết đã kiểm chứng. Chỉ số này cho biết đội ngũ có duy trì hoạt động hunt đều đặn hay không. Tuy nhiên, không nên dùng số lượng làm chỉ số duy nhất, vì nhiều hunt ít nhưng sâu có thể giá trị hơn nhiều hunt nông.

Chỉ số thứ hai là tỷ lệ hunt tạo ra cải tiến detection. Đây là chỉ số quan trọng hơn số lượng hunt. Một hunt tốt nên tạo ra rule mới, cải thiện rule cũ, giảm false positive, bổ sung dashboard hoặc cập nhật playbook.

Chỉ số thứ ba là số lượng telemetry gap được phát hiện và khắc phục. Threat Hunting giúp tổ chức biết mình đang thiếu dữ liệu ở đâu. Nếu các khoảng trống này được khắc phục, năng lực phòng thủ sẽ tăng lên rõ rệt.

Chỉ số thứ tư là mức độ bao phủ ATT&CK. Tổ chức có thể dùng MITRE ATT&CK để đánh giá những tactic và technique nào đã có detection, technique nào chỉ có log nhưng chưa có rule, technique nào chưa có telemetry. Đây là cách liên kết Threat Hunting với quản trị năng lực phát hiện.

Chỉ số thứ năm là thời gian chuyển hóa kết quả hunt thành detection. Nếu một phát hiện tốt mất nhiều tháng để đưa vào SIEM hoặc EDR, tổ chức đang có vấn đề về detection engineering. Chỉ số này giúp đo tốc độ học tập của hệ thống phòng thủ.

Chỉ số thứ sáu là tỷ lệ false positive sau khi rule được triển khai. Threat Hunting không chỉ tạo thêm alert. Nó phải tạo alert có chất lượng. Nếu rule mới tạo quá nhiều nhiễu, cần quay lại chỉnh logic, bổ sung điều kiện ngữ cảnh hoặc cải thiện baseline.

9. Tổ chức đội ngũ và quy trình vận hành Threat Hunting

Threat Hunting cần được đặt trong cơ cấu vận hành rõ ràng. Nếu chỉ giao cho một vài cá nhân tự làm khi có thời gian rảnh, chương trình sẽ khó bền vững.

Trong mô hình nhỏ, một SOC Analyst cấp cao có thể kiêm nhiệm hunting theo lịch định kỳ. Mỗi tuần hoặc mỗi tháng, nhóm chọn một giả thuyết có mức ưu tiên cao để kiểm tra. Kết quả được ghi thành hunt report và rule cải tiến.

Trong mô hình trưởng thành hơn, tổ chức nên có vai trò Threat Hunter, Detection Engineer, Threat Intelligence Analyst, SOC Analyst và IR Analyst phối hợp với nhau. Threat Intelligence cung cấp bối cảnh về đối thủ. Hunter kiểm chứng giả thuyết bằng dữ liệu. Detection Engineer chuyển logic thành rule vận hành. SOC dùng rule để giám sát. IR xử lý khi có dấu hiệu xâm phạm.

Threat Hunting cũng cần có nhịp vận hành. Tổ chức nên có hypothesis backlog, lịch hunt định kỳ, buổi review kết quả, quy trình chuyển giao sang SOC hoặc IR và cơ chế cập nhật ATT&CK coverage. Với các hunt lặp lại, nên tự động hóa bằng notebook, scheduled query hoặc dashboard.

Một quy trình thực tế có thể đi theo chuỗi sau. Thu thập ý tưởng hunt từ Threat Intelligence, SOC, IR, Red Team và thay đổi hệ thống. Đánh giá mức ưu tiên theo rủi ro. Viết hunt plan. Kiểm tra dữ liệu. Thực hiện điều tra. Kết luận. Chuyển kết quả thành detection, playbook hoặc telemetry request. Cập nhật backlog và coverage.

10. Sai lầm phổ biến khi triển khai Threat Hunting

Sai lầm đầu tiên là xem Threat Hunting như một tính năng của công cụ. SIEM, EDR hoặc XDR có thể hỗ trợ hunting, nhưng bản thân công cụ không tạo ra Threat Hunting. Threat Hunting cần giả thuyết, dữ liệu, con người, phương pháp và quy trình học lại từ kết quả.

Sai lầm thứ hai là chỉ săn IoC. IP, domain và hash có giá trị, nhưng dễ thay đổi. Nếu tổ chức chỉ săn IoC, đối thủ chỉ cần thay hạ tầng là có thể né tránh. Threat Hunting nên ưu tiên hành vi và TTP vì chúng khó thay đổi hơn.

Sai lầm thứ ba là không ghi chép quá trình điều tra. Nếu Hunter không lưu lại truy vấn, phạm vi dữ liệu, cách lọc nhiễu và lý do kết luận, kết quả hunt sẽ khó kiểm tra và khó tái sử dụng.

Sai lầm thứ tư là không chuyển kết quả thành detection. Nếu hunt phát hiện một hành vi đáng chú ý nhưng không tạo rule, không cập nhật playbook và không bổ sung dashboard, tổ chức sẽ phải điều tra lại từ đầu khi hành vi đó xuất hiện lần sau.

Sai lầm thứ năm là thiếu bối cảnh tài sản. Không hiểu hệ thống nào quan trọng, tài khoản nào hợp lệ, dịch vụ nào chạy định kỳ và luồng dữ liệu nào bình thường sẽ làm Hunter bị ngập trong false positive.

Sai lầm thứ sáu là dùng AI thiếu kiểm soát. AI có thể hỗ trợ sinh giả thuyết, tóm tắt log và gợi ý pivot. Tuy nhiên, nếu Hunter tin kết quả AI mà không kiểm tra log gốc, kết luận có thể sai. Nếu AI agent được cấp quyền quá rộng, nó có thể tạo thêm rủi ro về dữ liệu và hành động tự động.

11. Lộ trình triển khai Threat Hunting cho tổ chức

Tổ chức mới bắt đầu không nên triển khai Threat Hunting theo hướng quá phức tạp. Nên bắt đầu từ dữ liệu, use case và quy trình nhỏ.

Giai đoạn đầu là kiểm kê dữ liệu. Tổ chức cần biết mình đang có log gì, lưu bao lâu, bao phủ hệ thống nào và thiếu trường dữ liệu nào. Kết quả của giai đoạn này là bản đồ telemetry.

Giai đoạn hai là chọn use case cơ bản. Nên bắt đầu với các hunt có giá trị cao và dữ liệu dễ có, ví dụ persistence, lateral movement, credential access, C2 beaconing và exfiltration.

Giai đoạn ba là xây dựng hunt template. Mỗi hunt cần có mục tiêu, giả thuyết, phạm vi, dữ liệu, truy vấn, kết quả, kết luận và hành động tiếp theo. Template giúp chuẩn hóa chất lượng và dễ đào tạo người mới.

Giai đoạn bốn là chuyển kết quả sang detection engineering. Mỗi hunt có giá trị phải tạo ra rule, dashboard, playbook hoặc telemetry request. Đây là bước biến hunting thành năng lực phòng thủ bền vững.

Giai đoạn năm là đo lường và cải tiến. Tổ chức cần theo dõi số hunt đã thực hiện, số detection mới, số gap dữ liệu đã khắc phục, mức độ bao phủ ATT&CK và chất lượng alert sau khi triển khai rule.

Giai đoạn sáu là đưa AI vào hỗ trợ có kiểm soát. AI nên được dùng để tóm tắt Threat Intelligence, hỗ trợ viết truy vấn, gợi ý pivot, phân tích chuỗi sự kiện và viết báo cáo. Tổ chức cần quy định rõ dữ liệu nào được đưa vào AI, ai kiểm chứng kết quả, và AI có được phép thực thi hành động hay không.