# 53 Honeytoken credential file

> v0.1.0 · role: Detect · [policy: #30 · #33, #16](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

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 — otherwise an attacker with mail access sees, and deletes, their own tripwire.
- Any legitimate process that reads the file (backup agents, secret scanners, EDR) will trip the token — expect and whitelist those false positives before you trust it.

## Setup steps

1. 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

2. 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

3. 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

4. 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

1. 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.
