Điều tra alert password spray với Attack Story & AIR (TWL300 Lab 03, Phần 5/8)

Đây là bài thực chiến đầu tiên của chuỗi: điều tra alert một cuộc tấn công password spray mức trung bình trong Microsoft Defender XDR. Trong Lab 03 của loạt Microsoft Defender XDR (TWL300), bạn sẽ đi trọn vòng đời xử lý: tạo dữ liệu mẫu, dựng custom detection rule, phân tích incident bằng Attack Story, kiểm chứng bằng Advanced Hunting (KQL) và ngăn chặn bằng Automated Investigation & Response (AIR).
Bối cảnh: password spray là gì?
Password spray là kỹ thuật thử một vài mật khẩu phổ biến trên nhiều tài khoản, thay vì dồn nhiều mật khẩu vào một tài khoản (vốn dễ bị khóa). Trong lab, kẻ tấn công từ IP 198.51.100.23 nhắm vào nhiều người dùng với hàng loạt lần đăng nhập thất bại trong một khung giờ — một mẫu hành vi điển hình thuộc nhóm Credential access của MITRE ATT&CK.
Bước 1 — Nạp dữ liệu mẫu và tạo custom detection rule
Trước tiên, nạp dữ liệu hoạt động mẫu (seeded data) để mô phỏng tín hiệu đăng nhập. Sau đó, vào Investigation & response → Hunting → Advanced hunting, dán truy vấn KQL phát hiện spray rồi chọn Create detection rule. Quy tắc này sẽ tự động sinh alert và gom thành incident “LAB – Password spray involving multiple users” mỗi khi mẫu tấn công tái diễn — đây chính là lý do ở Lab 00 chúng ta đã chuẩn bị quyền Custom Detection Rule Creator.
Đặt mức nghiêm trọng, ánh xạ thực thể (tài khoản, IP) và lịch chạy cho rule. Khi rule kích hoạt, một incident mức Medium thuộc danh mục Credential access sẽ xuất hiện trong hàng đợi.

Bước 2 — Phân tích incident với Attack Story
Mở Investigation & response → Incidents & alerts → Incidents, chọn incident password spray rồi vào tab Attack Story. Đây là nơi Defender XDR tự động ghép các alert rời rạc thành một câu chuyện tấn công trực quan:
- Incident graph hiển thị IP nguồn ở trung tâm, tỏa ra các tài khoản và hộp thư bị nhắm tới — chọn node IP để xem IP details.
- Khung Alerts liệt kê từng lần spray theo dòng thời gian; nút Play attack story tái hiện diễn tiến tấn công.
- Khung Incident details tóm tắt phân loại, thời điểm hoạt động đầu/cuối và mô tả (IP, số tài khoản, số lần đăng nhập thất bại).

Cuộn xuống danh sách hộp thư bị ảnh hưởng, chọn một người dùng (ví dụ Alex Wilber) để xem chi tiết các alert liên quan và phạm vi tác động.
Khi triage, hãy chú ý các tín hiệu giúp bạn phân biệt tấn công thật với báo động giả: số lượng tài khoản bị nhắm tới (spray thường nhắm hàng loạt), mật độ thời gian (nhiều lần thử trong cửa sổ ngắn), nguồn IP lạ/đến từ vùng địa lý bất thường, và đặc biệt là có lần đăng nhập nào thành công xen giữa chuỗi thất bại hay không. Việc nắm rõ “câu chuyện” trước khi hành động giúp bạn ngăn chặn đúng phạm vi mà không làm gián đoạn người dùng hợp lệ.
Bước 3 — Kiểm chứng bằng Advanced Hunting
Đừng chỉ tin vào alert — hãy xác nhận phạm vi bằng Advanced Hunting. Chạy truy vấn KQL trên IdentityLogonEvents và AADSignInEventsBeta để đếm số lần đăng nhập thất bại theo tài khoản và theo IP nguồn. Mục tiêu là trả lời ba câu hỏi: có bao nhiêu tài khoản bị nhắm tới, mẫu thời gian ra sao, và có tài khoản nào đăng nhập thành công sau chuỗi thất bại hay không — dấu hiệu của một tài khoản có thể đã bị xâm phạm.
Bước 4 — Ngăn chặn bằng AIR và đóng incident
Khi đã khoanh vùng, tiến hành containment. Trong Incident Details, chọn người dùng bị ảnh hưởng và dùng Revoke all users’ sessions để vô hiệu hóa token đang hoạt động, buộc đăng nhập lại kèm MFA. Tận dụng Automated Investigation & Response (AIR) để Defender tự điều tra và đề xuất/thực thi các hành động khắc phục.
Xác minh kết quả tại Investigation & response → Actions & submissions → Action center → History: bạn sẽ thấy các bước remediation đã thực hiện (revoke session, yêu cầu reset mật khẩu/MFA). Khi đã chắc chắn mối đe dọa được kiểm soát, đặt phân loại (True positive), ghi chú kết luận và đóng incident.
Bài học rút ra
- Custom detection rule biến tri thức săn tìm (KQL) thành phát hiện tự động, lặp lại được.
- Attack Story rút ngắn thời gian hiểu một incident từ hàng chục alert rời rạc.
- Luôn kiểm chứng bằng Advanced Hunting trước khi ra quyết định ngăn chặn.
- Revoke session + MFA là hành động containment nhanh và hiệu quả cho tấn công danh tính.
Kết luận
Qua Lab 03, bạn đã điều tra alert password spray trọn vẹn: từ phát hiện, phân tích Attack Story, kiểm chứng KQL đến ngăn chặn bằng AIR. Ở phần tiếp theo, chúng ta sẽ xử lý một vấn đề vận hành thường gặp khác — khắc phục sự cố thu thập dữ liệu (data ingestion) để bảo đảm XDR không bị “mù”. Theo dõi trọn bộ chuỗi tại Office365Vietnam.info.
📚 Chuỗi bài Microsoft Defender XDR (TWL300) — Phần 5/8
⬅️ Bài trước: Lab 02 – Cấu hình Defender XDR theo best practices
➡️ Bài tiếp theo: Lab 04 – Khắc phục sự cố data ingestion trong XDR (đăng Thứ 5, 09/07).
