Attackers research people before they phish them, and most organisations only learn who is being targeted after a message lands or a payment goes out. D3-DP Decoy Persona is the MITRE D3FEND countermeasure that puts a fake person in the attacker's path: D3FEND defines it as "establishing a fake online identity to misdirect, deceive, and or interact with adversaries". It sits in the Deceive tactic under the parent technique Decoy Object, and D3FEND models it as something that spoofs the User artefact. This card covers what a decoy persona is made of, the thin ATT&CK relationship D3FEND records, how to build and monitor one in an enterprise, the legal and platform constraints, how to verify it, and where it fails. It is for threat intelligence, email security and detection teams. D3FEND's own data is short on implementation detail, so the practical sections below are NHI Mgmt Group guidance built from D3FEND's considerations.
Key takeaways
- A person who does not exist. A decoy persona is a fake identity with its own email address, phone number and online profiles; contact with it has no legitimate explanation.
- Early warning of targeting. Mail, calls or connection requests to the persona show reconnaissance and phishing aimed at the organisation, often before real staff are hit.
- Realism takes ongoing work. D3FEND advises responding to contacts and keeping activity current so the persona does not go stale.
- Legal and platform terms come first. Check each platform's current terms before creating a profile, and NIST SC-26 notes decoy use may need legal consultation.
- The account behind it is an identity to govern. The persona's mailbox and directory account must be locked down so it cannot be used to sign in or send mail on the organisation's behalf.
D3-DP at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DP (d3f:DecoyPersona) |
| Tactic | Deceive |
| Parent technique | Decoy Object (D3-DO, synonym "Lure") |
| Digital artefact | User (D3FEND relation: spoofs User) |
| Components | Name and role, email address, phone number, social and professional profiles, optional directory entry |
| Typical data sources | Mail gateway and mailbox logs, telephony logs, identity provider sign-in logs, profile message notifications |
| Main limitation | Only detects adversaries who choose the persona as a target; legal and platform constraints limit where it can exist |
For the wider decoy programme, see the Deception Technology Guide.
How it works
D3FEND's article describes a false online identity created to interact with adversaries directly or indirectly, including the associated email addresses, social media accounts and other online communication profiles. Its considerations are to include phone numbers and online social profiles, to respond to contacts made to the persona automatically or manually to improve realism, and to keep the persona and its activity streams continuously updated.
D3FEND's internet reference is a 2013 SANS Internet Storm Center diary by Lenny Zeltser. It frames decoy personas as a way to confuse, misdirect, slow and detect adversaries who harvest data, phish or guess passwords, and describes building blocks that translate well to an enterprise: unique addresses per service so a leak can be traced, spamtrap addresses published only where harvesters will find them, and decoy profiles kept active with regular updates, virtual phone numbers and auto-replies. The diary also notes that attackers may respond by profiling targets more carefully, which raises their cost.
Enterprise persona patterns
| Pattern | Where it is published | What contact reveals |
|---|---|---|
| Decoy finance or accounts payable contact | Website contact pages, supplier documents, public filings where appropriate | Invoice fraud and business email compromise attempts |
| Decoy IT or helpdesk administrator | Professional networking profiles, conference attendee lists | Targeting of privileged staff, credential phishing, pretext calls |
| Decoy executive assistant | Professional profiles and the organisation's own site | Executive impersonation and gift card or payment scams |
| Harvest-only address | Embedded only in page source or documents, never used | Automated address harvesting and the source that leaked it |
| Per-supplier unique address | Given to a single supplier or service | Which third party leaked or sold the address |
ATT&CK techniques D3FEND relates to D3-DP
Relationship type: inferred only, and very limited. D3FEND's technique page lists no ATT&CK mapping for D3-DP (checked November 2026). In the D3FEND ontology the only ATT&CK technique that touches the User artefact is ICS T0865 Spearphishing Attachment, modelled as having a User participant.
The rows below after T0865 are NHI Mgmt Group's view of what a decoy persona most often exposes in practice; they are not D3FEND mappings. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Name | Basis | Persona signal |
|---|---|---|---|
| T0865 (ICS) | Spearphishing Attachment | D3FEND ontology (User participant) | Attachments sent to a decoy engineer or operator persona |
| T1589 | Gather Victim Identity Information | NHI Mgmt Group view | Harvest-only addresses receiving mail |
| T1593 | Search Open Websites/Domains | NHI Mgmt Group view | Contact traced to the page where the persona was published |
| T1598 | Phishing for Information | NHI Mgmt Group view | Pretext emails, calls or messages asking the persona for details |
| T1566 | Phishing | NHI Mgmt Group view | Malicious links or attachments sent to the persona |
| T1110 | Brute Force | NHI Mgmt Group view | Sign-in attempts against the persona's account |
Defensive guidance: MITRE ATT&CK T1589 Gather Victim Identity Information, MITRE ATT&CK T1598 Phishing for Information, MITRE ATT&CK T1566 Phishing and MITRE ATT&CK T1593 Search Open Websites/Domains.
Where identity fits
A decoy persona needs real infrastructure: a mailbox, often a directory account, perhaps a phone number. That account is an identity like any other and must be governed so the decoy cannot become an entry point.
- Block interactive sign-in: the account should never authenticate. Keep it disabled for sign-in or behind a policy that blocks all access, and alert on every sign-in attempt, which becomes a detection in its own right. The Decoy accounts in Active Directory guide covers the directory side.
- No outbound mail by default: replies, if used for realism, come from a controlled process with a human review, not from a mailbox anyone can send from.
- No group membership or access: keep the persona out of distribution lists, shared mailboxes and application assignments.
- Owner and review: give each persona a named owner in the security team and review it like any other account.
Legal, platform and ethical constraints
- Platform terms: check each social or professional platform's current terms of service on account identity before creating a profile there; where its terms do not allow a fictitious profile, publish the persona only on channels the organisation controls, such as its own website and documents.
- Legal review: NIST SP 800-53 SC-26 notes that, depending on use, consultation with general counsel may be needed before deploying decoys.
- No real people: never base a persona on a real employee, customer or public figure, and never use real photos of identifiable people.
- Do not engage beyond detection: responding to an attacker to keep a conversation going is an active operation; agree its limits, approvals and record-keeping in advance.
Implementation steps
- Define the question. For example: are suppliers' finance contacts targeted for invoice fraud, or are IT administrators targeted for credential phishing?
- Get approval. Record legal, HR and communications sign-off, and the platforms where the persona may appear.
- Build the identity. Name, role and history consistent with the organisation; a dedicated mailbox and, if needed, a virtual phone number.
- Lock the account. Block sign-in, remove licences and access not needed to receive mail, and set alerts for sign-in attempts and mailbox changes.
- Publish deliberately. Place the persona in a few known locations and record each one; a unique address per location identifies which source an attacker used.
- Route alerts. Send every inbound message, call record or connection request to the security team; scan mail with existing email security and preserve originals for analysis.
- Maintain realism. Follow D3FEND's advice: keep profiles and activity current and decide how contacts are answered.
- Retire cleanly. Remove published references, disable then delete the mailbox after a retention period, and keep records of what the persona received.
How to verify it works
- Delivery test: send a test message from an external address to each persona and confirm the security team receives the alert within the target time.
- Sign-in test: attempt a sign-in to the persona's account and confirm it is blocked and alerted.
- Source attribution test: confirm each published address or number maps to exactly one recorded location.
- Staleness review: check on a schedule that profiles, roles and published pages are still current.
| Metric | What good looks like (examples) |
|---|---|
| Personas passing delivery and sign-in tests | 100% |
| Inbound contacts triaged within target | All, with outcome recorded |
| Persona contacts later seen against real staff | Tracked; shows early-warning value |
| Personas reviewed for staleness on schedule | All |
Limits, bypasses and failure patterns
- Thin footprint: a profile with no history and no connections is easy to spot and ignore.
- Spam noise: published addresses attract bulk spam; triage by content and sender, or the signal drowns.
- Persona becomes a foothold: an account with sign-in enabled or a weak password can be taken over and used to send trusted mail.
- Terms of service breaches: a removed profile, or reputational harm, follows creating a profile that a platform's terms do not allow.
- Nobody owns it: personas without an owner go stale and their alerts go unread.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-26 Decoys | Decoy components to detect, deflect and analyse attacks; possible legal consultation |
| NIST SP 800-53 Rev 5 | SC-30(4) Misleading Information | Realistic but misleading information placed where adversaries look |
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Governing the persona's underlying account |
| NIST CSF 2.0 | DE.CM-01 | Monitoring for potentially adverse events |
For response when persona contact turns out to be a live campaign, see the Business Email Compromise Response Playbook.
Practitioner checklist
- Write the targeting question each persona should answer.
- Obtain legal and HR approval and check each platform's terms.
- Never use real people's names or photos.
- Block sign-in and access on the persona's account; alert on attempts.
- Use a unique address or number per publication point and record it.
- Route all persona contact to the security team and preserve originals.
- Keep personas current and owned; retire them cleanly.
Standards and references
- MITRE D3FEND: Decoy Persona (D3-DP)
- SANS Internet Storm Center: Decoy Personas for Safeguarding Online Identity Using Deception
- NIST: SP 800-53 Rev 5 Security and Privacy Controls (SC-26, SC-30)
- MITRE ATT&CK: T1598 Phishing for Information
- MITRE ATT&CK: T1589 Gather Victim Identity Information
- MITRE ATT&CK for ICS: T0865 Spearphishing Attachment
Related NHI Mgmt Group resources: Deception Technology Deployment Guide · D3-DUC Decoy User Credential · D3-DPR Decoy Public Release · Email Identity and BEC Guide · Honeytokens and Canary Credentials Guide