Un honeypot, ou pot de miel, est une ressource informatique volontairement exposée et dépourvue de tout usage légitime, mise en place pour attirer un attaquant et observer ses gestes. Un partage de fichiers nommé « salaires-2025 » déposé sur un serveur interne en donne une illustration immédiate : aucun collaborateur, aucune application n’a de raison d’y accéder, et sa seule fonction est de déclencher une alerte à la première ouverture. Toute consultation trahit donc, selon toute vraisemblance, un intrus en train d’explorer le réseau.
La définition retenue par le glossaire du NIST repose sur ces deux traits : une ressource conçue pour paraître attractive aux yeux d’un intrus, et qui n’a pas d’utilisateur autorisé en dehors de ses administrateurs.
Du faux serveur au jeton-leurre
Le même mot recouvre des dispositifs d’ambition très inégale.
- le faux serveur : un service SSH, web ou base de données exposé sans rôle métier, qui enregistre les tentatives de connexion et les commandes saisies ;
- le faux compte, entrée d’annuaire ou boîte de messagerie qui n’appartient à personne et dont chaque tentative d’authentification est signalée ;
- le faux fichier, document au nom soigneusement choisi dont l’ouverture ou la copie déclenche une alerte ;
- le jeton-leurre (honeytoken) : une fausse clé d’API glissée dans un dépôt de code ou une fausse fiche client insérée en base, dont l’usage trahit celui qui les a récupérées.
Les honeypots dits à faible interaction se contentent de simuler la façade d’un service. Ceux à forte interaction offrent un vrai système à compromettre : l’observation y est plus riche, mais le confinement demande davantage de précautions.
Un signal à très faible bruit
L’intérêt en détection tient à la construction même du dispositif. Puisque le leurre n’a aucun usage légitime, toute interaction est suspecte par définition. Un SIEM doit corréler des volumes considérables de journaux pour isoler une anomalie, et le réglage des outils EDR et XDR demande un travail continu de réduction des faux positifs ; l’alerte issue d’un honeypot, elle, n’exige ni ligne de base ni apprentissage préalable. Pour les analystes d’un SOC, ce signal justifie presque toujours une investigation immédiate.
Une source de renseignement sur la menace
Exposés sur Internet, certains honeypots servent moins à protéger un périmètre qu’à observer l’écosystème offensif : ils enregistrent les balayages automatisés, les tentatives de force brute et les codes malveillants que déposent les robots. Ces captures alimentent le renseignement sur la menace en indicateurs concrets sur les infrastructures et les outils des attaquants. L’ENISA a consacré une étude aux honeypots comme instrument de détection proactive des incidents, destinée aux CERT, qui passe en revue les solutions disponibles et leurs conditions de déploiement. Des CSIRT entretiennent ainsi des réseaux de capteurs pour suivre l’évolution des campagnes d’attaque.
Des contraintes réelles
L’entretien vient en tête. Un leurre ne rend service que s’il reste crédible : il doit ressembler à son environnement et évoluer avec lui, et ses alertes doivent aboutir chez une équipe en mesure d’y répondre. Un faux serveur figé, jamais mis à jour, finit par se distinguer des machines réelles qu’il prétend imiter, et un attaquant attentif saura l’écarter.
L’isolement pèse tout autant. Un honeypot à forte interaction qui se laisse compromettre devient un point d’appui si son cloisonnement réseau est défaillant : l’attaquant peut s’en servir pour rebondir vers des systèmes de production, voire vers des tiers. Reste la question du périmètre : le dispositif ne voit que ce qui le touche. Un intrus qui n’effleure aucun leurre passe inaperçu ; le honeypot reste donc un complément de la supervision existante, incapable de s’y substituer.
Des leurres dans le système d’information financier
Dans une banque, le procédé vise d’abord le mouvement latéral, cette phase où un attaquant déjà entré cherche des droits plus élevés et un chemin vers les applications de paiement. De fausses entrées dans l’annuaire s’y prêtent bien : un compte de service au nom évocateur, doté en apparence de privilèges étendus mais jamais utilisé, attire précisément les outils d’énumération qu’emploient les intrus, et la moindre tentative d’authentification sur ce compte constitue un signal exploitable. La démarche complète les dispositifs de gestion des comptes à privilèges, centrés quant à eux sur la protection des accès réellement utilisés.
Les jetons s’appliquent aussi aux secrets techniques. Une fausse clé d’API laissée dans un dépôt interne, un faux identifiant rangé dans un coffre : le premier appel qui les utilise révèle une compromission en amont, dans un domaine où la surveillance des identités machine et des secrets peine parfois à distinguer l’usage légitime du détournement.
