Microsoft Defender XDR Blind Spot Hides Public Connections
A quirk in Microsoft Defender XDR's DeviceNetworkEvents table can cause legitimate public IP connections, including command-and-control channels, to go undetected.
Security teams utilizing Microsoft Defender XDR for threat hunting and detection may be overlooking critical external network connections due to an overlooked classification quirk within its DeviceNetworkEvents table. The issue stems from the 'FourToSixMapping' RemoteIPType value, which can cause traffic originating from public IP addresses to bypass detection filters that are narrowly focused on RemoteIPType set strictly to 'Public'.
This blind spot was brought to light during a Purple Team exercise where a simulated attacker deployed a binary to establish a covert command-and-control (C2) channel, successfully evading web proxy controls. Despite the presence of a detection rule designed for this specific attack phase, no alert was triggered. The investigation traced the failure back to a simple query constraint: where RemoteIPType == "Public". This filter inadvertently excluded valid public IP connections that were logged under the 'FourToSixMapping' RemoteIPType, creating a significant false-negative scenario.
Modern applications frequently employ dual-stack sockets, enabling simultaneous communication over both IPv4 and IPv6. When an application uses IPv4 through an IPv6-enabled socket, Microsoft Defender XDR logs this as an IPv4-mapped IPv6 address, typically appearing in the format ::ffff:8.8.8.8. As defined in RFC 4291, this format represents a legitimate public IP address but is classified by Defender XDR as 'FourToSixMapping' instead of 'Public'.
Security analysts often segment network detections by protocol or service (e.g., SSH, RDP, HTTPS, DNS) to streamline baselining and expedite triage. However, queries that exclusively filter for RemoteIPType == "Public" will systematically miss any connection logged as 'FourToSixMapping'. This creates a dangerous blind spot where real attacks can occur, detections exist, but no alerts are generated.
Even Microsoft's own Kusto Query Language (KQL) function, ipv4_is_private(), does not fully resolve this issue. When tested against a 'FourToSixMapping' value like ::ffff:8.8.8.8, it returns null rather than a definitive true or false. In KQL, null values are treated as neither, meaning queries relying on this function without proper normalization will silently drop these events.
The recommended solution involves normalizing the IP addresses by removing the ::ffff: prefix before applying filters. This can be achieved with a query modification such as: extend RemoteIP = iff(RemoteIPType == "FourToSixMapping", replace_string(RemoteIP, "::ffff:", ""), RemoteIP). This normalization converts the address into a standard IPv4 format, enabling accurate downstream filtering and analysis.
To audit their own environments for potentially missed events, security teams can employ a validation query. This query can compare 'RemoteIP' values across both 'Public' and 'FourToSixMapping' types over a historical period, flagging IPs that exclusively appeared as 'FourToSixMapping' without a corresponding 'Public' entry.
This vulnerability underscores a crucial lesson in detection engineering: relying solely on RemoteIPType == "Public" for filtering external communications is insufficient and risks missing a significant subset of legitimate public traffic, including that associated with active attacks. Security teams must treat both 'Public' and 'FourToSixMapping' as valid indicators of external communication and normalize IP formats before implementing detection logic. Furthermore, it highlights the necessity of manual validation for detection logic against edge cases, as even AI-assisted suggestions may overlook such nuances.