Honeypot : Comprendre les Hackers et leurs méthodes
La curiosité comme point de départ
Depuis que je travaille en administration systèmes et réseaux, j’entends régulièrement parler d’attaques automatisées, de scans massifs, de serveurs compromis en quelques minutes. On lit des articles, on voit des statistiques, on suit des formations. Mais il y a une différence entre savoir que ces choses existent et les observer vraiment, en conditions réelles, sur sa propre infrastructure.
C’est cette curiosité qui m’a poussé à monter un honeypot. Pas dans le cadre d’un projet scolaire, pas parce que quelqu’un me l’avait demandé. Simplement parce que je voulais voir. Voir ce qui se passe réellement quand un serveur Linux est exposé sur Internet sans protection. Voir combien de temps il faut avant que quelqu’un tente de s’y connecter. Voir ce que font les attaquants une fois qu’ils ont accès.
Configurer Cowrie : plus compliqué que prévu
Pour monter ce honeypot, j’ai utilisé Cowrie, un honeypot SSH open-source qui simule un environnement Linux vulnérable et enregistre tout ce que font les attaquants une fois connectés. Sur le papier, le projet semblait assez simple à mettre en place. Dans la pratique, la configuration de Cowrie s’est révélée nettement plus complexe que ce à quoi je m’attendais.
Entre la configuration du port d’écoute, la gestion des logs, le paramétrage du faux système de fichiers présenté aux attaquants, et la mise en place du VPS pour que tout soit correctement exposé sur Internet sans compromettre le reste de l’infrastructure, j’ai passé un temps considérable à lire la documentation, à tester, à corriger des erreurs de configuration, à recommencer.
Ce temps n’était pas perdu pour autant. Comprendre en profondeur comment fonctionne Cowrie m’a permis de mieux interpréter les données collectées par la suite. Quand on sait exactement ce que le honeypot enregistre et comment, on lit les logs différemment.
Les premières heures : une réalité brutale
Une fois le honeypot correctement configuré et le VPS exposé sur Internet, je n’ai pas eu à attendre longtemps. En quelques heures seulement, les premières tentatives de connexion ont commencé. Puis des dizaines. Puis des centaines.
Ce volume m’a immédiatement frappé, d’autant plus qu’il faut bien comprendre ce que représente ce serveur : il n’y avait strictement rien d’exposé sur Internet à part le port SSH. Pas de serveur web, pas de base de données, pas d’application. Juste un port 22 ouvert. Et pourtant, les tentatives de connexion étaient continues, automatisées, permanentes, provenant de dizaines de pays différents à toute heure du jour et de la nuit. Un simple port SSH suffit à attirer une quantité impressionnante d’attaquants automatisés. C’est une réalité que je connaissais théoriquement, mais que je n’avais jamais mesurée aussi concrètement.
Un ajustement stratégique : ouvrir les portes
Au début, Cowrie était configuré pour n’accepter qu’une liste restreinte de mots de passe bidons. La logique était simple : simuler un serveur mal sécurisé sans pour autant accepter n’importe quoi. Mais en analysant les logs, j’ai rapidement constaté qu’une grande partie des attaquants n’arrivaient pas à se connecter. Je ratais des comportements potentiellement intéressants à analyser.
J’ai donc pris la décision de modifier la configuration de Cowrie pour accepter toutes les tentatives de connexion, quels que soient les identifiants utilisés. Et tant qu’à rendre le piège plus permissif, autant le rendre aussi plus attrayant. J’ai personnalisé la machine présentée aux attaquants : quand ils se connectaient et cherchaient à vérifier les caractéristiques du système — processeur, mémoire, ressources disponibles — Cowrie leur affichait des composants particulièrement puissants. Un serveur avec beaucoup de CPU et de RAM, c’est exactement ce que cherche un attaquant qui veut installer un cryptominer. Plus la machine semble puissante, plus elle est alléchante.
Ce changement a immédiatement eu un impact sur la qualité des données collectées.
Analyser les données : construire ses propres outils
Au fil des semaines, le volume de données accumulé est devenu conséquent. Des milliers d’événements, des centaines de sessions, des dizaines de fichiers déposés. Lire des logs bruts ligne par ligne n’était plus une option réaliste pour avoir une vision claire de ce qui se passait.
J’ai donc développé un premier outil : un dashboard web en HTML et JavaScript, conçu spécifiquement pour visualiser les données collectées par Cowrie. Je l’ai vibe codé — en itérant rapidement, en ajoutant des visualisations au fur et à mesure de mes besoins. Le résultat m’a permis de transformer des milliers de lignes de logs bruts en données lisibles et exploitables : pays d’origine des attaquants, identifiants les plus utilisés, timeline des connexions, fichiers déposés.
Une fois les fichiers identifiés et leurs hash récupérés, il fallait savoir précisément à quoi je had affaire. Plutôt que d’aller vérifier chaque hash manuellement sur VirusTotal, j’ai développé un second outil utilisant l’API VirusTotal pour soumettre automatiquement les hash des fichiers collectés et récupérer les résultats d’analyse en masse. L’outil me retournait directement les détections de chaque éditeur de sécurité pour chaque fichier, sans avoir à faire une seule recherche manuelle.
J’ai également intégré une API de géolocalisation d’IP pour visualiser sur une carte l’origine géographique des attaquants. Voir en temps réel les connexions provenir de Chine, de Russie, des États-Unis ou du Brésil donne une dimension concrète à ce que les statistiques seules ne transmettent pas.
C’est grâce à ces trois outils que j’ai pu identifier et analyser l’attaque décrite ci-dessous.
La surprise : pas un fichier, mais plusieurs
En explorant les données via le dashboard, j’ai découvert qu’un attaquant avait réussi à se connecter et avait déposé plusieurs fichiers sur le serveur. Ce qui m’a surpris, ce n’était pas tant le fait qu’une connexion ait réussi — c’était précisément l’objectif du honeypot — mais la quantité de fichiers déposés.
Je m’attendais à observer un comportement simple : connexion, dépôt d’un exécutable, déconnexion. La réalité était plus complexe. L’attaquant avait déposé plusieurs fichiers, probablement pour s’assurer qu’au moins l’un d’entre eux fonctionnerait selon l’architecture et la configuration de la machine cible.
Ce qui m’a le plus marqué dans cette attaque, c’est sa discrétion. L’attaquant s’est connecté, a déposé ses fichiers, et s’est déconnecté en 1 minute 45 secondes, sans exécuter la moindre commande visible. Zéro trace dans les logs système. Cette sobriété n’est pas le fruit du hasard, c’est une technique délibérée pour minimiser les chances d’être détecté.
Ce que cachaient les fichiers
En soumettant les hash à mon outil VirusTotal, j’ai rapidement identifié le malware principal : un exécutable Linux baptisé sshd — exactement comme le processus du serveur SSH légitime. Ce choix de nom n’est pas anodin. Un administrateur qui jette un coup d’œil rapide à la liste des processus en cours ne verra rien d’anormal. Le processus se fond parfaitement dans le décor.
Derrière ce nom banal se cachait en réalité un cryptominer : un programme conçu pour exploiter les ressources CPU de la machine infectée afin de miner du Monero, une cryptomonnaie réputée difficile à tracer. Les gains partent directement dans le portefeuille de l’attaquant. La victime, elle, découvre progressivement que son serveur ralentit, surchauffe, et que sa facture électrique augmente — sans jamais comprendre pourquoi.
Il est probable que la personnalisation de la machine — les composants puissants affichés à l’attaquant — ait joué un rôle dans son comportement. Une machine avec de telles ressources représente une cible particulièrement rentable pour un cryptominer.
Détecté par 39 éditeurs de sécurité sur 65 sur VirusTotal, sous le nom Trojan:Linux/Multiverze, avec un score communautaire de -53. Une menace bien documentée, active depuis 2022, et toujours en circulation.
Ce que ce projet m’a appris
Cette expérience m’a confirmé quelque chose que j’entendais souvent mais que je n’avais jamais vraiment mesuré : la rapidité et l’automatisation des attaques sur Internet sont d’une efficacité redoutable. Un seul port ouvert, sans serveur web ni aucun autre service exposé, suffit à attirer des centaines de tentatives d’intrusion quotidiennes. Un serveur avec des identifiants faibles sera compromis. Ce n’est pas une éventualité, c’est une certitude.
Elle m’a aussi appris à lire une attaque différemment. Derrière chaque décision de l’attaquant — le choix du nom du fichier, l’absence de commandes exécutées, le dépôt de plusieurs variantes — il y a une logique, une réflexion, une expérience accumulée. Comprendre cette logique, c’est comprendre comment mieux se défendre.
Enfin, ce projet m’a donné une vision beaucoup plus concrète de ce que signifie sécuriser un accès SSH. Ce n’est pas une recommandation abstraite parmi d’autres dans une liste de bonnes pratiques. C’est la ligne de défense qui sépare un serveur sain d’un serveur transformé en mine de cryptomonnaie à l’insu de son propriétaire.
Le rapport technique complet
Cet article décrit la démarche et les observations du projet. Pour les détails techniques complets — hash SHA-256, analyse VirusTotal, cartographie MITRE ATT&CK, chaîne d’infection détaillée et cartographie des diverses attaques :