El hacker se desconectó. El agente de IA siguió trabajando: cómo Hermes podría cambiar el post-explotación
Un hacker ya no necesariamente necesita estar sentado frente a una computadora comprometida.
Puede potencialmente darle un objetivo a un agente autónomo de IA, proporcionarle acceso a un entorno, eliminar el paso de aprobación humana para acciones riesgosas y permitirle que continúe investigando mientras el operador está en otro lugar.
Eso es lo que hace tan importante el uso reciente de Hermes Agent en una operación dirigida contra el Ministerio de Finanzas de Tailandia.
Pero la historia no es que “la IA hackeó a un gobierno”.
El desarrollo más importante es este:
Un atacante que ya tenía acceso utilizó un agente autónomo de IA para realizar parte del trabajo repetitivo que normalmente requiere un operador humano.
La distinción importa.
La investigación de Hunt.io encontró infraestructura expuesta asociada con la operación, incluyendo herramientas de ataque, web shells, credenciales robadas y registros de Hermes. Los registros de Hermes mostraron al agente enumerando hosts del ministerio, recorriendo archivos y recopilando la salida de LinPEAS desde otro host. La investigación señala que el método de acceso inicial no era evidente de inmediato a partir del material recuperado.
The Hacker News informó por separado que Hermes fue operado en modo YOLO, lo que le permitía ejecutar acciones sin las solicitudes normales de aprobación para comandos potencialmente peligrosos.
Esto hace que Hermes sea interesante no porque sea malware, sino porque puede funcionar como algo más parecido a un:
asistente autónomo de post-explotación.
1. ¿Qué es un asistente autónomo de post-explotación?
Después de que un atacante obtiene un acceso inicial, gran parte del trabajo es repetitivo.
Un operador humano puede tener que:
- Entender la máquina comprometida.
- Identificar al usuario actual.
- Descubrir el entorno que la rodea.
- Determinar qué sistemas son accesibles.
- Examinar configuraciones y credenciales.
- Entender los privilegios.
- Investigar sistemas interesantes.
- Decidir qué investigar después.
- Repetir.
Tradicionalmente:
Atacante humano
↓
Observar
↓
Ejecutar comando
↓
Leer resultado
↓
Pensar
↓
Elegir siguiente acción
↓
Ejecutar comando
↓
Repetir
Un agente autónomo cambia el ciclo:
Atacante humano
↓
Dar un objetivo al agente
↓
Agente de IA
↓
Observar el entorno
↓
Razonar sobre los hallazgos
↓
Elegir la siguiente investigación
↓
Usar las herramientas disponibles
↓
Observar el resultado
↓
Actualizar su comprensión
↓
Elegir otra acción
↓
Repetir
La IA no necesariamente reemplaza al hacker; puede reemplazar gran parte del trabajo repetitivo y de teclado del hacker.
Ese es el cambio importante.
2. ¿Qué ocurrió realmente en Tailandia?
El incidente de Tailandia debe tratarse como el ejemplo del mundo real, no como una prueba de que Hermes puede realizar de forma autónoma un ciberataque completo de principio a fin.
Hunt.io informó que entre el 9 y el 13 de julio de 2026, investigadores encontraron tres directorios expuestos en un servidor alojado en Hong Kong que contenían cientos de archivos y aproximadamente 470 MB de herramientas de ataque e información robada. El material incluía código de exploits, web shells, túneles, scripts personalizados y credenciales robadas dirigidas a infraestructura de correo y Apache Hadoop.
La infraestructura también contenía registros de Hermes.
Esos registros mostraban al agente realizando actividades que incluían:
- enumeración de hosts;
- recorrido del sistema de archivos;
- investigación relacionada con privilegios;
- recopilación de resultados de LinPEAS;
- investigación relacionada con vulnerabilidades.
El atacante ya había obtenido acceso antes de que Hermes entrara en escena.
Por lo tanto:
Lo que sabemos
Atacante → acceso inicial → Hermes → investigación autónoma
No:
Hermes → mágicamente compromete al ministerio
Esa distinción debe mantenerse durante toda la discusión de este incidente.
3. Hermes no fue el arma inicial
Este es quizá el mayor malentendido.
Hermes es un agente autónomo de IA, no un troyano de acceso remoto tradicional.
La infraestructura del ataque supuestamente contenía otras herramientas, incluyendo web shells y un implante en Go al que el operador se refería como Hades.
Eso significa que la operación parece más cercana a:
Compromiso inicial
↓
Acceso existente del atacante
↓
Herramientas adicionales
↓
Hermes
↓
Investigación autónoma
Esto es importante porque cambia la manera en que los defensores deben pensar sobre la amenaza.
El agente de IA puede convertirse en el asistente del operador después de que la puerta ya está abierta.
4. ¿Por qué Hermes era interesante para el atacante?
Hermes combina muchas capacidades que tradicionalmente requieren varias herramientas separadas.
Su documentación actual incluye un amplio registro de herramientas que incluye:
- ejecución de terminal;
- interacción con procesos;
- lectura y edición de archivos;
- automatización del navegador;
- búsquedas web;
- memoria persistente;
- búsqueda de sesiones;
- tareas programadas;
- ejecución de código;
- delegación a subagentes;
- MCP;
- visión;
- generación de imágenes;
- integraciones de mensajería.
Esta combinación es importante.
Imagina darle a un analista humano:
Terminal
+
Navegador
+
Sistema de archivos
+
Búsqueda web
+
Memoria
+
Automatización
+
Mensajería
+
Trabajadores paralelos
Y después agregar:
“Tú decides qué investigar después.”
Ese es el cambio arquitectónico fundamental.
5. ¿Cómo puede controlar Hermes el atacante?
Hermes puede operarse mediante varias interfaces.
No necesariamente todas fueron utilizadas en la operación de Tailandia.
Interfaz directa
Atacante
↓
Acceso remoto
↓
Hermes
↓
Terminal / Archivos / Navegador
Mensajería
Hermes actualmente admite numerosas plataformas de mensajería, incluyendo Telegram, Discord, Slack, WhatsApp, Signal, Email, Microsoft Teams, Matrix y otras.
Conceptualmente:
Atacante
↓
Plataforma de mensajería
↓
Gateway de Hermes
↓
Agente Hermes
↓
Herramientas
El detalle de seguridad importante es que la documentación oficial de Hermes muestra que algunos conjuntos de herramientas de mensajería pueden tener acceso completo a herramientas, incluida la ejecución de terminal.
Eso significa que la interfaz de mensajería no necesariamente es solamente una interfaz de chat.
Puede convertirse en una superficie de control para un agente con capacidades reales de ejecución.
API
Hermes también admite acceso mediante un servidor API.
Conceptualmente:
Cliente externo
↓
API de Hermes
↓
Agente
↓
Herramientas
Tareas programadas
Hermes admite tareas recurrentes y de una sola ejecución, y puede entregar resultados a archivos locales o plataformas configuradas.
Entonces:
Atacante
↓
Configura una tarea
↓
Atacante se desconecta
↓
Hermes se activa después
↓
Realiza la tarea
↓
Reporta el resultado
Aquí es donde “desatendido” adquiere importancia.
6. La memoria persistente cambia la ecuación
Hermes tiene memoria persistente acotada que puede sobrevivir entre sesiones, además de búsqueda de sesiones.
Imagina una investigación que dura varios días.
Lunes
El servidor A está relacionado con ingeniería.
Martes
El servidor A se comunica con el servidor B.
Miércoles
La cuenta C parece administrar el servidor B.
Jueves
El servidor B parece dar soporte a una aplicación de producción.
El agente potencialmente puede conectar esas observaciones.
El resultado se convierte en:
Máquina
↓
Identidad
↓
Aplicación
↓
Dependencia
↓
Función empresarial
Esto es mucho más valioso que tener resultados aislados de comandos.
Se convierte en una memoria del entorno.
7. Skills: el agente puede conservar procedimientos
Hermes tiene un sistema de skills basado en documentos de conocimiento reutilizables. Los skills pueden cargarse cuando son necesarios y siguen el estándar agentskills.io.
Para un uso legítimo:
“Recuerda cómo realizo este tipo de análisis.”
Para un atacante, la implicación teórica es:
Los procedimientos pueden convertirse potencialmente en conocimiento reutilizable del agente.
Eso no significa que Hermes desarrolle automáticamente skills de hacking.
Significa que una implementación controlada por un atacante podría potencialmente conservar flujos de trabajo repetibles en lugar de reconstruirlos cada vez.
8. Escenario: la IA se convierte en un explorador de red
Imagina una estación de trabajo de ingeniería de una empresa manufacturera que ha sido comprometida.
La primera tarea del agente podría ser conceptualmente:
“Entiende el entorno disponible desde este host.”
Potencialmente podría recopilar información sobre:
- el host actual;
- la identidad/contexto;
- los recursos disponibles;
- las aplicaciones;
- la infraestructura accesible.
El resultado podría verse así:
RESUMEN DEL ENTORNO
Host:
Estación de trabajo de ingeniería
Observado:
• Infraestructura de archivos
• Servidores de ingeniería
• Infraestructura de autenticación
• Aplicaciones internas
• Infraestructura de administración/jump
Potencialmente sensible:
• Repositorios de ingeniería
• Documentación de producción
• Sistemas administrativos
Lo importante no son los datos sin procesar.
Es que el agente puede potencialmente convertir observaciones sin procesar en una explicación priorizada.
9. Escenario: el descubrimiento de credenciales se convierte en inteligencia sobre credenciales
Supongamos que el agente encuentra información que sugiere que existe una identidad de aplicación.
La pregunta importante ya no es solamente:
“¿Qué es esta credencial?”
Se convierte en:
“¿Qué representa esta identidad?”
Conceptualmente:
Credencial
↓
Identificar cuenta
↓
Identificar aplicación
↓
Identificar sistemas asociados
↓
Entender permisos
Esto crea una señal defensiva importante.
Un proceso de IA inusual que acceda a:
Archivos de credenciales/configuración
+
Actividad de red
+
Investigación de sistemas remotos
es considerablemente más interesante que un agente de IA que simplemente lee un documento de proyecto.
10. Escenario: mapeo de oportunidades de movimiento lateral
Supongamos:
Máquina A
↓
Identidad descubierta
↓
La máquina B parece accesible
El agente podría potencialmente investigar si la relación realmente funciona.
Pero:
credenciales no equivalen a movimiento lateral automático.
La cadena todavía depende de:
- credenciales válidas;
- permisos;
- conectividad de red;
- autenticación;
- MFA;
- segmentación;
- controles de endpoint;
- autorización de la aplicación.
Por lo tanto:
Máquina A
↓
Credencial
↓
¿Permiso?
↓
¿Conectividad?
↓
¿Autenticación?
↓
¿Acceso?
Cualquier paso puede fallar.
11. Escenario: manufactura y OT
Consideremos un entorno manufacturero ficticio:
Estación de trabajo de ingeniería
↓
Servidor de archivos
↓
Servidor de ingeniería
↓
Jump host
↓
Red OT
↓
┌────────┼────────┐
▼ ▼ ▼
Historiador SCADA Ingeniería
Un agente autónomo podría potencialmente ayudar a un atacante a entender:
- en qué segmento de red se encuentra la estación de trabajo;
- qué sistemas de ingeniería son accesibles;
- qué identidades están asociadas con esos sistemas;
- qué información de configuración/archivos existe;
- qué sistemas parecen importantes.
El agente podría potencialmente producir un mapa del entorno.
Pero descubrir un sistema OT no significa que pueda controlarlo.
Los entornos OT pueden tener:
- segmentación;
- jump hosts;
- listas de permitidos;
- controles unidireccionales;
- autenticación especializada;
- firewalls;
- controles sobre estaciones de ingeniería.
El objetivo defensivo es romper la cadena antes de que un compromiso de TI se convierta en un incidente de OT.
12. Escenario: banca
Ahora consideremos un banco.
Acceso inicial:
Estación de trabajo de empleado
↓
Identidad corporativa
↓
Aplicaciones internas
↓
Recursos cloud
↓
Bases de datos
↓
Sistemas financieros
Un agente podría potencialmente ayudar a determinar:
¿A qué puede acceder esta identidad?
En lugar de devolver miles de observaciones sin procesar, podría resumir:
100 sistemas observados
↓
25 potencialmente relevantes
↓
8 sensibles
↓
3 aparentemente accesibles
El valor está en la priorización.
La IA no necesita descubrir una vulnerabilidad nueva para ser útil.
Puede reducir el esfuerzo humano necesario para comprender un entorno complejo.
13. Escenario: salud
Una estación de trabajo hospitalaria comprometida podría potencialmente exponer relaciones entre:
Estación de trabajo clínica
↓
Sistemas de identidad
↓
Aplicaciones clínicas
↓
Infraestructura de archivos
↓
Sistemas de imagen
↓
Sistemas administrativos
Un agente autónomo podría potencialmente ayudar a clasificar:
- datos sensibles;
- sistemas importantes;
- identidades;
- relaciones entre aplicaciones;
- dependencias de infraestructura.
Las consecuencias podrían incluir:
- exposición de datos de pacientes;
- interrupción operativa;
- compromiso de credenciales;
- preparación para ransomware.
Nuevamente, el agente no derrota automáticamente MFA ni la segmentación.
14. Escenario: una identidad cloud se convierte en el mapa del ataque
La nube cambia la ecuación porque el activo más importante puede ser una identidad y no una máquina física.
Imagina que un atacante obtiene acceso a una credencial cloud.
La investigación conceptual se convierte en:
Identidad cloud
↓
Permisos IAM
↓
Recursos accesibles
┌─────────────────┼──────────────────┐
▼ ▼ ▼ ▼
Almacenamiento Cómputo Base de datos Secretos
El agente podría potencialmente ayudar a interpretar esas relaciones.
Para los defensores, esto hace que contar con IAM de mínimo privilegio sea extremadamente importante.
Una identidad con permisos excesivos proporciona a un agente autónomo un espacio de búsqueda mucho mayor.
15. Escenario: sesiones del navegador
Hermes admite automatización del navegador con backends de navegador locales y cloud.
Eso significa que el agente puede potencialmente interactuar con aplicaciones web y no solamente con archivos y shells locales.
Considera:
Navegador autenticado
↓
Aplicación interna
↓
Dashboard cloud
↓
Plataforma SaaS
↓
Información empresarial
Un agente con capacidades de navegador podría potencialmente navegar esos sistemas cuando tenga acceso autorizado mediante el entorno del navegador.
Esto es diferente de decir:
“Hermes roba cookies del navegador.”
Eso no es lo que significa la capacidad documentada.
El punto importante es:
Las sesiones de aplicaciones ya autenticadas pueden convertirse en parte del entorno operativo efectivo de un agente.
16. Escenario: descubrimiento de datos sensibles
Imagina que una organización tiene millones de archivos.
Una búsqueda tradicional puede producir miles de nombres de archivos.
Un agente de IA podría potencialmente clasificar la información semánticamente:
10,000,000 archivos
↓
Clasificación mediante IA
↓
2,000 potencialmente relevantes
↓
200 sensibles
↓
20 altamente valiosos
Las categorías posibles incluyen:
- información financiera;
- registros de personal;
- propiedad intelectual;
- información de ingeniería;
- código fuente;
- contratos;
- documentación operativa.
Esto convierte a la IA en un sistema de clasificación y priorización de información.
17. Escenario: propiedad intelectual
Los fabricantes suelen almacenar su información más valiosa en documentos en lugar de bases de datos:
- documentación de ingeniería;
- especificaciones de productos;
- archivos de diseño;
- información de pruebas;
- procedimientos de fabricación;
- información de proveedores.
Supongamos que un atacante llega a un repositorio de ingeniería.
En lugar de leer manualmente miles de documentos, un agente de IA podría potencialmente ayudar a identificar:
¿Qué documentos parecen estar relacionados con el producto de próxima generación de la empresa?
Conceptualmente:
Repositorio de ingeniería
↓
Clasificación de documentos
↓
Documentos relacionados con productos
↓
Subconjunto sensible
Nuevamente, la IA funciona como analista.
18. Escenario: preparación para ransomware
Un agente autónomo no necesita cifrar nada para ser útil a un operador de ransomware.
La fase de preparación puede ser más importante.
Conceptualmente:
Acceso inicial
↓
Entender el entorno
↓
Identificar servidores críticos
↓
Identificar dependencias empresariales
↓
Identificar infraestructura de respaldos
↓
Priorizar sistemas
El atacante busca respuestas a preguntas como:
¿Qué sistemas son críticos para la producción?
¿Qué aplicaciones dependen de qué servidores?
¿Dónde están los sistemas de recuperación?
¿Qué identidades parecen privilegiadas?
Un agente de IA podría potencialmente ayudar a organizar esta información.
El resultado es un asistente de reconocimiento para ransomware, no necesariamente ransomware en sí.
19. Escenario: mapeo de respaldos y recuperación
Los respaldos son críticos durante los ataques de ransomware.
Un entorno comprometido podría verse así:
Producción
├── Aplicaciones
├── Bases de datos
├── Servidores de respaldo
└── Infraestructura de recuperación
Un agente autónomo podría potencialmente ayudar a identificar esas relaciones.
Por eso los defensores deberían aislar la infraestructura de respaldos y protegerla con credenciales y controles de red independientes de los sistemas normales de producción.
20. Escenario: DevOps y CI/CD
Una computadora de un desarrollador puede ser una puerta hacia:
Desarrollador
↓
Repositorio Git
↓
CI/CD
↓
Registro de artefactos
↓
Despliegue cloud
↓
Producción
Un agente autónomo podría potencialmente ayudar a un atacante a comprender esas relaciones.
Podría clasificar:
- repositorios;
- infraestructura de compilación;
- sistemas de despliegue;
- recursos cloud;
- configuración;
- dependencias.
La parte peligrosa no es necesariamente la explotación inmediata.
Es comprender la cadena de suministro de software.
21. Escenario: la documentación interna como inteligencia
Los atacantes no aprenden solamente de los servidores.
Las organizaciones también exponen arquitectura mediante:
- wikis;
- tickets;
- archivos README;
- runbooks;
- documentación de proyectos;
- reportes de incidentes.
Un agente autónomo podría potencialmente transformar:
Documentación
↓
Nombres de aplicaciones
↓
Responsables
↓
Infraestructura
↓
Dependencias
en una base de inteligencia interna.
Por eso la documentación sensible de arquitectura también merece controles de seguridad.
22. Escenario: priorización de vulnerabilidades
Supongamos que un atacante observa:
20,000 activos
↓
2,000 vulnerabilidades
↓
200 potencialmente relevantes
↓
30 accesibles/relevantes
↓
5 de alta prioridad
Un agente autónomo podría potencialmente ayudar a priorizar según:
- exposición;
- importancia del sistema;
- software;
- identidad;
- posición en la red;
- contexto empresarial.
La misma capacidad resulta útil para la defensa.
Este es un tema importante:
La IA puede acelerar tanto la defensa como el ataque cibernético.
23. Escenario: monitoreo continuo
Hermes admite automatización programada, incluyendo tareas recurrentes.
Conceptualmente:
Entorno
↓
El agente registra el estado
↓
Espera
↓
Vuelve a revisar
↓
Compara
↓
Investiga cambios
El agente podría teóricamente utilizarse para monitorear:
- nuevos sistemas;
- cambios de configuración;
- nuevos recursos accesibles;
- cambios en aplicaciones;
- cambios en infraestructura.
La existencia de tareas programadas no es maliciosa por sí misma.
La pregunta de seguridad es:
¿Quién creó la tarea, a qué puede acceder y dónde se entregan sus resultados?
24. Escenario: múltiples investigadores de IA
Hermes admite delegación a subagentes. Su documentación describe agentes secundarios con contexto aislado y conjuntos de herramientas restringidos.
Conceptualmente:
Hermes
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Agente A Agente B Agente C
Identidad Archivos Apps
análisis análisis análisis
│ │ │
└──────────────┼──────────────┘
▼
Agente padre
Esto es paralelización, no auto-replicación.
Es una distinción importante.
El agente puede potencialmente delegar trabajo sin convertirse en un organismo de malware que se propaga por sí mismo.
25. ¿Puede desplegar más agentes?
Potencialmente, sí, pero esto requiere una formulación cuidadosa.
Existen cuatro conceptos diferentes:
1. Subagente
Hermes delega otra tarea de IA.
2. Ejecución de herramientas
Hermes ejecuta software que ya existe.
3. Despliegue de software adicional
Si un atacante tiene suficientes privilegios, un agente podría potencialmente utilizarse como parte del despliegue de herramientas adicionales.
4. Auto-replicación
El agente se propaga autónomamente por la red como un gusano.
Son conceptos completamente diferentes.
El incidente de Tailandia no demuestra auto-replicación autónoma.
Un escenario hipotético más realista sería:
Atacante
↓
Hermes en Máquina A
↓
Acceso descubierto
↓
Máquina B se vuelve accesible
↓
Herramienta adicional
↓
Agente/herramienta opera en B
Pero esto requiere que el entorno permita la acción subyacente.
26. MCP puede ampliar el alcance del agente
Hermes admite servidores MCP, lo que permite conectar herramientas externas al agente. La documentación oficial describe conexiones MCP con sistemas como GitHub, bases de datos, sistemas de archivos, stacks de navegador y APIs internas.
Conceptualmente:
Hermes
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Terminal Navegador MCP
│
┌────────┼────────┐
▼ ▼ ▼
Base de GitHub API interna
datos
Esto crea otra frontera de seguridad.
Cada herramienta externa conectada a un agente puede ampliar potencialmente lo que ese agente puede ver o hacer.
Por lo tanto:
Los permisos de MCP deben tratarse como permisos de una aplicación.
27. El agente puede potencialmente convertirse en el analista de inteligencia del atacante
Este puede ser, en última instancia, el caso de uso más importante.
Imagina que el atacante tiene acceso a:
Archivos
Logs
Emails
Observaciones de red
Información cloud
Documentación
Información de aplicaciones
El agente puede potencialmente transformar eso en:
Datos sin procesar
↓
Clasificación
↓
Relaciones
↓
Priorización
↓
Inteligencia para el atacante
En lugar de miles de observaciones, el humano recibe:
“Estos tres sistemas parecen ser los más relevantes.”
“Esta identidad parece estar asociada con esos sistemas.”
“Esta aplicación depende de esta infraestructura.”
“Estos recursos parecen ser particularmente sensibles.”
El agente se convierte en el analista entre el atacante y el entorno comprometido.
28. Escenario: ¿qué pasa si el hacker se va a dormir?
Aquí es donde el incidente de Hermes se vuelve especialmente convincente.
Un atacante tradicional:
Hacker
↓
Comando
↓
Esperar
↓
Analizar
↓
Comando
Una operación autónoma:
Hacker
↓
Objetivo
↓
Hermes
↓
Investigar
↓
Razonar
↓
Investigar
↓
Razonar
↓
Investigar
↓
Reportar
El humano puede desconectarse.
El agente puede continuar.
Esa es la diferencia operativa.
29. Hermes vs OpenClaw vs NanoClaw
Hermes no tiene capacidades únicas de comportamiento agentic.
OpenClaw y NanoClaw tienen capacidades que se superponen.
La diferencia es principalmente arquitectónica.
| Capacidad | Hermes | OpenClaw | NanoClaw |
|---|---|---|---|
| Agente autónomo | Sí | Sí | Sí |
| Memoria persistente | Sí | Sí | Sí |
| Skills | Sí | Sí | Sí |
| Ejecución de terminal/herramientas | Sí | Sí | Sí, dentro del contenedor |
| Navegador | Sí | Sí | Acceso web compatible |
| Tareas programadas | Sí | Sí | Sí |
| Subagentes | Sí | Sí | Enjambres de agentes |
| MCP | Sí | Sí | Compatible |
| Mensajería | Muy amplia | Muy amplia | Amplia |
| Autoalojado | Sí | Sí | Sí |
| Aislamiento mediante contenedores | Disponible | Configurable | Énfasis arquitectónico central |
| Enfoque principal | Trabajador autónomo persistente | Ecosistema amplio de agentes personales | Agente ligero + aislamiento |
La documentación actual de OpenClaw describe herramientas como exec, navegador, búsqueda web, mensajería, automatización y orquestación multiagente. Documentación de OpenClaw
NanoClaw se describe como una alternativa ligera que ejecuta agentes en contenedores Linux separados, con aislamiento del sistema de archivos.
Por lo tanto, la pregunta de seguridad no es:
“¿Cuál de ellos es la IA para hackear?”
Es:
“¿Qué arquitectura proporciona a un agente la combinación de autonomía, acceso, persistencia y conectividad que necesita un atacante?”
30. Por qué importa la arquitectura de NanoClaw
NanoClaw enfatiza deliberadamente el aislamiento mediante contenedores.
Su documentación señala que los agentes se ejecutan en contenedores y solamente pueden ver los recursos que se montan explícitamente. También describe el manejo de credenciales mediante un proxy de credenciales, en lugar de colocar directamente las claves API sin procesar dentro del contenedor del agente. Repositorio de NanoClaw
Eso cambia el posible radio de impacto.
Conceptualmente:
NanoClaw
↓
Contenedor
├── Agente
├── Herramientas
└── Archivos permitidos
X
│
│
Sistema host
El objetivo es:
Si el agente se ve comprometido, el contenedor se convierte en una frontera de seguridad.
Eso no hace que NanoClaw sea inmune al abuso.
Hace más difícil que tenga acceso irrestricto al host por diseño.
31. ¿Por qué elegiría Hermes un atacante?
No existe evidencia de que los ciberdelincuentes prefieran universalmente Hermes.
Pero un agente autoalojado puede ofrecer características atractivas para un atacante:
Control del runtime
El operador controla el entorno.
Flexibilidad de modelos
Hermes admite múltiples proveedores y modelos.
Persistencia
El agente puede permanecer disponible.
Memoria
Puede conservar contexto.
Skills
Los procedimientos pueden reutilizarse.
Programación
Las tareas pueden continuar sin que el operador esté conectado.
Subagentes
El trabajo puede paralelizarse.
Herramientas
Terminal, navegador, archivos, web y herramientas externas pueden combinarse.
Mensajería
El agente puede controlarse mediante numerosos canales de comunicación.
Personalización
Un runtime de código abierto puede ser modificado por su operador.
Esto no hace que Hermes sea malicioso.
Lo hace operativamente flexible.
32. Lo que Hermes NO demostró
Una investigación responsable debe separar claramente los hechos de las posibilidades.
El incidente de Tailandia NO demuestra que:
- Hermes descubrió la vulnerabilidad original.
- Hermes seleccionó de forma independiente al Ministerio de Finanzas de Tailandia.
- Hermes comprometió de forma independiente al ministerio.
- Hermes se propagó automáticamente como un gusano.
- Hermes se replicó autónomamente.
- Hermes derrotó MFA.
- Hermes atravesó la segmentación IT/OT.
- Hermes comprometió todos los sistemas que descubrió.
- Hermes logró exfiltrar todos los datos del personal.
La evidencia más sólida muestra que un atacante que ya tenía acceso utilizó Hermes para realizar una investigación autónoma. Investigación de Hunt.io
33. Un modelo de evidencia de cuatro niveles
Toda afirmación sobre ciberataques con agentes debería clasificarse.
DOCUMENTADO
Observado o reportado directamente.
Ejemplo:
Hermes fue utilizado en modo desatendido durante la operación de Tailandia.
RESPALDADO
Confirmado por documentación oficial o investigación independiente.
Ejemplo:
Hermes admite memoria persistente, tareas programadas y delegación a subagentes.
POSIBLE
Técnicamente viable con base en las capacidades documentadas.
Ejemplo:
Un atacante con suficientes privilegios podría potencialmente utilizar un agente para coordinar herramientas adicionales.
ESPECULATIVO
Posibilidades futuras sin evidencia actual.
Ejemplo:
Una flota completamente autónoma de agentes de IA autorreplicantes tomando redes empresariales completas.
Esto último no debe presentarse como una realidad actual.
34. ¿Cómo debería detectarlo un SOC?
El mayor error sería:
“Busca Hermes.”
Un atacante podría utilizar otro agente, o cambiar el nombre del ejecutable.
En cambio, hay que buscar comportamiento.
Telemetría de procesos
Monitorea comportamientos inusuales:
Agente
↓
Shell
↓
Descubrimiento del sistema
↓
Acceso a archivos
↓
Actividad de red
Presta atención a las relaciones padre-hijo entre procesos.
Acceso a credenciales
Monitorea agentes de IA inusuales que accedan a:
- almacenes de credenciales;
- archivos de configuración;
- variables de entorno;
- secretos;
- credenciales cloud;
- datos relacionados con navegadores;
- material SSH.
Actividad de red
Monitorea:
- conexiones con múltiples hosts internos;
- tráfico east-west inusual;
- nuevos destinos externos;
- plataformas de mensajería;
- gateways de agentes;
- endpoints API inesperados.
Persistencia
Monitorea:
- cron;
- tareas programadas;
- systemd;
- servicios;
- contenedores;
- mecanismos de inicio;
- procesos inesperados de larga duración.
El propio Hermes admite tareas programadas, por lo que una nueva tarea programada relacionada con Hermes en un sistema inesperado merece especial atención. Documentación de tareas programadas de Hermes
35. Perspectiva de EDR
Para un EDR como CrowdStrike, no empieces con:
“¿Está instalado Hermes?”
Empieza con:
“¿Por qué este proceso se está comportando como un operador autónomo?”
La telemetría útil incluye:
- árbol de procesos;
- línea de comandos;
- conexiones de red;
- autenticación;
- acceso a archivos;
- acceso a credenciales;
- persistencia;
- conexiones con sistemas remotos.
Una secuencia conceptual sospechosa sería:
Agente desconocido
↓
Shell ejecutado
↓
Descubrimiento del sistema
↓
Acceso a credenciales/configuración
↓
Conexiones con múltiples hosts internos
↓
Acceso remoto
↓
Persistencia
La secuencia es la señal.
36. Correlación en el SIEM
Una detección conceptual útil podría correlacionar:
Evento 1
Runtime de IA inesperado
Evento 2
Se ejecuta un shell
Evento 3
Acceso a credenciales/configuración
Evento 4
Se contactan múltiples hosts internos
Evento 5
Canal de control externo
Evento 6
Mecanismo de persistencia
PATRÓN DE ALTO RIESGO DE POST-EXPLOTACIÓN AGÉNTICA
Esto es mucho más sólido que una simple:
“Detección de Hermes.”
37. ¿Qué detiene el ataque?
La mejor defensa no es necesariamente prohibir la IA.
Es limitar a qué puede acceder un agente de IA.
Identidad
- MFA resistente al phishing;
- mínimo privilegio;
- PAM;
- cuentas de servicio restringidas;
- credenciales de corta duración.
Endpoint
- EDR;
- listas de aplicaciones permitidas;
- controles de instalación de agentes;
- protección de credenciales;
- controles de scripts.
Red
- segmentación IT/OT;
- monitoreo east-west;
- filtrado de tráfico de salida;
- interfaces de administración restringidas.
Cloud
- IAM de mínimo privilegio;
- identidad de workloads;
- gestión de secretos;
- logs de auditoría cloud.
Controles de agentes de IA
- aprobación humana para operaciones de alto riesgo;
- sandboxing;
- aislamiento mediante contenedores;
- acceso restringido al sistema de archivos;
- acceso restringido a la red;
- listas de herramientas permitidas;
- restricciones de MCP;
- logging de auditoría;
- identidad del agente;
- controles de destinos de salida.
El objetivo es:
Incluso si un agente autónomo es comprometido o utilizado indebidamente, no debería heredar automáticamente las llaves de toda la empresa.
38. La nueva ecuación de seguridad
El riesgo puede pensarse conceptualmente como:
Autonomía × Acceso × Persistencia × Conectividad × Privilegios
Considera dos agentes.
Agente A
Alta autonomía
+
Sin credenciales
+
Sandbox
+
Sin red
+
Datos de solo lectura
Impacto potencial: limitado.
Agente B
Alta autonomía
+
Acceso a credenciales
+
Terminal
+
Amplio acceso a la red
+
Memoria persistente
+
Comunicación externa
+
Altos privilegios
Impacto potencial: considerablemente mayor.
El modelo de IA puede ser idéntico.
La frontera de seguridad no lo es.
39. El próximo ataque podría no parecer malware
Esta es quizá la lección más importante.
Malware tradicional:
Atacante
↓
Malware
↓
Comando
↓
Acción
Operación agéntica:
Atacante
↓
Agente autónomo
↓
Observar
↓
Razonar
↓
Actuar
↓
Observar
↓
Razonar
↓
Actuar
El agente se convierte en una capa de toma de decisiones sobre las herramientas del atacante.
Eso hace que la detección basada únicamente en malware tradicional sea insuficiente.
Los defensores necesitan comprender el comportamiento de los runtimes de IA de la misma forma que entienden el comportamiento de scripts, shells y herramientas de administración remota.
40. El escenario más importante: una máquina se convierte en múltiples investigaciones
Imagina que un atacante compromete una estación de trabajo.
Normalmente:
Una máquina
↓
Una persona
↓
Investigación manual
Ahora:
Una máquina
↓
Hermes
↓
Mapeo de red
↓
Análisis de identidad
↓
Análisis de aplicaciones
↓
Análisis de documentos
↓
Análisis cloud
↓
Investigación continua
Y si se utilizan subagentes:
Hermes
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Identidad Archivos Apps
análisis análisis análisis
El atacante ha convertido efectivamente una máquina comprometida en una plataforma de inteligencia impulsada por IA.
Ese es el multiplicador de fuerza.
41. La verdadera amenaza no es “la IA puede hackear”
Los agentes de IA todavía son imperfectos.
Pueden:
- alucinar;
- malinterpretar entornos;
- elegir acciones irrelevantes;
- fallar en la autenticación;
- quedarse atascados;
- activar controles de seguridad;
- interpretar mal los resultados;
- desperdiciar recursos.
No son superarmas cibernéticas autónomas.
Pero eso tampoco es lo importante.
Un atacante humano no necesita que la IA sea perfecta.
Si el agente puede automatizar 60 % del trabajo aburrido, el humano puede concentrarse en el 40 % restante.
Si el agente puede operar mientras el atacante duerme, el atacante obtiene horas operativas adicionales.
Si el agente puede resumir miles de observaciones, el atacante puede comprender un entorno grande más rápidamente.
Si el agente puede ejecutar investigaciones en paralelo, el atacante puede potencialmente examinar más caminos simultáneamente.
Ahí es donde cambia la economía del ataque.
42. El cambio de seguridad más grande
La historia importante no es:
“Hermes puede hackear una computadora.”
La historia más precisa es:
“Una vez que un atacante tiene acceso, un agente autónomo puede potencialmente convertir una intrusión dirigida por humanos en una investigación que opera continuamente.”
El incidente de Tailandia demuestra el comienzo de ese modelo.
Las capacidades más amplias de Hermes muestran hacia dónde podría evolucionar.
Y OpenClaw y NanoClaw demuestran que esto no necesariamente es un fenómeno limitado a un solo producto.
La tecnología avanza hacia agentes capaces de:
recordar, navegar, ejecutar, comunicarse, programar, delegar y razonar a través de múltiples herramientas.
Eso cambia el modelo de amenazas.
Conclusión: ¿qué pasa cuando el hacker se desconecta?
Imagina esto:
Un atacante compromete la computadora de un empleado a las 10:00 PM.
A las 10:15 PM, le da a un agente autónomo un objetivo amplio de investigación.
El atacante se desconecta.
El agente continúa.
Examina el entorno.
Identifica sistemas.
Analiza identidades.
Organiza información.
Descubre relaciones.
Recuerda lo que encontró.
Potencialmente delega partes de la investigación.
Puede continuar de acuerdo con tareas programadas.
A las 8:00 AM, el atacante regresa.
En lugar de ver:
“Una computadora comprometida.”
puede ver:
Entorno mapeado
↓
Sistemas categorizados
↓
Identidades comprendidas
↓
Aplicaciones identificadas
↓
Recursos potencialmente sensibles priorizados
↓
Rutas de investigación adicionales identificadas
Ese es el verdadero significado de la post-explotación autónoma.
La IA no necesariamente inventó un nuevo exploit.
Cambió cuánto trabajo puede realizar un atacante.
Por eso la pregunta de seguridad del futuro no es simplemente:
¿Puede la IA hackear?
Es:
Si un atacante solo necesita comprometer una máquina, pero un agente autónomo puede pasar las siguientes 24 horas averiguando todo lo que esa máquina puede alcanzar, ¿cuánto ha cambiado fundamentalmente el costo del ataque?
Y por eso importa el incidente de Hermes.
No porque Hermes sea una herramienta mágica de hacking.
Sino porque ofrece una visión de lo que ocurre cuando el razonamiento de IA, la memoria persistente, herramientas reales, credenciales, acceso a la red y autonomía se combinan dentro de una intrusión activa.
Es especialista en ciberseguridad con más de 16 años de experiencia en seguridad de la información. Conoce muy bien la inteligencia de amenazas, la gestión de riesgos, la evaluación de vulnerabilidades y las pruebas de penetración, el análisis forense cibernético y la tecnología de seguridad en la nube (AWS, Azure, Google Cloud). Ocupó varios puestos de investigador de ciberseguridad en diferentes empresas. Tiene experiencia en diferentes industrias como finanzas, atención médica, marketing, gobierno, finanzas turísticas, aerolíneas, telecomunicaciones y biometría.
