Attackers who reach a host or a repository go looking for credentials, and a credential that no legitimate person or workload ever uses turns that search into a high-confidence alert. MITRE D3FEND names this countermeasure Decoy User Credential (D3-DUC) and defines it as "A Credential created for the purpose of deceiving an adversary." It sits under the Deceive tactic as a child of Decoy Object (D3-DO), alongside Decoy File, Decoy Network Resource, Decoy Persona, Decoy Public Release and Decoy Session Token. This card explains how D3-DUC works, which ATT&CK techniques D3FEND relates it to, how to deploy it for domain accounts, local accounts and cloud keys, and how to prove the decoys actually fire. It is written for detection engineers, identity security teams and SOC leads who already know the deception basics in the Honeytokens and Canary Credentials Guide.
Key takeaways
- Any use is a signal. A decoy credential has no business purpose, so an authentication attempt, a directory query or an attribute change against it is suspicious by definition, which gives very low false positive rates when the decoy is isolated from automation.
- D3FEND maps it to credential theft. The D3FEND knowledge base links D3-DUC through its Credential artefact to Unsecured Credentials (T1552), Forge Web Credentials (T1606) and Additional Cloud Credentials (T1098.001), with further inferred relations to credential dumping, brute force and token abuse.
- The decoy must lead somewhere watched. D3FEND's own considerations say decoy credentials should be integrated with a larger decoy environment so that a stolen credential is used against a monitored asset.
- Detection depends on the log source, not the decoy. A planted domain account is only useful if domain controller events 4768, 4771 and 4625 reach the SIEM; a planted cloud key only if the provider's API logs are collected.
- Test every decoy on a schedule. A decoy that was deleted, disabled by a clean-up job or excluded from log collection fails silently, so a scheduled test login per decoy is part of the control.
D3-DUC at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DUC (d3f:DecoyUserCredential) |
| Tactic | Deceive |
| Parent technique | Decoy Object (D3-DO), synonym "Lure" |
| Digital artefact | Credential (D3FEND relation: spoofs Credential) |
| Credential forms named by D3FEND | Domain username and password; local system username and password |
| What it changes | Adds credentials with no legitimate use to places attackers search: memory, files, scripts, configuration, directories, cloud accounts |
| Typical data sources | Domain controller security logs, endpoint logon events, identity threat detection tooling, cloud provider API audit logs, deception platform consoles |
| Effort | Low for a handful of decoy accounts or keys; medium to high for a maintained fleet integrated with decoy hosts |
| Main limitation | Detects only adversaries who find and use the decoy; it does not stop the use of real credentials |
How it works
D3FEND's description is short: a detection analytic is developed to determine when someone uses decoy credentials, and the subsequent actions of that user may be monitored or controlled by the defender. In practice the countermeasure has three parts.
- The lure: a credential that looks real in context. For Active Directory, an account with a plausible name, a description, group memberships and a password age consistent with real service accounts. For cloud, a key pair in a credentials file or environment file. For Linux and Windows hosts, a local account or a credential left in a script or a configuration file.
- The placement: where credential harvesters look. D3FEND's inferred relations show the target behaviours: dumping NTDS or /etc/shadow, reading cached domain credentials, scraping files for unsecured credentials, password spraying and guessing. A decoy in each of those places is in the attacker's path.
- The tripwire: a detection that fires on use. This can be a SIEM rule keyed on the decoy account name or SID, a native identity product feature, or a deception platform that owns the decoy and the alerting.
Two of D3FEND's references describe the same pattern in patent form. The Amazon Technologies patent describes a decoy credential that, when presented, routes the caller to a decoy network-based service whose API calls are recorded to understand the attacker's motivation. The Fidelis patent describes "mini-traps" on real endpoints that contain deceptive information pointing malware at decoy resources. Both show the design point D3FEND makes in its considerations: the credential is the bait, and the monitored decoy asset behind it is where you learn what the attacker wants.
Where identity fits
Most credentials attackers harvest today belong to non-human identities: service accounts, cloud access keys, kubeconfig tokens and application client secrets. Decoys should copy that reality. A fake service account with a password in a deployment script, or a fake access key in a CI variable file, is more believable than another fake human user, and its use maps straight to the NHI attack paths covered in the MITRE ATT&CK T1552 Unsecured Credentials Guide. Decoy accounts for AI agents follow the same logic and are covered in AI Agent Honeytokens and Canaries.
ATT&CK techniques D3FEND relates to D3-DUC
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DUC; every row below is inferred through a shared digital artefact (checked November 2026).
D3FEND does not hand-map D3-DUC to ATT&CK. Every row below is an inferred relationship that D3FEND derives through a shared digital artefact: D3-DUC spoofs Credential, so ATT&CK techniques that act on a Credential, or on one of its sub-artefacts such as Password or Access Token, are related to it. The relation column shows which. D3FEND labels these relations "inferred and experimental" (D3FEND 1.6.0, checked November 2026). D3FEND also lists Keychain under an ID that ATT&CK has since revoked; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What a decoy credential catches |
|---|---|---|---|
| T1552 | Unsecured Credentials | Same artefact: accesses Credential | A credential planted in a file, script or registry location is read and later used |
| T1606 | Forge Web Credentials | Same artefact: forges Credential | Forged material presented for a decoy identity |
| T1098.001 | Additional Cloud Credentials | Same artefact: creates Credential | Credentials added to a decoy cloud identity, which no administrator should ever touch |
| T1003.003 | NTDS | Sub-artefact: Encrypted Credential | Decoy domain account hashes are taken with the directory and later used |
| T1003.005 | Cached Domain Credentials | Sub-artefact: Encrypted Credential | A decoy logon cached on a host is extracted and replayed |
| T1003.008 | /etc/passwd and /etc/shadow | Sub-artefact: Encrypted Credential | A decoy local account hash is cracked and used |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Sub-artefact: Password | Spraying or guessing hits a decoy account name that only exists to be found |
| T1558.001 | Golden Ticket | Sub-artefact: Kerberos Ticket Granting Ticket | Ticket activity naming a decoy account |
| T1606.001 | Web Cookies | Sub-artefact: Session Cookie | Forged cookies for a decoy web identity |
| T1539, T1528 | Steal Web Session Cookie, Steal Application Access Token | Sub-artefact: Session Cookie, Access Token | Theft of tokens issued to a decoy identity |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie | Sub-artefact: Access Token, Session Cookie | Replay of decoy tokens or cookies |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Sub-artefact: Access Token | Token manipulation using a decoy account's credentials |
| T1555.001 | Keychain | Sub-artefact: Encrypted Credential | Decoy entries stored in a macOS keychain are extracted and used |
Treat these rows as a placement guide, not a coverage claim. A decoy only detects a technique when it sits where that technique looks and a log source records its use. Deeper treatment of two of the same-artefact techniques is in the MITRE ATT&CK T1606 Forge Web Credentials Guide and MITRE ATT&CK T1098.001 Account Manipulation.
Where it is implemented
| Implementation class | What it provides | Signal used | Fits when |
|---|---|---|---|
| Native directory plus SIEM rules | A disabled or never-used account in Active Directory and rules on its name or SID | DC events 4768 and 4771 (Kerberos TGT requested and pre-authentication failures), 4625 on the target host | You already collect DC security logs and want a no-cost start |
| Identity threat detection tooling | Honeytoken tagging and built-in alerts. Microsoft Defender for Identity, for example, tags users and devices as Honeytoken and raises alerts such as "Honeytoken authentication activity" (external ID 2014), "Honeytoken was queried via LDAP" (2429), "Honeytoken user attributes modified" (2427) and "Honeytoken group membership changed" (2428) | Authentication, LDAP reconnaissance and attribute or group changes on the decoy | An identity sensor already watches the domain controllers |
| Cloud provider keys | A real key pair for an identity with no permissions, planted in files or pipelines | Provider API audit log entries carrying the decoy key ID (for AWS, the CloudTrail userIdentity accessKeyId field) | Cloud credentials are the most likely loot in your estate |
| Hosted canary services | Generated decoys that alert on use. The open Canarytokens service, for example, offers AWS API key, Azure Entra ID login, Azure login certificate and kubeconfig tokens; its documentation notes AWS key alerts can arrive 2 to 30 minutes after use | Provider logging processed by the service | Small teams that want decoys without running log pipelines |
| Deception platforms | Decoy credentials injected into endpoint memory, browsers and files, pointing at decoy hosts and services | Use of the credential against a platform-owned decoy | Large estates that want scale and the "leads somewhere watched" design D3FEND recommends |
For Active Directory specifics such as naming, attributes and ACLs, see Decoy accounts in Active Directory. Wider platform choices are in the Deception Technology Guide.
Implementation steps
- Pick the credential stories. List where real credentials leak in your estate: deployment scripts, CI variables, shared drives, developer laptops, cloud credential files, kubeconfig files. Choose two or three places per environment and design one decoy for each.
- Create the decoy identities safely. Domain decoys: create the account, give it a plausible name and description, and grant no rights. Cloud decoys: create an identity with an explicit deny on everything and generate a key. Record every decoy in a register with owner, location, creation date and detection rule.
- Wire detection before planting. Write the SIEM rule or enable the native honeytoken tag first. For Windows, confirm DC audit policy produces 4768 and 4771 and that endpoint 4625 events are collected. For cloud keys, confirm the API audit trail covers every region and is ingested.
- Exclude the decoys from automation. Add the decoys to exclusion lists for stale-account clean-up, password expiry jobs and vulnerability scanners that authenticate, otherwise those jobs either delete the decoy or trigger it.
- Plant and pilot. Place decoys in one business unit first. Run for two to four weeks and tune out any benign trigger (backup software enumerating accounts, a scanner, an admin script) by fixing the source, not by weakening the rule.
- Write the response. A decoy alert means a host or repository is already compromised. The runbook should isolate the source host, identify every credential exposed in the same location and rotate real ones found there. Decoy alerts deserve high priority because they are rarely false.
- Roll back cleanly. To retire a decoy, remove it from every planted location before disabling the identity, then keep the detection rule for a period (for example 90 days, an NHI Mgmt Group suggestion, not a standard) so late use is still caught.
How to verify it works
A decoy that never fires looks identical to a decoy that is broken. Verification is therefore scheduled and recorded.
- Synthetic trigger test: monthly, from an approved test host, perform one failed authentication with each domain decoy and one denied API call with each cloud decoy. Confirm the alert arrives, carries the source host, and reaches the on-call queue within the expected time.
- Placement audit: quarterly, confirm each planted file, script and variable still exists and still contains the decoy, since refactoring and repository clean-ups remove them.
- Log path check: confirm the relevant DC, endpoint and cloud log sources are healthy. A gap in DC log forwarding silently disables every domain decoy.
- Purple team use: include decoy discovery in authorised red team or adversary emulation exercises and record whether the team found, used and triggered the decoys.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Decoys passing the monthly synthetic test | 100% | Proves the tripwire works end to end |
| Time from decoy use to analyst acknowledgement | Under 15 minutes for identity alerts | Decoy hits indicate active intrusion |
| Benign triggers per month after pilot | Close to zero | Shows exclusions and placement are right |
| Environments with at least one decoy per credential store type | Rising quarter on quarter | Coverage of the places attackers actually search |
| Decoys found and triggered in emulation exercises | Tracked per exercise | Shows the decoys are believable and well placed |
Limits, bypasses and failure patterns
- Decoys that lead nowhere: a decoy password for a host that does not exist gives one failed logon event and no insight. D3FEND's guidance is to connect decoy credentials to monitored decoy assets.
- Clean-up jobs that kill the decoy: stale-account removal deletes the never-used decoy account, and nobody notices because silence is the normal state.
- Decoys that are too obvious: names such as "honeypot_admin", a creation date of yesterday and no group membership are easy to spot during reconnaissance, especially with LDAP enumeration.
- Public placement without a plan: placing a decoy cloud key in a public repository is decoy public release, a different technique. Platform secret scanning will often report it: GitHub's partner programme sends matches found in public sources to the issuing provider and recommends treating them as compromised, so the key may be revoked before an attacker uses it.
- Decoys placed while real secrets stay beside them: a decoy in a repository that also holds a live long-lived key catches the attacker after the damage is done. The Uber Breach 2016 started with an AWS access key found in a private code repository; a decoy key in the same place would have raised an alert, but removing the real key was the control that mattered.
- Decoys with real permissions: a decoy that can read anything becomes a real credential the moment it leaks. Give decoys no rights, or an explicit deny.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-26 Decoys | Components that attract and detect malicious activity, the control family for decoy credentials |
| NIST SP 800-53 Rev 5 | SC-30 Concealment and Misdirection | Misdirection of adversaries through deceptive information |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting | The monitoring that turns decoy use into an alert |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity and technology usage; analysing adverse events |
| MITRE D3FEND | D3-DO, D3-DUC | Parent and technique |
Related countermeasures
- Decoy Session Token (D3-DST): the same idea applied to session tokens rather than reusable credentials.
- Decoy File (D3-DF): a file that holds the decoy credential is itself a decoy object.
- Decoy Network Resource (D3-DNR) and the honeynet techniques (D3-CHN Connected Honeynet, D3-IHN Integrated Honeynet, D3-SHN Standalone Honeynet): the monitored assets a decoy credential should lead to.
- Authentication Event Thresholding (D3-ANET): complements decoys by catching spraying against real accounts. See the overview in the MITRE D3FEND Guide.
Practitioner checklist
- Keep a register of every decoy credential with location, owner, rule and last test date.
- Grant decoys no permissions; use an explicit deny for cloud identities.
- Confirm DC events 4768, 4771 and endpoint 4625 are collected before planting domain decoys.
- Collect cloud API audit logs in every region before planting decoy keys.
- Exclude decoys from stale-account clean-up, password expiry and authenticated scanning.
- Prefer non-human decoys (service accounts, keys, kubeconfig files) where attackers look for them.
- Connect decoy credentials to monitored decoy hosts or services where possible.
- Run a monthly synthetic trigger test per decoy and record the result.
- Treat every decoy hit as a confirmed intrusion until proven otherwise and rotate real secrets found nearby.
Standards and references
- MITRE D3FEND: Decoy User Credential (D3-DUC)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-26 Decoys)
- Microsoft Learn: Defender for Identity entity tags (Honeytoken)
- Microsoft Learn: Defender for Identity security alerts
- Microsoft Learn: Event 4768, a Kerberos authentication ticket (TGT) was requested
- Microsoft Learn: Event 4771, Kerberos pre-authentication failed
- Microsoft Learn: Event 4625, an account failed to log on
- AWS: CloudTrail userIdentity element
- Canarytokens: AWS API keys token
- GitHub Docs: Secret scanning partner program
Related NHI Mgmt Group resources: Honeytokens and Canary Credentials Guide · Decoy accounts in Active Directory · Deception Technology Guide · Microsoft Defender for Identity · MITRE D3FEND Guide