Uphill Security a fait son entrée sur Hacker News, mais ses données d’identifiants SSH exigent une lecture attentive

Uphill Security a présenté 1,53 million de tentatives de connexion SSH aux lecteurs de Hacker News, mettant en lumière à la fois une automatisation acharnée et un important désaccord d’interprétation. Son réseau mondial de honeypots a enregistré 131 922 paires nom d’utilisateur-mot de passe distinctes en juillet 2026. Ces observations ne permettent toutefois pas d’établir que les mots de passe provenaient de comptes réels.

Cette distinction sépare une télémétrie de menace utile d’une base de données d’identifiants volés. Le projet montre ce que les scanners automatisés tentent lorsqu’ils rencontrent un service SSH ouvert. Il ne révèle pas quelles combinaisons fonctionnent ailleurs, qui les a constituées, ni si les attaquants les ont copiées à partir de violations antérieures.

Le débat qui en résulte est important, car les défenseurs interprètent souvent mal les journaux d’authentification échouée. Certains considèrent ce trafic comme un bruit de fond inoffensif. D’autres voient dans chaque mot de passe tenté la preuve d’une campagne de compromission active. La réalité se situe entre ces deux positions et exige d’examiner de plus près la méthode de collecte.

Le réseau de honeypots a enregistré 1,53 million de tentatives de connexion

Le projet a capturé un vaste échantillon d’attaques automatisées par identifiants SSH, et non une collection vérifiée de mots de passe fonctionnels.

Uphill Security a publié ses premières conclusions le 2 août, couvrant le premier mois complet d’exploitation du réseau. Les résultats du honeypot portent sur juillet 2026 et quinze serveurs dédiés.

Ces serveurs utilisaient quinze adresses IPv4 publiques réparties chez cinq fournisseurs de serveurs privés virtuels. La plupart se trouvaient en Europe, bien que l’infrastructure couvre plusieurs régions du monde. Chaque adresse exposait un honeypot SSH à faible interaction sur le port TCP 22.

Un honeypot à faible interaction imite suffisamment un service pour attirer et enregistrer les attaquants, sans leur fournir un environnement d’exploitation complet. Dans ce cas, il acceptait les tentatives d’authentification et consignait les noms d’utilisateur et mots de passe soumis. Il ne permettait pas aux intrus d’opérer dans un shell réaliste.

Le réseau a observé 1 531 053 tentatives de connexion provenant de 6 790 adresses IP uniques. Ces tentatives comprenaient 12 238 noms d’utilisateur uniques, 97 621 mots de passe uniques et 131 922 paires nom d’utilisateur-mot de passe distinctes.

La paire la plus fréquente associait root à 123456, tentée 3 861 fois. Parmi les autres principales combinaisons figuraient root avec root, password, 12345678, admin et plusieurs courtes séquences numériques.

Les attaquants ont essayé le nom d’utilisateur root 648 133 fois. Cela représentait plus de 42 % de toutes les tentatives d’authentification du jeu de données. Les noms d’utilisateur suivants les plus fréquents étaient admin, ubuntu, user et test.

Le mot de passe 123456 est apparu 73 592 fois. Parmi les autres choix fréquents figuraient 123, 1234, password, 12345678 et 12345. Ces valeurs ressemblent à des dictionnaires de mots de passe faibles bien établis et à des valeurs par défaut prévisibles d’appareils.

Les résultats montrent à quel point certains scanners ont besoin de peu de reconnaissance. Un serveur exposant SSH sur son port standard reçoit immédiatement des tentatives visant des identités administratives génériques. Un opérateur n’a pas besoin d’annoncer le système ni de le placer dans un annuaire public.

Cependant, l’expérience n’a compté que les tentatives d’authentification. Elle excluait les analyses réseau et les attaques contre d’autres protocoles. Elle n’a pas non plus suivi les intrus ayant réussi à se connecter, car le honeypot était conçu pour collecter les soumissions de connexion plutôt que les comportements post-authentification.

Cette limite est cruciale. Le jeu de données décrit ce que les scanners ont proposé à quinze serveurs leurres. Il ne peut pas révéler directement combien de systèmes de production ont accepté les mêmes combinaisons.

