La guerra en el tercer milenio se libra también en el Ciberespacio, que se ha convertido en el quinto espacio de guerra. Cada vez más, los estados utilizan armas cibernéticas para atacar sistemas e infraestructuras estratégicas en otros países.
Ciberguerra: la guerra se libra en el quinto espacio de guerra
El ataque de Rusia contra Ucrania ha llevado la Ciberguerra, es decir, la guerra cibernética entre estados, a la atención del mundo.
En realidad, estos ataques se vienen registrando desde hace años y en algunos casos simplemente no sabíamos de ellos porque, como veremos, una de las prerrogativas de la ciberguerra es la de complicar la atribución del ataque a un determinado hacker o grupo de hackers, ya que es fácil para el atacante ocultar sus huellas.
Esta guerra, llamada “ciberguerra”, se libra de forma no declarada y oculta, no en los espacios de guerra tradicionales (tierra, mar, cielo), sino en el “ciberespacio”. Y son los propios estados quienes la libran, a través de grupos dedicados que muchos de los principales estados del mundo han creado además de los ejércitos tradicionales.
Protección DNS de nueva generación: totalmente basada en la nube, potenciada por IA y de fácil activación
¿Cuál es el objetivo principal de la Ciberguerra?
Antes de contar algunos de los famosos casos de ciberguerra, es importante entender qué es la ciberguerra y cuáles son las razones que hacen que este tipo de ataques resulten convenientes.
A continuación, la definición de ciberguerra recogida en el “Glosario de Inteligencia” del sistema italiano para la Información y la Seguridad de la República (SISR):
“El conjunto de operaciones militares llevadas a cabo en y a través del ciberespacio con el fin de causar daño al enemigo, ya sea un estado u otro, y que consisten, entre otras cosas, en impedir que el enemigo haga un uso efectivo de sistemas, armas y herramientas informáticas, así como de las infraestructuras y procesos que estos controlan. El significado también incluye actividades de defensa y aquellas destinadas a garantizar la disponibilidad y el uso del ciberespacio al estado”.
A este respecto, sugerimos también consultar el Manual de TALLIN (actualizado a la versión 3.0 en 2021) del Centro de Excelencia para la Cooperación en Ciberdefensa (CCDCOE) de la OTAN.
El Manual de Tallin original (publicado por primera vez en 2013 por Cambridge University Press) analiza la aplicabilidad de los principios existentes del derecho internacional al ciberespacio, tanto en tiempos de paz como de guerra.
Se trata de la interpretación y aplicabilidad del derecho internacional en el contexto cibernético.
Analiza las normas del derecho internacional que rigen los incidentes cibernéticos entre estados, pero que están por debajo del umbral que desencadenaría el uso de la fuerza o el conflicto armado.
Las armas cibernéticas se utilizan cada vez más, ya que funcionan bien y resultan convenientes para quienes las emplean.
Y, a diferencia de sus contrapartes analógicas, es decir, las formas de guerra tradicional:
- No ponen en riesgo sus fuerzas.
- Causan menos daños colaterales.
- Pueden desplegarse de forma oculta e incluso es posible ocultar las técnicas de ataque: de esta manera es difícil atribuir la responsabilidad del ataque.
- Son menos costosas.
Ahora veremos algunos ataques de ciberguerra, aquellos que conocemos (no siempre es así por las razones que acabamos de exponer).
El ataque Stuxnet: el caso más famoso
Stuxnet representa un punto de inflexión en la ciberguerra.
Se remonta a 2010, pero aún hoy se considera un caso de estudio ejemplar, tanto por la forma en que se llevó a cabo como por los efectos que provocó en la ciberguerra a nivel mundial.
Stuxnet puede considerarse una “paradoja de la historia”, ya que, como veremos, tenía como objetivo contrarrestar la proliferación de armas nucleares, pero en realidad terminó abriendo la puerta a una proliferación mucho más difícil de controlar: la proliferación de tecnología en armas cibernéticas.
En enero de 2010, en la planta nuclear de Natanz, en Irán, las centrifugadoras utilizadas para enriquecer Uranio235 se volvieron locas y se descontrolaron: pasaron de 1.064 revoluciones por minuto a 1.410 revoluciones por minuto y explotaron. Esto dejó fuera de servicio al menos 1.000 de las 5.000 centrifugadoras y retrasó el programa nuclear iraní un par de años.
¿Qué sucedió?
Retrocedamos en el tiempo hasta 2006, cuando el programa nuclear iraní ya era preocupante para Estados Unidos e Israel. El presidente Bush dio la orden secreta de preparar un ciberataque contra las plantas iraníes para dañar su programa atómico sin desencadenar una guerra convencional. Esta operación, bajo el nombre en clave “Juegos Olímpicos”, fue continuada y concluida posteriormente durante la presidencia de Barack Obama.
El ataque fue asignado a expertos estadounidenses de la Agencia de Seguridad Nacional (NSA), en colaboración con técnicos informáticos israelíes, la legendaria Unidad 8200 de las Fuerzas de Defensa de Israel (IDF).
Se creó un malware mortal, llamado Stuxnet, que era capaz de actuar sobre el PLC Siemens Simatic S7-300, que gobernaba el funcionamiento de las centrifugadoras para el enriquecimiento de uranio. Las centrifugadoras de la planta industrial de Natanz eran del tipo P-1 y se basaban en proyectos antiguos que el gobierno iraní había comprado a Pakistán.
Estas centrifugadoras trataban hexafluoruro de uranio en forma de gas, separando el Uranio-235 (el que puede sufrir fisión nuclear y, por tanto, puede utilizarse para construir bombas atómicas) del isótopo U-238 (mucho más abundante en la naturaleza, pero menos útil). El proceso de enriquecimiento de uranio tiene como objetivo aumentar la concentración de U-235: un enriquecimiento bajo (20%) permite utilizar el uranio como combustible en reactores nucleares, mientras que para producir una bomba atómica es necesario alcanzar una concentración de U-235 de al menos el 85%.
La primera versión del software Stuxnet fue creada, según Kaspersky, en junio de 2009, pero no produjo los resultados esperados. El ataque final fue llevado a cabo por la versión 2.0 de Stuxnet en los primeros meses de 2010.
Protección DNS de nueva generación: totalmente basada en la nube, potenciada por IA y de fácil activación

