Intruders read, copy, stage and delete files long before they reach their goal, yet most environments cannot tell a legitimate file access from a hostile one. D3-DF Decoy File is the MITRE D3FEND countermeasure that changes that: D3FEND defines it as "a file created for the purposes of deceiving an adversary". It sits in the Deceive tactic under the parent technique Decoy Object, and D3FEND models it as something that spoofs the File artefact. Because no legitimate user or process has a reason to touch a well-placed decoy, any access is a high-confidence signal. This card covers how decoy files work, which ATT&CK techniques D3FEND relates them to, how to deploy and monitor them on Windows and Linux, how to verify they fire, and where they fail. It is for detection engineers and security operations teams building low-noise tripwires.
Key takeaways
- Any touch is the signal. A decoy file has no business use, so a read, write, rename or delete on it is worth an alert with very little tuning.
- Credibility decides success. D3FEND notes that checksums, creation and modified dates, size and owner may be adjusted so the decoy looks real; a decoy that looks planted is skipped.
- Monitoring is the control, not the file. Without object access auditing (Windows event 4663 with a SACL) or a Linux audit watch, a decoy is just clutter.
- Credential-bearing decoys bridge two signals. A decoy configuration file holding a fake key or password alerts on access and again when the fake secret is tried, which covers non-human identity theft paths well.
- Verify on a schedule. Decoys silently stop working when audit policy, paths or agents change, so test each one regularly.
D3-DF at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DF (d3f:DecoyFile) |
| Tactic | Deceive |
| Parent technique | Decoy Object |
| Digital artefact | File (D3FEND relation: spoofs File) |
| What it changes | Adds files with no legitimate use to hosts or shares, and monitors any access to them |
| Typical data sources | Windows Security log (4663, 4656), Linux audit log, EDR file telemetry, file share audit logs, cloud storage access logs |
| Typical tooling categories | Native OS auditing plus SIEM rules, EDR custom detections, deception platforms, canary token services |
| Effort | Low for a handful of decoys with native auditing; moderate to keep many decoys credible and verified |
| Main limitation | Only detects adversaries who touch the decoy; legitimate indexing, backup and antivirus scans cause benign hits |
This card goes deeper than D3FEND's parent technique, Decoy Object; for the programme view, see the Deception Technology Guide.
How it works
D3FEND's article describes the mechanism in three parts. The decoy file is made available as a local or network resource. Accesses to it may be monitored. The files may be configurations, documents, executables or other file types. Its worked example is a CSV file containing decoy user credentials placed on a system, with the system or network then watched for any access.
A practical deployment combines three elements:
- Placement: where an intruder will look. Discovery activity (ATT&CK T1083 File and Directory Discovery) and collection (T1005 Data from Local System, T1119 Automated Collection) sweep user profiles, admin shares, deployment folders and configuration directories, so decoys belong there.
- Bait content: names and contents that match what attackers want: password exports, VPN profiles, cloud credential files, finance spreadsheets, backup configurations. The content should be plausible but never contain a real secret.
- Telemetry: an audit rule on the file that records who accessed it, with which process and what kind of access. Some decoys add a second channel: a fake credential inside the file that alerts when used, or a document that calls out to a monitored URL when opened.
Where identity fits
Credential-bearing decoys are where D3-DF meets identity security. Attackers search hosts for secrets in files (T1552.001 Credentials In Files), shell history (T1552.003) and browser stores (T1555.003), and stolen service account passwords, API keys and cloud access keys are among the most valuable finds. A decoy configuration file with a fake cloud key, a deployment script with a fake service account password, or a decoy SSH config gives two alert points: the file read, then any authentication attempt with the fake credential. The credential half is a separate D3FEND technique, Decoy User Credential (D3-DUC); the token-based variants are covered in the Honeytokens and Canary Credentials Guide and, for agent workloads, AI Agent Honeytokens and Canaries.
ATT&CK techniques D3FEND relates to D3-DF
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DF; every row below is inferred through a shared digital artefact (checked November 2026).
D3FEND does not hand-map D3-DF to ATT&CK. Every row below is an inferred relationship that D3FEND derives through a shared digital artefact: a decoy file spoofs File, so ATT&CK techniques that act on a File, or on one of its sub-artefacts such as Archive File or Executable File, are related to it. The relation column shows which. Because so many techniques read or write files, the full D3FEND list runs to more than 100 ATT&CK techniques and sub-techniques; the table is a selection chosen where a decoy file gives a realistic detection opportunity. Each ID was checked against ATT&CK v20. D3FEND still lists two techniques under IDs that ATT&CK v20 has revoked; their successors are T1690 Prevent Command History Logging and T1685.006 Clear Linux or Mac System Logs, which a decoy history or log file can also expose.
| ATT&CK ID | Name | D3FEND relation (inferred via artefact) | Decoy file opportunity |
|---|---|---|---|
| T1083 | File and Directory Discovery | Same artefact: accesses File | Enumeration that opens decoys in browsed folders |
| T1552.001 | Unsecured Credentials: Credentials In Files | Same artefact: accesses File | Fake password or key files are read |
| T1552.003 | Unsecured Credentials: Shell History | Sub-artefact: Command History Log File | A decoy history file with a fake secret is read |
| T1555.003 | Credentials from Password Stores: Credentials from Web Browsers | Sub-artefact: Database File | Decoy browser credential store in an unused profile is opened |
| T1003.008 | OS Credential Dumping: /etc/passwd and /etc/shadow | Sub-artefact: Password File | A decoy copy of shadow content in a backup path is read |
| T1074.001 | Data Staged: Local Data Staging | Same artefact: may-create File | Decoys are copied into a staging folder |
| T1560.001 | Archive Collected Data: Archive via Utility | Sub-artefact: Archive File | An archiver process reads decoys while compressing |
| T1114.001 | Email Collection: Local Email Collection | Sub-artefact: Email | A decoy mailbox file (for example a PST) is opened |
| T1070.004 | Indicator Removal: File Deletion | Same artefact: deletes File | Deletion of decoys placed among tools or logs (DELETE right in 4663) |
| T1036.005 | Masquerading: Match Legitimate Resource Name or Location | Same artefact: may-create File | Decoy binaries in expected locations show tampering or replacement |
| T1036.006 | Masquerading: Space after Filename | Same artefact: creates File | Writes of look-alike names beside decoys in monitored folders |
| T1565.001 | Data Manipulation: Stored Data Manipulation | Same artefact: modifies File | Writes to decoy data files, including mass encryption of share contents |
| T1204.002 | User Execution: Malicious File | Sub-artefact: Executable File | Execution of a decoy executable in a lure folder |
| T1072 | Software Deployment Tools | Same artefact: adds File | Decoy deployment packages or configuration in tool repositories are read |
Defensive guidance for several of these techniques is in the MITRE ATT&CK T1552 Unsecured Credentials Guide, T1560 and T1074 Archive and Stage Collected Data Defensive Guide, T1070 Indicator Removal Defensive Guide and T1036 Masquerading Defensive Guide.
Where it is implemented
Monitoring options by platform
| Platform | Mechanism | What to configure | Event or record |
|---|---|---|---|
| Windows (local or file server) | Object access auditing | Enable the Audit File System subcategory and add a SACL entry (Everyone, success) on the decoy for read and the write, delete and permission-change rights | 4663 "An attempt was made to access an object" (access right used), correlated with 4656 (handle requested) by Handle ID |
| Linux | Linux Audit (auditd) | A syscall-form rule on the path, for example -a always,exit -F arch=b64 -F path=/path/to/decoy -F perm=rwa -F key=decoy_file (auditctl documents watch rules with -w and -p as the deprecated equivalent) | Audit records searchable by key with ausearch |
| EDR-managed endpoints | File telemetry | Custom detection on any process opening the decoy path, excluding the EDR's own scanner | EDR alert with process tree |
| Cloud object storage | Data access logging | Object-level read logging on a decoy object in a real bucket or container | Provider data access log entry |
Event 4663 records an access right that was actually used and has no failure variant, while 4656 records the request and can log failures. Microsoft's access mask table gives ReadData 0x1, WriteData 0x2, AppendData 0x4 and DELETE 0x10000, which lets a rule distinguish "opened and read" from "modified" or "deleted". On Linux, auditctl notes that -F perm letters (r, w, x, a) refer to kinds of system calls, and an arch field must precede it to avoid auditing every syscall.
Implementation steps
- Pick the questions you want answered. Examples: is anyone browsing admin shares, harvesting secrets from build servers, staging data on file servers, or encrypting shares? Each answer sets placement and bait.
- Design credible decoys. Use the organisation's naming conventions, realistic sizes and dates (D3FEND explicitly lists checksum, creation and modified dates, size and owner as properties to adjust), and permissions that match neighbouring files. Never place real data or real secrets.
- Turn on telemetry first. On Windows, enable Audit File System through advanced audit policy and set the SACL on each decoy. On Linux, load the audit rule with a unique key. Confirm events reach the SIEM before relying on them.
- Write the detection. Alert on any 4663 for decoy paths, or any audit record with the decoy key, and include account, logon ID, process name and access mask. Correlate the logon ID with 4624 to find the source.
- Pilot and baseline. Deploy to a small set of servers for two to four weeks. Expect hits from backup agents, search indexers, antivirus and EDR scanners; exclude them by process and account, not by path, so a hostile process with the same path still alerts.
- Roll out by tier. Prioritise file servers, jump hosts, build and deployment servers, and administrator workstations.
- Document and protect the register. Keep a restricted list of decoy paths, owners and expected alert routes. Tell the help desk and backup teams enough to avoid "cleaning up" decoys, without publishing their locations.
- Roll back cleanly. To retire a decoy, remove the audit rule and the file together, and record it so stale alerts are not misread.
How to verify it works
- Touch test: on a schedule, open each decoy with a test account and confirm the alert arrives with the right account, host and process within your detection target.
- Access-type test: read, modify and delete a test decoy and confirm the access mask shows ReadData, WriteData and DELETE respectively, so rules can grade severity.
- Bulk test: copy a folder containing decoys with an archiver in a lab, the way staging and ransomware behave, and confirm the alert fires once with useful context rather than flooding.
- Drift check: compare the decoy register with the files and audit rules actually present; a missing SACL or unloaded audit rule is a silent failure.
| Metric | What good looks like |
|---|---|
| Decoys passing the scheduled touch test | 100%; failures fixed within a set time |
| Coverage of priority hosts with at least one decoy | All file servers, jump hosts and build servers |
| Benign hits per month after tuning | Near zero; each new benign source documented |
| Time from decoy access to analyst triage | Within the SOC's high-priority target |
| Decoy alerts that led to a confirmed finding | Tracked; the ratio shows whether placement matches attacker behaviour |
Limits, bypasses and failure patterns
- Noise from your own tools: indexers, backup, antivirus and data classification scanners read everything. Exclude by process and account with care, or the exclusion becomes a blind spot.
- Obvious decoys: files named "passwords.txt" with today's date in an empty folder are easy to spot and avoid. Match surrounding content.
- Targeted attackers skip them: an intruder who knows exactly what they want may never browse. Decoys complement, not replace, process and identity analytics.
- Audit policy drift: a group policy change or a rebuilt server removes the SACL or audit rule and the decoy stops reporting without any error.
- Real secrets in bait: copying a "realistic" config that still contains a live key turns the decoy into an exposure. Generate fake credentials deliberately and make them alert on use.
- Register exposure: a decoy list stored on an ordinary share tells an intruder which files to avoid.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-26 Decoys; SC-30 Concealment and Misdirection | Decoy components and misdirection of adversaries |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; AU-12 Audit Record Generation | Monitoring and the audit records decoys depend on |
| NIST CSF 2.0 | DE.CM-09 | Monitoring software, runtime environments and their data for potentially adverse events |
| NIST CSF 2.0 | PR.PS-04 | Log records generated and available for continuous monitoring |
Related countermeasures
- Decoy Object (parent): the family of decoys, including files, credentials, network resources and personas.
- Decoy User Credential (D3-DUC) and Decoy Session Token (D3-DST): sibling decoys that pair well with credential-bearing decoy files.
- Decoy Environment: whole decoy hosts and networks.
- File integrity monitoring: watches real files for change, the complement to watching fake files for access; see the File Integrity Monitoring Guide.
Practitioner checklist
- Decide which attacker behaviours each decoy should reveal and place it accordingly.
- Make decoys credible in name, size, dates, owner and permissions.
- Never include real data or live secrets; use fake credentials that alert on use.
- Enable Audit File System and SACLs on Windows, keyed audit rules on Linux.
- Alert on any decoy access with account, process, access mask and source.
- Tune out scanners by process and account, not by path.
- Keep a restricted decoy register and check it against reality.
- Touch-test every decoy on a schedule and track the pass rate.
Standards and references
- MITRE D3FEND: Decoy File (D3-DF)
- Microsoft Learn: 4663 An attempt was made to access an object
- Linux man-pages: auditctl(8)
- NIST: SP 800-53 Rev 5 Security and Privacy Controls (SC-26 Decoys)
- MITRE ATT&CK: T1083 File and Directory Discovery
- MITRE ATT&CK: T1552.001 Credentials In Files
Related NHI Mgmt Group resources: Deception Technology Deployment Guide · Honeytokens and Canary Credentials Guide · Linux File Integrity Monitoring Guide