D3-DPR Decoy Public Release: Planting Public Lures That Reveal Attacker Reconnaissance

Attackers research a target in public before they touch it, and a public lure that only an attacker would act on turns that quiet reconnaissance into an alert. MITRE D3FEND names this countermeasure Decoy Public Release (D3-DPR) and defines it as "Issuing publicly released media to deceive adversaries." It sits under the Deceive tactic as a child of Decoy Object (D3-DO), alongside Decoy File, Decoy Network Resource, Decoy Persona, Decoy Session Token and Decoy User Credential. This card explains what D3FEND says about D3-DPR, what kinds of public lure work in practice, how to wire them to detection and prove they fire, and where the technique stops being safe. It is written for threat intelligence, detection engineering and deception teams who already know the basics in the Deception Technology Guide.

Key takeaways

• The lure lives outside your perimeter. D3-DPR is the only decoy object D3FEND describes as public media: press releases, videos and marketing collateral carrying URLs, points of contact or other identifiers that invite adversary interaction.
• D3FEND gives no ATT&CK mapping. The knowledge base lists no digital artefact and no ATT&CK relation for D3-DPR (checked November 2026), so any technique mapping is a placement judgement, and this page labels it as ours.
• The identifier is the tripwire. A decoy email address, URL, phone number or subdomain that appears only in one public item tells you exactly which source the adversary harvested when it is contacted.
• Realism has to be maintained. D3FEND's considerations say decoy media needs enough realism to deceive and continuous creation and distribution to keep adversaries engaging over time.
• Public deception carries real-world risk. Customers, journalists, investors and search engines read the same media, so every release needs legal and communications sign-off and must never make false statements about the business.

D3-DPR at a glance

The D3FEND reference is a security awareness training patent. It describes mock attacks delivered through messages, rogue wireless access points and USB drives carrying fake malware, and its classification includes deception as a countermeasure. It does not describe decoy press releases, so treat it as background on deceptive lures, not as an implementation guide.

How it works

Reconnaissance in ATT&CK starts with public sources: open websites and social media, victim-owned websites, and the people and contact details an organisation publishes. D3-DPR places deliberately unique identifiers into that public material so that any later use of them is attributable.

• The release: a genuine piece of public material, such as a careers page, a conference talk abstract, a partner announcement or a downloadable whitepaper, that carries one or more decoy identifiers. The material itself should be truthful; the deception is in the identifier, not in claims about the business.
• The identifier: an email address that routes to a monitored mailbox, a phone number that rings a monitored line, a URL on a tracked path or subdomain, or a named contact that exists only as a decoy persona. Each identifier is unique to one release so a hit names its source.
• The tripwire: monitoring on the identifier. Mail to the decoy address, a request to the decoy URL, a lookup of the decoy subdomain or a connection request to the decoy persona raises an alert or an intelligence record.
• The follow-on: what the adversary does next. A phishing email sent to the decoy contact shows the lure, infrastructure and sender used against you before real staff receive it.

Lure types and what each one reveals

ATT&CK techniques a public lure can surface

Relationship type: NHI Mgmt Group placement view, not D3FEND. D3FEND lists no ATT&CK relationship for D3-DPR, direct or inferred (checked November 2026). The table below is our view of the reconnaissance techniques whose output a decoy release can catch. Each ID was checked against ATT&CK v20.

The detection guidance for each technique is in the MITRE ATT&CK T1593 Search Open Websites/Domains, MITRE ATT&CK T1594 Search Victim-Owned Websites and MITRE ATT&CK T1598 Phishing for Information pages.

Where it is implemented

• Mail platform: a dedicated mailbox or alias per release, excluded from marketing lists and auto-replies, with all inbound mail forwarded to the SOC or a threat intelligence queue. Keep messages intact with full headers for analysis.
• Web server or hosted token service: a unique path on your own site logged to the SIEM, or a hosted web bug token. The open Canarytokens service, for example, issues a URL that raises an alert when anyone browses to it.
• DNS: a decoy subdomain with query logging on the authoritative servers, pointing at a monitored host or a D3-DNR Decoy Network Resource.
• Social and SaaS platforms: D3FEND's considerations note that releases can sit on enterprise-owned infrastructure, IaaS or SaaS including social platforms, and that platforms the enterprise does not fully own may be more likely to gather information. In practice, owned infrastructure gives you full logs; third-party platforms give reach but only the telemetry the platform shares.
• Deception platforms: some commercial deception products manage decoy identifiers and the decoy assets behind them, which suits large programmes that also run decoy hosts and credentials.