Pourquoi le débat sur Hacker News s’est concentré sur la « collecte »

Le désaccord ne porte pas sur la réalité des mesures ; il concerne ce que représentent réellement les identifiants soumis.

Plusieurs commentateurs de Hacker News ont contesté l’emploi du terme « collecte » dans l’article. Leur préoccupation était que les robots automatisés fournissaient les identifiants plutôt que de les perdre au profit du honeypot. Le réseau a recueilli des données saisies par les attaquants, et non des secrets extraits de systèmes contrôlés par ceux-ci.

Un fil de discussion avançait que la plupart des combinaisons étaient intéressantes d’un point de vue statistique, mais sans valeur opérationnelle. Un scanner aléatoire essayant root:123456 ne prouve pas qu’un serveur non lié utilise cette paire.

Cette critique est fondée. Un identifiant associe normalement une identité déclarée à un moyen d’authentification qui donne accès à un système précis. Sans l’hôte ou le service correspondant, une paire nom d’utilisateur-mot de passe ne dispose pas du contexte nécessaire pour être vérifiée.

Même les combinaisons inhabituelles exigent de la prudence. Un robot peut les générer à partir d’un dictionnaire, modifier des valeurs par défaut connues, combiner des mots divulgués ou réutiliser des listes collectées lors de campagnes antérieures. Le honeypot ne peut pas distinguer ces origines à partir de ses seuls enregistrements d’authentification.

Le mot « collecte » peut donc suggérer davantage que ce que l’expérience a établi. Les lecteurs pourraient en déduire que le jeu de données contient des mots de passe volés à des systèmes actifs. La méthode publiée ne permet pas de soutenir cette conclusion.

Qualifier pour autant les données d’inutiles va trop loin. Les soumissions répétées révèlent les hypothèses intégrées à l’infrastructure d’attaque automatisée. Elles montrent quels comptes les attaquants s’attendent à trouver, quelles valeurs par défaut restent attrayantes et avec quelle agressivité certaines sources opèrent.

Le projet met également en évidence le ciblage des comptes de service. Aux côtés de root et admin, les scanners ont essayé postgres, oracle, git, ftpuser, deploy et deployer. Ces noms correspondent à des rôles logiciels et à des pratiques de déploiement courants.

Certaines entrées semblent influencées par les tendances technologiques actuelles. Le nom d’utilisateur claude a fait l’objet de 5 993 tentatives, tandis que solana en a reçu 8 223. Ces libellés ne prouvent pas le ciblage d’une campagne, mais ils montrent comment les dictionnaires d’attaque intègrent des termes logiciels et produits reconnaissables.

Une interprétation utile consiste à considérer chaque paire soumise comme une hypothèse d’attaquant. Le scanner prédit qu’un hôte pourrait exposer un compte désigné avec un mot de passe faible ou défini par défaut. La répétition indique une confiance, une commodité ou une réutilisation répandue dans les outils de scan.

Cela rend ces enregistrements précieux pour les tests défensifs. Les administrateurs peuvent comparer les noms d’utilisateur observés avec les comptes locaux, confirmer que l’authentification par mot de passe est désactivée et rechercher dans les journaux des schémas de tentatives concentrées.

Ces enregistrements restent de mauvaises preuves pour attribuer des attaques. Une adresse IP observée peut appartenir à un serveur compromis, un proxy, une machine virtuelle louée ou une infrastructure contrôlée via un autre intermédiaire. La géographie indique l’enregistrement réseau ou une localisation estimée, et non la personne responsable.

En définitive, le débat améliore la valeur du projet. Il oblige les lecteurs à distinguer la télémétrie brute d’affirmations de sécurité plus fortes. Cette rigueur importe chaque fois qu’un jeu de données marquant atteint un large public technologique.

La géographie montre l’infrastructure, pas l’identité des attaquants

La répartition des sources indique d’où le trafic a émergé, mais elle ne peut pas identifier de manière fiable où les opérateurs vivaient ou travaillaient.

