MS17-010 EternalBlue: La Vulnerabilidad de los 10.000 Millones (2017)

El error de dos bytes que costó 10.000 millones de dólares

En la historia de la ciberseguridad existe un antes y un después de EternalBlue. Una vulnerabilidad en el protocolo SMBv1 de Windows, catalogada como CVE-2017-0144, se convirtió en el motor de los dos ciberataques más destructivos jamás registrados: WannaCry y NotPetya. Los daños combinados superaron los 14.000 millones de dólares. Hospitales paralizados, fábricas detenidas, infraestructura portuaria bloqueada, cadenas logísticas rotas.

Pero el impacto económico es solo una parte de la historia. EternalBlue representa un punto de inflexión en múltiples dimensiones: la primera demostración a escala global de lo que ocurre cuando un exploit de grado militar llega a manos de cibercriminales, la confirmación de que las agencias de inteligencia acumulan vulnerabilidades peligrosas, y la prueba definitiva de que un solo bug puede paralizar la infraestructura digital de un planeta.

El identificador técnico es seco: MS17-010. El nombre en clave es evocador: EternalBlue. La realidad es que un error de conversión de tipos en dos líneas de código del kernel de Windows, combinado con decisiones geopolíticas sobre la retención de vulnerabilidades, produjo una catástrofe que todavía resuena casi una década después.

SMBv1: un protocolo de los años 80 en la infraestructura del siglo XXI

Server Message Block (SMB) es el protocolo de Windows para compartir archivos, impresoras y otros recursos en red. La versión 1 del protocolo data de 1983, cuando Barry Feigenbaum la diseñó en IBM como parte del PC Network Program. Microsoft la adoptó y extendió durante los años 90, convirtiéndola en el corazón del networking de Windows.

Para 2017, SMBv1 era un fósil. Las versiones 2 y 3 del protocolo, mucho más eficientes y seguras, llevaban años disponibles. Pero la compatibilidad retroactiva es sagrada en el ecosistema Windows: SMBv1 seguía habilitado por defecto en todas las versiones del sistema operativo, incluyendo Windows 10 y Server 2016. Millones de máquinas lo exponían en sus redes internas, y un número preocupante lo exponían directamente a Internet a través del puerto TCP 445.

El driver del kernel responsable de manejar las peticiones SMB es srv.sys (también conocido como srvnet.sys en versiones más recientes). Este driver procesa los paquetes SMB entrantes, parsea sus estructuras de datos, y ejecuta las operaciones solicitadas. Al operar a nivel de kernel, cualquier vulnerabilidad en este código permite ejecución con los máximos privilegios del sistema: SYSTEM en Windows, equivalente a root en Unix.

Anatomía técnica: la conversión DWORD a WORD

La vulnerabilidad se encuentra en el manejo de las transacciones SMB, específicamente en la forma en que Windows convierte las estructuras de datos FEA (Full Extended Attributes) del formato OS/2 al formato NT.

Cuando un cliente envía una petición SMB con atributos extendidos, el servidor necesita calcular el tamaño del buffer para la conversión. Este cálculo se realiza en la función Srv!SrvOs2FeaListSizeToNt. La función itera sobre la lista de FEAs y suma los tamaños convertidos.

El bug crítico está en el tipo de dato utilizado para esta suma. El código original usa una variable de tipo WORD (16 bits, unsigned, rango 0 a 65.535) para acumular el tamaño total:

// Pseudocódigo simplificado del bug
WORD totalSize = 0;  // 16 bits: máximo 65.535

for (each FEA in feaList) {
    DWORD convertedSize = calculateNtFeaSize(fea);  // 32 bits
    totalSize += (WORD)convertedSize;  // Truncamiento silencioso
}

// Si la suma real excede 65.535, totalSize sufre integer overflow
// Ejemplo: tamaño real 0x10000 (65.536) → totalSize = 0x0000 (0)

El atacante construye una lista de FEAs cuyo tamaño total convertido excede los 65.535 bytes. La función calcula un tamaño truncado (mucho menor que el real) y asigna un buffer de ese tamaño en la nonpaged pool del kernel. Cuando la función Srv!SrvOs2FeaToNt ejecuta la operación memmove con el tamaño real, se produce un desbordamiento masivo.

