Si lleváis un tiempo siguiendo esta web o mis redes sociales, sabéis que la irrupción de la Inteligencia Artificial no solo ha traído cosas buenas, sino que ha puesto en manos de cibercriminales herramientas de automatización, creación de deep fakes o generación de malware al alcance de casi cualquier persona. Hoy no nos vamos a quedar en la teoría, vamos a realizar un análisis forense de un servidor real de OpenClaw, este es un framework diseñado para operar agentes de IA de forma autónoma, que en este caso ha sido configurado para interactuar mediante Telegram, pero se podría controlar desde Whatsapp o Discord. Lo más interesante en este caso, es que OpenClaw se puede conectar a modelos locales a través de un servidor tipo: Ollama o LM Studio. De este modo, si se utiliza además un modelo sin censura o bloqueos, se podrá operar el sistema de inteligencia artificial sin ningún tipo de restricción, es decir, se le podrá solicitar cualquier tipo de información o acción, que OpenClaw la ejecutará sin contemplación, ya sea para bien o para mal.

Si todavía no sabes lo que es OpenClaw, decirte que es un sistema de orquestación que actúa como el sistema operativo de un agente autónomo de IA, transformando un modelo de lenguaje estático (como puede ser ChatGPT o Gemmini) en un operador capaz de ejecutar acciones en el mundo real. Su funcionamiento se basa en conectar el «cerebro» (el LLM) con «extremidades» (APIs, scripts o acceso a archivos, emails, agendas, sistemas… ) para que la IA no solo responda preguntas, sino que planifique y ejecute acciones de forma independiente. Todo esto bajo un entorno que, al integrarse con servidores locales como Ollama, permite lleva un paso mas allá la potencia de estos agentes de IA.

Por otra parte, lo que estamos viendo con OpenClaw es un hito sin precedentes en el código abierto: OpenClaw ha pulverizado los récords de GitHub al superar las 250.000 estrellas en apenas 3 meses, dejando atrás la progresión histórica de titanes como Linux o React. Incluso la explosión de OpenClaw ha provocado que el famoso mini pc Apple Mac Mini vuele de las estanterías y si quede sin stock en muchas tiendas en cuestión de semanas, esto es debido a que la eficiencia y arquitectura de un Mac Mini lo han convertido en la hardware ideal para que estos agentes autónomos corran localmente las 24 horas sin descanso ni vigilancia, por un coste irrisorio.

Este crecimiento vertical no es solo cuestión de «hype», sino la prueba de que el interés de la industria ha mutado de los simples chatbots hacia la autonomía absoluta, permitiendo a cualquier desarrollador desplegar agentes locales sin restricciones mediante Ollama, pero no os equivoquéis, esta adopción masiva a la velocidad del rayo es un arma de doble filo, ya que ha creado un ecosistema tan potente como caótico donde la seguridad a menudo se queda en un segundo plano frente a la urgencia de automatizarlo todo, y ya no digamos los aspectos forenses, que es lo que vamos a tratar hoy.

Un ejemplo del o que digo es el siguiente: hace unos días le pedí a OpenClaw que me escribiera un código fuente de ransomware, ya que estaba utilizando un modelo local sin bloqueos, hasta aquí todo normal, si no fuese por la respuesta que me dio:

Efectivamente, no solo me generó un código fuente válido para un ransomware, si no que además: ¡Me lo ejecutó en mi propio ordenador!, por eso es importante tomar precauciones a la hora de darle demasiados permisos a estos agentes de IA.

El artículo que vais a leer a continuación desgrana dónde y cómo OpenClaw almacena su información más crítica, ideal para investigaciones forenses y respuesta a incidentes (DFIR), con evidencias reales extraídas del servidor. Y como siempre digo, esto no es un manual para que montéis vuestro propio Skynet ofensivo, es una guía técnica para que, cuando os topéis con un servidor comprometido operando IA, sepáis exactamente dónde buscar y qué buscar.

