Según investigadores de Symantec y Carbon Black (ambas pertenecen a Broadcom), el framework malicioso fast16 basado en Lua fue diseñado para distorsionar de forma dirigida los resultados de las simulaciones de compresión de uranio, un proceso crítico para el diseño de armas nucleares. Si las conclusiones de los investigadores son correctas, se trataría de uno de los casos más antiguos conocidos de sabotaje cibernético de procesos industriales, anterior a Stuxnet y que obliga a replantear la cronología de los ciberataques estatales contra infraestructuras críticas.

Mecanismo técnico del sabotaje

Según el informe del equipo Threat Hunter Team, fast16 intercepta de forma selectiva los cálculos dentro de dos aplicaciones de ingeniería: LS-DYNA y AUTODYN. Ambos paquetes se utilizan ampliamente para modelar procesos físicos reales: desde pruebas de choque de automóviles hasta simulaciones de detonación de explosivos.

La característica clave del malware es su activación altamente selectiva. Los investigadores señalan que fast16 comprueba la densidad del material modelado y se activa solo cuando se supera el umbral de 30 g/cm³, un valor que el uranio alcanza exclusivamente bajo compresión por impacto en un dispositivo de implosión. De este modo, el malware ignora los cálculos de ingeniería rutinarios y se activa únicamente durante simulaciones a gran escala de detonaciones.

La arquitectura de fast16 incluye 101 reglas de interceptación (hook rules), organizadas en 9–10 grupos. Cada grupo está orientado a un ensamblado concreto de LS-DYNA o AUTODYN, lo que, según la evaluación de los investigadores, indica un mantenimiento metódico: los desarrolladores seguían las actualizaciones del software objetivo y adaptaban el malware a las nuevas versiones.

Los investigadores destacan tres estrategias de ataque implementadas mediante estos interceptores:

• La distorsión se activa solo durante cálculos transitorios a gran escala de explosiones y detonaciones
• El malware se propaga automáticamente a otros nodos de la misma red, garantizando resultados distorsionados idénticos en cualquier máquina que ejecute simulaciones
• Fast16 evita infectar ordenadores que tengan instaladas determinadas soluciones de seguridad

Resulta llamativo un detalle descubierto al analizar la secuencia de grupos de reglas: según los investigadores, algunos grupos destinados a versiones más antiguas del software fueron añadidos después de los grupos para versiones más recientes. Esto podría indicar que el usuario del software de simulación, al encontrarse con anomalías, revertía a una versión anterior, que entonces también pasaba a convertirse en objetivo.

Contexto y atribución

Previamente, la empresa SentinelOne describió fast16 como el primer framework de sabotaje conocido cuyos componentes, presumiblemente, podrían haberse desarrollado ya en 2005, dos años antes de la versión más antigua conocida de Stuxnet (Stuxnet 0.5). Cabe señalar que esta datación no está respaldada por fuentes primarias independientes y se basa en las conclusiones analíticas de los investigadores.

Entre las pruebas indirectas figura la mención de la cadena «fast16» en un archivo de texto publicado por el grupo de hackers The Shadow Brokers en 2017. Este archivo formaba parte de un conjunto de herramientas que, supuestamente, eran utilizadas por el grupo Equation Group. Sin embargo, en el material disponible no hay fuentes primarias que respalden esta afirmación, por lo que esta relación debe tratarse con cautela.

Como informó la periodista Kim Zetter, el director técnico de Symantec, Vikram Thakur, calificó el nivel de pericia necesario para crear un malware de este tipo en 2005 como «asombroso». Los investigadores subrayan que para desarrollar fast16 se requería un conocimiento profundo de las ecuaciones de estado, de los convenios de llamadas generados por compiladores concretos y de la lógica de clasificación de las simulaciones, un conjunto de conocimientos poco común en cualquier época y excepcional para 2005.

Evaluación del impacto

Symantec y Carbon Black sitúan fast16 en la misma línea conceptual que Stuxnet: ambos tipos de malware fueron adaptados no solo a un producto de un fabricante concreto, sino a un proceso físico específico modelado o controlado por dicho producto. La diferencia es que Stuxnet actuaba sobre equipos físicos (centrífugas para el enriquecimiento de uranio en Natanz a través de controladores Siemens), mientras que fast16 distorsionaba los resultados de los cálculos, con el potencial de invalidar ciclos completos de investigación.

Las consecuencias de un sabotaje de este tipo son especialmente insidiosas: a diferencia de los ataques destructivos, la distorsión de simulaciones puede pasar desapercibida durante largo tiempo, minando la confianza en los resultados de investigación y llevando a tomar decisiones de diseño erróneas.

Al mismo tiempo, según los datos disponibles, se desconoce si existe una versión moderna de fast16.

Recomendaciones

Aunque fast16 forma parte de un arsenal histórico, los principios de funcionamiento identificados son relevantes para la protección de entornos de investigación e ingeniería modernos:

• Control de la integridad de los cálculos: las organizaciones que utilicen LS-DYNA, AUTODYN y software de simulación similar deben implantar mecanismos de verificación de resultados, como comprobaciones cruzadas en sistemas aislados con compilaciones distintas
• Segmentación de la red: los equipos destinados a simulaciones críticas deben aislarse de la infraestructura de red general, teniendo en cuenta la capacidad de fast16 para propagarse automáticamente por la red
• Supervisión de modificaciones: control de la integridad de los archivos ejecutables del software de simulación y supervisión de interceptores (hooks) no autorizados en los procesos de modelado
• Auditoría de versiones: documentación y control de todas las versiones de software de ingeniería utilizadas, dado que fast16 muestra un patrón de adaptación a los retrocesos a versiones anteriores

El análisis de fast16 demuestra que el sabotaje estratégico de procesos de cálculo no es una amenaza teórica, sino una práctica documentada con veinte años de historia. Las organizaciones que trabajen con simulaciones críticas en los sectores de defensa, nuclear y aeroespacial deberían revisar sus modelos de amenazas teniendo en cuenta los ataques dirigidos a la integridad de los resultados de modelado, y no solo a la disponibilidad o la confidencialidad de los datos.