Deploying Honeytokens and Canarytokens

Authorized Use Only: Deception assets described here are defensive controls deployed inside your own environment. Deploying tokens, decoy credentials, or honeypots on infrastructure you do not own or administer, or using them to entrap third parties, may violate computer-misuse and privacy law. Deploy only on assets you own or are explicitly authorized to instrument, and route all alert data through approved monitoring channels.

Overview

Honeytokens (a.k.a. canarytokens) are decoy artifacts — credentials, files, URLs, API keys, DNS names, database connection strings, documents — that have no legitimate operational use. Because no authorized user or process should ever touch them, any interaction is a high-fidelity signal of an intrusion, insider misuse, or reconnaissance. Unlike signature- or anomaly-based detection, honeytokens generate near-zero false positives: the alert is the compromise.

Thinkst's open-source Canarytokens project (https://canarytokens.org and the self-hostable thinkst/canarytokens-docker) generates dozens of token types that "phone home" when triggered: an HTTP/web-bug URL that fires on GET, an AWS API key that fires when used against AWS, an MS Word/PDF document that fires on open, a DNS token that fires on resolution, a Slack API token, a Kubernetes kubeconfig, an Azure login certificate, a log4shell payload, and more. Each token is bound to a unique memo (so you know where it was planted) plus an alert channel (email and/or webhook).

This skill maps to MITRE D3FEND's Decoy File (D3-DF), Decoy User Credential (D3-DUC), and Honeytoken techniques. From an ATT&CK perspective, a triggered honey credential most commonly evidences adversary attempts to abuse or modify authentication material (T1556 – Modify Authentication Process and related credential-access activity), giving the SOC an early, unambiguous tripwire deep inside the kill chain — typically after initial access but before lateral movement completes.

When to Use

• When you need high-fidelity intrusion detection in segments where traditional telemetry is sparse (file shares, password vaults, code repos, cloud accounts).
• When validating that an attacker who reaches a "crown-jewel" host or document store is detected, not just blocked at the perimeter.
• When seeding decoy credentials into LSASS-reachable memory, browser stores, .aws/credentials, or password managers to catch credential dumping and reuse.
• When instrumenting documents, repos, or wikis to catch data theft and ransomware staging.
• When building a MITRE D3FEND-aligned deception layer as part of a defense-in-depth or zero-trust program.