Imagen 1 – El presidente iraní Mahmoud Ahmadinejad observa las centrifugadoras dentro de la planta de enriquecimiento de uranio en Natanz
¿Cómo entró Stuxnet en la planta de Natanz?
Por supuesto, los iraníes no eran tan ingenuos como para publicar los detalles de su planta en línea.
La planta estaba en realidad “aislada del aire” (air gapped), es decir, aislada de la red de Internet.
El problema para los atacantes era, por lo tanto, poder inyectar el malware en Natanz.
A estas alturas es casi seguro que el comienzo del contagio por Stuxnet ocurrió dentro de la propia planta, a través de uno o más dispositivos USB.
Se considera, con razonable certeza, que la infección por Stuxnet comenzó a partir de cinco proveedores iraníes utilizados como vehículos para el ataque, con una técnica llamada Ataque a la Cadena de Suministro, que hoy en día es extremadamente frecuente.
Estas empresas no eran conscientes de haber sido atacadas y, una vez infectadas, era solo cuestión de tiempo antes de que la planta de Natanz fuera afectada. A través de un dispositivo USB insertado en varios ordenadores dentro de Natanz, la infección se propagó desde los ordenadores con Windows al software industrial Step7 (creado por Siemens), que controlaba los PLC de la planta y podía modificar su código.
Más adelante veremos cómo todo esto fue posible gracias a la explotación de una serie de vulnerabilidades de día cero por parte de Stuxnet.
Los analistas que examinaron Stuxnet, a través del análisis de miles de archivos, creen haber identificado las cinco empresas iraníes que fueron infectadas por Stuxnet – en distintos momentos a partir de junio de 2009 – y que luego lo introdujeron en Natanz.
De nuevo en 2010, versiones posteriores de Stuxnet golpearon a otras cinco organizaciones iraníes con el objetivo de controlar y dañar la producción iraní de uranio enriquecido. Más del 60% de los ordenadores infectados por Stuxnet en 2010 se encontraban en Irán.
Tras la infección del virus en la planta de Natanz, Stuxnet se propagó fuera de la planta iraní.
Parece que fue Israel quien quiso reforzar el virus para hacerlo más agresivo y capaz de propagarse con mayor facilidad (¡de hecho, versión 2.0!)
Quizás demasiado: se considera que un ordenador que había sido infectado en Natanz propagó luego el malware fuera de los sistemas afectados, causando importantes daños a otras redes que utilizaban el PLC Siemens Simatic y que no se suponía que estuvieran en absoluto entre los objetivos.
Stuxnet nunca debería haber salido de Natanz, pero en cambio, al salirse de control, comenzó a propagarse por Internet. A Obama le dijeron: “Perdimos el control sobre el virus”.
Descubierto, detectado y analizado ya por las principales empresas de ciberseguridad (Kaspersky, F-Secure, Symantec en su informe “W32.Stuxnet Dossier Version 1.4 February 2011”), Stuxnet fue considerado de inmediato un malware “anómalo”, demasiado sofisticado para haber sido creado por hackers normales.
De hecho, explotaba no una, sino nada menos que cuatro vulnerabilidades de día cero, es decir, vulnerabilidades aún no conocidas por las empresas de seguridad. Los exploits de día cero son muy difíciles de encontrar y tienen un coste muy elevado en el mercado de vulnerabilidades.
En aquella época, nunca se había dado el caso de un malware que explotara más de una vulnerabilidad de día cero. ¡Y Stuxnet explotó nada menos que cuatro!
Solo un Estado podría haber creado un arma cibernética tan poderosa….
Las sospechas se centraron de inmediato en los servicios de inteligencia estadounidenses e israelíes, los únicos capaces de producir un software con estas características.
“La NSA e Israel escribieron Stuxnet juntos”: en julio de 2013 Edward Snowden confirmó que Stuxnet había sido diseñado por la NSA con la colaboración de la inteligencia israelí a través de un equipo especial conocido como Foreign Affairs Directorate.
Nadie ha reivindicado nunca el ataque ni ha puesto su firma en Stuxnet. Pero en realidad quizás esta “firma” exista de verdad.
Cuando los analistas seccionaron el código de Stuxnet encontraron distintas funciones. Entre ellas está la función número 16, que contiene una variable cuyo valor es 19790509. Dado que a esta variable, utilizada puramente para control, se le podía asignar cualquier valor, ¿por qué precisamente ese número?
Alguien descubrió que 19790509 corresponde a la fecha del 9 de mayo de 1979, que tiene un significado muy preciso tanto para Irán como para Israel: ese día, en una plaza de Teherán, fue ejecutado Habib Elghanian. Era el jefe de la comunidad judía iraní. Fue una de las primeras ejecuciones de personas judías por parte del nuevo régimen de Jomeini en Irán.
No solo eso: en ese período había instaladas algunas centrifugadoras del tipo P-1 (como las de Natanz), casualmente, en la planta israelí de Dimona, en el desierto del Néguev: demasiado pocas para fines productivos, pero suficientes para realizar algunas pruebas en una planta piloto. Habían sido suministradas a Israel por Estados Unidos, que las había recuperado del programa nuclear libio.
Este caso, a pesar de haber sido analizado ya con el máximo nivel de detalle, todavía presenta algunos aspectos poco conocidos, que hacen que parezca una inquietante película de guerra o de espionaje.
Y, de hecho, la película existe de verdad: el ataque de Stuxnet fue narrado en el documental “Zero Days” (2016) del productor ganador de un Oscar Alex Gibney.

