Defending with AD Tripwires - GOAD Walkthrough

Part 2 flips to the defender’s point of view. We deploy AD Tripwires inside the same GOAD lab and show how a small set of purpose-built tripwire accounts produces deterministic alerts the moment an attacker touches credential material. Purpose-built tripwire accounts (exposed credentials, Kerberoasting, AS-REP) seeded in AD light up the second an attacker pokes credential material. These tripwires work by watching Windows Security Events 4625, 4768, 4769, and 4771 for any reference to those accounts—any hit is attacker-only signal. This provides deterministic, low-noise telemetry that fires at the earliest step of the Attack Path and feeds right into Splunk Cloud, Microsoft Sentinel, or your SIEM/EDR.

Tripwire accounts are planted specifically to catch reconnaissance. They never hold privileges, are never tied to applications, and use long, random passwords so that any interaction is unambiguously hostile. Because these accounts are never used by production workflows, baseline noise rounds to zero. If they fire, someone is enumerating AD with malicious intent. AD Tripwires subscribes to a handful of Windows Security Events on the Domain Controller. Each alert contains the tripwire account, source host/user, Domain Controller, timestamp, and event payload that matters for triage. The three event families to watch are: Failed logons (4625 / 4771) — exposed-credential tripwires when someone tries the fake Description password; Service ticket requests (4769) — Kerberoasting tripwire SPNs requested for offline cracking; and Authentication ticket requests (4768 / optional 4771) — AS-REP tripwires where pre-auth is disabled. That is the entire playbook: plant the lures, monitor the four event IDs, forward the alerts to Splunk Cloud, Microsoft Sentinel, or your SIEM/EDR, and respond immediately.

In a GOAD (Game of Active Directory) environment, AD Tripwires were deployed to demonstrate how tripwire accounts surface attacker behavior. For instance, in Scenario 1, an Exposed Credentials Tripwire was deployed. The tripwire account details included: Account name: svc_backup_legacy, Description field: pw: iMhZFDkLYzR7nKaIhtuH, Actual password: Long complex randomly generated string (not iMhZFDkLYzR7nKaIhtuH), Group membership: Domain Users only (no privileges). During Lightweight Directory Access Protocol (LDAP) enumeration, the attacker harvests the Description field and attempts to authenticate with iMhZFDkLYzR7nKaIhtuH. When the attacker tries the fake password, the Domain Controller logs a failed logon: Key fields: Event ID: 4771 (Kerberos pre-authentication failed), TargetUserName: svc_backup_legacy, ServiceName: krbtgt/NORTH, FailureCode: 0x18 (bad password), Ticket Options: 0x40810010 (indicates pre-auth failure), Client Address: 192.168.57.100 (attacker host).

AD Tripwires are effective because they are deterministic, not heuristic: Tripwire accounts are dormant. Any touch is an attacker, period. They fire at the earliest point in the Attack Path: Alerts fire during reconnaissance/collection—well before domain admin or data access. They also offer low noise: No production services reference these accounts; allowlist your own security scanners and you’re done. For deployment, create the tripwire accounts exactly as listed above—no privileges, random passwords, enticing metadata/SPNs/pre-auth toggles. Enable DC auditing for 4625, 4768, 4769, and 4771. Forward those events (or the AD Tripwires alerts) into your logging pipeline. Test from a lab host: Intentionally trigger each tripwire to confirm alert routing, timestamps, and enrichment. Fold alerts into playbooks: Route as “Credential Access: Kerberos,” isolate the source, snapshot volatile data, and hunt for adjacent enu.

To read the complete article see: Full Article