Motore autonomo di penetration testing basato su AI multi-agente: un sandbox di strumenti governato, un gate immutabile di evidenza e validazione, e un ambiente riproducibile di valutazione per agenti di sicurezza.
OIHK-pentesting è un motore multi-agente autonomo per valutazioni di sicurezza autorizzate. Un planner root delega ad agenti di recon, discovery, attack (Privesc), validation e reporting — e il motore stesso applica le policy di scope, egress, evidenze e risorse indipendentemente da quale modello lo guidi. I finding richiedono evidenze di esecuzione reali più una validazione indipendente; una storia convincente non prova nulla.
Si misura contro il proprio benchmark di scenari vulnerabili — il solver mock deterministico mantiene 24/24 a 100/100 — e funziona completamente offline con qualsiasi modello locale compatibile con OpenAI.
Beta iniziale, in sviluppo attivo. Il comportamento può cambiare senza preavviso; alcune funzionalità sono parziali o deliberatamente escluse. Verifica prima di farci affidamento — vedi la matrice di stato.
La maggior parte del tooling offensivo si affida al buon comportamento del modello. OIHK no: il confine di sicurezza vive nel motore e regge indipendentemente da ciò che il modello è disposto a dire.
example.com non autorizza i suoi sottodomini; gli host dichiarati sono DNS-pinned per l'intera esecuzione.| OS | Windows 10/11 e Linux (Kali testato). macOS non testato. |
| Python | 3.12+ con uv |
| Docker | Necessario per il sandboxing delle scansioni. L'OSINT passivo di Baron funziona senza. |
| RAM | 8 GB minimo, 16 GB consigliati |
| GPU | Non richiesta da OIHK. Un modello locale gira su CPU o GPU — i suoi requisiti sono quelli del modello. |
| Modello | Qualsiasi endpoint compatibile con OpenAI (LM Studio di default), o una chiave cloud via /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
Su Kali Linux, assicurati che Docker sia in esecuzione prima (sudo systemctl start docker).
Oppure apri Baron, il copilota interattivo — tu parli, lui guida il motore governato (default passivo a meno che tu non autorizzi una valutazione approfondita):
uv run oihk start
Baron esegue valutazioni reali, risponde con ricette di tool esatte da un corpus RAG di 164 tool, fa pivot attraverso l'OSINT (page_osint, username_osint, domain_osint, breach_osint, phone_osint), e ricorda ogni sessione in Redis. Non ottiene mai una shell grezza — solo il motore governato — e tutto è guidato da menu: /models, /apimodel, /adaptador e /instancia aprono picker interattivi Textual. /power <0-100> imposta il budget di parallelismo — quanti container sandbox extra possono vivere contemporaneamente — così Docker e la macchina dell'operatore non vengono mai soffocati automaticamente; 0 mantiene una singola istanza on-demand.
La TUI si disegna istantaneamente (lo stack pesante del modello si carica dietro la prima riga "pensando…") ed è completamente guidata da tastiera: il mouse reporting è deliberatamente disattivato — alcuni terminali fanno trapelare byte grezzi del mouse nell'input — quindi Ctrl+G ferma la generazione, PageUp/PageDown scorrono la cronologia, Ctrl+L pulisce il log e Ctrl+/ apre il menu dei comandi.
Non ci sono scorciatoie di attacco da memorizzare: basta digitare un target — una web app, un host, un IP — e Baron lo rileva, pianifica la valutazione e delega i passi di attacco alla flotta di subagenti qui sotto. Si auto-migliora anche dai propri fallimenti: ogni errore diventa una lezione pesata e a decadimento in AdapterOne (registro sotto oihk_runs/adapterone/), iniettata automaticamente nei suoi prompt futuri, con adapterone_review / adapterone_confirm per consultare e rafforzare le regole durante l'esecuzione.
Mentre oihk start è in esecuzione, puoi affidare a Baron shell reali alle tue condizioni. In qualsiasi terminale del progetto, uv run oihk bashai trova il beacon LAN di Baron, rivalida un segreto di handshake, mostra un avviso esplicito di pieno controllo e si connette solo alla tua accettazione (numeri di coda bashai-1, bashai-2, …; nessuna identità persistente, solo posizione). Baron invia comandi a quei terminali — in parallelo — e ogni comando e risultato finisce in un log di audit persistente (oihk_runs/bashai/audit.jsonl) che alimenta il gate delle evidenze. Con OIHK_CONFIRM_COMMANDS=1 (o /confirmar on nella TUI), ogni comando attende la tua conferma esplicita in quel terminale prima di eseguire; il default è l'esecuzione diretta con un avviso rafforzato registrato nel log di audit. Il client invia heartbeat costantemente e si spegne immediatamente se Baron smette di rispondere.