Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Oihk-pentesting — Moteur autonome de test d'intrusion par IA multi-agents : un bac à sable d'outils gouverné, une porte immuable de preuve et de validation, et un environnement reproductible d'évaluation d'agents de sécurité. | Kitploit
Outils/GitHubGitHub/broskigx/oihk-pentesting
OSINT (Renseignement de Sources Ouvertes)Frameworks de Tests d'IntrusionEscalade de PrivilègesScanners de VulnérabilitésFrameworks d'ExploitationScripting et AutomatisationApprentissage et ÉducationRed TeamingSécurité de l'IALabs et Pratique
GitHub
4110il y a 2 joursPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
broskigx/oihk-pentesting

Oihk-pentesting

Moteur autonome de test d'intrusion par IA multi-agents : un bac à sable d'outils gouverné, une porte immuable de preuve et de validation, et un environnement reproductible d'évaluation d'agents de sécurité.

Voir le dépôtSite web
Apóyame en Ko-fi — BROSKIGX

OIHK-pentesting

Un moteur multi-agents pour les évaluations de sécurité autorisées. Un planificateur racine délègue aux agents de reconnaissance, de découverte, d'attaque (OPTIZero), de validation et de rapport — et le moteur lui-même applique les politiques de périmètre, de sortie réseau, de preuve et de ressources, quel que soit le modèle qui le pilote. Les constats nécessitent une preuve d'exécution réelle plus une validation indépendante ; une histoire convaincante ne prouve rien.

Il s'évalue sur son propre benchmark de scénarios vulnérables — le solveur factice déterministe obtient 24/24 à 100/100 — et fonctionne entièrement hors ligne avec n'importe quel modèle local compatible OpenAI.

Bêta précoce, en développement actif. Le comportement peut changer sans préavis ; certaines capacités sont partielles ou délibérément absentes. Vérifiez avant de vous y fier — voir la matrice de statut.

CI Python Types Lint Tests Status Tested on Windows Tested on Kali Linux License: MIT

OIHK en action — démo en direct

Table des matières

  • Pourquoi OIHK
  • Prérequis
  • Démarrage rapide
  • Inférence locale
  • Architecture
  • Évaluation des agents IA
  • Structure du dépôt
  • Documentation
  • Mentions légales
  • Licence

Pourquoi OIHK

La plupart des outils offensifs font confiance au bon comportement du modèle. OIHK non : la frontière de sécurité réside dans le moteur et tient quel que soit ce que le modèle est prêt à dire.

  • Constats conditionnés par les preuves. Un constat nécessite une exécution d'outil gouvernée réelle, autorisée et réussie, plus un enregistrement de validation distinct — et seul un agent de validation peut en créer un.
  • Périmètre exact, aucune dérive. Déclarer example.com n'autorise pas ses sous-domaines ; les hôtes déclarés sont épinglés par DNS pour toute la durée de l'exécution.
  • Sortie réseau en échec fermé. Le périmètre se compile en une liste d'autorisation netfilter à l'intérieur du propre espace de noms réseau du bac à sable ; là où cela ne peut être garanti, le démarrage s'interrompt au lieu de prétendre isoler.
  • Une surface d'outils gouvernée. Le mode passif expose une surface réduite et rejette l'exécution active — y compris les tentatives routées via le shell générique.
  • Un cœur agnostique au modèle. N'importe quel point de terminaison compatible OpenAI, routage par rôle, rien de codé en dur pour un fournisseur — le même harnais évalue n'importe quel modèle.

Prérequis

Démarrage rapide

root@kitploit:~
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

Sur Kali Linux, assurez-vous d'abord que Docker est démarré (sudo systemctl start docker).

Ou ouvrez Baron, le copilote interactif — vous parlez, il pilote le moteur gouverné (mode passif par défaut, sauf si vous autorisez une évaluation approfondie) :

root@kitploit:~
uv run oihk start

Baron exécute de vraies évaluations, répond avec des recettes d'outils exactes issues d'un corpus RAG de 156 outils, pivote via l'OSINT (page_osint, username_osint, domain_osint, breach_osint, phone_osint), et mémorise chaque session dans Redis. Il n'obtient jamais de shell brut — uniquement le moteur gouverné — et tout est piloté par menus : /apimodel, /adaptador et /instancia ouvrent des sélecteurs Textual interactifs.

Inférence locale

Les valeurs par défaut pointent vers LM Studio sur http://localhost:1234/v1 :

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

Fournisseurs cloud — /apimodel

N'importe lequel des six préréglages se connecte avec une seule commande ; chacun mémorise sa propre clé :

root@kitploit:~
/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 (sans argument) ouvre le sélecteur de plateforme ; /apimodel <plataforma> se reconnecte avec la clé enregistrée ; /apimodel off déconnecte. Tout autre fournisseur compatible OpenAI fonctionne via /models base + /models key + /models use.

Deux préfixes cloud suppriment aussi toute configuration de point de terminaison au niveau de l'environnement : deepseek/… et nvidia_build/… routent vers leurs API de fournisseur — définissez la clé, rien d'autre. Les surcharges par rôle (OIHK_ROOT_LLM, OIHK_RECON_LLM, …) routent les rôles logiques vers différents modèles.

