Security teams utilizing Microsoft Defender XDR’s DeviceNetworkEvents table for threat detection may be inadvertently overlooking critical external network connections due to an underrecognized IP address classification issue. This concern revolves around the FourToSixMapping value in the RemoteIPType field, which can cause public IP traffic to evade detection filters that exclusively target entries labeled as Public.
During a Purple Team exercise, a scenario was simulated where an attacker deployed a binary to establish a covert command-and-control (C2) channel, effectively bypassing web proxy controls. Despite having a detection mechanism in place for this specific attack vector, the alert failed to trigger. The investigation pinpointed the root cause to a query constraint that filtered events based solely on RemoteIPType == "Public". This filter inadvertently excluded valid public IP connections logged under the FourToSixMapping classification.
Understanding the ‘FourToSixMapping’ Classification
Modern Windows applications often employ dual-stack sockets, enabling simultaneous communication over both IPv4 and IPv6 protocols. When an application communicates over IPv4 through an IPv6-capable socket, Defender XDR logs the address as an IPv4-mapped IPv6 address, formatted as ::ffff:8.8.8.8. This notation is defined in RFC 4291, the IPv6 addressing standard. Consequently, Defender XDR assigns these events the FourToSixMapping label instead of Public, even though the underlying address is a legitimate public IP.
Analysts frequently categorize network detections by protocol or service (e.g., SSH, RDP, HTTPS, DNS) to streamline baselining and expedite triage processes. However, queries that filter exclusively for RemoteIPType == "Public" will systematically miss any connections logged as FourToSixMapping, resulting in false negatives where real attacks occur, but the detection mechanisms fail to trigger alerts.
Mitigation Strategies
To address this blind spot, it is recommended to normalize the IP addresses by stripping the ::ffff: prefix from FourToSixMapping addresses before evaluation. This can be achieved using the following query:
| extend RemoteIP =
iff(RemoteIPType == "FourToSixMapping",
replace_string(RemoteIP, "::ffff:", ""),
RemoteIP)
This approach converts the address into a standard IPv4 format, allowing for accurate filtering and analysis. Additionally, security teams should audit their environments to identify any missed events by comparing RemoteIP values across both Public and FourToSixMapping types over a historical period. This process can flag IPs that have only appeared under the FourToSixMapping classification without corresponding Public entries.
In summary, relying solely on RemoteIPType == "Public" for filtering public external communications can lead to the exclusion of significant subsets of legitimate public traffic, including potential attack-related activities. Security teams are advised to treat both Public and FourToSixMapping classifications as valid indicators of external communication and to normalize IP formats prior to applying detection logic. This proactive approach ensures a more comprehensive and accurate threat detection framework.
This issue underscores the importance of continuous refinement in detection engineering practices. Even with advanced tools and AI-assisted query suggestions, nuanced technical details can create blind spots that adversaries may exploit. Regular audits and updates to detection logic are essential to maintain robust security postures.
