Các nhóm bảo mật dựa vào bảng DeviceNetworkEvents của Microsoft Defender XDR để săn tìm và phát hiện các hoạt động bất thường có thể bỏ lỡ các kết nối mạng bên ngoài quan trọng. Nguyên nhân chính là do một đặc điểm phân loại địa chỉ IP ít được biết đến. Đây là một rủi ro bảo mật tiềm tàng cần được khắc phục.
Vấn đề này tập trung vào giá trị RemoteIPType mang tên FourToSixMapping. Giá trị này có thể khiến lưu lượng IP công cộng hợp lệ vượt qua logic phát hiện được thiết lập để lọc nghiêm ngặt chỉ dựa trên RemoteIPType == "Public", dẫn đến điểm mù nghiêm trọng trong hệ thống.
Hiểu rõ về FourToSixMapping trong Defender XDR
Theo Detect FYI, điểm mù này được phát hiện trong một bài tập Purple Team. Bài tập này mô phỏng một kẻ tấn công triển khai một binary để thiết lập một kênh C2 (command-and-control) bí mật, nhằm vượt qua các kiểm soát proxy web. Mặc dù có một cơ chế phát hiện được xây dựng cho giai đoạn tấn công chính xác này, cảnh báo đã không bao giờ được kích hoạt.
Nguyên nhân sâu xa được truy ngược về một ràng buộc truy vấn duy nhất. Ràng buộc này đã âm thầm loại trừ các kết nối IP công cộng hợp lệ được ghi lại dưới một giá trị RemoteIPType khác: FourToSixMapping.
Cơ chế ánh xạ IPv4 sang IPv6
Các ứng dụng Windows hiện đại thường sử dụng các socket dual-stack. Chúng cho phép giao tiếp đồng thời qua cả IPv4 và IPv6. Khi một ứng dụng giao tiếp qua IPv4 thông qua một socket có khả năng IPv6, Defender XDR sẽ ghi lại địa chỉ dưới dạng địa chỉ IPv6 được ánh xạ IPv4.
Địa chỉ này có định dạng ví dụ như ::ffff:8.8.8.8. Định dạng này được định nghĩa trong RFC 4291, tiêu chuẩn địa chỉ IPv6. Defender XDR gắn thẻ các sự kiện này là FourToSixMapping thay vì Public, mặc dù địa chỉ cơ bản là một IP công cộng hợp lệ.
Tác động đến quy trình phát hiện xâm nhập
Các nhà phân tích thường chia nhỏ các quy tắc phát hiện mạng theo giao thức hoặc dịch vụ (SSH, RDP, HTTPS, DNS). Mục đích là để đơn giản hóa việc thiết lập baseline và tăng tốc độ xử lý. Tuy nhiên, các truy vấn chỉ lọc cho RemoteIPType == "Public" sẽ bỏ sót một cách có hệ thống bất kỳ kết nối nào được ghi lại là FourToSixMapping. Điều này tạo ra một trường hợp False-Negative (FN): một cuộc tấn công thực sự xảy ra, một cơ chế phát hiện tồn tại, nhưng cảnh báo không bao giờ được kích hoạt.
Tình trạng này làm tăng đáng kể rủi ro bảo mật cho hệ thống. Nó tạo ra một điểm mù mà qua đó các hoạt động độc hại, như thiết lập kênh C2, có thể diễn ra mà không bị phát hiện. Khả năng phát hiện xâm nhập bị suy giảm nghiêm trọng.
Ngay cả hàm KQL tích hợp ipv4_is_private() cũng không giải quyết vấn đề này một cách triệt để. Khi kiểm tra hàm này với một giá trị FourToSixMapping như ::ffff:8.8.8.8, nó trả về null chứ không phải true hay false. Trong KQL, null không phải là cả hai. Các truy vấn dựa vào hàm này mà không có bước chuẩn hóa sẽ âm thầm bỏ qua các sự kiện quan trọng này.
Khuyến nghị khắc phục và chuẩn hóa dữ liệu
Để khắc phục vấn đề này, giải pháp được khuyến nghị là loại bỏ tiền tố ::ffff: khỏi các địa chỉ FourToSixMapping trước khi đánh giá chúng. Điều này đảm bảo rằng địa chỉ IP được chuẩn hóa về định dạng IPv4 tiêu chuẩn, cho phép lọc và phân tích chính xác hơn. Việc chuẩn hóa dữ liệu là bước thiết yếu để đảm bảo an ninh mạng.
Ví dụ KQL để chuẩn hóa địa chỉ IP
DeviceNetworkEvents
| extend NormalizedRemoteIP = iff(RemoteIPType == "FourToSixMapping", replace(@"::ffff:", "", RemoteIP), RemoteIP)
| where isnotempty(NormalizedRemoteIP) // Đảm bảo địa chỉ đã chuẩn hóa không rỗng
| where ipv4_is_private(NormalizedRemoteIP) == false // Áp dụng logic lọc sau khi chuẩn hóa
// Các điều kiện phát hiện khác của bạn
Việc áp dụng bước chuẩn hóa này trong các truy vấn KQL của bạn sẽ giúp hệ thống phát hiện xâm nhập hiệu quả hơn. Nó sẽ ngăn chặn các kết nối IP công cộng bị bỏ sót do cơ chế ánh xạ đặc biệt của Defender XDR, từ đó giảm thiểu rủi ro bảo mật.
Kiểm tra và xác thực các sự kiện bị bỏ sót
Để kiểm tra môi trường của bạn có bị bỏ sót sự kiện hay không, bạn có thể sử dụng một truy vấn xác thực. Truy vấn này so sánh các giá trị RemoteIP giữa cả hai loại Public và FourToSixMapping trong một khoảng thời gian lịch sử nhất định.
Truy vấn sẽ đánh dấu các địa chỉ IP chỉ xuất hiện dưới dạng FourToSixMapping mà không có mục nhập Public tương ứng. Điều này được đề cập trong báo cáo từ Detect FYI. Thực hiện kiểm tra này là một phần quan trọng trong việc duy trì một chiến lược an ninh mạng mạnh mẽ.
Bài học trong kỹ thuật phát hiện
Không bao giờ lọc các giao tiếp công cộng bên ngoài chỉ dựa trên điều kiện RemoteIPType == "Public". Làm như vậy có nguy cơ âm thầm loại trừ một tập hợp đáng kể các lưu lượng công cộng hợp lệ, bao gồm cả lưu lượng liên quan đến các cuộc tấn công thực sự. Đây là một rủi ro bảo mật lớn mà các tổ chức cần tránh.
Thay vào đó, hãy coi Public và FourToSixMapping là các chỉ số hợp lệ ngang nhau của giao tiếp bên ngoài. Luôn chuẩn hóa định dạng IP trước khi áp dụng logic phát hiện xâm nhập. Phương pháp này giúp đảm bảo sự toàn diện của các quy tắc phát hiện và tăng cường khả năng bảo vệ.
Điểm mù này cũng làm nổi bật một bài học rộng hơn trong kỹ thuật phát hiện. Ngay cả các gợi ý KQL được hỗ trợ bởi AI cũng có thể bỏ lỡ sắc thái này, vì các hàm tiêu chuẩn như ipv4_is_private() không xử lý các địa chỉ IPv6 được ánh xạ IPv4 một cách chính xác ngay từ đầu. Việc xác thực thủ công logic phát hiện chống lại các trường hợp biên vẫn là điều cần thiết để duy trì an ninh mạng hiệu quả và giảm thiểu mọi rủi ro bảo mật tiềm ẩn.
