OIHK-pentesting

OIHK-pentesting é um motor autônomo multiagente para avaliações de segurança autorizadas. Um planejador raiz delega para agentes de reconhecimento, descoberta, ataque (Privesc), validação e relatório — e o próprio motor impõe escopo, egress, evidência e política de recursos, independentemente de qual modelo o conduz. Achados exigem evidência de execução real mais validação independente; uma história convincente não prova nada.

Ele pontua contra seu próprio benchmark de cenários vulneráveis — o solucionador mock determinístico mantém 24/24 com 100/100 — e roda totalmente offline contra qualquer modelo local compatível com OpenAI.

Beta inicial, em desenvolvimento ativo. O comportamento pode mudar sem aviso; algumas capacidades são parciais ou deliberadamente omitidas. Verifique antes de confiar — veja a matriz de status.

Índice

• Por que OIHK
• Requisitos
• Início rápido
• Baron, o copiloto interativo
• bashai, os terminais do operador
• Inferência local
• Arquitetura
• Avaliação de agente de IA
• Layout do repositório
• Ajuste fino do seu próprio modelo
• Documentação
• Contribuindo
• Legal
• Licença

Por que OIHK

A maioria das ferramentas ofensivas confia no bom comportamento do modelo. OIHK não: a fronteira de segurança vive no motor e se mantém independentemente do que o modelo esteja disposto a dizer.

• Achados condicionados a evidência. Um achado precisa de uma execução de ferramenta governada real, própria e bem-sucedida, mais um registro de validação separado — e apenas um agente de validação pode criar um.
• Escopo exato, sem desvio. Declarar example.com não autoriza seus subdomínios; hosts declarados são fixados por DNS durante toda a execução.
• Egress falha fechado. O escopo é compilado em uma allowlist de netfilter dentro do próprio namespace de rede do sandbox; onde isso não pode ser garantido, a inicialização é abortada em vez de fingir isolar.
• Uma superfície de ferramentas governada. O modo passivo expõe uma superfície reduzida e rejeita execução ativa — incluindo tentativas roteadas pelo shell genérico.
• Um núcleo agnóstico de modelo. Qualquer endpoint compatível com OpenAI, roteamento por função, nada codificado para um provedor — o mesmo harness pontua qualquer modelo.

Requisitos

SO	Windows 10/11 e Linux (Kali testado). macOS não testado.
Python	3.12+ com uv
Docker	Necessário para sandboxing de varredura. O OSINT passivo do Baron funciona sem ele.
RAM	8 GB mínimo, 16 GB recomendado
GPU	Não exigida pelo OIHK. Um modelo local roda em CPU ou GPU — seus próprios requisitos são os do modelo.
Modelo	Qualquer endpoint compatível com OpenAI (LM Studio por padrão), ou uma chave de nuvem via /apimodel//models: Claude, ChatGPT, Gemini, Grok, DeepSeek, NVIDIA NIM

Início rápido

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

No Kali Linux, certifique-se de que o Docker está em execução primeiro (sudo systemctl start docker).

Ou abra o Baron, o copiloto interativo — você fala, ele conduz o motor governado (padrão passivo, a menos que você autorize uma avaliação profunda):

uv run oihk start

Baron, o copiloto interativo

O Baron executa avaliações reais, responde com receitas exatas de ferramentas de um corpus RAG de 164 ferramentas, faz pivôs por OSINT (page_osint, username_osint, domain_osint, breach_osint, phone_osint) e lembra de cada sessão no Redis. Ele nunca recebe um shell bruto — apenas o motor governado — e tudo é orientado por menus: /models, /apimodel, /adaptador e /instancia abrem seletores interativos Textual. /power <0-100> define o orçamento de paralelismo — quantos contêineres sandbox extras podem existir ao mesmo tempo — para que o Docker e a máquina do operador nunca sejam sufocados automaticamente; 0 mantém uma única instância sob demanda.

A TUI é desenhada instantaneamente (a pilha pesada do modelo carrega atrás da primeira linha "pensando…") e é totalmente controlada por teclado: o reporte do mouse é deliberadamente desativado — alguns terminais vazam bytes brutos do mouse na entrada — então Ctrl+G interrompe a geração, PageUp/PageDown paginam o histórico, Ctrl+L limpa o log e Ctrl+/ abre o menu de comandos.

Não há atalhos de ataque para memorizar: basta digitar um alvo — um aplicativo web, um host, um IP — e o Baron o detecta, planeja a avaliação e delega as etapas de ataque à frota de subagentes abaixo. Ele também se aprimora a partir de suas próprias falhas: cada erro se torna uma lição ponderada e decrescente no AdapterOne (registro em oihk_runs/adapterone/), injetada automaticamente em seus prompts futuros, com adapterone_review / adapterone_confirm para consultar e reforçar as regras durante a execução.

bashai, os terminais do operador

Enquanto oihk start roda, você pode entregar ao Baron shells reais nos seus termos. Em qualquer terminal do projeto, uv run oihk bashai encontra o beacon de LAN do Baron, revalida um segredo de handshake, mostra um aviso explícito de controle total e conecta apenas com a sua aceitação (números de fila bashai-1, bashai-2, …; sem identidade persistente, apenas posição). O Baron despacha comandos para esses terminais — em paralelo — e cada comando e resultado vai para um log de auditoria persistente (oihk_runs/bashai/audit.jsonl) que alimenta o portão de evidências. Com OIHK_CONFIRM_COMMANDS=1 (ou /confirmar on na TUI), cada comando aguarda sua confirmação explícita naquele terminal antes de executar; o padrão é execução direta com um aviso reforçado registrado no log de auditoria. O cliente envia heartbeats constantemente e desliga imediatamente se o Baron parar de responder.