Por Canuto  

Un nuevo análisis forense apunta a que Fast16, un malware desarrollado en 2005, fue diseñado para manipular simulaciones de detonaciones nucleares y engañar a ingenieros con datos falsos. La investigación lo perfila como un antecedente directo de Stuxnet y como parte de una campaña más amplia para frenar el programa nuclear de Irán.

***

  • Symantec confirmó que Fast16 apuntaba a LS-DYNA y AUTODYN, dos programas usados para modelar explosivos y compresión extrema.
  • El malware alteraba datos de presión y densidad cuando la simulación se acercaba al umbral de supercriticidad del uranio.
  • Expertos creen que la operación buscaba retrasar el programa nuclear iraní mediante sabotaje silencioso y confusión técnica.

 

Investigadores de Symantec confirmaron que Fast16, una pieza de malware descubierta hace años pero analizada en profundidad apenas recientemente, fue diseñada para sabotear simulaciones de pruebas de armas nucleares.

El objetivo habría sido alterar los resultados que veían los ingenieros, sembrar confusión y ralentizar el avance de un programa nuclear que, según múltiples especialistas, probablemente era el de Irán.

La conclusión refuerza hipótesis planteadas antes por SentinelOne, que había identificado la muestra y señalado que el código apuntaba a software de cálculo de alta precisión. El nuevo análisis va más allá y sostiene que Fast16 no solo manipulaba cálculos complejos, sino que se enfocaba de forma selectiva en simulaciones de detonaciones de altos explosivos vinculadas al diseño de armas nucleares.

De acuerdo con los investigadores Vikram Thakur y Eric Chien, del Threat Hunter Team de Symantec, el malware apuntaba al menos a dos aplicaciones concretas: LS-DYNA y AUTODYN. Ambos programas se usan para modelar fenómenos físicos extremos, desde choques de vehículos hasta explosiones, y también pueden emplearse para estudiar la compresión necesaria en una ojiva nuclear.

La relevancia del caso va más allá de la ciberseguridad. Fast16 muestra que, incluso antes de Stuxnet, ya existían herramientas digitales diseñadas no solo para robar información o tomar control de sistemas, sino para alterar la integridad de datos científicos y técnicos en procesos de importancia estratégica nacional.

Qué hacía Fast16 dentro del software de simulación

Según el análisis técnico, Fast16 intervenía el sistema desde un controlador de sistema de archivos que se cargaba con el arranque del equipo. Su función era interceptar archivos ejecutables a medida que eran leídos desde el disco y parchear en memoria secuencias de código muy específicas, usando un motor de reglas con 101 patrones.

El malware no atacaba cualquier programa. Primero esperaba a que se iniciara EXPLORER.EXE y luego filtraba ejecutables compilados con el compilador de Intel, identificando la cadena “Intel” en la cabecera PE. Solo aplicaba sus hooks cuando detectaba secuencias de instrucciones compatibles con ciertas versiones de LS-DYNA y AUTODYN.

Symantec concluyó que el motor de manipulación se activaba únicamente en simulaciones de detonación de altos explosivos. Para ello, comprobaba qué ecuación de estado estaba siendo usada. En el caso de LS-DYNA, buscaba selecciones EOS 2, 3 o 7, asociadas a modelos como Jones-Wilkins-Lee, Sack Tuesday e Ignition and Growth of Reaction in High Explosives. En AUTODYN, verificaba los valores 3, 5 y 11, que corresponden a Ideal Gas, JWL y Lee-Tarver.

La lógica operativa era aún más precisa. Fast16 no comenzaba a alterar valores hasta que la simulación alcanzaba ciertos umbrales. Entre ellos, una densidad del material de 30 g/cm3, un nivel que el uranio solo puede alcanzar bajo la compresión de choque propia de un dispositivo de implosión. Esa condición es una de las razones por las que los investigadores consideran que el blanco real eran simulaciones nucleares y no otro tipo de análisis industrial.

Cómo manipulaba los resultados

Los investigadores describen tres mecanismos principales de ataque, identificados como A, B y C. Todos buscan perturbar simulaciones de comportamiento de choque a alta presión, aunque con métodos algo distintos según la aplicación y la versión del software.

En el mecanismo A, Fast16 dejaba pasar la primera y la decimosexta vez que se alcanzaba un punto de hook. En las demás ocasiones, si el valor de entrada se ubicaba entre 30 y 65, reducía los valores de salida al 10 % de su nivel normal y mantenía esa distorsión en adelante.

