El malware está dejando de incorporar su lógica maliciosa para pasar a generarla en tiempo de ejecución con un modelo de lenguaje.
Durante décadas, el malware ha funcionado con una lógica sencilla de entender para quien defiende. El atacante escribe el código dañino, lo empaqueta con un conjunto de exploits elegido de antemano y lo distribuye. La defensa, a grandes rasgos, consiste en reconocer ese código conocido y bloquear las rutas de ataque que ya lleva incorporadas. Bajo ese modelo, parchear la vulnerabilidad concreta que explota una amenaza basta para frenarla.
Ese supuesto está empezando a resquebrajarse. Dos hallazgos, uno observado en la práctica y otro demostrado en laboratorio, apuntan en la misma dirección: el malware está dejando de incorporar su lógica maliciosa de forma predefinida para pasar a generarla en tiempo de ejecución con ayuda de un modelo de lenguaje. No se trata solo de que la IA ayude a escribir malware antes de un ataque, algo que ya conocíamos. Se trata de código que consulta a una IA mientras se ejecuta para producir, en el momento, exactamente lo que necesita frente a cada víctima.
Analizados por separado, cada caso es un dato aislado. Vistos juntos, dibujan una trayectoria clara y con consecuencias directas para cómo diseñamos nuestras defensas.
El Threat Intelligence Group de Google (GTIG) documentó en su informe de noviembre de 2025 una técnica a la que denominó «modificación just-in-time» [1]. La idea central es que el malware ya no lleva su código de evasión predefinido, sino que lo pide a un modelo de lenguaje durante la propia ejecución.
El ejemplo más ilustrativo es PROMPTFLUX, un dropper experimental escrito en VBScript identificado por GTIG a comienzos de junio de 2025. Su componente más novedoso es un módulo bautizado como «Thinking Robot», diseñado para consultar de forma periódica la API de Gemini y obtener código nuevo con el que evadir el software antivirus. Algunas variantes llegaban a instruir al modelo para reescribir el script cada hora, pidiéndole que actuara como un ofuscador experto de VBScript. Conviene ser precisos con su estado real: según Google, la muestra se encontraba en fase de desarrollo o pruebas, con funciones incompletas comentadas en el código, y no demostraba capacidad para comprometer una red o un dispositivo. Google, por su parte, inhabilitó las cuentas y las claves de acceso a Gemini vinculadas a esta actividad, con lo que cortó la vía por la que el malware consultaba al modelo.
Junto a él, GTIG describió PROMPTSTEAL, también conocido como LAMEHUG, atribuido al grupo APT28. A diferencia de PROMPTFLUX, este sí se observó en operaciones reales. Se trata de un recolector de datos que consulta un modelo de lenguaje, en concreto Qwen2.5-Coder a través de Hugging Face, para generar en tiempo de ejecución los comandos de recopilación de archivos e información del sistema. Según el análisis, ejecuta de forma directa los comandos que le devuelve el modelo y probablemente recurre a tokens de API robados.
Lo relevante de esta primera fase es una limitación que juega a favor de quien defiende. Todo este malware depende de un modelo alojado fuera del equipo comprometido. Para funcionar necesita hacer llamadas de red hacia una API externa, arrastra credenciales o tokens que en muchos casos son robados, y genera patrones de uso que pueden resultar anómalos. Cada una de esas señales es una oportunidad de detección.
Aquí es donde entra el segundo hallazgo, mucho más reciente. Un preprint publicado en arXiv el 2 de junio de 2026, elaborado por investigadores de la Universidad de Toronto, la Universidad de Cambridge y otras instituciones, presenta lo que describe como una amenaza de un tipo nuevo: un gusano que genera estrategias de ataque adaptadas a cada objetivo que encuentra [2].
La diferencia de fondo con el malware tradicional es que este no incorpora un conjunto de exploits predeterminado en el momento de compilarlo. En su lugar, utiliza un modelo de lenguaje de pesos abiertos ejecutándose en una sola GPU para generar la lógica de ataque en tiempo de ejecución, ajustada a lo que descubre en cada máquina. Para hacerlo, se apropia de la capacidad de cómputo del propio host comprometido y la dedica a su razonamiento.
Los resultados del experimento, realizado en una red aislada y deliberadamente vulnerable, ayudan a dimensionar el problema [2]. En 15 ejecuciones independientes sobre una red de 33 hosts que reproducía vulnerabilidades corporativas habituales, como contraseñas reutilizadas, el gusano identificó de media unas 31 vulnerabilidades, obtuvo acceso elevado en unos 23 hosts, aproximadamente tres cuartas partes de los que atacó de forma activa, y se replicó de manera autónoma a unos 20 hosts, en torno al 62 por ciento de la red, a lo largo de siete días. Todo ello sin conocimiento previo de la topología de la red y sin intervención humana.
Es importante situar este caso en su justa medida. Se trata de un preprint todavía en proceso de revisión por pares y de una prueba de concepto ejecutada en un entorno aislado y controlado, no de una amenaza observada en operaciones reales. Su valor no está en un daño causado, sino en lo que demuestra que es posible construir hoy con modelos disponibles públicamente y a bajo coste.
El hilo que conecta los dos hallazgos no es simplemente que «el malware usa IA». Es algo más concreto y con implicaciones más incómodas para la defensa. El malware que se apoya en IA está evolucionando desde depender de la nube hacia ser autosuficiente, y ese movimiento desactiva dos capas de defensa a la vez.
La primera capa es la detección basada en firmas. Funciona reconociendo código conocido. Pierde eficacia frente a un malware cuyo código se genera o se reescribe en cada ejecución, porque nunca hay dos ejecuciones idénticas que reconocer.
La segunda capa es la detección basada en el tráfico de red. En la fase que representan PROMPTFLUX y PROMPTSTEAL, el malware todavía tiene que llamar a una API externa, lo que permite detectar conexiones hacia endpoints de modelos de lenguaje, uso anómalo de claves de API o tokens robados en circulación. El gusano de Toronto elimina precisamente esa oportunidad al integrar el modelo en el propio malware. Si la inferencia ocurre en local, sobre la GPU del propio equipo, no hay llamada externa que interceptar.
Dicho de otro modo, un caso muestra lo que ya ocurre y el otro señala hacia dónde apunta la tendencia. Cada uno por separado es interesante. Juntos marcan una tendencia, y es esa tendencia la que conviene tener presente al planificar.
De esta trayectoria se derivan varias consecuencias prácticas que merece la pena ordenar.
El parcheo guiado por un único CVE parte de un supuesto que ya no siempre se sostiene. Asume que conocemos de antemano el exploit que hay que neutralizar. Cuando el malware puede inspeccionar los servicios expuestos, leer avisos de seguridad recién publicados y construir una ruta de ataque nueva en tiempo de ejecución, cerrar una vulnerabilidad concreta deja de ser suficiente. La respuesta razonable pasa por la defensa en profundidad y por reducir de forma agresiva la superficie de ataque.
La higiene básica gana peso, no lo pierde. Resulta significativo que el gusano de Toronto se apoyara en debilidades tan comunes como las contraseñas reutilizadas. La IA no necesita capacidades extraordinarias para progresar cuando encuentra sistemas mal protegidos. Se limita a explotar con rapidez lo que ya estaba mal configurado.
La detección debe desplazarse hacia el comportamiento. Frente a código que muta en cada ejecución, la monitorización de anomalías en tiempo de ejecución resulta más robusta que la comparación con firmas estáticas. Esto incluye vigilar el uso inesperado de recursos locales, como una actividad de GPU o de inferencia difícil de justificar en un equipo determinado.
Y la vigilancia del tráfico hacia modelos de lenguaje sigue siendo útil, aunque con una fecha de caducidad implícita. Detectar y controlar las conexiones salientes hacia APIs de IA, así como proteger y rotar las credenciales, mitiga la fase actual del problema. Conviene mantenerlo, pero sin olvidar que la variante autocontenida está diseñada precisamente para no emitir esa señal.
Ninguno de estos dos casos justifica el alarmismo. PROMPTFLUX era una muestra en pruebas sin capacidad demostrada de comprometer redes, y el gusano de Toronto es una prueba de concepto académica en un entorno aislado. Lo que sí justifican, tomados en conjunto, es revisar algunos supuestos que hemos dado por sentados durante mucho tiempo.
La conclusión no es que las defensas actuales hayan dejado de servir. Es que el modelo mental sobre el que se construyeron, el de un artefacto malicioso estático y reconocible, empieza a resultar insuficiente frente a un ataque que se genera en el momento y, cada vez más, sin depender de nada externo. Anticipar ese cambio hoy, mientras todavía es incipiente, es mucho más barato que reaccionar cuando se haya generalizado.
En Kaptor Security vigilamos de forma constante las nuevas tendencias en ciberseguridad e inteligencia artificial para anticiparnos a amenazas como las descritas en este artículo y trasladar ese conocimiento a defensas concretas. Si quieres evaluar la seguridad de tus integraciones de inteligencia artificial o revisar tus defensas frente a este tipo de amenazas, podemos ayudarte.