Deception Technology Guide: Honeypots and Canary Tokens

Most intrusions are found late because defenders are trying to pick malicious activity out of a sea of legitimate activity, while deception flips the problem: a decoy has no legitimate use, so anyone who touches it is worth an alert. Deception technology covers honeypots and honeynets, honeytokens and canary files, decoy credentials, deceptive Active Directory objects and fake cloud access keys. This guide explains how each works, where to place them, how to keep alerts high fidelity, how to measure results and what can go wrong. It maps the practice to MITRE D3FEND, MITRE Engage and NIST SP 800-160 Vol. 2 Rev. 1, and is written for SOC leads, detection engineers and identity teams who want early warning of credential theft and lateral movement.

Key takeaways

• Deception detects by exception. A decoy account, file or key has no business use, so a single touch is a strong signal, which makes deception one of the few controls that produces low-volume, high-confidence alerts.
• Credentials are the best bait. Attackers hunt for passwords, service account tickets, API keys and cloud access keys; D3FEND defines a decoy user credential as one "created for the purpose of deceiving an adversary", and those decoys sit exactly where attackers look.
• Start cheap and internal. Honeytoken accounts, canary files and fake AWS keys cost almost nothing to deploy and cover discovery, credential access and lateral movement before you consider a full honeynet or a distributed deception platform.
• Believability is maintenance, not a one-off. D3FEND notes that "Continuous maintenance and updates are needed"; stale decoys that look nothing like production are ignored by attackers and forgotten by defenders.
• Strategy before product. The NCSC's cyber deception trials found that "without a clear strategy organisations risk deploying tools that generate noise rather than insight". Decide which attacker behaviours you want to catch, then place decoys on those paths.

What deception technology is

NIST's glossary, drawing on RFC 4949, defines a honeypot as "A system (e.g., a web server) or system resource (e.g., a file on a server)" that is "designed to be attractive to potential crackers and intruders". NIST SP 800-160 Vol. 2 Rev. 1 lists Deception as a cyber resiliency technique: "Mislead, confuse, hide critical assets from, or expose covertly tainted assets to the adversary", with four approaches: Obfuscation, Disinformation, Misdirection and Tainting. The same publication notes that Deception and Unpredictability are "the cyber resiliency techniques specific to adversarial threats", and places Deception among techniques "not predicated on the assumption of successfully detecting adversity".

MITRE D3FEND groups the defensive techniques under the Deceive tactic, split into decoy environments and decoy objects. MITRE Engage is the companion planning framework: it describes itself as "a framework for planning and discussing adversary engagement operations" and reminds teams that "Deception is a process, not a fire-and-forget technology stack."

Honeypots and honeynets

Honeypots differ in how much of a real system they expose: more interaction yields more intelligence but more cost and risk.

• Honeypot vs honeynet: a honeypot is a single decoy system or service; a honeynet is a network of decoys that lets an attacker move between them. D3FEND distinguishes an integrated honeynet ("setting decoys in a production environment"), a connected honeynet that is "connected to the enterprise network", and a standalone honeynet "created for the purpose of attracting attackers and eliciting their behaviors" in isolation.
• Internal vs internet-facing: internet-facing honeypots see constant opportunistic scanning; they are a threat intelligence feed, not a breach alarm. Internal honeypots should see nothing, so every hit matters. For enterprise detection, start internal.
• Tarpits: a tarpit answers connections very slowly to waste scanners' time; useful at the edge, of little detection value inside.
• Containment: T-Pot's own disclaimer says a compromise "can never be ruled out". Segment honeypots, deny outbound traffic except to the log collector, and never store real data on them. T-Pot also shares captured data with a community backend by default.

Honeytokens, canary files and decoy objects

A honeytoken is any piece of data that should never be used: a document, a database row, a URL, a DNS name, a credential or a configuration file. Canarytokens, an open service maintained by Thinkst, describes them as "like motion sensors for your networks, computers and clouds" and offers token types from Word, Excel and PDF documents to Kubeconfig, SQL Server, AWS API Keys, Azure Entra ID login and MCP Configuration files. Other tools provide equivalents; the patterns are what matter.

