Stuxnet reconstruido en GitHub: el código del primer ciberarma

Por qué hay código de Stuxnet en GitHub en 2026

Un repositorio público en GitHub, mantenido por el usuario Sadpainy, acaba de publicar una reconstrucción del código fuente de Stuxnet derivada del trabajo de ingeniería inversa que la comunidad de seguridad global realizó sobre los binarios originales descubiertos en 2010. El proyecto se distribuye bajo GPL v3.0 y se presenta como una pieza exclusivamente académica: sirve para entrenar análisis de malware, escribir firmas de detección y estudiar la intersección entre ciberseguridad e infraestructura crítica.

El repositorio no es Stuxnet ejecutable. Como aclara su propio README, el código "preserva la lógica y los vectores de ataque originales mientras estructura el codebase para ser legible y analizado". Es, en esencia, un mapa abierto de uno de los ataques más estudiados de la historia.

¿Qué reconstruyó el repositorio?

La reconstrucción divide Stuxnet en módulos funcionales tal como los identificaron los analistas de Symantec, Kaspersky Lab y ESET. Cada archivo corresponde a un componente del gusano original:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Loader/Dropper (winsta.exe, ~WTR4141.tmp): punto de entrada, escalada de privilegios y despliegue del resto del malware.
Escalada de privilegios (~WTR4132.tmp): explota una vulnerabilidad en Win32k.sys para obtener permisos de sistema.
Hook de S7 (s7otbxdx.dll): reemplaza la DLL legítima s7otbxsx.dll para interceptar la comunicación entre Step 7 y el PLC.
Hook de Step 7 (s7aaapix.dll): intercepta llamadas API de la herramienta de ingeniería.
Rootkit de sistema de archivos (mrxcls.sys): driver en modo kernel que oculta archivos, procesos y claves de registro mediante SSDT hooking.
Rootkit de red (mrxnet.sys): filtra peticiones del sistema de archivos y habilita la propagación P2P.
Payload de ataque (s7plcmain): la lógica central que manipula los bloques OB1/OB35 del PLC para alterar la frecuencia de los variadores.

El flujo de ejecución documentado en el repo replica las 12 fases del gusano original: infección inicial por USB o red, dropper y escalada, reconocimiento del entorno, instalación de hooks si detecta software Siemens, monitorización de escritura de bloques, inyección del payload y, finalmente, sabotaje físico de las centrifugadoras.

Por qué Stuxnet cambió las reglas del juego

Stuxnet no fue el primer ataque a sistemas industriales, pero sí el primer malware conocido que saboteó físicamente equipos industriales reprogramando controladores lógicos programables (PLC). El gusano fue detectado el 17 de junio de 2010 por la empresa bielorrusa VirusBlokAda, según documenta Wikipedia.

Sus características técnicas lo convirtieron en una rareza incluso hoy:

Tamaño aproximado de 500 KB (inusualmente grande para malware).
Escrito en varios lenguajes, incluyendo C y C++.
Explotaba cuatro zero-days de Windows simultáneamente, un hecho sin precedentes.
Se propagaba por USB (vulnerabilidad LNK), por compartición de impresoras en red y por P2P entre sistemas aislados.
Incorporaba el primer rootkit documentado para PLCs Siemens S7-300/400.

Según datos de Symantec citados por Wikipedia, aproximadamente el 58,9% de los equipos infectados estaban en Irán. El Instituto para la Ciencia y la Seguridad Internacional (ISIS) estimó que Stuxnet destruyó alrededor de 1.000 centrifugadoras (el 10% del inventario de Natanz) entre noviembre de 2009 y enero de 2010. The Washington Post reportó que cámaras de la IAEA instaladas en Natanz registraron el desmantelamiento de entre 900 y 1.000 centrifugadoras durante el período activo del gusano.

Stuxnet fue el producto de Operation Olympic Games, un programa conjunto de Estados Unidos e Israel iniciado bajo el gobierno de George W. Bush y acelerado por Barack Obama, según reportó The New York Times en junio de 2012. En julio de 2013, Edward Snowden confirmó la autoría conjunta desde Spiegel. Los ingenieros iraníes, según Reuters, terminaron por neutralizar y limpiar el malware de sus sistemas hacia 2012, y la capacidad de enriquecimiento nuclear iraní se recuperó e incluso mejoró durante 2010, según un análisis de la Federation of American Scientists.

Cómo se estudia Stuxnet hoy (sin tocar infraestructura real)

El repositorio de Sadpainy ofrece instrucciones de compilación solo para entornos de análisis estático en máquinas virtuales aisladas. El README recomienda explícitamente:

Entorno: VMware o VirtualBox con red Host-Only y sin conectividad a Internet.
Stack de análisis: IDA Pro, Ghidra o x64dbg para abrir las DLL y drivers.
Monitorización: Process Monitor, Process Hacker y Wireshark para observar el comportamiento.

El proyecto no compila contra versiones modernas de Windows. El target es Windows XP o Windows 7 y, para los drivers, el Windows Driver Kit 7600. Esa es la pista que confirma que el repositorio sirve solo como material de estudio del binario original, no como base para nuevos ataques.

Por qué importa para tu startup

Stuxnet dejó tres lecciones que cualquier founder de ciberseguridad, OT, IA industrial o infraestructura crítica debería tener en el playbook:

El código de los ataques viejos nunca muere, solo cambia de manos. Reuters reportó en mayo de 2015 que la NSA intentó una variante de Stuxnet contra el programa nuclear norcoreano y falló por la falta de puntos de entrada físicos. Lo que se filtra hoy se convierte en vector de ataque mañana.
La superficie OT es el eslabón débil. El reporte inaugural de InfraTrust Pulse de Eclypsium, publicado en julio de 2026, rastreó 61 advisories de infraestructura de 14 vendors; 26 vulnerabilidades eran explotables de forma remota sin autenticación, y varias afectaban appliances de borde (SonicWall SMA1000, Fortinet FortiSandbox, F5 BIG-IP) que en una planta industrial son puertas directas al SCADA.
El talento en reversing escasea. Roel Schouwenberg, investigador senior de Kaspersky Lab, estimó en 2013 que un equipo de 10 personas durante 2 a 3 años fue necesario para construir Stuxnet. Hoy los equipos rojos de red team que dominan ingeniería inversa de binarios en C/C++ sobre Windows nativo siguen siendo escasos. Esa es una oportunidad de nicho si tu startup quiere competir en ciberseguridad ofensiva/defensiva.

¿Qué significa esto para tu startup?

Si construyes software para infraestructura crítica: audita tu cadena de suministro de dependencias nativas y firmware antes que tu próximo cliente industrial. La superficie de ataque en OT crece más rápido que los parches.
Si montas un equipo de seguridad defensiva: capacita a tu gente en reversing con proyectos como este, en sandboxes aislados. La capacidad de leer lo que hizo Stuxnet en sus hooks y drivers es el mismo skillset que detecta una APT nueva.
Si vendes IA o no-code para el sector industrial: entiende que tus clientes regulados (energía, salud, manufactura) viven bajo el mismo modelo de amenaza que Natanz en 2009. El "demo en una planta" puede terminar como una nota de prensa.

Conclusión

Stuxnet sigue siendo el caso de estudio canónico de la ciberseguridad industrial, y un repositorio GPL que reconstruye su código es, sobre todo, una invitación a estudiarlo con lupa. Para los founders hispanohablantes que están construyendo productos en seguridad, IA industrial o infraestructura crítica, la pregunta no es si alguien va a reutilizar esta lógica: ya lo están haciendo. La pregunta es si tu equipo sabe detectarla antes de que aparezca en tu red.