Imagen 2 – El cartel del documental “Zero Days” (2016) del productor Alex Gibney (imagen de nientepopcorn.it)
2012: Shamoon contra Saudi Aramco
Saudi Aramco es la empresa pública saudí de producción petrolera, la más grande del mundo.
En agosto de 2012, a las 11:08 hora local del día 15 de ese mes, los empleados de la empresa notaron que algunos archivos de sus portátiles se estaban cancelando ante sus ojos.
En pocas horas, Saudi Aramco ya no estaba en línea.
Aún más devastadoras fueron las consecuencias para los pagos, para los cuales la red es ya esencial: kilómetros de camiones cisterna llenos de petróleo y bloqueados, por la simple razón de que no había forma de facturar su contenido. Solo los sistemas de extracción, completamente automatizados e independientes de Internet, siguieron funcionando.
La causa del problema fue descubierta por Seculert: el malware se llamó primero Disttrack y luego tomó el nombre de Shamoon.
Una vez más, la inyección tuvo lugar a través de un simple correo de spear phishing, que transportaba el nuevo malware.
Shamoon tenía una alta capacidad de replicarse y propagarse y era capaz de transferir archivos del ordenador de la víctima al del atacante y luego cancelarlos del sistema original. Como la mayoría de estos programas, era un malware modular compuesto por tres módulos:
- Shamoon Dropper: el módulo utilizado para entrar dentro del sistema atacado y soltar los otros dos componentes.
- Shamoon Wiper: el componente que borraba, o sea destruía, los contenidos instalando un controlador capaz de sobrescribir los datos y que lograba escribir en el Master Boot Record (MBR) del ordenador, dejándolo así inutilizable.
- Shamoon Reporter: que informaba al atacante de toda la información sobre los archivos que habían sido sobrescritos.
Saudi Aramco tardó 10 días (hasta el 25 de agosto) en restaurar los más de 30.000 sistemas basados en Windows que habían sido sobrescritos por Shamoon.
¿Quién fue el autor de semejante ataque?
El ataque fue reivindicado por “Cutting Sword of Justice”, un grupo hacker islámico que exigía mejores condiciones laborales para los empleados de Saudi Aramco.
Es posible, aunque no hay pruebas certeras, que las plantas petroleras saudíes fueran atacadas por hackers iraníes patrocinados por el Estado, quizás el grupo Elfin (también conocido como: APT33, HOLMIUM). Este grupo iraní es famoso por haber atacado a organizaciones de diversos sectores de Estados Unidos, Arabia Saudí y Corea del Sur, con especial interés en los sectores de la aviación y la energía, y especialmente en las plantas petroleras.
Fuera quien fuera, se trató de un ciberataque perfecto desde el punto de vista técnico y, sobre todo, por su capacidad de golpear un recurso económico mundial: el petróleo. El caso confirma que los ataques a sistemas industriales prefieren el sector energético.
Según Symantec, Shamoon regresó de repente en noviembre de 2016 y luego se volvió a utilizar en un ataque el 23 de enero de 2017. Se lo llamó Shamoon 2.
Protección DNS de nueva generación: totalmente basada en la nube, potenciada por IA y de fácil activación
Rusia contra Ucrania
Desde los albores de los tiempos, Rusia ha utilizado a Ucrania como su objetivo favorito para los ciberataques.
Aquí no nos centraremos en la actualidad sobre la reciente invasión militar rusa, también porque la información sobre los últimos ataques todavía no es clara.
Nos centraremos, en cambio, en los casos de guerra cibernética que ya han hecho historia y sobre los cuales los analistas pudieron recabar mucha información.
BlackEnergy en Ucrania
Aunque no causó daños importantes, este fue un ataque de manual.
23 de diciembre de 2015, 15:35 h: la empresa ucraniana Kyivoblenergo, un proveedor regional de electricidad, fue atacada por un hacker. En un corto lapso de tiempo, los sistemas de al menos 3 operadores eléctricos regionales fueron afectados.
7 subestaciones de 100kV y 23 de 35 kV quedaron desconectadas durante más de tres horas. La mitad de las casas de la región de Ivano-Frankivsk (en el oeste de Ucrania) se quedaron sin electricidad. Se estima que unas 225.000 personas se vieron afectadas.
El ataque, procedente de un país extranjero, toma el control de forma remota de los sistemas SCADA (Supervisory Control and Data Acquisition) de las plantas. Para restablecer la normalidad del servicio, los gestores tuvieron que pasar al control manual de las plantas.
El agente utilizado fue el troyano BlackEnergy, con funciones de backdoor.
Se trata de un malware modular que puede descargar varios componentes para completar actividades específicas. En 2014 fue utilizado para varios ataques de ciberespionaje dirigidos a objetivos de alto perfil vinculados al gobierno ucraniano.
Según el informe detallado preparado por E-ISAC y SANS “Analysis of the Cyber Attack on the Ukrainian Power Grid” (18 de marzo de 2016), los atacantes demostraron que conocían y podían explotar una amplia gama de técnicas para llevar a cabo la acción ofensiva:
- El uso de correos electrónicos de spear phishing para acceder a las redes de las tres empresas proveedoras (y aquí tenemos, como en casi cualquier ataque, el factor H, es decir, el error humano). Parece que el correo del ataque incluía como archivo adjunto un documento de Office “armado” con una macro.
- La inyección de la variante de malware BlackEnergy 3 en cada uno de los proveedores afectados, utilizada en combinación con el nuevo plug-in KillDisk (Win32/KillDisk), que tiene la capacidad de destruir archivos y puede sobrescribir más de 4.000 tipos de archivos, y por lo tanto es capaz de sobrescribir el sistema operativo y bloquear un sistema entero.
- El robo de credenciales de acceso a las redes de las empresas.
- El uso de Redes Privadas Virtuales (VPN) para acceder a la red ICS.
- La manipulación de documentos de Microsoft Office que incluían malware para acceder a las redes informáticas de las empresas eléctricas.
- La capacidad de tomar el control de los sistemas SAI (UPS) con el fin de generar una interrupción del servicio: en al menos uno de los proveedores afectados, los atacantes descubrieron una red conectada a un SAI y la reconfiguraron de manera que, cuando se produjo el corte de energía, también se produjo un corte en el suministro eléctrico a los edificios y centros de datos de la empresa eléctrica.
Por lo tanto, se trató de un ataque coral, bien diseñado y llevado a cabo por especialistas.
Los servicios secretos ucranianos condenaron a Rusia de inmediato por el ataque, también debido a las muy malas relaciones entre los dos países (poco antes había tenido lugar la anexión de Crimea por parte de Rusia).
En particular, se considera que el ataque fue llevado a cabo por el Sandworm Team, también conocido como Unidad 74455, que es una unidad cibermilitar rusa vinculada al GRU, los servicios secretos de las fuerzas armadas rusas.
Se sospecha que Sandworm también está detrás de los ciberataques de 2017 contra Ucrania con NotPetya y detrás del ciberataque a los Juegos Olímpicos de invierno en Corea del Sur en 2018.
En diciembre de 2016 el ataque fue reiterado, con un impacto más leve en comparación con el de 2015 y un apagón que duró aproximadamente una hora. Parece que fue llevado a cabo por los mismos atacantes del año anterior, no para causar daños sino más bien como una prueba para futuras acciones.

