Active Directory Penetration Testing: What Attackers Find in Enterprise Networks

Active Directory (AD) is the backbone of identity in most large enterprises — it authenticates users, enforces group policies, manages access to resources, and underpins virtually every business-critical system on their networks. When AD is compromised, the attacker doesn't just gain access to one system — they gain access to everything: email, file shares, databases, cloud resources federated through Azure AD Connect, and every endpoint joined to the domain.

Most organizations assume their Active Directory is secure because it functions correctly. Users can log in, group policies apply, DNS resolves. But "working" and "secure" are entirely different states. In our network penetration testing engagements, AD misconfigurations are the single most common path from initial foothold to full domain compromise — and they exist in nearly every environment we test.

This guide walks through how penetration testers actually attack Active Directory, what we find in real-world engagements, and what your organization should do about it.

Why Automated Scanners Miss AD Vulnerabilities

If your security program relies on vulnerability scanners like Nessus, Qualys, or Rapid7 to assess Active Directory security, you are missing the majority of exploitable weaknesses. This is not a criticism of those tools — they are excellent at what they do. But what they do is check for known CVEs and missing patches. Active Directory vulnerabilities are overwhelmingly logic-based, not patch-based.

Consider what a scanner checks versus what a penetration tester checks:

• Scanner: "Is MS17-010 patched on this host?" Pentester: "Can I relay NTLM authentication from this host to the domain controller because SMB signing isn't enforced?"
• Scanner: "Is this server running an outdated TLS version?" Pentester: "Does this service account have unconstrained delegation configured, allowing me to capture and reuse Kerberos TGTs from any user that authenticates to it?"
• Scanner: "Are default credentials in use?" Pentester: "Can I Kerberoast 47 service accounts and crack 12 of their passwords offline because they use RC4 encryption and weak passphrases?"

The difference is fundamental. Scanners test for vulnerabilities in software. Penetration testers test for vulnerabilities in configuration, architecture, and trust relationships. In Active Directory, the latter category is where the real risk lives. This is precisely why manual penetration testing is not replaceable by automated scanning — especially in AD-heavy environments.

The AD Attack Kill Chain

A realistic Active Directory attack doesn't happen in a single step. It follows a methodical progression — sometimes called the "attack kill chain" — where each phase builds on the previous one. Here is how it typically unfolds in a professional penetration test.

Phase 1: Initial Access

Every AD compromise starts with a foothold. In a penetration test, we simulate the methods real attackers use to gain that first set of credentials or that first code execution on a domain-joined machine:

• LLMNR/NBT-NS Poisoning: When a Windows machine fails to resolve a hostname via DNS, it falls back to broadcast protocols (LLMNR and NBT-NS) that ask the entire local network "does anyone know where this is?" An attacker on the same network segment responds: "That's me." The victim machine then sends its NTLMv2 authentication hash to the attacker. Using tools like Responder, we capture these hashes and crack them offline. In most environments, we capture credentials within minutes of connecting to the network.
• Password Spraying: Rather than brute-forcing a single account (which triggers lockout), we test one or two common passwords against every account in the domain simultaneously. Passwords like "Company2026!" or "Winter2026" are discovered with alarming frequency. One valid credential is all we need.
• Phishing (simulated): A well-crafted phishing email delivers a payload that establishes a command-and-control session on a workstation. From there, we extract cached credentials from memory using tools like Mimikatz.

Phase 2: Enumeration

Once we have a single domain user credential — even a low-privileged helpdesk account — we can enumerate the entire Active Directory structure. AD is designed to be readable by all authenticated users by default. This is a feature, not a bug, but it provides attackers with a complete map of the environment:

• BloodHound: This tool queries AD via LDAP and builds a graph database of every user, group, computer, GPO, OU, and trust relationship in the domain. More critically, it calculates the shortest attack paths from any compromised account to Domain Admin. In complex environments, BloodHound often reveals attack paths that would take a human analyst days to identify manually.
• SPN Enumeration: We query AD for all Service Principal Names (SPNs), which identify service accounts. These accounts are Kerberoasting targets — and service accounts frequently have weak passwords because they were created years ago and never rotated.
• DACL/ACE Analysis: We examine Discretionary Access Control Lists to find accounts with dangerous permissions like GenericAll, WriteDACL, WriteOwner, or ForceChangePassword over privileged accounts or groups. These permissions often exist because of legacy migrations or administrative shortcuts.
• Group Policy Analysis: We inspect GPOs for stored credentials (Group Policy Preferences), overly permissive configurations, and logon script contents that reveal additional attack surfaces.

Phase 3: Privilege Escalation

With enumeration complete, we know exactly which attack paths are available. The most common privilege escalation techniques in AD environments include:

