Conficker: El Gusano que Nadie Podía Parar (2008-2009)

El contexto: octubre de 2008, un parche urgente de Microsoft

El 23 de octubre de 2008, Microsoft hizo algo que casi nunca hacía: publicar un parche de seguridad fuera de su ciclo habitual del segundo martes de cada mes (Patch Tuesday). El boletín MS08-067 corregía una vulnerabilidad crítica en el servicio Windows Server, presente en todas las versiones de Windows desde 2000 hasta Server 2008. La vulnerabilidad permitía ejecución remota de código sin autenticación a través del puerto 445/TCP.

El parche era urgente porque Microsoft ya había detectado explotación activa limitada. Pero la mayoría de organizaciones no parchearon inmediatamente. Algunas por negligencia, otras por procesos internos lentos, muchas porque ni siquiera tenían Windows Update habilitado.

Tres semanas después, el 21 de noviembre de 2008, apareció un gusano que explotaba exactamente esa vulnerabilidad. Se llamaba Conficker (también conocido como Downadup o Kido). En pocas semanas infectó millones de máquinas. Y durante los siguientes meses, cada intento de la industria de seguridad por detenerlo fue respondido con una variante más sofisticada.

Conficker no fue el gusano más destructivo de la historia. Pero fue, probablemente, el más resiliente.

MS08-067: la puerta de entrada

La vulnerabilidad residía en la función NetPathCanonicalize() del módulo netapi32.dll, parte del servicio Windows Server (Server Service, también conocido como LanmanServer). Este servicio gestiona las comparticiones de archivos e impresoras en red y escucha en el puerto 445/TCP.

El problema era un desbordamiento de búfer clásico. La función recibía rutas de red (UNC paths) y las "canonicalizaba" (normalizaba a una forma estándar). Pero no validaba correctamente ciertas secuencias de caracteres especiales en las rutas. Un atacante podía enviar una petición RPC (Remote Procedure Call) con una ruta maliciosa que desbordaba el búfer y permitía ejecutar código arbitrario con privilegios de SYSTEM, el nivel más alto en Windows.

Lo que hacía esta vulnerabilidad especialmente peligrosa:

• No requería autenticación. Cualquier máquina que tuviera el puerto 445 accesible podía ser atacada sin credenciales.
• Afectaba a todas las versiones de Windows. Desde Windows 2000 hasta Vista y Server 2008. La superficie de ataque era enorme.
• El puerto 445 estaba abierto por defecto en redes corporativas para compartición de archivos. Millones de máquinas lo exponían.

Aspecto	Detalle
CVE	CVE-2008-4250
Boletín	MS08-067
Módulo vulnerable	netapi32.dll (Server Service)
Puerto	445/TCP (SMB/RPC)
Impacto	Ejecución remota de código como SYSTEM
Autenticación requerida	Ninguna
CVSS v2	10.0 (máximo)
Parche disponible	23 de octubre de 2008
Primera explotación masiva	21 de noviembre de 2008

Anatomía de Conficker: cinco variantes, cada una peor

Conficker no fue un gusano estático. Evolucionó en cinco variantes documentadas, cada una corrigiendo debilidades de la anterior y añadiendo capas de sofisticación. Esa evolución es lo que lo hizo tan difícil de combatir.

Conficker.A (noviembre 2008)

La primera variante era relativamente simple. Explotaba MS08-067, se copiaba a la máquina objetivo como un archivo DLL con nombre aleatorio en el directorio %SystemRoot%\system32, se registraba como un servicio de Windows con nombre aleatorio y comenzaba a escanear la red local y direcciones IP aleatorias en Internet buscando más máquinas vulnerables.

Para recibir actualizaciones, Conficker.A usaba un algoritmo de generación de dominios (DGA, Domain Generation Algorithm): cada día generaba una lista de 250 dominios pseudoaleatorios en cinco TLDs (.com, .net, .org, .info, .biz). El gusano intentaba conectarse a cada uno para descargar instrucciones. Los atacantes solo necesitaban registrar uno de esos 250 dominios para enviar comandos a toda la botnet.

