Motor de pruebas de penetración con IA multiagente autónomo: un sandbox de herramientas gobernado, una puerta inmutable de evidencia y validación, y un entorno reproducible de evaluación de agentes de seguridad.
OIHK-pentesting es un motor autónomo multiagente para evaluaciones de seguridad autorizadas. Un planificador raíz delega en agentes de reconocimiento, descubrimiento, ataque (Privesc), validación y generación de informes — y el propio motor impone el alcance, la salida de red, la evidencia y la política de recursos sin importar qué modelo lo impulse. Los hallazgos requieren evidencia de ejecución real más una validación independiente; una historia convincente no demuestra nada.
Se puntúa contra su propio benchmark de escenarios vulnerables — el solucionador mock determinista mantiene 24/24 con 100/100 — y se ejecuta totalmente offline contra cualquier modelo local compatible con OpenAI.
Beta temprana, en desarrollo activo. El comportamiento puede cambiar sin aviso; algunas capacidades son parciales o se han dejado fuera deliberadamente. Verifica antes de confiar en él — consulta la matriz de estado.
La mayoría de las herramientas ofensivas confían en el buen comportamiento del modelo. OIHK no: el límite de seguridad vive en el motor y se mantiene independientemente de lo que el modelo esté dispuesto a decir.
example.com no autoriza sus
subdominios; los hosts declarados quedan fijados por DNS durante toda la
ejecución.| SO | Windows 10/11 y Linux (probado en Kali). macOS no está probado. |
| Python | 3.12+ con uv |
| Docker | Necesario para el sandboxing de escaneos. El OSINT pasivo de Baron funciona sin él. |
| RAM | 8 GB mínimo, 16 GB recomendado |
| GPU | No la requiere OIHK. Un modelo local se ejecuta en CPU o GPU — sus propios requisitos son los del modelo. |
| Modelo | Cualquier endpoint compatible con OpenAI (LM Studio por defecto), o una clave en la nube vía /apimodel//models: Claude, ChatGPT, Gemini, Grok, DeepSeek, NVIDIA NIM |
git clone https://github.com/Broskigx/Oihk-pentesting.git
cd Oihk-pentesting
uv sync
uv run oihk --help
uv run oihk run -t https://example.test --mode passive --scan-mode standard
En Kali Linux, asegúrate de que Docker esté en ejecución primero (sudo systemctl start docker).
O abre Baron, el copiloto interactivo — tú hablas, él dirige el motor gobernado (por defecto en pasivo a menos que autorices una evaluación profunda):
uv run oihk start
Baron ejecuta evaluaciones reales, responde con recetas exactas de herramientas
de un corpus RAG de 164 herramientas, pivota a través de OSINT (page_osint,
username_osint, domain_osint, breach_osint, phone_osint) y recuerda
cada sesión en Redis. Nunca obtiene un shell en bruto — solo el motor
gobernado — y todo está dirigido por menús: /models, /apimodel,
/adaptador y /instancia abren selectores interactivos de Textual.
/power <0-100> establece el presupuesto de paralelismo — cuántos contenedores
sandbox adicionales pueden existir a la vez — para que Docker y la máquina del
operador nunca se saturen automáticamente; 0 mantiene una única instancia bajo
demanda.
La TUI se dibuja al instante (la pesada pila del modelo se carga tras la
primera línea "pensando…") y se maneja completamente por teclado: el reporte
del ratón está deliberadamente desactivado — algunas terminales filtran bytes
de ratón en bruto hacia la entrada — así que Ctrl+G detiene la generación,
PageUp/PageDown pasan las páginas del historial, Ctrl+L limpia el
registro y Ctrl+/ abre el menú de comandos.
No hay atajos de ataque que memorizar: solo escribe un objetivo — una
aplicación web, un host, una IP — y Baron lo detecta, planifica la evaluación y
delega los pasos de ataque a la flota de subagentes de abajo. También se
mejora a sí mismo a partir de sus propios fallos: cada error se convierte en
una lección ponderada y decreciente en AdapterOne (registro bajo
oihk_runs/adapterone/), inyectada automáticamente en sus prompts futuros, con
adapterone_review / adapterone_confirm para consultar y reforzar las reglas
a mitad de ejecución.