Aller au contenu

Qu'est-ce que HYDRA

HYDRA est un honeypot SSH où chaque commande inconnue est traitée par un LLM qui génère une réponse contextuelle et persistante en temps réel.

Contrairement aux honeypots traditionnels (Cowrie, Kippo) qui reposent sur des réponses pré-scriptées, HYDRA peut répondre à n'importe quelle commande tapée par un attaquant — y compris des commandes jamais vues auparavant.

Pourquoi les honeypots traditionnels échouent

Un attaquant expérimenté détecte Cowrie en moins de 30 secondes :

Technique de détection Ce qui trahit
uname -r Retourne une version de noyau codée en dur, souvent obsolète
/proc/1/cgroup Montre les traces de conteneur Docker
/bin/./uname (astuce Kinsing) Échoue ou retourne une sortie différente de /usr/bin/uname
Commandes arbitraires Retourne des erreurs ou une sortie vide au lieu de données réalistes
Analyse temporelle Réponses instantanées (pas de latence I/O)

Comment HYDRA résout cela

  • Génération LLM — llama-3.3-70b (via Groq) génère des réponses contextuelles pour toute commande inconnue. 65+ commandes built-in gèrent les utilitaires courants nativement (40 core + 25 réseau/processus/système) ; tout le reste va au LLM avec un cache LRU (200 entrées, TTL 5min).
  • Système de fichiers virtuel — Un VFS mutable avec isolation Copy-on-Write par session. Voir Système de fichiers virtuel.
  • Anti-empreinte — Bannière SSH, version noyau, cgroup, délai d'auth — tout soigneusement accordé. Voir Anti-empreinte.
  • Personas — Trois simulations de cibles à haute valeur en rotation. Voir Personas.
  • PromptGuard — Détection silencieuse des tentatives d'injection de prompt. Voir PromptGuard.
  • Boucle de retour — Leurres et prompts auto-améliorants basés sur le comportement des attaquants. Voir Boucle de retour.

Le pipeline de commandes

Chaque commande tapée par un attaquant passe par un pipeline en 9 étapes dans le CommandRouter :

graph TD
    A[Entrée brute] --> B[1. Sanitize]
    B --> C[2. Score PromptGuard]
    C --> D[3. Alias/expand]
    D --> E[4. Split commandes composées]
    E --> F[5. Détecter les pipes]
    F --> G[6. Classifier built-in vs LLM]
    G --> H[7. Exécuter]
    H --> I[8. Muter l'état VFS]
    I --> J[9. Log + tag MITRE]
  1. Sanitize — Normaliser l'Unicode, supprimer les séquences d'échappement ANSI, gérer les octets nuls
  2. PromptGuard — Scorer la commande pour la probabilité d'injection (0.0–1.0)
  3. Expand — Résoudre les alias, développer ~ et les variables d'environnement
  4. Split — Gérer les commandes composées ;, &&, ||
  5. Pipes — Détecter et chaîner les commandes pipées (cmd1 | cmd2 | cmd3)
  6. Classifier — Router vers le handler built-in ou le LLM
  7. Exécuter — Exécuter le built-in ou envoyer au LLM avec le contexte VFS complet
  8. Muter — Appliquer les effets de bord sur le système de fichiers (mkdir, touch, rm, apt install)
  9. Log — Écrire l'événement JSONL structuré avec les tags MITRE ATT&CK

Registre d'effets de bord

HYDRA suit 25+ installations de paquets de façon réaliste. Quand un attaquant exécute apt install nmap, le paquet est « installé » — les which nmap suivants retournent /usr/bin/nmap, et les commandes nmap produisent une sortie générée par le LLM. Les paquets supportés incluent nmap, netcat, gcc, vim, htop, tmux, strace, gdb, tcpdump, john, hydra, nikto, sqlmap, masscan, gobuster, ffuf, et plus.

Classification des sessions

Toutes les sessions ne produisent pas des données d'entraînement utiles. Le SessionClassifier filtre le trafic en temps réel :

Label Critères Entraînement ?
bot_ephemeral Session < 5 secondes Non
bot_exec_scanner Pas de PTY, commande exec unique (ex. uname) Non
bot_dropper Pattern wget\|curl pipé vers sh, chmod +x, nohup Non
bot_recon PTY mais < 3 commandes, toutes discovery, < 20s Non
likely_human PTY + > 20s + ≥ 1 commande non-discovery + signal humain Oui
unclassified Tout le reste À revoir

Seules les sessions signal (2,2 % du trafic total) sont transmises au pipeline PDX pour la génération de données d'entraînement.

Classification en direct

Le classifieur tourne à la fois en temps réel pendant la session (classify_live) et post-hoc à la fin de la session (classify_session). La classification en direct permet à HYDRA d'ajuster le niveau de détail des réponses — les sessions signal reçoivent des réponses LLM plus riches et détaillées pour maximiser l'engagement.

Cycle de vie d'une session

  1. L'attaquant se connecte au port 2222
  2. Handshake SSH avec anti-empreinte (bannière, délai d'auth)
  3. Authentification acceptée (tout credential — tout est logué)
  4. Persona sélectionné aléatoirement (fintech, crypto, ou corp_ad)
  5. Fork VFS créé (Copy-on-Write depuis le blueprint du persona)
  6. Chaque commande passe par le pipeline en 9 étapes
  7. Chaque commande reçoit un tag MITRE ATT&CK + un score PromptGuard
  8. Fin de session → classifié signal ou bruit → transmis à PDX
  9. La boucle de retour met à jour les leurres pour les sessions futures

Arrêt propre

HYDRA implémente un arrêt propre via les signaux SIGINT, SIGTERM et SIGHUP. Quand l'arrêt est déclenché :

  1. Priorité 50 (business) — Le serveur SSH arrête d'accepter de nouvelles connexions, les sessions actives peuvent se terminer
  2. Priorité 100 (support) — Le serveur de health check s'arrête
  3. Priorité 200 (logger) — Le logger flush et ferme tous les handles de fichiers (dernier à fermer, capture les erreurs des autres callbacks)