Honeytoken.

Ein Honeytoken ist ein Täuschungsartefakt, das in reale Systeme eingebettet wird, sodass jede Nutzung per Design bösartig oder anomal ist. Der Begriff wurde von Augusto Paes de Barros in einem Mailinglisten-Austausch im Februar 2003 mit Lance Spitzner vom Honeynet Project geprägt und erweiterte das Honeypot-Denken von ganzen Systemen auf einzelne Datenelemente. Beispiele sind platzierte Benutzerkonten, gefälschte Datenbankzeilen, Köder-Cloud-Zugangsschlüssel, mit Wasserzeichen versehene Dokumente und DNS-Einträge, die beim Auflösen ein Beacon senden.

flowchart LR
  P[Honeytoken platzieren<br/>in Repo / Share / DB] --> W[Warten: keine legitime Nutzung]
  W --> X((Angreifer findet<br/>und nutzt es))
  X --> T[Nutzung löst<br/>hochpräzisen Alarm aus]
  T --> IR[IR: Quelle ermitteln,<br/>Vorfall eingrenzen]

Da Honeytokens inert sind und nie von legitimen Prozessen berührt werden, erzeugen sie nahezu keine Fehlalarme und liefern ein frühes, hochpräzises Signal für Zugangsdatendiebstahl, Datenstaging oder Insider-Missbrauch. Ein praktisches Muster ist der AWS-Canary-Key: ein platzierter IAM-Schlüssel, dessen Nutzung CloudTrail erfasst; Thinkst Canarytokens machte kostenlose, selbst hostbare Varianten populär (URL-, Dokument- und AWS-Key-Tokens). Honeytokens erweitern die Sichtbarkeit dorthin, wo Logs spärlich sind – Drittanbieter-SaaS, Code-Repositories und Backups – und lassen sich auf ATT&CKs defensive Decoy-Techniken abbilden. Vorbehalte: Das Token muss plausibel, aber von normalen Workflows nie erreichbar sein, und Scanner für geleakte Zugangsdaten oder nachlässige CI-Pipelines können es auslösen, sodass jeder Alarm weiterhin ein Triage gegen seinen platzierten Ort braucht.