Security researcher Alex Teixeira disclosed on July 20, 2026, that Microsoft Defender XDR and Microsoft Sentinel can log outbound connections to public internet destinations under a value that many detection queries never check.
Quick Summary – TLDR:
- Alex Teixeira’s Detect FYI report found that, per Microsoft’s own documentation, Defender XDR and Sentinel can tag public IPv4 connections as `FourToSixMapping` instead of `Public` in the `DeviceNetworkEvents` table.
- Queries that filter only on `RemoteIPType == “Public”` silently miss those events, producing a false negative where a detection exists but the alert never fires.
- The gap surfaced, per Teixeira’s account, during a purple-team exercise simulating a covert command-and-control channel that evaded a detection built for that exact attack stage.
- KQL’s own `ipv4_is_private()` function returns null for a `FourToSixMapping` value, so queries that lean on it drop the same events a separate way.
- Two security outlets, per GBHackers and Cyber Security News, independently corroborated the finding on July 21, 2026.
What Happened?
The issue turned up, according to Teixeira, during a Purple Team exercise where part of the simulation involved an attacker deploying a binary that establishes a covert command-and-control channel to bypass web proxy controls. Teixeira had built a detection for that stage of the attack chain, but despite having a detection built for this exact attack stage, the alert never fired.
The root cause, per Detect FYI’s account, traced back to a single line. The query contained a constraint filtering out any RemoteIPType values other than “Public“, even though the connection went to a genuine public IP address. This oversight creates a significant coverage gap for detections monitoring outbound communications, especially in environments where dual stack networking is prevalent.
That value, FourToSixMapping, is not some obscure edge case. It is documented behavior, per Microsoft’s own reference materials, and its address format follows the public IPv6 addressing specification, per the IETF’s governing standard.
RemoteIPType == “Public” was the exact constraint at fault, Teixeira’s report notes, and otherwise you’re going to automatically filter out those important events once dual stack traffic enters the picture.
Security teams using Microsoft Defender XDR may overlook critical external connections due to the ‘FourToSixMapping’ classification, which can cause public IP traffic to evade detection filters targeting ‘Public’ entries. This blind spot underscores the need for refined detection… pic.twitter.com/WEF7c0anoR
— The Daily Tech Feed (@dailytechonx) July 21, 2026
Why Defender Logs “FourToSixMapping” Instead of “Public”?
The behavior is not a bug. FourToSixMapping is a value defenders may encounter in Microsoft Defender XDR’s DeviceNetworkEvents.RemoteIPType field that indicates the IP address is an IPv4-mapped IPv6 address. Modern Windows applications routinely open dual-stack sockets that carry either protocol.
When one of those sockets talks IPv4 over an IPv6-capable channel, Defender logs the destination as an embedded address such as `::ffff:8.8.8.8`.
That format traces to an internet standard, not a Microsoft quirk. RFC 4291 Section 2.5.5.2 defines the IPv4-mapped IPv6 address format used to represent IPv4 nodes as IPv6 addresses. Microsoft’s own schema reference backs this up directly: Microsoft documents RemoteIPType as a string field whose values include Public, Private, Reserved, Loopback, Teredo, FourToSixMapping, and Broadcast.
FourToSixMapping sits on that documented list as a fully supported type. The failure mode is a detection query that checks one value on the list and silently ignores the rest. Defender XDR sits inside a stack many enterprises run alongside Microsoft 365 adoption, which is part of why a quiet gap in its flagship hunting table carries weight beyond any single tenant.
| `RemoteIPType` value | What it represents | Caught by `== “Public”` filter? |
|---|---|---|
| `Public` | Plain IPv4 or IPv6 public address | Yes |
| `FourToSixMapping` | IPv4 address embedded in an IPv6-mapped format (`::ffff:x.x.x.x`) | No, silently dropped |
The Query Trap: Even the “Safe” Fix Can Miss It
A defender who spots the gap and reaches for KQL’s built-in privacy check runs into another trap. The ipv4_is_private function evaluates to null when used with FourToSixMapping values. Standard functions like ipv4_is_private() don’t handle IPv4-mapped IPv6 addresses correctly out of the box.
In KQL, null is neither true nor false. A filter written as “not private” quietly excludes those rows instead of including them. That produces another, distinct false negative layered onto the original one.
The recommended fix treats both RemoteIPType values as external and normalizes the address by stripping the “::ffff:” prefix before applying public/private logic. That normalization step is the difference between a detection that looks correct in a query editor and one that actually fires during a real intrusion.
Detection engineers should review existing Microsoft Defender XDR and Microsoft Sentinel queries that filter by RemoteIPType == “Public,” particularly for rules concerning C2, suspicious outbound HTTPS, unusual DNS activity, remote access tools, and proxy bypass techniques.
SQ Magazine’s Takeaway
This reads as a detection-authorship problem, not a product flaw. Microsoft’s logging matches the IPv6 standard, and Defender documents FourToSixMapping openly in its own schema reference. One comparison operator, checked against one of seven documented values, quietly decides whether a real external connection ever reaches an analyst’s screen.
There’s a compounding twist. KQL’s own privacy check function returns neither true nor false for the same edge case, so a defender can patch the obvious filter and still leave the query broken by leaning on that function without normalizing the address first.
What’s next for affected teams is a direct audit, not a wait and see approach. Security teams running Defender XDR or Sentinel should pull every saved query referencing `RemoteIPType`, add `FourToSixMapping` alongside `Public`, and strip the `::ffff:` prefix before any private-range check.
That’s the exact normalization Teixeira published. A handful of rewritten saved queries, arriving inside the same 2026 disclosure window, closes a gap that otherwise depends on an attacker’s socket configuration rather than a defender’s intent.
