Honeypots & Deception in AD
Honeypot accounts and deception objects in AD provide high-confidence attack detection — any interaction with them is guaranteed to be malicious because no legitimate user or application ever touches them.
Most detection methods have a false-positive problem — legitimate activity that looks like an attack. Honeypots solve this completely. You create a fake service account with an SPN (like "MSSQLSvc/sqlprod01") that no real application uses. If anyone requests a Kerberos ticket for it, that is 100% Kerberoasting. You create a fake Domain Admin account named something tempting. If anyone tries to authenticate as it, that is 100% an attacker. You plant fake credentials in memory or in files. If anyone uses them, that is 100% lateral movement from a compromised machine. The beauty of deception is its certainty: any interaction is malicious by definition.
Police sometimes leave an unlocked car with the keys in the ignition in a high-crime area, wired with cameras and a GPS tracker. Anyone who takes the bait is definitively a car thief — there is zero false-positive risk. AD honeypots work the same way: you create tempting-looking accounts (fake service accounts with SPNs, fake Domain Admin accounts) that no legitimate user ever accesses. Any authentication attempt or query against them is guaranteed to be an attacker doing reconnaissance or attempting an attack.
Try It Yourself
Key Takeaways
- Honeypot accounts provide near-zero false-positive attack detection.
- Any interaction with a honeypot is guaranteed malicious — no legitimate user ever touches them.
- Deploy honeypot SPNs to detect Kerberoasting, honeytoken admins to detect enumeration.
- Combine with SACLs and SIEM alerting for real-time notification.
- Deception is one of the highest-value, lowest-cost security investments in AD.
In a world of noisy security alerts and false positives, honeypots stand out as a uniquely reliable signal. A single honeytoken can detect sophisticated attackers that evade every other detection method.