Si queremos entender de verdad cómo funciona OpenClaw y cómo identificar los rastros de su uso, tenemos que bajar al barro del análisis forense. El entorno de estudio es un servidor Linux (Ubuntu 24.04) en el que se ha desplegado un servicio de OpenClaw, conectado por un lado a la API de Telegram para recibir órdenes, y por otro a un servidor local Ollama para ejecutar el “cerebro” de la bestia, este cerebro será un modelo local de IA sin restricciones de uso. En este caso, el host es un ordenador con un procesador Intel i7-13650HX con una gráfica Nvidia RTX 4060 de 8Gb de VRAM, que carga un modelo Gemma-4 de 6Gb.

A diferencia del malware tradicional, un agente de IA no tiene un código estático y predecible. Es dinámico, razona y toma decisiones. En este laboratorio controlado el cual vamos a analizar, el servidor ejecuta un motor que delega el pensamiento a modelos de lenguaje (LLMs), en este caso un Gemma-4. Al no querer usar APIs comerciales censuradas (como las de OpenAI o Anthropic), he optado por desplegar modelos locales. Y aquí es donde la cosa se pone interesante: nuestro trabajo es encontrar las trazas de qué se le ha pedido exactamente a esta IA a través de su agente, cómo este lo ha razonado y, sobre todo, quién está moviendo esos hilos y que tareas le ha hecho ejecutar al agente de OpenClaw.

A la hora de abordar en análisis forense de OpenClaw, me he decantando por una aproximación tradicional, realizar una análisis estático de los ficheros que se han generado al ejecutar OpenClaw. El análisis de la estructura de directorios en el servidor es el primer paso de este camino. Aquí tendremos unos ficheros que nos darán el control central de OpenClaw y una información muy valiosa.

En la ruta /openclaw, encontramos el núcleo del sistema. Para que este agente funcione, el usuario debe haber configurado los endpoints y los modelos. Toda esta lógica reside en el fichero principal de configuración llamado: openclaw.json. Este fichero contiene las credenciales, los modelos configurados, topología, endpoints locales, perfiles activos y las políticas del sistema.

Al realizar un análisis estático de este archivo, nos encontramos con toda la configuración del sistema.

Desde el punto de vista forense, este fichero nos da datos los siguientes parametros fundamentales:

• Modelo de IA número 1: Se puede observar en las primeras lineas el uso de modelos sin censura. El modelo principal configurado es: Gemma-4-Uncensored-XXXX-Aggressive:e4b. Hablamos de un modelo explícitamente diseñado para ser agresivo y no tener filtros o bloqueos.

• Modelo de IA número 2: También se listan configuraciones para LM Studio, como el caso del modelo local y sin censura XorXXXXUncensored2025.1-GGUF.

• Tokens y Autenticación: Se expone el token de autenticación del gateway local y los tokens de la API de los bots de Telegram utilizados para el control remoto del agente, como en este caso son:
  • Default: 86XXXXX23:AAFGH
  • Agente Q: 85XXXXX52:AAGjE

• Entorno: Muestra el directorio de trabajo donde la IA tiene permisos (/home/airi/.openclaw/workspace).

• Endpoints: Se evidencian conexiones a APIs locales, se puede saber que es compatible con Ollama al ver el puerto TCP de escucha: http://127.0.0.1:11434.

• Restricciones (DenyList): Vemos una lista denyCommands en el gateway que bloquea explícitamente acciones como camera.snap, screen.record o contacts.add. Esto nos da una pista del poder real que puede llegar a tener OpenClaw en el sistema operativo si se le quitan estos bloqueos. Normalmente,la la ejecución de comandos genéricos (exec) sí está permitida. Por lo que podríamos ejecutar cualquier comando de forma remota desde nuestro Agente, como si de un SSH se tratase.

Llegamos a un punto crítico de la investigación: la atribución, es decir, identificar quién controla el bot es fundamental. OpenClaw gestiona el acceso mediante listas blancas para evitar que cualquier persona pueda hablar con el agente.

En openclaw/credentials/telegram-default-allowFrom.json veremos cuales son los usuarios de Telegram con su ID único, que pueden interactuar con el bot.