• Canary files: a canary file is a decoy document named and placed to look valuable (for example a spreadsheet of VPN accounts in a finance share) that alerts when opened. Most rely on the viewer fetching a remote resource or resolving a unique DNS name, so they can stay silent on an offline machine, in a viewer that blocks external content, or when the file is exfiltrated and opened in a sandbox. Back them with file system auditing on the server (event 4663 with a SACL on the file, or 5145 for share access).
• Database honeytokens: fake customer rows or a decoy table with a trigger or audit rule. Any query returning those rows suggests bulk extraction or SQL injection.
• Canary configuration files: fake credentials, kubeconfig, .env, SSH config or MCP client configuration files on developer machines, jump hosts and build agents.
• Decoy shares and hosts: an SMB share or server with an attractive name that nothing legitimate uses, audited for every access.

Identity deception: honey credentials and decoy keys

Identity decoys deserve most of the effort in an enterprise programme, because credential theft precedes most lateral movement and cloud compromise. D3FEND's Decoy User Credential technique works by building "a detection analytic ... to determine when a user uses decoy credentials", and advises that "Decoy credentials should be integrated with a larger decoy environment" so a stolen decoy leads somewhere monitored.

• Honeytoken accounts in Active Directory: create a dormant account that looks like a privileged or service account (realistic name, description, group membership display, password age) and alert on any authentication: 4624 and 4625 logons, 4768 TGT requests and 4771 pre-authentication failures. Microsoft Defender for Identity offers a Honeytoken tag (Settings > Identities) for users and devices: "Any sign-in from a honeytoken account triggers an alert."
• Honey service principal names: register an SPN on a decoy account so Kerberoasting tools request a ticket for it. ATT&CK's detection guidance for T1558.003 looks for "anomalous Kerberos TGS requests (Event ID 4769) with RC4 encryption (etype 0x17)"; a 4769 for the decoy SPN needs no anomaly model at all. Give the account a long random password that cannot be cracked.
• Deceptive AD objects: decoy computer objects, groups and accounts that appear on attack paths drawn by directory reconnaissance tools. Set a SACL so reads of selected attributes on the decoy generate 4662 (directory service access) events; reconnaissance across the directory then shows up as access to objects nobody legitimately queries.
• Lures in memory and on disk: cached credentials, saved RDP connections or scripts that reference the decoy account, planted on endpoints so credential dumping and file searching return it.
• Cloud decoy keys: an AWS access key belonging to an IAM user with no permissions, placed in a credentials file, CI variable or private repository. Alert on any CloudTrail event containing that access key ID. The Canarytokens AWS key token works this way and warns that the logging path "may introduce a delay of between 2 and 30 minutes". Exposed .env files fed the 230 Million AWS Cloud Environments campaign, and the TruffleNet campaign tested stolen AWS keys at scale: a decoy key in those locations turns key harvesting into an alert.
• Fake API keys and tokens: decoy SaaS API keys, personal access tokens and session cookies (D3-DST) issued with no privileges but full logging. Keep a register so a decoy is never mistaken for a real leak during secret scanning, and tell the secret scanning team which values are decoys.

Decoy non-human identities need the same hygiene as real ones: an owner, a record of where each copy is planted, zero permissions and a rotation plan if a decoy is burned. See the Service Account Security Guide, the API Key Management Guide and the Secrets Management Guide. For directory attack paths see the Active Directory and Entra ID Hardening Guide.

Choosing an approach

• Small organisations: a handful of honeytoken accounts, a fake AWS key on each admin workstation and in the main repository, and canary documents in the finance and HR shares, all alerting to the managed SOC or a monitored mailbox.
• Large organisations: a deception plan per network zone and cloud account, decoys deployed through configuration management, alert routing into the SIEM with dedicated playbooks, and regular red team validation. See the Detection Engineering Guide.

Deploying deception step by step

1. Define what you want to catch: list the attacker behaviours that worry you most (credential dumping, Kerberoasting, share crawling, cloud key theft, lateral movement into a crown jewel segment) and the gap each decoy fills. The NCSC advises organisations to "identify strategic gaps before choosing a product".
2. Agree the rules of engagement: who knows about the decoys (a small group in the SOC, identity and legal), how alerts are handled, what data may be captured, and that decoys never contain real personal or business data.
3. Build the register: every decoy gets an ID, owner, location, trigger mechanism, alert route and review date.
4. Make it believable: follow local naming conventions, set realistic descriptions and timestamps, and give accounts some history. MITRE Engage lists activities such as Pocket Litter and Burn-In for exactly this purpose.
5. Pilot in one zone: deploy to a single domain, subnet or cloud account. Run for two to four weeks with alerts going to the detection team only, and record every hit.
6. Remove legitimate noise: identify scanners, backup agents, search indexers and admin tools that touch decoys, and fix them at the source (scope the scanner) rather than suppressing the decoy alert broadly.
7. Validate: have the red team or a purple team exercise use the decoys: dump credentials, Kerberoast, crawl shares, try the fake key. Confirm every alert arrives in the SIEM within the expected time.
8. Go live and expand: route alerts to the SOC with a playbook, then extend zone by zone.
9. Rollback: each decoy can be disabled or deleted individually from the register; a decoy that causes operational problems (for example a service trying to use it) is withdrawn while the cause is fixed.

