Microsoft Defender XDR Blind Spot Can Hide Public Connections Behind FourToSixMapping

Security teams relying on Microsoft Defender XDR’s DeviceNetworkEvents table for hunting and detection may be missing critical external network connections due to a lesser-known IP address classification quirk.

The issue centers on FourToSixMapping, a RemoteIPType value that can cause public IP traffic to slip past detection logic that filters strictly on RemoteIPType == "Public".

According to Detect FYI, the blind spot surfaced during a Purple Team exercise simulating an attacker deploying a binary to establish a covert command-and-control (C2) channel bypassing web proxy controls. Despite having a detection built for this exact attack stage, the alert never fired.

The root cause traced back to a single query constraint:

text| where RemoteIPType == "Public"

This filter silently excluded valid public IP connections logged under a different RemoteIPType value: FourToSixMapping.

Microsoft Defender XDR Blind Spot

Modern Windows applications frequently use dual-stack sockets, allowing simultaneous communication over IPv4 and IPv6. When an application communicates over IPv4 through an IPv6-capable socket, Defender XDR logs the address as an IPv4-mapped IPv6 address, formatted like ::ffff:8.8.8.8.

This format is defined in RFC 4291, the IPv6 addressing standard. Defender XDR tags these events as FourToSixMapping rather than Public, even though the underlying address is a legitimate public IP.

Analysts often split network detections by protocol or service (SSH, RDP, HTTPS, DNS) to simplify baselining and speed up triage. But queries filtering only for RemoteIPType == "Public" will systematically miss any connection logged as FourToSixMapping, creating a false-negative (FN): a real attack occurs, a detection exists, but the alert never triggers.

Even KQL’s built-in ipv4_is_private() function doesn’t solve this cleanly. Testing it against a FourToSixMapping value like ::ffff:8.8.8.8 returns null rather than true or false, and in KQL, null is neither. Queries relying on this function without normalization will silently drop these events too.

The recommended fix is to strip the ::ffff: prefix from FourToSixMapping addresses before evaluating them:

text| extend RemoteIP =
    iff(RemoteIPType == "FourToSixMapping",
        replace_string(RemoteIP, "::ffff:", ""),
        RemoteIP)

This normalizes the address into standard IPv4 format, allowing accurate downstream filtering and analysis.

To audit your own tenant for missed events, a validation query can compare RemoteIP values across both Public and FourToSixMapping types over a historical window, flagging IPs that only ever appeared as FourToSixMapping without a corresponding Public entry, as Detect FYI said in a report shared with CybersecurityNews.

Takeaway for Defenders

Never filter public external communications solely on RemoteIPType == "Public". Doing so risks silently excluding a meaningful subset of legitimate public traffic, including traffic tied to real attacks.

Instead, treat Public and FourToSixMapping as equally valid indicators of external communication, and normalize IP formats before applying detection logic.

This gap also highlights a broader lesson in detection engineering: even AI-assisted KQL suggestions can miss this nuance, since standard functions like ipv4_is_private() don’t handle IPv4-mapped IPv6 addresses correctly out of the box. Manual validation of detection logic against edge cases remains essential.

The Privilege Paths Attackers See That You Don’t: BeyondTrust Pathfinder Platform Does It for You -> Get Free Identity Security Assessment