53 Honeytoken credential file

A fake but plausible cloud credential — an AWS canarytoken in a ~/.aws/credentials file, a deploy-notes file, a backup runbook — planted where an intruder would look and referenced by no real automation. Any use of the key is hostile by construction: there is no legitimate caller. The alert goes to a mailbox outside the tenant being defended, and the placement is recorded in a register so a triggered alert maps back to the file that leaked.

Caveats

The alert destination must be outside the tenant you are protecting¹
Any legitimate process that reads the file (backup agents, secret scanners, EDR) will trip the token²

Setup steps

Generate an AWS-key canarytoken at canarytokens.org (or a self-hosted instance) with an alert address that is NOT in the tenant being defended.

Token type
AWS keys
alert email
out-of-band mailbox
Embed the key pair in a plausible file (e.g. ~/.aws/credentials, deploy-notes.txt, backup-restore.md) and place it where an intruder would look: a personal Drive folder, an admin's Desktop, an ops shared drive.

Filename/content plausible; never referenced by any real automation
Record the token's location and fingerprint in the honeytoken register so a triggered alert can be mapped to the file that leaked.

Register: token id, placement, date, owner
Test once from a throwaway network, then confirm the alert arrived out-of-band. From then on the key is never referenced by any legitimate automation — the only sanctioned touches are the scheduled re-tests in the maintenance list, each followed by rotating the token that fired.

Ongoing maintenance

automatable: script Quarterly: trip each honeytoken to prove it still alerts; rotate tokens that have fired.

How to verify

Use the honeytoken yourself (from a clean context) and confirm the alert fires with enough context to act on. An untested canary is indistinguishable from a dead one.

v0.1.0Detect policy #30 · #33, #16 ↗