Anthropic: modelos de IA pequeños hacia la autorreplicación en IoT

El Frontier Red Team de Anthropic ha publicado una investigación sobre los llamados «AI worms»: malware que lleva consigo los pesos de un modelo de lenguaje y lo ejecuta directamente en los dispositivos comprometidos, sin depender de un centro de datos. La conclusión de los investigadores es que los modelos open-weight pequeños (30.000 millones de parámetros o menos) podrían estar a pocos meses de ser lo bastante capaces de replicarse solos en dispositivos IoT comerciales, como cajas de TV Android baratas u hornos conectados.

La noticia la han recogido SecurityWeek, Security Affairs, The Register, BleepingComputer, The Hacker News, Dark Reading y Ars Technica. No es una amenaza en circulación: no se ha observado ningún replicador autónomo completo, ni en laboratorio ni en internet. Para quien defiende, el valor de la investigación está en las cifras de cada paso y en las contramedidas.

Qué midieron los investigadores

Anthropic divide la replicación en cuatro fases: encontrar objetivos, obtener ejecución de código, poner en marcha la inferencia en el nuevo dispositivo y propagarse a otros hosts. Según Ars Technica, los agentes disponían de herramientas de explotación comunes, como las reverse shells.

• Un modelo repartido en hardware barato. Gemma4-26B-A4B, cuantizado y dividido en partes, se ejecutó en 15 cajas de TV Android sin marca (unos 55 dólares cada una, 4 GB de memoria cada una). Funciona, pero a 0,39 tokens por segundo.
• Inferencia en hardware desconocido. Qwen3.5-9B logró instalar y configurar la inferencia de Llama3.1-8B en 8 de los 9 tipos de hardware probados, desde una Jetson Nano hasta un Mac. Es la fase que Anthropic considera menos estudiada y más difícil: elegir software compatible, instalar dependencias, corregir errores propios de cada plataforma.
• Ciclo completo. En una red cerrada de ocho dispositivos Android emulados (instancias en la nube con un emulador de Android 15, según The Register), solo GLM-5.2 completó la replicación desde cero, propagando Llama3.1-8B a los ocho nodos en 4 de 5 pruebas (siete de ocho en la quinta). Los demás modelos open-weight probados fallan de forma sistemática; The Register señala que el informe no dice cuántos eran.
• Aprendizaje entre generaciones. Cada copia deja a la siguiente notas sobre lo que ha intentado y lo que no ha funcionado. El éxito de Qwen3.5-9B en una tarea de configuración subió del 45% inicial a valores entre el 61% y el 84% en seis generaciones. Darle como asesor un modelo más potente (Opus 4.8) no aportó mejoras medibles.

Los tiempos siguen siendo largos: para poner en marcha la inferencia, BleepingComputer indica 28–51 horas con Qwen3.5-9B (29–51 según Ars Technica) y 71–150 horas con Gemma4-26B-A4B. El tiempo de duplicación estimado es de días; Mirai, en 2016, se duplicaba en aproximadamente una hora.

Los límites del estudio

Las fuentes coinciden en algunos puntos que relativizan el resultado:

• la explotación se hizo trivial: los objetivos exponían ADB (Android Debug Bridge) sin autenticación. Anthropic considera los resultados un límite superior respecto al mundo real y remite a estudios anteriores sobre la capacidad de los modelos pequeños para explotar vulnerabilidades;
• la replicación completa solo funcionó con GLM-5.2, que orquestaba el proceso mientras en los objetivos se ejecutaba un modelo más pequeño;
• según The Register, también se utilizó un entorno de trabajo creado a propósito, llamado Memento.

The Register es el medio más crítico y habla de una amenaza que todavía no existe. En Ars Technica, el investigador Xiaohan Fu observa que el estudio no demuestra que un modelo elegiría replicarse por sí mismo, y pide publicar prompts y configuraciones para que sea reproducible.