Imagen 3 – El archivo adjunto de Office con la macro adjunta al correo de spear-phishing que vehiculó la inyección de BlackEnergy
27 de junio de 2017: ataque NotPetya
Se considera que NotPetya es el ciberataque que ha creado los mayores daños en el mundo: se estima que el impacto en las organizaciones afectadas costó alrededor de 10.000 millones de dólares.
Es un clásico ataque a la cadena de suministro (Supply Chain): tuvo como objetivo a una empresa ucraniana (M.E.doc), que produce software de gestión. A través de esta empresa, las empresas ucranianas se vieron gravemente afectadas, hasta el punto de que en 24 horas NotPetya eliminó el 10% de todos los ordenadores de Ucrania.
Por primera vez en 31 años, los detectores de radiación de Chernóbil fueron apagados, lo que obligó a los empleados a monitorear los niveles de radiación manualmente.
Desde Ucrania, NotPetya se extendió al resto del mundo, causando enormes daños a varias grandes empresas, entre las que se encontraban:
- Moller-Maersk: daños por 300 millones de dólares, y la empresa tuvo que reinstalar 4.000 servidores y 45.000 portátiles.
- TNT Express (grupo FedEx): daños por 300 millones de dólares.
- Mondelēz International: 1.700 servidores y 24.000 portátiles bloqueados (daños por más de 84 millones de dólares).
- Merck (farmacéutica): interrupción de operaciones a nivel global.
- Saint Gobain Group.
- Reckitt Benckiser: menores ventas por unos 110 millones de libras.
Italia fue uno de los países más afectados.
NotPetya era un ransomware que pedía un rescate de 300 dólares (0,138 bitcoin), pero en realidad resultó ser un wiper, ya que los archivos nunca fueron devueltos.
Explotó el exploit Eternalblue creado por la NSA para propagarse a través de las redes de las empresas, el mismo que había sido utilizado un mes antes para el infame ataque WannaCry (12 de mayo de 2017).
Estados Unidos y Gran Bretaña han culpado oficialmente a Rusia por el ataque NotPetya, y también en este caso se considera que fue llevado a cabo por el Sandworm Team, vinculado al GRU, los servicios secretos militares rusos.
Protección DNS de nueva generación: totalmente basada en la nube, potenciada por IA y de fácil activación
El Autor
Giorgio Sbaraglia, ingeniero, es consultor y formador en temas de ciberseguridad y privacidad.
Imparte cursos de formación sobre estos temas para numerosas empresas italianas importantes, incluyendo ABIFormazione y la 24Ore Business School.
Es el coordinador científico del Máster “Cybersecurity and Data Protection” de la 24Ore Business school.
Es miembro del Comité Científico CLUSIT (Asociación Italiana para la Ciberseguridad) y Innovation Manager certificado por RINA.
Ocupa cargos de DPO (Delegado de Protección de Datos) en empresas y colegios profesionales.
Es autor de los siguientes libros:
- “GDPR kit di sopravvivenza” – “Kit de supervivencia del RGPD” (Editado por goWare)
- “Cybersecurity kit di sopravvivenza. Il web è un luogo pericoloso. Dobbiamo difenderci!” – “Kit de supervivencia de ciberseguridad. La web es un lugar peligroso. ¡Debemos defendernos!” (Editado por goWare)
- “iPhone. Come usarlo al meglio. Scopriamo insieme tutte le funzioni e le app migliori” – “iPhone. Cómo aprovecharlo al máximo. Descubramos juntos todas las funciones y las mejores apps” (Editado por goWare)
Colabora con CYBERSECURITY360, una revista online especializada del grupo Digital360 centrada en la ciberseguridad.
También escribe para ICT Security Magazine, para Agenda Digitale y para la revista CLASS.
Puedes activar la protección FlashStart® Cloud en cualquier tipo de router y firewall para proteger dispositivos de escritorio, móviles y dispositivos IoT en redes locales.