Implementation steps

1. Agree the rules first. Get written approval from legal, communications and the business owner of each channel. Set one rule above all others: the release content is true, only the identifier is a decoy.
2. Choose the reconnaissance you want to see. Pick two or three questions, such as "who phishes our finance contacts" or "who scans systems named in our engineering blog", and design one identifier for each.
3. Build the monitoring before publishing. Create the mailbox, URL, subdomain or line, connect it to the SIEM or intelligence platform, and send a test interaction to prove the alert path.
4. Register every identifier. Record the identifier, the release it appears in, the publication date, the owner and the alert rule, so a hit maps straight back to its source.
5. Publish and baseline. Expect noise in the first weeks from crawlers, link preview services, spam lists and security scanners. Classify it and tune by source characteristics rather than turning the tripwire off.
6. Write the response. Define what a hit triggers: blocking the sender or infrastructure, warning staff about the specific lure, sharing indicators, and checking whether real contacts in the same release were targeted.
7. Retire cleanly. When a release ages out, keep the identifier monitored for a period (for example six months, an NHI Mgmt Group suggestion, not a standard), because harvested lists are reused long after collection.

How to verify it works

• Synthetic interaction test: monthly, send mail to each decoy address and request each decoy URL from an external network, and confirm the alert arrives with sender or source details intact.
• Placement audit: quarterly, confirm each release is still published and still carries the identifier; website redesigns and document updates remove them silently.
• Uniqueness check: search for each identifier and confirm it appears only where you placed it. An identifier that leaks into internal lists or partner directories loses its attribution value.
• Authorised exercises: include public reconnaissance in red team scopes and record whether the team harvested and used a decoy identifier.

Limits, bypasses and failure patterns

• Machines read public media too: search crawlers, link preview services and email security gateways that detonate links will request decoy URLs. Without classification by user agent and source, the tripwire drowns in noise.
• False statements in public: a release that invents products, partnerships, financial results or incidents can mislead customers and investors and damage trust. Keep the deception in the identifier only.
• Spam lists flatten the signal: once a decoy address reaches commercial spam lists, mail to it says little. Rotate identifiers per release and treat bulk spam as a separate class.
• Too obvious: an address such as "honeypot@" or a contact who exists nowhere else online is easy to spot. Pair named contacts with a credible decoy persona.
• Nothing behind the lure: a decoy subdomain that resolves to nothing shows interest but nothing more. Point it at a monitored decoy asset where the risk is acceptable, as covered in Honeypot deployment.
• Platform terms of service: social and SaaS platforms set their own rules on account identity and content. Check them before publishing a decoy persona or decoy page there.

Framework mapping

Related countermeasures

• Decoy Persona (D3-DP): the believable person behind a decoy named contact. See D3-DP Decoy Persona.
• Decoy File (D3-DF): a downloadable document can carry decoy identifiers in its body or metadata. See D3-DF Decoy File.
• Decoy User Credential (D3-DUC): the internal equivalent once an attacker is inside. See D3-DUC Decoy User Credential.
• Domain Registration Takedown (D3-DRT): acts on lookalike infrastructure a decoy release may reveal. See D3-DRT Domain Registration Takedown.

Practitioner checklist

• Get legal and communications approval; keep release content true and deceive only through identifiers.
• Use one unique identifier per release so every hit names its source.
• Build and test monitoring before anything is published.
• Keep a register of identifiers, releases, owners and alert rules.
• Classify crawler, preview and scanner traffic instead of disabling alerts.
• Keep decoy identifiers out of internal directories and marketing lists.
• Run a monthly synthetic test per identifier and a quarterly placement audit.
• Feed hits into phishing defence and threat intelligence sharing.

Standards and references

• MITRE D3FEND: Decoy Public Release (D3-DPR)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-26, SC-30)
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: T1593 Search Open Websites/Domains
• MITRE ATT&CK: T1598 Phishing for Information
• Google Patents: US9558677B2 Mock attack cybersecurity training system and methods
• Canarytokens: Web bug token

Related NHI Mgmt Group resources: Deception Technology Guide · Honeytokens and Canary Credentials Guide · Disinformation and Brand Impersonation Guide · MITRE D3FEND Guide