OIHK-pentesting

Eine Multi-Agenten-Engine für autorisierte Sicherheitsbewertungen. Ein Root-Planer delegiert an Recon-, Discovery-, Attack- (OPTIZero), Validation- und Reporting- Agenten — und die Engine selbst erzwingt Scope, Egress, Evidenz und Ressourcen- richtlinien, unabhängig davon, welches Modell sie steuert. Findings erfordern echte Ausführungsnachweise plus unabhängige Validierung; eine überzeugende Geschichte beweist nichts.

Sie bewertet gegen ihren eigenen Benchmark für verwundbare Szenarien — der deterministische Mock-Solver hält 24/24 bei 100/100 — und läuft vollständig offline gegen jedes OpenAI-kompatible lokale Modell.

Frühe Beta, in aktiver Entwicklung. Das Verhalten kann sich ohne Vorankündigung ändern; einige Fähigkeiten sind teilweise oder bewusst ausgelassen. Verifiziere, bevor du dich darauf verlässt — siehe die Status-Matrix.

Inhaltsverzeichnis

• Warum OIHK
• Anforderungen
• Schnellstart
• Lokale Inferenz
• Architektur
• KI-Agenten-Evaluierung
• Repository-Struktur
• Dokumentation
• Rechtliches
• Lizenz

Warum OIHK

Die meisten Offensive-Tools vertrauen auf das Wohlverhalten des Modells. OIHK nicht: die Sicherheitsgrenze liegt in der Engine und hält stand, unabhängig davon, was das Modell zu sagen bereit ist.

• Evidenzgestützte Findings. Ein Finding benötigt eine echte, eigene, erfolgreiche gesteuerte Tool-Ausführung plus einen separaten Validierungsdatensatz — und nur ein Validierungsagent kann einen solchen erstellen.
• Exakter Scope, keine Abweichung. Die Deklaration von example.com autorisiert nicht dessen Subdomains; deklarierte Hosts werden für den gesamten Lauf per DNS gepinnt.
• Egress schlägt fehl, geschlossen. Der Scope wird in eine Netfilter-Allowlist innerhalb des eigenen Netzwerk-Namespace der Sandbox kompiliert; wo das nicht garantiert werden kann, bricht der Start ab, statt Isolation vorzutäuschen.
• Eine gesteuerte Tool-Oberfläche. Der Passive-Modus legt eine reduzierte Oberfläche offen und lehnt aktive Ausführung ab — einschließlich Versuchen, die über die generische Shell geleitet werden.
• Ein modellagnostischer Kern. Jeder OpenAI-kompatible Endpunkt, Routing pro Rolle, nichts fest an einen Anbieter gebunden — dieselbe Harness bewertet jedes Modell.

Anforderungen

Schnellstart

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

Unter Kali Linux stelle zuerst sicher, dass Docker läuft (sudo systemctl start docker).

Oder öffne Baron, den interaktiven Copiloten — du sprichst, er steuert die gesteuerte Engine (standardmäßig passiv, es sei denn, du autorisierst eine tiefgehende Bewertung):

uv run oihk start

Baron führt echte Bewertungen durch, antwortet mit exakten Tool-Rezepten aus einem 156-Tool- RAG-Korpus, pivotiert durch OSINT (page_osint, username_osint, domain_osint, breach_osint, phone_osint) und merkt sich jede Sitzung in Redis. Er erhält niemals eine rohe Shell — nur die gesteuerte Engine — und alles ist menügesteuert: /apimodel, /adaptador und /instancia öffnen interaktive Textual-Picker.

Lokale Inferenz

Die Standardeinstellungen zeigen auf LM Studio unter http://localhost:1234/v1:

export OIHK_LLM="openai/mistral-nemo"
export OIHK_API_BASE="http://localhost:1234/v1"
export OIHK_API_KEY="lm-studio"

Cloud-Anbieter — /apimodel

Jedes der sechs Presets verbindet sich mit einem Befehl; jedes merkt sich seinen eigenen Schlüssel:

/apimodel claude sk-ant-…          # Anthropic
/apimodel chatgpt sk-…             # OpenAI
/apimodel gemini AIza…             # Google AI Studio
/apimodel grok xai-…               # xAI
/apimodel deepseek sk-…            # DeepSeek
/apimodel nvidia nvapi-… [model]   # NVIDIA NIM

/apimodel (ohne Argumente) öffnet den Plattform-Picker; /apimodel <plataforma> verbindet sich mit dem gespeicherten Schlüssel neu; /apimodel off trennt die Verbindung. Jeder andere OpenAI-kompatible Anbieter funktioniert über /models base + /models key + /models use.

Zwei Cloud-Präfixe entfernen zudem jede Endpunkt-Einrichtung auf Umgebungsvariablen-Ebene: deepseek/… und nvidia_build/… leiten zu ihren Anbieter-APIs — setze den Schlüssel, sonst nichts. Überschreibungen pro Rolle (OIHK_ROOT_LLM, OIHK_RECON_LLM, …) leiten logische Rollen an verschiedene Modelle.

Ein Modell auswählen

