D3FEND Deceive Tactic: Using Decoys to Expose and Slow Attackers

Most detection controls have to separate attacker activity from a flood of legitimate use, while a well-placed decoy has no legitimate users at all, so any touch is worth investigating. MITRE D3FEND captures this idea in its Deceive tactic, defined as being "used to advertise, entice, and allow potential attackers access to an observed or controlled environment." This hub explains what the tactic covers, lists all 11 Deceive techniques in D3FEND 1.6.0 (checked November 2026) with links to their technique pages, and shows how the two families, Decoy Environment and Decoy Object, fit together. It also sets out where to start, which ATT&CK behaviours D3FEND relates to decoys, and how to measure whether a deception programme is working. It is written for detection engineers, SOC leads and security architects planning or reviewing deception. For the wider framework, see the MITRE D3FEND Guide.

Key takeaways

• Two families, eleven techniques. D3FEND groups Deceive into Decoy Environment (D3-DE, with three honeynet children) and Decoy Object (D3-DO, with six lure children), so the tactic has 2 parents and 9 children.
• Objects are the cheap entry point. Decoy credentials, files and session tokens can be planted in hours on existing hosts; honeynets need build, isolation and upkeep.
• Decoys only work when wired to an alert. D3FEND's own guidance for decoy objects is that any communication with them "should be logged and analyzed"; a lure with no monitoring is clutter.
• ATT&CK relations are inferred. D3FEND links decoys to ATT&CK through shared digital artefacts, and labels those relations inferred and experimental. Several child techniques have none at all.
• Realism decays. Almost every Deceive technique in D3FEND lists continuous maintenance as a consideration: stale personas, expired tokens and untouched files give the game away.

What Deceive means in D3FEND

D3FEND organises defensive techniques under seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict and Restore. Deceive is distinct from Detect. Detect techniques analyse real activity on real assets to find the malicious part. Deceive techniques create assets whose only purpose is to be found by an attacker, so that interaction itself is the signal. The two meet in practice, because a decoy alert is consumed by the same SOC pipeline as any other detection.

The ontology models every Deceive technique around a Decoy Artifact, which D3FEND defines as "an imitation digital artifact" intended to mislead an attacker's surveillance or evaluation, with examples of "fake files, accounts, hosts (honeypots), and network segments (honeynets)." Alternative labels in the ontology are Decoy, Decoy Object, Lure and Trap. Each child technique then states what it spoofs: a file, a credential, a session token, a user, a network resource, a local area network or an intranet network.

Deception buys three things, and a programme should decide which it wants before building anything:

• High-fidelity detection: an early, low-noise alert that someone is inside and exploring.
• Slowing and misdirection: time spent by the attacker on fake assets is time not spent on real ones.
• Intelligence: observed tools, commands and targets, which feed detection content and threat hunting.

For the adversary engagement side, including goals and operational planning, MITRE Engage is the companion framework; see the MITRE Engage Guide.

Every Deceive technique

The table lists all 11 techniques under the Deceive tactic, taken from the D3FEND ontology and tactic page (D3FEND 1.6.0, checked November 2026). Parent techniques D3-DE and D3-DO are the family roots.

D3FEND shows no digital artefact relations for the Decoy Object parent itself; its children each spoof a specific artefact, so the deployment detail lives on the child pages above.

How the two families fit together

Decoy Objects and Decoy Environments are complementary rather than alternatives. D3FEND says so directly in the D3-DUC entry: decoy credentials "should be integrated with a larger decoy environment" so that a stolen decoy credential leads the attacker to a monitored decoy asset. The typical pattern is a breadcrumb trail:

1. Lure: a decoy credential, file or token is placed where an attacker searching a compromised host will find it (credential stores, scripts, shell history, browser profiles, shares).
2. Path: the lure points at a decoy network resource or honeynet host.
3. Observation: the attacker's use of the lure fires an alert, and the decoy environment records what they do next.

Inside the environment family the choice is a risk and realism trade-off that D3FEND spells out in its considerations:

The object family splits by where the lure lives. D3-DF, D3-DUC, D3-DST and D3-DNR live inside the estate and catch post-compromise activity. D3-DP and D3-DPR live outside it, in public channels, and catch reconnaissance and phishing before initial access. External lures carry legal and platform constraints (terms of service for social accounts, consistent public statements) that internal lures do not; the persona and public release pages cover them.

Where to start

The order below is an NHI Mgmt Group view based on effort, risk and signal quality, not a D3FEND ranking.

1. Decide the objective and the alert path first. Name the SOC queue, severity and response runbook for a decoy alert before planting anything. A decoy alert should be treated as a likely intrusion, not as informational.
2. Plant decoy credentials (D3-DUC). Credential theft sits on most intrusion paths, and a decoy domain account or local credential with an authentication alert is cheap to run. On Windows domains, authentication attempts appear in Security events 4624, 4625, 4768 and 4771 on domain controllers or the target host.
3. Add decoy files and tokens (D3-DF, D3-DST). Place them in the paths that credential and data collection tools sweep. Alert on open or read events, or on use of the token at the receiving service.
4. Stand up a small connected honeynet (D3-CHN). A few emulated services in server subnets give the lures somewhere to lead and catch scanning and lateral movement attempts. See the Honeypot deployment guide for placement.
5. Extend to decoy network resources (D3-DNR). Decoy shares and repository paths on real servers catch collection and staging.
6. Consider external lures (D3-DP, D3-DPR). Only with legal sign-off and someone to maintain them.
7. Integrated honeynets last (D3-IHN). Only when isolation, egress control and out-of-band logging are proven.