Pool overflow en el kernel

La nonpaged pool es una región de memoria del kernel de Windows que contiene datos que nunca se paginan a disco. Estructuras críticas del kernel residen aquí: objetos de proceso, tokens de seguridad, descriptores de archivo. Un overflow en esta región permite sobrescribir cualquiera de estas estructuras.

El exploit de EternalBlue utiliza una técnica llamada pool grooming: antes de disparar el overflow, envía una serie de peticiones SMB cuidadosamente diseñadas para colocar la pool en un estado predecible. El objetivo es que el buffer desbordado esté adyacente a una estructura controlable, típicamente un buffer de sesión SMB o una estructura srvnet!SRVNET_BUFFER_HDR.

Nonpaged Pool (después del grooming):

┌────────────────────────┐
│  Buffer SMB (overflow)  │  ← El buffer asignado con tamaño incorrecto
├────────────────────────┤
│  SRVNET_BUFFER_HDR      │  ← Estructura víctima a sobrescribir
│  - MDL pointer          │
│  - pNetRawBuffer        │
│  - función de dispatch   │
├────────────────────────┤
│  Otros objetos kernel   │
└────────────────────────┘

Al desbordar el buffer, el exploit sobrescribe la estructura SRVNET_BUFFER_HDR adyacente. Esta estructura contiene un puntero a una función de dispatch que se invoca cuando se recibe el siguiente paquete de red. El exploit reemplaza este puntero con la dirección de su shellcode, que se ha colocado en una posición conocida de la pool.

La cadena de ejecución

La secuencia completa del exploit sigue estos pasos:

1. Detección: enviar una petición SMB_COM_NEGOTIATE para identificar la versión del sistema operativo y confirmar que SMBv1 está habilitado.

2. Grooming: enviar múltiples transacciones SMB para manipular el estado de la nonpaged pool y crear un layout predecible.

3. Overflow: enviar una petición SMB con FEAs malformadas que disparan la conversión DWORD a WORD, causando la asignación de un buffer insuficiente y el posterior desbordamiento.

4. Hijack: el overflow sobrescribe la estructura SRVNET_BUFFER_HDR adyacente, reemplazando el puntero de dispatch con la dirección del shellcode.

5. Ejecución: cuando el driver procesa el siguiente paquete SMB, invoca el puntero sobrescrito y ejecuta el shellcode del atacante en contexto de kernel (SYSTEM).

6. Payload: el shellcode carga DoublePulsar u otro implante, estableciendo persistencia en la máquina comprometida.

Lo que hace a EternalBlue especialmente peligroso es la fiabilidad del exploit. A diferencia de muchos exploits de kernel que dependen de condiciones de carrera o layouts de memoria impredecibles, el grooming de la pool en EternalBlue produce resultados consistentes. En pruebas, el exploit tiene una tasa de éxito superior al 90% contra sistemas vulnerables. Esta fiabilidad es lo que permite su uso como componente de un worm: puede propagarse automáticamente sin intervención humana y sin preocuparse por crashear las máquinas objetivo.

DoublePulsar: la backdoor compañera

EternalBlue raramente se utiliza solo. El toolkit original de la NSA incluía un implante llamado DoublePulsar que se instalaba inmediatamente después de la explotación exitosa. DoublePulsar es una backdoor que opera a nivel de kernel, modifica la tabla de dispatch del driver SMB para interceptar ciertos tipos de paquetes, y permite ejecutar payloads arbitrarios en la máquina comprometida.

DoublePulsar tiene características que revelan su origen en una agencia de inteligencia:

No persistente por diseño: se pierde al reiniciar la máquina. Esto minimiza la evidencia forense y reduce la probabilidad de detección. Si la NSA necesitaba acceso continuado, podía reinstalar el implante usando EternalBlue.

Comunicación encubierta: utiliza paquetes SMB legítimos con modificaciones sutiles en campos que normalmente son ignorados por los IDS/IPS. La detección requiere inspección profunda del tráfico SMB, algo que pocos sistemas realizaban en 2017.

Plataforma de carga: DoublePulsar no es el payload final, sino una plataforma para cargar otros payloads. Acepta DLLs y shellcode que ejecuta en el contexto del kernel o inyecta en procesos de userspace.

