De Morris a Stuxnet:
la historia de los gusanos y qué cambió cada uno
Cultura y contexto | unfantasmaenelsistema.com
Un gusano informático es, en esencia, un programa que se copia a sí mismo de una máquina a otra sin que nadie tenga que abrir un archivo ni pulsar nada. Esa diferencia con el virus clásico —que necesita que alguien lo ejecute— es la que ha convertido a los gusanos en los incidentes de mayor alcance de las últimas cuatro décadas: cuando uno bien hecho se suelta, no se propaga en días, se propaga en minutos, y para cuando alguien entiende qué está pasando ya está en medio mundo.
La historia de la seguridad informática se puede contar casi entera a través de sus grandes gusanos. Cada oleada dejó una lección concreta —y una institución, una práctica o una ley nueva— que hoy damos por sentada. Este es un recorrido por los que marcaron un antes y un después, y por lo que cada uno nos obligó a aprender.
Qué aprenderás en este artículo
Qué distingue a un gusano de un virus y de un troyano · Cómo el gusano de Morris (1988) hizo nacer el primer CERT · Por qué ILOVEYOU, Code Red y Slammer fueron un problema de parches y de correo, no de genialidad técnica · Cómo Conficker profesionalizó las botnets y cómo Stuxnet llevó el malware al mundo físico · Qué cambió con WannaCry y NotPetya, y las lecciones que se repiten en cada ola
1. Gusano, virus, troyano: no son lo mismo
Los tres términos se usan como sinónimos y no lo son. Un virus se adhiere a un archivo o programa legítimo y solo actúa cuando la víctima lo ejecuta. Un troyano se hace pasar por algo inofensivo para que la víctima lo instale por su propia mano. Un gusano no necesita ninguna de las dos cosas: explota un fallo en un servicio de red o abusa de una libreta de direcciones para saltar solo de un sistema al siguiente.
Esa autonomía es la que dispara el alcance. Un gusano que tarda tres segundos en infectar una máquina y buscar la siguiente crece de forma exponencial: la curva de infección de los casos más rápidos que veremos aquí se mide en decenas de minutos hasta la saturación global. Lo demás —robar datos, cifrar discos, sabotear un proceso industrial— es la carga útil que el gusano transporta; la propagación es el motor.
2. Morris, 1988: el gusano que apagó internet (y creó el CERT)
El 2 de noviembre de 1988, Robert Tappan Morris, estudiante de posgrado en Cornell, soltó desde el MIT un programa experimental que pretendía medir el tamaño de ARPANET. Un error de diseño lo convirtió en un desastre: el gusano reinfectaba máquinas ya comprometidas una y otra vez, y cada copia consumía recursos hasta dejar los sistemas inutilizables. En pocas horas había tumbado una fracción considerable de las aproximadamente 60.000 máquinas que entonces formaban internet.
Morris explotó una combinación que resultaría clásica: un desbordamiento en el servicio finger, una puerta trasera de depuración en sendmail y contraseñas débiles adivinadas por diccionario. Fue la primera persona condenada bajo la Computer Fraud and Abuse Act estadounidense. Pero la consecuencia duradera fue institucional: a los pocos días, DARPA financió en la Universidad Carnegie Mellon la creación del CERT/CC, el primer equipo de respuesta a incidentes. El modelo —un punto central que coordina información sobre vulnerabilidades y ataques— se replicó por todo el mundo y es el origen directo de los CERT y CSIRT nacionales de hoy, INCIBE-CERT incluido.
La lección de Morris
Un fallo de software combinado con propagación automática es un problema colectivo, no de cada administrador por separado. Hacía falta alguien coordinando la respuesta: así nacieron los CERT
3. ILOVEYOU, 2000: la ingeniería social a escala planetaria
El 4 de mayo de 2000, millones de personas recibieron un correo con el asunto «ILOVEYOU» y un adjunto llamado «LOVE-LETTER-FOR-YOU.TXT.vbs». Windows ocultaba por defecto la extensión real, así que el archivo parecía un inofensivo .txt. Quien lo abría ejecutaba un script en Visual Basic que sobrescribía ficheros locales y, sobre todo, se reenviaba a toda la libreta de direcciones de Outlook.
El resultado: unos 45 millones de equipos afectados en pocos días y daños estimados en miles de millones de dólares, con parlamentos y multinacionales apagando sus servidores de correo para frenar la avalancha. Técnicamente era trivial. Su fuerza estaba en el sobre: un asunto irresistible, un remitente conocido (la última víctima) y un sistema operativo que ayudaba a esconder el engaño. Los autores, en Filipinas, quedaron impunes porque el país no tenía entonces ninguna ley que cubriera el hecho —lo que aceleró la legislación sobre delitos informáticos en medio mundo.
La lección de ILOVEYOU
El eslabón atacable no era el código, era la persona y la configuración por defecto. De aquí salen el filtrado de adjuntos ejecutables en el correo y años de campañas de concienciación
4. Code Red, Nimda y SQL Slammer (2001-2003): el parche que nadie aplicaba
El verano de 2001 trajo Code Red, que explotaba un desbordamiento en el servidor web IIS de Microsoft. El parche llevaba un mes publicado cuando el gusano empezó a propagarse; aun así infectó más de 350.000 servidores en menos de 14 horas y llegó a lanzar un ataque de denegación de servicio contra la Casa Blanca. Semanas después, Nimda combinó cinco vías de propagación a la vez (web, correo, carpetas compartidas, sitios ya infectados y las puertas traseras que había dejado Code Red) y se convirtió en el incidente más extendido hasta la fecha.
En enero de 2003, SQL Slammer llevó la velocidad al extremo. Cabía en un único paquete UDP de 376 bytes, no tocaba disco —vivía solo en memoria— y explotaba un fallo de Microsoft SQL Server para el que también existía parche desde hacía seis meses. Duplicó el número de máquinas infectadas cada 8,5 segundos y en diez minutos había saturado buena parte del ancho de banda mundial, tirando cajeros automáticos, sistemas de reservas de vuelos e incluso una red de monitorización de una central nuclear.
La lección de esta trilogía
Publicar el parche no es aplicarlo. El problema pasó a ser de gestión: inventario de activos, ventanas de parcheo y la idea de que el tiempo entre parche y explotación se mide ya en días
5. Conficker, 2008: la botnet como industria
Conficker explotaba un fallo en el servicio de red de Windows (MS08-067) y añadía difusión por unidades USB y por contraseñas débiles de recursos compartidos. Llegó a controlar entre 9 y 15 millones de equipos, incluyendo redes militares francesas y británicas y hospitales enteros. Pero lo que lo hizo histórico fue su infraestructura de mando: generaba cada día cientos de nombres de dominio pseudoaleatorios entre los que buscaba órdenes, usaba criptografía moderna para firmar sus actualizaciones y se defendía desactivando antivirus y bloqueando el acceso a webs de seguridad.
La respuesta también marcó época: el Conficker Working Group reunió a Microsoft, registradores de dominios, académicos y fabricantes de seguridad para registrar por adelantado los dominios que el gusano iba a usar. Fue uno de los primeros ejemplos de defensa coordinada público-privada a escala global. Curiosamente, la enorme botnet apenas se usó: su potencial de daño siempre fue mayor que su actividad real.
La lección de Conficker
El malware masivo se había profesionalizado: nombres de dominio generados por algoritmo, actualizaciones firmadas, autodefensa. La respuesta tenía que ser igual de organizada y cruzar fronteras entre empresas y países
6. Stuxnet, 2010: cuando el malware salió de la pantalla
Stuxnet es la frontera entre dos épocas. Descubierto en 2010, estaba diseñado con un único objetivo: las centrifugadoras de enriquecimiento de uranio de la planta iraní de Natanz. Se propagaba por USB y por la red local, pero solo activaba su carga cuando encontraba un modelo muy concreto de autómata programable (PLC) de Siemens controlando variadores de frecuencia en un rango específico. Entonces alteraba sutilmente la velocidad de giro de las centrifugadoras mientras enviaba a los operadores lecturas normales grabadas de antes.
Para lograrlo encadenaba cuatro vulnerabilidades de día cero en Windows —algo inaudito— y usaba controladores firmados con certificados robados a empresas taiwanesas reales. El consenso de la industria es que fue una operación de Estado. Stuxnet demostró que el software podía causar daño físico dirigido y permanente, y abrió de forma oficial la era de las ciberarmas y de la preocupación por la seguridad de los sistemas industriales (OT) y las infraestructuras críticas.
Por qué Stuxnet cambió el marco mental
Hasta 2010 el peor caso era «nos roban datos» o «nos paran los sistemas». Después, el peor caso pasó a ser «nos destruyen una planta», y la frontera entre el mundo IT y el mundo industrial dejó de ser un problema teórico
7. WannaCry y NotPetya, 2017: el gusano vuelve, ahora con rescate
Durante años se pensó que el gusano de propagación masiva era cosa del pasado, frenado por cortafuegos y actualizaciones automáticas. 2017 lo desmintió dos veces. En mayo, WannaCry combinó un exploit del servicio de compartición de archivos SMB —filtrado de un arsenal de la NSA— con ransomware: cifraba los discos y pedía un pago en bitcoin. En un fin de semana golpeó unos 200.000 equipos en 150 países, con el Servicio Nacional de Salud británico como víctima más visible. Un investigador lo detuvo casi por accidente al registrar un dominio que actuaba de interruptor.
En junio, NotPetya usó la misma vía de propagación pero con otra intención. Entró a través de la actualización troyanizada de un software de contabilidad muy usado en Ucrania y, aunque simulaba pedir un rescate, en realidad destruía los datos sin posibilidad de recuperarlos. Se extendió por las multinacionales con presencia en el país —Maersk, Merck, FedEx, Mondelez— y provocó pérdidas estimadas en más de 10.000 millones de dólares, el ciberataque más caro de la historia. La «petición de rescate» era una cortina de humo sobre lo que era, en la práctica, un sabotaje.
La lección de 2017
El gusano nunca se fue: basta un exploit potente de un servicio de red expuesto. Y la propagación automática se puede usar tanto para extorsión como para destrucción disfrazada de extorsión
8. Treinta años en una tabla
| Gusano | Año | Vía de propagación | Qué cambió |
|---|---|---|---|
| Morris | 1988 | Fallos en finger y sendmail, contraseñas débiles | Nacimiento del CERT/CC y de la respuesta a incidentes coordinada |
| ILOVEYOU | 2000 | Adjunto VBS por la libreta de Outlook | Filtrado de ejecutables en el correo; leyes de delitos informáticos |
| Code Red / Nimda | 2001 | Fallo en IIS + cinco vectores combinados | La gestión de parches como disciplina; inventario de activos |
| SQL Slammer | 2003 | Un paquete UDP contra SQL Server (parche de 6 meses) | Propagación en minutos; malware solo en memoria |
| Conficker | 2008 | MS08-067, USB, recursos compartidos | Botnets profesionales; defensa público-privada global |
| Stuxnet | 2010 | USB y red local hacia PLC Siemens concretos | Daño físico dirigido; seguridad de OT e infraestructura crítica |
| WannaCry | 2017 | Exploit SMB (EternalBlue) + ransomware | Vuelve el gusano masivo; parcheo de servicios expuestos |
| NotPetya | 2017 | Actualización troyanizada + exploit SMB | Wiper disfrazado de ransomware; riesgo de cadena de suministro |
9. Lo que se repite en cada ola
- Casi nunca es un fallo nuevo. Morris, Code Red, Slammer, Conficker y WannaCry explotaron vulnerabilidades con parche disponible desde semanas o meses antes. El problema recurrente es el tiempo de aplicación, no el de publicación
- La superficie de red es el motor. Servicios accesibles desde fuera (o desde toda la red interna) sin necesidad real de estarlo son lo que convierte una infección puntual en una epidemia. De ahí la segmentación y el principio de mínima exposición
- La respuesta tiene que ser colectiva. Del CERT de 1988 al Conficker Working Group de 2009, cada salto de escala del problema se resolvió con más coordinación entre organizaciones y países, no con cada uno defendiéndose por su cuenta
- La frontera IT/OT ya no existe. Slammer tocó una central nuclear por accidente; Stuxnet lo hizo a propósito. Los sistemas industriales necesitan el mismo cuidado que los ofimáticos, y estar separados de ellos
- El propósito cambia, la técnica no tanto. La misma propagación automática ha servido para medir la red, mandar spam, construir botnets, sabotear centrifugadoras y extorsionar hospitales. Conviene mirar el motor, no solo la carga de turno
Referencias
INCIBE-CERT (incibe.es) — Avisos y respuesta a incidentes en España · CERT/CC — Carnegie Mellon Software Engineering Institute, el equipo original · «Worm: The First Digital World War», Mark Bowden — crónica de Conficker · «Countdown to Zero Day», Kim Zetter — investigación periodística sobre Stuxnet · «Sandworm», Andy Greenberg — NotPetya y el grupo detrás
Conclusión
Los grandes gusanos no fueron proezas técnicas irrepetibles; fueron, casi siempre, el resultado previsible de un fallo conocido, un servicio expuesto de más y una organización defensiva que aún no existía. Cada uno forzó la creación de algo que hoy es rutina: los equipos de respuesta, la gestión de parches, el filtrado de correo, la coordinación internacional, la seguridad industrial.
La parte incómoda es que las lecciones se siguen redescubriendo. El intervalo entre que se publica un parche y que alguien lo explota a gran escala no ha dejado de encogerse, y la propagación automática sigue siendo la herramienta más rentable para quien quiere hacer daño rápido. Conocer esta historia no es nostalgia: es el mapa de los errores que conviene no repetir.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)