Canary Tokens and Honeytokens: The Cheapest Breach Detection Control You Are Not Using
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most detection controls generate alerts that require investigation to determine whether they indicate a real attack. A canary token alert has near-zero false positive rate by definition, no legitimate process reads a fake .env file placed in a backup share, and no legitimate user opens a document that exists only to detect unauthorized access. When a canary fires, something accessed it that should not have. That is a high-confidence signal that justifies immediate investigation, deployed in under 10 minutes per token.
Canary Token 1: Fake AWS Credentials in a .env File
What it detects: Attackers who scan developer machines, backup shares, or code repositories for .env files containing cloud credentials.
Setup:
- Go to canarytokens.org and select AWS Keys
- Enter your alert email and a reminder (e.g., 'Fake .env in dev share, server /backup/dev')
- Download the generated credentials file
- Place it in a location attackers would scan: a backup share, a developer home directory subfolder, or an old project directory
The generated credentials look exactly like real AWS access keys. When an attacker uses them to make any AWS API call, you receive an email alert containing the attacker's source IP, the AWS region they called, and the API action they attempted.
What a real alert looks like:
Canary Alert: AWS API Key Used
Source IP: 185.220.101.x (Tor exit node)
AWS Region: eu-west-1
API Call: iam:GetUser
Time: 2026-05-21 14:32:11 UTC
Reminder: Fake .env in dev share, server /backup/dev
The source IP and AWS region combination tells you whether this was an automated credential scanner (typically multiple regions in rapid succession) or a targeted attacker exploring what the credentials have access to.
Canary Token 2: DNS Token in a Configuration File
What it detects: Attackers who read configuration files containing hostnames, database connection strings, API endpoint URLs, internal service addresses.
Setup:
- Go to canarytokens.org and select DNS Token
- Note the generated subdomain (e.g., abc123.canarytokens.com)
- Place it as a hostname in a configuration file that should never be accessed externally:
; config.ini, placed in /etc/legacy-app/
[database]
host = abc123.canarytokens.com
port = 5432
user = dbadmin
password = legacy-backup-2019
When the attacker reads this file and attempts to connect to the database, their system resolves the hostname, making a DNS query that fires your alert. You receive the source IP that made the DNS query.
Advanced deployment: Embed the DNS token hostname in environment variables, Dockerfile EXPOSE labels in old images, or Kubernetes ConfigMaps that should never be accessed by external principals. Any DNS resolution triggers an alert.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Canary Token 3: Word Document in an Admin Share
What it detects: Attackers who are exploring shared network drives or admin shares after gaining initial access, a common lateral movement step.
Setup:
- Go to canarytokens.org and select Microsoft Word Document
- Name it something tempting: 'Q2 2026 Security Audit Findings.docx' or 'VPN Credentials - IT Use Only.docx'
- Place it in locations attackers commonly explore after compromising an endpoint: \SERVER\ADMIN$, \SERVER\C$, or in an IT-accessible fileshare
When the document is opened, it makes an outbound request that fires your alert. You receive the source IP and timestamp of when the document was opened.
What makes a good decoy document name:
- Financial: 'Annual Budget FY2026.xlsx', 'Employee Salaries 2026.xlsx'
- Credentials: 'Network Passwords - IT Only.docx', 'Service Account Credentials.txt'
- Security: 'Penetration Test Report - Draft.docx', 'Firewall Rules Export.csv'
The document name should be believable in context. A file named 'Credentials.docx' in an IT admin share is plausible. The same file in a developer home directory is not.
Canary Token 4: Fake Database Credentials in Code
What it detects: Attackers who search source code repositories for hardcoded credentials, a common post-compromise step and a primary supply chain attack technique.
Setup:
- Create a file in each repository that looks like a developer accidentally committed credentials:
# db_config.py, committed to git as if accidentally
# This file should never be executed in production
DB_HOST = 'abc123.canarytokens.com' # DNS canary token
DB_USER = 'prod_admin'
DB_PASS = 'ProdDB@2024!'
DB_NAME = 'production'
-
Commit this file to the repository's git history (not on the main branch, add it to a stale feature branch or as a 'deleted' file that still exists in history)
-
Use a DNS token as the DB_HOST, when the attacker extracts the credentials and attempts a connection, the DNS query fires your alert
Alternative, GitHub secret scanning canary: Configure GitHub Advanced Security secret scanning with a custom pattern that matches a unique fake credential format. When the canary is detected by an automated scanner, GitHub alerts you.
Canary Token 5: Fake Kubernetes Service Account Token
What it detects: Attackers who have achieved container or node access and are looking for Kubernetes credentials to escalate privileges.
Setup: Create a fake kubeconfig file with a DNS canary token as the cluster API endpoint:
# /root/.kube/config.bak, placed on Kubernetes nodes
apiVersion: v1
kind: Config
clusters:
- cluster:
server: https://abc123.canarytokens.com:6443
certificate-authority-data: [fake CA data]
name: production
contexts:
- context:
cluster: production
user: admin
name: production
current-context: production
users:
- name: admin
user:
token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.[fake token]
Place this in locations on Kubernetes nodes where attackers look for cluster credentials: /root/.kube/, /home/*/.kube/, /var/lib/kubelet/ (as a backup file). When an attacker reads the file and attempts to connect to the cluster, the DNS query to your canary server fires the alert.
The fake token looks like a real JWT and will fool automated credential scanners. The DNS query fires before the attacker determines the token is invalid.
Operationalizing Canary Tokens at Scale
Centralize alerting: Configure all canary tokens to alert to a single email or Slack channel. Canarytokens.org supports webhook delivery, set up a webhook to your SIEM or incident response platform (PagerDuty, Opsgenie) so canary alerts create incidents automatically.
Document every deployed token: Maintain a registry of what token is deployed where, when it was placed, and what alert it generates. Without this, you will investigate a canary alert that turns out to be a legitimate process you forgot about.
Rotate tokens periodically: Canary tokens do not expire, but deploying new ones periodically (quarterly) in different locations gives you broader coverage. Old tokens in the same locations can also become ineffective if attackers learn to recognize the canarytokens.com DNS signature.
Thinkst Canary for fleet-scale deployment: The free tier at canarytokens.org handles most small team needs. Thinkst Canary (paid) provides physical canary devices that impersonate internal infrastructure (fake servers, NAS devices, Cisco switches) and a management console for deploying and monitoring tokens at scale across hundreds of endpoints.
Combine with your SIEM: Ingest canary token alerts as a high-priority event type in your SIEM. A canary firing should auto-create a P1 incident. The time between canary trigger and your response is your effective detection time for that attack path, measure and optimize it.
The bottom line
Canary tokens give you detection capabilities that take minutes to deploy, cost nothing to run, and generate alerts with near-zero false positive rates. The five deployments in this guide cover the most common post-compromise exploration paths: credential files, shared drives, source code, Kubernetes access, and network exploration. Deploy one this afternoon and you will have better detection coverage for lateral movement than most organizations with six-figure SIEM budgets.
Frequently asked questions
Do canary tokens work if the attacker is offline or air-gapped?
DNS-based and web-based canary tokens require the attacker to make an outbound network request. If the compromised system has no outbound internet access, the token will not fire. For air-gapped environments, use file-access-based monitoring (Windows file auditing, inotifywait on Linux) on honeydocument files instead.
What is the difference between canarytokens.org and Thinkst Canary?
Canarytokens.org is a free, community-supported service providing individual token generation. Thinkst Canary is a commercial product providing physical canary devices, fleet management, and enterprise features. For most teams, canarytokens.org covers the use cases in this guide at no cost. Thinkst Canary is worth the investment for organizations that need physical deception devices or centralized management across hundreds of endpoints.
Will canary tokens interfere with legitimate security scanning tools?
Potentially. If your internal vulnerability scanner or secret scanner reads the fake .env file or config file during a scan, it may trigger the alert. Document all internal scanning tools and their credentials so you can distinguish scanner alerts from attacker alerts. Some teams configure canary tokens with an IP allowlist that suppresses alerts from known scanner source IPs.
How do I place a canary token where an attacker will find it without affecting production?
The key is realistic placement without operational impact. Fake .env files in non-production directories, Word documents in read-only shares, and DNS tokens in old configuration backups all work because they are accessible but not part of any running system. Never use canary credentials in a location where a legitimate automation tool might read and attempt to use them.
What should I do immediately when a canary token fires?
Treat it as a confirmed breach indicator, not a potential one. The attacker is in your environment and actively exploring. Immediately: identify which system the canary was placed on, check for active sessions on that system, review recent authentication events for unusual activity, and escalate to your incident response process. The canary alert tells you the attacker's source IP, check that IP against your network logs to determine how they got in.
How do I prevent canary tokens from being flagged by internal secret scanners like Trufflehog or GitHub Advanced Security and accidentally removed before an attacker finds them?
Add the canary credential patterns to your secret scanner's allowlist or false-positive suppression configuration. For Trufflehog, use the --exclude-paths flag or a .trufflehogignore file in the repository root that lists the specific file paths where canary tokens are intentionally placed. For GitHub Advanced Security custom patterns, add a custom secret pattern that matches your canary format and mark alerts from that pattern as 'used in tests' to suppress them from the main alert queue without deleting the pattern from the codebase. Document each suppression rule with the canary's purpose and expected expiry date so future reviewers know why the finding was suppressed. The key discipline is maintaining a separate canary registry outside the repository so the token's location is known to your security team but the suppression rule itself does not reveal the canary's nature to anyone who reads the scanner config.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.