Grafana Labs discovered they’d been breached in April 2025 within minutes — not months. The difference was a single fake AWS API key they’d deliberately placed in their environment. When the attacker tried to validate it, an alert fired instantly.

TL;DR

  • Canary tokens are fake digital assets (files, credentials, URLs) that trigger an alert the moment someone accesses them — the only reason they’d ever be touched is if an attacker found them
  • They’re free, require no software installation, and generate zero false positives by design
  • They work against insider threats, external attackers, and even automated recon tools
  • canarytokens.org offers 20+ token types — DNS, AWS credentials, Office documents, fake WireGuard VPN configs, and more
  • The biggest challenge isn’t setting them up — it’s placing them somewhere realistic enough that an attacker actually finds them

The Problem With Traditional Detection

Most security detection works by looking for known-bad behavior: suspicious process trees, network signatures, YARA matches on malware samples. This works well against known threats — but against a careful attacker, it can take months before they do something detectable.

The 2023 Mandiant M-Trends report put the median attacker dwell time at 197 days. That’s six months of undetected access before discovery. By then, an attacker has had time to understand your environment, identify your most valuable data, and exfiltrate it quietly.

Canary tokens take a different approach. Instead of looking for bad behavior, you create a fake asset that has no legitimate purpose. Anyone who touches it — opens the file, uses the credential, resolves the DNS name — is doing something wrong. No tuning, no thresholds, no baseline needed.

Every alert is real. There are no false positives by design.


How Canary Tokens Work

The concept is simple. You create a token — a URL, a document, a set of credentials — that does nothing useful but immediately phones home when activated. The “phone home” is an HTTP request, a DNS resolution, or an API call to a monitoring service that logs the source IP, timestamp, and token type, then sends you an alert.

Attacker opens fake document
Document fetches hidden URL (DNS/HTTP)
canarytokens.org logs: IP, timestamp, user-agent, geolocation
Alert sent to your email, Slack, or webhook — within seconds

The attacker may not even realize they triggered anything. They opened a Word document that happened to embed a remote image. Or they validated an AWS key that happened to be a honeytoken. Your alert fired while they were still in your environment.


Token Types: What You Can Deploy

canarytokens.org is the de facto standard — free, no registration required, and it supports over 20 token types. Here’s a practical breakdown:

For Files and Documents

Token TypeTriggers When…Best Used In
Word / Excel documentOpened in native Office appShared drives, email archives
PDF documentOpened in Acrobat ReaderSensitive document folders
Windows FolderFolder opened in ExplorerFile servers, backup paths

These are some of the most valuable tokens for insider threat detection. A file named Q4-Bonus-Structure.xlsx sitting in a shared HR folder has no reason to be opened by anyone outside HR. If it is, you know immediately.

For Credentials and Cloud Access

Token TypeTriggers When…Best Used In
AWS API KeyKey used in any AWS API callCI/CD configs, .env files, code repos
AWS S3 BucketBucket access attemptedFake backup storage
Azure Login CertificateCertificate used for Azure authKey vaults, developer machines
Slack API KeyConnection to Slack attemptedConfig files, internal wikis

AWS API key tokens are particularly powerful because attacker tooling (like TruffleHog) automatically validates found credentials — which triggers the alert even if the attacker is just checking whether the key works.

For Network and Infrastructure

Token TypeTriggers When…Best Used In
DNS tokenThe hostname is resolvedAny config file, hosts entry, internal docs
Web bug / URLURL is fetched via HTTPEmails, documents, wikis
WireGuard VPN configConnection attempted”Leaked” VPN configs
Cloned websiteYour site is cloned for phishingJavaScript embed on login pages
QR CodeCode is scannedPhysical access areas, printed docs

The DNS token is especially useful because it fires even without an HTTP connection — a port scanner that resolves names will trigger it before any real connection is made.


Real-World Example: How Grafana Labs Used It

In April 2025, a vulnerable GitHub Actions workflow accidentally exposed Grafana secrets across five public repositories. An attacker forked the repo, injected a command to exfiltrate environment variables (including credentials), and then deleted the fork to cover their tracks.

Here’s where the canary token made the difference: the attacker ran TruffleHog to validate the stolen credentials. TruffleHog made an sts:GetCallerIdentity call to AWS — and one of those keys was a canary token.

The alert fired to Grafana’s Slack webhook within seconds. Their security team was notified before the attacker had time to pivot. No production systems were accessed. No customer data was compromised. All tokens were rotated within minutes.

Grafana’s conclusion: “Canary tokens turn hours of triage into minutes of containment.”

They now deploy tens of thousands of canary tokens across their environment: GitHub Secrets at both org and repo level, Google Drive, dummy inboxes, DNS subdomains, CI/CD pipelines, cloud consoles, and vaults.


Practical Deployment: Where to Put Tokens

Setting up a canary token takes about 60 seconds at canarytokens.org. The harder question is where to place them for maximum effect.

