Active Directory Deception: Detecting Identity Attacks

Active Directory is a database that every authenticated account is allowed to read, which means the reconnaissance phase of an identity attack is authorized by design and generates no error, no denial, and nothing to alert on. Deception works here by planting objects in that readable map which no legitimate process will ever authenticate as, request a ticket for, or log into, so the attacker's first real decision becomes the detection.

The directory will tell an intruder where the privilege is. What it will not tell them is which of those accounts is bait.

Why identity attacks are the hard case

Lateral movement at least involves a connection between two machines. An identity attack can be a sequence of entirely legitimate protocol operations: an LDAP query that any domain user may run, a Kerberos ticket request the KDC is supposed to honor, a replication call from an account that holds replication rights. Nothing is exploited. The attacker is using the directory exactly as designed, with a credential that works.

That breaks the usual detection model in two places. The signature model has nothing to match, because there is no malicious payload. The behavioral model has a baseline problem, because the operations in question are performed constantly by administrators, service accounts, backup agents, inventory scanners, and the identity tooling itself. Domain controller logs are the highest-volume, lowest-specificity source most teams own: turn on the events that would catch directory enumeration and you get millions of rows a day, nearly all of them legitimate.

So teams filter, and the filters are written against what normal looks like, and the attack is made of normal.

A decoy object inverts the economics. It has no legitimate population to baseline against. No service authenticates as it, no human logs in with it, no scheduled task requests a ticket for it. The question stops being "was this directory operation appropriate" and becomes "did anything at all touch this object."

Read, choose, act

An identity attack has three stages, and only the last two can be detected cleanly. Blurring them is what produces decoys placed as though reading the directory were itself the alert.

Read. The attacker enumerates: accounts (T1087.002), groups (T1069.002), domain trusts (T1482), and the relationships between them. Attack-path mapping tooling does this as a bulk LDAP collection and then solves the graph offline. Your decoy objects are returned by the same query that returns the real ones, because they are in the same directory. But a read is not a touch. The attacker pulled ten thousand objects and yours were three of them, and that is not evidence of anything.

Choose. They look at the graph and pick a target. This is the step deception actually attacks, and it is where decoy design matters more than decoy count. The graph gives them attributes to rank by: a service principal name worth roasting, a password set four years ago, membership in something that sounds like tier-zero, adminCount set, a description field that reads like it was written by someone careless. An object built to score well on that ranking gets picked early, because the attacker has no way to validate it short of using it.

Act. They authenticate, request a ticket, read the secret, or forge something. Now there is a record with no innocent explanation. A TGS request for a decoy service principal, a logon attempt with an account that has never had a session, a certificate enrollment for an identity that enrolls for nothing: each of these is a single event you can page on, not a correlation you have to build.

The honest version of the pitch is that deception does not detect reconnaissance. It makes reconnaissance lead somewhere.

The identity attack surface, by technique

The IDs are here so you can line this up against your existing coverage map. Where this page overlaps the movement protocols, that ground is covered in lateral movement detection; this one is about the credential material and the directory itself rather than the road between hosts.

Kerberos ticket theft and roasting (T1558). Kerberoasting (T1558.003) requests a service ticket for an account with a service principal name and cracks it offline. The request itself is a normal KDC operation, which is why detection usually depends on volume heuristics or encryption-type downgrades. A decoy account with an SPN removes the ambiguity: a service ticket request for a service that does not exist has exactly one explanation. AS-REP roasting (T1558.004) targets accounts with Kerberos preauthentication disabled, so a decoy account with preauth deliberately off is a lure that only an attacker scanning for that property will find. Golden tickets (T1558.001) and silver tickets (T1558.002) sit further on and are a different problem, covered below.

Credential dumping from the directory (T1003). DCSync (T1003.006) abuses replication rights to pull password material without touching a domain controller's disk; NTDS extraction (T1003.003) takes the database itself. These are near-catastrophic and under-detected. The deception angle is narrow but real: once an attacker has the hashes, they have your decoy accounts' hashes too, and those are the credentials with no production use. The dump is invisible; spending it is not.

Forged and stolen certificates (T1649). Certificate-based authentication has become a favored path because a certificate outlives a password reset. An identity that never legitimately enrolls, requesting or presenting a certificate, is an unambiguous event.

Alternate authentication material (T1550). Pass the hash (T1550.002) and pass the ticket (T1550.003) skip the password, which defeats anything assuming a person typed something. The decoy identity does not care how it was authenticated, only that it was.

Valid accounts (T1078.002). The baseline problem in one technique ID. A domain account used by its owner and a domain account used by an intruder produce the same event. Decoy accounts are the subset of domain accounts where that is not true.

Account manipulation and policy modification (T1098, T1484). Adding a member to a privileged group, modifying a Group Policy Object (T1484.001), or adding or altering a domain trust (T1484.002) to make authentication flow somewhere it should not. Decoy groups are useful here precisely because they look like a worthwhile place to add yourself.

