How to Use Honeytokens and Decoys: A Practical Guide
TL;DR · the short version
Cyber deception plants believable-but-fake assets — credentials, accounts, files, systems — that legitimate users have no reason to touch, so any interaction is a high-confidence sign of an intruder with almost no false positives. Techniques include honeytokens (fake credentials, API keys or documents that alert when used), canary accounts (decoy users that should never log in), and honeypots/decoy systems. Deception is especially effective against living-off-the-land and lateral-movement activity that blends in with normal traffic.
Most detection is a fight against false positives: you infer that behaviour is malicious from signals that are also, sometimes, normal. Cyber deception sidesteps that fight entirely. You plant assets that no legitimate user should ever touch — so when one is touched, you know. That is why honeytokens and decoys are some of the highest-signal, lowest-noise detections a defender can deploy, and why guidance increasingly recommends them for catching intruders who otherwise blend in.
The techniques
- Honeytokens: fake credentials, API keys, database records, documents or URLs, instrumented to alert the instant they are accessed or used. The tripwire of choice — cheap, and unambiguous when triggered.
- Canary accounts: decoy user accounts (often named to look privileged) that should never authenticate. A login attempt is a near-certain sign of compromise or reconnaissance.
- Honeypots / decoy systems: fake services or hosts that attract attackers, waste their time, and reveal their tools and techniques while keeping them away from real assets.
Why it works so well against modern attacks
Living-off-the-land techniques — using legitimate tools and credentials — are hard to catch precisely because they look normal. Deception does not care what tools an attacker uses; it cares that they touched something they should not know exists. An intruder doing reconnaissance to find credentials and move laterally is very likely to stumble onto a well-placed honeytoken, and the moment they do, you have a high-confidence, early alert.
Starting on a budget
- Seed a few honeytokens. Plausible fake credentials, a decoy API key, a tempting document — wired to alert on use, placed where recon would find them.
- Add a canary account. An unused, privileged-looking account that should never log in.
- Route alerts to the SOC with runbooks. A honeytoken hit must trigger investigation, not sit unseen — the value is entirely in the response.
- Expand to decoy systems once the basics prove their signal quality.
Where to plant honeytokens and decoys, and what each one catches
To use honeytokens and decoys well, place each one where an attacker doing a specific step would find it, and wire an alert to the one event that legitimate activity never produces. Common placements:
- Fake cloud access keys in a config file, script or internal repo. These catch credential harvesting from endpoints and code. Alert on any authentication attempt with the key.
- A decoy service account with a service principal name (SPN) in Active Directory. This catches Kerberoasting. Alert on Kerberos service-ticket requests for that account (Windows event 4769).
- A canary admin account that nobody uses. This catches password spraying and stolen-credential use. Alert on any logon, failed or successful (events 4625 and 4624, or your identity provider's sign-in log).
- Decoy documents with a tempting name (for example "passwords" or "payroll") on file shares, built to call home when opened. These catch share browsing and staging for exfiltration.
- Fake database records, such as a customer row with a unique email address you monitor. These catch data theft, because mail to that address, or the record appearing anywhere outside your systems, means the data has left.
- Decoy hosts or services (honeypots) on internal subnets. These catch network scanning and lateral movement.
Four rules keep the signal clean:
- Never give a decoy real privileges or real data.
- Keep an inventory of every token and where it is placed.
- Exclude legitimate scanners and backup jobs that might touch decoys, so they don't raise false alarms.
- Route every alert to a runbook that says who investigates and how fast.
See the CISA-aligned deployment detail (Sigma rules, scripts) in our CISA cyber decoys guide →, and practise detection triage in the SOC triage tool.
Frequently asked questions
What is cyber deception? Planting fake but believable assets so any interaction with them is a high-confidence sign of an intruder.
What is a honeytoken? A fake credential, key, record or document instrumented to alert the moment it is accessed or used.
Why is it high-fidelity? The asset is designed so no legitimate activity ever touches it, so an interaction is unambiguous — great against living-off-the-land and lateral movement.
How do we start cheaply? Seed a few honeytokens and a canary account wired to SOC alerts with runbooks; expand to decoys later.
Frequently asked questions
How do you use honeytokens and decoys?
Use them as high-fidelity tripwires: plant fake-but-believable assets that no legitimate user should ever touch, so any interaction is a near-certain sign of an intruder. On a budget, start with a few honeytokens (plausible fake credentials, a decoy API key, a tempting document) wired to alert the instant they are used, add an unused privileged-looking "canary" account that should never log in, and place them where an attacker doing reconnaissance would find them (credential stores, file shares, config). Route every hit to your SOC with a clear runbook so it triggers investigation, then expand to full decoy systems/honeypots once the basics prove their signal. They are especially effective against living-off-the-land and lateral-movement activity that otherwise blends into normal traffic.
Why is deception such a high-fidelity signal?
Most detections fight false positives because they infer maliciousness from ambiguous behaviour. Deception inverts this: the asset is designed so that no legitimate activity ever touches it, so an interaction is unambiguous by construction. That makes honeytokens and canary accounts some of the highest-signal, lowest-noise alerts a SOC can deploy, and they are particularly good at catching living-off-the-land and lateral-movement activity that otherwise blends in.
How do we start with deception on a budget?
Start with honeytokens, which cost little: seed a few fake but plausible credentials, an unused "admin" canary account that should never log in, and a decoy document or API key, each wired to alert on use. Place them where an attacker doing reconnaissance would find them (credential stores, file shares, config). Ensure the alerts route to your SOC with clear runbooks so a hit triggers investigation, not confusion.