• Kerberoasting: Any authenticated domain user can request a Kerberos service ticket (TGS) for any SPN in the domain. The ticket is encrypted with the service account's password hash. We extract these tickets and crack them offline — no failed login attempts, no account lockouts, no alerts. If the service account password is weak (and it often is), we now have credentials for an account that frequently has elevated privileges.
• AS-REP Roasting: Accounts configured with "Do not require Kerberos preauthentication" allow us to request encrypted authentication data without even knowing the password. We crack this data offline, just like Kerberoasting.
• Unconstrained Delegation: Servers configured with unconstrained delegation store the Kerberos TGT (Ticket Granting Ticket) of every user that authenticates to them. If we compromise such a server, we can extract TGTs and impersonate any user — including Domain Admins — who has connected to that machine.
• DACL Abuse: If our compromised account has GenericAll permissions over a privileged group, we can simply add ourselves to that group. If we have WriteDACL, we can grant ourselves GenericAll first, then add ourselves. These permission chains are invisible to users but clearly visible in BloodHound graphs.

Phase 4: Lateral Movement

With escalated credentials, we move through the network to reach high-value targets:

• Pass-the-Hash (PtH): NTLM authentication allows us to authenticate using a password hash directly — no plaintext password needed. If we extract a local administrator hash from one workstation and that same local admin password is reused across the environment (common without LAPS), we can access every workstation in the domain.
• Overpass-the-Hash: We use an NTLM hash to request a Kerberos TGT, then use that TGT for lateral movement. This blends with normal Kerberos traffic and is harder to detect than raw NTLM pass-the-hash.
• PsExec/WMI/WinRM: With valid administrative credentials, we use legitimate Windows administration tools to execute commands on remote systems. Because these are built-in tools using authorized credentials, they blend perfectly with normal administrative traffic.

Phase 5: Domain Dominance

The final escalation targets the domain controllers themselves:

• DCSync: With Replicating Directory Changes permissions (held by Domain Admins, Enterprise Admins, and the domain controller machine accounts), we simulate a domain controller replication request and extract every password hash in the domain — including the krbtgt account hash. This requires no malware on the DC, generates minimal logs, and is extremely difficult to detect without specific monitoring.
• Golden Ticket: With the krbtgt hash, we forge Kerberos TGTs for any user, including non-existent users with arbitrary group memberships. A Golden Ticket is valid for the lifetime of the krbtgt password — which, in many organizations, has never been changed since the domain was created. This provides persistent, undetectable domain access.
• Silver Ticket: Using a service account hash, we forge service tickets for specific services without touching the domain controller. This is useful for targeted access to specific systems while minimizing detection.

Phase 6: Persistence

In a real attack (not a penetration test), the attacker establishes multiple persistence mechanisms to survive remediation attempts:

• AdminSDHolder Manipulation: Modifying the AdminSDHolder ACL grants persistent access to all protected groups. The SDProp process reapplies these permissions every 60 minutes, overwriting manual cleanup attempts.
• Machine Account Creation: By default, any domain user can add up to 10 machine accounts to the domain. These accounts have their own credentials, don't follow standard password policies, and are rarely audited.
• GPO Modification: Modifying Group Policy Objects to include startup scripts, scheduled tasks, or registry changes provides persistence that is enforced by the domain infrastructure itself.

We document these techniques in our report so your team understands the persistence risk and can verify complete remediation.

What We Actually Find in AD Penetration Tests

Theory is useful, but real-world findings drive remediation. Across our Active Directory penetration testing engagements, these are the most common — and most impactful — findings we report:

• Kerberoastable service accounts with weak passwords: Service accounts with weak, crackable passwords are among the most common findings in Active Directory assessments. Many of these accounts have Domain Admin equivalent privileges or access to sensitive databases. Service account passwords are often set once during initial deployment and never rotated, and they frequently use predictable patterns.
• Unconstrained delegation on non-DC servers: Application servers, web servers, and even workstations configured with unconstrained delegation. Each one is a credential theft opportunity — and the vast majority have no business need for this configuration.
• Domain Users with local admin on workstations: When every domain user is a local administrator on their workstation, any single compromised user credential immediately yields local admin access, enabling credential extraction from memory, lateral movement, and further escalation.
• Legacy NTLM authentication enabled everywhere: NTLMv1 still enabled in some environments. NTLM relay attacks possible because SMB signing is not enforced on non-DC servers. LDAP signing not required. Each of these is a credential interception vector.
• Excessive privileged group membership: Organizations with 30, 50, or even 100+ members in Domain Admins. Every unnecessary DA account is an attack target. We routinely find service accounts, application accounts, and accounts of former employees in privileged groups.
• GPP (Group Policy Preferences) passwords in SYSVOL: Despite Microsoft deprecating this feature in 2014 (MS14-025), we still find encrypted passwords in SYSVOL Group Policy Preferences XML files. The encryption key was published by Microsoft — these passwords are trivially recoverable.