Choisir un modèle

OIHK fonctionne mieux avec un modèle qui ne refuse pas à l'excès : les assistants fortement alignés sur la sécurité déclinent des étapes offensives légitimes et autorisées et bloquent l'agent en pleine évaluation. Cela n'abaisse pas la sécurité d'OIHK — la frontière n'a jamais été les refus du modèle ; c'est le périmètre exact du moteur, la sortie réseau en échec fermé, la surface d'outils gouvernée et la barrière de preuve, qui tiennent quoi que dise le modèle.

Architecture

Un planificateur racine détient un unique ScanPlan versionné et délègue les étapes aux agents enfants. Chaque appel d'outil gouverné franchit quatre autorités de politique — mode/rôle, périmètre exact, gouverneur de ressources, sortie réseau du bac à sable — avant de s'exécuter, et sa sortie devient une preuve immuable dans le registre d'exécution. Seul un agent de validation peut transformer cette preuve en constat ; la racine ne peut pas terminer une exécution tant que le travail critique est ouvert. Les exécutions reprennent à partir des artefacts (--resume <run-id>) et atterrissent sous oihk_runs/<run-id>/ (plan, preuves, validations, constats, SARIF, rapport).

root@kitploit:~
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, le rôle attack, apporte un catalogue déclaratif de vecteurs d'élévation de privilèges pour Windows, Linux et macOS derrière un limiteur de débit adaptatif AIMD — et la racine contrôle toute la flotte en vol (list_children, send_message, stop_child, broadcast). Détails dans ARCHITECTURE.

Évaluation des agents IA

OIHK sert aussi de propre environnement d'évaluation : le vrai moteur s'exécute contre 24 scénarios vulnérables fournis — web, API, authentification, code source, configuration, et privesc/crypto/CVE alignés sur AutoPenBench — et un vérificateur programmatique note de manière normalisée de 0 à 100 selon l'exactitude des constats, la validité des preuves, l'usage des outils, l'efficacité et l'évitement des faux positifs. Aucun modèle ne se note lui-même.

root@kitploit:~
uv run oihk eval list
uv run oihk eval run-all --model mock
uv run oihk eval compare --models mock,mock:wrong_finding

Le même harnais est fourni comme environnement verifiers sur le Prime Intellect Hub (broskigx/oihk-security-agent) :

root@kitploit:~
prime env install broskigx/oihk-security-agent
vf-eval oihk-security-agent -m mock

Table complète des scénarios, formule de notation et correspondance des benchmarks : EVALUATION.

Structure du dépôt

root@kitploit:~
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

Affiner votre propre modèle

scripts/build_lora_dataset.py génère un jeu de données LoRA bilingue (espagnol/anglais) — 536 échantillons chacun, 336 avec de vrais appels d'outils — à partir du corpus d'outils gouvernés et des 24 scénarios d'évaluation, incluant des comportements de sécurité (discipline de périmètre, barrière docker, résistance à l'injection). Entraînez-le sur Qwen2.5-14B-Instruct, exportez un GGUF Q4_K_M, et servez-le dans Ollama ou LM Studio : pipeline complet dans deploy/local-models.

Documentation

Mentions légales

Usage autorisé uniquement. OIHK teste activement les cibles qui lui sont fournies. L' opérateur est seul responsable de l'autorisation, des limites sûres, de la disponibilité des cibles, du traitement des données et de la conformité à la loi applicable.

Pour signaler une vulnérabilité de sécurité dans OIHK lui-même, voir Signaler une vulnérabilité.

Licence

Publié sous la licence MIT — libre d'utilisation, de modification et de distribution, y compris commerciale, tant que la mention de copyright et le texte de la licence restent en place.

Télécharger l’outil
OSWindows 10/11 et Linux (Kali testé). macOS non testé.
Python3.12+ avec uv
DockerRequis pour le bac à sable des scans. L'OSINT passif de Baron fonctionne sans.
RAM8 Go minimum, 16 Go recommandés
GPUNon requis par OIHK. Un modèle local tourne sur CPU ou GPU — ses propres prérequis sont ceux du modèle.
ModèleN'importe quel point de terminaison compatible OpenAI (LM Studio par défaut), ou une clé cloud via /apimodel : Claude, ChatGPT, Gemini, Grok, DeepSeek, NVIDIA NIM
DocContenu
ARCHITECTUREGraphe d'agents, stockage de plan, autorités de politique, OPTIZero
SECURITYFrontières de confiance, modèle de menace, signalement d'une vulnérabilité
STATUS-MATRIXCe qui est implémenté, partiel ou délibérément absent
CONFIGURATIONRéférence complète des variables d'environnement — gouvernance, bac à sable, mémoire
EVALUATIONLes 24 scénarios, vérificateur, notation, correspondance AutoPenBench
FINDINGSSchéma des constats, SARIF, artefacts de remédiation
PRIME-INTELLECTEnvironnement Verifiers et cadrage du calcul
CHANGELOGChaque changement, par version
.env.exampleLe sous-ensemble opérationnel des variables d'environnement