Microsoft Defender XDR Queries Can Miss Public Connections Logged as FourToSixMapping

Microsoft Defender XDR detection rules can miss public network connections when they filter the DeviceNetworkEvents table only for RemoteIPType == "Public". Some IPv4 connections made through IPv6-capable sockets appear under the separate FourToSixMapping classification.

The connection events remain available in Defender XDR. The gap occurs when hunting queries or custom detection rules exclude the additional address type, creating a false negative even though the relevant network telemetry was collected.

Security researcher Alex Teixeira documented the problem in a Detect FYI investigation after an expected alert failed during a purple-team exercise. The simulated attacker used a binary to establish a covert command-and-control channel that bypassed web proxy controls.

What Is FourToSixMapping in Microsoft Defender XDR?

FourToSixMapping describes an IPv4 address represented in IPv4-mapped IPv6 notation. A destination such as 8.8.8.8 may appear as ::ffff:8.8.8.8 when an application uses a dual-stack socket capable of handling IPv4 and IPv6 traffic.

The official Microsoft DeviceNetworkEvents schema lists Public, Private, Reserved, Loopback, Teredo, FourToSixMapping, and Broadcast as possible values for RemoteIPType. Microsoft’s documentation does not describe FourToSixMapping as a security alert or malicious classification.

The address structure comes from RFC 4291, which defines IPv4-mapped IPv6 addresses. The format reserves the first 80 bits as zero, follows them with 16 bits set to FFFF, and stores the IPv4 address in the final 32 bits.

Original IPv4 address	Mapped representation	Possible Defender type
8.8.8.8	::ffff:8.8.8.8	FourToSixMapping
192.168.1.25	::ffff:192.168.1.25	FourToSixMapping

The second example shows why analysts should not automatically classify every FourToSixMapping event as internet traffic. The mapped address can contain either a public or private IPv4 destination.

Why Defender XDR Detection Rules Can Miss the Traffic

A common hunting pattern selects external connections using a strict equality filter:

DeviceNetworkEvents
| where RemoteIPType == "Public"

This query returns only records explicitly classified as Public. It does not return events whose RemoteIPType is FourToSixMapping, even when the embedded IPv4 address belongs to a public destination.

The resulting coverage gap can affect detections for command-and-control traffic, suspicious HTTPS connections, remote administration tools, unusual DNS activity, data transfers, and attempts to bypass an organization’s web proxy.

Detection approach	Potential result
Filter only for RemoteIPType == "Public"	Mapped public IPv4 connections may be excluded
Include every FourToSixMapping event as public	Mapped private or loopback addresses may create noise
Normalize the embedded IPv4 address before classification	Public and private destinations can be evaluated consistently

KQL ipv4_is_private() Can Also Return Null

Replacing the RemoteIPType filter with ipv4_is_private() does not fully solve the problem unless the address is normalized first. The function expects an IPv4 string, while ::ffff:8.8.8.8 remains formatted as an IPv6 address.

The official Microsoft KQL documentation states that ipv4_is_private() returns null when it cannot parse the input as an IPv4 address. It returns true for an RFC 1918 private address and false for other successfully parsed IPv4 addresses.

A query using where not(ipv4_is_private(RemoteIP)) can therefore lose mapped events. When the function returns null, the expression does not produce the Boolean value needed for the row to pass the filter.

datatable(IPAddress:string)
[
    "192.168.0.1",
    "::ffff:8.8.8.8"
]
| extend IsPrivate = ipv4_is_private(IPAddress)

In this example, the private IPv4 address returns true. The mapped value can return null because it has not yet been converted into a standard dotted-decimal IPv4 string.

How to Normalize FourToSixMapping Addresses

Detection engineers can include Public and FourToSixMapping records, create a separate normalized field, and remove the ::ffff: prefix only when it appears at the beginning of a mapped address.

DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where RemoteIPType in ("Public", "FourToSixMapping")
| extend NormalizedRemoteIP =
    iff(
        RemoteIPType == "FourToSixMapping"
        and RemoteIP startswith "::ffff:",
        substring(RemoteIP, 7),
        RemoteIP
    )

