Honeytokens: Detection by Bait

Honeytokens trigger alerts when accessed.

Idea

Honeytokens are one of the simplest and most effective security controls available. The idea is to plant fake but realistic-looking credentials, files, or data in places attackers would search. The bait has no legitimate business reason to be accessed; access to the bait is therefore unambiguous evidence of compromise. The signal-to-noise ratio is among the highest in the security toolkit.

What honeytokens actually are:

• Fake credentials in attractive locations.: A fake AWS access key in a config file. A fake API token in a README. A fake password in an "old" .env file. Each looks real to an attacker scanning for exposed credentials but is in fact a tripwire that alerts the security team when used.
• Access equals compromise indicator.: Legitimate users have no reason to use these credentials; they are not documented anywhere as real. Attackers find them in the same way they find real credentials (scanning code, scanning storage, scanning compromised endpoints). Use of the credential is unambiguous: someone who should not have it just used it.
• Cannot be detected by attackers.: The honeytoken looks real. The attacker cannot tell from inspection that this AWS key is a honeytoken rather than a working credential. They use it; the alert fires; the security team learns that the system or the file containing the honeytoken has been compromised.
• Specific implementations available.: Canary tokens (Thinkst, free), AWS canary credentials with CloudTrail alerting, custom honeytokens built on specific cloud APIs. Each has its own trade-offs; the principle is the same.
• Multi-layer detection.: Honeytokens detect compromise at the layer where the credential was found. A honeytoken in a code repo detects code-repo compromise. A honeytoken in an S3 bucket detects S3 access. A honeytoken in a developer's home directory detects endpoint compromise. The placement determines what is being monitored.

Honeytokens are cheap to deploy and high-value when they fire. The discipline is placing them deliberately in the spots attackers would actually look.

Placement

The placement of honeytokens determines their detection coverage. Random placement produces alerts on random compromises; deliberate placement focused on attacker-attractive surfaces produces alerts on the compromises that actually matter.

• S3 buckets that look interesting.: A bucket named "backups" or "production-data" with what looks like sensitive content (named files like "customer-export-2023.csv"). The bucket has a honeytoken inside; access to the bucket fires the alert. Attackers scanning S3 for misconfigured buckets reach this and trigger detection.
• Code repositories.: A honeytoken AWS credential committed to a private repo, in a file named "config.example.env" or "old-secrets.txt." Attackers who compromise the source control system scan for credentials and find this. The use of the credential is the alert.
• Internal file shares.: SharePoint folders, internal wikis, Confluence spaces. A document titled "Production credentials backup" with a honeytoken inside. Insider attackers and external attackers who compromised an employee's account both look at these; either triggers detection.
• Developer endpoints.: A honeytoken in a developer's home directory; one in their browser bookmarks; one in their downloads folder. Endpoint compromise (malware, RAT, lateral movement) reaches the developer's environment; the honeytoken fires.
• Where attackers actually look.: The placement reflects how attackers operate. They scan code repos for credentials, scan public buckets for sensitive data, scan compromised endpoints for stored secrets. Honeytokens placed where attackers look are honeytokens that fire when attackers find them.

The placement is the most important design decision. Honeytokens placed in inactive systems detect inactive attackers; honeytokens placed in active surfaces detect active attackers.

Alert

The alert is the output of the honeytoken practice. When a honeytoken is used, the alert fires immediately and routes to the security team's highest priority queue. The alert is reliable; false positives are rare; response should be aggressive.

• Access fires high-priority alert.: The alert routes to the security on-call. The page is treated as an active incident. Investigation begins immediately because the signal is reliable enough to warrant the response.
• Real signal, rare false positive.: Most security alerts have meaningful false positive rates. Honeytoken alerts are different; the only way they fire is if someone used a credential or file that has no legitimate use. The false positive rate is approximately zero.
• Investigation immediately.: The honeytoken's metadata identifies what was compromised. The honeytoken in the code repo fired; the source repository or someone with access to it is compromised. The honeytoken in the developer's laptop fired; the laptop or the developer's account is compromised. The fired honeytoken localizes the investigation.
• Combine with broader response.: The honeytoken alert is the first signal. The full response includes pulling logs from the surrounding systems, correlating with other detections, and beginning containment. The honeytoken is the trigger; the response is structured.
• Maintenance: rotate honeytokens periodically.: Honeytokens age. Old fake credentials get cleaned up by automated scanners; old fake files get retired; the placement that made sense two years ago may not match attacker behavior today. Quarterly review and rotation keep the program effective.

Honeytokens are one of the highest leverage detection controls available, and one of the cheapest to deploy. Nova AI Ops integrates with honeytoken platforms, surfaces honeytoken alerts as top-priority incidents, and tracks honeytoken-fired investigations from detection through resolution so the security team has a structured workflow for the highest-fidelity signals they receive.