Un equipo de investigación de Symantec, la división de ciberseguridad de Broadcom, ha documentado un agente de ataque que no usa un modelo de inteligencia artificial propio: busca en internet modelos de lenguaje que otras personas o empresas han dejado abiertos sin protección y los usa como cerebro para planear sus siguientes pasos. Sus operadores llamaban «modo Skynet» a la directiva que lo dejaba actuar solo. La factura del cómputo la paga el dueño del modelo secuestrado.

El hallazgo, publicado el 21 de octubre en el blog de inteligencia de amenazas de Symantec, describe una técnica que la industria denomina LLMjacking: apropiarse del acceso a un modelo ajeno. Lo relevante no es solo lo que el agente pretendía hacer, sino cómo se descubrió y, sobre todo, lo que el informe no llega a demostrar.

Cómo se descubrió

Symantec instaló un señuelo, un honeypot, que se hacía pasar por un servicio de IA expuesto en internet y sin protección. En verano de 2026, alguien le envió una petición completa como si fuera un modelo real: instrucciones de sistema, capas para saltarse las salvaguardas y un catálogo de herramientas ofensivas.

El señuelo no ejecutó ninguna de esas herramientas. Respondió con un mensaje genérico y la sesión terminó. Todo lo que se conoce del agente procede, por tanto, del contenido de esa petición, no de un ataque observado en marcha.

Durante el periodo de observación, según el informe, el señuelo registró más de 127.000 peticiones externas desde decenas de miles de direcciones distintas. La mayoría eran búsquedas de servicios de IA abiertos, pruebas con claves de API robadas e intentos de leer archivos de configuración expuestos.

Qué pretendía hacer el agente

El diseño es el de un agente autónomo. El modelo secuestrado razona y decide; los módulos del atacante ejecutan. Según el análisis, la petición incluía unas 74 herramientas: rastreo masivo de internet, explotación de fallos en programas y marcos web muy usados, volcado de bases de datos, robo de credenciales y despliegue de mineros de criptomonedas.

Entre los objetivos citados figuran servidores de VS Code, Django, Jupyter, Laravel, Supabase, Next.js y Flask, además de pasarelas de IA y servidores MCP, el protocolo con el que muchos asistentes se conectan a herramientas externas. Las instrucciones autorizaban hasta 100.000 pasos seguidos sin aprobación humana y describían un bucle: buscar nuevos objetivos, infectarlos, instalar el minero y reinfectar los equipos.

Para que el modelo obedeciera, la petición apilaba cuatro capas de manipulación, más una quinta con el catálogo de herramientas. Ocultaba qué modelo había detrás, presentaba la lectura de contraseñas y bases de datos como trabajo de desarrollo rutinario, asignaba al modelo un personaje para el que negarse equivalía a una traición y le ordenaba ignorar sus propios avisos de seguridad.

Al día siguiente llegó una segunda petición con un guion de órdenes codificado. Una vez descifrado por los investigadores, descargaba XMRig, un minero de la criptomoneda Monero, lo escondía en carpetas de go2rtc, un servidor de vídeo habitual en pasarelas de cámaras domésticas, configuraba cuatro grupos de minado de reserva y borraba registros de acceso en bucle. Tampoco se ejecutó.

Lo que no está demostrado

Aquí conviene leer con calma. Las cifras más llamativas del informe describen capacidades diseñadas o tráfico recibido por el señuelo, no daños confirmados:

  • Los 100.000 pasos son un límite fijado por el operador en sus instrucciones. No se observó ninguna campaña de esa duración.
  • Las 127.000 peticiones son tráfico recibido por el señuelo, no sistemas comprometidos.
  • Las 74 herramientas figuraban en la petición, pero el señuelo no las ejecutó. La petición incluía además un historial fabricado de tres llamadas previas contra un reto inocuo de una plataforma de entrenamiento, sin hallazgos graves.
  • El propio informe de Symantec no atribuye a este agente concreto ningún compromiso confirmado de una víctima real, ni identifica a sus autores. Medios como The Decoder e Infobae describen igualmente el diseño del agente y las instrucciones capturadas, sin daños comprobados.

Eso no resta interés al hallazgo. Muestra cómo se está empaquetando ya el uso ofensivo de la IA: alguien escribió, probó y envió un agente preparado para funcionar solo con el modelo de un tercero.

Cómo protegerse

Las recomendaciones de Symantec se dirigen a quien instala o expone modelos y agentes, desde grandes empresas hasta equipos que prueban un servidor propio:

  • No publicar en internet APIs de modelos, servidores de inferencia ni servidores MCP sin autenticación, incluidas las rutas de listado de modelos y de estado. Poner delante una pasarela y no dejar el servidor escuchando en todas las interfaces.
  • Tratar las claves de API de IA como credenciales críticas: rotarlas, limitar su alcance, sacarlas del código y vigilar consumos o gastos anómalos.
  • Restringir las conexiones de salida de las máquinas con IA para cortar rastreos, comunicaciones con servidores de control y descargas de mineros.
  • En la nube, exigir IMDSv2 con un límite de un salto para impedir el robo de credenciales del servicio de metadatos.
  • Mantener privilegios mínimos y aprobación humana para las acciones sensibles de los agentes, y actualizar y retirar de internet el software señalado como objetivo.

Para un usuario doméstico, la lección práctica es más simple: si se instala un servidor de modelos o una pasarela de cámaras, no debe quedar abierto a internet sin contraseña.

Por qué importa

Lectura de TodoWeb. Durante años, el miedo a los ataques con IA se centraba en textos de phishing mejor escritos. Este caso apunta a otra cosa: modelos ajenos convertidos en recurso gratuito para automatizar la intrusión. Que el agente no haya llegado a ejecutarse en el señuelo no lo convierte en inofensivo, pero sí obliga a separar capacidad diseñada de daño comprobado. La pregunta abierta es cuántos servicios de IA siguen hoy expuestos sin protección, una cifra que el informe no da.

Sigue la actualidad de la inteligencia artificial en la sección de IA. Sobre la importancia de parchear a tiempo, puedes leer también qué son los fallos críticos de PHP conocidos como «PHP2shell».

Fuentes

Elaborado por la redacción de TodoWeb con asistencia de inteligencia artificial a partir de las fuentes enlazadas. ¿Has visto un error? Escríbenos desde correcciones.