Entradas de junio de 2026

Había una dimensión del retrohacking ochentero y noventero que rara vez sale en las conversaciones habituales sobre phreaking, warez o demoscene y, sin embargo, estaba ahí, latiendo en silencio entre los sectores de los disquetes y los búferes de memoria de los módems: la manipulación deliberada de las bases de mensajes en sistemas BBS para alterar la realidad percibida por sus usuarios. Y no hablamos de borrar envíos ni de vandalismo simplón, sino de reescribir la historia de una comunidad byte a byte, atacando el propio formato en que los mensajes se almacenaban.

A la sazón, muchas BBS populares utilizaban formatos de almacenamiento propietarios o semiestandarizados, como los MSG de FidoNet, los JDT de JAM o los HMB de Hudson. Estos sistemas no eran bases de datos en el sentido moderno, sino colecciones de registros binarios con cabeceras relativamente sencillas. Cada mensaje tenía offsets, identificadores, flags y enlaces a otros mensajes. La mayoría de operadores de sistemas confiaban en la integridad del software que gestionaba estos archivos, asumiendo que cualquier modificación debía pasar por la lógica de la aplicación. Ahí estaba el error.

El truco consistía en acceder a los archivos de mensajes desde fuera de la BBS, normalmente mediante una puerta trasera bastante mundana como una cuenta mal configurada en un shell auxiliar o, también, aprovechando scripts de mantenimiento accesibles. Una vez dentro, se trataba de entender la capa binaria para poder modificarla. Nada glamuroso, sólo paciencia, un editor hexadecimal y la propia documentación recogida de FidoNews o la experiencia directamente deducida a base de prueba y error. Cambiar el autor de un mensaje era tan simple como sobrescribir un campo ASCII, pero lo interesante venía al jugar con los punteros de hilo y los estados de lectura.

En los sistemas JAM, por ejemplo, los envíos estaban indexados por un archivo separado (JDX) que apuntaba a los bloques de texto. Si se alteraban estos índices, era posible hacer que un mensaje respondiera a otro distinto, creando conversaciones que nunca ocurrieron o, mejor aún, reorganizando debates enteros para que pareciera que alguien había dicho lo contrario horas antes. En Hudson, más primitivo, bastaba con duplicar un registro con ligeras modificaciones y ajustar la marca de tiempo (timestamp) para insertar respuestas fantasma que parecían perfectamente legítimas.

Lo realmente perverso de este tipo de hacking vetusto no era el acceso técnico, sino el efecto psicológico. A diferencia de la desfiguración visible (defacing) o del robo de cuentas, aquí el sistema seguía funcionando con aparente normalidad. Los usuarios leían discusiones que tenían coherencia sintáctica pero no semántica, respuestas que nunca recordaban haber escrito o mensajes que parecían anticipar eventos futuros. Era desinformación artesanal, hecha con offsets y checksums, antes de que la palabra estuviera de moda.

Otro vector menos conocido consistía en manipular los identificadores únicos de mensaje utilizados durante las exportaciones y sincronizaciones entre nodos. En redes basadas en FidoNet, muchos programas dependían de campos como MSGID y REPLY para reconstruir árboles de conversación durante el intercambio de correo. Alterando cuidadosamente esos valores era posible provocar bifurcaciones lógicas en los hilos, generar referencias huérfanas o hacer que mensajes legítimos aparecieran asociados a contextos completamente distintos. El resultado no siempre era visible de inmediato; a menudo la distorsión emergía gradualmente a medida que los paquetes se propagaban entre sistemas y cada nodo reinterpretaba la estructura según sus propias reglas.

Tampoco ayudaba la ausencia de controles criptográficos significativos. La autenticidad de un mensaje descansaba casi por completo en la confianza depositada en el software de transporte y en la integridad del sistema remoto. Salvo mecanismos puntuales de validación o firmas implementadas por algunas redes especializadas, la mayoría de mensajes circulaban como registros cuya procedencia se asumía legítima. Desde una perspectiva moderna resulta llamativo comprobar hasta qué punto la coherencia social de aquellas comunidades dependía más de convenciones operativas que de garantías técnicas verificables, lo que convertía la manipulación de metadatos en una herramienta sorprendentemente eficaz para alterar narrativas sin necesidad de comprometer grandes infraestructuras.

Por supuesto, había riesgos técnicos. Muchos de estos formatos incluían mecanismos rudimentarios de verificación, y un byte mal colocado podía corromper enteramente la base de mensajes, obligando al sysop a restaurar desde una copia de seguridad. Por eso, los más finos trabajaban siempre sobre copias, recalculaban punteros y, en algunos casos, desarrollaban pequeñas utilidades en C para automatizar las modificaciones sin romper la estructura. Era un equilibrio delicado entre el caos creativo y la ingeniería inversa meticulosa.

Hoy, cuando todo está en bases de datos relacionales con registros inmutables y sistemas de auditoría, este tipo de manipulación parece infantil o inviable. Pero en aquel ecosistema distribuido y heterogéneo de las BBS, donde cada nodo tenía su propia idiosincrasia y las sincronizaciones eran lentas y parciales, había espacio para jugar con la realidad misma de la comunicación. No era sólo hackear máquinas, era hackear la memoria colectiva de una comunidad digital en pañales, y hacerlo sin dejar apenas rastro distinguible del ruido normal del sistema.

En mayo de 2017 el mundo fue testigo de uno de los ciberataques más impactantes de la historia. Miles de organizaciones en decenas de países vieron cómo sus sistemas informáticos quedaban bloqueados de forma repentina por un ransomware llamado WannaCry. Hospitales, empresas de telecomunicaciones, fábricas, universidades y organismos públicos se encontraron con sus archivos cifrados y una exigencia de rescate en bitcoins para recuperarlos. Durante unas horas pareció que Internet estaba asistiendo a una especie de pandemia digital capaz de expandirse sin control.

Lo que hacía especialmente peligroso a WannaCry era que no dependía de la torpeza de los usuarios. La mayoría de los programas maliciosos necesitan que alguien abra un archivo adjunto, pulse sobre un enlace o instale una aplicación infectada. WannaCry era diferente, pues hacía uso de una vulnerabilidad de Windows conocida como MS17-010 para propagarse automáticamente de un ordenador a otro. Dicha vulnerabilidad afectaba (y afecta, si no está parcheada) al protocolo SMBv1, el mecanismo utilizado por Windows (en su primera versión) para compartir archivos, impresoras y recursos en general dentro de una red. Gracias a ella, un atacante podía ejecutar código de forma remota en una máquina vulnerable sin necesidad de autenticarse ni de que el usuario realizara ninguna acción.

La herramienta que aprovechaba esta vulnerabilidad era un exploit denominado EternalBlue. Lo más sorprendente es que EternalBlue no había sido desarrollado por un grupo criminal cualquiera, sino por la propia Agencia de Seguridad Nacional de Estados Unidos, la NSA. Durante años fue una herramienta secreta utilizada con fines de inteligencia hasta que acabó filtrada al público por un misterioso grupo conocido como The Shadow Brokers. De repente, una de las armas digitales más sofisticadas del arsenal de una agencia gubernamental quedó al alcance de cualquiera que quisiera utilizarla.

Cuando WannaCry apareció en Internet (viernes, 12 de mayo de 2017), combinó dicho exploit EternalBlue con un ransomware tradicional, y el resultado fue devastador. Una vez que una máquina era infectada, comenzaba a escanear la red en busca de otros equipos vulnerables. Si encontraba alguno, lo comprometía automáticamente y repetía el proceso. Este comportamiento convirtió a WannaCry, además, en un gusano informático, una categoría especialmente peligrosa de malware porque puede expandirse por sí mismo sin intervención humana y, en aquel entonces, en cuestión de horas se registraron decenas de miles de infecciones en más de ciento cincuenta países.

Entre las víctimas más conocidas estuvo el Servicio Nacional de Salud británico. Numerosos hospitales tuvieron que cancelar operaciones y consultas porque sus sistemas informáticos quedaron inutilizados, y también resultaron afectadas grandes empresas industriales, compañías de telecomunicaciones y organismos gubernamentales. Las imágenes de pantallas mostrando el mensaje de rescate dieron la vuelta al mundo y generaron una sensación de vulnerabilidad pocas veces vista hasta entonces.

Sin embargo, cuando todo parecía fuera de control, ocurrió algo inesperado. Un joven investigador británico de seguridad informática llamado Marcus Hutchins, conocido en Internet por el alias MalwareTech, comenzó a analizar una muestra del ransomware para comprender su funcionamiento. Durante su investigación, Hutchins observó un comportamiento extraño. Descubrió que, antes de iniciar el cifrado de archivos o de comenzar su propagación, WannaCry intentaba contactar con un extraño dominio de nombre aparentemente aleatorio: iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com.

La mayoría de los investigadores habría considerado aquel detalle como una simple curiosidad técnica, pero Hutchins, intrigado por su presencia en el código fuente, decidió registrar aquel dominio para estudiar el tráfico que pudiera recibir. El coste fue insignificante, apenas unos pocos dólares, pero lo que ocurrió después sorprendió a todo el mundo. Una vez que el dominio comenzó a responder, las nuevas instancias de WannaCry dejaron de ejecutarse. Sin saberlo, Hutchins había activado un mecanismo oculto dentro del software malicioso que actuaba como un interruptor de apagado, conocido popularmente como kill switch. Si la conexión fallaba, el malware continuaba ejecutándose normalmente; si la conexión tenía éxito, se detenía.

La razón exacta por la que los autores incluyeron este mecanismo sigue siendo objeto de debate. La teoría más aceptada es que pretendían dificultar el análisis del malware en entornos de laboratorio, ya que muchos sistemas automáticos utilizados por investigadores responden positivamente a cualquier petición DNS o HTTP realizada por un programa sospechoso con el objeto de observar su comportamiento. Los desarrolladores de WannaCry podrían haberlo diseñado para que se detuviera si conseguía contactar con aquel dominio, asumiendo que eso significaba que estaba siendo ejecutado dentro de una sandbox de análisis. Lo que no imaginaron es que a alguien le diera por registrar el dominio (o sí, quién sabe) y provocaría que todas las nuevas infecciones interpretaran que debían detenerse.

Es importante señalar que el hallazgo no eliminó el ransomware de los equipos ya comprometidos ni recuperó los archivos cifrados. Los sistemas infectados continuaron afectados. Sin embargo, el descubrimiento sí que logró frenar la propagación masiva que estaba alimentando el crecimiento exponencial del ataque. En otras palabras, se cerró la principal vía por la que la epidemia digital seguía expandiéndose.

El caso WannaCry también dejó al descubierto una realidad incómoda. Microsoft había publicado el parche que corregía la vulnerabilidad dos meses antes del ataque. A pesar de ello, miles de organizaciones no habían actualizado sus sistemas. Muchas utilizaban versiones antiguas de Windows o mantenían configuraciones obsoletas por motivos de compatibilidad. El resultado fue que una vulnerabilidad conocida y corregida acabó convirtiéndose en la puerta de entrada de una de las mayores crisis de seguridad informática de la década.

Con el paso del tiempo, WannaCry se ha convertido en un ejemplo clásico de cómo múltiples factores pueden combinarse para producir una tormenta perfecta: una vulnerabilidad grave, una herramienta ofensiva filtrada desde una agencia gubernamental, miles de sistemas sin actualizar y un malware diseñado para propagarse automáticamente fueron los ingredientes de un incidente histórico. Sin embargo, también es recordado por una circunstancia casi surrealista, la de que una crisis global que amenazaba con paralizar infraestructuras críticas terminó siendo frenada, al menos en gran medida, gracias al registro de un dominio olvidado que costó menos que una comida rápida.

Pocas veces en la historia de la informática una decisión tan simple tuvo un impacto tan enorme. Mientras miles de expertos intentaban comprender qué estaba ocurriendo y gobiernos de todo el mundo activaban protocolos de emergencia, un investigador sentado frente a su ordenador acabó encontrando la pieza que detuvo la expansión del ataque. Es una historia que parece sacada de una novela ciberpunk, pero ocurrió de verdad. Y, quizás por ello, WannaCry sigue siendo, casi una década después, uno de los episodios más fascinantes de la historia de la ciberseguridad.