Canary-watermarked decoy files
The attacker leaves with a file. The file keeps reporting. Fake credentials that trip an alert the moment anyone tries to use them.
The problem
A honeypot session ends when the attacker disconnects. What they took with them is usually where the real story is — credentials get tested, resold and reused, often from different infrastructure than the original scan.
Without a watermark, that second act is invisible.
How it works
- 01Serve the file they asked for
Requests for /.env, /backup.sql, archive .zip files or a PDF on a decoy host get a believable file back instead of a 404.
- 02Watermark every copy
Each decoy carries session-bound canary tokens — fake AWS key pairs, Postgres connection strings, env-var API tokens and web-beacon URLs.
- 03Alert on reuse
When a canary value shows up again — a fake key tried, a connection string used, a beacon URL fetched — it trips an alert, fires your webhooks and links back to the session that took it.
- 04Feed enforcement
New infrastructure that touches a canary is just as attributable as the scanner that stole it, and can be blocked the same way.
What you get
- Decoy .env, .zip, .sql and .pdf files
- Per-session canary tokens, so a trip maps back to who took the file
- Alerts that fire after the session ends
- Visibility into hand-off: the scanner and the user of the credentials are often different
Set it up
Canary files ship with the sensor and are served automatically on trap paths and decoy hosts.
- 01 · Expose trap paths or decoy subdomains
Either via Site Shield edge traps or decoy subdomains on a tunnel.
- 02 · Wire the webhooks
Route canary trips to Slack, a SIEM or your pager. See the integrator guide.
- 03 · Check it end to end
$ deploy/site-shield/shield.sh verify sites/yourdomain.com.env
FAQ
- Are the credentials in the decoy files real?
- No. They are fabricated and tied to canary tokens. Using them reaches nothing except the alert.