Un ataque Nuke es un término legado para una categoría de técnicas de denegación de servicio que envían paquetes malformados, fragmentados o fuera de banda diseñados para colapsar el stack de red del objetivo en lugar de agotar su ancho de banda. El ejemplo más conocido, WinNuke, explotaba una falla en cómo los sistemas Windows de los años noventa manejaban datos TCP fuera de banda en el puerto NetBIOS 139, congelando o colapsando la máquina con un solo paquete manipulado.
Resumen rápido — “Nuke” describe una clase de ataques de la era de los años noventa que enviaban uno o unos pocos paquetes malformados para colapsar directamente a un objetivo, en lugar de inundarlo con volumen. WinNuke, la variante más famosa, enviaba segmentos TCP con el flag URGENT activado y datos fuera de banda al puerto 139 en máquinas Windows 95 y Windows NT, provocando una pantalla azul o un bloqueo porque el sistema operativo manejaba mal los datos OOB cuando ninguna aplicación los estaba leyendo. Microsoft parchó la falla en 1997-1998. El término ahora funciona mayormente como una etiqueta histórica; el uso moderno a veces lo extiende informalmente a cualquier ataque que colapse un stack de red con un solo paquete malformado, pero los sistemas operativos actuales manejan de forma segura las opciones TCP malformadas y los datos OOB.
Última actualización: 2026-08-08
Cómo funciona el ataque
TCP incluye un mecanismo de datos urgentes, señalado por el flag URGENT y un campo de puntero urgente en el header TCP, originalmente pensado para permitir que las aplicaciones envíen datos de alta prioridad (como una señal de interrupción de Telnet) antes del flujo de datos normal. WinNuke abusaba de este mecanismo contra los servicios NetBIOS de Windows escuchando en el puerto 139.
Manejo normal de datos urgentes TCP:Cliente ──segmento TCP (flag URG activado, puntero urgente fijado, datos OOB)──▶ ServidorServidor: pasa los datos OOB a la aplicación vía su rutina de manejo OOB
WinNuke:Atacante ──segmento TCP (URG=1, datos OOB)──▶ objetivo:139 (NetBIOS)El driver NetBIOS del objetivo recibe datos OOB sin ninguna aplicaciónesperándolos; el código vulnerable de manejo OOB en el stack TCP/IPdesreferencia un puntero inválido o maneja mal los datos │ ▼Windows 95/NT: el sistema se congela, muestra una pantalla azul, o colapsaLa falla subyacente no estaba en la especificación TCP misma, sino en cómo el stack TCP/IP de Windows afectado procesaba los datos OOB entregados a una sesión NetBIOS establecida: la rutina de manejo no consideraba correctamente el caso en que los datos OOB llegaban sin que una aplicación estuviera leyendo activamente de ese socket de la forma esperada, provocando una falla a nivel de kernel. Como NetBIOS sobre TCP/IP (puerto 139) estaba habilitado por defecto y ampliamente expuesto en las configuraciones tempranas de redes Windows, el exploit era alcanzable en una gran cantidad de máquinas con un solo paquete manipulado.
Contexto histórico
WinNuke surgió en 1997 como uno de los exploits de “colapso de un solo paquete” más ampliamente publicitados de la época, apareciendo poco después de Ping of Death y Teardrop, que habían demostrado técnicas similares de denegación de servicio de un solo paquete contra otras partes del stack TCP/IP. Afectó específicamente a sistemas Windows 95 y Windows NT 3.51/4.0 con NetBIOS habilitado en el puerto 139. Microsoft publicó parches abordando la falla de manejo de datos OOB en 1997 y 1998, y la corrección se incorporó en los service packs posteriores de Windows y en versiones más recientes de Windows por defecto.
El nombre “Nuke” es anterior a WinNuke y se usaba informalmente en la cultura hacker e IRC de los años noventa para cualquier herramienta que pudiera colapsar o desconectar remotamente la máquina de otro usuario; WinNuke se convirtió en el ejemplo con nombre propio más prominente y efectivamente se volvió sinónimo de la categoría.
Ataques Nuke vs. ataques modernos de interrupción de conexión
| Aspecto | Nuke / WinNuke (legado) | TCP RESET Flood (moderno) |
|---|---|---|
| Mecanismo | Datos OOB TCP malformados explotando un bug del stack | Alto volumen de paquetes RST falsificados para forzar el cierre de conexión |
| Paquetes requeridos | Uno o unos pocos | Muchos, sostenidos durante la duración del ataque |
| Causa raíz | Defecto de software en el manejo de datos OOB | Comportamiento de protocolo (TCP acepta RST sin validación completa) |
| Efecto | Colapso, congelamiento o reinicio completo del objetivo | Interrupción de conexiones activas, no un colapso del sistema |
| Exposición en sistemas modernos | Parchado desde finales de los años noventa | Todavía relevante; mitigado con validación de secuencia |
| Objetivos típicos hoy | Esencialmente ninguno en sistemas parchados | Cualquier servicio basado en TCP con conexiones de larga duración |
Por qué los sistemas modernos son en gran medida inmunes
Los sistemas operativos actuales ya no habilitan por defecto servicios legados de NetBIOS sobre TCP/IP como el puerto 139, y donde los servicios NetBIOS o SMB permanecen habilitados, su manejo de datos OOB y opciones TCP se ha reimplementado y reforzado a lo largo de más de dos décadas de revisión de seguridad posterior. Los stacks TCP/IP estándar en Windows, Linux y sistemas derivados de BSD ahora validan el manejo del puntero urgente y datos OOB sin los defectos de manejo de puntero o estado que hicieron posible a WinNuke.
El riesgo residual es en gran medida conceptual más que literal: el término “Nuke” a veces se aplica informalmente a exploits de colapso de uno o pocos paquetes más nuevos, descubiertos en software específico (firmware de dispositivos embebidos, stacks de protocolo industrial, o appliances de red de nicho) que manejan mal la entrada malformada de forma similar. Los sistemas Windows legados que aún corren en entornos sin soporte, aislados (air-gapped), o industriales sin parches siguen siendo los descendientes literales más cercanos de la exposición original.
Detección y mitigación
- Deshabilitar servicios legados no usados — NetBIOS sobre TCP/IP (puerto 139) debería deshabilitarse a menos que se requiera explícitamente, eliminando por completo la superficie de ataque histórica
- Validación de entrada a nivel de kernel — los stacks TCP/IP modernos validan el manejo de datos OOB y puntero urgente; asegúrate de que los sistemas legados o embebidos corran stacks parchados
- Reglas de firewall que bloquean flags anómalos — filtra segmentos TCP con uso inusual o innecesario del flag URG dirigidos a servicios internos desde redes no confiables
- Segmentación de red — aísla los sistemas legados que no se pueden parchar detrás de firewalls que restringen el acceso solo a orígenes requeridos y de confianza
- Gestión de parches y activos — mantén un inventario de dispositivos legados o embebidos que todavía corren stacks de red vulnerables y prioriza el parcheo o reemplazo
Cómo implementarlo con Azion
DDoS Protection y Network Shield de Azion pueden ayudar a filtrar tráfico TCP malformado y anómalo, incluyendo combinaciones inusuales de flags, antes de que llegue a la infraestructura de origen. Las reglas de Firewall se pueden configurar para restringir qué puertos y protocolos son alcanzables en el edge, reduciendo la exposición de servicios legados o internos que todavía puedan ser vulnerables a técnicas de colapso de un solo paquete.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es la protección y mitigación DDoS?
- ¿Qué es un ataque Teardrop?
- ¿Qué es un ataque TCP RESET Flood?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque Nuke? Un ataque Nuke es un término legado para denegación de servicio técnicas que envían paquetes malformados o fuera de banda para colapsar el stack de red de un objetivo directamente, en lugar de inundarlo con alto volumen de tráfico. WinNuke, apuntando a Windows vía el puerto NetBIOS 139, es el ejemplo más conocido.
¿Es el ataque Nuke todavía una amenaza hoy? El exploit literal WinNuke no es una amenaza a ningún sistema moderno parchado; Microsoft corrigió la falla subyacente en 1997-1998. El término persiste informalmente para describir cualquier exploit de pocos paquetes que colapse un stack de red, una categoría que todavía puede aparecer en software embebido o legado sin parchar.
¿Cómo funcionaba WinNuke? WinNuke enviaba un segmento TCP con el flag URGENT activado y datos fuera de banda al puerto 139 (NetBIOS) en máquinas Windows 95 o Windows NT. La rutina vulnerable de manejo de datos OOB en el stack TCP/IP afectado manejaba mal los datos, causando un congelamiento o colapso del sistema.
¿Qué son los datos fuera de banda (OOB) en TCP? Los datos OOB son un mecanismo de TCP, señalado con el flag URGENT y un puntero urgente, que permite a una aplicación enviar datos de alta prioridad antes del flujo normal. Originalmente se usaba para señales como caracteres de interrupción de Telnet; WinNuke abusaba de cómo Windows los procesaba cuando ninguna aplicación los esperaba activamente.
¿En qué se diferencia un ataque Nuke de un ataque Teardrop? Teardrop explota offsets de fragmento IP superpuestos para colapsar un objetivo durante el reensamblado de paquetes, mientras que los ataques Nuke estilo WinNuke explotan una falla de manejo de datos OOB a nivel TCP, sin relación con la fragmentación. Ambos son exploits de colapso de uno o pocos paquetes de la misma era de mediados de los años noventa de vulnerabilidades de stack TCP/IP.
¿En qué se diferencia un ataque Nuke de un TCP RESET flood? Un TCP RESET flood usa volumen —muchos paquetes RST falsificados— para derribar conexiones activas y depende del comportamiento normal de TCP, no de un bug de software. Un ataque Nuke como WinNuke explota un defecto de implementación específico y puede colapsar un objetivo con un solo paquete manipulado.
¿Por qué era significativo el puerto 139 en WinNuke? El puerto 139 lo usa NetBIOS sobre TCP/IP, un servicio habilitado por defecto en las configuraciones tempranas de redes Windows para compartir archivos e impresoras. Su exposición amplia y habilitada por defecto lo convirtió en un objetivo conveniente y ampliamente alcanzable para el exploit de datos OOB.
¿Los ataques estilo Nuke pueden afectar a Linux o macOS? El exploit original de WinNuke era específico a la implementación NetBIOS de Windows de esa era y no afectaba a los stacks TCP/IP de Linux o macOS de la misma forma. Otros sistemas operativos han tenido sus propios bugs históricos de colapso de un solo paquete, pero generalmente no se les llama “WinNuke”.
¿Los firewalls modernos bloquean los ataques estilo Nuke? Sí. Los firewalls e IPS modernos pueden detectar y descartar segmentos TCP con combinaciones de flags anómalas o datos OOB innecesarios dirigidos a servicios que no los esperan, y la mayoría de los entornos ya no exponen puertos NetBIOS externamente en absoluto.
¿“Nuke” es un término técnico formal? No. A diferencia de SYN flood o Teardrop, “Nuke” se originó como jerga informal de la cultura hacker e IRC de los años noventa para cualquier herramienta que pudiera colapsar o desconectar remotamente la máquina de un objetivo. WinNuke se convirtió en la implementación con nombre propio más reconocida del concepto.
¿Qué deberían hacer las organizaciones que todavía corren sistemas Windows legados? Deshabilitar NetBIOS sobre TCP/IP a menos que se requiera, aplicar todos los parches de seguridad disponibles, y aislar cualquier sistema legado sin parchar detrás de una segmentación de red que restrinja el acceso entrante solo a orígenes de confianza.
Fuentes
- CERT|CC. Avisos y boletines de proveedores que documentan la vulnerabilidad WinNuke (datos OOB), 1997.
- Microsoft. Boletines de seguridad que abordan el manejo de datos fuera de banda en Windows 95 y Windows NT, 1997-1998.
- IETF. “Transmission Control Protocol.” RFC 793 (obsoleto por RFC 9293). 1981.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.