Un investigador de seguridad, Malcolm Stagg, ha presentado una nueva clase de ataques conocida como NatJack. Su idea central consiste en manipular el estado de las conexiones en mecanismos de network address translation (NAT), con consecuencias que van desde el secuestro de sesiones TCP hasta la falsificación de respuestas DNS. Además, la investigación advierte sobre riesgos como la exposición de puertos mapeados y la posibilidad de agotar tablas NAT.
El trabajo se presentó en Black Hat USA 2026 y describió comportamientos observados en implementaciones desarrolladas de forma independiente, incluyendo entornos de Windows y Linux. A continuación, repasamos qué está en juego, cómo opera a grandes rasgos NatJack y qué puedes hacer para reducir el impacto.
Qué es NatJack y por qué afecta a las sesiones TCP
NatJack parte de una suposición frecuente en muchas implementaciones de NAT: si dos equipos comparten la misma infraestructura NAT, normalmente no deberían poder alterar el estado de conexión que pertenece a otro host. La investigación de Stagg cuestiona esa premisa.
En términos prácticos, NatJack intenta manipular entradas de seguimiento de conexiones (connection tracking) o el mapeo que NAT mantiene entre direcciones/puertos internos y externos. Si el atacante logra provocar cambios en el estado asociado a la víctima, puede desviar el flujo de red y tomar el control lógico de una sesión.
Este enfoque encaja directamente con la categoría de NatJack sesiones TCP, porque la familia de ataques se centra en interferir con conexiones activas y en el uso de información de red para redirigir o completar intercambios de forma manipulada.
Cuatro rutas principales de ataque
Según la investigación, NatJack se puede materializar mediante varios caminos. No son técnicas idénticas en todos los casos, pero sí comparten la intención de alterar el estado que NAT cree que corresponde a una comunicación legítima.
1) Reemplazo del mapeo NAT para redirigir tráfico
Una vía consiste en redirigir tráfico de una conexión TCP activa. El atacante busca reemplazar el mapeo NAT existente por uno nuevo, de modo que el tráfico que debía seguir a la víctima termine alcanzando al adversario.
2) Interferencia con la solicitud DNS para inyectar una respuesta falsa
Otra ruta se apoya en DNS. NatJack puede interferir con una petición DNS de la víctima para que la respuesta legítima llegue al atacante. Con ese control del contexto, el atacante puede enviar una respuesta falsificada que se acepte dentro del flujo de la sesión o del intercambio.
3) Revelar puertos mapeados desde el exterior
La investigación también menciona que determinadas técnicas podrían disclose (en el sentido de revelar) puertos mapeados hacia la infraestructura interna. Esto puede ayudar al adversario a identificar superficies expuestas o a perfilar el camino de comunicación real.
4) Agotar la tabla de conexiones NAT
Finalmente, NatJack contempla la posibilidad de llenar la tabla de conexiones NAT con flujos falsos o manipulados. El resultado sería que los clientes legítimos no logren crear nuevas conexiones, generando una degradación del servicio o un bloqueo funcional.
Quién puede ejecutar NatJack: el papel del acceso privilegiado
La investigación subraya que, en general, NatJack requiere acceso privilegiado al sistema que el atacante controla, y ese sistema debe estar dentro del mismo NAT que la víctima. En otras palabras, el escenario típico es un entorno donde varios workloads comparten infraestructura de traducción de direcciones.
Este punto influye en las recomendaciones de mitigación: si eliminas o reduces la compartición de NAT entre cargas confiables y no confiables, disminuyes la ventana para que el adversario abuse del estado que NAT mantiene para otros hosts.
Vulnerabilidades asignadas y sistemas afectados
La investigación no describe una única “solución” para toda la familia de ataques. En cambio, se asignaron dos fallos específicos con identificadores CVE para componentes de NAT en distintas plataformas.
- CVE-2026-56181: asociado a NAT en Windows usado por Hyper-V. La puntuación CVSS reportada es 8.3.
- CVE-2026-63913: asociado a Linux Netfilter conntrack. La puntuación CVSS reportada es 8.2.
Además, las notas de seguridad citadas en la investigación describen el problema desde la perspectiva del tipo de validación y control del estado, lo que ayuda a entender por qué el ataque puede culminar en secuestro de sesión, falsificación DNS o cierres prematuros de entradas.
Linux: correcciones en releases estables del kernel
Para Linux, el registro CNA asociado a la información del kernel señala que un paquete SYN construido seguido por un reset con un número de secuencia inválido puede forzar de forma prematura un estado “cerrado” en una entrada NAT de Netfilter. La causa, según el reporte, estaría relacionada con una falla en la validación de la lógica de conntrack respecto a la dirección del tráfico.
La investigación lista releases estables con corrección, incluyendo: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 y 7.1.
Stagg aclara que el cambio del kernel corrige el fallo de código, pero solo mitiga la técnica de suplantación aguas abajo (downstream-spoofing). En consecuencia, no elimina por completo el riesgo general: aumenta la complejidad del ataque, en lugar de cerrarlo al 100%.
Windows: error de validación del origen y rangos de versiones
Para Windows, el registro CNA descrito en el artículo explica el problema como un error de validación del origen que permite suplantación desde una red adyacente. Los afectados indicados incluyen:
- Windows 11 24H2 antes de 26100.8875
- Windows 25H2 antes de 26200.8875
- Windows 26H1 antes de 28000.2525
- Windows Server 2025 antes de 26100.33158
Este encuadre es relevante porque ayuda a priorizar la corrección: si el sistema no valida adecuadamente el origen, el atacante puede intentar que el estado de NAT evolucione como si el tráfico viniera de un contexto confiable.
Estado de explotación en el mundo real
La investigación indica que el sitio de NatJack no publica una matriz completa por producto y modelo. Además, hasta el 7 de agosto de 2026, no se encontró evidencia pública de explotación “en la naturaleza” (wild) asociada a estas técnicas.
Eso no elimina la necesidad de prepararse: la ausencia de reportes públicos recientes no equivale a que el riesgo sea menor. Por eso conviene tratar NatJack como una alerta preventiva, especialmente en redes con segmentación insuficiente.
Qué probó el equipo y cómo se valida el impacto
El artículo menciona que Stagg probó las técnicas contra decenas de productos reales de infraestructura de red de múltiples fabricantes. De esa evaluación, también se reporta la demostración de prueba de concepto en un entorno de laboratorio controlado.
La metodología de pruebas y el hecho de que existan implementaciones independientes con comportamientos similares elevan la importancia de revisar configuraciones, parches y prácticas de segmentación.
Mitigaciones recomendadas: separa cargas y refuerza el cifrado
Como NatJack suele requerir un atacante con acceso privilegiado dentro del mismo NAT, el plan de defensa se enfoca en reducir la posibilidad de que un host no confiable pueda interactuar de forma peligrosa con el estado que NAT mantiene para otros.
Las recomendaciones clave incluyen:
- Aplicar actualizaciones disponibles en Windows y Linux que corrijan las vulnerabilidades asignadas.
- Cifrar el tráfico, incluso en redes internas, para disminuir el valor de la manipulación del flujo.
- Separar workloads no confiables de sistemas confiables que comparten la misma infraestructura NAT.
- Usar IP Source Guard donde sea aplicable, como medida adicional de control de origen.
Además, la investigación destaca que no hay un parche “único” para toda la familia. Por eso, lo más efectivo suele ser combinar correcciones técnicas con buenas prácticas de arquitectura de red.
Antecedentes: NAT-state manipulation y estudios previos
NatJack no surge de la nada. El artículo señala que el trabajo se apoya en investigación previa sobre manipulación del estado NAT. En particular, un estudio de NDSS 2024 exploró el secuestro de TCP mediante manipulación de mapeo NAT y encontró que 52 de 67 routers probados eran susceptibles, generando diez CVEs en ese contexto.
Esa continuidad sugiere que el problema no es aislado: mientras NAT gestione el estado de conexión con suposiciones de confianza entre hosts, seguirán existiendo escenarios en los que un atacante dentro del mismo dominio pueda intentar interferir.
Conclusión
NatJack sesiones TCP describe una amenaza que va más allá de un fallo puntual: se apoya en la forma en que NAT mantiene y valida el estado de las conexiones. La investigación asocia esta manipulación con resultados como secuestro de sesiones TCP, falsificación de respuestas DNS, posible exposición de puertos mapeados y agotamiento de tablas NAT.
Para reducir el riesgo, lo más importante es combinar parches en Windows y Linux con medidas de segmentación y cifrado dentro de redes internas. Si tu infraestructura comparte NAT entre cargas confiables y no confiables, ahora es un buen momento para reevaluar el diseño y aplicar controles como IP Source Guard donde corresponda.
Fuente: https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