Tras la filtración de Shadow Brokers, investigadores de seguridad desarrollaron herramientas para detectar máquinas infectadas con DoublePulsar. Los escaneos iniciales en abril de 2017 revelaron decenas de miles de máquinas infectadas, muchas de ellas antes de que WannaCry apareciera. Esto sugiere que otros actores (posiblemente la propia NSA u otros servicios de inteligencia) ya estaban explotando estas herramientas antes de la filtración pública.

La cronología: de la NSA a WannaCry

La historia de EternalBlue es una secuencia de decisiones y eventos que, vistos en retrospectiva, tenían un final casi inevitable.

2011-2012 (estimado): La NSA descubre o desarrolla el exploit para la vulnerabilidad en SMBv1. El exploit se integra en el toolkit FUZZBUNCH, junto con otros exploits como ETERNALROMANCE, ETERNALSYNERGY y ETERNALCHAMPION. El equipo responsable se conoce internamente como el Equation Group.

Agosto de 2016: Un grupo autodenominado The Shadow Brokers anuncia la subasta de herramientas de hacking robadas al Equation Group de la NSA. Publican una muestra gratuita para demostrar que tienen material real.

Enero-febrero de 2017: La NSA, consciente de que Shadow Brokers posee sus herramientas, notifica a Microsoft sobre las vulnerabilidades. Los detalles exactos de esta comunicación nunca se han hecho públicos.

14 de marzo de 2017: Microsoft publica el boletín de seguridad MS17-010, parcheando seis vulnerabilidades en SMBv1. No se atribuye ninguna de las vulnerabilidades a ningún actor específico. Windows XP, Server 2003 y otros sistemas fuera de soporte no reciben parche.

14 de abril de 2017: Shadow Brokers publica el quinto lote de herramientas, incluyendo ETERNALBLUE, ETERNALROMANCE, DOUBLEPULSAR y el framework FUZZBUNCH. Las herramientas son funcionales y relativamente fáciles de usar.

21 de abril de 2017: Comienzan los primeros ataques masivos utilizando EternalBlue para instalar DoublePulsar. En cuestión de días, decenas de miles de máquinas están comprometidas.

12 de mayo de 2017: WannaCry se propaga a una velocidad sin precedentes. En menos de 24 horas, infecta más de 200.000 máquinas en 150 países. Hospitales del NHS británico cancelan cirugías. Fábricas de Renault y Nissan se detienen. Telefónica en España desconecta estaciones de trabajo.

27 de junio de 2017: NotPetya golpea, principalmente a Ucrania pero con daño colateral global. Maersk pierde su infraestructura IT completa. Merck, FedEx (TNT Express), Mondelez y otras multinacionales sufren pérdidas masivas. Los daños estimados superan los 10.000 millones de dólares.

WannaCry: el worm que paralizó el mundo

WannaCry combinó EternalBlue con un componente de ransomware y un mecanismo de propagación tipo worm. Una vez ejecutado en una máquina, utilizaba EternalBlue para escanear la red local y propagar automáticamente a otras máquinas vulnerables. Cada máquina infectada cifraba sus archivos y exigía un rescate de 300 dólares en Bitcoin.

La velocidad de propagación fue extraordinaria. WannaCry no necesitaba interacción del usuario, no requería phishing ni ingeniería social. Bastaba con que una máquina vulnerable estuviera accesible en la red. El worm escaneaba rangos de IP aleatorios además de la red local, lo que le permitía saltar entre organizaciones.

El freno llegó de forma inesperada. Marcus Hutchins, un investigador de seguridad británico de 22 años, descubrió que WannaCry consultaba un dominio específico antes de activarse. Si el dominio respondía, el malware se detenía. Hutchins registró el dominio por unos pocos dólares, activando accidentalmente el "kill switch" que frenó la propagación global. Este mecanismo probablemente existía como medida anti-análisis: los sandboxes de malware suelen responder a cualquier petición DNS, y el kill switch evitaría la activación en un entorno de análisis.

NotPetya: destrucción disfrazada de ransomware

