Agente Oh My Open Pentest IA que hace pentesting

Estimados amigos de Inseguros !!!

Últimamente todo el mundo habla de «agentes» de IA que hacen tu trabajo mientras te tomas un café. En pentesting la promesa es gorda: le dices fullscan https://objetivo y el bicho hace recon, enumera la superficie de ataque, explota lo que encuentra, lo verifica y te suelta un informe con CVSS y pasos de reproducción. Cero babysitting.

Me topé con Oh My Open Pentest (OmOP para los amigos), y me lié la manta a la cabeza para probarlo. 109 herramientas, 250 playbooks, 10 modos de engagement. La teoría es preciosa. La práctica… ya sabéis cómo es esto 🙂

Este post es el diario de guerra: qué es la herramienta, cómo la instalas de verdad, y mis opiniones y pequeñas batallas.

Lo divido en tres bloques: instalación, auditoría web y auditoría interna.

Qué es OmOP

Antes de instalar nada, un par de cosas que conviene entender, porque me habrían ahorrado tiempo.

OmOP no es un programa suelto. Es un plugin que se enchufa dentro de OpenCode, que es un agente de IA que vive en tu terminal (piensa en algo tipo Claude Code, pero open source y de línea de comandos). El plugin le da a ese agente el arsenal ofensivo y los playbooks.

Segundo: es un fork del proyecto oh-my-openagent, con muchísimos cambios encima. Un agente que se auto-instala 109 herramientas ofensivas y encadena exploits solo es exactamente el tipo de cosa que quieres auditar antes de darle la llave de tu casa. Revisa tú el postinstall.mjs y el .mcp.json antes de lanzarlo. No por paranoia: por oficio.

Y tercero, el que más me marcó: yo empecé montándolo en el Mac. Error. Muchas de las herramientas de red y de Active Directory (responder, netexec, impacket, mimikatz…) son nativas de Linux/Kali y en macOS no van, o van a medias. La auto-instalación «before first use» se te queda a medias en Apple Silicon. El Mac es un buen puesto de control… no una máquina atacante.

Y aquí viene el matiz importante, porque no es blanco o negro. Depende de qué vayas a auditar:

• Web / externo: el grueso del tooling que necesitas (httpx, nuclei, ffuf, sqlmap, nmap…) sí corre razonablemente en macOS. Para tirar contra una web desde tu casa, con el Mac te puede valer. Es userland, no necesita meterse en la tripa de la red.
• Interno / Active Directory: aquí el Mac se cae. No solo porque responder, netexec o impacket sean bestias de Linux, sino porque para atacar un dominio tienes que estar dentro de la red del objetivo, con visibilidad hacia los DCs. Un agente en tu Mac, desde tu oficina, ni ve esa red ni ejecuta bien esas herramientas.

Resumido: Mac para web, Kali dentro de la red para interno. Lo desarrollo en la Parte 3, pero tenlo claro antes de decidir dónde instalas.

Instalación en Kali, paso a paso

Aprendida la lección, el sitio correcto es un Kali — VM o máquina física — con las herramientas nativas donde deben estar. Si además tienes VPN al entorno objetivo, ese Kali ve la red y ejecuta el tooling de verdad.

Vamos por orden. Bloque a bloque, comprobando cada uno antes de seguir.

En mi caso, sigo el post anterior de como instalar Ollama como servidor proxy de modelos Ollama cloud

1 · Ollama y el modelo

Yo uso Ollama como proxy de modelos en la nube. Aquí el que quieras: yo tiro de un GLM 5.3 cloud, pero también dejo un gpt-oss:20b local para pruebas gratis.

# Instalar Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Iniciar sesión (esto autoriza los modelos :cloud)
ollama signin

# Traer la info de los modelos que vayas a usar
ollama pull gpt-oss:20b

# Verificar que el endpoint local sirve los modelos
curl http://localhost:11434/v1/models

Un detalle que me costó un rato: el nombre del modelo lleva dos puntos, no guion. ollama pull glm-5.3-cloud falla con Error: pull model manifest: file does not exist. El nombre real era glm-5.3:cloud. Cuando dudes, mira siempre lo que hay de verdad:

$ ollama list
NAME             ID              SIZE     MODIFIED
glm-5.3:cloud    8477dab3e25b    -        2 hours ago
gpt-oss:20b      17052f91a42e    13 GB    4 days ago

2 · Bun y OpenCode

OmOP necesita Bun como runtime, y OpenCode como agente base.

# Bun
curl -fsSL https://bun.sh/install | bash
source ~/.bashrc
bun --version

# OpenCode
curl -fsSL https://opencode.ai/install | bash
source ~/.bashrc
opencode --version

3 · El plugin OmOP

bunx oh-my-open-pentest install

Te lanza un asistente. Cuando te pregunte por proveedor de IA y API key, sáltalo o pon lo mínimo: el modelo lo vamos a configurar a mano en el paso siguiente, porque el asistente es justo donde empieza el lío de las keys.

4 · La configuración del modelo (la clave de todo)

