A decoy that nobody legitimate should ever touch gives one of the cleanest detection signals a security team can have, but only if the lures are believable, placed on real attack paths and wired to an alert someone answers. MITRE D3FEND groups these lures under Decoy Object (D3-DO), a technique in the Deceive tactic that it defines as an object created and deployed for the purposes of deceiving attackers, with the synonym Lure. This guide is for detection engineers and security architects planning a decoy programme: the six child techniques, how to choose and combine them, where to place them, how to measure them, and where they go wrong. Each child has its own page on this site and the general discipline is covered in the Deception Technology Deployment Guide; this page does not repeat them.
Key takeaways
- Decoy objects have no business purpose. D3FEND's overview says any communication via or to these objects should be logged and analysed for indicators of compromise.
- There are six children. Decoy File, Decoy Network Resource, Decoy Persona, Decoy Public Release, Decoy Session Token and Decoy User Credential.
- Objects are lures, environments are where they lead. D3FEND models Decoy Environment separately, and its Decoy User Credential entry says decoy credentials should be integrated with a larger decoy environment.
- The ATT&CK list is long and inferred. D3FEND relates D3-DO to techniques across most tactics because decoys spoof files, credentials, session tokens and network resources, and labels the mappings inferred and experimental.
- Freshness is the main operating cost. D3FEND's considerations for personas, public releases and session tokens all stress continuous updating so decoys do not go stale.
What D3FEND means by Decoy Object
D3-DO sits under the Deceive tactic beside Decoy Environment. In the ontology each child declares a "spoofs" relation to the artefact it imitates: a File, a Network Resource, a User, a Session Token or a Credential. Decoy Public Release has no artefact relation; it is defined as issuing publicly released media to deceive adversaries.
The split with Decoy Environment matters for planning. A decoy object is something an attacker finds and uses: a document, a share, a credential, a token, a persona or a published identifier. A decoy environment is the system, network or honeynet it leads to. Most programmes need both: objects create the trigger, and an environment gives the attacker somewhere monitored to go. See the MITRE D3FEND Decoy Environment Implementation Guide and the honeynet pages such as D3-IHN Integrated Honeynet.
The child techniques
Every child of D3-DO in the D3FEND ontology, with its purpose from the D3FEND definition and the artefact it spoofs.
| D3FEND technique | Purpose | Spoofs | Where it is found by an attacker |
|---|---|---|---|
| Decoy File (D3-DF) | A file created to deceive an adversary | File | Endpoints, file shares, document stores, code repositories |
| Decoy Network Resource (D3-DNR) | A network resource deployed to deceive an adversary | Network Resource | Web servers, file shares, other network sharing services |
| Decoy Persona (D3-DP) | A fake online identity to misdirect, deceive or interact with adversaries | User | Email, social media and other public profiles |
| Decoy Public Release (D3-DPR) | Publicly released media issued to deceive adversaries | Not modelled | Press releases, videos, marketing material with seeded identifiers |
| Decoy Session Token (D3-DST) | An authentication token created to deceive an adversary | Session Token | Browser stores, memory, configuration and token caches |
| Decoy User Credential (D3-DUC) | A credential created to deceive an adversary | Credential | Credential stores, scripts, configuration files, directory accounts |
The last column is NHI Mgmt Group guidance drawn from the D3FEND "how it works" text and common placement practice.
How to choose and combine the children
Start from the attack path you want to see
| Stage you want to detect | Children that fit | Why |
|---|---|---|
| Reconnaissance of people and the organisation | D3-DP, D3-DPR | Contact with a persona or a seeded identifier happens before any intrusion |
| Credential theft on a compromised host | D3-DUC, D3-DST, D3-DF | Credential dumping and file searching find planted credentials and tokens |
| Discovery and lateral movement | D3-DNR, D3-DUC | Scans and logon attempts reach decoy shares, servers and accounts |
| Collection and staging | D3-DF | Bulk reads of shares and document stores open decoy files |
| Ransomware encryption | D3-DF | Decoy files modified early in an encryption run give an early trigger |
Sequencing
- Internal credential and file lures first. D3-DUC, D3-DST and D3-DF on high-value servers and admin workstations are cheap, have near-zero legitimate use and fire at the credential access stage most intrusions pass through. See the Honeytokens and Canary Credentials Guide.
- Decoy network resources next. D3-DNR on each major network segment. D3FEND's considerations ask for a deployment and placement strategy and warn about resource exhaustion through denial of service.
- External personas and public releases last. D3-DP and D3-DPR need ongoing content work, legal and communications sign-off, and analysts able to engage. They suit organisations with a threat intelligence function.
Combining lures
Lures work best in chains. A decoy file on a file server holds a decoy credential; the credential is valid only on a decoy network resource; that resource sits in a monitored decoy environment. Each step confirms intent and gives analysts time. D3FEND's Decoy User Credential considerations describe exactly this integration, and add that the decoy assets need continuous maintenance to stay credible.
Implementation roadmap
- Define the alert path first. Decide where decoy interactions are logged, which team receives the alert, and the response playbook. A lure with no responder is not a control.
- Inventory placement candidates. List the hosts, shares, directories and repositories an attacker is likely to search, from your threat model and past incidents.
- Make lures believable. D3FEND's Decoy File entry notes that checksums, creation and modification dates, size and owner may be adjusted to improve credibility. Follow local naming conventions.
- Exclude legitimate tooling. Backup, indexing, antivirus and inventory tools touch files and shares. Record their identities and exclude or tune them before alerting goes live.
- Pilot in one segment. Run for at least a month (an example period) with alerts routed to the deception owner only, then tune.
- Roll out by ring. Expand to critical servers, then all servers, then endpoints. Rollback is removing the lures and their detection rules, which should be scripted and recorded so no orphaned decoys remain.
- Test regularly. Trigger each lure type in a controlled exercise and confirm the alert reaches the responder with enough context to act.
Small and large organisations
- Small organisations: a handful of decoy credentials, files and one decoy share, with alerts to an existing SOC or managed detection service, give most of the value.
- Large organisations: automate lure generation and rotation per segment, integrate with a decoy environment, and add personas and public releases where a threat intelligence team can use them.
Where identity fits
Three of the six children are identity artefacts: credentials, session tokens and personas. Decoy service account credentials and decoy API keys are among the most effective lures because attackers actively hunt for non-human credentials in scripts, configuration files and CI variables. Make decoy non-human identities look like the real ones in naming, permissions metadata and location, and ensure the directory or cloud provider logs every authentication attempt against them. See the AI Agent Honeytokens and Canaries guide for decoys aimed at agent credentials, and the MITRE ATT&CK T1552 Unsecured Credentials Guide for the behaviour they catch.
ATT&CK relations D3FEND infers for the parent
The D3FEND page for D3-DO lists offensive techniques across Persistence, Stealth, Execution, Lateral Movement, Collection, Credential Access, Impact, Initial Access, Privilege Escalation, Defense Impairment, Command and Control, Exfiltration and Discovery. It explains the relations through the artefacts D3-DO spoofs (Network Resource, Credential, Session Token and File) and states that the mappings are inferred, experimental and will improve as the knowledge graph grows. The selection below uses ATT&CK v20 IDs and is grouped by tactic; it is a test list, not a coverage claim.
| Tactic | Examples from D3FEND's list | Child most likely to fire |
|---|---|---|
| Credential Access | T1552.001 Credentials In Files, T1552.003 Shell History, T1003.003 NTDS, T1555.003 Credentials from Web Browsers, T1110.003 Password Spraying | D3-DUC, D3-DF |
| Lateral Movement | T1550.004 Web Session Cookie, T1550.001 Application Access Token | D3-DST |
| Collection | T1074.001 Local Data Staging, T1213.002 Sharepoint, T1213.001 Confluence, T1114.001 Local Email Collection | D3-DF, D3-DNR |
| Initial Access | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link | D3-DP |
| Persistence | T1505.003 Web Shell, T1547.001 Registry Run Keys / Startup Folder, T1098.001 Additional Cloud Credentials | D3-DF, D3-DNR |
| Impact | T1565.001 Stored Data Manipulation | D3-DF |
| Defense Impairment | T1556.003 Pluggable Authentication Modules, T1685.006 Clear Linux or Mac System Logs | D3-DF |
D3FEND's page still shows some ATT&CK IDs that v20 has revoked; where a v20 successor exists, such as T1685.006 for the log clearing entry, the table uses it. The child pages list each child's own relations. See the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide for the session token techniques.
Detection and measurement
Every interaction with a decoy object is an alert candidate. Typical signals: an authentication attempt with a decoy credential at the directory or identity provider, use of a decoy session token at the application, a read or modification of a decoy file in file access auditing, a connection to a decoy network resource, and an email or message to a decoy persona. Metrics we suggest at NHI Mgmt Group:
- Placement coverage: percentage of critical servers and segments with at least one decoy object.
- Lure freshness: percentage of decoys refreshed within the planned cycle.
- Alert fidelity: share of decoy alerts that were malicious or authorised tests, versus legitimate tooling.
- Test pass rate: percentage of scheduled lure tests that produced an alert at the responder.
- Time to triage a decoy alert.
- Orphaned decoys: count of lures with no working detection rule, which should be zero.
Framework mapping
| Framework | Reference | Link to D3-DO |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-26 Decoys | Components designed to be the target of attacks for detecting, deflecting and analysing them |
| NIST SP 800-53 Rev. 5 | SC-30 Concealment and Misdirection | Techniques to confuse and mislead adversaries |
| NIST CSF 2.0 | DE.CM-01, DE.CM-03 | Monitoring of networks and of technology usage that decoy interactions feed |
| NIST CSF 2.0 | DE.AE-02 | Analysis of the adverse events a lure produces |
| MITRE D3FEND | Decoy Environment | Where decoy objects lead |
Common failure patterns
- Lures without responders. Alerts land in a queue nobody owns, so the best signal in the estate is ignored.
- Obvious decoys. Default names, fresh timestamps and empty content tell an attacker what to avoid.
- Legitimate tools tripping lures. Backup, search and vulnerability scanners generate noise until the team mutes the rule.
- Stale tokens and personas. Session tokens and personas that never change stop looking like production, as D3FEND's considerations warn.
- Decoy credentials with real access. A lure that authenticates to a production system becomes a backdoor; scope decoys to monitored decoy resources only.
- Forgotten decoys. Lures left behind after a pilot with no detection rule create risk and confusion.
Practitioner checklist
- Define the alert route, owner and playbook before planting any lure.
- Choose children by the attack stage you most need to see.
- Start with decoy credentials, tokens and files on high-value systems.
- Match local naming, metadata and location so lures are credible.
- Exclude backup, indexing and scanning identities before alerting goes live.
- Chain lures to a monitored decoy environment, never to production.
- Refresh tokens, personas and public lures on a fixed cycle.
- Test each lure type on schedule and keep an inventory of every decoy.
Standards and references
- MITRE D3FEND: Decoy Object
- MITRE D3FEND: Decoy User Credential
- MITRE D3FEND: Decoy File
- MITRE D3FEND: Decoy Session Token
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Credentials In Files
- MITRE ATT&CK: Web Session Cookie
Related NHI Mgmt Group resources: Deception Technology Guide · Deception Technology Deployment Guide · Honeytokens and Canary Credentials Guide · Honeypot deployment · MITRE D3FEND Guide