La proyección de Anthropic es condicional: si los modelos pequeños siguen mejorando al ritmo histórico, alcanzarán el nivel de GLM-5.2 antes de finales de 2026, y los replicadores basados en pesos «podrían ser posibles poco después».

Por qué importa a quien defiende

La diferencia con las botnets tradicionales es la capacidad de adaptación. Mirai y Kimwolf (más de dos millones de dispositivos infectados, sobre todo cajas de TV Android) están escritas para tipos de dispositivo y exploits concretos; un agente de IA, según Anthropic, puede entender por sí solo un hardware que no conoce. Según Ars Technica, los pesos podrían viajar con el malware o volver a descargarse de un hub público de modelos, y pasar a formar parte del payload.

Esas mismas características lo hacen visible. Según el cálculo que recoge SecurityWeek, una botnet del tamaño de Kimwolf alojaría unas 133.000 copias del modelo de 26.000 millones de parámetros, con una potencia total equivalente como máximo a unas 40 GPU Nvidia H100. Y mover archivos de varios gigabytes entre dispositivos que normalmente no se comunican deja rastro.

Impacto para las empresas europeas e italianas

Cajas de TV, pantallas de salas de reuniones, cámaras, electrodomésticos conectados: en muchas empresas están en la misma red que los ordenadores, a menudo con credenciales de fábrica. Es el mismo perímetro que ya explotan hoy las botnets IoT clásicas, y la investigación no cambia las prioridades: en todo caso, aumenta su urgencia.

Para las entidades sujetas a NIS2, el artículo 21 exige gestión de activos, de vulnerabilidades y seguridad en la cadena de suministro: los dispositivos IoT no gestionados entran en el perímetro. Anthropic señala como palanca a largo plazo a fabricantes y reguladores (sin contraseñas predeterminadas, actualizaciones de firmware obligatorias, certificaciones más estrictas) y cita al Reino Unido, que ya ha prohibido las contraseñas predeterminadas en dispositivos IoT. En la Unión Europea va en la misma dirección el Cyber Resilience Act, que incluye entre sus requisitos esenciales la configuración segura por defecto.

Qué hacer ya

1. Haz el inventario de los dispositivos IoT y de consumo en las redes de la empresa, incluidas cajas de TV y dispositivos traídos por proveedores o empleados. Retira los que no tienen marca o no reciben actualizaciones.
2. Cierra ADB en red (normalmente en el puerto TCP 5555) y comprueba que no sea accesible ni desde internet ni desde la red interna.
3. Cambia las credenciales de fábrica y desactiva Telnet y los demás servicios de gestión que no uses.
4. Segmenta: dispositivos IoT en una red separada, sin tráfico hacia los servidores y, cuando sea posible, tampoco entre ellos.
5. Filtra el tráfico saliente del IoT, permitiendo solo los destinos necesarios, incluidas las descargas desde hubs públicos de modelos.
6. Busca las anomalías que señala la investigación: transferencias de archivos grandes hacia o desde dispositivos IoT, tráfico continuo entre dispositivos que no suelen comunicarse, escaneos que parten de un dispositivo IoT.
7. Prepara la cuarentena: en la limpieza de Mirai que cita Anthropic, aislar a los abonados infectados y guiarlos en la limpieza eliminó el 92% de las infecciones en 14 días, frente al 74% sin aviso.

Cómo ayuda ARXDOME

ARX Watch encuentra en la red los dispositivos sin sonda, como cajas de TV, cámaras e impresoras, escuchando las peticiones DHCP y las tablas de vecinos, y avisa cuando aparece uno nuevo. ARX Expose muestra desde fuera los puertos abiertos y los servicios expuestos por error, como un ADB accesible desde internet. ARX Sentry lleva los logs de los firewalls a las páginas del SOC y al mapa del NOC, con las conexiones rechazadas y el tráfico saliente bloqueado, también el de los dispositivos IoT.

Última actualización: 14 de octubre de 2026