Microsoft Defender XDR users may inadvertently overlook command-and-control (C2) traffic when searching for Internet-bound connections due to a specific behavior in how IP addresses are classified.
This issue arises from Kusto Query Language (KQL) detections that depend solely on filtering by RemoteIPType == “Public” in the DeviceNetworkEvents table. As a result, traffic destined for public IP addresses might be excluded from investigations and alert logic.
Microsoft Defender XDR Blind Spot
The DeviceNetworkEvents table is a crucial telemetry source within Microsoft Defender XDR because it connects network activity with endpoint context, such as processes, command lines, user accounts, ports, URLs, and protocol information, as reported by Detect FYI.
Security teams frequently use this table to identify suspicious HTTPS, DNS, remote management, and other outbound communications. However, using overly restrictive filters can lead to false negatives, especially when adversaries establish covert C2 channels that blend in with normal network activity.
The issue arises from the FourToSixMapping value found in the RemoteIPType field. Modern Windows applications can create dual-stack sockets that support both IPv4 and IPv6 communications.
When an IPv4 address is represented in IPv4-mapped IPv6 notation, Defender may record it as ::ffff:x.x.x.x and classify its type as FourToSixMapping instead of Public. For instance, a connection to the IP address 8.8.8.8 may appear as ::ffff:8.8.8.8. Consequently, a search limited to RemoteIPType == “Public” will fail to return the event.
This behavior was uncovered during a purple-team exercise when a covert external C2 channel did not trigger the expected alert. The underlying query filtered solely for the Public RemoteIPType, thereby unintentionally excluding traffic represented as IPv4-mapped IPv6.
This oversight creates a significant coverage gap for detections monitoring outbound communications, especially in environments where dual-stack networking is prevalent.
Defenders should also be cautious about relying solely on the ipv4_is_private() function to solve this problem. When given an IPv4-mapped IPv6 value like ::ffff:8.8.8.8, the KQL function may return null instead of a Boolean result.
Since null is neither true nor false in KQL filtering logic, queries assessing private-address status without first normalizing the IP address can silently omit mapped addresses.
Security teams should ensure they include both Public and FourToSixMapping values, normalizing the latter before applying checks for IPv4 addresses. The appropriate query would be:
| where RemoteIPType in ("Public", "FourToSixMapping")
| extend RemoteIP = iff(RemoteIPType == "FourToSixMapping", replace_string(RemoteIP, "::ffff:", ""), RemoteIP)After normalization, analysts can consistently exclude RFC 1918 private ranges, loopback addresses, and other non-Internet destinations.
Detection engineers should review existing Microsoft Defender XDR and Microsoft Sentinel queries that filter by RemoteIPType == “Public,” particularly for rules concerning C2, suspicious outbound HTTPS, unusual DNS activity, remote access tools, and proxy-bypass techniques.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
 traffic when searching for Internet-bound connections due to a specific behavior in how IP addresses are classified.){kind=link}