“Claude & Control” plantea una idea incómoda pero útil para equipos de seguridad: si un agente con capacidades de computer use puede interactuar con un escritorio (navegador, terminal, apps) como lo haría una persona, entonces el concepto de Command & Control (C2) deja de ser solo “malware hablando con un servidor” y pasa a ser “un operador remoto que automatiza acciones de usuario a escala”. La diferencia no es semántica: cambia la superficie de ataque, el tipo de telemetría que importa y los puntos donde conviene poner fricción.
En empresas, esto se vuelve tangible cuando hay escritorios virtuales, RPA, jump hosts, navegadores endurecidos y SSO: el atacante ya no necesita explotar binarios exóticos si puede encadenar acciones legítimas (login, búsqueda en el portal interno, descarga de un export, cambio de configuración) guiado por un agente. Defenderlo exige pensar en “comportamientos” y “capacidad de ejecución”, no solo en IOC tradicionales.
Qué significa Agentic C2 cuando el agente “usa el ordenador”
En un C2 clásico, el endpoint comprometido ejecuta instrucciones a través de un canal (HTTP/S, DNS, etc.) y el control se expresa en comandos del sistema. En un Agentic C2 con Computer Use Agents, la instrucción puede ser de alto nivel (“abre el panel de administración y crea un nuevo token”) y la ejecución se materializa como clicks, navegación, copiado/pegado y uso de aplicaciones.
Esto tiene un efecto directo en la defensa: muchas acciones dejan de parecer “técnicas” y pasan a parecer “operativa de usuario”, pero con una velocidad, repetición y consistencia que un humano no tiene. Además, el agente puede adaptarse al entorno (cambios de UI, mensajes de error) y reintentar con variantes, lo que erosiona controles basados en rutas fijas.
En entornos corporativos, el impacto más frecuente no es “exfiltración inmediata a través de un backdoor”, sino abuso de herramientas internas: portales ITSM, consolas cloud, paneles de proveedores SaaS, VPN/VDI, e incluso flujos de aprobación donde el agente intenta forzar el camino con ingeniería social y automatización. El C2 se vuelve una coordinación entre: instrucciones del operador, razonamiento del agente y acciones en la interfaz.
Arquitectura típica: dónde vive el control y dónde se filtra el riesgo
Una arquitectura común para Computer Use Agents incluye: un runtime del agente (modelo + orquestación), un “entorno de ejecución” (VM/VDI/contenedor con navegador y herramientas), conectividad saliente a servicios externos (incluyendo el canal de control), y acceso a credenciales o tokens para operar aplicaciones. Cada bloque introduce riesgos distintos: el modelo puede ser inducido, el entorno puede ser persistente, y las credenciales pueden quedar expuestas en texto/clipboard/logs.
En la práctica, el punto crítico suele ser el entorno de ejecución: si el agente opera dentro de una VDI con SSO y acceso a consolas sensibles, el “radio de acción” se dispara. El C2 no necesita entrar por un endpoint corporativo; puede vivir fuera (un host controlado por el adversario) y aun así operar “como empleado” si obtiene credenciales o sesión.
- Canal de control y observabilidad: si la orquestación del agente se apoya en APIs externas, el tráfico saliente y los patrones de llamadas se convierten en señal defensiva.
En empresa, esto se traduce en revisar egress (proxy, CASB, firewall) y registrar con suficiente detalle: dominios, SNI/JA3 cuando aplique, volumen y periodicidad. No basta con “permitir HTTPS”; hay que poder atribuir qué proceso/host realiza la comunicación y si coincide con el uso esperado.
- Persistencia de sesión: cookies, tokens y estados de navegador que quedan vivos entre ejecuciones facilitan que el control sea continuo.
Si el agente reutiliza perfiles de navegador o snapshots de VDI, un incidente puede convertirse en un “acceso duradero” sin necesidad de malware adicional. La consecuencia real es que la rotación de contraseña no corta el acceso si hay sesiones activas no revocadas en SaaS o en IdP.
- Fugas por artefactos: capturas, logs del agente, historial de comandos o el portapapeles pueden contener secretos.
Esto aparece en auditorías internas: el equipo habilita logging “para depurar”, el agente imprime tokens o pega credenciales en un formulario, y esos datos terminan en un bucket o en un sistema de tickets. El riesgo no es teórico; es un patrón recurrente cuando se mezclan automatización y troubleshooting.
Escenarios de abuso realistas: del “haz clic aquí” a operar tu SaaS
El abuso más verosímil no empieza con un agente “superinteligente”, sino con un operador que guía tareas concretas. Por ejemplo: obtener acceso a una cuenta de baja fricción (proveedor, becario, cuenta con MFA débil) y luego usar un agente para recorrer UI complejas a escala: localizar paneles, exportar listados, crear integraciones, generar API keys y probar permisos.
Un rasgo diferencial del Agentic C2 es la elasticidad: si el portal cambia, el agente no se rompe como un script rígido; intenta alternativas. En un incidente real, esto complica el playbook del defensor porque el atacante puede “pivotar” sin desplegar nuevas herramientas: basta con nuevas instrucciones.
- Creación de credenciales duraderas en SaaS: el agente navega a “Integrations/API” y genera un token con scopes amplios.
La consecuencia empresarial típica es que el “punto de entrada” (una sesión web) deja de importar; el token vive fuera, y la actividad posterior se mueve a API, a menudo desde infra del atacante. Si no hay inventario de tokens ni alertas de creación/uso anómalo, el equipo llega tarde.
- Abuso de flujos internos: apertura de tickets, cambios de grupo, solicitudes de acceso y aprobaciones con ingeniería social asistida.
Visto en operaciones: el agente redacta solicitudes convincentes, adjunta capturas y persiste hasta lograr una excepción. La defensa aquí es menos “bloquear malware” y más “controlar privilegios y verificaciones humanas” con señales adicionales (origen, contexto, velocidad, historial).
- Exploración de consolas cloud: localizar roles, cuentas, buckets, secrets managers y rutas de escalado vía configuración.
Incluso con IAM decente, la UI de cloud permite descubrir mucho. Un agente puede recorrer páginas y recopilar inventario. Si el equipo solo monitoriza llamadas API y no accesos interactivos a consola (o no revisa la auditoría), pierde el preludio del ataque.
Cómo hacerlo en la práctica: guardrails que ponen fricción sin romper el negocio
La respuesta efectiva no es “prohibir agentes”, sino encajarlos en un entorno controlado donde su capacidad de acción esté acotada. El objetivo operativo es reducir el impacto de un C2 agentic aunque el agente tenga instrucciones maliciosas o sea manipulado por contenido (prompt injection) durante la navegación.
Empieza por separar “entorno del agente” de “entorno del usuario” y por tratar al agente como una carga de trabajo de alto riesgo: sin acceso directo a datos sensibles, sin egress libre y con credenciales de vida corta. Si el agente necesita operar una consola, que lo haga con roles específicos, sin permisos de escritura por defecto y con aprobación para acciones peligrosas.
- Crear un entorno de ejecución desechable: VDI/VM efímera por tarea, sin perfil persistente y con borrado al terminar.
Acción concreta: configurar imágenes doradas con navegador endurecido, deshabilitar almacenamiento de contraseñas, limpiar cookies al cerrar, y destruir la instancia al finalizar. Valida que no queda estado revisando que el siguiente arranque no hereda historial, cookies ni tokens (prueba con un SaaS de laboratorio y confirma que no hay sesión activa).
- Configurar egress con allowlist y proxy autenticado: salida solo a dominios necesarios, con inspección/registro.
Acción concreta: enrutar todo tráfico del entorno del agente por un proxy corporativo con autenticación y políticas por destino. Verifica en logs que cualquier intento de acceso a dominios no permitidos queda bloqueado y queda trazabilidad por identidad/host. Esto reduce la viabilidad de canales C2 improvisados.
- Usar credenciales de corta duración y mínimo privilegio: roles temporales y scopes mínimos para la tarea.
Acción concreta: si hay integración con cloud, prioriza roles con sesión corta y permisos específicos. Como referencia técnica (AWS), una trust policy típica para asumir un rol desde un identity provider o desde una cuenta controlada debería limitar principal y condiciones. Ejemplo de trust policy restringida por cuenta y external ID (ajústalo a tu caso):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:root"},
"Action": "sts:AssumeRole",
"Condition": {"StringEquals": {"sts:ExternalId": "agent-run-locked"}}
}]
}
Validación operativa en AWS: revisa CloudTrail para confirmar que las sesiones del rol tienen duración corta, que el AssumeRole solo ocurre desde el principal esperado y que no existen acciones fuera de los permisos definidos. Complementa con alertas en eventos de creación de access keys, cambios de policy y elevaciones de privilegio.
Detección y respuesta: señales que sí cambian con agentes de computer use
Si el atacante opera vía UI, muchas detecciones tradicionales basadas en procesos o payloads no saltan. En su lugar, cobra valor correlacionar identidad + comportamiento + contexto: velocidad de navegación, secuencias improbables de acciones, acceso a páginas poco frecuentes, y creación de credenciales en momentos atípicos.
En un SOC maduro, esto implica unir telemetría de IdP (SSO, MFA), logs de SaaS (auditoría de admin), proxy/secure web gateway y, cuando exista, registros de VDI. El patrón que verás no es “ejecución de Mimikatz”, sino “usuario X creó token Y, luego hubo llamadas API desde ASN extraño, y antes hubo navegación intensiva por consola”.
- Señales de UI automation: ráfagas de acciones repetitivas, tiempos de interacción demasiado regulares, y navegación que “barre” menús.
Esto no se resuelve con una regla simple, pero sí con baselines: qué hace un admin real en una semana normal. La consecuencia de no hacerlo es que el primer aviso llega cuando ya hay export masivo o cambios de configuración. Si tienes VDI, captura métricas de sesión (duración, destinos, apps abiertas) y correlaciónalas con eventos de auditoría de SaaS.
- Eventos de “creación de capacidad”: nuevos tokens, nuevas apps OAuth, nuevos webhooks, nuevos usuarios/roles.
En respuesta a incidentes, prioriza revocar lo que habilita persistencia: tokens, integraciones y sesiones activas, no solo contraseñas. En empresas, este es un fallo común: se resetea la password y se deja viva una app OAuth con permisos amplios creada durante el incidente.
Recomendaciones para entornos corporativos
“Claude & Control” es útil para aterrizar que el C2 puede tomar forma de automatización de interfaz: el adversario no necesita herramientas ruidosas si puede dirigir un agente que opera aplicaciones como un usuario. Eso desplaza el foco defensivo hacia controlar el entorno de ejecución, el egress, la identidad y los artefactos que el agente genera.
Operativamente, lo que mejor funciona es poner límites claros: entornos efímeros para el agente, credenciales temporales y mínimas, y trazabilidad fuerte (proxy + auditoría de SaaS + IdP). A nivel de detección, prioriza señales de creación de persistencia (tokens/apps) y correlación de comportamiento en consola/UI, porque ahí es donde este modelo de C2 deja huella.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.