File shares, intranet sites and document repositories are where intruders go to find data, stage it and spread malware, and ordinary access to them looks exactly like legitimate work. D3-DNR Decoy Network Resource is the MITRE D3FEND countermeasure that plants something no legitimate user needs among them: D3FEND defines it as "deploying a network resource 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 Network Resource artefact, which D3FEND describes as a shared resource or network share made available from one host to others. This card covers what counts as a decoy network resource, the ATT&CK techniques D3FEND relates to it, how to deploy and monitor decoy shares and repository spaces, how to prove they fire, and where they fail. It is for detection engineers and file and collaboration platform owners.
Key takeaways
- A shared resource nobody needs. A decoy share, folder, site or repository space has no business users, so any access to it is worth an alert.
- D3FEND links it to collection and spread. Its inferred relationships include Remote Data Staging (T1074.002), Taint Shared Content (T1080) and External Defacement (T1491.002).
- Share-level auditing is the core telemetry. On Windows file servers, Audit Detailed File Share (event 5145) records the share, the file path and the access requested.
- Write access is the strongest signal. Writes, renames and deletes in a decoy share point to staging, tainting or encryption, not curiosity.
- Plan for abuse of the decoy itself. D3FEND warns of resource exhaustion through denial of service; cap size and rate.
D3-DNR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DNR (d3f:DecoyNetworkResource) |
| Tactic | Deceive |
| Parent technique | Decoy Object (D3-DO, synonym "Lure") |
| Digital artefact | Network Resource, also called Shared Resource (D3FEND relation: spoofs Network Resource) |
| Examples | Decoy SMB or NFS shares, intranet or wiki spaces, document library sites, web application paths, repository projects |
| Typical data sources | Windows Security log (5145), NAS and file server audit logs, collaboration platform audit logs, web server logs |
| Main limitation | Only detects adversaries who browse to the decoy; indexers and backup jobs cause benign hits |
For the decoy programme as a whole, see the Deception Technology Guide.
How it works
D3FEND's article says decoy network resources are deployed to web application servers, network file shares or other network based sharing services, and that one honeypot may serve a variety of them. Its examples are honeypots that mimic a known system with fake vulnerabilities, decoy accounts used to observe attempted logins, and tarpits that monitor unallocated IP space. The parent technique adds the rule that makes the method work: decoy objects have no legitimate business purpose, so any communication with them should be logged and analysed.
A decoy network resource has three parts.
- The resource: a share, folder, site, library or repository with a name an intruder wants: "Finance-Archive", "IT-Backups", "HR-Payroll", "Deploy-Scripts". It is published where discovery will find it, for example on a real file server alongside real shares.
- Bait content: plausible but fake documents, scripts or configuration. Decoy files inside it are a separate D3FEND technique, covered in D3-DF Decoy File.
- Telemetry: share or platform audit logging that records who connected, from where, which object and with what access.
Telemetry by platform
| Resource type | Mechanism | What it records |
|---|---|---|
| Windows SMB share | Audit Detailed File Share subcategory, event 5145 | Share Name, Relative Target Name, Access Mask, Source Address, and whether access was granted or denied |
| Windows file system under the share | Audit File System with a SACL, event 4663 | Object accessed, process, access right used |
| Linux file server (Samba or NFS export) | Linux Audit watch on the exported path; Samba audit modules where used | Path, user, system call type |
| Collaboration and wiki platforms | The platform's audit log for site, page and file access | User, object, action, client address |
| Web application path | Web server access log on a decoy URL | Source address, user agent, request |
Microsoft documents that 5145 is generated for every share object access, so volume can be high; filter at collection to the decoy Share Name. It also notes that failure events appear only when access is denied at the share level; a denial at the NTFS level produces no 5145. The Access Mask lets a rule separate reads (ReadData 0x1) from write-type rights such as WriteData, AppendData, DELETE and WRITE_DAC, which Microsoft lists as worth monitoring.
ATT&CK techniques D3FEND relates to D3-DNR
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DNR; every row below is inferred through the shared Network Resource artefact (checked November 2026).
D3FEND's ontology links three techniques directly to the Network Resource artefact; its technique page also shows further inferred rows through related artefacts. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Name | Tactic | Decoy opportunity |
|---|---|---|---|
| T1074.002 | Data Staged: Remote Data Staging | Collection | A writable decoy share is used as a staging point |
| T1080 | Taint Shared Content | Lateral Movement | Files written or modified in a decoy share or repository |
| T1491.002 | Defacement: External Defacement | Impact | Changes to a decoy web path or site |
| T1039 | Data from Network Shared Drive | Collection | Any read of decoy share content |
| T1213.001 | Data from Information Repositories: Confluence | Collection | Access to a decoy wiki space |
| T1213.002 | Data from Information Repositories: Sharepoint | Collection | Access to a decoy document library site |
| T1037.003 | Boot or Logon Initialization Scripts: Network Logon Script | Persistence, Privilege Escalation | Writes to decoy logon script locations |
| T1070.005 | Indicator Removal: Network Share Connection Removal | Stealth | Connections to a decoy share removed after use |
In NHI Mgmt Group's view, discovery activity such as T1135 Network Share Discovery is also what usually leads an intruder to a decoy share; D3FEND does not list it for D3-DNR. Technique guides: T1074 Data Staged, MITRE ATT&CK T1080 Taint Shared Content, MITRE ATT&CK T1039 Data from Network Shared Drive, T1213 Data from Information Repositories Defensive Guide and MITRE ATT&CK T1491 Defacement.
Where identity fits
Every decoy access is made by an account. When a decoy share alert names a service account, a backup identity or an automation account, that is a strong lead that the credential has been stolen, because those identities follow fixed, predictable paths. Record which non-human identities legitimately touch each file server so a decoy hit by one of them stands out, and route it to credential revocation as well as host triage.
Implementation steps
- Choose the behaviours to catch. Data hunting on file servers, staging, malware spread through shares, or mass encryption. Each sets the resource type and whether it should be readable or writable.
- Create the resource on a real host. A decoy share on a production file server is more credible than a lone decoy server; set share and NTFS permissions so that broad groups can see it, matching neighbouring shares.
- Populate credibly. Use naming conventions, folder structures and file dates that match real shares. Never copy real data in.
- Turn on telemetry. Enable Audit Detailed File Share on the host and collect only 5145 events for the decoy Share Name; for platforms, enable the audit log and confirm decoy access appears.
- Write the detection. Alert on any access; raise severity for write-type access masks and for many objects touched in a short window.
- Cap abuse. D3FEND advises considering resource exhaustion through denial of service: set a quota on writable decoys and rate-limit decoy web paths.
- Pilot and exclude. Search indexers, backup and data classification scanners will touch decoys. Exclude them by account and source host, not by share, and record each exclusion.
- Roll back cleanly. Remove the share, its content and its audit filter together, and update the restricted decoy register.
How to verify it works
- Browse test: from a normal workstation and test account, open the decoy share and a file in it; confirm the alert names the account, source address and object.
- Write test: create, modify and delete a test file; confirm the access mask shows the write and delete rights and the rule raises severity.
- Bulk test: in a lab, copy the whole decoy share with a sync tool, the way staging behaves, and confirm one useful alert rather than a flood.
- Drift check: confirm the share, its permissions and the audit setting still exist after server rebuilds and policy changes.
| Metric | What good looks like (examples) |
|---|---|
| File servers and repositories with a decoy resource | All servers holding sensitive shares |
| Decoys passing the scheduled browse test | 100% |
| Benign hits per month after tuning | Near zero; each source documented |
| Time from decoy write to analyst triage | Within the SOC high-priority target |
Limits, bypasses and failure patterns
- Obvious names: a share called "Passwords" on a server with no other shares looks planted. Blend into the surrounding naming.
- Hidden shares not found: a decoy share that is not enumerable to the groups an intruder will use never gets visited.
- Exclusion blind spots: excluding a whole backup server means an intruder on that server is invisible.
- Audit gaps: 5145 does not log NTFS-level denials, and collection filters can silently drop the decoy share after a rename.
- Writable decoys abused: without quotas, a writable decoy can be filled to exhaust disk space, as D3FEND warns.
- Real data creep: staff copy real files into a "convenient" empty share; review decoy contents.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-26 Decoys | Components designed to be the target of attacks, for detection and analysis |
| NIST SP 800-53 Rev 5 | SC-30(4) Misleading Information | Realistic but misleading information about systems |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation; SI-4 System Monitoring | The share and platform audit records decoys rely on |
| NIST CSF 2.0 | DE.CM-01 | Networks and network services monitored for potentially adverse events |
For hardening the real shares around a decoy, see the Unstructured Data and File Share Security Guide.
Practitioner checklist
- Decide whether each decoy should catch reads, writes or both.
- Host decoy shares on real file servers with matching names and permissions.
- Fill decoys with credible fake content, never real data.
- Enable Audit Detailed File Share and filter 5145 to decoy share names.
- Raise severity for write, delete and permission-change access.
- Apply quotas and rate limits to writable or web decoys.
- Exclude scanners by account and host, and record each exclusion.
- Test browse and write alerts on a schedule.
Standards and references
- MITRE D3FEND: Decoy Network Resource (D3-DNR)
- Microsoft Learn: 5145 A network share object was checked to see whether client can be granted desired access
- NIST: SP 800-53 Rev 5 Security and Privacy Controls (SC-26, SC-30)
- MITRE ATT&CK: T1074.002 Remote Data Staging
- MITRE ATT&CK: T1080 Taint Shared Content
- MITRE ATT&CK: T1039 Data from Network Shared Drive
Related NHI Mgmt Group resources: Deception Technology Deployment Guide · Honeypot deployment · D3-DF Decoy File · D3-CHN Connected Honeynet