NotPetya fue peor. Mucho peor. Aunque se presentaba como ransomware (con una pantalla de rescate y una dirección de Bitcoin), su verdadero propósito era la destrucción. El mecanismo de cifrado estaba diseñado para ser irreversible: la clave de cifrado se generaba aleatoriamente y se destruía, haciendo imposible la recuperación incluso si se pagaba el rescate.

NotPetya utilizaba EternalBlue como uno de sus vectores de propagación, pero no el único. También explotaba credenciales robadas de memoria con Mimikatz y se propagaba a través de recursos compartidos ADMIN$ y C$ usando PsExec y WMI. Esta combinación de vectores lo hacía más efectivo que WannaCry en redes corporativas bien parcheadas.

El vector de infección inicial fue un servidor de actualización comprometido de M.E.Doc, un software de contabilidad ucraniano de uso obligatorio para declaraciones fiscales. Cualquier empresa que operara en Ucrania y usara este software recibió NotPetya como una "actualización". Desde esas máquinas iniciales, el malware se propagó lateralmente usando EternalBlue y credenciales robadas.

Maersk, el gigante naviero danés, perdió la totalidad de su infraestructura IT: 49.000 laptops, 4.000 servidores, 2.500 aplicaciones. La reconstrucción tomó 10 días y requirió la reinstalación completa de toda la infraestructura. Un solo domain controller que estaba apagado durante el ataque, en una oficina en Ghana, permitió recuperar Active Directory. Sin esa copia, la recuperación habría sido exponencialmente más costosa.

La Casa Blanca estimó los daños totales de NotPetya en más de 10.000 millones de dólares. En 2018, Estados Unidos y Reino Unido atribuyeron públicamente el ataque a la unidad de inteligencia militar rusa GRU, específicamente al grupo conocido como Sandworm.

El debate: ¿debería la NSA haber revelado la vulnerabilidad antes?

EternalBlue reavivó un debate fundamental en ciberseguridad: el Vulnerabilities Equities Process (VEP), el mecanismo por el cual el gobierno estadounidense decide si revelar vulnerabilidades descubiertas a los fabricantes o retenerlas para uso ofensivo.

Los argumentos a favor de la retención son claros: una vulnerabilidad conocida solo por una agencia de inteligencia proporciona capacidad de acceso a sistemas de adversarios extranjeros. EternalBlue probablemente fue utilizado contra objetivos de inteligencia legítimos durante los años que la NSA lo mantuvo en secreto.

Los argumentos en contra son igualmente claros: durante esos mismos años, todos los sistemas Windows del mundo (incluyendo los del gobierno estadounidense, infraestructura crítica, hospitales, y sistemas militares aliados) eran vulnerables al mismo exploit. Si un adversario hubiera descubierto independientemente la misma vulnerabilidad, habría tenido acceso a toda esa infraestructura.

Y eso es exactamente lo que ocurrió. Cuando Shadow Brokers filtró el exploit, los adversarios obtuvieron la herramienta y la usaron contra la infraestructura que la NSA supuestamente protege. El coste, más de 10.000 millones de dólares y la paralización de servicios hospitalarios, superó con creces cualquier beneficio de inteligencia que la vulnerabilidad pudiera haber proporcionado.

Microsoft, a través de su presidente Brad Smith, comparó la filtración con "el robo de misiles Tomahawk al ejército". La analogía no es perfecta (un exploit puede copiarse infinitamente, un misil no), pero captura la esencia del problema: las armas cibernéticas, una vez filtradas, no pueden recuperarse.

Aspectos técnicos de la mitigación

El parche MS17-010 corrige la vulnerabilidad reemplazando la variable WORD por un DWORD en la función SrvOs2FeaListSizeToNt, eliminando el integer overflow. Es un cambio de pocas líneas que resuelve el problema raíz.

Sin embargo, parchear no siempre fue posible o inmediato:

Sistemas legacy: Windows XP y Server 2003 estaban fuera de soporte cuando se descubrió la vulnerabilidad. Microsoft tomó la decisión excepcional de publicar parches para estos sistemas, reconociendo la gravedad del riesgo.

Sistemas embebidos e industriales: equipos médicos, sistemas SCADA, y dispositivos IoT con Windows Embedded no siempre podían actualizarse sin certificación del fabricante.

