Why does a honey account — a decoy Active Directory user nobody uses — alert with higher fidelity than a behavioural rule?
answer
- precision by design, not by tuning
- nothing legitimate should ever touch it
- no baseline, no threshold needed
- isolation must be maintained, not assumed
- fires only if they walk into it
basics
~20 sThe fidelity comes from the asset, not the rule. Nothing legitimate should ever touch an account no person or service uses, so a single interaction is abnormal by construction — no baseline, threshold or tuning required.
solid answer
~50 sA behavioural rule has to separate malicious use of a real thing from normal use of the same thing, so it inherits a false-positive rate and needs baselines and re-tuning. A honey account removes the legitimate side of that distribution: no script embeds it, no service runs as it, no human signs in with it, so the detection can be as blunt as "any authentication attempt naming this account" and still be precise. That precision is a property of placement, not cleverness — the decoy must be discoverable by the enumeration an adversary performs and reachable by nothing else. The moment a credentialed scanner, an inventory crawler or a cleanup job can reach it, you have manufactured a recurring benign source and the fidelity is gone. And a fire proves interaction with the bait, not intent: I still have to establish who touched it.
go deeper
Be ready to say in one sentence why bait is high fidelity: nothing legitimate uses it, so any touch is abnormal by construction and needs no threshold. Then add that a fire means interaction, not proof of malice.
Explain the mechanics: a behavioural rule must split malicious from normal use of a real object and inherits a false-positive rate; bait has no legitimate population, so the rule is trivial and its precision comes from placement and isolation.
Show you treat isolation as something maintained. Name the legitimate touchers that erode it — credentialed scanners, inventory crawlers, cleanup sweeps — and explain why fixing placement beats writing an exclusion an adversary can wear.
Own the portfolio argument: bait buys precision, not coverage, so decide how much of the detection budget goes to tripwires on enumeration paths versus telemetry-based detection, and who is accountable for keeping the decoys unreachable.
## What bait is A honey account is an Active Directory user object created for no purpose except to be touched by someone who should not be touching it. It runs no service, no scheduled task uses it, no script embeds its credential, no human signs in with it. Its whole value is negative space: because there is no legitimate use, there is no legitimate signal, and the detection over it can be as blunt as "any authentication attempt naming this account". ## Where the fidelity actually comes from A conventional behavioural detection has a hard job. The activity it watches — a remote service being created, a script interpreter spawning from a document, a sign-in from an unusual place — also happens during real work. The rule has to draw a line through a distribution that contains both populations, so it inherits a false-positive rate, needs a baseline, needs thresholds, and needs re-tuning every time the estate changes. Bait deletes the distribution. There is no legitimate population to separate from, so the rule needs no threshold and no learning period, and its precision does not decay when a new deployment tool arrives next quarter. That is the inversion worth saying out loud in an interview: **the fidelity lives in the asset, not in the rule**. You did not write a cleverer detection; you built an object whose only possible interaction is one you want to know about. ## What a fire proves, and what it does not A fire proves interaction with the decoy — a credential was presented for it, a service ticket was requested for it, a decoy document was opened. It does not prove intent and it does not prove an adversary. Three legitimate touchers reach bait routinely if you let them: - a credentialed vulnerability scanner that authenticates broadly across the estate; - an asset-inventory or identity-governance crawler that enumerates every directory object; - an IT administrator running a stale-account cleanup sweep. Each produces a real fire from a real interaction — the detection did not malfunction — which is why bait alerts still get worked for *who* and *how* rather than simply believed. ## Placement is the control you maintain Isolation is not a one-time property. The decoy must be discoverable by the same enumeration an adversary performs — a directory query for accounts carrying a service principal name, a browse of the file server's share list, a listing of a documents share — and reachable by nothing else. If its name appears in a configuration file, a password-vault entry, a runbook, a monitoring check or a scanner's target list, legitimate machinery will touch it, and the detection you built precisely so that it would never need tuning acquires a recurring benign source. From there you either fix the placement or you start writing exclusions, and every exclusion is a shape an adversary can wear. ## Coverage is the trade you accept Bait's weakness mirrors its strength: it fires only when the adversary walks into it. A detection over real telemetry sees whatever crosses that telemetry wherever the adversary steps; bait sees nothing at all unless the specific path crosses the specific object. So bait is not a substitute for detection engineering. It is a cheap, high-precision tripwire laid across paths you expect enumeration to cross, and its value is decided by where you put it rather than by how many of them you have. ## The same contract generalises A decoy share that appears in the share list but is referenced by no mapped drive; a document inside it carrying a token that calls home when opened; a decoy DNS name; a credential seeded in a browser's saved passwords. All of them share one design contract — a thing whose only reader is someone enumerating — and all of them fail the same way, by quietly becoming reachable through legitimate automation. ## What a strong answer sounds like "Its precision is structural. Nothing legitimate uses the account, so I need no baseline and no threshold — any authentication attempt naming it is abnormal by construction, and it stays precise as the estate changes. That only holds while the account is genuinely unreachable by legitimate work, so the engineering effort goes into placement: discoverable by enumeration, invisible to scanners, crawlers and cleanup jobs. And the fire is evidence of interaction, not of malice."
- If bait is so precise, why not replace behavioural detections with a hundred honey accounts?Because precision is not coverage. Bait fires only when the adversary happens to touch that specific object, so a hundred decoys still see nothing if the intrusion path never crosses them. Behavioural detections watch activity that occurs wherever the adversary steps. Bait is a cheap tripwire laid on expected enumeration paths, not a replacement for telemetry-based detection.
- What single change most often destroys a honey account's fidelity?Letting legitimate automation reach it — typically by adding the decoy to a credentialed scanner's scope, an inventory crawler's discovery source, or a password vault. That converts a zero-noise signal into a recurring benign fire, and the usual reflex, an exclusion for the scanner's identity or source host, hands an adversary a documented shape to operate inside.
- Does a honey account fire tell you an intrusion is under way?No. It tells you something interacted with an object nothing should interact with. That is a strong lead, but the toucher can be a scanner, a governance crawler or an administrator tidying up. The interaction is the fact; the actor and the intent still have to be established before you call it an intrusion.
A tripwire in an empty corridor nobody has reason to walk down. You do not need to tell footsteps apart from other footsteps — you only need to be sure the cleaners were routed somewhere else.
saying these in an interview costs you the question
- Says a honey account fire is proof of an adversary
- Thinks the fidelity comes from a clever rule rather than the object
- Assumes bait needs tuning like any other detection
- Treats bait as broad coverage rather than a narrow tripwire
- Documents the decoy in the CMDB or runbook where anyone can read it