Testing and rollback: run each decoy in a pilot segment for two to four weeks (an example period, not a standard) to find legitimate tools that touch it, such as backup agents, vulnerability scanners, search indexers and asset discovery. Tune by excluding named service identities, not by suppressing the alert. Removing a decoy is simple: disable the account, delete the file or take down the host, and record the removal so the alert rule is retired at the same time.

Small and large organisations: a small team gets most of the value from a handful of decoy credentials and files plus one emulated host, monitored through existing log tooling. A large estate needs a placement strategy per site and business unit, automated refresh of lures, and a register of every decoy so that IT changes do not break or expose them. Dedicated deception platforms help at that scale; the Deception Technology Buyer's Guide covers evaluation criteria.

ATT&CK techniques D3FEND relates to Deceive

Relationship type: inferred only. D3FEND does not map Deceive techniques directly to ATT&CK. It infers relations when an ATT&CK technique may access or create the kind of artefact a decoy spoofs, and labels them inferred and experimental. The D3-DO page (D3FEND 1.6.0, checked November 2026) shows a long inferred list across persistence, stealth, credential access, collection, lateral movement and initial access. The table groups representative rows from that list; every ID was checked against ATT&CK v20.

D3FEND still lists two inferred rows under IDs that ATT&CK v20 has revoked; their v20 successors are T1690 Prevent Command History Logging and T1685.006 Clear Linux or Mac System Logs. D3FEND lists no ATT&CK relation at all for D3-DPR or D3-DST, and only an ontology-level link for D3-DP, so the technique pages label their own tables as NHI Mgmt Group context. In practice a connected or integrated honeynet observes far more than discovery (scanning such as T1046 Network Service Discovery, login attempts under T1110 Brute Force, and T1021 Remote Services); that is our view of operational coverage, not a D3FEND mapping. For the attacker side, see the ATT&CK Credential Access Tactic Guide and ATT&CK Lateral Movement Tactic.

Where identity fits

Three of the six Decoy Object children spoof identity material: D3-DUC (credentials), D3-DST (session tokens) and D3-DP (a user persona). This extends naturally to non-human identities. A decoy API key, cloud access key or service account secret placed in a code repository, CI variable or configuration file is a D3-DUC or D3-DF lure aimed at the secrets that attackers now hunt first, and use of it at the cloud provider produces a clear audit event. The same pattern applies to tokens planted in AI agent configurations and tool manifests. See the Honeytokens and Canary Credentials Guide and AI Agent Honeytokens and Canaries for deployment. Two cautions: decoy identities must hold no real permissions, and they must be excluded from automated cleanup of dormant accounts, or the identity governance process will quietly delete them.

Detection and measurement

A decoy is only as good as the alert behind it. Monitor these sources:

• Directory and host authentication: logons and Kerberos requests for decoy accounts (Windows Security events 4624, 4625, 4768, 4769, 4771).
• File access: object access auditing (event 4663) or EDR file-open telemetry on decoy files and shares.
• Cloud and SaaS audit logs: any API call made with a decoy key or token.
• Honeynet sensors: connection, login and command logs, shipped off the decoy host so an attacker cannot erase them.
• External channels: mail to persona addresses and requests to tracked URLs from public releases.

Metrics that show the programme is working (example targets are illustrative):

Test decoys the way you test any detection: touch each lure on a schedule from a known test identity and confirm the alert arrives with the right context. The Deception platform health check gives a review routine.

Common failure patterns

• Decoys with no alert route. Lures are planted during a project, the monitoring rule is never deployed or is later broken by a log pipeline change, and the decoy is touched silently.
• Stale realism. Personas that never post, decoy accounts with a 2019 last logon and files nobody has modified are easy for an attacker to spot. D3FEND flags continuous maintenance for most of these techniques.
• Integrated honeynets without containment. D3FEND warns that an attacker controlling an integrated honeynet host may attack connected hosts, eavesdrop or stop the logging processes. Egress controls and out-of-band logging are not optional.
• Over-broad exclusions. Tuning out a whole subnet or tool family to silence scanner noise also hides an attacker using the same tool.
• Decoys with real access. A decoy credential that actually works on a production system turns a lure into an attack path.
• Exposure of the deception platform itself. The management console knows where every decoy is; protect it as a privileged system. See Securing the deception platform itself.

Framework mapping

Practitioner checklist

• State the objective of each decoy: detection, slowing or intelligence.
• Define the SOC route, severity and runbook for decoy alerts before deployment.
• Start with decoy credentials and files on high-value hosts, then add a connected honeynet for them to lead to.
• Give decoy identities no real permissions and exclude them from dormant-account cleanup.
• Pilot each decoy, list legitimate tools that touch it, and exclude named identities only.
• Ship honeynet logs off the decoy host and restrict honeynet egress.
• Keep a register of every decoy, its owner, alert rule and refresh date.
• Test every decoy on a schedule and track the five metrics above.
• Get legal sign-off before any external persona or public release lure.

Standards and references

• MITRE D3FEND: Deceive tactic
• MITRE D3FEND: Decoy Object
• MITRE D3FEND: Decoy Environment
• MITRE ATT&CK: Enterprise Matrix
• MITRE: Engage
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Deception Technology Guide · Deception Technology Deployment Guide · D3FEND Detect Tactic · D3FEND Evict Tactic