A practical guide to building high-signal deception inside Active Directory: decoy users, computers, groups, SPNs, and ACL “tripwires” that trigger alerts when an attacker enumerates, Kerberoasts, moves laterally, or attempts privilege escalation.
- What “AD honeypots” and decoy accounts really are
- Design principles: make decoys believable, safe, and noisy
- Decoy user accounts (honeyusers)
- Decoy computer accounts and “fake endpoints”
- Decoy service accounts for Kerberoasting detection
- Decoy privileged groups and role bait
- ACL / directory object tripwires (SACL + auditing)
- What to alert on: logs and signals that matter
- Response playbook: what to do when a decoy fires
- Common pitfalls (and how to avoid them)
- Implementation checklist
1) What “AD honeypots” and decoy accounts really are
In an Active Directory context, a “honeypot” usually isn’t a single server running a trap service. It’s a set of directory objects designed to be irresistible to attackers—and useless (or safely inert) to everyone else.
Decoys are about early detection
You’re not trying to “catch hackers” with a cinematic sting. You’re trying to create high-confidence alerts the moment someone starts doing attacker things: enumeration, ticket harvesting, suspicious logons, group tampering, or directory replication probing.
A decoy is successful when it’s boring to admins
The best decoy is one your IT team never needs to touch—yet an attacker will touch because it looks valuable: “BackupAdmin”, “SQLSvc-Prod”, “Tier0-Operators”, “GPO-Deploy-Software”, etc.
If you want supporting fundamentals for how authentication works in AD (so your alerts are grounded in reality), revisit NTLM vs Kerberos authentication and the implications for tickets, logons, and lateral movement.
2) Design principles: believable, safe, and noisy
Use these principles to keep deception effective without creating new risk:
- Believable naming + placement. Put decoys where real objects live (correct OU, description style, department tags, “managedBy”, etc.).
- High value to attackers, low value to operations. The decoy should look privileged, but not actually grant privilege.
- Instrumented by default. Every decoy has an explicit alert path (SIEM rule, Defender/IDR alert, email/pager).
- Hard to “accidentally” trigger. Avoid names that interns might try, or that scripts might enumerate and touch routinely.
- Fail-safe configuration. Decoy credentials should be strong, logon rights constrained, and access paths controlled.
Related reading: protecting powerful identities is still the baseline. See Securing administrator accounts in Active Directory for hardening patterns that reduce your blast radius if an attacker gets closer than your decoys.
3) Decoy user accounts (honeyusers)
A decoy user account is a “bait” identity that should never be used for normal logons, email, or apps—but looks like it could be. Typical attacker behaviors it catches:
- Credential spraying / password guessing against “obvious” admin-like names
- Enumeration leading to targeted logon attempts
- Privilege escalation attempts using “found” accounts
How to make a decoy user believable
- Use a realistic employee pattern:
first.lastorsvc_appname_env(match your org conventions) - Populate attributes: Department, Title, Manager, office location, and a plausible description
- Place it in the correct OU (not a “Honeypots” OU that screams trap)
How to make it safe
- Set a very strong random password (not stored in documentation; store it in a secure vault if needed)
- Deny interactive logon where possible; ensure it’s not a member of privileged groups
- Use explicit alerting for any authentication activity involving this account
Tip: decoys work best when you also understand what “normal” looks like. If you’re tracking lockouts and bad password attempts, this lockout troubleshooting guide pairs nicely with decoy-based alerting because it helps you quickly distinguish “fat-fingered user” vs “active attack”.
4) Decoy computer accounts and “fake endpoints”
Decoy computers catch discovery and lateral movement. Attackers often scan AD for “servers”, “RDP targets”, “file servers”, or systems that “must” contain credentials (backup servers, management servers, jump hosts).
Two practical patterns
Pattern A: directory-only decoy computer
Create a computer account that looks like a sensitive host. Don’t actually deploy a system behind it. You then alert on attempts to authenticate to it (Kerberos/NTLM), connect via SMB, or resolve its name repeatedly.
Good for: low effort, quick wins, catching recon.
Pattern B: lightweight decoy endpoint
Deploy a minimal VM with no real data, but with telemetry enabled (Windows event logs, Sysmon/EDR, and network logs). It advertises “tempting” services (e.g., a share name, an RDP banner, or a fake app folder structure).
Good for: catching lateral movement and tooling behavior.
If you’re building decoys around “who can access what”, it helps to be fluent in AD permissions and how access is granted. Reference: Active Directory Permissions Explained.
5) Decoy service accounts for Kerberoasting detection
Kerberoasting is attractive because it’s quiet: attackers request service tickets for accounts with SPNs and crack them offline. A decoy service account is a perfect trap because any request for its ticket is suspicious—if no real application uses it.
Safe configuration for an SPN decoy
- Create a dedicated service-style user (not privileged), set a very strong password
- Assign a plausible SPN like
MSSQLSvc/sql-prod-01:1433orHTTP/app-portal-prod(matching your environment patterns) - Do not bind it to a real service; it exists to be requested, not used
- Alert on Kerberos service ticket requests (and who requested them)
Example: creating a decoy service account + SPN (PowerShell)
# Requires RSAT AD PowerShell module
# 1) Create the decoy user (choose an OU that matches your real service accounts OU)
New-ADUser `
-Name "SQL Service (Prod)" `
-SamAccountName "svc_sql_prod" `
-UserPrincipalName "svc_sql_prod@corp.example" `
-Path "OU=Service Accounts,DC=corp,DC=example" `
-Description "Prod SQL service identity - managed by platform team" `
-Enabled $true
# 2) Set a long random password (store in a vault if you must store it at all)
$pw = ConvertTo-SecureString "REPLACE_WITH_A_LONG_RANDOM_PASSWORD" -AsPlainText -Force
Set-ADAccountPassword -Identity "svc_sql_prod" -Reset -NewPassword $pw
# 3) Assign a plausible SPN (use setspn if preferred)
setspn -S MSSQLSvc/sql-prod-01.corp.example:1433 corp\svc_sql_prodKeep the password uncrackable. The point is not to give attackers a weak credential—it’s to generate an alert the moment they start harvesting tickets.
6) Decoy privileged groups and role bait
Attackers love groups because groups are leverage. A decoy group is designed to trigger when someone tries to add themselves, nest another group into it, or modify ownership/ACLs to gain control.
Examples that attract attacker attention
Tier0-Admins,Backup-Operators-Prod,GPO-Deploy-SoftwareVPN-Admins,Privileged-App-Support,Helpdesk-LAPS-Readers
Make it realistic, but inert
- Keep membership empty (or include only a disabled “sentinel” account)
- Do not grant rights via GPO/user rights assignment to this group
- Configure auditing so that group change events are immediately alerted
Group changes often happen through delegated admin patterns. If your environment uses granular delegation, map where changes should be legitimate using: GPO Delegation in AD. The more precisely you define “who should be able to change what”, the higher-signal your decoy alerts become.
7) ACL / directory object tripwires (SACL + auditing)
Decoys aren’t only identities. You can create tripwire objects that should never be modified or even read in certain ways, and then enable auditing (SACL) to log access.
Tripwire ideas that don’t add operational risk
- A “fake” OU that looks like it contains sensitive servers (but is empty)
- A decoy GPO with an attractive name (but no linked scope and no settings)
- A decoy “admin share” folder on a decoy endpoint with auditing enabled
- A “bait” group policy preference item placeholder (never deployed) that triggers on access attempts
To reason about what’s possible here, it helps to understand how permissions and inheritance are evaluated on directory objects: Active Directory Permissions Explained.
8) What to alert on: logs and signals that matter
Decoys only work if they generate actionable alerts. At a minimum, wire these signals into your SIEM/IDR:
- Any logon involving decoy users (success or failure) from non-approved hosts
- Kerberos ticket activity for decoy SPNs (TGS requests are especially useful)
- Group membership changes involving decoy groups
- Repeated name resolution / SMB / RDP attempts toward decoy computer names
- Directory object access events on tripwire OUs/GPOs (where you’ve enabled auditing)
Practical correlation ideas
- Decoy trigger + unusual source host + recent privilege discovery activity = escalate severity
- Decoy trigger + account just created or recently reset = check for compromised admin workflow
- Decoy Kerberos ticket request + subsequent SMB/RDP scans = probable lateral movement stage
If you need to sanity-check whether a signal could be “normal”, start with your authentication baseline: NTLM and Kerberos explained.
9) Response playbook: what to do when a decoy fires
Treat a decoy hit as a credible incident until proven otherwise. The workflow below keeps you fast and disciplined.
- Validate the trigger: which decoy object, which event type, which source host/IP, which account.
- Scope blast radius: search for adjacent suspicious events from the same source in a +/- 30 minute window.
- Contain: isolate the source endpoint (EDR), disable or reset the involved account if needed, block lateral movement paths.
- Hunt: check for enumeration, privilege group changes, SPN ticket harvesting, and abnormal logon patterns.
- Eradicate and recover: remove persistence, rotate exposed credentials, validate GPO/ACL integrity.
- Improve: turn the incident into new detections (more decoys, better alerting, better segmentation).
When responders are under time pressure, “simple” issues (like lockouts) can mask attacker activity. Keep your troubleshooting muscle sharp with: How to resolve an AD account lockout issue.
10) Common pitfalls (and how to avoid them)
- Decoys that are too obvious: “honeypot-admin-01” is not deception; it’s signage.
- Decoys that create real privilege: never grant rights “for realism”. Realism is in metadata and placement, not in power.
- No alert ownership: if no one’s on the hook to respond, decoys become noise.
- Maintenance blind spots: OU restructuring, naming changes, or new admin tooling can accidentally touch decoys—design for stability.
- Over-collection without context: more logs aren’t better unless they drive confident decisions.
A strong deception program sits on top of strong admin hygiene. If your admin accounts are exposed, decoys won’t save you—only buy time. Keep this cornerstone handy: Securing administrator accounts in Active Directory.
11) Implementation checklist
- Define decoy goals: recon detection, Kerberoasting detection, lateral movement detection, privilege escalation detection
- Create 3–10 decoy objects to start: 1–2 decoy users, 1 decoy SPN service account, 1–2 decoy groups, 1 decoy computer
- Make them believable: correct OU placement, consistent naming, realistic attributes
- Make them safe: strong credentials, no real privilege, constrained logon rights
- Instrument: configure DC security auditing + forward logs to SIEM/IDR
- Alert: build rules keyed on the decoy identity list (tight conditions, high severity)
- Test: simulate an attacker—enumerate, request tickets, attempt logons—and verify alerts fire
- Operationalize: on-call path, ticket workflow, runbook, and quarterly validation