Le réseau de honeypots a enregistré des sources de connexion dans 129 pays et 1 334 systèmes autonomes. Un système autonome est un ensemble de routes Internet gérées par un même opérateur réseau.

L’Asie a fourni 4 084 adresses sources uniques, soit 60,1 % du total. L’Europe en a fourni 1 294, tandis que l’Amérique du Nord en a fourni 832. Les adresses restantes étaient associées à l’Amérique du Sud, à l’Afrique et à l’Océanie.

Le volume de trafic dressait un tableau différent. Les adresses européennes ont généré 921 439 tentatives, soit 60,2 % de toutes les connexions. Les sources asiatiques ont généré 453 254 tentatives, bien qu’elles représentent un nombre d’adresses uniques beaucoup plus élevé.

Ce contraste reflète une concentration. Les sources européennes ont enregistré en moyenne 712,1 tentatives par adresse observée. Les sources nord-américaines en ont enregistré 117,1, contre 111 pour les sources asiatiques.

À l’échelle des pays, la Chine a produit le plus grand nombre d’adresses uniques, avec 1 653. Les États-Unis suivaient avec 721, tandis que l’Inde en produisait 458 et le Vietnam 338.

Les Pays-Bas arrivaient en tête par nombre total de tentatives, avec 686 449 soumissions issues de 276 adresses observées. Cela représentait 44,8 % de l’ensemble du jeu de données. La Chine a produit 112 793 tentatives et les États-Unis 72 314.

Cela ne signifie pas que des résidents néerlandais ont mené près de la moitié de l’activité. Les centres d’hébergement, les relais, les serveurs infectés et les infrastructures louées peuvent concentrer le trafic dans certaines régions du réseau. Un seul cluster d’automatisation peut également générer bien plus de tentatives que des milliers de sources moins actives.

Les résultats par système autonome renforcent cette leçon. Le réseau de Microsoft contenait le plus grand nombre d’adresses observées uniques, soit 303. Toutefois, un autre réseau, TechTies, a produit 448 559 tentatives à partir de 110 adresses.

Des fournisseurs de cloud et d’hébergement apparaissent dans toute la liste des sources. DigitalOcean, Oracle, OVH, Alibaba, Tencent, Google et plusieurs réseaux de télécommunications ont tous enregistré du trafic. Leur présence n’implique pas la participation de ces entreprises.

Les attaquants privilégient les infrastructures hébergées parce qu’elles offrent une bande passante stable et un provisionnement rapide. Ils compromettent aussi des serveurs légitimes et utilisent ces machines comme nœuds de scan. Ces deux pratiques affaiblissent toute attribution simpliste au niveau des pays.

Les données comportent également un effet d’échantillonnage. Soixante pour cent des honeypots se trouvaient en Europe. La localisation des serveurs peut affecter le routage, la latence, la visibilité pour les scanners et les campagnes qui rencontrent une adresse durant une fenêtre d’observation limitée.

Quinze adresses fournissent des observations significatives, mais pas un recensement représentatif des abus SSH mondiaux. La réputation d’une adresse peut aussi jouer un rôle. Une adresse IP nouvellement attribuée peut attirer un trafic différent de celui d’une adresse auparavant associée à un autre service.

L’expansion future du projet devrait rendre les comparaisons géographiques plus instructives. Davantage d’adresses, une répartition régionale équilibrée et des mesures mensuelles répétées aideraient à distinguer les tendances durables des pics de campagne de courte durée.

La publication de résultats par capteur ajouterait une dimension supplémentaire. Si un honeypot recevait l’essentiel du trafic néerlandais, les chercheurs pourraient examiner si un scanner ciblait une plage d’adresses étroite. Si chaque capteur observait un comportement similaire, la campagne scannerait probablement plus largement.

Pour les défenseurs, la leçon opérationnelle est plus simple que la carte. Bloquer des pays entiers sur la base de cet échantillon créerait un faux sentiment de sécurité. Les limites de débit, l’authentification par clé, les restrictions de comptes et la surveillance traitent plus directement la méthode d’attaque.

Ce que deviennent les attaques par identifiants SSH après une connexion réussie

