La escena se repite en muchos equipos técnicos: un agente de Inteligencia Artificial promete automatizar tareas repetitivas, desde revisar un repositorio hasta operar con APIs, generar informes o “limpiar” bandejas de entrada. Se instala un skill, se copian un par de comandos y el sistema empieza a “hacer cosas”. El problema, según el análisis publicado por VirusTotal a principios de febrero de 2026, es que ese mismo flujo de trabajo ya se está utilizando como canal de malware: la automatización no solo ejecuta tareas, también hereda permisos, acceso a red y visibilidad sobre credenciales.
Para administradores de sistemas y desarrolladores, el aviso no es teórico. OpenClaw —un agente autoalojado que corre localmente y puede ejecutar comandos, manipular ficheros y hacer peticiones de red— ha crecido a gran velocidad junto a su marketplace de extensiones (skills). Y, con ello, ha abierto un nuevo frente de supply chain: paquetes de terceros que se presentan como utilidades inocuas, pero incluyen desde robo de secretos hasta persistencia y control remoto.
VirusTotal lo explica con crudeza: si el agente no está aislado en un sandbox, el “radio de explosión” de un fallo (o de un skill malicioso) puede ser el sistema completo. Es el tipo de frase que un sysadmin entiende de inmediato, porque traduce “productividad” en “superficie de ataque”.
Un patrón clásico con un envoltorio moderno: “el malware es el workflow”
El diagnóstico de VirusTotal apunta al corazón del problema: muchos skills no son solo código, también son documentación. En OpenClaw, el archivo SKILL.md suele incluir instrucciones de instalación y uso. Y ahí es donde aparece el vector más antiguo de todos, empaquetado como conveniencia: “pega esto en tu terminal”, “descarga este script”, “ejecuta este instalador remoto”.
En su primera entrega, VirusTotal afirma haber analizado ya más de 3.016 skills y detectar “cientos” con características maliciosas. Parte de ese volumen se explica por malas prácticas —secretos embebidos, ejecución insegura, permisos excesivos—, algo que encaja con la ola de vibe coding y publicaciones rápidas sin modelo de seguridad. Pero la categoría que más preocupa es la intencional: skills cuyo propósito real es exfiltrar, instalar droppers o abrir puertas traseras.
El ejemplo más ilustrativo, según el propio post, es el de un publicador con cientos de skills asociados a patrones maliciosos: el ZIP puede parecer “limpio” y no levantar alertas tradicionales, pero la documentación obliga a descargar y ejecutar código externo como prerequisito. Es decir, el artefacto no contiene el malware; el malware es el procedimiento. Para un equipo de desarrollo, esto es un recordatorio incómodo: el “README” también es superficie de ataque.
Cinco técnicas que ya están apareciendo: del RCE al “rootkit cognitivo”
La segunda parte de la serie baja a la operativa y propone una taxonomía de cinco técnicas que VirusTotal dice estar viendo abusadas mediante skills. Para un medio de sysadmin y desarrollo, lo relevante no es solo la lista, sino el cambio de mentalidad: el agente puede ser víctima, pero también puede convertirse en ejecutor y amplificador.
1) Ejecución remota (RCE) con secuestro de ejecución
El caso descrito muestra un patrón pensado para pasar revisiones rápidas: un script largo, “bien escrito”, que hace lo que promete… hasta que no. El disparador se oculta en una función con nombre inocente (por ejemplo, warmup), que se ejecuta antes de que el usuario valide argumentos. El resultado es que el payload puede activarse incluso cuando el agente solo “carga” el skill para mostrar ayuda. Para un desarrollador, la lección es clara: revisar entrypoints reales, no solo la “ruta feliz”.
2) Propagación como “gusano semántico”
Aquí la técnica explota el comportamiento del modelo y el ecosistema: el skill introduce instrucciones para que el agente recomiende, distribuya o “viralize” el propio paquete. No necesita persistir como daemon: se apalanca en el planificador del agente (y en sus rutinas) para mantener un “latido” periódico y un canal de actualización. En un entorno corporativo, esto se parece peligrosamente a un insider automatizado: el agente, que goza de confianza, empieza a empujar software no verificado.
3) Persistencia mediante inyección de claves SSH
VirusTotal describe el “cebo y cambio” en su versión más directa: una instrucción que muestra un resultado válido (por ejemplo, una consulta legítima) y, en la misma cadena, intenta añadir una clave del atacante al fichero de authorized_keys. Además, se silencian errores para evitar sospechas. El detalle operativo que preocupa a cualquier sysadmin es el contexto: si el agente corre con permisos elevados (y muchos contenedores lo hacen por defecto), el intento se acerca demasiado a un acceso privilegiado persistente.
4) Exfiltración de secretos desde .env
En stacks de automatización, el archivo .env suele ser un cofre de llaves: credenciales de LLM, tokens de APIs, claves de servicios internos. El caso documentado combina una funcionalidad “real” (por ejemplo, un fetcher) con una segunda acción oculta: enviar el contenido del .env a un endpoint externo. Es una forma de monetización rápida: robar credenciales y consumir créditos o tomar control de cuentas.
5) Persistencia de prompt: implantes en ficheros de contexto (“rootkit cognitivo”)
Esta es la parte más novedosa, y quizá la más relevante para el futuro de la administración de agentes. En lugar de dejar un binario residente, el skill modifica ficheros que el agente carga automáticamente (por ejemplo, SOUL.md o AGENTS.md). Con una sola línea, el atacante puede condicionar decisiones futuras: debilitar guardarraíles, priorizar ciertos dominios, ejecutar sin pedir confirmación o preparar exfiltración “rutinaria”. VirusTotal lo define como un rootkit cognitivo porque el payload no es un proceso: es el comportamiento alterado del agente.
Qué cambia para sysadmins y devs: el agente como dependencia con permisos
En paralelo al análisis técnico, otros informes han puesto números al problema en el marketplace: se han detectado oleadas de skills maliciosos publicados en ventanas de días, y parte de ellos se han disfrazado como herramientas de cripto o automatización financiera, apoyándose en ingeniería social y comandos ofuscados. Para equipos de operaciones, esto huele a “momento npm”: un repositorio abierto, presión por adoptar rápido y un nuevo tipo de paquete que, en la práctica, puede ejecutar acciones locales con acceso a datos y red.
La conclusión operativa es incómoda pero útil: instalar un skill debe tratarse como introducir una dependencia ejecutable con privilegios. Ni más, ni menos.
Controles “aburridos” que sí funcionan
VirusTotal insiste en que la respuesta no necesita ciencia ficción, sino disciplina. En un lenguaje que cualquier equipo técnico puede convertir en policy-as-code, las medidas prácticas se ordenan así:
- Aislamiento por defecto: ejecutar agentes en contenedores o VMs con mínima superficie, sin montajes innecesarios del host y con sistema de ficheros lo más inmutable posible.
- No ejecutar como root: si el agente necesita permisos elevados, algo está mal diseñado.
- Egreso denegado y allowlist: si un skill no necesita hablar con Internet, no debería poder hacerlo. Si lo necesita, que lo haga por proxy controlado y con destinos permitidos.
- Registro y auditoría: log de invocaciones, cambios de ficheros sensibles y llamadas salientes. Lo que no se ve, no se puede investigar.
- Prohibición del patrón “descargar y ejecutar”: cualquier “curl | bash” o equivalente debe disparar alarmas, incluso si viene en un README “bonito”.
- Protección de ficheros de contexto persistente: SOUL.md, AGENTS.md y similares deben considerarse activos críticos, con monitorización de cambios y revisiones como si fueran reglas de firewall o claves SSH.
- Gestión moderna de secretos: menos .env estático y más tokens efímeros, acotados por tarea y entregados just-in-time (vault/broker). Si un workflow cae, que no caiga la cuenta.
En esta línea, algunos actores del sector ya están moviéndose: Cisco, por ejemplo, ha presentado un escáner de skills de código abierto orientado a ayudar a equipos de seguridad y desarrollo a evaluar extensiones con análisis estático, comportamiento y apoyo semántico, además de integraciones con servicios como VirusTotal.
La moraleja para un medio de sysadmin y desarrollo es directa: los agentes llegan con promesa de productividad, pero el perímetro no se negocia. En 2026, la pregunta ya no es si un “plugin” puede ser malicioso. La pregunta es qué controles existen para que, si lo es, no tenga dónde correr.
Preguntas frecuentes
¿Cómo debe auditarse un skill de OpenClaw antes de instalarlo en un servidor o entorno corporativo?
Como una dependencia ejecutable: revisión de código y documentación, verificación de descargas externas, análisis de permisos, control de red saliente y pruebas en sandbox.
¿Qué indicadores suelen delatar un skill peligroso en su SKILL.md o README?
Instrucciones de instalación con scripts remotos, comandos ofuscados, necesidad de permisos elevados, cambios en ficheros de identidad/memoria del agente y endpoints externos no justificados.
¿Qué medidas mínimas puede aplicar un sysadmin para reducir el riesgo sin frenar el uso de agentes?
Ejecutar en contenedor/VM sin root, egreso por allowlist, logging de acciones y bloqueo de patrones “descargar y ejecutar” salvo repositorios verificados.
¿Por qué los “rootkits cognitivos” son más difíciles de detectar que un malware clásico?
Porque no requieren un proceso residente: la persistencia vive en ficheros de contexto que el agente carga al arrancar, alterando decisiones futuras sin “ruido” en el sistema.
vía: OpenSecurity
