Decoy accounts in Active Directory: design, audit and respond to honey users

Attackers in an Active Directory domain enumerate accounts, roast service tickets and spray passwords long before they touch anything valuable, and a well-built decoy account turns each of those steps into a near-certain alert. A decoy account (honey user, honeytoken account) is a real directory object that nobody legitimately uses, so any query, ticket request or sign-in against it is suspicious. The Deception Technology Guide introduces the idea and the Honeytokens and Canary Credentials Guide covers canaries across cloud and code. This page goes deeper on Active Directory alone: the decoy types worth building, the attribute and audit settings that make them work, the exact events and Defender for Identity alerts to watch, and how to respond. It is for AD engineers, detection engineers and identity threat detection and response (ITDR) teams.

Key takeaways

• Build one decoy per attacker behaviour. A honey SPN catches Kerberoasting, a no-preauthentication account catches AS-REP roasting, an audited "admin" catches LDAP reconnaissance, and a planted password catches credential reuse.
• The decoy must be useless if stolen. No real group rights, deny-logon rights everywhere, and a long random password so roasted hashes cannot be cracked; a decoy that grants access is a backdoor.
• Auditing makes or breaks it. Enable Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Credential Validation and Audit Directory Service Access on domain controllers, and put a SACL on the decoy so reads produce event 4662.
• Defender for Identity has four honeytoken alerts. Tag the account with the Honeytoken tag and you get LDAP query (2429), attribute modified (2427), group membership changed (2428) and authentication activity (2014) alerts, with no learning period.
• Every hit is an incident until proven otherwise. Identify the source host and account, contain them, and assume the attacker holds whatever else was on that host; do not touch the decoy and tip them off.

Decoy account types and what each catches

Most organisations start with three: a honey SPN, a honey admin and a password lure. See the Kerberoasting and AS-REP Roasting Defence Guide for the attacks the first two expose.

Designing a decoy that attackers believe

Directory reconnaissance tools pull every user, group, SPN and attribute in minutes, and experienced operators look for objects that do not fit. Believability comes from matching your own conventions, not from clever names.

• Naming: follow the real pattern for the account type, such as svc- prefixes for service accounts or adm- for admin accounts. Avoid words like "honey", "decoy" or "trap" anywhere.
• Location: place the decoy in the OU where real accounts of that type live, not in a dedicated "Deception" OU.
• History: an account created yesterday with no logon history stands out. Create decoys well ahead of need, and consider occasional scripted logons from a controlled host so lastLogonTimestamp moves.
• Attributes: fill in description, department, manager, title and phone the way real accounts do. Microsoft's own description of honeytokens uses an attractive name such as "SQL-Admin" as the example.
• Group membership: real privileged groups (Domain Admins, Enterprise Admins, Account Operators, Backup Operators) are off limits. Membership of a protected group also sets adminCount=1 and applies AdminSDHolder permissions, which changes how the object looks and behaves. Use a decoy group with a convincing name and no delegations or ACL entries anywhere.
• Kerberos settings: the honey SPN account needs a password of 30 or more random characters so a roasted ticket cannot be cracked. The same applies to the no-preauthentication decoy.

Making the decoy useless if stolen

• Deny logon everywhere: assign the decoy accounts to a group that has "Deny log on locally", "Deny log on through Remote Desktop Services", "Deny access to this computer from the network", "Deny log on as a batch job" and "Deny log on as a service" in a GPO linked across the domain. Authentication attempts still reach the domain controller and still log.
• Disabled or enabled: a disabled account still produces Kerberos events (the KDC returns 0x12 KDC_ERR_CLIENT_REVOKED), but tools often filter out disabled accounts, so it attracts less interest. Enabled decoys with deny-logon rights are more convincing.
• No access in ACLs: check that the decoy and its group appear in no DACL on any object, share or GPO. Run your attack path tool against the decoy to confirm it leads nowhere. See the BloodHound and Active Directory Attack Path Guide.
• No mailbox, no SaaS: exclude decoys from directory sync to cloud identity unless you build a matching cloud decoy deliberately, so a decoy password cannot open Microsoft 365 or SaaS apps.
• Planted passwords are fake: a password lure should be valid for the decoy only, never a real account's password, and never reused across decoys.

Audit configuration and the events that fire

Enable these Advanced Audit Policy subcategories on domain controllers through the Default Domain Controllers Policy, and confirm the security log size and forwarding can handle the extra volume.

• The SACL: on the decoy object, add an auditing entry for Everyone (or Authenticated Users) for Read all properties, Write all properties and the extended rights you care about. Event 4662 is logged only when the object has a SACL and the operation matches it, and one event is written per operation type.
• Read-audit noise: directory sync, identity governance connectors, backup and some monitoring tools read every object. Exclude those exact service accounts and source hosts in the detection rule, not by narrowing the SACL, and review the exclusion list quarterly. An exclusion is also a blind spot if that service account is stolen.
• Kerberoast signal quality: Microsoft's 4769 guidance recommends alerting on Account Name and Service ID pairs that should never occur. For a honey SPN that pair is "anyone and the decoy", which needs no baseline.

The Active Directory Security Monitoring and Event IDs Guide covers these events in the wider monitoring context.

Microsoft Defender for Identity honeytokens

If you run Defender for Identity, tag each decoy in Microsoft Defender XDR under Settings, Identities, Honeytoken. The tag supports users and devices, and Microsoft states that "Any sign-in from a honeytoken account triggers an alert". The classic alert reference lists four honeytoken alerts, all with no learning period:

• Raise the severity in your SOC: the vendor severity for the LDAP alert is Low, but against a decoy nobody should query it is a strong reconnaissance signal. Route all four to a dedicated playbook.
• SAM-R: the honeytoken reconnaissance alert is documented for LDAP. SAM-R enumeration is covered by the separate "User and Group membership reconnaissance (SAMR)" alert, so do not assume a SAM-R query of the decoy raises a honeytoken alert.
• Without Defender for Identity: forward the events above to the SIEM and write one rule per decoy type keyed on the decoy names or SIDs. Keep the list of decoy SIDs in a restricted lookup table, not in rule text visible to many people.

Deploying decoys step by step

1. Agree scope and secrecy: SOC lead, AD owner and security leadership agree which decoys to build and who knows. Record them in a restricted decoy register with owner, location, purpose and review date.
2. Enable auditing: turn on the subcategories above on all domain controllers, then confirm 4768, 4769, 4771, 4776 and 4662 arrive in the SIEM.
3. Create the decoys: build the accounts in normal OUs with realistic attributes, random passwords, the deny-logon group and the SACL. Exclude them from cloud sync.
4. Plant the lures: place the password lure where an attacker would look, for example an old script on an admin file share or a decoy credential in a jump host's saved connections.
5. Tag and write rules: apply the Honeytoken tag in Defender for Identity and build SIEM rules for each event and decoy.
6. Tune for two to four weeks: alerts go to the detection team only. Each hit is investigated; legitimate readers are excluded by exact account and host.
7. Validate with the red team: run LDAP enumeration, Kerberoasting, AS-REP roasting and spraying from a test host and confirm every decoy alerts within the expected time.
8. Go live: route alerts to the SOC with the playbook below, then repeat per domain and forest.
9. Rollback: disable a decoy's rule or remove its tag, or delete the account, from the register. A decoy that breaks something (for example a script that tries to use it) is withdrawn while the cause is fixed.

Responding to a decoy alert

1. Identify the source: client address and workstation from 4768, 4769, 4771, 4776 or 4625, and the subject account from 4662.
2. Scope the account and host: what else did that account do in the past 24 to 72 hours, which other tickets did that host request, and was the decoy request part of a burst against many SPNs.
3. Contain without touching the decoy: isolate the source host through EDR, disable or reset the subject account, and revoke its sessions. Leave the decoy unchanged so the attacker does not learn it was a trap.
4. Assume wider credential exposure: any credential cached or stored on the source host may be stolen. If the alert suggests directory-wide credential theft, follow the Active Directory Domain Compromise Response Playbook.
5. Record and refresh: log the outcome in the register. If the decoy is burned (used in a known incident or red team report), replace it.

Where identity fits

Decoys are the cheapest identity threat detection you can deploy, and most of the attacks they catch target non-human identities. Kerberoasting goes after service accounts with SPNs and weak passwords; a honey SPN sits among them. Stolen directory hashes stay useful to attackers for years: Kraken's 2025 republication of Cisco's 2022 directory hashes, covered in the Cisco Active Directory credentials leak, included service and machine accounts. A decoy in a dumped NTDS turns any later replay of that dump into an alert. See the ITDR Guide and the Service Account Security Guide.

Detection and measurement

• Coverage: share of domains with each decoy type live and tagged; target every domain in every forest.
• Audit health: share of domain controllers forwarding 4768, 4769, 4771, 4776 and 4662 in the last 24 hours.
• Time to alert: from red team action to SOC alert, measured in each validation exercise.
• Precision: share of decoy alerts that were malicious or authorised testing; benign noise should trend to near zero after tuning.
• Exercise detection rate: share of red team or purple team exercises in which a decoy fired, and at which stage.
• Exclusion count: number of excluded readers; growth means the decoy is drifting toward blindness.

Common failure patterns

• A decoy with real rights: a "honey admin" placed in Domain Admins for realism becomes the easiest domain admin account to steal.
• Crackable decoy passwords: a honey SPN with a short password gives the attacker a valid credential after offline cracking.
• Audit policy missing on some DCs: a new domain controller built without the policy silently drops events for every decoy.
• Obvious names and OUs: an OU called "Honeypots" or a description saying "do not use" tells the attacker what to avoid.
• Broad exclusions: excluding a whole subnet or a powerful service account from 4662 alerts to stop sync noise hides the attacker who compromises it.
• Synced decoys: a decoy synced to Entra ID with a planted password becomes a working cloud account.

Framework mapping

Practitioner checklist

• Build at least a honey SPN, a honey admin and a password lure in every domain, named and placed like real accounts.
• Give every decoy a 30+ character random password, no real group rights and deny-logon rights domain-wide.
• Enable Kerberos, credential validation and directory service access auditing on every domain controller.
• Add a SACL to each decoy so reads and writes generate event 4662.
• Tag decoys with the Defender for Identity Honeytoken tag, or write SIEM rules keyed on decoy SIDs.
• Exclude decoys from cloud directory sync.
• Keep a restricted decoy register with owner, location, purpose and review date.
• Validate every decoy with red or purple team exercises at least twice a year.
• Respond by containing the source host and account, never by changing the decoy.

Standards and references

• Microsoft Learn: Defender for Identity entity tags
• Microsoft Learn: Defender for Identity classic security alerts
• Microsoft Learn: Event 4662, an operation was performed on an object
• Microsoft Learn: Event 4769, a Kerberos service ticket was requested
• Microsoft Learn: Event 4768, a Kerberos authentication ticket was requested
• MITRE D3FEND: Decoy User Credential
• MITRE ATT&CK: Kerberoasting
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Deception Technology Guide · Honeytokens and Canary Credentials Guide · Kerberoasting and AS-REP Roasting Defence Guide · ITDR Guide