Les tentatives échouées ne sont que du trafic de fond jusqu’à ce que l’une d’elles réussisse, après quoi la même automatisation peut transformer un serveur en infrastructure d’attaque.

Le honeypot n’a pas observé les commandes post-connexion ; il ne peut donc pas indiquer ce que ses scanners avaient l’intention de faire ensuite. Des recherches indépendantes sur les incidents fournissent le contexte manquant.

MITRE classe la devinette de mots de passe comme une technique d’accès aux identifiants et identifie SSH sur le port TCP 22 comme une cible courante. Son entrée sur la devinette de mots de passe décrit également les échecs répétés suivis d’une éventuelle réussite comme un schéma de détection important.

Un mot de passe réussi ne se contente pas d’exposer un terminal interactif. Le compte peut donner accès au code source, aux fichiers d’environnement, aux clés privées, aux jetons cloud, aux identifiants de base de données ou aux systèmes de déploiement.

Les privilèges déterminent les dommages immédiats. Une connexion root donne à un attaquant un contrôle étendu. Un compte de service restreint peut néanmoins exposer des données précieuses ou permettre des déplacements latéraux via des permissions de fichiers faibles et des identifiants hérités.

Les attaquants peuvent également modifier les paramètres d’autorisation SSH afin d’assurer leur persistance. MITRE documente l’ajout de clés contrôlées par un adversaire dans authorized_keys, y compris via des interfaces de gestion cloud. Une clé implantée permet à un intrus de revenir après la modification du mot de passe d’origine.

Microsoft a documenté des malwares qui commencent par du brute force SSH automatisé. Son analyse des menaces Linux décrit une connexion réussie suivie d’un script malveillant et d’un bot contrôlé via IRC.

Ce botnet prenait en charge des activités de déni de service distribué et l’exécution de commandes arbitraires. D’autres compromissions Linux utilisent les systèmes capturés pour le minage de cryptomonnaies, l’envoi de spam, le scan ou le trafic proxy.

Une enquête distincte sur une attaque Linux a retracé une compromission réussie par brute force SSH à travers des téléchargements de scripts par étapes. Le serveur affecté est ensuite devenu un point de lancement pour une activité malveillante plus étendue.

Ces cas expliquent pourquoi les échecs répétés méritent de l’attention. Un scanner peut essayer des milliers de combinaisons faibles à faible coût. Il lui suffit d’un seul compte exposé pour rentabiliser cet effort.

Ils montrent également pourquoi le jeu de données Uphill Security ne doit pas être considéré comme une fuite de mots de passe. Le signal important réside dans le flux de travail automatisé autour de ces tentatives. Les attaquants recherchent continuellement des systèmes où des identifiants courants fonctionnent encore.

Les résultats concernant root révèlent le décalage le plus évident entre risque et commodité. Les administrateurs de production conservent parfois un accès root pour les opérations d’urgence. Les bots supposent qu’une partie de ces systèmes autorisera également l’authentification par mot de passe.

Les comptes de service créent un problème plus subtil. Les équipes peuvent créer des utilisateurs git, deploy ou de base de données pour l’automatisation, puis négliger les permissions de connexion interactive. D’anciens scripts de déploiement peuvent conserver des mots de passe longtemps après l’évolution du flux de travail initial.

Désactiver un shell interactif aide, mais les administrateurs doivent examiner la configuration SSH complète. La redirection de ports, l’exécution de commandes, le transfert de fichiers et le comportement des commandes forcées peuvent chacun créer des voies d’accès différentes après l’authentification.

Les autorisations cloud élargissent le rayon d’impact potentiel. Une machine virtuelle compromise peut accéder aux métadonnées d’instance, aux identités attachées, aux services internes ou aux secrets de déploiement. Le compte local peut devenir un point d’entrée vers un environnement plus vaste.

C’est là que les données de honeypots SSH deviennent utiles sur le plan opérationnel. Elles indiquent aux équipes quels noms d’utilisateur reçoivent une attention régulière et à quel point l’obscurité protège peu un service public. Elles fournissent aussi des entrées réalistes pour valider les alertes et les contrôles de débit.

