Implementing Honeytokens For Breach Detection

Implementing Honeytokens for Breach Detection

When to Use

• When deploying or configuring implementing honeytokens for breach detection capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Common Misconfigurations & Verification

• Token never alerts because it was whitelisted: vuln scanners, DLP crawlers, backup agents and EDR file-indexers trip canaries constantly, so teams add broad allowlists that also swallow real attacker triggers. Scope suppression to specific source IPs/process names, never to the token itself.
• AWS canary key with no trigger path: a fake key in ~/.aws/credentials only alerts when used against AWS — confirm by running aws sts get-caller-identity with the key and verifying the Canarytokens/CloudTrail alert fires. A key an attacker can never reach is decoration, not detection.
• DNS canary blocked by egress filtering: internal resolvers that drop unknown external lookups mean the beacon never reaches canarytokens.org. Test with nslookup <token-hostname> from the segment where the token actually lives, not from your laptop.
• Document beacons defeated by offline/preview readers: Office "Protected View" and many PDF viewers block the callback. Verify the beacon fires in the target's real software, and place tokens where attackers exfiltrate (file shares, password vaults), not just open.
• Confirm the alert pipeline, not just creation: trigger each token once at deploy time and confirm it reaches the SOC channel (webhook/email). A created token with an unverified webhook is a silent failure.

Prerequisites

• Familiarity with security operations concepts and tools
• Access to a test or lab environment for safe execution
• Python 3.8+ with required dependencies installed
• Appropriate authorization for any testing activities

Instructions

Deploy honeytokens across critical systems to detect unauthorized access. Each token type alerts via webhook when triggered by an attacker.

import requests

# Create a DNS canary token via Canarytokens
resp = requests.post("https://canarytokens.org/generate", data={
    "type": "dns",
    "email": "soc@company.com",
    "memo": "Production DB server honeytoken",
})
token = resp.json()
print(f"DNS token: {token['hostname']}")

Token types to deploy:

1. AWS credential files (~/.aws/credentials) with canary keys
2. DNS tokens embedded in configuration files
3. Document beacons (Word/PDF) in sensitive file shares
4. Database honeytoken records in user tables
5. Web bugs in internal wiki/documentation pages

Examples

# Generate a fake AWS credentials file with canary token
aws_creds = f"[default]\naws_access_key_id = {canary_key_id}\naws_secret_access_key = {canary_secret}\n"
with open("/opt/backup/.aws/credentials", "w") as f:
    f.write(aws_creds)