Los equipos de seguridad que utilizan la tabla DeviceNetworkEvents de Microsoft Defender XDR para la detección y búsqueda de amenazas podrían estar omitiendo conexiones externas críticas. Esto se debe a una peculiaridad en la clasificación de direcciones IP relacionada con el valor FourToSixMapping, el cual puede provocar que el tráfico de IPs públicas evite la lógica de detección que filtra estrictamente mediante el criterio RemoteIPType == "Public".

Los equipos de seguridad que confían en la tabla DeviceNetworkEvents de Microsoft Defender XDR para la búsqueda y detección podrían estar perdiendo conexiones de red externas críticas debido a una peculiaridad poco conocida en la clasificación de direcciones IP.

El problema se centra en FourToSixMapping, un valor de RemoteIPType que puede provocar que el tráfico de IP públicas eluda la lógica de detección que filtra estrictamente por RemoteIPType == "Public".

Según Detect FYI, este punto ciego surgió durante un ejercicio de Purple Team que simulaba a un atacante desplegando un binario para establecer un canal encubierto de comando y control (C2) saltándose los controles del proxy web. A pesar de tener una detección creada para esta etapa exacta del ataque, la alerta nunca se disparó.

La causa raíz se rastreó hasta una única restricción de la consulta:

text| where RemoteIPType == "Public"

Este filtro excluyó silenciosamente conexiones IP públicas válidas registradas bajo un valor de RemoteIPType diferente: FourToSixMapping.

Punto ciego de Microsoft Defender XDR

Las aplicaciones modernas de Windows utilizan frecuentemente sockets de doble pila, lo que permite la comunicación simultánea a través de IPv4 e IPv6. Cuando una aplicación se comunica a través de IPv4 mediante un socket compatible con IPv6, Defender XDR registra la dirección como una dirección IPv6 mapeada a IPv4, formateada como ::ffff:8.8.8.8.

Este formato está definido en el RFC 4291, el estándar de direccionamiento IPv6. Defender XDR etiqueta estos eventos como FourToSixMapping en lugar de Public, aunque la dirección subyacente sea una IP pública legítima.

Los analistas suelen dividir las detecciones de red por protocolo o servicio (SSH, RDP, HTTPS, DNS) para simplificar la creación de líneas base y acelerar el triaje. Pero las consultas que filtran solo por RemoteIPType == "Public" omitirán sistemáticamente cualquier conexión registrada como FourToSixMapping, creando un falso negativo (FN): ocurre un ataque real, existe una detección, pero la alerta nunca se activa.

Incluso la función integrada de KQL ipv4_is_private() no resuelve esto de manera limpia. Al probarla contra un valor de FourToSixMapping como ::ffff:8.8.8.8, devuelve null en lugar de verdadero o falso, y en KQL, null no es ninguna de las dos cosas. Las consultas que dependan de esta función sin normalización también descartarán silenciosamente estos eventos.

La solución recomendada es eliminar el prefijo ::ffff: de las direcciones de FourToSixMapping antes de evaluarlas:

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

Esto normaliza la dirección al formato IPv4 estándar, permitiendo un filtrado y análisis posteriores precisos.

Para auditar tu propio tenant en busca de eventos perdidos, una consulta de validación puede comparar los valores de RemoteIP en los tipos Public y FourToSixMapping durante una ventana histórica, marcando las IP que solo aparecieron como FourToSixMapping sin una entrada de Public correspondiente, tal como indicó Detect FYI en un informe.

Conclusión para defensores

Nunca filtres las comunicaciones externas públicas basándote únicamente en RemoteIPType == "Public". Hacerlo conlleva el riesgo de excluir silenciosamente un subconjunto significativo de tráfico público legítimo, incluyendo el tráfico vinculado a ataques reales.

En su lugar, trata Public y FourToSixMapping como indicadores igualmente válidos de comunicación externa, y normaliza los formatos de IP antes de aplicar la lógica de detección.

Esta brecha también resalta una lección más amplia en la ingeniería de detección: incluso las sugerencias de KQL asistidas por IA pueden pasar por alto este matiz, ya que las funciones estándar como ipv4_is_private() no gestionan correctamente las direcciones IPv6 mapeadas a IPv4 de serie. La validación manual de la lógica de detección frente a casos límite sigue siendo esencial.