Alert fidelity, response and monitoring

A decoy alert should be treated as a probable intrusion until proven otherwise, and the playbook should say so. The response starts with the source: which host or identity touched the decoy, what it did before and after, and whether any real credentials from the same location have been used.

• Enrich, then act fast: attach host owner, account type and recent activity to the alert. For a decoy credential, check whether real credentials stored alongside it have been used, and reset them. See the Leaked Credential Response Playbook.
• Protect the logging path: decoys are only as good as the telemetry behind them; monitor for silent sources and log tampering. See the SIEM Guide.
• Do not tip off: contain the source host or identity rather than visibly changing the decoy.

The NCSC trials found that "outcome-based metrics were not readily available and require development", so define your own from the start:

• Coverage: share of priority zones, domains and cloud accounts with each planned decoy type live.
• Time to alert: from decoy touch to SOC alert, measured in validation exercises (cloud key alerts include provider logging delay).
• Alert precision: share of decoy alerts that were malicious or authorised testing, against benign tool noise; target well above other rule sets.
• Red team detection rate: share of exercises in which at least one decoy fired, and how early in the kill chain.
• Decoy health: share of decoys that passed their last validation test and review date.

Legal, ethical and operational safety

• Stay on your own estate: deception for detection uses decoys on infrastructure you own or control. Never hack back, and contain honeypots so they cannot attack third parties.
• Personal data still counts: honeypot logs hold IP addresses, usernames and sometimes typed content. Apply your data protection and retention rules.
• No real data in decoys: fake documents and rows must be synthetic, so a leak of a decoy never becomes a reportable breach.
• Insider cases: agree evidence handling with legal before deployment, because a decoy that catches an employee feeds an HR process.
• Secrecy: 90% of NCSC trial participants said they would not publicly announce their use of deception because they "don't want to tip off attackers". Keep the register on a need-to-know basis.

Framework mapping

Common failure patterns

• Set and forget: decoys deployed once, never validated, with alerts going to a mailbox that nobody reads after the project lead leaves.
• Obviously fake decoys: accounts called honeypot01, honeypots with default banners, or documents with no plausible content. Attackers who spot one decoy grow careful everywhere.
• Decoys that create real risk: a "decoy" account with real permissions, or a honeypot with outbound internet access. The NCSC warns that "misconfiguration can introduce new vulnerabilities".
• Broad suppression: a backup or scanning service account is excluded from all decoy alerts to stop noise, and the attacker who steals that account is invisible.
• Decoy keys mistaken for leaks, or leaks mistaken for decoys: without a register, secret scanning teams waste incident time on decoys, or dismiss a real exposed key as "probably a canary".
• Internet honeypot data treated as breach detection: noisy external hits swamp the SOC and train analysts to ignore anything labelled deception.

Practitioner checklist

• Write down the attacker behaviours and zones the deception programme must cover.
• Deploy honeytoken accounts and a honey SPN in every AD domain, with alerts on 4624, 4625, 4768 and 4769.
• Plant permissionless decoy cloud keys in repositories, CI variables and admin workstations, alerting on CloudTrail or equivalent.
• Place canary documents and decoy shares in high-value file stores, backed by file auditing.
• Keep a decoy register with owner, location, trigger, alert route and review date.
• Segment and egress-filter every honeypot; never store real data on decoys.
• Give decoy alerts a dedicated SOC playbook that contains the source, not the decoy.
• Validate every decoy with red or purple team exercises at least twice a year.
• Track coverage, time to alert, precision and red team detection rate.

Standards and references

• MITRE D3FEND: Deceive tactic
• MITRE D3FEND: Decoy User Credential (D3-DUC)
• MITRE Engage: Engage Matrix
• NIST: SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems
• NCSC: Cyber deception trials, what we've learned so far
• MITRE ATT&CK: T1558.003 Kerberoasting
• Microsoft Learn: Defender for Identity entity tags (Honeytoken)
• Canarytokens: AWS API Keys token

Related NHI Mgmt Group resources: ITDR Guide · Service Account Security Guide · Secrets Management Guide · Lateral Movement Guide · Incident Response Guide