La bonne question n’est pas de savoir si chaque combinaison tentée fonctionne. Elle est de savoir si un compte de production reste capable d’en accepter une.

Les données appuient le renforcement, mais pas les conclusions universelles

L’expérience renforce l’argument en faveur de la suppression de l’exposition fondée sur les mots de passe, tout en laissant plusieurs questions de recherche sans réponse.

La réponse défensive la plus claire consiste à exiger une authentification par clé publique pour les accès SSH administratifs. Une clé privée offre bien davantage de résistance aux tentatives en ligne qu’un mot de passe choisi par un humain.

La CISA conseille aux administrateurs d’exiger l’authentification par clé publique lorsque c’est possible, de désactiver l’authentification par mot de passe et de limiter les tentatives répétées. Ses recommandations de durcissement SSH préconisent également de séparer les services de gestion du trafic internet ordinaire.

Déplacer SSH vers un autre port peut réduire les scans bruyants, mais ne remplace pas les contrôles d’authentification. Les scanners à grande échelle peuvent découvrir des services sur des ports non standard. Un changement de port réduit surtout le trafic peu sophistiqué et le volume de journaux.

Désactiver la connexion root directe supprime de l’accès fondé sur les mots de passe l’identité la plus ciblée. Les administrateurs devraient plutôt utiliser des comptes nominatifs, des privilèges limités et une élévation contrôlée.

Les comptes de service inutilisés méritent également un examen. Un compte git ou deploy ne devrait exposer que les capacités requises par son flux de travail. La configuration devrait refuser les shells, les redirections, les sous-systèmes et les commandes dont le service n’a pas besoin.

La limitation du débit ajoute une couche supplémentaire. Le NIST décrit le throttling comme une défense principale contre les tentatives de mots de passe en ligne. Ses recommandations sur les mots de passe privilégient également les listes de blocage et les identifiants générés par machine plutôt que des règles de composition arbitraires.

Les journaux doivent relier les échecs à une réussite ultérieure. Dix mille mots de passe rejetés depuis une adresse peuvent être bruyants mais contenus. Une connexion réussie après des échecs répétés exige une enquête immédiate.

Les équipes devraient aussi surveiller ce qui suit l’authentification. De nouveaux processus, des scans sortants, une bande passante inattendue, des clés modifiées, des tâches planifiées, des répertoires cachés et des connexions à des pools de minage peuvent révéler une compromission.

L’isolation réseau réduit les conséquences d’une alerte manquée. Les charges de travail publiques ne devraient pas recevoir un accès non restreint aux systèmes de gestion, aux bases de données sensibles ou aux magasins d’identifiants. Le principe du moindre privilège reste important après l’échec de l’authentification.

Cependant, le projet Uphill Security présente encore des limites importantes. Quinze adresses IP observées pendant un mois ne peuvent décrire chaque région, fournisseur ou saison. Les campagnes commencent et s’arrêtent, tandis que les scanners adaptent leurs dictionnaires.

Le honeypot a enregistré les valeurs soumises mais ne les a pas validées auprès de services externes. Une telle validation serait éthiquement dangereuse et potentiellement illégale. Les chercheurs ne devraient pas tester les combinaisons collectées contre des systèmes sans lien avec l’étude.

Le projet a également publié des chaînes d’identifiants réversibles. Bien que les valeurs proviennent d’attaquants, certaines peuvent correspondre à de vrais mots de passe par coïncidence ou réutilisation. Le hachage des futures publications permettrait une analyse des fréquences avec moins d’exposition inutile.

L’auteur mentionne déjà le hachage des mots de passe parmi les améliorations prévues. Le recoupement avec des listes de mots de passe connues pourrait aussi distinguer les entrées courantes de dictionnaire des valeurs inhabituelles. Ce processus devrait utiliser des données de référence obtenues légalement et de manière responsable.

Des données temporelles plus détaillées révéleraient la structure des campagnes. Les chercheurs pourraient regrouper les rafales par réseau source, ordre des identifiants, comportement de connexion et couverture des capteurs. Des séquences similaires pourraient révéler des logiciels de scan partagés sans nécessiter d’attribution des attaquants.