El DGA usaba la fecha actual como semilla, lo que significaba que todas las copias del gusano generaban la misma lista de dominios el mismo día. Esto permitía a los investigadores predecir los dominios futuros, pero registrar 250 dominios cada día en cinco TLDs era logística y económicamente inviable.

Conficker.B (diciembre 2008)

La variante B añadió múltiples mejoras:

• Propagación por USB. Además de la red, el gusano se copiaba a unidades USB y creaba un archivo autorun.inf que lo ejecutaba automáticamente al insertar el dispositivo en otra máquina.
• Propagación por fuerza bruta. Conficker.B intentaba acceder a comparticiones de red administrativas (ADMIN$, C$) usando una lista interna de contraseñas comunes.
• Bloqueo de actualizaciones. El gusano parcheaba la vulnerabilidad MS08-067 en memoria (para evitar que otro malware la explotara), pero también bloqueaba el acceso a sitios web de Microsoft Update y de las principales empresas antivirus.
• Anti-análisis. Terminaba procesos asociados con herramientas de seguridad y deshabilitaba el servicio de actualizaciones automáticas de Windows.

Conficker.C (febrero 2009): el salto cualitativo

Conficker.C fue la variante que aterrorizó a la industria. Incorporó cambios radicales:

DGA ampliado a 50.000 dominios diarios. En lugar de 250 dominios en 5 TLDs, la variante C generaba 50.000 dominios diarios distribuidos en 116 TLDs, incluyendo dominios de código de país. Registrar o bloquear 50.000 dominios al día en 116 TLDs era prácticamente imposible.

Verificación criptográfica de actualizaciones. Las actualizaciones descargadas debían estar firmadas con RSA-4096 (clave de 4096 bits) y verificadas con un hash MD6 (el algoritmo de hash de Ronald Rivest, que en aquel momento era candidato para SHA-3). Solo los autores, poseedores de la clave privada, podían generar actualizaciones válidas. Esto hacía inútil cualquier intento de enviar comandos falsos a la botnet.

Fecha de activación: 1 de abril de 2009. El nuevo DGA de 50.000 dominios no se activaría hasta esa fecha. Esto generó semanas de especulación mediática sobre qué haría Conficker cuando "despertara".

Conficker.D (marzo 2009)

Conficker.D abandonó parcialmente la dependencia de dominios e implementó un sistema de comunicación P2P (peer-to-peer) entre las máquinas infectadas. Cada copia del gusano podía recibir actualizaciones de otras copias cercanas, sin necesidad de conectarse a un servidor central. Esto hacía que derribar la botnet fuera virtualmente imposible: no había infraestructura central que atacar.

Conficker.E (abril 2009)

La última variante conocida. Se distribuyó a través de la red P2P de Conficker.D y tenía una fecha de autoeliminación (3 de mayo de 2009). Su función principal fue instalar dos piezas de software:

• Waledac, un bot de spam que enviaba emails masivos.
• SpyProtect 2009, un falso antivirus (scareware) que mostraba alertas de seguridad falsas e intentaba que el usuario pagara 49,95 dólares por una "versión completa" que no hacía nada.

El hecho de que meses de sofisticación técnica culminaran en spam y scareware desconcertó a muchos investigadores. La teoría más aceptada es que los autores monetizaron la botnet de la forma más segura y discreta posible, evitando acciones destructivas que habrían intensificado la presión policial.

Técnicas MITRE ATT&CK

Conficker implementó técnicas que hoy son referencia en el framework MITRE ATT&CK:

Técnica MITRE	ID	Implementación en Conficker
Exploit Public-Facing Application	T1190	Explotación de MS08-067 en el puerto 445/TCP sin autenticación
Dynamic Resolution: Domain Generation Algorithms	T1568.002	DGA de 250 dominios/día (variante A/B) y 50.000 dominios/día (variante C)
Encrypted Channel	T1573	Comunicaciones P2P cifradas, payloads firmados con RSA-4096

Además de estas tres técnicas principales, Conficker empleó:

• T1021.002 (Remote Services: SMB/Windows Admin Shares): propagación por fuerza bruta contra ADMIN$ y C$.
• T1091 (Replication Through Removable Media): propagación por USB con autorun.inf.
• T1562.001 (Impair Defenses: Disable or Modify Tools): terminación de procesos antivirus y deshabilitación de Windows Update.
• T1053.005 (Scheduled Task/Job): persistencia mediante servicios de Windows registrados dinámicamente.

El DGA: la innovación que cambió el malware

El Domain Generation Algorithm de Conficker merece atención especial porque definió una técnica que hoy es estándar en malware avanzado.

El problema que resuelve un DGA es simple: si un gusano se conecta siempre al mismo dominio para recibir instrucciones, los defensores pueden bloquear ese dominio y la botnet queda sin control. Si el gusano genera dominios nuevos cada día usando un algoritmo determinista, los atacantes solo necesitan registrar uno de los miles de dominios generados para mantener el control, mientras que los defensores tendrían que bloquear todos.

El DGA de Conficker.A funcionaba así:

1. Tomar la fecha UTC actual como semilla.
2. Aplicar una serie de operaciones aritméticas y de bit-shifting sobre la semilla.
3. Generar una cadena de caracteres pseudoaleatoria de entre 4 y 10 caracteres.
4. Añadir uno de cinco TLDs (.com, .net, .org, .info, .biz).
5. Repetir 250 veces.

El resultado eran dominios como asjdfkl.com, qpwmdnv.net, xhgtobj.org: cadenas sin sentido lingüístico pero perfectamente válidas como nombres de dominio. Los autores de Conficker solo necesitaban registrar uno de esos 250 dominios antes de que los defensores lo hicieran.

Conficker.C escaló esto a 50.000 dominios diarios en 116 TLDs. El coste de registrar preventivamente todos esos dominios era prohibitivo. ICANN, la organización que gestiona el sistema de nombres de dominio global, tuvo que intervenir directamente para coordinar el bloqueo con los registradores de dominios de cada país.

Evolución del DGA en malware posterior

Malware	Año	Dominios/día	Técnica DGA
Conficker.A	2008	250	Fecha como semilla, 5 TLDs
Conficker.C	2009	50.000	Fecha como semilla, 116 TLDs
Murofet/Zeus	2010	Variable	DGA basado en fecha + semilla adicional
CryptoLocker	2013	1.000	DGA con fallback a dominios hardcoded
Necurs	2016	2.048	DGA con semilla derivada del año/mes
Emotet	2018+	Variable	DGA combinado con lista de IPs hardcoded

Conficker demostró que un DGA bien implementado podía hacer que una botnet fuera prácticamente indestructible desde el punto de vista de la infraestructura de red. La técnica se convirtió en estándar para todo malware serio posterior.

El Conficker Working Group: la industria se une

La respuesta a Conficker fue sin precedentes. En febrero de 2009, Microsoft, ICANN, Symantec, F-Secure, Kaspersky, Georgia Tech, SRI International y otras organizaciones formaron el Conficker Working Group (CWG), una coalición ad hoc para combatir el gusano.

Las acciones del CWG incluyeron:

• Registro preventivo de dominios DGA. Los investigadores de SRI International reverse-engineered el algoritmo DGA de Conficker y publicaron las listas de dominios futuros. El CWG coordinó con los registradores de dominios para bloquear o sinkholear esos dominios antes de que los atacantes los registraran.
• Sinkholing. Los dominios registrados por el CWG redirigían el tráfico a servidores controlados por los investigadores, lo que permitía estimar el número de máquinas infectadas y su distribución geográfica.
• Microsoft ofreció 250.000 dólares de recompensa por información que condujera a la identificación y condena de los autores. La recompensa nunca se cobró.
• Coordinación con ICANN. Para la variante C y sus 50.000 dominios diarios en 116 TLDs, ICANN tuvo que coordinar el bloqueo con ccTLDs (registradores de dominios de código de país) de todo el mundo. Fue la primera vez que se intentó una operación de bloqueo de dominios a esa escala.

Los límites del CWG

A pesar del esfuerzo, el Conficker Working Group tuvo limitaciones significativas:

