Domain Controller Security: What Attackers Know That You Don't

In Red Team engagements, the domain controller is almost always the final objective. Not because it's necessarily the easiest target, but because it's the most consequential. Control the DC, and you control everything: accounts, policies, trust relationships, and every password hash in the organization. It's the single point of failure that most Windows environments can't afford to expose — and yet regularly do.

This article walks through the real techniques used in penetration tests against Active Directory environments, with practical demonstrations and concrete defensive measures you can act on immediately.

Why Attackers Always Go for the DC

The domain controller holds the keys to the kingdom. It manages Kerberos authentication, enforces Group Policy, hosts the NTDS.dit database (which contains the NTLM hashes of every domain account), and maintains trust relationships with other domains. Owning the DC means owning the domain — permanently, if the attacker does it right.

Active Directory remains the backbone of enterprise IT in most organizations. That's not a weakness in itself. The weakness is when it's deployed without the defensive depth it requires.

Attack Techniques Red Teams Actually Use

1. Kerberoasting

Any authenticated domain user can request a Kerberos service ticket (TGS) for accounts with a registered Service Principal Name (SPN). That ticket is encrypted with the target account's password hash. The attacker takes the ticket offline and cracks it — no interaction with the DC required after the initial request.

# Using Rubeus to extract tickets
Rubeus.exe kerberoast /outfile:hashes.txt

# Offline cracking with Hashcat
hashcat -m 13100 hashes.txt wordlist.txt

The uncomfortable truth: if a service account has a weak password or one that hasn't rotated in years, cracking takes minutes. And in most environments, there are more Kerberoastable accounts than anyone realizes.

2. DCSync — Replicating Secrets Without Touching the DC

DCSync abuses Active Directory's own replication protocol. Any account with Replicating Directory Changes All rights can impersonate a domain controller and request a replication of password hashes — including the krbtgt account hash.

# Mimikatz DCSync
lsadump::dcsync /domain:corp.local /user:Administrator

# Impacket from Linux
secretsdump.py domain/user:password@dc_ip

What makes this particularly dangerous is that it requires no interactive session on the DC. The attacker never logs in. They just need the right privileges on a compromised account — and those privileges are granted far too broadly in most environments.

3. Golden Ticket — Persistent Domain Control

Once you have the NTLM hash of the krbtgt account, you can forge any Kerberos ticket in the domain, for any user, with any group membership, and any expiration date. This is a Golden Ticket.

# Forging a Golden Ticket with Mimikatz
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /ptt

The persistence is near-absolute. Reset the Administrator password — it doesn't matter. The forged tickets remain valid. The only real fix is to rotate the krbtgt password twice, which invalidates all outstanding tickets.

How to Actually Defend Your Domain Controller

• Implement the Tiering Model. Never manage your DC from a standard workstation. Use dedicated Privileged Access Workstations (PAWs) that are isolated from the rest of the network. Administrative access to Tier 0 assets should only happen from Tier 0 devices.
• Clean up your service accounts. Every SPN is a potential Kerberoasting target. Migrate to Group Managed Service Accounts (gMSA), which rotate their own passwords automatically and can't be cracked offline.
• Audit replication rights. Run BloodHound against your own domain before an attacker does. Look for any non-DC accounts with Replicating Directory Changes All. There should be none.
• Enable Protected Users and Credential Guard. The Protected Users security group disables NTLM authentication, unconstrained Kerberos delegation, and credential caching for your most sensitive accounts. It's a quick win with real impact.
• Build detection around key event IDs. Windows event IDs 4768, 4769, 4771 (Kerberos activity), 4662 (object access in AD), and 4742 (computer account changes) are your early warning system. Feed them into your SIEM and write detection rules that actually fire.
• Rotate krbtgt regularly. Use Microsoft's official New-KrbtgtKeys.ps1 script. It handles the operational complexity and dramatically reduces your Golden Ticket exposure window.

What Red Team Engagements Keep Revealing

Across the majority of Active Directory penetration tests, domain controller compromise happens within 48 hours of initial access. The tools help, but the real enabler is consistently the same: overly permissive rights, stale service accounts, and no separation between administrative tiers.

BloodHound, run in read-only mode against your domain, will surface attack paths in minutes that your team never knew existed. It's not an attacker tool — it's a visibility tool. Every defensive team should be running it before someone else does.

If your Active Directory has never been tested under realistic attack conditions, that's the first gap to close. Not for compliance reasons — because the findings will change how you think about your environment.

Simulating these attack chains in a controlled range environment, before they happen in production, is exactly what separates organizations that detect intrusions early from those that discover them months later.