Directory backdoors (T1134.005, T1207). SID-History injection writes a privileged SID into an account's SID-History attribute so the privilege travels with a token that looks ordinary. Registering a rogue domain controller (T1207) creates server and nTDSDSA objects in the configuration partition and lets an attacker inject and replicate arbitrary changes into the directory. Both are persistence mechanisms that survive password rotation, and both are the reason the section below exists.

Credentials in Group Policy and on disk (T1552.001, T1552.006). Passwords in logon scripts, in SYSVOL, in Group Policy Preferences, in a share nobody audits. This is the cheapest breadcrumb placement there is, because the attacker is already looking in those exact locations and the artifact is an inert line of text. Nothing is installed on the production system.

Placement table

If you build two rows, build the roastable decoy account and the breadcrumb credential row. Both fire during the attacker's planning phase, before any privilege has actually been gained, which is the only point at which the response is cheap.

What the SOC receives

The test of an identity alert is whether an analyst can act on it without first writing a correlation search across domain controller logs. A decoy alert names the object touched, the operation, the source, and where the identity material was planted:

severity    : high
decoy       : svc_sql_rpt  (decoy service account, SPN set, no sessions on record)
event       : Kerberos TGS-REQ for decoy SPN
enc type    : RC4-HMAC  (downgrade requested)
source      : 10.22.8.117  (WS-FIN-0442, user jdelgado)
identity    : jdelgado  (domain user, valid session)
note        : decoy SPN has never been requested by any host

The useful part is the last two lines together. The account doing the roasting is a real user with a real session, so every identity signal about it reads as normal, and the only reason this is on screen is that the target was never real. Alerts arrive enriched and deduplicated in the tooling the SOC already runs, including Splunk, Microsoft Sentinel, IBM QRadar, and Google Chronicle.

After the directory is already owned

If an intruder has the KRBTGT hash, they can mint tickets for any identity, including identities that do not exist, and the KDC will accept them. No decoy prevents that. What decoys still provide is the behavior afterward: forged tickets get used, and they get used against targets chosen from the same enumerated directory. An attacker with a golden ticket who presents it to a decoy host has given you a confirmed-compromise signal, with the one property forged-ticket detection usually lacks, which is a target you control and can reason about.

The same logic covers the persistence cases. A rogue domain controller injects changes, but someone eventually authenticates as the backdoored identity, and that authentication has to arrive somewhere. Placement decides whether "somewhere" is instrumented.

This is also why decoy objects should not be the only control on this path. Tiered administration, limiting replication rights, and protecting the accounts that can write to the configuration partition are preventive, and deception is not a substitute for any of them.

Next to EDR, identity tooling and SIEM

Deception adds a layer. The boundaries are what make it worth buying.

EDR is better on any host where it is installed: process lineage, in-memory credential access, what ran after arrival, and blocking. It is strongest exactly where deception is blind, which is on the production endpoint. It is weakest where the activity is a protocol operation against a domain controller rather than something executing locally.

Identity threat detection and UEBA tooling own the authentication record. They are the right place for impossible travel, privilege-change tracking, and account-wide risk scoring, and they cover every account rather than the handful you planted. They work on probability, which is their strength when you need breadth and their weakness when you need something an on-call analyst can act on at 3 AM without a judgement call.

SIEM is where this lands. Deception does not reduce your log sources; it adds one with an unusually high signal-to-noise ratio. That makes it the rare source where automated escalation is defensible, which matters most for the domain controller events that are too voluminous to escalate on their own.

The honest limits. A decoy account that no attacker ranks highly detects nothing, so decoy design is not a one-time provisioning task: an object with a never-changing password and no login history for three years is distinguishable by an attacker who is paying attention. Your own tools will reach decoy objects, because vulnerability scanners, identity hygiene tools, and attack-path assessments all enumerate the directory and some of them will try to authenticate, so write down the expected benign triggers and who owns them before an analyst meets them at 3 AM. An attacker who compromises one workstation and never looks at the directory will not trip anything. And an alert nobody owns is decoration, which is a process problem rather than a product one.

Where to start

The cheapest honest test takes one account. Create a decoy service account with an SPN, give it the attributes that make an attacker rank it first, and leave it alone. Then run your own roasting attempt from a normal workstation and check two things: whether the alert fires, and whether it arrives with the requesting user and host attached rather than as a line in a domain controller log you have to go find.

Decoy Management provisions, blends, and retires those assets from one control plane, with coverage planned against MITRE ATT&CK so placement follows the techniques you are actually exposed to. For the movement step that usually follows a stolen identity, see lateral movement detection; if the outcome you are defending against is encryption at scale, see ransomware early detection. For deception as a detection layer in general, see a practical guide to modern cyber deception, and for why credential-and-native-binary attacks are the hardest ones to catch, scaling living off the land engagement.

See it running on your directory.