Honeytokens and decoy accounts in Active Directory and Entra ID: catching the attacker before they move

The first thing an attacker does after landing on a Windows network is ask the directory questions. Who the administrators are, which accounts carry passwords set years ago, which ones have a Kerberos service principal name attached, and from which workstations the admin accounts log on. Active Directory answers all of it for an authenticated user with no special rights and, in most environments, raises no alarm, because querying the directory is a legitimate operation that happens millions of times a day.

If one of those answers is an account that looks valuable but has no legitimate use at all, then any interaction with it is hostile by definition. That is the idea behind a honeytoken, of which the decoy account is the commonest case: an asset built to deceive, whose only job is to report whoever touches it. This article covers which decoys work in Active Directory and Entra ID, how to build them so they pass inspection, which native tooling watches them, and where they belong in a detection programme.

What is a honeytoken, and why does it catch what other rules miss?

MITRE D3FEND lists the technique as Decoy User Credential (D3-DUC): a credential created for the purpose of deceiving an adversary, paired with an analytic that fires when someone uses it. The definition is short because the mechanism is simple. A conventional detection rule hunts for anomalies amid millions of legitimate events, which is why it produces false positives and needs constant tuning. A decoy flips the problem: the asset has no legitimate traffic, so the rule becomes "a single event on this object" and the false-positive rate tends towards zero. Our glossary explains how this differs from a full honeypot.

That shift in logic has two practical consequences. The first is cost: a domain account and a few lines of correlation in the SIEM are a fraction of what it takes to tune a behavioural detection. The second is fidelity: when the decoy fires, the event carries the name of the account that touched it and the address of the machine the access came from. A suspicion becomes a concrete starting point for response.

What does an attacker look for in Active Directory, and where should the decoy go?

Sean Metcalf, a leading authority on Active Directory security, describes the reconnaissance sequence an attacker follows with plain user rights. First they identify privileged accounts, often through the AdminCount attribute, which the directory sets to 1 on every account that has been in a protected group. Next they filter for old passwords. Then they look for privileged accounts with a Kerberos service principal name (SPN), because any domain user can request a service ticket for that SPN and try to crack the password offline. Finally they query network sessions to learn which workstations the admin accounts are being used on.

Each of those steps is a question to the directory, and each question can be given a prepared answer. The bait goes exactly where the attacker will look: an account with AdminCount set to 1, a password from years back and an SPN pointing at a service nobody runs. It is the same reconnaissance we walked through when explaining how Active Directory tiering stops a compromised laptop reaching the domain controller; the decoy adds a detection layer on top of that containment architecture.

Four decoy accounts and honeytokens that work in Active Directory and beyond it

An account with a fake SPN to catch Kerberoasting

This is the highest-yield decoy in a Windows domain. Metcalf documented it in 2017: create a user account, give it a unique SPN that matches no existing service (an invented SQL instance name, say) and set AdminCount to 1 so it looks privileged, without adding it to any privileged group (the attribute is cosmetic) and with a long random password that cannot be cracked offline. Because no such service is running, no business process will ever request a ticket for it. If a domain controller logs event 4769 with that service name, someone is Kerberoasting, and the Client Address field shows where the request came from.

The advantage over generic Kerberoasting detection is certainty. Filtering 4769 events for RC4 encryption (type 0x17) cuts millions of events down to hundreds or thousands, but still demands judgement to separate the unusual from the malicious. With the fake SPN the question disappears: a single request, once the authorised scanners you already know are discounted, is enough to escalate the incident.

An account that never signs in, to catch password spraying

Password spraying tries one password against every user, then pauses before the next one so no account locks out. Detecting it by correlating failed sign-ins is noisy, because people mistype. TrustedSec proposes the alternative for Active Directory and for Entra ID: an account for a person who has never worked at the organisation. No employee will ever try to sign in with it, so almost every attempt, successful or not, comes from someone working through the user list.

Two operational details matter. In Active Directory, when the spray runs over Kerberos the failure may not appear as 4625; you also need to audit 4771 (Kerberos pre-authentication failure). In Entra ID, the sign-in log for that account shows error code 50126 when the password is wrong. If it is right and the account is under an MFA requirement with no method registered, the code is 50079; if there is no MFA requirement, the same attempt shows up as a successful sign-in (code 0). That is why the Entra ID decoy must hold no licences and no permissions. The log also supplies the source IP and geolocation.

Decoy credentials in SYSVOL: the password nobody should read

The third type is not an account but a piece of data that looks like a credential. Metcalf suggests creating in SYSVOL (the share every domain controller exposes) a folder named after a GUID that matches no existing Group Policy object, with an audit entry (SACL) on it. Inside can sit an XML file carrying an invented Group Policy Preferences password. No business process reads a policy that was never created; whoever opens it is hunting for stored passwords in SYSVOL, a classic privilege escalation technique. The fake password written into an account attribute, covered further down, belongs to the same family.

Canary tokens outside the domain: AWS keys, files and the sign-in page itself

Decoys are not confined to Active Directory. Thinkst runs Canarytokens, a free service that generates, among other things, a pair of genuine AWS API keys issued so that any use raises an alert: leave them in a private repository or on a developer's laptop and, if anyone uses them against the AWS API, the alert arrives. AWS activity logging adds a delay of between 2 and 30 minutes. Equivalent tokens exist for Word and Excel documents, network folders, Kubernetes configuration files and MCP configuration files (Model Context Protocol, the standard that connects tools to AI models).

One of them deserves particular attention from anyone running Microsoft 365. The Entra ID login token is installed as a stylesheet in the tenant's company branding. Browsers load it when rendering the sign-in page; if the requesting site is not a Microsoft domain, someone is serving a copy of your page from a server in the middle. It is a direct detection of adversary-in-the-middle session hijacking, which no password control sees because the user types the correct password into the fake page.