For organizations in regulated industries — financial services firms subject to NY DFS 500 or healthcare organizations under HIPAA — these findings represent both security risks and compliance violations that auditors and examiners are increasingly asking about.

Defense Strategies: Hardening Active Directory

Identifying vulnerabilities is only valuable if it drives remediation. These are the highest-impact hardening measures we recommend based on what we find in the field:

1. Implement a Tiered Administration Model

Microsoft's Enhanced Security Administrative Environment (ESAE) — commonly called the "Red Forest" model — separates administrative privileges into three tiers:

• Tier 0: Domain controllers, AD infrastructure, and the accounts that manage them. These accounts never touch Tier 1 or Tier 2 systems.
• Tier 1: Servers, applications, and cloud infrastructure. Managed by dedicated Tier 1 admin accounts.
• Tier 2: Workstations, printers, and end-user devices. Managed by helpdesk and desktop support accounts.

The principle is simple: compromise of a workstation (Tier 2) should never yield credentials that can access a server (Tier 1) or domain controller (Tier 0). Without tiered administration, a single compromised workstation often leads directly to Domain Admin through cached credential extraction.

2. Deploy LAPS (Local Administrator Password Solution)

LAPS randomizes the local administrator password on every domain-joined machine and stores it securely in AD. This eliminates pass-the-hash lateral movement using shared local admin passwords — one of the most common attack paths we exploit.

3. Disable NTLM Where Possible

Enable and enforce SMB signing on all servers. Require LDAP signing and channel binding. Audit NTLM usage with Group Policy settings, identify applications still requiring NTLM, and systematically migrate them to Kerberos. Block NTLMv1 entirely — there is no legitimate reason for it in a modern environment.

4. Use the Protected Users Security Group

Members of the Protected Users group cannot authenticate via NTLM, cannot use DES or RC4 encryption, cannot be delegated, and have their TGT lifetime reduced to 4 hours. Add all privileged accounts to this group. It eliminates multiple attack vectors simultaneously.

5. Audit Kerberos Delegation Settings

Inventory every account and computer object with unconstrained delegation, constrained delegation, or resource-based constrained delegation configured. Remove unconstrained delegation from everything except domain controllers. Convert remaining delegation to resource-based constrained delegation with specific target services defined.

6. Harden Service Accounts

Use Group Managed Service Accounts (gMSAs) wherever possible — they have automatically rotated, 240-character random passwords that are uncrackable. For service accounts that cannot use gMSAs, enforce 25+ character passwords, use AES encryption only (disable RC4), and rotate on a defined schedule.

7. Regular AD Health Assessments

Active Directory environments drift. New service accounts are created, delegation settings are added for "temporary" application requirements, and privileged group membership creeps upward. Conduct AD security assessments at least annually — ideally quarterly for high-risk environments. Pair these with architecture hardening engagements to implement the findings systematically.

What Your AD Pentest Report Should Contain

A legitimate Active Directory penetration test is not a scanner export. When evaluating pentest firms, ensure the deliverable includes:

• Attack path diagrams: Visual representations (typically from BloodHound) showing the exact path taken from initial foothold to domain compromise. These diagrams make complex attack chains understandable to both technical teams and executive leadership.
• CVSS-scored findings: Every finding scored with CVSS v3.1, including the specific vector string. This provides an objective, industry-standard severity rating that maps to your risk management framework.
• Evidence and proof of exploitation: Screenshots, command output, and sanitized credential hashes demonstrating each finding. This evidence is essential for compliance auditors and for your internal team to validate and reproduce findings in a controlled manner.
• Remediation priority matrix: Findings ranked not just by CVSS score, but by exploitability and business impact. A CVSS 7.5 finding with a publicly available exploit tool and direct path to domain compromise should be remediated before a CVSS 9.0 finding that requires physical access.
• Executive summary: A 1–2 page summary written for non-technical leadership: what was tested, what was found, what the business risk is, and what needs to happen next.
• Remediation verification: The best pentest engagements include a follow-up retest window — typically 30–90 days after the initial report — to verify that critical and high findings have been successfully remediated.

Secure Your Active Directory

Active Directory is the keys to your kingdom. If an attacker can compromise AD, they can access every system, every mailbox, every file share, and every database in your environment. The misconfigurations that make this possible are not theoretical — they exist in nearly every organization we test, and they are actively exploited by real-world threat actors every day.

Fortress MSSP provides comprehensive network penetration testing with deep Active Directory focus. Our experienced team uses the same tools and techniques as real adversaries — BloodHound, Mimikatz, Rubeus, Impacket — to map every attack path in your environment before a real attacker does.

Ready to find out what an attacker would find in your AD environment? Request a scoping call to discuss your Active Directory penetration test.