AD Defense & Hardening
The blue-team mirror of the AD attack chain: tiering, LAPS, gMSA, honeytokens, and the specific detection signals for Kerberoasting, DCSync, and Golden Ticket attacks.
Learning Objectives
- → Apply the AD tiering model to limit lateral movement from a compromised low-tier account
- → Explain LAPS and gMSA as concrete mitigations against AD credential-reuse patterns
- → Identify detection signals for Kerberoasting, DCSync, and Golden Ticket attacks
- → Explain honeytokens as a detection strategy specific to AD environments
- → Apply an AD security baseline checklist covering the most common attacker-exploited misconfigurations
Why AD Defense Needs Its Own Lesson
"Active Directory Attacks" and the "Capstone CTF: Full AD Attack Chain" showed how Kerberoasting, DCSync, and Golden Ticket attacks chain together. Every one of those techniques has a concrete, well-understood defense — this lesson is the blue-team mirror image of that offensive content.
The AD Tiering Model
Microsoft's tiering model separates AD assets into tiers so a compromise at one tier can't cascade upward:
| Tier | Contains | Rule |
|---|---|---|
| Tier 0 | Domain controllers, AD itself, PKI, anything that can compromise the domain | Only Tier 0 admins log into Tier 0 assets, from a dedicated, hardened workstation |
| Tier 1 | Servers, applications | Tier 1 admins never reuse credentials on Tier 0 or Tier 2 |
| Tier 2 | End-user workstations | The most-exposed tier — assume compromise is a matter of when, not if |
The core rule that actually stops lateral movement: credentials for a higher tier never get typed on a lower tier's machine. This single practice is what prevents a phished workstation (Tier 2) from ever exposing a domain admin's (Tier 0) credentials in memory.
LAPS: Ending Shared Local Admin Passwords
Local Administrator Password Solution (LAPS) randomizes and rotates the local Administrator password on every domain-joined machine, storing each machine's current password in AD, readable only by authorized admins. Without LAPS, a single leaked local admin password (often identical across an entire fleet) turns one compromised workstation into "every workstation, instantly," via pass-the-hash.
gMSA: Service Accounts Without Human-Manageable Passwords
A Group Managed Service Account (gMSA) has its password automatically generated and rotated by AD, never known to or typed by a human — directly closing the "service accounts have old, weak, never-rotated passwords" weakness that Kerberoasting depends on.
Detecting the Attack Chain
| Technique | Detection signal |
|---|---|
| Kerberoasting | A burst of TGS requests for many different SPNs from one account in a short window (Event ID 4769 with RC4 encryption is a particularly strong signal, since modern Kerberos prefers AES) |
| DCSync | Directory Service Access events (Event ID 4662) requesting replication rights, sourced from a host that isn't a real domain controller |
| Golden Ticket | Kerberos tickets with anomalously long lifetimes, or a TGT presented for an account that has since been disabled |
Honeytokens: A Detection Strategy Unique to AD
A honeytoken account is a fake, unused account deliberately planted to look attractive to an attacker (e.g. named svc-backup-legacy, given a plausible-looking SPN) — any authentication attempt against it is, by definition, illegitimate, since no real process ever uses it. This turns Kerberoasting itself into a nearly zero-false-positive detection trigger: cracking and using a honeytoken's ticket immediately flags the attacker.
An AD Security Baseline Checklist
- Enforce the tiering model with Protected Users group membership for Tier 0 accounts (blocks NTLM authentication and limits ticket lifetime for those accounts)
- Deploy LAPS on every domain-joined machine
- Migrate service accounts to gMSAs wherever the application supports it
- Remove unnecessary SPNs and rotate any service account password that can't be migrated to a gMSA
- Restrict
Replicating Directory Changesrights to the minimum set of accounts that legitimately need them - Plant and monitor at least one honeytoken account per domain
Common Pitfalls
- Building a tiering model on paper but never actually enforcing it with technical controls (e.g. logon restrictions)
- Deploying LAPS but leaving pre-existing local admin passwords unrotated on machines it hasn't touched yet
- Assuming a longer Golden Ticket detection window is "good enough" — the whole point is catching it before the 10-year default lifetime makes remediation catastrophic
The tiering model's entire value comes from one enforced rule about where credentials are allowed to be typed.
What is the core rule that stops lateral movement in the AD tiering model?
A single leaked local admin password is dangerous specifically because it's usually identical across an entire fleet of machines.
What problem does LAPS solve?
A honeytoken has no legitimate purpose whatsoever — which is exactly what makes any interaction with it a reliable detection signal.
Why is any authentication attempt against a honeytoken account inherently suspicious?
💪 Exercises & Challenges
AD Defense & Hardening MCQ
Test your understanding of AD Defense & Hardening.
Design an AD Hardening Rollout Plan
An organization has no tiering model, no LAPS, and several service accounts with SPNs that haven't rotated passwords in years. Design a phased rollout plan (at least 4 steps, in priority order) to har
Confirm the Honeytoken Alert
A blue team deploys a honeytoken account named 'svc-legacy-backup' with a plausible SPN, used by nothing in production. Three weeks later, SIEM alerts fire: Event ID 4769 shows a TGS request for 'svc-