• No era una estructura formal. Era una coalición voluntaria sin autoridad legal ni presupuesto propio. Cada organización participaba con sus propios recursos.
• Conficker.D hizo irrelevante el bloqueo de dominios. Al implementar comunicación P2P, la variante D podía recibir actualizaciones sin conectarse a ningún dominio. El trabajo de meses bloqueando DGA quedó parcialmente obsoleto.
• El gusano seguía propagándose. Bloquear los dominios de C2 no eliminaba las infecciones existentes ni impedía nuevas infecciones por USB o fuerza bruta.
• Tensiones entre competidores. Empresas de seguridad que normalmente competían entre sí tuvieron que compartir investigación y coordinar acciones en tiempo real.

El CWG fue un precedente importante para operaciones posteriores como el desmantelamiento de botnets GameOver Zeus (2014) y Emotet (2021), donde agencias gubernamentales y empresas privadas colaboraron de forma similar pero con más estructura legal.

El 1 de abril de 2009: la fecha que aterorizó a los medios

Conficker.C contenía código que programaba la activación de su nuevo DGA de 50.000 dominios para el 1 de abril de 2009. Los medios de comunicación convirtieron esa fecha en un evento apocalíptico.

Los titulares eran predecibles: "El gusano que destruirá Internet el 1 de abril", "Millones de ordenadores podrían ser controlados a distancia", "El peor ciberataque de la historia está a punto de ocurrir". CNN, BBC, 60 Minutes y decenas de medios cubrieron la historia durante semanas.

Los investigadores de seguridad intentaron moderar las expectativas. La fecha solo marcaba el momento en que el DGA se expandiría, no necesariamente el momento de un "ataque". Pero la narrativa mediática ya estaba establecida.

¿Qué pasó realmente el 1 de abril? Casi nada visible. Conficker.C activó su DGA ampliado y sus comunicaciones P2P, pero no lanzó ningún ataque destructivo. No borró archivos, no robó datos masivamente, no derribó infraestructura. Semanas después, a través del canal P2P, distribuyó Waledac y SpyProtect 2009.

La discrepancia entre la histeria mediática y la realidad generó dos reacciones opuestas:

1. "Era todo exagerado": muchos concluyeron que la amenaza había sido inflada y que la ciberseguridad era alarmista.
2. "Fue una bala esquivada": los profesionales argumentaron que las acciones del CWG habían limitado las opciones de los atacantes y que la monetización discreta era precisamente la estrategia más racional.

La verdad probablemente está en un punto intermedio. Los autores de Conficker tenían una botnet de millones de máquinas y eligieron usarla para spam y scareware. Pudieron haber hecho mucho más daño. Que no lo hicieran no significa que no pudieran.

Los autores fantasma

A pesar de los esfuerzos del FBI, Europol, Microsoft y el Conficker Working Group, los autores de Conficker nunca fueron identificados ni procesados. La recompensa de 250.000 dólares de Microsoft sigue sin cobrarse casi dos décadas después.

Las pistas apuntaban a Europa del Este, específicamente Ucrania:

• El gusano evitaba máquinas con teclado ucraniano. Conficker comprobaba la configuración de idioma del sistema y no se instalaba si detectaba el layout de teclado ucraniano. Esta es una técnica habitual del crimen organizado de la región para evitar problemas con las autoridades locales.
• Infraestructura de distribución. Varios de los dominios y servidores utilizados en las primeras fases tenían conexiones con proveedores de hosting en Ucrania y Rusia.
• Waledac, el bot de spam instalado por Conficker.E, tenía vínculos documentados con la botnet Storm Worm, asociada a grupos criminales rusos.
• Patrón de monetización. Spam y scareware era el modelo de negocio habitual del crimen organizado de la antigua Unión Soviética en esa época.

Pero correlación no es atribución. Sin pruebas concretas, los autores permanecen anónimos.

Cifras de la infección

Métrica	Dato
Primera detección	21 de noviembre de 2008
Pico de infecciones estimado	9 a 15 millones de máquinas
Países afectados	Más de 190
Variantes documentadas	5 (A, B, B++, C, D, E)
Dominios DGA generados (variante C)	50.000 por día
TLDs utilizados por DGA	116
Recompensa de Microsoft	250.000 USD (nunca cobrada)
Organizaciones en el CWG	Más de 20
Autores identificados	Ninguno

