Honeytoken Placement Planner: Where to Plant Decoys

TL;DR

What this tool is

Pick your environments (Active Directory, AWS, Azure, Google Cloud, code repos and CI, SaaS and Microsoft 365, databases, file shares, endpoints) and the attacker behaviours you most want to catch.
Get a placement plan drawn from 20 honeytokens and decoys: fake cloud keys, a Kerberoasting lure account, canary admin users, decoy shares, beacon documents, DNS canaries, fake database rows and more.
Each placement says where to put it, what fires the alert, the exact log or Windows event you need, the false-positive risk and how to keep it believable but unused.
A coverage score shows how well the plan covers each behaviour you chose, and which environment would close a gap.
Copy the plan as plain text with owner and test fields, a do-not list and a rollout checklist based on CISA’s September 2026 decoy guidance. Runs in your browser; nothing is uploaded.

Every honeytoken placement in the planner

The planner covers 9 environments and 6 attacker behaviours (credential theft, lateral movement, discovery and recon, data discovery and exfiltration, cloud key abuse, insider browsing). Here is the full list it draws from, with where each one goes, what fires the alert and the telemetry you need.

Fake AWS access key in a credentials or config file

Catches: Credential theft, Lateral movement (partly), Cloud key abuse.
Where: An ~/.aws/credentials profile on an admin jump host or build server, a .env file in an internal repository, or a deployment script on a file share. Name the profile like your real ones (for example "prod-backup").
Alert fires on: Any AWS API call signed with the key, including calls that are denied.
Telemetry: CloudTrail. Create the key on a dedicated IAM user with no permissions, then alert on any event whose userIdentity.accessKeyId is the decoy key ID (an EventBridge rule or a SIEM search). Denied calls are logged with an AccessDenied error code. Alerts are not instant: CloudTrail delivery takes minutes. A few AWS API calls are not recorded by CloudTrail, so a careful attacker can sometimes test a key quietly.
False-positive risk (low): Low in private locations. A key in a public repository or public bucket is found by automated scanners and provider secret-scanning programmes, so expect alerts that have nothing to do with an intruder in your network.
Believable but unused: Put it beside the real config it imitates, give the file a plausible modified date, and keep the IAM user permission-free. No script, pipeline or person may ever use it.

Decoy cloud key stored as a CI/CD secret variable

Catches: Credential theft, Cloud key abuse.
Where: A repository or project-level secret in your CI system (for example a GitHub Actions secret or a GitLab CI/CD variable) named like a deploy credential, such as DEPLOY_AWS_ACCESS_KEY_ID, in a project that has real pipelines.
Alert fires on: Anyone who dumps pipeline secrets (a compromised runner, a malicious pull request workflow, a stolen maintainer token) and then tries the key.
Telemetry: The cloud provider’s audit log for the decoy identity: CloudTrail for an AWS key, Entra ID service principal sign-in logs for an Azure secret, Cloud Audit Logs for a Google Cloud key. Same alert as a file-based decoy key.
False-positive risk (medium): Your own pipelines must never reference the variable. Secret scanners and CI security tools may list it in findings; tell the AppSec owner so it is not "fixed" by deletion.
Believable but unused: Use the same naming pattern as real secrets and create it in a project people actually work in. Never wire it into a job.

Decoy Entra ID app registration credential

Catches: Credential theft, Cloud key abuse.
Where: A client ID and client secret (or certificate) for a decoy app registration, left in an appsettings.json, a script, a Key Vault or a CI variable. Name the app like an automation account ("backup-automation-prod").
Alert fires on: Any sign-in attempt by the service principal.
Telemetry: Entra ID service principal sign-in logs, exported with diagnostic settings to Log Analytics or your SIEM. Alert on any row for the decoy application ID.
False-positive risk (low): Low, provided no automation ever uses the app. Watch for clean-up scripts that flag unused apps and delete them.
Believable but unused: Give the app a plausible owner and description, but no API permissions and no role assignments.

Decoy Google Cloud service-account key file

Catches: Credential theft, Cloud key abuse.
Where: A JSON key file for a decoy service account, in a developer tools folder, an internal repo or a build server.
Alert fires on: Authentication with the key and any API call it makes.
Telemetry: Cloud Audit Logs routed to your SIEM with a log sink. Admin Activity logs are always on; Data Access logs are off by default for most services, so give the account read access to one decoy bucket in an isolated project, enable Data Access logs there, and test that a call with the key produces the log line you alert on.
False-positive risk (low): Low. Key-age and unused-key reports will flag it; record it in the decoy register so nobody deletes it.
Believable but unused: Name the service account after a plausible workload. No roles beyond the decoy bucket.

