Microsoft Defender XDR Blind Spot Lets Public C2 Traffic Evade Detection Queries

A newly disclosed detection gap in Microsoft Defender XDR could be causing security teams to silently miss command-and-control (C2) traffic and other malicious external communications, according to researcher Alex Teixeira.

The flaw centers on how Defender’s DeviceNetworkEvents table classifies IPv4-mapped IPv6 addresses, a common but overlooked artifact of dual-stack networking on Windows systems.

Many detection and hunting queries built on Defender’s DeviceNetworkEvents table filter external traffic using the constraint RemoteIPType == "Public" to isolate internet-bound connections.

Microsoft Defender XDR Blind Spot

Teixeira discovered this approach introduces a false-negative during a Purple Team exercise, when an alert designed to catch a C2 channel bypassing web proxy controls failed to fire despite the attack traffic being logged.

The root cause: modern Windows applications frequently create dual-stack sockets that communicate over both IPv4 and IPv6 simultaneously.

When this happens, Defender XDR doesn’t tag the connection’s RemoteIPType as “Public,” even though the destination IP is genuinely public. Instead, it classifies the record as FourToSixMapping, denoting an IPv4-mapped IPv6 address per RFC 4291 (formatted like ::ffff:8.8.8.8).

Any query or detection rule filtering strictly on RemoteIPType == "Public" silently excludes all FourToSixMapping records, creating a systemic blind spot for external communications, including potential C2 traffic.

Teixeira also tested how AI chatbots would approach writing a KQL query for detecting all public destination traffic. The suggested query relied on the built-in ipv4_is_private() function to exclude private IPs.

However, when applied to FourToSixMapping-formatted addresses (with the ::ffff: prefix), the function returns null rather than true or false.

Since KQL treats null as neither true nor false, these events get dropped from results, meaning even AI-generated queries reproduce the same detection gap.

Teixeira recommends two remediation steps for detection engineers:

• Normalize RemoteIP values before filtering by stripping the ::ffff: prefix from FourToSixMapping entries, converting them to standard IPv4 format.
• Avoid filtering solely on RemoteIPType == "Public"; instead, explicitly include "FourToSixMapping" in the in() clause.

He also published a diagnostic KQL query that cross-references RemoteIP values across both types within a given time window, flagging any FourToSixMapping-only entries lacking a corresponding Public record a practical way for defenders to audit their own tenants for missed events.

Any detection rule, baseline, or KQL query built around remote IP classification without accounting for FourToSixMapping risks missing C2 beaconing, data exfiltration, and other outbound attacker traffic precisely the kind of gap adversaries exploit to evade proxy and EDR visibility.

Prevent critical incidents and financial loss with stronger proactive defense. Integrate a live threat feed from 15K SOCs