How to Set Up Active Directory Honeypot Accounts That Detect Lateral Movement
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most lateral movement detection requires baselining normal behavior and alerting on deviations: an expensive, time-consuming process prone to false positives. Honeypot accounts reverse the problem: because no legitimate user ever authenticates as the honeypot, any authentication attempt is a guaranteed true positive.
This is a zero-cost, high-precision detection control that any organization running Active Directory can implement in 20 minutes. The implementation details matter: a poorly named or misconfigured honeypot account generates false positives or goes unnoticed by attackers. Here is the complete setup.
Step 1: Create the Account with the Right Identity
The honeypot account needs to look legitimate to an attacker performing LDAP reconnaissance. Attackers scan AD for high-value targets: accounts with names that suggest administrative access, service accounts, or legacy accounts that might have weak passwords.
Effective naming patterns:
svc-backup(suggests backup service account: attackers target these for Domain Admin paths)legacy-admin(implies reduced security oversight on older accounts)sql-reporter(common service account type, often over-privileged)helpdesk-readonly(sounds like a real functional account)IT-admin-2019(year suffix implies it was set up and forgotten)
Avoid names that are obviously fake (honeypot, trap, decoy) or that do not match your organization's naming conventions. If your real service accounts are named svc-[function], name the honeypot svc-[function] too.
Account settings in Active Directory Users and Computers:
Account is disabled: NO (must be enabled to attract authentication attempts)Password never expires: YES (avoids false positive notifications from expiry-checking tools)User cannot change password: YESAccount is sensitive and cannot be delegated: YES (prevents Kerberos delegation abuse)- Password: set a strong random 20-character password. It should never be used. Store it in your password manager under a label that makes clear it is a honeypot.
Description field: Make it sound real. 'SQL Server Reporting Services read-only access account. Managed by IT Operations. Do not delete.' This description appears in LDAP query results and makes the account more convincing to automated tools that enumerate AD.
Do not add the account to any security groups. Zero group memberships means zero actual access. If an attacker compromises this account, they get nothing. The alert is the entire value.
Step 2: Ensure Audit Policy Logs Authentication Attempts
The honeypot account only generates alerts if the relevant audit events are being logged. Verify your domain-level audit policy includes the following:
Via Group Policy Management: Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Account Logon
Enable:
Audit Kerberos Authentication Service: Success and FailureAudit Kerberos Service Ticket Operations: Success and FailureAudit Credential Validation: Success and Failure
And under: Logon/Logoff:
Audit Logon: Success and Failure (generates Event ID 4624 and 4625)
Verify the policy is applied:
gpresult /r | findstr /i "audit"
auditpol /get /subcategory:"Kerberos Authentication Service"
If audit policy is already configured for your domain, these may already be enabled. If you are not collecting any Windows security events in a SIEM, the honeypot account creates a forcing function to start: the alert has no value if no one receives it.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Step 3: Create the SIEM Alert Rules
The following event IDs are the primary alert triggers. Configure one alert rule per event ID targeting the honeypot account's SamAccountName.
Event ID 4625 (Failed logon): Triggered when any system attempts to authenticate as the honeypot account and fails. This is the most common trigger during lateral movement: an attacker with a credential list is trying passwords against accounts found via LDAP enumeration.
Alert rule logic (generic format):
EventID = 4625
AND TargetUserName = "svc-backup" // your honeypot account name
Severity: High. Response: immediate alert to SOC or on-call.
Event ID 4771 (Kerberos pre-authentication failed): Triggered when an attacker attempts to request a Kerberos ticket for the honeypot account without the correct password. This is the Kerberos equivalent of Event ID 4625 and often appears before a successful pass-the-hash or AS-REP roasting attempt.
EventID = 4771
AND TargetUserName = "svc-backup"
Event ID 4768 (Kerberos ticket request): Triggered when a Kerberos TGT is requested for the account. A successful TGT request (Result Code 0x0) against the honeypot account means an attacker has the correct password or hash: treat this as a Critical alert.
EventID = 4768
AND TargetUserName = "svc-backup"
AND Status = "0x0" // success
Severity: Critical.
Event ID 4624 (Successful logon): This should never occur for a honeypot account. If it does, it means an attacker has successfully authenticated. This is your highest-priority alert.
EventID = 4624
AND TargetUserName = "svc-backup"
Severity: Critical. Immediately escalate.
Step 4: Exclude Known False Positive Sources
Before enabling alerts, identify and exclude the systems that will generate false positives against your honeypot. Common sources:
Password expiry notification tools: Some user management tools enumerate all user accounts and check password age. If these tools attempt to authenticate or query the honeypot account, they generate noise. Identify the service account these tools run as and either exclude those authentications or configure the tools to skip accounts marked with User cannot change password.
Legacy authentication sweeps: Some backup software, monitoring agents, or compliance scanners perform broad authentication tests across all accounts. Identify these systems by their IP addresses and exclude them from the alert by source IP.
Active Directory health check tools: Tools like DCDiag and similar third-party products enumerate all accounts. Exclude their source IPs.
How to identify false positive sources before going live: Enable audit logging for the honeypot account but configure the alert in a 'detect only, do not alert' mode for 72 hours. Review all Event ID 4625/4771 events for the honeypot account. Any source that appears is either a legitimate tool generating false positives or an attacker: investigate each one. After 72 hours, add confirmed legitimate sources to your exclusion list and enable the alert.
Once tuned, the remaining triggers should be zero per day. Any event that passes the exclusion filter is a true positive.
Optional: Extend With Planted Credentials
The account-only honeypot catches authentication-based lateral movement. To also catch credential harvesting and LSASS dumping, plant fake credentials referencing the honeypot account in locations attackers commonly look.
In a network share accessible to standard users:
Create a file named legacy-config.txt or db-credentials-old.txt containing a line like:
BACKUP_ACCOUNT=svc-backup
BACKUP_PASSWORD=<the actual honeypot password>
When an attacker finds this file, harvests the password, and attempts to use it, the 4625/4768 alert fires. The attacker is moving. You have their timing, source IP, and target system.
Canary tokens in Microsoft Office documents: Services like Thinkst Canary Token allow you to generate a Word document that fires a web request when opened, giving you the opener's IP without requiring any AD interaction. Place these in shared drives labeled with names that suggest sensitive content.
These extended techniques are optional. The base account and alert rule implementation is the mandatory starting point.
The bottom line
An Active Directory honeypot account costs nothing, takes 20 minutes to implement, and produces zero false positives once tuned: because no legitimate user or system ever authenticates as the account. The entire detection capability comes from naming the account convincingly, enabling the correct audit policy, and configuring four event ID alert rules in your SIEM. Any alert that fires is an attacker performing lateral movement or credential stuffing. Start with the base account before adding planted credentials.
Frequently asked questions
What is an Active Directory honeypot account?
An Active Directory honeypot account is a deliberately created user account with a convincing name, no group memberships, and no legitimate use. Because nothing in your environment ever authenticates as this account, any authentication attempt against it is an immediate indicator of an attacker performing lateral movement, credential stuffing, or AD reconnaissance.
Which Windows Event IDs should I alert on for a honeypot account?
Alert on Event ID 4625 (failed logon) and 4771 (Kerberos pre-auth failure) at High severity, and Event ID 4624 (successful logon) and 4768 with Result Code 0x0 at Critical severity. The Critical alerts mean the attacker has valid credentials for the honeypot account.
How do I create an effective Active Directory honeypot account?
Name the account something an attacker would target during AD reconnaissance: 'svc-backup', 'admin-old', or 'helpdesk-admin' are common patterns. Set a complex, unique password that is not used anywhere else. Do not add the account to any security groups. Set the description to something plausible like 'Backup service account - DO NOT DELETE'. Disable the account from interactive logon (set Login Hours to none) but keep it enabled for authentication attempts. Set the password to never expire so the account remains stable as a detection anchor. Document the account in your CMDB as a security control so future AD administrators do not delete it.
What is the difference between a honeypot account and a canary token?
An Active Directory honeypot account is a user object that generates authentication events when an attacker attempts to use it. A canary token is a tracked resource (a file, URL, or credential) that generates an alert when accessed or executed. Both are deception-based detection mechanisms. Honeypot accounts detect lateral movement and credential stuffing. Canary tokens can be placed inside documents, scripts, or configuration files to detect when an attacker accesses sensitive file shares or executes staged payloads. Canary.tools and Thinkst Canary provide hosted canary token infrastructure; manual implementations use web request tokens embedded in files.
How many honeypot accounts should I create and where?
Create at least two to three accounts per domain with different naming conventions representing different account types: a service account pattern, a personal admin account pattern, and an IT helpdesk pattern. Place the accounts in the Users container rather than a dedicated OU to make them appear to belong to a real environment. For organizations with multiple sites or OUs, create one honeypot account per major OU to ensure visibility across different discovery queries an attacker might run against different parts of the directory.
How do I prevent an Active Directory honeypot account from being deleted by other administrators?
Protecting the honeypot account from accidental deletion requires two steps. First, enable the 'Protect object from accidental deletion' checkbox in Active Directory Users and Computers by opening the account properties, navigating to the Object tab, and checking the protection box. Second, document the account in your CMDB or IT asset management system with a clear label indicating it is a security control and must not be deleted or modified without approval from the security team. Add a description field note such as 'SECURITY CONTROL: Do not disable or delete without approval from IT Security' to the account object itself, which appears in LDAP query results and serves as a reminder for administrators performing routine AD cleanup. If your organization runs periodic AD cleanup scripts that remove stale or unused accounts, add explicit logic to exclude accounts tagged as security controls, or maintain a protected-accounts list that those scripts check before taking action. The final protection is regular verification: include the honeypot account in your monthly AD audit checklist to confirm it exists, is enabled, has no group memberships, and its SIEM alert rule is still active.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.