Diagram showing attacker touching tripwire accounts, Domain Controller writing Windows events, AD Tripwires generating alerts, and Security Information and Event Management (SIEM)/Endpoint Detection and Response (EDR) notifying analysts.

Defending with AD Tripwires: GOAD Walkthrough

Justin Cady

January 26, 2026

Attack Blogs, Attack Paths, Attack Research

From Attacker Story to Defender Story

Part 1, The Quiet Attack Path, showed how attackers enumerate Active Directory (AD), walked through the attacker’s first fifteen minutes inside GOAD (Game of Active Directory). The key lesson: native Kerberos and LDAP activity looks completely normal until it is too late. 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.

TL;DR

What are AD Tripwires? Purpose-built tripwire accounts (exposed credentials, Kerberoasting, AS-REP) seeded in AD to light up the second an attacker pokes credential material.
How they work: Watch Windows Security Events 4625, 4768, 4769, and 4771 for any reference to those accounts—any hit is attacker-only signal.
Why it matters: 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.
What we show: A GOAD walkthrough that pairs each tripwire account with the exact attacker move from Part 1 so you can see detection, event payload, and alert response end to end.

Setting the Stage: GOAD’s Real Victims

Before adding any tripwires, GOAD already contains vulnerable production accounts—the same ones our autonomous operations abused in Part 1.

Account	Why it is vulnerable	What the attacker does with it
`samwell.tarly`	Cleartext password exposed via SMB null session	Provides first authenticated domain foothold
`jon.snow`	Service account with SPN, weak password hygiene	Classic Kerberoasting target once a foothold exists
`missandei`	Kerberos pre-authentication disabled (legacy setting)	Enables unauthenticated AS-REP Roasting

These are “real” users. Touching them might blend into legitimate helpdesk noise, which is exactly why defenders struggle to spot the attack path. We introduce tripwire accounts to change the story.

The Tripwire Cast (Safe by Design)

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.

Tripwire Type	Bait the attacker sees	Signal we monitor
Exposed Credentials	Friendly Description field that “leaks” a fake secret	Failed logon (4771/4625) using the fake password
Kerberoasting	Legit-looking service account with a safe SPN	TGS request (4769) for that SPN
AS-REP Roasting	Account with pre-auth disabled	AS-REQ / TGT request (4768, sometimes 4771)

Because these accounts are never used by production workflows, baseline noise rounds to zero. If they fire, someone is enumerating AD with malicious intent.

Turning Recon into Deterministic Alerts

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:

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.
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.

GOAD Walkthrough — Three Mini-Stories

The examples below come from a GOAD (Game of Active Directory) environment—a widely used enterprise-style reference architecture for AD security validation. We deployed AD Tripwires alongside the existing GOAD infrastructure, then ran autonomous pentesting operations to demonstrate how tripwire accounts surface attacker behavior in real time.

Scenario 1: Exposed Credentials Tripwire

Attack Path

This attack path shows how quickly an exposed credentials tripwire account lights up:

00:00 → SMB null session (H3-2020-0007). Anonymous access to 192.168.57.11:445 yields discovery of the anonymous credential.
00:02 → Cleartext password exposure (H3-2023-0029). The session uncovers a cleartext password for samwell.tarly stored in an Active Directory attribute.
00:03 → Domain user ready. With valid credentials, the operator now has authenticated domain access to pivot into Kerberoasting or AS-REP Roasting.

Tripwire Configuration

AD Users and Computers showing tripwire account with fake password in Description field

Tripwire account details:

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)

What the Attacker Sees

During Lightweight Directory Access Protocol (LDAP) enumeration, the attacker harvests the Description field and attempts to authenticate with iMhZFDkLYzR7nKaIhtuH.

PowerShell output showing `Get-ADUser` returning Description with fake password

Attacker attempts a login using the password recovered from the account description.

Windows Security Event

When the attacker tries the fake password, the Domain Controller logs a failed logon:

Event Viewer showing Event ID 4771 with TargetUserName=svc_backup_legacy, ServiceName=krbtgt/NORTH, FailureCode=0x18 (bad password), ClientAddress=attacker IP

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)

Platform Alert

AD Tripwires alert dashboard showing exposed-credentials tripwire trip with source host, timestamp, and response guidance.

Tripwire type	Exposed Credentials
Tripwire ID	`svc_backup_legacy@north.sevenkingdoms.local`
Tripwire origin	`north.sevenkingdoms.local`
Source IP	`192.168.57.100`
DC observed	`DC01.north.sevenkingdoms.local`
Timestamp	`Oct 10, 2025 4:03 PM UTC`
Windows Event	`4771 Kerberos pre-authentication failed`
Guidance	“The actor failed logon using the Kerberos authentication protocol, indicating they might have used brute force or password guessing against the tripwire account.”