Honeytoken.

Un honeytoken est un artefact de tromperie placé au sein de systèmes réels, de sorte que tout usage qu'on en fait est, par conception, malveillant ou anormal. Le terme a été forgé par Augusto Paes de Barros lors d'un échange sur une liste de diffusion en février 2003 avec Lance Spitzner, du Honeynet Project, étendant l'idée du honeypot des systèmes entiers aux éléments de données individuels. Les exemples incluent des comptes utilisateurs plantés, de fausses lignes de base de données, des clés d'accès cloud leurres, des documents filigranés et des enregistrements DNS qui émettent une balise à leur résolution.

flowchart LR
  P[Placer le honeytoken<br/>dans dépôt / partage / BD] --> W[Attendre : aucun usage légitime]
  W --> X((L'attaquant le<br/>trouve et l'utilise))
  X --> T[L'usage déclenche<br/>une alerte haute fidélité]
  T --> IR[IR : identifier la source,<br/>cerner la brèche]

Comme les honeytokens sont inertes et jamais touchés par des processus légitimes, ils produisent quasi zéro faux positif et donnent un signal précoce et haute fidélité de vol d'identifiants, de préparation de données ou d'abus interne. Un motif pratique est la clé canary AWS : une clé IAM plantée dont l'usage est capté par CloudTrail ; Thinkst Canarytokens a popularisé des versions gratuites et auto-hébergeables (jetons URL, document et clé AWS). Les honeytokens étendent la visibilité là où les journaux sont rares — SaaS tiers, dépôts de code, sauvegardes — et s'alignent sur les techniques défensives Decoy d'ATT&CK. Réserves : le jeton doit être plausible mais jamais atteignable par les flux normaux, et les scanners d'identifiants fuités ou des pipelines CI négligents peuvent le déclencher, si bien que chaque alerte requiert encore un triage au regard de son emplacement planté.