El legado: por qué Conficker importa en 2026

Conficker fue un punto de inflexión en la historia del malware por varias razones:

El DGA se convirtió en estándar. Antes de Conficker, la mayoría del malware usaba dominios hardcoded o listas estáticas de IPs para comunicarse con su C2. Después de Conficker, los DGA se convirtieron en una técnica esperada en cualquier malware avanzado. CryptoLocker, Necurs, Emotet, Dyre, Matsnu: todos adoptaron variantes de la idea que Conficker popularizó.

La comunicación P2P en botnets. Conficker.D demostró que una botnet podía funcionar sin infraestructura centralizada. GameOver Zeus (2014), ZeroAccess y TrickBot implementaron arquitecturas P2P similares, haciendo que los takedowns fueran mucho más difíciles.

La verificación criptográfica de payloads. Usar RSA-4096 para firmar las actualizaciones del gusano era una sofisticación sin precedentes en 2009. Garantizaba que solo los autores pudieran enviar comandos a la botnet, bloqueando cualquier intento de secuestro por parte de investigadores o competidores criminales.

La colaboración industria-gobierno. El Conficker Working Group sentó el precedente para operaciones coordinadas posteriores. El modelo de coalición voluntaria entre competidores, ISPs, registradores de dominios y agencias gubernamentales se replicó (con mejoras) en cada gran takedown de botnet posterior.

La brecha entre parche disponible y parche aplicado. Conficker demostró que la existencia de un parche no significa que las organizaciones lo apliquen. MS08-067 llevaba tres semanas disponible cuando Conficker apareció. Años después, millones de máquinas seguían sin parchear. Esa brecha, el patch gap, sigue siendo uno de los problemas fundamentales de la ciberseguridad.

Infecciones persistentes

Quizás el dato más revelador sobre el legado de Conficker es que sigue detectándose en 2026. Máquinas con Windows XP embebido en sistemas industriales, equipos médicos, cajeros automáticos y sistemas de control de acceso siguen ejecutando copias del gusano casi dos décadas después. No porque Conficker sea especialmente sigiloso, sino porque esas máquinas no se pueden actualizar.

Conficker se convirtió en una especie de fósil viviente: un recordatorio permanente de que el malware no desaparece cuando los medios dejan de hablar de él.

Línea temporal

Fecha	Evento
23 oct 2008	Microsoft publica MS08-067 fuera de ciclo
21 nov 2008	Primera detección de Conficker.A
Dic 2008	Conficker.B: añade USB, fuerza bruta, bloqueo de AV
Feb 2009	Se forma el Conficker Working Group
Feb 2009	Conficker.C: DGA de 50.000 dominios, RSA-4096
13 feb 2009	Microsoft ofrece recompensa de 250.000 USD
Mar 2009	Conficker.D: comunicación P2P
1 abr 2009	Fecha de activación de Conficker.C (activación sin incidentes)
Abr 2009	Conficker.E: instala Waledac y SpyProtect 2009
3 may 2009	Conficker.E se autoelimina (Waledac persiste)
2009-2026	Conficker sigue detectándose en sistemas legacy

Conclusión: la resiliencia como herencia

Conficker no destruyó Internet. No robó miles de millones. No derribó infraestructura crítica. Visto desde la perspectiva de lo que pudo haber hecho con 9 a 15 millones de máquinas bajo su control, su impacto directo fue modesto.

Pero su impacto técnico fue profundo. Conficker forzó a la industria de seguridad a colaborar de formas que nunca había hecho. Demostró que un gusano bien diseñado podía resistir los esfuerzos combinados de Microsoft, ICANN, Symantec, Kaspersky y docenas de organizaciones más. Introdujo técnicas (DGA masivo, P2P, firma criptográfica de payloads) que se convirtieron en el estándar del malware avanzado durante la siguiente década.

Y 18 años después, sigue ahí. En máquinas que nadie puede parchear, en redes que nadie quiere apagar, en sistemas que nadie se atreve a reemplazar. Conficker es el fantasma que recuerda que el malware no tiene fecha de caducidad.