Analyse d'un honeypot SSH — 4 jours d'exposition

1. Setup

Un VPS Linux exposé sur Internet avec Cowrie, honeypot SSH qui simule un serveur accessible sur le port 22. Les logs sont collectés, parsés et enrichis (GeoIP) par une stack ELK déployée via Docker. Période d'observation : du 19 au 23 mars 2026, soit 4 jours d'exposition complète.

2. Vue d'ensemble

63 061 événements collectés sur la période, dont 10 143 tentatives d'authentification et 1 910 connexions réussies. 480 téléchargements ont été enregistrés après authentification.

Le 20 mars concentre 18 511 hits, soit près de 29% du trafic total en une seule journée. Ce spike reste inexpliqué avec les données disponibles — pas d'IP dominante identifiable, plutôt un groupe d'adresses ponctuellement actives ce jour-là. Une fenêtre de 4 jours est insuffisante pour distinguer un événement coordonné du bruit de fond normal.

Géographie des sources

Précision importante : une IP américaine ne signifie pas un attaquant américain. Les fournisseurs cloud américains hébergent une part massive de l'internet mondial et leurs plages IP servent régulièrement de relais. La précision du GeoIP sur des IPs de datacenter reste imparfaite — ces chiffres sont indicatifs, pas attributifs.

3. Profil des attaquants

Outils utilisés

Cowrie capture le SSH client version string à chaque connexion — information bien plus précise qu'une analyse comportementale.

Ces deux familles représentent 96,8% des connexions. Deux outils distincts, ou un même outil qui alterne ses signatures — impossible à trancher avec ces seules données. En faible volume : une signature Mirai, ZGrab (outil de cartographie de Censys — confirmant que le honeypot est indexé publiquement), et 64 connexions envoyant une requête HTTP sur le port 22, signal d'un scanner de masse qui sonde tous les ports sans vérifier le protocole.

Ce que les attaquants ont réellement fait

Sur 1 910 connexions réussies, zéro commande exécutée. Les attaquants se connectent et raccrochent immédiatement. Ce comportement indique des credential harvesters : ils testent si un mot de passe fonctionne, l'enregistrent si oui, et passent à la cible suivante. Ils ne cherchent pas à compromettre ce serveur — ils construisent des listes de credentials valides pour un usage ultérieur.

Les 480 téléchargements représentent une couche supplémentaire : une fraction des connexions réussies a déclenché des téléchargements automatisés. Cowrie n'a pas capturé les noms ou hashes de fichiers dans ces logs — impossible de confirmer la nature exacte des payloads.

Les credentials : la découverte inattendue

root domine sans surprise (1 959 occurrences). Mais le reste du top 10 est révélateur :

sol, solana, solv, validator, node — ce sont des noms d'utilisateurs typiques des configurations de nœuds Solana. Ce n'est pas du brute-force générique.

Les paires confirment le pattern : solana > solana, sol > sol, validator > validator, node > node. Ces listes de credentials correspondent à des configurations par défaut de nœuds blockchain — des serveurs qui font tourner des validateurs ou des RPC nodes, souvent configurés rapidement sans durcissement.

Une nuance : je n'ai pas vérifié si ces couples username+password proviennent de fuites connues ou de configurations par défaut documentées. Les conclusions sur l'origine exacte de ces listes restent des hypothèses.

4. Deux profils d'attaquants

En croisant les listes d'IPs qui échouent et d'IPs qui réussissent, deux comportements distincts émergent :

Le scanner pur — L'IP 92.118.39.87 (719 tentatives échouées, active tous les jours avec un pattern régulier de 3-4 minutes entre tentatives) n'apparaît jamais dans les connexions réussies. Elle teste des credentials, aucun ne passe. Totalement automatisé, méthodique.

Les harvesters ciblés — Deux IPs n'apparaissent que dans les succès, jamais dans les échecs. Elles ne ratent pas. Elles semblent utiliser des listes pré-filtrées, plus précises — cohérent avec l'hypothèse de credentials blockchain déjà validés ailleurs.

5. Limites

Ce que Cowrie ne voit pas. Aucune donnée sur les vulnérabilités applicatives, aucune visibilité sur les autres protocoles (HTTP, RDP, DNS). Cowrie simule SSH uniquement.

Le biais de sélection. Cowrie est connu dans la communauté. Certains outils avancés détectent les honeypots via fingerprinting SSH. Ce qui a été capturé représente peut-être sélectivement les outils les moins sophistiqués.

L'absence de baseline. 63 061 événements en 4 jours — sans comparaison avec d'autres honeypots publics (DShield, T-Pot), ce volume flotte dans le vide.

4 jours, c'est court. Insuffisant pour détecter des campagnes furtives sur plusieurs semaines ou observer des tendances saisonnières.

Sur "aucun humain dans la boucle". L'absence de commandes exécutées prouve que personne n'a eu de session interactive. Ça ne prouve pas l'absence d'humain derrière les outils — un opérateur qui orchestre des scans automatisés et consulte les résultats ne laisse aucune trace dans ces logs.

6. Conclusion

Sur 4 jours, ce honeypot a capturé quelque chose de plus précis qu'un simple bruit de fond : une campagne de credential harvesting distribuée, avec une composante inattendue ciblant spécifiquement des configurations de nœuds blockchain.

1 910 connexions réussies, zéro commande exécutée, 480 téléchargements automatisés. Les attaquants n'essayaient pas d'entrer — ils testaient des clés pour en garder les copies qui fonctionnent, avec un intérêt particulier pour l'infrastructure Solana.

Ce que ça dit du paysage des menaces automatisées : l'exposition d'un serveur SSH est quasi-immédiate, les outils sont distribués sur des centaines d'IPs, et les listes de credentials sont de plus en plus spécialisées par type de cible.