OIHK funktioniert am besten mit einem Modell, das nicht übermäßig verweigert: stark sicherheitsoptimierte Assistenten lehnen legitime, autorisierte offensive Schritte ab und blockieren den Agenten mitten in der Bewertung. Dies senkt nicht OIHKs Sicherheit — die Grenze war nie die Verweigerung des Modells; es ist der exakte Scope der Engine, der fehlschlagende Egress, die gesteuerte Tool-Oberfläche und das Evidenz-Gate, die standhalten, egal was das Modell sagt.

Architektur

Ein Root-Planer besitzt einen einzigen versionierten ScanPlan und delegiert Schritte an untergeordnete Agenten. Jeder gesteuerte Tool-Aufruf passiert vier Richtlinien-Instanzen — Modus/Rolle, exakter Scope, Ressourcen-Governor, Sandbox-Egress — bevor er ausgeführt wird, und seine Ausgabe wird zu unveränderlicher Evidenz im Run-Ledger. Nur ein Validierungsagent kann diese Evidenz in ein Finding umwandeln; der Root kann einen Lauf nicht beenden, während kritische Arbeit offen ist. Läufe werden aus Artefakten fortgesetzt (--resume <run-id>) und landen unter oihk_runs/<run-id>/ (Plan, Evidenz, Validierungen, Findings, SARIF, Bericht).

flowchart TB
    OP([Operator: scope + mode]) --> ROOT[Root planner]
    ROOT --> RECON[Recon]
    ROOT --> DISC[Discovery]
    ROOT --> ATTACK[Attack - OPTIZero]
    ROOT --> VALID[Validation]
    ROOT --> REPORT[Reporting]

    RECON --> GATE
    DISC --> GATE
    ATTACK --> GATE
    VALID --> GATE

    subgraph GATE[Policy authorities - fail closed]
        direction LR
        M[Mode / role] --> S[Exact scope] --> G[Resource governor] --> BOX[Sandbox: egress allowlist]
    end

    GATE --> LEDGER[(Evidence ledger)]
    LEDGER --> VALID
    VALID --> FIND[Findings + SARIF report]
</mermaid>

OPTIZero, die attack-Rolle, bringt einen deklarativen Katalog für Privilegien- Eskalationsvektoren für Windows, Linux und macOS hinter einem adaptiven AIMD-Ratenbegrenzer — und der Root steuert die gesamte Flotte im Flug (list_children, send_message, stop_child, broadcast). Details in ARCHITECTURE.

KI-Agenten-Evaluierung

OIHK dient zugleich als seine eigene Eval-Umgebung: die echte Engine läuft gegen 24 mitgelieferte verwundbare Szenarien — Web, API, Auth, Quellcode, Konfiguration und AutoPenBench-konforme Privesc/Crypto/CVE — und ein programmatischer Verifier bewertet normalisiert 0–100 über Finding-Korrektheit, Evidenz-Gültigkeit, Tool-Nutzung, Effizienz und Vermeidung von Falsch-Positiven. Kein Modell bewertet sich selbst.

uv run oihk eval list
uv run oihk eval run-all --model mock
uv run oihk eval compare --models mock,mock:wrong_finding

Dieselbe Harness wird als verifiers- Umgebung auf dem Prime Intellect Hub ausgeliefert (broskigx/oihk-security-agent):

prime env install broskigx/oihk-security-agent
vf-eval oihk-security-agent -m mock

Vollständige Szenariotabelle, Bewertungsformel und Benchmark-Zuordnung: EVALUATION.

Repository-Struktur

oihk/          CLI, policy/governance, agents, tools, sandbox, findings
oihk/evals/    evaluation subsystem (scenarios, verifier, scoring, mock provider)
environments/  standalone verifiers environment package (Prime Intellect Hub)
containers/    sandbox image, entry point, browser driver, SBOM generation
deploy/        local-model LoRA pipeline: dataset trainer, Ollama Modelfiles
docs/          architecture, security boundary, configuration, evaluation
tests/         unit, regression, and opt-in integration tests
ToolsHelp/     RAG corpus: 156 governed-tool cards
skills/        external-agent skill packs

Dein eigenes Modell feinabstimmen

scripts/build_lora_dataset.py generiert einen zweisprachigen (Spanisch/Englisch) LoRA-Datensatz — je 536 Samples, 336 mit echten Tool-Aufrufen — aus dem gesteuerten Tool-Korpus und den 24 Eval-Szenarien, einschließlich Sicherheitsverhalten (Scope- Disziplin, Docker-Gate, Injektionsresistenz). Trainiere ihn gegen Qwen2.5-14B-Instruct, exportiere ein Q4_K_M GGUF und serviere es in Ollama oder LM Studio: vollständige Pipeline in deploy/local-models.

Dokumentation

Rechtliches

Nur autorisierte Nutzung. OIHK testet aktiv die Ziele, die ihm gegeben werden. Der Betreiber ist allein verantwortlich für Autorisierung, sichere Grenzen, Ziel- Verfügbarkeit, Datenhandhabung und Einhaltung geltenden Rechts.

Um eine Sicherheitsschwachstelle in OIHK selbst zu melden, siehe Melden einer Schwachstelle.

Lizenz

Veröffentlicht unter der MIT-Lizenz — frei zu nutzen, zu ändern und zu verbreiten, einschließlich kommerziell, solange der Urheberrechtshinweis und der Lizenz- text erhalten bleiben.