Using a new field such as NormalizedRemoteIP preserves the original telemetry for investigation. It also prevents later analysts from confusing the normalized value with the address originally recorded by Defender XDR.

For mapped records, analysts can then evaluate the extracted IPv4 value against private, loopback, reserved, and organization-specific address ranges. Public records can continue through the rule without being passed to an IPv4-only function when they contain native IPv6 addresses.

DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where RemoteIPType in ("Public", "FourToSixMapping")
| extend NormalizedRemoteIP =
    iff(
        RemoteIPType == "FourToSixMapping"
        and RemoteIP startswith "::ffff:",
        substring(RemoteIP, 7),
        RemoteIP
    )
| where RemoteIPType == "Public"
    or (
        RemoteIPType == "FourToSixMapping"
        and ipv4_is_private(NormalizedRemoteIP) == false
        and ipv4_is_in_range(NormalizedRemoteIP, "127.0.0.0/8") == false
    )
| project Timestamp, DeviceName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, RemoteIP, NormalizedRemoteIP,
    RemotePort, RemoteUrl, Protocol

Organizations may need additional exclusions for link-local, documentation, carrier-grade NAT, multicast, benchmarking, or other special-use ranges. The correct definition of external traffic depends on the purpose of each detection.

How Security Teams Can Audit Existing Defender Rules

The original FourToSixMapping research recommends examining historical records that appeared only under the mapped classification. This can reveal destinations or processes excluded from existing alerts.

• Search custom detections and hunting queries for strict RemoteIPType == "Public" filters.
• Review rules that use ipv4_is_private(RemoteIP) without first normalizing mapped addresses.
• Compare Public and FourToSixMapping events across a representative historical period.
• Identify processes that communicate with public destinations only through mapped addresses.
• Retest command-and-control, proxy-bypass, DNS, HTTPS, SSH, RDP, and remote-tool detections.
• Preserve the original IP field alongside any normalized field.
• Monitor query changes for higher event volumes and false positives.

The DeviceNetworkEvents reference confirms that the table connects network information with endpoint details such as the initiating process, command line, account, port, protocol, and destination. This context can help analysts distinguish expected dual-stack activity from suspicious outbound communication.

Security teams should also review Microsoft Sentinel analytics rules that consume Defender XDR data. Any downstream query that assumes Public is the only internet-facing RemoteIPType can reproduce the same gap.

Is FourToSixMapping a Microsoft Defender Vulnerability?

No CVE or Microsoft security advisory has been published for this behavior. The available evidence describes a detection-engineering issue caused by how queries interpret documented telemetry categories, not an exploit that disables Defender XDR or removes network records.

The IPv6 addressing standard has defined IPv4-mapped IPv6 addresses for years. The security risk arises when monitoring logic does not account for this representation while trying to identify public IPv4 communication.

Microsoft’s ipv4_is_private() reference also documents that parsing failures return null. Detection authors should explicitly test null handling instead of assuming every input will produce true or false.

What Defender XDR Customers Should Do

Organizations should review network detections before treating this as evidence of an endpoint sensor failure. The priority is to find queries that discard FourToSixMapping records and correct their address-normalization logic.

1. Inventory Defender XDR and Sentinel queries that identify external connections.
2. Include FourToSixMapping records where they are relevant to the detection objective.
3. Extract and validate the embedded IPv4 address before testing whether it is private or public.
4. Handle null results from IP parsing functions explicitly.
5. Run revised queries against historical telemetry to identify previously missed activity.
6. Test updated rules with controlled IPv4, IPv6, and IPv4-mapped IPv6 connections.
7. Tune exclusions without removing visibility into unusual processes or destinations.

The issue illustrates how a valid telemetry field can still produce a detection gap when query logic is too narrow. Defender XDR users do not need to wait for a software patch to improve coverage. They can update and validate their hunting and alert rules now.

FAQ