Détecter un honeytoken sans le déclencher : méthodes et limites
Comment un attaquant repère un honeytoken sans l'activer : métadonnées, documents, domaine de rappel, clés AWS. Et ce qui met chaque méthode en échec.
Un honeytoken ne vaut que tant qu'on ne l'a pas identifié comme tel. Un attaquant un peu méthodique dispose aujourd'hui de plusieurs façons de repérer un leurre sans l'activer, et la plupart ne demandent ni outil exotique ni accès particulier. On les passe en revue ci-dessous, avec à chaque fois ce qui permet de s'en prémunir côté défense.
Ce qu'est un honeytoken, en deux phrases
Un honeytoken est une donnée factice dont le seul rôle est de générer une alerte quand quelqu'un s'en sert. Ça peut être un couple d'identifiants, une clé API, un document piégé, un enregistrement DNS, une adresse email. Aucun utilisateur légitime n'a de raison d'y toucher, donc toute interaction est suspecte par construction. D'où le taux de faux positifs très bas.
La fiche honeytoken du glossaire détaille son fonctionnement et les formes qu'il peut prendre. Retenons ici la différence avec un honeypot : ce dernier émule un système complet et offre un terrain d'observation riche, là où le honeytoken est une simple donnée posée sur un système existant, plus légère à déployer à grande échelle et au signal plus immédiat.
À quoi ressemble un honeytoken déployé
Avant de chercher à les repérer, il faut voir à quoi ils ressemblent une fois en place. Trapster permet de générer ces différents types de honeytokens, prêts à être déployés sur vos systèmes.
Prenons l'exemple d'un honeytoken de type URL avec redirection. Ce type de token permet de créer un lien piégé : dès qu'il est ouvert, il redirige l'utilisateur vers une adresse définie au préalable, tout en levant une alerte du côté de Trapster.
Il suffit ensuite de placer le lien généré de manière à ce qu'un attaquant tombe dessus. Par exemple, en créant un raccourci sur le bureau qui semble légitime (nom de fichier crédible, icône familière) :
Lorsque l'attaquant clique sur ce raccourci, il est redirigé vers l'URL définie lors de la création du honeytoken. Du côté de Trapster, une alerte est immédiatement levée, signalant l'interaction avec le token :
C'est précisément ce clic que l'attaquant va chercher à éviter.
Détecter sans déclencher
La difficulté, pour qui veut repérer un leurre, tient en une phrase : il faut conclure sans jamais interagir. Chaque vérification doit donc rester hors ligne, ou porter sur autre chose que le token lui-même. Voici les principales méthodes, et ce qui les met en défaut.
Une accessibilité trop suspecte
Un honeytoken contenant des identifiants, des mots de passe ou des clés d'accès AWS, placé de manière trop visible, est suspect. Un attaquant pourrait s'en méfier : pourquoi une ressource aussi sensible serait-elle aussi facilement accessible ?
La parade tient à peu de chose : imiter la négligence réelle plutôt que de la caricaturer. Un .env oublié au fond d'un répertoire de travail passe. Un passwords.txt sur le bureau, non.
Des métadonnées incohérentes
Les métadonnées d'un fichier peuvent trahir un honeytoken. Une date de création trop récente par rapport aux autres fichiers du même dossier, un auteur inconnu ou générique, l'absence d'historique de modification, ou encore des propriétés d'édition qui ne correspondent pas aux habitudes de l'environnement (logiciel, version, template utilisé) sont autant d'indices qui peuvent éveiller la méfiance d'un attaquant.
Un fichier réellement utilisé au quotidien porte presque toujours des traces d'usage : plusieurs versions, des modifications régulières, un auteur cohérent avec l'organisation. Un honeytoken statique, créé une seule fois puis jamais modifié, peut se distinguer par cette absence d'historique naturel.
Le contournement est simple à mettre en place mais rarement fait : partir d'un vrai document de l'organisation plutôt que d'une page blanche, et lui garder son auteur, son template et une date de modification plausible.
Un secret qui n'existe qu'à un seul endroit
Un identifiant réellement utilisé laisse des traces ailleurs que dans le fichier où on le découvre : il apparaît dans un script de déploiement, une variable de CI, une documentation interne, la configuration d'un autre serveur. Un honeytoken, lui, est presque toujours un singleton. Déposé à un endroit, référencé nulle part.
Un grep sur le poste compromis, sur les dépôts accessibles ou sur les partages réseau répond à la seule question qui compte : ce secret sert-il à quelque chose ? Ça coûte quelques secondes. Ça ne déclenche rien. Et une clé qui n'apparaît dans aucun historique de commandes, dont aucun service ne semble dépendre, devient tout de suite un candidat sérieux.
C'est aussi le point le plus facile à corriger côté défense. Il suffit de semer le même leurre à plusieurs endroits qui se répondent : une entrée dans un script de déploiement, une mention dans un document, une variable de configuration. Le secret gagne alors l'épaisseur qui lui manquait.
Analyser les documents sans les ouvrir
Certains honeytokens se présentent sous la forme de documents Word, Excel ou PDF. Lorsqu'ils sont ouverts, ces documents effectuent une requête vers Internet, qui déclenche l'alerte côté défenseur. Si l'on parvient à détecter ce comportement sans ouvrir le document, il devient possible de repérer le honeytoken sans jamais l'activer.
Il existe un outil qui permet de tester ce type de document sans déclencher le honeytoken : CanaryTokenScanner.
Principe : les fichiers .docx, .xlsx et .pptx sont en réalité des archives ZIP. L'outil lit directement le contenu de l'archive, sans jamais ouvrir le document dans Word, Excel ou un autre logiciel, et recherche des URLs suspectes embarquées, typiques des honeytokens à callback HTTP comme les canary tokens de canarytokens.org. Il applique le même principe aux fichiers PDF, en décompressant leurs flux internes (stream...endstream).
Le voilà en action :
L'outil ne voit que ce qu'il sait chercher. Un déclencheur qui ne passe pas par une URL embarquée lui échappe, tout comme une adresse de rappel qui ne ressemble à aucun fournisseur connu.
Lire un raccourci sans le suivre
Le honeytoken de type URL vu plus haut repose sur un clic. Or le lien n'a pas besoin d'être suivi pour être lu : un fichier .url Windows est un simple fichier texte au format INI, dont la ligne URL= se lit avec n'importe quel éditeur. Un fichier .lnk est binaire, mais sa cible s'extrait tout aussi bien avec un parseur dédié ou un simple strings.
L'attaquant récupère ainsi l'adresse de destination sans jamais l'ouvrir, puis la juge sur pièces : domaine inconnu, sous-domaine généré aléatoirement, absence de rapport avec l'organisation.
Parade : héberger le lien sur un domaine de l'organisation, avec un chemin crédible. Le raccourci devient indiscernable d'un raccourci interne, et il ne reste plus qu'une façon d'en avoir le cœur net. L'ouvrir.
Le domaine de rappel
La plupart des honeytokens à callback (documents, images, liens, requêtes DNS) doivent joindre un serveur pour signaler leur activation. Une fois l'adresse extraite par les méthodes précédentes, rien n'oblige à la contacter pour la juger.
Les fournisseurs publics utilisent des domaines connus, recensés dans des listes communautaires : en reconnaître un suffit à classer le fichier comme leurre. À défaut, l'âge du domaine, son enregistrement WHOIS ou la forme de son sous-domaine donnent des indices, tous consultables sans émettre la moindre requête vers le serveur piégé lui-même.
Un domaine de rappel maison, enregistré depuis longtemps et déjà utilisé pour autre chose, annule tout ça. C'est d'ailleurs un des critères que nous regardons dans notre comparatif des alternatives à Thinkst Canary, parce que tous les produits ne le permettent pas.
Décoder une clé d'accès AWS
Lorsqu'il s'agit d'une clé d'accès AWS, il est possible de déterminer s'il s'agit d'un honeytoken sans le déclencher, grâce à son Account ID. Cet identifiant de compte AWS peut être retrouvé de manière totalement hors ligne (sans aucune requête réseau), directement à partir de l'Access Key ID.
TruffleHog permet de faire ce décodage automatiquement, et de vérifier si l'ID de compte obtenu est connu pour appartenir à un fournisseur de honeytoken :
Cette méthode reste toutefois limitée : elle ne fonctionne que si l'ID de compte décodé fait partie d'une liste de comptes déjà connus et recensés publiquement. Un fournisseur qui gère ses comptes AWS de façon moins prévisible échappe à cette détection, comme c'est le cas ici, où TruffleHog ne détecte rien d'anormal alors qu'il s'agit pourtant bien d'un honeytoken :
Il nous fournit toutefois un indice : le nom d'utilisateur IAM.
arn:aws:iam::225619513056:user/orpmwqbwzgojpxjpomqczuldwwbltkwvmpacehwoaurbvvcatp
Cette chaîne de 50 caractères aléatoires semble très suspecte et ne ressemble à aucune convention de nommage d'entreprise réelle (pas de préfixe métier, pas de nom de service, pas de date, pas d'environnement).
Autrement dit : la cryptographie a tenu, c'est la convention de nommage qui a parlé. Un utilisateur IAM baptisé comme les autres du parc, avec un préfixe métier et un environnement, n'aurait rien laissé filtrer.
Conclusion
Aucune des méthodes ci-dessus n'attaque le concept de honeytoken. Toutes exploitent une incohérence de mise en œuvre : un compte AWS déjà recensé, un nom généré au hasard, un callback embarqué repérable, un leurre posé à un endroit sans lien avec le reste. Le principe, lui, tient toujours. Un identifiant que personne n'a de raison d'utiliser reste le signal le plus propre qu'on puisse mettre dans un système d'information.
Ce qui distingue un leurre qui tient d'un leurre qui saute, c'est donc le soin apporté à son intégration, pas la technologie derrière. Des métadonnées conformes aux conventions maison, un domaine de rappel qui appartient à l'organisation, une présence cohérente à plusieurs endroits : trois détails ennuyeux qui font la différence entre une alerte et rien du tout.
Reste l'asymétrie, qui joue en faveur du défenseur. Chacune de ces vérifications coûte du temps à l'attaquant, et il lui suffit de se tromper une fois. Un honeytoken n'a pas besoin d'être indétectable. Il a besoin d'être assez crédible pour que vérifier coûte plus cher que tenter sa chance.
Vous avez rencontré d'autres techniques de détection sur le terrain ? On complète volontiers cet article, écrivez-nous.
