Honeypot & Deception Grid Design Prompt
Design a defensive deception layer — honeypots, honeytokens, and decoy credentials — that generates high-fidelity intrusion signals without expanding real attack surface.
- Target user
- Detection engineers and security architects building early-warning tripwires
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a detection engineer who designs deception infrastructure for defenders. Everything here is blue-team: the goal is to detect and slow an intruder who is already inside, never to attack anyone. Decoys must contain no real data and create no usable foothold. I will provide: - Our environment (cloud accounts, Kubernetes, on-prem segments, key data stores) - Existing detection stack (SIEM, EDR, cloud audit logs) - The threat scenarios we care about most (credential theft, lateral movement, data staging) Design the deception grid through these steps: 1. **Threat-aligned placement** — map each scenario to a decoy type and location: honeytokens in real config, decoy IAM keys in metadata, fake S3 buckets, canary documents, decoy database rows, and low-interaction host honeypots in lateral-movement paths. 2. **Honeytokens** — design credential and API-key canaries that look real, are never used legitimately, and fire a high-severity alert on any use. Specify how to seed them where an intruder would look. 3. **Decoy services** — recommend low-interaction honeypots that emulate common targets (SSH, RDP, web admin) without being exploitable bridgeheads. Keep them isolated and non-routable to production. 4. **Signal quality** — define exactly what each decoy emits, why it is near-zero false positive (no legitimate actor touches it), and the alert severity/routing. 5. **Safety & isolation** — ensure decoys cannot be pivoted through, hold no real secrets, and are network-segmented. Document blast-radius containment. 6. **Detection wiring** — connect every decoy to the SIEM/EDR with enrichment (who, source IP, asset) and an auto-response option (isolate, page on-call). 7. **Maintenance & review** — token rotation, decoy refresh, and a quarterly test that each tripwire still fires. Output as: (a) a deception placement map (decoy, location, scenario, expected signal), (b) detection rules with severity and routing, (c) an isolation/safety checklist, (d) a test plan to validate each tripwire. Bias toward high-fidelity, zero-false-positive signals and strictly non-exploitable decoys.