Microsoft Defender XDR C2 Detection Gap

Security teams using Microsoft Defender XDR should be aware of a detection gap that can cause command-and-control (C2) traffic to be missed during threat hunting and investigations. The issue is related to how Microsoft Defender XDR classifies certain IP addresses in the DeviceNetworkEvents table.

Many Kusto Query Language (KQL) detection rules search only for connections where RemoteIPType is set to “Public”. However, some internet-bound connections are recorded differently, which means they may not appear in search results or trigger alerts. This creates a blind spot that attackers could exploit to hide malicious outbound communications.

Why Does This Happen?

The DeviceNetworkEvents table is one of the most important telemetry sources in Microsoft Defender XDR. It provides detailed information about endpoint network activity, including:

Processes initiating the connection
Command-line arguments
User accounts
Remote IP addresses
Ports
URLs
Protocol information

Security analysts frequently use this data to investigate suspicious HTTPS traffic, DNS requests, remote management tools, and potential command-and-control (C2) communications.

The issue occurs because of the RemoteIPType field. Modern Windows systems often use dual-stack networking, allowing applications to communicate using both IPv4 and IPv6.

When an IPv4 address is stored as an IPv4-mapped IPv6 address, Microsoft Defender XDR may classify it as FourToSixMapping instead of Public.

For example:

IPv4 address: 8.8.8.8
Recorded value: ::ffff:8.8.8.8
RemoteIPType: FourToSixMapping

If a detection rule only searches for:

| where RemoteIPType == "Public"

the connection to 8.8.8.8 will not appear in the results because it has been classified as FourToSixMapping instead of Public.

This behavior was discovered during a purple-team exercise after a covert external C2 channel failed to trigger the expected alert. The investigation revealed that the detection rule unintentionally ignored IPv4-mapped IPv6 traffic because it only filtered for Public IP types.

Impact on Detection

This classification behavior can create a significant detection gap, particularly in organizations that use dual-stack networking.

Detection rules designed to monitor:

Command-and-control (C2) traffic
Suspicious outbound HTTPS connections
Unusual DNS activity
Remote access tools
Proxy-bypass techniques

may fail to detect malicious activity if they rely only on RemoteIPType == “Public”.

Another important consideration is the ipv4_is_private() KQL function. Some analysts use this function to identify private IP addresses, but it does not always work correctly with IPv4-mapped IPv6 values.

For example, when the function receives an address such as:

::ffff:8.8.8.8

it may return null instead of true or false.

Since null is neither true nor false in KQL filtering logic, mapped IPv4 addresses can be silently excluded from search results if the IP address is not normalized first.

To avoid this issue, Microsoft recommends including both Public and FourToSixMapping values in detection queries and normalizing mapped IPv4 addresses before applying additional filters.

A recommended query is shown below:

| where RemoteIPType in ("Public", "FourToSixMapping")
| extend RemoteIP = iff(
    RemoteIPType == "FourToSixMapping",
    replace_string(RemoteIP, "::ffff:", ""),
    RemoteIP
)

After normalizing the IP address, analysts can consistently filter private RFC 1918 addresses, loopback addresses, and other non-internet destinations without accidentally excluding legitimate outbound traffic.

Security teams should review existing Microsoft Defender XDR and Microsoft Sentinel detection rules that rely on RemoteIPType == “Public”. Rules designed to detect C2 activity, suspicious outbound HTTPS traffic, unusual DNS requests, remote management tools, and proxy-bypass techniques should be updated to account for both Public and FourToSixMapping values.

By making these changes, organizations can improve detection coverage, reduce false negatives, and ensure that outbound communications are monitored more accurately across both IPv4 and IPv6 environments.