Aquí está el truco que me evitó dos horas de sufrimiento. OpenCode guarda proveedores, y si dejas que el /connect registre un «Ollama Cloud», te va a pedir la API key en cada arranque, para siempre. La solución elegante: declarar tu Ollama local como un proveedor con un nombre propio que no choque con nada. Le llamé ollamalocal.

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["oh-my-open-pentest@latest"],
  "provider": {
    "ollamalocal": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama Local Proxy",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "glm-5.3:cloud": { "name": "GLM 5.3 Cloud" },
        "gpt-oss:20b": { "name": "GPT-OSS 20B" }
      }
    }
  }
}

5 · Arrancar y elegir modelo

bunx oh-my-open-pentest doctor
opencode

Dentro de OpenCode: /models → eliges el modelo bajo «Ollama Local Proxy». Y no toques /connect: eso es para proveedores con API key; el tuyo es local y no la necesita. Cada vez que le das a connect, vuelves a crear el problema.

Parte 2Auditoría web: cómo lanzarlo (y cómo saber si de verdad funciona)

Con el motor montado, lo tentador es soltarle tu lista de URLs a lo bruto. No lo hagas todavía. Primero hay que responder a una pregunta: ¿el agente ejecuta herramientas de verdad, o solo describe lo que haría?

Porque OmOP vive del tool-calling: el modelo llama a nmap, parsea, decide, llama a sqlmap… en bucle. Si el modelo no es fuerte en eso, tendrás un agente que razona precioso pero no toca un puerto.

La prueba del algodón

Empieza con el modelo local y gratis contra un objetivo público de práctica, el que el propio proyecto Nmap mantiene para esto:

haz un recon básico de scanme.nmap.org

Y ahora míralo con lupa:

• Si lanza nmap / httpx de verdad y trae resultados → tu tool-calling funciona. Enhorabuena, pasa a tus URLs.
• Si solo dice «yo haría un nmap así…» sin ejecutar nada → el modelo no está haciendo tool-calling. Prueba otro. Un modelo pequeño te da un pentest que «habla» pero no «hace».

Cuando confirmes que ejecuta, ya puedes ir a lo tuyo. Una por una es lo más controlable al principio:

fullscan https://tu-objetivo-autorizado.com

Parte 3Auditoría interna y Active Directory: aquí cambia el juego

Llegamos a la parte que a mí más me interesa, la interna. ¿OmOP hace pentest de red local y AD? Sobre el papel, sí: modo red-team, fullscan 10.0.0.1/24 que auto-selecciona ese modo, y el arsenal completo de AD — netexec, bloodhound, certipy, kerbrute, responder, impacket — con playbooks tipo /proto-kerberos, /post-bloodhound, /post-credential-dumping.

Pero hay dos condiciones que no se saltan.

La máquina atacante tiene que estar DENTRO

Para AD, tu máquina de ataque necesita visibilidad L2/L3 hacia los DCs. Un agente en tu Mac, desde tu oficina, no ve la red interna del cliente. El patrón correcto es un Kali con VPN al entorno objetivo — o un dropbox que coloques allí — y ejecutar el tooling desde ahí.

Aquí es donde encaja todo lo de la Parte 1: si montaste OmOP en el Kali (no en el Mac), y ese Kali levanta la VPN, ya lo tienes. El flujo queda así:

El Mac es tu puesto de mando; el Kali, la máquina que trabaja. Y tu modelo viaja: como sale por Ollama, que habla con la nube por internet, en el Kali repites la misma config y usas el mismo modelo. No está atado a ninguna máquina.

En interno, la aprobación humana NO es opcional

Y aquí me pongo serio, porque es la red de un cliente y no tu laboratorio. Soltar un agente autónomo con responder, credential dumping y lateral movement dentro de una red productiva, sin confirmación por paso, es jugar con fuego. Puedes tumbar servicios, envenenar la red, o disparar el SOC del cliente sin querer.

¿Qué haría yo en interno? Empezar por módulos acotados — un /recon-internal, un /post-bloodhound en modo lectura — antes que un fullscan a lo loco. Y valorar herramientas del mismo palo que sí traen puertas de aprobación humana para acciones de alto riesgo, que es justo lo que quieres cuando no es tu casa la que estás pisando.

Hasta aquí llegué en esta tanda. La parte interna la dejo empezada — Kali con VPN, OmOP dentro, modelo funcionando — y el fullscan real contra un dominio de laboratorio queda para el siguiente capítulo, con capturas de BloodHound y todo. Que un post ya es largo de por sí…

Lo que me llevo de todo esto

Que estos agentes de IA para pentest son una herramienta más, no un botón mágico. Montarlos tiene su miga: nombres de modelo con dos puntos, variables de entorno traicioneras, proveedores que se pisan, logins que se rompen en Kali. Nada insalvable, pero nada «dale a instalar y ya».

Y sobre todo, que el criterio sigue siendo tuyo. La IA lanza nmap más rápido que tú, sí. Pero decidir qué es scope, qué no lanzas un viernes contra producción, cómo interpretas un hallazgo y cómo lo priorizas para el cliente… eso no lo automatiza un fullscan. Eso es el oficio.