Decoy AD service account with an SPN (Kerberoasting lure)

Catches: Credential theft, Discovery and recon (partly).
Where: A user account in Active Directory with a service principal name that looks like a real service (for example MSSQLSvc on a plausible host name), placed in the same OU as your real service accounts.
Alert fires on: A Kerberos service-ticket request for that SPN. Kerberoasting tools request tickets for every SPN they find, and nothing legitimate ever requests this one.
Telemetry: Windows event 4769 (A Kerberos service ticket was requested), logged only on domain controllers and only with "Audit Kerberos Service Ticket Operations" enabled. Alert when Service Name is the decoy account. If you run Microsoft Defender for Identity, you can also tag the account with its Honeytoken tag.
False-positive risk (low): Low to medium: AD assessment tools and vulnerability scanners that enumerate SPNs will request tickets. Allow-list those scanner hosts by source address, and tell the team that runs them.
Believable but unused: Give it a long, random, never-used password so a cracked ticket yields nothing, a plausible description and an old-looking creation history if you can. Never add it to a privileged group and never run a service as it.

Canary admin-looking user account that never signs in

Catches: Credential theft, Lateral movement, Discovery and recon (partly).
Where: A user named to your admin naming convention (for example adm-jsmith2) in AD or Entra ID. CISA’s guidance gives "fake, low-privilege accounts across systems" where any authentication attempt alerts.
Alert fires on: Any authentication attempt, failed or successful: password spraying, a stolen-credential test, or lateral movement with credentials the attacker found.
Telemetry: Alert on any authentication by the decoy account. On domain controllers: 4768 (Kerberos TGT requested), 4771 (Kerberos pre-authentication failed) and 4776 (NTLM credential validation). On member hosts: 4624 (logon) and 4625 (failed logon). For cloud-synced accounts, also alert on any row for the account in the Entra ID sign-in logs, failed or successful.
False-positive risk (medium): If the account can sign in from the internet, password-spray noise against your tenant will hit it. Treat those as lower priority than an internal source, or exclude the account from external sign-in with Conditional Access and alert on the block.
Believable but unused: A realistic display name, description, manager and group memberships that look interesting but grant nothing. Never add it to a real privileged group.

Fake password breadcrumb on a decoy AD account

Catches: Credential theft (partly), Lateral movement (partly), Discovery and recon.
Where: A "temporary password" written in the description field of the canary account, or in a decoy helpdesk note. Attackers who enumerate AD read descriptions; this leads them to try the canary account.
Alert fires on: The fake password being tried, which fires the canary account alert.
Telemetry: The canary account alerts (4768, 4771, 4776, 4624, 4625). Optionally, Windows event 4662 (An operation was performed on an object) shows who read the object, but only with "Audit Directory Service Access" enabled and a SACL on the object, and many legitimate tools read AD, so treat 4662 as context, not the alert.
False-positive risk (low): Low for the logon alert. High if you alert on reads of the object.
Believable but unused: Mimic the way real (bad) notes look in your directory. The password must not work anywhere.

Decoy saved credentials on endpoints

Catches: Credential theft, Lateral movement.
Where: A saved RDP connection file, a Windows Credential Manager entry, or a script with a "service" username and password on a sample of workstations and jump hosts, pointing at the canary account or a decoy host. CISA’s guidance gives "planting fake admin-only credentials; any use signals compromise".
Alert fires on: The credentials being used to sign in anywhere.
Telemetry: The canary account alerts. If the credential points at a decoy host, also alert on any connection to that host.
False-positive risk (low): Low. An administrator who finds it during clean-up may test it; brief the desktop team.
Believable but unused: Deploy with your endpoint management tool so placement is consistent and recorded. Use host names that fit your naming scheme.

Decoy file share

