Most internal penetration tests don't start with a zero-day. They start with a domain controller running default settings. Active Directory is the backbone of nearly every mid-sized organization's IT infrastructure, which is exactly why attackers target it first. When the DC is misconfigured, the entire network is at risk — not because of a missing patch, but because of choices made during deployment that nobody ever revisited.
This article breaks down the most common Domain Controller misconfigurations that security teams encounter in the field, the ones that consistently turn a critical asset into an easy target for any attacker with a foothold on the local network.
LLMNR and NBT-NS: the protocols that betray your users
LLMNR (Link-Local Multicast Name Resolution) and NBT-NS are Windows name resolution protocols enabled by default. When a workstation fails to resolve a hostname through DNS, it broadcasts a query to the entire network segment. Any host can respond — including a malicious one.
This is the core mechanism behind tools like Responder. An attacker simply listens for these broadcast queries, responds to them, and captures NTLMv2 hashes from users attempting to authenticate. Those hashes can be cracked offline or relayed directly to gain access to other systems, without ever needing the plaintext password.
Disabling LLMNR through Group Policy and suppressing NBT-NS at the interface level are straightforward changes with virtually no operational impact in modern environments. There's no good reason to leave these enabled.
SMB Signing and protocol versions: two problems that often appear together
SMB is deeply embedded in any Active Directory environment. It handles file shares, domain controller connections, GPO application, and replication. It's also one of the most abused protocols for lateral movement.
Missing SMB Signing
Without SMB signing, an attacker positioned between two hosts can execute an NTLM relay attack. The concept is straightforward: intercept a legitimate authentication attempt and replay it against a different target to gain unauthorized access. In practice, combining Responder with ntlmrelayx in relay mode can compromise file shares or entire machines without any additional user interaction.
SMB signing should be set to required on all domain controllers, and enforced across the entire estate where possible. Modern Windows servers support it natively. The only edge case involves some legacy NAS devices or older third-party appliances that don't implement it properly — those need to be addressed separately.
SMBv1 still running in production
SMBv1 should not exist in any current production environment. It lacks modern encryption and robust signing, and it's the protocol that EternalBlue exploited to fuel some of the worst ransomware outbreaks in recent memory. Yet it still shows up regularly, usually kept alive by a legacy application or aging network device.
Disabling SMBv1 is a PowerShell command or a GPO setting away. If a business application still requires it, that's a project prioritization conversation, not a reason to leave it running.
Misconfigured accounts and delegations in Active Directory
The Domain Controller also exposes everything in the directory. Several default or inherited configurations create direct privilege escalation paths that attackers know well.
Kerberoasting and unprotected service accounts
Any service account registered with a Service Principal Name is a potential Kerberoasting target. Any authenticated user in the domain can request a Kerberos ticket for that account — a ticket encrypted with the account's password hash. If the password is weak, it falls to an offline cracking attempt in minutes.
The fix is to use Group Managed Service Accounts (gMSA). Passwords are automatically generated, long, and rotated without human intervention. They can't be requested or cracked by standard users.
Unconstrained Kerberos Delegation
When a machine or account is configured with unconstrained delegation, it stores Kerberos tickets from any user who connects to it — including domain administrators. An attacker who compromises that system can extract those tickets and move laterally through the network, potentially all the way to the DC itself.
Other overlooked attack vectors
Beyond the obvious protocol-level issues, several less visible settings significantly expand the attack surface of any Active Directory environment.
- Unpatched systems vulnerable to Zerologon (CVE-2020-1472), which allowed unauthenticated attackers to reset the DC machine account password and take full control of the domain.
- Overly permissive ACLs on AD objects: regular users with write access to privileged groups, GPOs, or even the DC object itself — often the result of permissions granted for a specific project and never revoked.
- NTLMv1 still accepted by domain controllers. NTLMv2 should be enforced as a minimum, and Kerberos should be preferred wherever authentication flows allow it.
- Identical local administrator passwords across all workstations, making lateral movement trivial once a single machine is compromised. LAPS solves this problem cleanly.
How to approach Domain Controller hardening
Hardening an Active Directory environment isn't a one-time project — it's an ongoing practice. It starts with auditing what's actually configured, not what the deployment documentation says should be configured. Those two things are often very different.
Tools like BloodHound map privilege escalation paths in existing directories and help prioritize remediation based on real-world impact. The CIS Benchmark for Windows Server provides a structured starting point for systematic hardening.
For SOC teams, detecting these attack patterns requires monitoring Kerberos events (4769, 4771), unusual SMB connection patterns, and LLMNR traffic on the network. A SIEM properly fed with DC logs can surface these behaviors before they escalate into a full domain compromise.
Frequently asked questions
Why is LLMNR dangerous in an Active Directory environment?
LLMNR allows any host on the local network segment to respond to name resolution queries. An attacker can intercept those queries, capture NTLMv2 hashes from users trying to authenticate, and either crack them offline or relay them to gain access to other resources — without ever knowing the plaintext password.
What's the difference between disabled SMB signing and SMBv1?
They're two separate issues. Missing SMB signing enables NTLM relay attacks, where a legitimate user's authentication is hijacked and redirected to a different target. SMBv1 is an outdated protocol version that lacks modern encryption and was exploited by critical vulnerabilities like EternalBlue. Both need to be fixed, but they address different risk categories.
Is a fully patched domain controller enough to stay protected?
Patches address known vulnerabilities, but they don't fix misconfigurations. A fully updated DC with LLMNR enabled, SMB signing disabled, and poorly delegated accounts remains highly exposed. Patching is necessary — it's just not sufficient without a rigorous configuration audit alongside it.
How do you detect a Kerberoasting attack on a Domain Controller?
Kerberoasting generates event ID 4769 in Windows security logs, specifically with RC4 encryption type (0x17). An unusual spike in these requests, or requests originating from accounts that wouldn't normally generate them, are reliable signals to monitor in a SIEM or dedicated detection platform.