En el mecanismo B, orientado a LS-DYNA, el código primero comprobaba el modelo EOS y exigía que ciertos atributos de la simulación alcanzaran cinco veces su valor inicial. Después, si la densidad del material llegaba a 30 g/cm3, reducía los valores de salida del tensor de tensiones de Cauchy, como sig_xx, sig_yy y sig_zz, al 1 % de sus valores reales. No lo hacía de golpe, sino de forma gradual, calculando una pendiente para que la reducción pareciera natural a medida que aumentaba la densidad.

En el mecanismo C, enfocado en AUTODYN, el malware realizaba verificaciones similares y además buscaba la cadena “$Loading co” en memoria. Dependiendo de la versión del programa, escalaba valores de salida como la presión con distintas pendientes. La reducción comenzaba también al llegar a 30 g/cm3 y se proyectaba hacia densidades finales como 40, 47, 48 o 60 g/cm3, con recortes equivalentes al 42 %, 10 %, 10 % u 8 % del valor real según el caso.

En términos prácticos, el efecto era engañar a los ingenieros sobre si una simulación se acercaba o no al punto de supercriticidad, es decir, el momento en que se desencadena la reacción en cadena que produce una explosión nuclear. Según el análisis citado por la fuente Zero Day, Fast16 reemplazaba datos legítimos por falsos y hacía creer a los operadores que la presión en el núcleo de uranio era insuficiente, aunque los datos reales indicaran lo contrario.

Por qué Irán aparece como principal objetivo

Aunque los investigadores no pueden excluir completamente a otros países que trabajaban en armas nucleares a comienzos de los 2000, varios expertos consideran que el contexto temporal, el enfoque en el uranio y el tipo de acceso requerido apuntan con fuerza a Irán. David Albright, físico y fundador del Institute for Science and International Security, dijo a Zero Day que esos elementos encajan con los esfuerzos iraníes por desarrollar armas nucleares.

El contexto histórico refuerza esa lectura. En agosto de 2002, el National Council of Resistance reveló la existencia de instalaciones nucleares secretas en Irán. En febrero de 2003, inspectores del OIEA visitaron por primera vez algunos de esos sitios y concluyeron que Teherán no había revelado plenamente su programa, que además estaba más avanzado de lo esperado.

En noviembre de 2004, Irán aceptó una suspensión temporal de su actividad nuclear mientras negociaba con la Unión Europea. Pero a comienzos de agosto de 2005, las conversaciones se estancaron y el país anunció que se retiraba del acuerdo y continuaría con su programa, incluido el enriquecimiento de gas de uranio en Natanz.

Ese detalle es clave porque, según la marca temporal del binario principal svcmgmt.exe, Fast16 fue compilado el 30 de agosto de 2005. El controlador fast16.sys tenía un link time del 19 de julio de 2005. Para entonces, según Albright, las agencias de inteligencia creían que Irán mantenía investigación relacionada con armas nucleares y que dependía en buena medida de simulaciones por computadora, más aún si las pruebas cinéticas habían sido reducidas o interrumpidas.

El propio análisis de Symantec indica que Irán utilizó tanto LS-DYNA como AUTODYN durante el período en que Fast16 habría estado activo. Eso no prueba por sí solo la atribución, pero sí explica por qué ambos programas fueron señalados como objetivos de alto valor dentro de una posible operación encubierta para frenar el avance técnico del programa.

Un antecedente directo de Stuxnet

La historia de Fast16 inevitablemente remite a Stuxnet, el malware atribuido a Estados Unidos e Israel que saboteó centrifugadoras iraníes y permaneció oculto durante años. La similitud conceptual es notable: ambos ataques alteraban datos para engañar a operadores y ambos requerían un conocimiento muy preciso del entorno objetivo.

En Stuxnet, el código hacía girar las centrifugadoras fuera de rango mientras mostraba a los operadores señales que sugerían que todo funcionaba bien. Fast16 adoptó una lógica inversa, según el nuevo análisis: mostraba que las pruebas de simulación estaban saliendo mal, aunque podían estar bien, para empujar a los ingenieros a cambiar modelos, fórmulas o configuraciones en una dirección equivocada.