Catches: Discovery and recon, Data discovery and exfiltration, Insider browsing (partly).
Where: A share with a tempting, plausible name (for example \\fs02\Finance-Archive) on a real file server, filled with realistic but non-sensitive files. CISA’s scenario uses shares mimicking current projects and tells legitimate users not to open them.
Alert fires on: Anyone listing or opening files in the share.
Telemetry: Windows event 5145 (A network share object was checked) on the file server, with "Audit Detailed File Share" enabled; alert on the decoy share name. Or 4663 with a SACL on the folder and "Audit File System" enabled.
False-positive risk (medium): Backup jobs, antivirus scans, search indexing and data-discovery scanners touch everything. Exclude their service accounts by name, not the share.
Believable but unused: Folder names, file names and dates that look lived in. Refresh a few files each quarter.

Decoy documents that beacon when opened

Catches: Discovery and recon (partly), Data discovery and exfiltration, Insider browsing.
Where: Word, Excel or PDF files with tempting names ("2027 salary bands", "VPN passwords") inside the decoy share, an executive’s OneDrive, or a project folder.
Alert fires on: The document being opened, wherever it is opened, including after it has been copied out of your network.
Telemetry: The beacon calls a URL or resolves a hostname you control; alert on that request. You do not need your own log pipeline if you use a hosted token service.
False-positive risk (medium): Mail and file sandboxes, preview services and DLP engines may open files and fire the beacon; check the source of the callback. It will not fire if the file is only copied, or opened offline or in a viewer that blocks external content.
Believable but unused: Real-looking content with no real data. One token per placement, so the alert tells you which copy was opened.

DNS canary hostname

Catches: Credential theft (partly), Lateral movement (partly), Discovery and recon.
Where: A unique hostname in a subdomain you control, embedded in a config file, a connection string, a hosts list, an old runbook or a database connection table.
Alert fires on: Anything resolving the name: an attacker testing a connection string, a scanner, a tool following a config.
Telemetry: Query logs on the authoritative DNS server for that zone, or query logging on your internal resolvers. The source you see is often a resolver, not the attacker’s host.
False-positive risk (medium): Security tools, link scanners and resolvers that prefetch names can resolve it. Use it as an early signal and correlate with endpoint logs.
Believable but unused: Make the hostname fit your naming scheme (db-replica-03.<your decoy zone>). Never reference it in anything that runs.

Fake customer records with a monitored email address

Catches: Data discovery and exfiltration, Insider browsing (partly).
Where: A few rows in your customer or CRM tables, each with a unique email address in a mailbox only the security team reads.
Alert fires on: Mail arriving at that address from anyone other than you, or the record appearing outside your systems. That means the data has left and is being used.
Telemetry: The monitored mailbox. Alert on any inbound message that is not from your own systems.
False-positive risk (medium): Your own marketing, CRM sync and processors may email it. Suppress it from every legitimate mailing using a flag kept outside the table, and record which processors legitimately hold the data.
Believable but unused: Realistic names and order history. Different records in different systems, so the alert tells you which system leaked.

Decoy database table with read auditing

Catches: Discovery and recon, Data discovery and exfiltration, Insider browsing.
Where: A table with a tempting name (for example payment_cards_legacy or users_backup) in a production database, with realistic fake rows.
Alert fires on: Any SELECT on the table.
Telemetry: Database auditing on that one object: a database audit specification for SELECT in SQL Server Audit, object-level auditing with the pgaudit extension in PostgreSQL, or your managed database’s audit log. Ship the audit log to your SIEM.
False-positive risk (medium): Backup tools, schema crawlers, data catalogues and BI jobs that read every table will fire it. Exclude their identities.
Believable but unused: Columns and row counts that match the name. No real data.

Decoy cloud storage bucket or container

Catches: Discovery and recon (partly), Data discovery and exfiltration, Cloud key abuse (partly).
Where: A private bucket or blob container with a tempting name ("prod-db-backups-2026") in a real account, holding realistic decoy files.
Alert fires on: Any object read (and, more noisily, any listing).
Telemetry: Object-level logs, which are off by default on all three clouds. AWS: enable CloudTrail data events for that bucket (or S3 server access logging) and alert on GetObject. Azure: send Storage resource logs (StorageBlobLogs) to Log Analytics with a diagnostic setting and alert on reads. Google Cloud: enable Data Access audit logs for Cloud Storage and alert on object reads.
False-positive risk (medium): Cloud posture and inventory tools list every bucket; alert on object reads, not listings. Keep it private: a public bucket attracts internet scanners.
Believable but unused: A name that matches your conventions and files with plausible sizes and dates.

Decoy secret in a secrets manager