Un environnement à interaction plus élevée pourrait montrer ce qui se passe après l’authentification, mais il comporte davantage de risques. Un tel honeypot doit contenir les intrus, limiter les abus sortants et empêcher le leurre de nuire à d’autres systèmes.

Cela crée le compromis central du projet. Un honeypot simple capture en toute sécurité une télémétrie d’authentification étendue, mais manque de profondeur comportementale. Un système réaliste fournit des éléments plus riches tout en augmentant les exigences de confinement, juridiques et opérationnelles.

Les résultats actuels appuient un durcissement concret, car les attaquants essaient de façon répétée des comptes prévisibles. Ils ne permettent pas d’affirmer quoi que ce soit sur les taux mondiaux de compromission, la nationalité des attaquants ou la validité réelle de 131,922 paires d’identifiants.

Ce qu’il faut surveiller après l’attention de Hacker News

La phase suivante devrait tester si ces schémas persistent, si les campagnes se regroupent entre capteurs et ce que les bots ayant réussi tentent après l’authentification.

Le premier signal est la cohérence mensuelle. Une autre période de collecte peut montrer si root, admin et les mots de passe numériques courts restent dominants. Des classements stables conforteraient la conclusion selon laquelle des dictionnaires standard alimentent une grande partie de l’activité.

De grands changements de classement indiqueraient un renouvellement des campagnes. Une hausse soudaine d’un nom d’utilisateur spécifique à un produit pourrait refléter un nouveau ciblage, un modèle de configuration divulgué ou un scanner parcourant de façon répétée le réseau.

Le deuxième signal est la distribution au niveau des capteurs. Des statistiques par adresse et par région révéleraient si un trafic important atteint l’ensemble du réseau ou se concentre sur un sous-réseau. Cette distinction améliorerait l’interprétation du pic observé aux Pays-Bas.

Un déploiement géographique équilibré renforcerait les comparaisons. La concentration européenne actuelle rend les totaux bruts par continent difficiles à généraliser. Davantage de fournisseurs pourraient également réduire l’influence de l’historique d’adresses d’une seule société d’hébergement.

Le troisième signal est le comportement post-authentification contrôlé. Un environnement soigneusement isolé pourrait accepter certaines combinaisons leurres et enregistrer les premières commandes émises par les attaquants. Cela relierait les tentatives d’identifiants à des objectifs mesurables.

Le confinement doit passer en premier. L’environnement devrait bloquer les scans sortants, le spam, le trafic de déni de service et l’accès à de vrais secrets. Les chercheurs auraient aussi besoin de politiques claires de conservation, de confidentialité et de divulgation.

Les futures publications devraient distinguer, lorsque possible, les tentatives générées des listes réutilisées. L’analyse des séquences peut aider, car les scanners soumettent souvent les identifiants dans des ordres cohérents. Faire correspondre ces séquences entre adresses IP peut identifier des outils partagés.

Publier des hachages plutôt que des mots de passe réversibles améliorerait également la conception de la recherche. Les lecteurs pourraient comparer des valeurs faibles connues au moyen de procédures documentées sans recevoir une liste en clair des soumissions des attaquants.

La réponse sur Hacker News a déjà apporté une correction utile : les grands nombres exigent des libellés précis. « Paires d’identifiants soumises » décrit correctement les éléments observés. « Identifiants récoltés » risque d’impliquer une validité que l’expérience n’a jamais testée.

Pour les opérateurs, la prochaine action ne dépend pas des recherches futures. Inventoriez chaque service SSH exposé à internet, vérifiez que l’authentification par mot de passe est désactivée et examinez si les comptes de service autorisent davantage d’accès que prévu.

Les équipes devraient conserver ces décisions avec les notes d’incident, les configurations et les preuves d’authentification. Une base de connaissances d’ingénierie consultable peut aider à maintenir le contexte opérationnel connecté entre les documents locaux.

Posez ensuite une question directe : si un scanner automatisé tente root:123456 ce soir, votre serveur se contentera-t-il d’enregistrer la tentative, ou deviendra-t-il l’infrastructure de quelqu’un d’autre ?