Threat Intelligence Platform (honeypot personnel)

Contexte

J'ai monté cette plateforme seul pour apprendre l'analyse de malware sur du concret. Des honeypots exposés sur Internet capturent des charges dans la nature, un pipeline les décortique automatiquement et un dashboard web me sert à suivre ce qui rentre. Le projet tourne depuis le 14 août 2026.

Infrastructure

Le socle est un T-Pot (Ubuntu 24.04, Docker) qui expose 33 services leurres. Sept d'entre eux servent vraiment à collecter : Dionaea, Cowrie, Adbhoney, Honeytrap, H0neytr4p, Log4Pot et Glutton.

L'administration (Kibana, Elasticsearch) n'est accessible qu'à travers un tunnel WireGuard. Devant le dashboard, un nginx avec ModSecurity et l'OWASP CRS fait office de pare-feu applicatif. Le SSH est durci et un service caché Tor reste disponible en accès de secours.

Pipeline CTI

L'orchestration est en Bash (sept scripts en production, lancés par cron) et les traitements en Python. À chaque nouveau fichier déposé sur un honeypot :

le fichier est repéré et mis en file d'analyse ;
il passe par cinq sources croisées (VirusTotal, analyse statique, YARA, reverse engineering, sandbox), ce qui donne un score de confiance ;
Ghidra tourne en mode headless avec des scripts Jython pour décompiler et repérer le packing ;
une sandbox l'exécute après avoir détecté seule l'environnement cible, Linux ou Windows ;
les logs Elasticsearch sont recoupés pour la partie réseau ;
dès qu'une IP revient trop souvent, une investigation OSINT part automatiquement avec SpiderFoot.

Dashboard

Backend en Node.js et Express, frontend en JavaScript sans framework avec Chart.js, déploiement sous PM2 et systemd. On y trouve une vue temps réel (stats, graphiques, campagnes repérées automatiquement), une recherche qui couvre à la fois les rapports, les événements réseau et l'OSINT, un export par rapport ou complet et une interface responsive avec thème clair et sombre.

Résilience

Le pipeline pose des verrous pour éviter que deux analyses se marchent dessus, respecte le quota des API et rejoue tout seul les échecs. Les données du honeypot sont sauvegardées indépendamment de leur rotation. Le service web se surveille et se répare seul, avec trois niveaux d'escalade, et survit aux redémarrages grâce à systemd.

Ce que j'ai trouvé

WannaCry, neuf ans après. Plus de 40 % des échantillons capturés sont de la famille WannaCry. Le ver se propage encore tout seul : un même hachage a été redéposé par des IP différentes à plusieurs jours d'écart.

Un webshell remonté jusqu'à son auteur. Un webshell PHP planqué dans une archive ZIP maquillée en polices web, que j'ai rattaché aux outils publics du chercheur « Nxploited » (Khaled Alenazi), auteur d'une dizaine d'exploits WordPress documentés. Un bon exemple de code de recherche récupéré pour de vraies attaques.

Une infrastructure de commande partagée. Un webhook Discord servait de canal commun à un mineur de cryptomonnaie et à un bot DDoS de la même famille (Multiverze). Deux charges, une seule infrastructure.

Un malware zombie. Un mineur Android (ADBMiner) déployait une charge CoinHive, alors que ce service a fermé en 2019. La campagne continue de tourner mécaniquement, des années après la disparition de sa brique finale.

Une campagne suivie dans la durée. Une même IP source a déposé du malware pendant plus de huit jours d'affilée. À chaque fois, l'enrichissement OSINT s'est lancé seul (géolocalisation, hébergeur, réputation), ce qui donne une méthode de threat hunting reproductible.

Bilan

De la collecte à la diffusion des IOC, ce projet touche à l'analyse de malware statique et dynamique, au reverse engineering sous Ghidra, au développement d'outils en Bash, Python et Node.js, à l'administration Linux et Docker, à la sécurisation d'une infra (VPN, pare-feu applicatif, durcissement SSH) et à la conception d'une API avec son interface.