Deshabilitar SMBv1: la medida más efectiva. Microsoft publicó guías para deshabilitar SMBv1 a nivel de sistema operativo. Esto elimina la superficie de ataque por completo, pero puede romper la compatibilidad con dispositivos antiguos (impresoras, NAS, etc.) que solo hablan SMBv1.

Reglas de firewall: bloquear el puerto TCP 445 en el perímetro impide la explotación desde Internet, pero no protege contra propagación lateral interna.

IDS/IPS: firmas para detectar paquetes SMB malformados que disparan el overflow. Productos como Snort, Suricata y soluciones comerciales incorporaron detecciones específicas.

EternalBlue en 2026: una vulnerabilidad que no desaparece

Nueve años después de su divulgación, EternalBlue sigue siendo explotado. Los datos de plataformas de monitorización muestran cientos de miles de sistemas con SMBv1 expuesto a Internet. En redes internas, la cifra es probablemente de millones.

El exploit se ha integrado en toolkits de ataque de todo tipo: desde frameworks de pentesting legítimos como Metasploit hasta botnets como Emotet y campañas de cryptomining. Grupos APT lo utilizan como vector de movimiento lateral en redes ya comprometidas, donde la probabilidad de encontrar máquinas sin parchear es significativamente mayor que en Internet.

La persistencia de EternalBlue ilustra un principio fundamental de la ciberseguridad: los exploits fiables nunca mueren. Mientras existan máquinas vulnerables (y en una base instalada de miles de millones de sistemas Windows, siempre las habrá), EternalBlue seguirá siendo una herramienta activa en el arsenal de los atacantes.

Lecciones para la industria

EternalBlue dejó lecciones que transformaron la ciberseguridad:

La deuda técnica mata. SMBv1 era un protocolo de 1983 habilitado por defecto en sistemas de 2017. La compatibilidad retroactiva tiene un coste de seguridad que se acumula silenciosamente hasta que explota.

Los gobiernos no pueden proteger lo que deliberadamente debilitan. La retención de vulnerabilidades crea un riesgo sistémico que, cuando se materializa, supera cualquier beneficio ofensivo.

La velocidad de parcheo es un factor existencial. Entre la publicación del parche (14 de marzo) y WannaCry (12 de mayo) pasaron 59 días. Suficiente para que cualquier organización con un programa de gestión de parches mínimamente funcional se protegiera. Las que fueron afectadas, en su mayoría, simplemente no parcheaban.

Un solo exploit puede tener impacto geopolítico. EternalBlue no fue solo un incidente de seguridad informática, fue un evento geopolítico que involucró a agencias de inteligencia de múltiples países y causó daños económicos comparables a desastres naturales.

La seguridad por capas no es opcional. Las organizaciones que segmentaban sus redes, monitorizaban tráfico SMB anómalo, y tenían backups offline sobrevivieron a WannaCry y NotPetya. Las que dependían exclusivamente del parche del sistema operativo, no.

Indicadores técnicos relevantes

Para equipos SOC y threat hunters, estos son los indicadores asociados a la explotación de EternalBlue:

Red: tráfico SMBv1 en puerto TCP 445 con paquetes SMB_COM_TRANSACTION2 o SMB_COM_NT_TRANSACT con tamaños de FEA anómalamente grandes. Paquetes SMB con valores de TotalDataCount inconsistentes con DataCount. Tráfico de escaneo masivo al puerto 445.

Host: presencia de DoublePulsar (modificaciones en la tabla de dispatch de srvnet.sys). Procesos lsass.exe con actividad de red inusual. Creación de servicios con nombres aleatorios. Modificaciones en el registro para persistencia.

Detección: reglas Sigma y YARA específicas para EternalBlue y DoublePulsar están disponibles en repositorios públicos como SigmaHQ. Productos EDR modernos detectan tanto el exploit como los payloads asociados mediante firmas y análisis de comportamiento.

La vulnerabilidad CVE-2017-0144 tiene un CVSS de 8.1 (Alto). Pero el impacto real, medido en miles de millones de dólares, en hospitales paralizados, en infraestructura crítica destruida, supera cualquier métrica numérica. EternalBlue es la vulnerabilidad que demostró que la ciberseguridad no es un problema técnico aislado: es un componente fundamental de la seguridad nacional y la estabilidad económica global.