The Golden Rule: Make Them Realistic

A file named honeytoken.docx in a folder called Decoys will never trigger. The goal is to make the token look like something genuinely valuable — so realistic that an attacker reaching that point in your network would naturally want to open or use it.

Good token placement:

  • \\fileserver\finance\2026-budget-draft.xlsx — a finance share any attacker would target
  • .env file in a dev repo with a fake AWS key alongside real-looking variable names
  • ~/.aws/credentials on a developer machine with a canary key under [default]
  • C:\Users\admin\Documents\break-glass-credentials.txt — administrators’ machines
  • Internal wiki page titled “Emergency Access Procedures” with a link token embedded

Bad token placement:

  • Isolated folders with no connection to real assets
  • Filenames that look obviously fake
  • Locations a normal user would access during routine work (this creates false positives)

SOC Use Cases

Detecting Lateral Movement

Create a service account in Active Directory with a realistic name (e.g., svc-backup-mgmt) and a high-value-looking SPN (Service Principal Name). Embed a DNS canary token in a UNC path the account would theoretically access.

If an attacker runs Kerberoasting or BloodHound enumeration and then tries to use the account, the canary fires.

Detecting Credential Dumping

Place a canary AWS key in the Windows credential store or in a browser-saved password. If LSASS is dumped and the credentials are extracted and validated, you get an immediate alert.

Detecting Recon Tools

A DNS canary token embedded in an internal config file or documentation page fires the moment an automated scanner resolves the hostname — before the attacker has done anything else. You get early warning of their presence, not a post-incident audit trail.

Detecting Insider Threats

A Word document with a believable name in a restricted share. Legitimate users have no reason to access it. Any access is an investigation trigger.

Detecting Phishing Infrastructure

The “Cloned Website” token embeds a JavaScript snippet in your login page. If someone downloads your page to clone it for a phishing campaign, the script detects the wrong domain and fires an alert.


Integration: Getting Alerts Where They Matter

canarytokens.org supports email alerts out of the box. For production SOC use, you’ll want webhook integration:

Terminal window
# When creating a token, set the webhook URL to your SIEM or Slack
# Alert payload includes:
{
"manage_url": "https://canarytokens.org/manage?...",
"time": "2026-03-26 09:14:22",
"src_ip": "203.0.113.42",
"geo_info": {"city": "Amsterdam", "country": "Netherlands"},
"user_agent": "python-requests/2.31.0",
"token_type": "aws-id",
"memo": "Fake AWS key in prod CI/CD config"
}

Splunk: Forward webhook alerts to an HTTP Event Collector input and build a saved search that escalates to an incident when a canary fires.

Microsoft Sentinel: Use a Logic App to receive the webhook and create a Sentinel incident automatically. Canary alerts skip the noise — every trigger is a high-confidence incident.

Slack / Teams: The simplest integration. Name the token with a clear memo (e.g., “AWS key in dev/infra repo”) so the alert message is immediately actionable without needing to look anything up.


Limitations: What Canary Tokens Don’t Do

A balanced view is important. Canary tokens are excellent at what they do, but they have real limitations:

Sophisticated attackers can identify them. AWS canary tokens have a tell: running aws sts get-caller-identity with a honeytoken returns a username that contains a Thinkst beacon domain. A careful attacker who knows this can avoid validation. The countermeasure is diversity — don’t rely solely on AWS tokens, and layer them with other token types.

Placement is everything. A poorly placed token that no attacker would realistically find provides no value. This requires understanding attacker behavior in your specific environment.

They detect, not prevent. A canary token tells you an attacker touched something sensitive. It doesn’t stop them. Your incident response process needs to be fast enough to act on the alert before they move on.

Alert metadata can be spoofed. Unauthenticated HTTP requests can trigger some token types with a spoofed source IP, potentially generating a false alert. Using EventBridge-based AWS token monitoring (rather than CloudWatch alone) gives you richer, tamper-resistant telemetry.


Getting Started: Deploy Your First Tokens Today

This takes about 10 minutes:

1. Go to canarytokens.org No account needed. Choose “DNS” as your first token type — it’s the most universal.

2. Give it a descriptive memo Example: "Fake AWS key — dev/infra GitHub repo". This is what appears in your alert, so make it actionable.

3. Set your alert destination Email for getting started. Webhook to Slack or your SIEM for production use.

4. Deploy it realistically For a DNS token: embed the generated hostname in an internal config file, wiki page, or .env file alongside real-looking variable names. Not in a folder called “Honeypots”.

5. Test it Resolve the DNS name yourself (from a non-production IP) to confirm the alert fires. Then forget about the token — it only matters when it fires unexpectedly.

6. Scale gradually Start with 5–10 tokens in your highest-risk locations. Build a simple inventory (spreadsheet or wiki page) noting what each token is, where it’s deployed, and what an alert means. After a few months, expand to cover more of your environment.



Sources