Making the decoy look genuine, and what gives it away

An experienced attacker checks an account before attacking it, and Metcalf lists the tells: a recent creation date, no sign-in since creation, a password never changed, no ordinary user account matching the supposed admin, and an SPN whose computer name is nowhere in the forest. If creation date, last password change and last logon all line up, the account smells of a trap.

The fake privileged account has to age like the others. Reuse an old, forgotten account, stripped of its groups and permissions, rather than creating a new one; if its password has to be reset so you can use it, the password-change date becomes today and the account will need months before that age matches the other service accounts, so the earlier it is prepared the better.

Log on with it now and then via a scheduled task, so the last-logon attributes hold believable values. Create the ordinary user account that would accompany an administrator. And above all, do not let it be the only weak account in an otherwise spotless directory: if it stands out too much, the attacker walks past it.

That periodic logon carries two obligations: exclude it from the rules by machine and time window, and never extend it to the spraying decoy, which must never log on at all.

Metcalf draws one hard line: do not use a Domain Admins account with valid, recoverable credentials as bait, because if that account's protection is anything short of perfect the decoy becomes the route to domain compromise.

There are three safe options. First, a random password that cannot be guessed: enabling the smart-card logon option sets one automatically, and it can be disabled afterwards; with this option no periodic logon is possible and the password-change date resets to today, so the account has to be left to age and look forgotten.

Second, a fake password written into an attribute such as the description, with alerting on any authentication attempt. Third, a real password that only works on specific machines via LogonWorkstations, taking care that every listed machine exists in the directory: by default a user can join up to 10 computers to the domain, and a non-existent computer name in that list is an escalation path, because anyone able to join a computer under that name can use the account. The last two options allow the scheduled task; the first does not.

Honeytokens in Defender for Identity and Defender XDR: what they already watch

Microsoft Defender for Identity includes the Honeytoken tag for users and devices: an authentication by a tagged entity raises an alert, and Microsoft also documents an alert for LDAP queries against those entities (the SAM-R variant was retired in June 2024, and Microsoft points to custom detections built on advanced hunting queries). It is set in the Defender XDR portal under Settings > Identities, and it is the fastest route for an organisation that already has the sensor on its domain controllers.

Two cautions. If the tagged account is the one a scheduled task logs on with, every run will raise the alert, so exclude it or reserve the tag for accounts that never log on. And what the tag does not cover is the 4769 ticket request or the SYSVOL read; for those, keep your own SIEM rules and check the alert documentation for what the tag covers in your version.

Microsoft also announced a deception capability in Defender XDR, with automatically generated decoy accounts and hosts and lures planted on user devices. At the time of writing, the documentation for that feature redirects to automatic attack disruption, so confirm the actual state of the capability in your tenant before relying on it.

Without extra licences, four SIEM rules are enough: 4769 carrying the decoy's service name, 4625 or 4771 carrying the name of the account that never signs in (plus 4776 if the spray runs over NTLM against a domain member), 4663 on the GUID folder in SYSVOL, and in Entra ID every sign-in record for the decoy account.

The third requires file system auditing on the domain controllers and exclusions for the system, replication and antivirus accounts that do read SYSVOL.

The difficulty lies in getting those sources into the SIEM; we have covered in detail which logs to send and which to leave out.

Where deception fits in a detection programme

A honeytoken does not replace behavioural detection; it complements it where that detection is weakest: internal reconnaissance with user rights. Nor does it replace attack surface reduction: if the domain is still full of accounts with SPNs and passwords from 2012, the bait competes with live targets that are just as easy.

Its natural home is inside detection engineering, with the same cycle as any other analytic: hypothesis, deployment, testing and maintenance. Testing is the part most often neglected. A Red Team exercise that trips no decoy, or that identifies every one of them, is a sign the bait is not fooling anyone. Maintenance is continuous: the decoy accounts' attributes have to keep looking alive, and the accounts need reviewing whenever the password policy changes or the domain is migrated.

The response when the alert fires belongs in a playbook as well. An event on a decoy identifies a compromised account and machine with high confidence, so containment can be immediate: isolate the device, revoke the source account's sessions and start investigating the initial access and any lateral movement that preceded it. In the threat hunting and managed SOC services at Hard2bit Cybersecurity, decoys are among the few sources we treat, once legitimate origins are excluded, as confirmed positives without triage.

What honeytokens cannot do

Deception has clear limits. A careful actor checks the attributes described above and, if the account fails the check, leaves it alone; the decoy then detects nothing, but it does no harm either. Whoever already holds administrator credentials needs no reconnaissance and is unlikely to touch the bait. Third-party tokens depend on their infrastructure receiving the call, with whatever delay that involves. And a poorly protected decoy adds risk instead of removing it. With those caveats, the accounts and rules described here take an afternoon to set up, though getting the sources into the SIEM may take longer; going without them means not knowing that reconnaissance has already begun.

Hard2bit has supported organisations in detecting and responding to intrusions in Microsoft environments since 2013, and holds Spain's ENS (National Security Framework) High-category certification and five ISO standards, including ISO 27001:2022.

This analysis is provided for informational and defensive purposes and reflects the information available on its publication date; Microsoft Defender features and the third-party services cited may change, so always verify the details against the official documentation. The decoy accounts, detection rules and configurations described should be validated in a test environment and adapted to your directory before being applied in production; a poorly protected decoy can become a route to compromise. They do not replace an assessment specific to your environment. If you want to review detection in your Active Directory or Entra ID, you can talk to the Hard2bit team.