What makes an Active Directory decoy account carrying an SPN believable to an adversary who checks before biting?

## The check the bait has to survive A decoy service account only works if the adversary spends a request on it. Anyone enumerating the directory for accounts that carry a service principal name gets back a list, and the list is triaged before it is used: which of these look like they belong to a real, running, valuable service? Effort goes to the plausible ones. So the design problem for a deception owner is not "can this be found" but "does this survive being looked at". An account carrying a service principal name is bait specifically because that attribute makes it requestable by ordinary domain users, and the directory records that request — you get a signal without the adversary ever needing to reach a host you own. The attribute is the hook; believability is what makes the hook get taken. ## The attributes that betray a decoy The tells are almost always freshness and isolation: - **Creation date and password age.** An account created this week, or whose password was set the day the sweep runs, is obviously not running anything. Real service accounts in most estates have passwords months or years old. Create the decoy well before you need it, or at least during a batch of real account creations, and let it age. - **Never-used.** An object with no recorded prior authentication reads as abandoned or synthetic. - **Empty context.** No description, no owner, no company or department, no group memberships. Real service accounts accumulate lineage; decoys are usually born bare. - **Wrong neighbourhood.** Sole occupant of a container nobody else lives in, or sitting in the default users container while every real service account lives in a dedicated organisational unit. - **Naming that breaks the convention.** If real accounts read `svc-sql-prd-04`, then `svc_test_account1` is a flag, and anything containing *honey*, *canary*, *decoy* or *trap* is a gift. - **A service principal name pointing nowhere.** If the value names a host that does not resolve or an application nobody has heard of, the account describes a service that does not exist. ## Building the lineage deliberately Mirror a real peer and change only what must change. Same organisational unit, same naming pattern, same description style, same `managedBy`, membership of a group real service accounts belong to — chosen so it confers no meaningful access. Point the service principal name at a host that exists in DNS, ideally one that genuinely runs something of that class. Give the surrounding story a reason to exist: a description referencing a reporting database is more inviting, and more plausible, than a blank field. ## The last-logon problem, and the exclusion it creates Making the account look *used* is the hardest part, because the only way to update its last-logon is to authenticate as it — which is the very event you are detecting. Teams that do this schedule a benign authentication from one known host and carve that exact combination out of the detection. Understand the cost before you agree to it: you have created a documented exclusion (this identity, from this host, on this schedule), and an exclusion is a shape an adversary can operate inside. If you accept it, pin every element of the tuple and alert when any of them deviates, so the carve-out is itself a detection. Many teams decide a plausible age and rich context are enough and leave last-logon alone. ## Look valuable, be worthless The temptation is to make the bait irresistible by giving it real privilege — privileged group membership, rights on a real server. Do not. Bait is an account whose credential material an adversary may try to recover offline, and a decoy that is genuinely privileged converts your tripwire into an access path you handed over. Value should be entirely in the *appearance*: the group name, the description, the service principal name. Set a long random password so recovery is impractical, and keep the account's actual rights at the floor. ## Believable also means undocumented An adversary inside the estate reads what your staff read. If the decoy appears in the password vault, the configuration management database, a monitoring check, a joiners-and-leavers spreadsheet or the SOC's own wiki tagged as a decoy, then the same enumeration that finds the account finds the answer. Deception has to be recorded somewhere — that is a real operational need — but not in the systems an intruder reaches first. ## What a strong answer sounds like "I clone the attribute profile of a real service account: same organisational unit, same naming convention, populated description and owner, a group membership real ones have, a password aged into the same band, and a service principal name for a host that actually resolves. It looks valuable and holds no privilege, and it exists in no vault, CMDB or runbook — because the adversary reads those too."