Hay además señales de contemporaneidad entre ambos proyectos. Aunque Stuxnet no se desplegó en Irán hasta 2007, algunos dominios usados como servidores de mando y control fueron registrados en noviembre de 2005. También se sabe que a comienzos de 2006 se realizó una prueba de sabotaje con Stuxnet en Estados Unidos, cuyo resultado fue mostrado al entonces presidente George Bush.

Ese cruce temporal sugiere que Fast16 pudo haber formado parte de una campaña más amplia, posiblemente conectada con Olympic Games, la operación encubierta destinada a retrasar o impedir que Irán desarrollara una bomba nuclear. En ese marco, Fast16 habría sido un frente complementario, centrado no en las centrifugadoras, sino en el proceso de diseño y validación por simulación.

Cómo se descubrió y por qué siguió oculto tanto tiempo

Fast16 llamó por primera vez la atención del investigador Juan Andrés Guerrero-Saade cuando apareció mencionado en una herramienta de la NSA filtrada en 2017 por el grupo Shadow Brokers. El propio malware no estaba en la filtración, pero la referencia sugería que había sido creado por la NSA o por un aliado, y que no se trataba de un mero experimento de laboratorio.

Meses después, en octubre de 2017, alguien subió una muestra a VirusTotal. Allí pasó inadvertida durante dos años. En 2019, Guerrero-Saade la encontró y pasó años intentando descifrar su propósito junto con Vitaly Kamluk. Según SentinelOne, finalmente recurrieron a inteligencia artificial para entender mejor la finalidad de ciertos bloques de código y eso ayudó a perfilar que estaba saboteando software de cálculo de alta precisión.

El framework estaba compuesto por svcmgmt.exe, un binario de servicio con una máquina virtual Lua 5.0 embebida; fast16.sys, un controlador de kernel que parcheaba código al vuelo; y svcmgmt.dll, un módulo auxiliar de reporte. El carrier podía ejecutarse en distintos modos, instalarse como servicio, ejecutar código Lua, persistir mediante Image File Execution Options y desplegarse en hosts remotos.

También tenía capacidades de propagación lateral. Enumeraba dominios, servidores y recursos compartidos, se copiaba a través de <remote>admin$system32svcmgmt.exe y creaba un servicio remoto SvcMgmt para ejecutar el implante. Aun así, estaba diseñado para no salir de la red objetivo. Comprobaba rangos locales como 10.x.x.x, 172.16.x.x y 192.168.x.x, y aplicaba reglas de misma subred para mantenerse contenido.

Otra señal de sofisticación es que Fast16 evitaba infectar sistemas con 18 productos de seguridad concretos. Si encontraba una de esas claves de registro, no se propagaba. Además, soportaba entre 8 y 10 versiones diferentes de LS-DYNA, con grupos de hooks añadidos fuera de secuencia, lo que llevó a los investigadores a plantear que los desarrolladores podrían haber recibido inteligencia continua sobre qué versiones usaban los ingenieros objetivo.

Impacto probable y vigencia del caso

No está claro si las víctimas detectaron alguna vez el sabotaje. Tampoco se sabe con certeza cómo reaccionaban los usuarios al ver resultados anómalos. Symantec plantea que los cambios podían ser visibles para un experto, pero también lo bastante sutiles como para parecer errores del modelo, del software o del diseño, no un compromiso deliberado del sistema.

Albright considera que un ajuste de entre 1 % y 5 % en valores críticos habría bastado para desviar conclusiones sin generar sospechas inmediatas. En ese escenario, los ingenieros podían creer que su diseño no alcanzaba la supercriticidad, recalcular parámetros, aumentar fuerza explosiva o probar nuevas versiones del programa, todo sin resolver un problema que en realidad había sido inducido por el atacante.

El efecto probable, según el experto, habría sido desperdiciar tiempo, recursos y moral dentro del programa. Ese patrón coincide con el objetivo atribuido también a Stuxnet: no provocar una destrucción instantánea y total, sino introducir fricción acumulativa, retrasos y desconfianza en procesos críticos para ganar tiempo político y diplomático.

Las revelaciones sobre Fast16 llegan además en un momento sensible, cuando Estados Unidos e Israel siguen presionando para limitar el programa nuclear iraní por distintas vías. En ese contexto, el caso sirve como recordatorio de que las operaciones de sabotaje digital pueden apuntar no solo a maquinaria física, sino también a modelos, simulaciones y datos, es decir, a la capa invisible donde hoy se toman decisiones estratégicas de enorme impacto.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA.

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados