«Trátalo como plutonio digital»: el problema es que el plutonio no se clona

El lunes 7, Computer Hoy publicó un artículo sobre la mayor biblioteca de malware creada: un estudiante de ingeniería informática, embajador de Microsoft Learn, ha publicado en GitHub un archivo con cincuenta y tres años de historia del software malicioso, de Creeper (1971) al ransomware moderno, catalogado, indexado y buscable desde una aplicación que se levanta en tu portátil con dos comandos.

El titular se lo lleva una frase del propio autor, y es una buena frase:

Un espécimen extraído es hostil. Trátalo como plutonio digital.

Dice exactamente lo que quiere decir. Y falla justo donde importa.

El plutonio tiene una propiedad que el malware no tiene: es materia. Pesa, hay que sacarlo de un sitio para llevarlo a otro y, cuando lo mueves, deja de estar donde estaba. Hay un organismo internacional dedicado a contarlo precisamente porque se puede contar. Un archivo no. Un archivo se copia, la copia es idéntica al original, el original sigue donde estaba, y nadie lleva la cuenta.

No es una objeción de salón. Cuando escribo esto, el jueves 10 de septiembre, el repositorio lleva treinta y seis días publicado y GitHub le cuenta 129 forks públicos que su autor ya no controla. Las copias descargadas en equipos particulares no las cuenta nadie.

De eso va este artículo. No de si el proyecto está bien hecho —lo está, y ahora explico por qué—, sino de qué le pasa a una cosa así cuando se sale del contexto para el que se pensó. Y sobre todo de un tipo de usuario que casi nunca aparece en estas conversaciones, porque no es ni un investigador ni un delincuente: el que lo abre por probar.

Plutonio de verdad: una pastilla de óxido de plutonio-238, el que alimenta los generadores termoeléctricos de las sondas espaciales, brillando por el calor de su propia desintegración. Es también un ejemplo de manual de tecnología de doble uso: el mismo material que llevó a las Voyager fuera del sistema solar es un peligro radiológico si acaba donde no debe. Fotografía del Departamento de Energía de Estados Unidos, en dominio público, vía Wikimedia Commons; imagen recortada.

Qué hay ahí dentro, exactamente

Los datos son los del propio repositorio, comprobados el 10 de septiembre. Y el primero es un detalle bonito: el proyecto se mueve más rápido de lo que se deja contar. Computer Hoy cita 2.764 especímenes y 80 familias, que es lo que sigue diciendo la descripción que GitHub enseña bajo el nombre del repositorio. El README dice 2.916 y 84 desde un commit del 5 de septiembre que metió nueve colecciones de una tacada. Dos días de diferencia entre una cosa y otra, y a estas alturas las dos cifras que definen el proyecto siguen sin coincidir entre sí.

Debajo de collections/ hay diecinueve carpetas, y sus nombres son un quién es quién del asunto: theZoo, vxunderground-MalwareSourceCode, MalwareBazaar, InQuest-samples, android-malware, JS-malware, VX-API, stuxnet y una que se llama, literalmente, NotPetyaFileEncryptor.

Las muestras no están enlazadas ni las descarga un script al arrancar: están dentro del árbol de git, en ZIP cifrados. No hay Git LFS —el .gitattributes solo marca las colecciones como material de terceros para que no ensucien las estadísticas de lenguaje—, así que un git clone a secas se los trae todos. La API de GitHub declara para el repositorio un tamaño de 5.911.165 kilobytes, unos 5,6 GiB.

Y la contraseña de esos ZIP está publicada en el README. Es infected, que no es una ocurrencia: es la convención del sector desde hace décadas, la que piden los propios fabricantes de antivirus cuando te dicen «mándanos la muestra en un zip con contraseña infected».

O sea: un comando, sin cuenta, sin registro, sin aceptar nada, y tienes en el disco casi tres mil piezas de software malicioso real y la llave para abrirlas.

Antes de seguir: el autor lo ha hecho bien

Esto hay que decirlo antes que nada, porque el resto del artículo va a sonar a otra cosa.

El repositorio tiene un SECURITY.md en dos idiomas. Cifra todas las muestras. El servidor que incluye no ejecuta binarios ni los sirve por el navegador: solo mueve metadatos y abre carpetas. Documenta la configuración de laboratorio —máquina virtual aislada, red desconectada o solo anfitrión, instantáneas, REMnux, FakeNet‑NG o INetSim para los que se autopropagan—. Advierte de que detonar un gusano fuera de un laboratorio cerrado es peligroso e ilegal en la mayoría de jurisdicciones. Y pide que, si alguien encuentra una muestra que se quedó sin cifrar por error, avise sin adjuntarla.

Es más cuidado del que ponen muchos productos comerciales. No estoy señalando a nadie: estoy diciendo que hacerlo todo bien no basta, y que esa es justamente la parte interesante.

Donde se rompe la metáfora

La frase del plutonio es tan buena que conviene llevarla hasta el final, porque es ahí donde enseña algo.

Del plutonio hay una cantidad concreta en el mundo y existe una contabilidad internacional de ese material, precisamente porque se puede contabilizar. Su peligro va con la masa: proteger el material y proteger a la gente son la misma tarea. Por eso la contención física funciona.

Con un archivo, esa relación no existe. Copiar no consume nada. La copia número mil es tan peligrosa como la primera, y sacarla no deja hueco en el sitio de donde salió. Lo que se protege no es la muestra: es su ausencia en todos los demás sitios. Y esa es una propiedad que se pierde para siempre en cuanto se pierde una vez.

En GitHub, además, se pierde de una forma particularmente definitiva. En julio de 2024, Truffle Security publicó que los commits de una red de forks siguen siendo accesibles aunque el fork se borre, y que GitHub considera ese comportamiento intencionado y documentado. Le pusieron nombre —Cross Fork Object Reference— y demostraron el ciclo entero en menos de un minuto: bifurcar, subir algo, borrar el fork, recuperar lo subido.

Traducido a este caso: si mañana el autor se arrepiente y borra el repositorio, no se lleva por delante ni uno solo de los 129 forks. Miré dos de esa lista, al azar. Cada uno declara un tamaño de 4.252.447 kilobytes y registra su último push el 10 de agosto. Están en cuentas ajenas y no hay ningún mecanismo por el que el autor pueda modificarlos.

Un archivo publicado se puede retirar del origen. De las copias no lo retira nadie.

La fricción era la medida de seguridad

Aquí está, creo, lo importante, y no tiene que ver con lo que el repositorio contiene sino con lo que quita.

Ninguna de las fuentes que agrega era secreta. Estaban todas ahí. Pero cada una imponía su propio peaje, pequeño y aburrido:

• MalwareBazaar, de abuse.ch, pide desde 2024 una clave de autenticación para su API. Es gratis y se la dan a cualquiera, pero hay que ir, registrarse y aceptar una política de uso que se puede revocar.
• Esa misma política dice, con todas las letras, que no se suban gusanos ni infectores de ficheros.
• Los repositorios históricos tipo theZoo tienen su propio ritual: leer el aviso, entender la estructura, descifrar a mano.

Ninguna de esas puertas es fuerte. Ninguna detiene a nadie decidido. Todas son fricción: unos minutos, un formulario, un momento en el que quien está al otro lado se pregunta qué está haciendo.

El agregado las quita todas a la vez. Y las quita de una forma concreta que merece la pena mirar despacio: la colección resultante incluye exactamente la clase de cosa que la fuente más profesional de la lista se niega a alojar. MalwareBazaar rechaza gusanos por escrito; el archivo agregado los tiene, los documenta y explica cómo montar el laboratorio para contenerlos.

Cada fuente tomó su decisión pensando en su propio contexto. El agregado hereda todos los contenidos y ninguna de las decisiones.

Y esto no es una manía mía de administrador de sistemas. Es un criterio legal en al menos una jurisdicción: la guía de la fiscalía británica para el artículo 3A de la Computer Misuse Act —el que castiga fabricar, suministrar u obtener herramientas para delinquir— dice que, para valorar si era «probable» que se usaran mal, hay que mirar, entre otras cosas, si el material circuló en una lista cerrada y verificada de profesionales de seguridad o se publicó abiertamente. La fricción no es un detalle de implementación. Para un fiscal inglés es una prueba.

El cifrado protege en las dos direcciones

Hay una segunda ironía, y esta es puramente técnica.

Cifrar las muestras es la decisión correcta: evita el doble clic accidental, evita que el antivirus del investigador se coma el corpus a media descarga y evita que un fichero suelto se ejecute accidentalmente. Todo eso es cierto.

Y a la vez, un ZIP cifrado es opaco para cualquiera que quiera mirar dentro por el camino. Es exactamente el mismo mecanismo que usa un correo fraudulento cuando te manda un adjunto «protegido» con la contraseña escrita en el propio mensaje, que es una historia que ya conté con las cabeceras de uno en la mano. La medida que protege tu equipo es la que hace que el fichero cruce la pasarela de correo de tu empresa sin que nadie le mire la tripa.

No hay contradicción: es la propiedad del cifrado, funcionando como debe. Lo que no hay es forma de quedarse solo con la mitad buena.

El contraste está en la solución que se inventó la industria para no tener este problema nunca: el fichero de prueba EICAR, sesenta y ocho bytes de ASCII imprimible que los antivirus detectan por acuerdo y que no hacen absolutamente nada. Se acordó precisamente para que nadie tuviera que tocar un virus de verdad solo para comprobar si su antivirus estaba despierto.

Conviene decir hasta dónde llega eso, porque no es un argumento contra las muestras reales. EICAR resuelve sin ningún riesgo una necesidad muy concreta: saber que la cadena de detección está despierta. Para el resto —análisis de comportamiento, firmas, sandboxing, forense— pueden hacer falta muestras reales, y quien las necesita existe y su trabajo importa. Para la comprobación cotidiana, la que hace casi todo el mundo casi todo el tiempo, no hace falta ninguna.

Ahora hablemos del que lo abre por probar

En estas conversaciones siempre aparecen dos personajes: el investigador serio y el criminal. Y quien se descarga estas cosas casi nunca es ninguno de los dos.

La cifra que mejor lo resume la publicó la Agencia Nacional del Crimen británica en su informe Pathways into Cyber Crime: la edad media de sospechosos y detenidos en las investigaciones de su unidad de cibercrimen en 2015 era de 17 años. En sus casos de drogas era 37. En delitos económicos, 39. Y el informe añade la conclusión que lo explica: la barrera de entrada por habilidad técnica está más baja que nunca.

Los ejemplos no son teóricos.

Febrero de 2001. Jan de Wit, veinte años, holandés, fabrica el gusano de Anna Kournikova en unas horas usando un generador de gusanos hecho por otro. No lo escribió: lo generó. El tribunal rechazó en septiembre su alegación de que no pretendía causar daño y le cayeron 150 horas de trabajos comunitarios. La herramienta puso casi todo; él puso las ganas.

2016. Paras Jha, Josiah White y Dalton Norman montan Mirai. No para tirar internet: para servidores de Minecraft. Tenían una empresa de mitigación de ataques y tumbaban a los servidores de la competencia para que sus clientes se mudaran. En 2018 les cayeron cinco años de libertad vigilada, 127.000 dólares y 2.500 horas de trabajos comunitarios, con una rebaja del 85 % por cooperar con el FBI. Jha, además, había atacado la red de su propia universidad, Rutgers.

Mayo de 2026, Motril. La Policía Nacional detiene a un chaval de dieciséis años por difundir datos personales de miembros del INCIBE, del Consejo de Seguridad Nacional, de la Fiscalía General del Estado, de la Agencia Tributaria, de la Policía y de la Guardia Civil. Según la información oficial, estudiaba bachillerato sin relación con la informática, era autodidacta, no tenía antecedentes y no había motivación económica: buscaba notoriedad. El material se intervino en su habitación, en casa de sus padres.

Ese último caso es de hace tres meses, en España, y tiene todos los ingredientes: capacidad suficiente, intención difusa, cero cálculo de consecuencias y un registro domiciliario en un cuarto de adolescente.

Tampoco hace falta equipo. Arion Kurtaj, condenado en 2023 por los ataques del grupo Lapsus$ a BT/EE y a Nvidia, filtró los vídeos de GTA VI desde la habitación de un hotel, con un Fire Stick, la tele del cuarto y un móvil.

La curva que baja no es la de la capacidad. Es la del esfuerzo que hay que hacer antes de que ocurra algo.

Una gamberrada es una gamberrada mientras se pueda deshacer

Y aquí llega la palabra que me llevó a escribir esto: gamberrada.

Yo no creo que el problema sea la gamberrada. Creo que el problema es que la gamberrada informática no escala como la de toda la vida, y que eso a los quince años no lo sabe nadie.

Un petardo en un portal afecta a un portal. Un gusano afecta a lo que alcance, y no sabe que era una broma. Es literalmente el caso de NotPetya: en junio de 2017 se soltó contra objetivos ucranianos un programa que parecía ransomware y en realidad destruía datos sin posibilidad de recuperarlos. Se escapó. La naviera Maersk se comió entre 200 y 300 millones de dólares en ingresos perdidos, y la Casa Blanca cifró después el daño global en más de 10.000 millones. En collections/ hay una carpeta que se llama NotPetyaFileEncryptor.

Lo que separa una gamberrada de un delito no suele ser la intención. Suele ser la reversibilidad y la contención: que se pueda deshacer y que no se extienda. El código que se autopropaga no tiene ninguna de las dos.

El mejor ejemplo de esto es, curiosamente, una gamberrada que salió bien. El 30 de abril de 2021, Minh Duong, estudiante de secundaria, se hizo con todas las pantallas en red de su distrito escolar de Illinois —seis institutos, más de once mil alumnos— y las puso a reproducir a Rick Astley, sincronizadas. Encontró por el camino fallos que nadie conocía en el sistema de televisión IP del distrito.

No lo denunciaron. Le dieron las gracias. ¿Por qué? Porque se podía deshacer apagando las pantallas, porque no salió del distrito y porque lo que entregó al final fue un informe con los fallos y cómo arreglarlos, que acabó en el fabricante.

Esa es la diferencia, y no es de talento. Es de contención.

Y va en las dos direcciones, por cierto: el pseudoinocente también es la víctima. En un estudio publicado en 2016, un equipo de las universidades de Illinois y Michigan y de Google dejó tiradas 297 memorias USB por un campus; el 48 % acabaron enchufadas y con alguien abriendo archivos, la primera en menos de seis minutos. Y el hallazgo que más me gusta: la mayoría las enchufaba para buscar al dueño. La buena fe también es un vector.

Y una pregunta que casi nadie se hace: quién paga

Esta es la parte que menos gracia hace y la que más falta escribir, porque en casa esto se habla poco.

En España, la posesión de una muestra de malware no está tipificada por sí sola. Lo que castiga el artículo 264 ter del Código Penal es producir, adquirir para su uso, importar o facilitar a terceros un programa concebido o adaptado principalmente para cometer daños informáticos «con la intención de facilitar la comisión» de esos delitos: de seis meses a dos años de prisión, o multa. El 197 ter hace lo mismo para los delitos contra la intimidad. En los dos, la bisagra es la intención, no el fichero.

Lo cual está bien, y tiene una consecuencia incómoda: la intención no la evalúas tú. La evalúa alguien que llega después, mirando tu disco duro, tu historial y tus conversaciones. Y fuera de aquí el listón cambia: Alemania castiga desde 2007, en el §202c de su código penal, la preparación con herramientas de este tipo —el famoso Hackerparagraf, que el Chaos Computer Club lleva desde entonces pidiendo que se derogue—, y el Reino Unido incluye en su artículo 3A el hecho de obtener el material con la vista puesta en un delito.

Y luego está el artículo que a mí me parece que debería salir en todas las charlas de instituto. Cuando quien lo hace es menor de dieciocho años, el artículo 61.3 de la Ley Orgánica 5/2000 dice esto:

Cuando el responsable de los hechos cometidos sea un menor de dieciocho años, responderán solidariamente con él de los daños y perjuicios causados sus padres, tutores, acogedores y guardadores legales o de hecho, por este orden.

Solidariamente. Y la moderación que permite el mismo párrafo cuando los padres no favorecieron la conducta con dolo o negligencia grave es eso, una moderación que decide el juez: no una exención.

Dicho en la lengua de casa: si el chaval de dieciséis años que hay en tu salón le tira la web a alguien un martes por la noche por ver qué pasa, de los daños respondes tú. No hace falta que hayas lanzado el ataque: la ley parte de que, si es tu hijo menor de edad, respondes solidariamente con él.

Escribo esto como el aita que tuvo que revisar tres ordenadores en cuarenta minutos porque unos mods de Steam llevaban malware dentro, en un juego que había instalado yo. Aquella vez el susto vino de fuera. Esta conversación va del susto que puede salir de dentro, y es bastante peor.

Lo que sí se puede pedir

No creo que la conclusión sea «que no se publique». La investigación defensiva necesita muestras reales, el corpus curado tiene valor didáctico auténtico y el trabajo de catalogación —integrar diecinueve colecciones y hacerlas buscables— es un trabajo de verdad.

Lo que se puede pedir es que la fricción forme parte del diseño y no del README. Cuatro cosas concretas:

1. Las muestras, fuera del árbol de git. Metadatos, hashes, fichas y línea de tiempo en abierto —que es donde está casi todo el valor educativo—, y los binarios detrás de un paso que haya que dar a propósito. El proyecto ya trae el script para bajarlas de MalwareBazaar: el corpus podría reconstruirse en vez de venir empaquetado.
2. Heredar también las decisiones de cada fuente, no solo sus ficheros. Si el proveedor más serio de la lista no acepta gusanos, esa política dice algo que el agregado no debería descartar en silencio.
3. Una licencia explícita en la raíz. Hoy la API de GitHub no le ve ninguna; el README dice que cada subcolección conserva la suya, en su carpeta. Está bien decirlo, y es justo donde no lo va a mirar quien clone el conjunto entero.
4. Asumir que no hay botón de deshacer. Es la única de las cuatro que no depende del autor, y por eso es la que hay que tener en cuenta antes de publicar y no después.

Es la misma diferencia que importa cuando el horizonte se ha quedado en mañana: una cosa es asumir un riesgo que puedes corregir después y otra decidir cuando ya no habrá una segunda oportunidad.

Y para el otro lado de la casa, el consejo que de verdad me interesa dejar por escrito. Si te encuentras este repositorio —o herramientas de ataque, o un booter, o un troyano de acceso remoto— en el portátil de alguien de quince años, la reacción útil no es el castigo. La curiosidad es la materia prima; no hay forma de fabricar a un profesional de seguridad sin ella, y quien se la corta no obtiene un adolescente prudente: obtiene uno que no se lo cuenta.

Lo que hay que enseñar es lo otro, que es lo que no enseña nadie: la contención. Que la máquina virtual va sin red. Que el laboratorio es el laboratorio. Que lo que se autorreplica no distingue tu red de pruebas de la red de casa. Que la diferencia entre Minh Duong y una detención en Motril no está en lo que sabían: está en dónde terminó lo que hicieron y en qué hicieron con ello después. Es el mismo error de fondo que dar por hecho que aquí no hay nada que robar, solo que en espejo: sentirse a salvo de las consecuencias en vez de a salvo del ataque.

Y sí, lo he enlazado

Se me ocurrió no poner el enlace al repositorio. Estuve un rato con la duda.

Está ahí arriba, en el primer párrafo, y la razón es la propia tesis de este artículo. Está en la portada de un medio generalista, tiene 569 estrellas y 129 forks públicos. Un enlace menos en un blog personal no evita el acceso, y sí cambia una cosa: convierte un texto que se puede comprobar en uno que hay que creerse. Todos los números de aquí arriba salen de la API de GitHub y del README el 10 de septiembre, y cualquiera tiene que poder ir a mirar si sigo teniendo razón la semana que viene.

La fricción funciona de verdad antes de publicar. Después ya no sirve para recuperar el control: solo para dificultar la siguiente copia.

Que es, exactamente, lo que este artículo intenta decir sobre los ZIP.

Datos del repositorio comprobados el 10 de septiembre de 2026 contra la API de GitHub y su README: 2.916 muestras, 84 familias, 19 carpetas en collections/, 569 estrellas, 129 forks públicos, 5.911.165 KB de tamaño declarado. Tres días antes, cuando empecé a escribir esto, eran 491 estrellas y 114 forks. Volverán a cambiar, y esa es media noticia.