Catches: Credential theft, Discovery and recon (partly), Cloud key abuse (partly).
Where: A secret named like a high-value credential ("prod-db-root") in AWS Secrets Manager, Azure Key Vault or Google Secret Manager. Its value is another decoy (the canary account or a decoy key), so you get a second alert when it is used.
Alert fires on: Anyone reading the secret value.
Telemetry: The read event for that secret. AWS: GetSecretValue in CloudTrail; alert on the decoy secret’s ARN. Azure: Key Vault AuditEvent logs via a diagnostic setting; alert on SecretGet for the decoy secret. Google Cloud: enable Data Access audit logs for Secret Manager and alert on AccessSecretVersion for the decoy secret.
False-positive risk (medium): Backup, rotation and inventory tooling may read every secret. Exclude those identities.
Believable but unused: Tags and a description like the real secrets around it. No application reads it.

Fake internal API token in a repository

Catches: Credential theft, Lateral movement (partly).
Where: A token for one of your own internal APIs in an old config sample, a test fixture or a past commit of an internal repository.
Alert fires on: Any request carrying the token.
Telemetry: Your API gateway or WAF logs: make the token valid-looking, map it to a decoy client ID that is denied, and alert on any request presenting it.
False-positive risk (low): Low. Secret scanners will flag it; record it so AppSec does not rotate or purge it.
Believable but unused: Use the real token format, prefix and length.

Decoy host and listening services

Catches: Lateral movement, Discovery and recon.
Where: A low-interaction honeypot on a production VLAN offering services that fit the segment (SMB, RDP, SSH, a database port), or unused address space routed to a sinkhole. Both are examples in CISA’s guidance.
Alert fires on: Any connection attempt. Nothing legitimate talks to it.
Telemetry: The honeypot’s own logs forwarded to your SIEM, or firewall logs for the sinkhole range.
False-positive risk (medium): Vulnerability scanners, asset discovery and monitoring probes will touch it. Allow-list their source addresses.
Believable but unused: A host name, OS banner and open ports that match its neighbours. Point the decoy saved credentials at it.

Decoy tool or command on non-technical workstations

Catches: Credential theft (partly), Discovery and recon.
Where: A network-scanning or admin utility on the workstations of people who never use one. CISA’s guidance gives "placing a fake network-scanning tool on a nontechnical user’s workstation" as an example.
Alert fires on: The tool being executed.
Telemetry: Process-creation events from your EDR, Sysmon or Windows event 4688 (with command-line auditing). Alert on that executable name or hash on that group of machines.
False-positive risk (low): Low on non-technical machines. IT staff using the same machine for support may run it; brief the service desk.
Believable but unused: A plausible install path and file name.

Decoy file or site in SharePoint / OneDrive

Catches: Discovery and recon (partly), Data discovery and exfiltration, Insider browsing.
Where: A file with a tempting name ("Board remuneration 2027.xlsx") in a broadly shared SharePoint site, or decoy folders in executives’ OneDrive. CISA’s guidance gives decoy folders on executive desktops as an example.
Alert fires on: The file being opened or downloaded.
Telemetry: Microsoft Purview audit log activities FileAccessed and FileDownloaded for that file, exported to your SIEM. A beacon document gives a second, independent signal.
False-positive risk (medium): Enterprise search and AI assistants surface files people can access, so curious staff will find it. Decide in advance, with HR and legal, what a hit by an employee means.
Believable but unused: Place it where similar real files live, with a plausible author and date.

Decoy credentials in a mailbox

Catches: Credential theft, Insider browsing (partly).
Where: An email in a high-risk mailbox (for example an executive who often fails phishing tests) containing apparent credentials for the canary account or a decoy portal. CISA’s scenario does exactly this and tells the mailbox owners to keep but never use them.
Alert fires on: Someone who has read the mailbox trying the credentials.
Telemetry: The canary account alerts, or the decoy portal’s login log.
False-positive risk (low): Low once the mailbox owner is briefed. Their assistant or delegate may try it; brief them too.
Believable but unused: Make it look like a real IT or vendor message from your environment.

What not to do