Auditando esta ruta, encontramos la clave para llegar a la identificación del usuario de OpenClaw: el ID de usuario de Telegram autorizado. En este caso, el ID es 1623423408 (inventado). Este es el dueño legítimo de la instancia y el único que puede darle órdenes. Pero, ¿cómo demostramos quién es el propietario de ese ID?

Con el Historial de Sesiones y Logs de Chat (El “Cerebro”), podremos extraer mucha información de interés. Aquí es donde el forense de IA toma un nuevo sentido. A diferencia de un humano que borra su historial, OpenClaw es extremadamente “verbose” en su registro de interacciones. A diferencia de otros sistemas que usan bases de datos complejas para los chats, el historial de sesiones y el “razonamiento” no va a un syslog, sino que se almacena en texto plano en formato .jsonl (JSON Lines).

En la ruta openclaw/agents/main/sessions/*.jsonl encontraremos este fichero con la transcripción exacta de qué se le pidió a la IA, cómo respondió, metadatos del atacante/usuario, evidencia de escaneos y el razonamiento interno de la IA (ahí es nada…)

Al extraer los datos de una de las sesiones más voluminosas (61XXXXXX…jsonl, aprox. 570KB), localizamos la inyección directa de metadatos de Telegram que el bot procesa antes de responder. Observad esta evidencia cruda extraída del log:

¡Lo tenemos! Los metadatos asocian inequívocamente el ID 16XXXXX08 con el nombre “Manu {G}” y el username @CiberPoliES. La atribución está completada y cerrada con una marca de tiempo exacta (2026-04-22 09:47).

Pero la investigación no termina aquí. Necesitamos saber qué ha modificado el atacante/usuario/yo en el servidor. Para ello, OpenClaw mantiene una bitácora de auditoría de su propia configuración en openclaw/logs/config-audit.jsonl.

Esta línea nos demuestra exactamente, que en la hora (07:30:27 UTC) el atacante ejecutó el comando para vincular el bot de Telegram (agent_q) al sistema, utilizando la interfaz de línea de comandos local.

Y volviendo al “Cerebro” de la IA en los JSONL, podemos leer exactamente cómo la IA razona sus acciones ofensivas.

En los logs, vemos cómo el usuario (@CiberPoliES) le ordena realizar tareas de escaneo de la red host. La IA, utilizando su herramienta interna exec en la terminal, intenta lanzar comandos reales contra el sistema operativo anfitrión. Vemos intentos fallidos de escalar privilegios para instalar herramientas de escaneo (como nmap) tal y como se muestra a continuación:

Al fallar en la escalada, la IA recurre astutamente a herramientas integradas y comandos de red básicos que no requieren root, como ip addr e ip neigh, logrando mapear la red local 192.168.2.0/24 (identificando la IP local 192.168.2.239 y otros dispositivos como el router 192.168.2.1, 192.168.2.22, 192.168.2.176) de forma totalmente autónoma a petición mía.

En cuanto a los modelos usados, vemos que el atacante conectó el bot a un servidor local de LM Studio (localhost:1234) para explotar una suite de modelos especializados llamados XoXXXXCriminal Computing (nombre censurado), diseñados para tareas ofensivas, los cuales no tienen censura.

Además, se evidencian exhaustivas pruebas de rendimiento (Benchmarking) intentando forzar a la IA a usar una GPU dedicada (NVIDIA GeForce RTX 4060 con 8GB de VRAM y 46GB de RAM). Se ejecutan repetidamente comandos como nvidia-smi y time curl para medir los tokens por segundo y la latencia.

Finalmente, aunque los archivos JSONL guardan el “razonamiento”. Realmente el estado interno de las ejecuciones de herramientas del sistema operativo se guarda en bases de datos relacionales SQLite, como el caso de openclaw/tasks/runs.sqlite que no son mas que un registro estructurado de las herramientas del sistema utilizadas por la IA a petición del usuario.

Al auditar esta base de datos con herramientas como DB Browser for SQLite, obtenemos el registro estructurado de todas las llamadas a herramientas del sistema (los exec de consola), los timestamps exactos y los resultados devueltos por el sistema operativo. El archivo WAL de 4MB nos indica una actividad inusualmente alta de escritura reciente. Como manda el procedimiento estándar en análisis forense, podremos correlacionar los timestamps de estas sentencias SQL con las decisiones lógicas tomadas por la IA en los ficheros JSONL, de tal forma, que todo tendrá que tener una coherencia.

A nivel forense, poder reconstruir el diálogo exacto entre el atacante y el agente de IA permite entender no solo la cronología, sino la intención y los objetivos (TTPs) del atacante. Analizando los JSONL línea por línea. Esta es la secuencia exacta de comandos y respuestas extraída de la sesión 61b36f00-d455-402c-8098-c4488dc66ab5:

[09:47] CiberPoliES: hola, como estas?

[09:47] Agente 007: Hola Manu, todo operativo por aquí. 🕶️ ¿En qué puedo ayudarte hoy?

[09:47] CiberPoliES: que modelo estas usando?

[09:47] Agente 007: Estoy operando con Google Gemma 4, concretamente la versión google/gemma-4-31b-it. 🕶️

(*Nota: Aquí el atacante empieza a preparar la infraestructura ofensiva local)

[09:48] CiberPoliES: tienes un servidor local con lm-studio que esta ejecutando un modelo de xorXXXX, puedes usar tu directamente ese modelo local?

[09:48] Agente 007: No puedo conectarme directamente a LM Studio por mi cuenta… si tienes LM Studio exponiendo el servidor local… dime en qué IP/puerto está corriendo…

[09:49] CiberPoliES: localhost:1234

[09:49] Agente 007: (El log registra la ejecución interna del comando curl -s http://localhost:1234/v1/models) ¡Conexión establecida! 🕶️ He podido acceder a tu servidor local en localhost:1234 y veo que tienes desplegado un arsenal interesante de modelos de XorXXX, especialmente los de la serie criminalcomputing, que son muy potentes para temas de ciberseguridad…

[09:50] CiberPoliES: cuales son los modelos uncesured que ves y de que tamaño son?

[09:50] Agente 007: Basándome en la lista… los que están marcados explícitamente como uncensored son: xorXXX22b-uncensored-i1 (22B), xoXXXXuncensored2025.1. Recordemos que la línea de criminalcomputing de XoXXXX está diseñada específicamente para ser sin restricciones en contextos de seguridad.

(*Nota: El atacante pasa a la fase de reconocimiento (Recon) de la red de la víctima)

[12:47] CiberPoliES: Mira a ver si hay algún otro equipo conectado a tu misma red local

[12:48] Agente 007: (El log registra intentos de usar nmap y arp, y finalmente usa ip neigh) He revisado la tabla de vecinos (ip neigh) de la máquina y he encontrado otros dispositivos activos en tu red local (192.168.2.0/24): 192.168.2.1 (router/gateway), 192.168.2.22, 192.168.2.176…

Además de los logs de chat y las configuraciones principales que hemos visto en el artículo, el analisis del servidor de OpenClaw ha revelado una serie de mecanismos internos y archivos que son muy interesantes para un investigador forense. A continuación, detallo cinco hallazgos técnicos adicionales que permiten profundizar aún más en la actividad del atacante y en la seguridad interna del propio framework.

OpenClaw incorpora un sistema nativo de monitorización de integridad para evitar el “tampering” (manipulación) o tácticas de Anti-Forense, que podremos encontrar en la ruta: openclaw/logs/config-health.json

Si un atacante modifica el archivo openclaw.json manualmente para borrar un token o cambiar un modelo e intenta ocultar sus huellas modificando el timestamp (Timestomping). Este archivo lo delatará, ya que este registro captura el hash criptográfico exacto, el Inode del sistema de archivos y el tamaño en bytes de la última configuración válida. Permite a los investigadores validar si la configuración actual es la legítima o si ha sido alterada offline de forma maliciosa.

Otro aspecto interesante, es que OpenClaw delega la ejecución de comandos (la herramienta exec que usa la IA) a un proceso separado, comunicándose a través de sockets UNIX. Como este archivo, localizado en: openclaw/exec-approvals.json expone el token en texto plano (8G_zVjqgE25jOAShrXxXXXXXXXXbsB) y el socket utilizado para aprobar la ejecución de comandos en el sistema anfitrión. Si durante un incidente se detecta actividad anómala, este socket puede ser monitorizado (con herramientas como socat o strace) para interceptar las instrucciones exactas que la IA está intentando lanzar contra el sistema en tiempo real.

La carpeta openclaw/ tambien contiene múltiples archivos de respaldo nombrados como openclaw.json.bak, openclaw.json.bak.1, openclaw.json.bak.2, etc., con tamaños que varían desde 1839 bytes hasta los 3426 bytes de la configuración final. Como OpenClaw realiza copias de seguridad automáticas antes de cada modificación importante. Un analista puede hacer un diff entre estas versiones para construir una línea de tiempo cronológica (Timeline Analysis) de cómo el atacante fue construyendo su infraestructura ofensiva: cuándo añadió el modelo de XorXXXX, cuándo activó el Gateway, y en qué momento preciso vinculó el bot de Telegram.

A pesar de la automatización sofisticada del framework, el factor humano siempre deja migas de pan, como las que podemos encontrar en el fichero : ollama/history dónde vemos la ejecucción de los siguientes comandos:

Este pequeñísimo archivo de 10 bytes demuestra que el operador interactuó manualmente con la interfaz de línea de comandos (CLI) del servidor local de Ollama antes de cederle el control a OpenClaw. La presencia de las palabras “hola” y “exit” indica pruebas de conectividad manuales. Son este tipo de detalles los que ayudan a perfilar el comportamiento del atacante: verifica sus herramientas manualmente antes de automatizarlas.

En una investigación forense típica, uno de los primeros objetivos (Indicators of Compromise – IoC) es localizar la dirección IP pública o privada desde la que se conectó el ciberdelincuente. Sin embargo, al buscar direcciones IP en los ficheros de configuración y logs de OpenClaw, nos encontramos con un muro interesante a nivel de OPSEC (Seguridad de las Operaciones).

Aunque OpenClaw no almacena la IP de origen porque asume que la conexión ya es de confianza local. Para obtener la IP real desde la que se conectó el atacante en este escenario, el aplicando otros conocimientos forense mas tradicionales, se podría ir a los registros del sistema operativo Linux, concretamente a: /var/log/auth.log (o journalctl -u sshd) para ver las conexiones SSH exitosas al usuario airi. Por ejemplo, en el archivo /var/log/wtmp usando el comando last se podrían ver el historial de IPs logueadas en el sistema.

A nivel forense, OpenClaw es muy “rastreable”. Al ser un framework que opera localmente, no depende de la nube para almacenar el historial. Todo queda registrado normalmente en texto plano (.jsonl) o bases de datos simples (.sqlite). Para un buen forense, la carpeta de sessions es una mina de oro que revela no solo qué comandos se ejecutaron en el sistema comprometido/analizado, sino también la intención y el diálogo exacto entre el operador y su IA ofensiva.

El análisis forense de agentes de IA nos demuestra que, aunque la Inteligencia Artificial parece una caja negra inescrutable y volátil, los frameworks que la orquestan dejan un rastro digital masivo, algo que a estas alturas de la pelicula ya no debe sorprendernos. La integración con modelos locales sin censura y la ejecución autónoma de comandos en la máquina anfitriona son la clave técnica que diferencia un simple script automatizado de un agente ofensivo completo. Como analistas, nuestra misión es conectar esos registros de configuración, las trazas de auditoría y los logs de “razonamiento” para reconstruir la línea de tiempo del ataque y entender lo que verdaderamente ocurrió en ese sistema.

¡Misión Cumplida Agente!.

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.