Vue d'ensemble de l'architecture¶

HYDRA × PDX est un système à trois couches : capture, routage et sortie, connectées par une boucle de retour continue.

Couche 1 — Capture¶

Deux sources de données indépendantes alimentent le pipeline :

HYDRA (passif)¶

Un honeypot SSH exposé sur le port 2222. Les attaquants se connectent, s'authentifient (tout credential est accepté), et interagissent avec un environnement Linux simulé. Chaque commande est traitée par llama-3.3-70b (via l'API Groq) qui génère des réponses contextuelles en temps réel.

HYDRA n'est pas un système de replay statique. Il maintient un système de fichiers virtuel mutable par session (Copy-on-Write), alterne entre trois personas (fintech_trading, crypto_validator, corp_ad), et inclut un anti-empreinte profond pour déjouer les techniques standard de détection de honeypots.

Le routeur de commandes gère un pipeline en 9 étapes : sanitize → PromptGuard → expand → split → pipes → classify → execute → mutate VFS → log. 65+ commandes built-in gèrent les utilitaires courants nativement ; tout le reste est routé vers le LLM avec le contexte VFS complet.

Chaque session produit un fichier JSONL avec des événements structurés : auth_attempt, session_start, command_executed, injection_detected, session_end.

Pont Burp Suite (actif)¶

Une extension Java + un proxy Python qui connecte PDX à Burp Suite. Pendant un pentest web, chaque paire requête/réponse HTTP est analysée et convertie au même format delta .pdx utilisé par HYDRA.

Le même pipeline traite ainsi à la fois les données passives du honeypot et les résultats actifs de pentest.

Couche 2 — Routage¶

Le SessionClassifier sépare d'abord le signal du bruit — seuls 2,2 % des sessions (interactions humaines) passent. Il identifie 5 catégories de trafic automatisé (bot_ephemeral, bot_exec_scanner, bot_dropper, bot_recon, unclassified) et une catégorie signal (likely_human).

Le DataRouter lit ensuite chaque événement et le classifie dans un ou plusieurs flux :

• Défensif — chaque command_executed et auth_attempt y va. Utilisé pour l'entraînement à la détection.
• Offensif — les commandes correspondant à des patterns d'attaque connus (accès aux credentials, escalade de privilèges, mouvement latéral) y vont. Utilisé pour la reconstruction de chaînes d'attaque.
• Les deux — la plupart des événements se qualifient pour les deux flux. Le même cat /etc/shadow est à la fois une alerte de détection (défensif) et une technique d'extraction de credentials (offensif).

La classification repose sur un mapping MITRE ATT&CK avec 11 tactiques, chacune ayant une description duale dans le code.

Couche 3 — Sortie¶

Sept générateurs d'entraînement produisent des datasets structurés :

Avant l'export, tout passe par un Pipeline Qualité : déduplication par trigrammes, filtrage qualité (avec pondération de validation humaine), ordonnancement curriculaire (exemples simples d'abord, kill chains complexes ensuite) et décroissance temporelle (demi-vie de 90 jours).

Le fine-tuning s'exécute localement via Unsloth avec des adaptateurs LoRA sur des modèles Qwen ou Llama.

La boucle de retour¶

Le pipeline n'est pas unidirectionnel. L'Orchestrateur Pipeline PDX coordonne un cycle de feedback continu :

1. SessionAnalyzer parse les logs HYDRA en deltas structurés
2. FeedbackEngine regroupe le comportement des attaquants en profils et calcule des métriques agrégées
3. LureGenerator traduit les métriques en changements concrets du système de fichiers (nouveaux fichiers leurres, credentials mis à jour, .bash_history enrichi)
4. FeedbackStore écrit feedback.yaml
5. FeedbackConsumer (dans HYDRA) poll toutes les 60s et injecte les mises à jour dans le VFS live

L'orchestrateur peut tourner en trois modes : one-shot (--once), mode watch (--watch pour la surveillance continue), ou mode auto (déclenché par l'AutoTraining quand le seuil min_sessions est atteint).

Résultat : le honeypot s'améliore de lui-même continuellement. Après 48h de feedback, l'engagement moyen du persona fintech est passé de ~800 à 1 349 commandes par session.

Analyse multi-modèles¶

PDX ne repose pas sur un seul LLM. Une cascade à 4 niveaux analyse chaque delta de sécurité :

Niveau 1 : Copilot local (7B)     — première passe rapide sur chaque delta
   ↓ incertain ?
Niveau 2 : Teacher local (32B)    — seconde passe détaillée
   ↓ toujours incertain ?
Niveau 3 : API Anthropic          — quand la complexité l'exige
   ↓ indisponible ?
Niveau 4 : WebChat fallback       — marqué NÉCESSITE VALIDATION HUMAINE

Chaque niveau produit un verdict (VULNERABLE, NOT_VULN, INFORMATIONAL, UNCERTAIN, FALSE_POS). Quand les niveaux divergent, le conflit est signalé. Rien n'est supprimé.

Enrichissement des données¶

8 collecteurs enrichissent chaque observation avec du contexte externe : NVD/NIST (CVEs), ExploitDB (exploits connus), OWASP (classifications web), MITRE ATT&CK (tactiques/techniques), Nuclei (signatures de détection), CWE (classifications de faiblesses), IETF RFCs (spécifications de protocoles) et pages man Linux (documentation des commandes).

Infrastructure¶