Never use a real credential, and never give a decoy real privileges or real data. A decoy that works is a backdoor.
Never deploy a token without a named owner and a recorded location. Keep the register outside the production environment, as CISA advises, so an intruder cannot read it.
Never use the same token in two places. One token per placement, so the alert tells you where it was found.
Never reference a decoy from a script, pipeline or job. If something you run touches it, the signal is gone.
Never use decoys to monitor employees without legal, HR and privacy review first. Rules on workplace monitoring differ by country and contract.
Never bait people with personal lures. Place lures where only someone with no business reason would look.
Never put a decoy in a public repository or public bucket unless you want internet noise.
Never use a decoy to trace back into, or act against, someone else’s systems. Alert, investigate, respond.
Do not treat decoys as your only detection. A careful attacker may avoid them; they add to logging and EDR, they do not replace them.

Rollout checklist

Agree the objective and scope in writing with the CISO, IT and legal (CISA’s scenario consults legal counsel before defining the objective). Add HR and privacy if any decoy could catch an employee.
Turn on the telemetry first: the audit policies, data events and diagnostic settings listed for each token. Confirm the logs reach your SIEM.
Create the decoys in a maintenance window. Record each one: owner, location, token ID, expected alert and expected benign touchers.
Trigger every decoy yourself once and confirm the alert arrives in the right queue at the right priority. CISA’s guidance tests each decoy after deployment.
Write a one-page runbook per alert: who investigates, how fast, the first three steps (identify the source host and account, contain, preserve evidence).
Allow-list known benign touchers (scanners, backup, indexing) by identity or source address, never by muting the decoy.
Restrict detailed decoy information to the people who need it; brief leadership on objectives only.
Test the whole chain with threat emulation, a red team or a purple team, as CISA recommends.
Review every quarter: still believable, still unused, logs still flowing, owner still in post. Retire decoys cleanly and remove them from the register.

The checklist follows CISA’s Using Cyber Decoys to Strengthen Detection and Response (September 2026), which recommends starting with tripwires and honeytokens before honeypots, and adds common practice. To practise turning a decoy hit into a reliable alert, write and tune the rule in the Detection Lab.

Frequently asked questions

What are honeytokens?

A honeytoken is fake data planted as a tripwire: a decoy credential, cloud access key, database record, document or hostname that no legitimate process ever uses. Because nothing normal touches it, any use is a strong sign that someone is inside and looking. CISA’s 2026 guidance defines honeytokens as data elements or logical objects with no legitimate business use, planted to detect unauthorized access or exfiltration.

Where should I place honeytokens?

Where an attacker doing a specific step will look: fake cloud keys in credentials files, scripts and CI variables (credential theft and cloud key abuse); a decoy service account with an SPN in Active Directory (Kerberoasting); saved credentials on jump hosts pointing at a canary account (lateral movement); decoy shares, tables and documents with tempting names (data discovery and exfiltration). Choose your environments and behaviours in the planner above for a specific list.

How do honeytokens detect Kerberoasting?

Create a user account with a service principal name (SPN) that no service uses. Kerberoasting tools request service tickets for every SPN they find, so a ticket request for the decoy SPN only happens during an attack. Domain controllers log it as Windows event 4769 (A Kerberos service ticket was requested) when "Audit Kerberos Service Ticket Operations" is enabled. Give the account a long random password and no privileges, so a cracked ticket yields nothing.

What does CISA recommend about honeytokens and cyber decoys?

CISA’s "Using Cyber Decoys to Strengthen Detection and Response" (September 2026) recommends starting with lower-complexity techniques such as tripwires and honeytokens, planning decoys with MITRE Engage and ATT&CK, testing that each decoy alerts, keeping decoy location records outside the production environment, and testing the whole operation with threat emulation, red teaming or purple teaming. It is voluntary guidance and does not create requirements.

Are there free honeytoken tools?

Yes. Thinkst Canarytokens (canarytokens.org) is free and offers token types including AWS API keys, DNS, MS Word, MS Excel, Adobe PDF, Windows directory, SQL Server, Kubeconfig and unique email addresses. OpenCanary is Thinkst’s open-source network honeypot. If you already run Microsoft Defender for Identity, it can tag an account as a honeytoken. Many placements also work with logs you already have, such as CloudTrail and Windows security events.

Can I use honeytokens to catch insiders?

You can, but get legal, HR and privacy review first. Rules on monitoring employees differ by country and employment contract, and a decoy that an employee opens out of curiosity needs a pre-agreed response. Place lures where only someone with no business reason would look, never bait individuals with personal lures, and decide in advance what a hit by an employee means.