Active Directory Penetration Testing: What We Find in Nearly Every Engagement

Active Directory controls who can access what in most enterprise environments. It manages authentication, authorization, group policies, and trust relationships across every Windows domain on the planet. It is also, without exaggeration, the single most consistently misconfigured piece of infrastructure we encounter during penetration testing engagements.

Over the past several years, we have tested hundreds of Active Directory environments. The specifics vary, but the patterns are remarkably consistent. Default configurations that were never hardened. Service accounts with domain admin privileges. Password policies that haven't been updated since the domain was first stood up. Legacy protocols that broadcast credentials in cleartext across the network.

This article walks through what we actually find during AD penetration tests, how those findings chain together into full domain compromise, and what you can do to harden your environment before an attacker does it for you. If you are unfamiliar with how a penetration test works in general, start with our overview of what happens during a penetration test before diving into the AD-specific material here.

Why Active Directory is the number one target

Every attacker who lands on a corporate network asks the same question: where is Active Directory? The answer matters because AD is the central authority for identity in most enterprises. Compromise AD and you compromise everything it controls, which is usually everything.

There are several reasons AD environments are disproportionately targeted:

• Centralized control. A single domain admin account typically has full control over every server, workstation, file share, and application joined to the domain. One compromised credential can unlock the entire environment.
• Legacy by design. Active Directory was first released with Windows 2000. Many environments still run domain functional levels from 2008 or 2012, with backward-compatible protocols enabled for "compatibility reasons" that no longer exist.
• Configuration drift. AD environments accumulate technical debt over years. Administrators come and go, group memberships expand but never contract, service accounts get temporary privileges that become permanent, and GPOs layer on top of each other until nobody fully understands what's enforced.
• Implicit trust. Most organizations trust their internal network more than they should. Once an attacker has any foothold on the domain, they can query AD for an enormous amount of information: every user, every group, every computer, every trust relationship. That information is available to any authenticated user by default.
• High-value payoff. Domain compromise gives an attacker persistent, stealthy access to the entire organization. They can read email, exfiltrate data, deploy ransomware, or maintain a backdoor that survives individual machine reimaging.

The combination of centralized authority, legacy configurations, and high-value payoff makes AD the preferred target for both nation-state actors and financially motivated attackers. It is also why AD penetration testing is one of the most impactful assessments an organization can invest in.

Common AD misconfigurations we find

The findings below appear in the majority of AD environments we test. Some are well-known in the security community but remain unpatched in production. Others are subtler configuration issues that compound into serious risk.

Kerberoasting

Kerberoasting is arguably the most common AD attack we execute successfully. It exploits the way Kerberos authentication works with service accounts. Any authenticated domain user can request a service ticket (TGS) for any account that has a Service Principal Name (SPN) registered. That ticket is encrypted with the service account's password hash. The attacker takes the ticket offline and cracks it. No network traffic, no logs, no alarms.

The problem is not Kerberos itself. The problem is that most service accounts have weak passwords that were set once and never rotated. We routinely crack service account passwords in minutes using commodity hardware. When that service account happens to be a domain admin, or has privileges over sensitive systems, the entire domain falls.

AS-REP roasting

AS-REP roasting targets accounts that have Kerberos pre-authentication disabled. When this setting is turned off, an attacker can request an authentication ticket for that account without even knowing the password. The response from the domain controller contains data encrypted with the user's password hash, which can be cracked offline.

This configuration is sometimes enabled intentionally for legacy application compatibility, but more often it is enabled by accident or inherited from a migration. We find accounts with pre-authentication disabled in roughly 40% of the AD environments we test.

Unconstrained delegation

Delegation allows a service to impersonate a user when accessing other resources. Unconstrained delegation means a server can impersonate any user to any service. If an attacker compromises a server with unconstrained delegation, they can harvest Kerberos tickets for any user who authenticates to that server, including domain administrators.

The classic attack involves coercing a domain controller to authenticate to the compromised server (using techniques like PrinterBug or PetitPotam), capturing the DC's machine account ticket, and using it to perform a DCSync attack. This is a well-documented attack path that has been publicly known since 2018, yet we still find unconstrained delegation configured on servers that do not need it.

Weak GPO permissions

Group Policy Objects control security settings across the domain. If the permissions on a GPO are misconfigured, a lower-privileged user can modify the policy and push arbitrary settings or scripts to every machine in the GPO's scope. We have seen GPOs that apply to domain controllers writable by regular helpdesk users.

GPO abuse is particularly dangerous because the changes are applied automatically by the domain's own infrastructure. An attacker who modifies a GPO to deploy a scheduled task or startup script gets code execution on every machine the GPO targets, often with SYSTEM-level privileges.

LLMNR and NBT-NS poisoning

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are fallback name resolution protocols. When a Windows machine cannot resolve a hostname via DNS, it broadcasts a request on the local network asking "does anyone know where fileserverr is?" (note the typo). Any machine on the network can respond and claim to be that resource.

An attacker on the network responds to these broadcasts, redirects the requesting machine to their own system, and captures the NTLMv2 hash of the user attempting to authenticate. These hashes can be cracked offline or relayed to other services for immediate access.

LLMNR and NBT-NS have been the first step in the majority of our internal network penetration tests for years. Despite being a well-known issue with a straightforward fix (disable both protocols via GPO), we find them enabled in approximately 80% of environments.

SMB signing disabled

SMB signing ensures that SMB traffic between machines is authenticated and has not been tampered with. When SMB signing is not required, an attacker who captures an NTLM authentication request can relay it to another server and authenticate as that user. This is called an NTLM relay attack.

Combined with LLMNR poisoning, disabled SMB signing creates a direct path from network access to authenticated access on multiple systems. We capture credentials via LLMNR, relay them to a server without SMB signing required, and gain remote code execution. The entire chain, from network access to shell on a server, takes minutes.

The attack chain: from initial foothold to domain admin

Individual misconfigurations are concerning. The real risk emerges when they chain together. In nearly every AD engagement, we follow an attack chain that looks something like this. Understanding the chain is important because fixing any single link can break the entire path to domain compromise.

Step 1: Initial foothold

The engagement starts with some level of access. In a network penetration test, this might be a laptop plugged into a network port, VPN access with low-privilege credentials, or a compromised workstation from a phishing exercise. The starting point simulates what an attacker would have after gaining initial access through any means.

From this foothold, the first action is reconnaissance. We query Active Directory for the full list of users, groups, computers, trust relationships, GPOs, and organizational units. All of this information is available to any authenticated domain user by default. Tools like BloodHound visualize these relationships and automatically identify the shortest paths to domain admin.

Step 2: Credential harvesting

With network access, we begin capturing credentials. LLMNR/NBT-NS poisoning runs passively in the background, collecting NTLMv2 hashes from machines that make typos in hostname lookups or try to reach decommissioned servers. Simultaneously, we identify Kerberoastable and AS-REP roastable accounts and begin cracking those hashes offline.

Within the first few hours, we typically have a handful of cracked passwords. Many of these belong to service accounts that authenticate to multiple systems, giving us lateral movement opportunities.

Step 3: Lateral movement

With valid credentials, we move laterally across the network. This means authenticating to other systems using techniques like Pass-the-Hash, Pass-the-Ticket, or simply logging in with cracked passwords over SMB, WinRM, or RDP. Each system we access is a new opportunity to harvest additional credentials, find cached tokens, and discover new attack paths.

On a compromised workstation, we extract credentials from memory using tools like Mimikatz. If a domain admin recently logged into that workstation (for troubleshooting, for example), their credentials may still be cached in memory. One careless RDP session from an admin to a compromised machine, and the engagement is effectively over.

Step 4: Privilege escalation

The path from regular user to domain admin rarely requires a single jump. It is usually a chain of smaller escalations. A helpdesk account has local admin on a server. That server has a cached credential for an IT admin. That IT admin has write access to a GPO that applies to domain controllers. Each link in the chain is a small permission issue. Together, they form a highway to full domain compromise.

Step 5: Domain compromise

Once we achieve domain admin or equivalent privileges, we demonstrate the full impact. This typically includes performing a DCSync to extract every password hash in the domain, accessing sensitive file shares, reading executive email (with permission in scope), and demonstrating the ability to deploy code to every machine on the network. The goal is not to cause damage but to prove conclusively what an attacker with this level of access could do.

Privilege escalation techniques in detail

Several privilege escalation techniques appear repeatedly in our engagements. Understanding them helps defenders know what to monitor and what to block.

Golden Ticket attacks

A Golden Ticket is a forged Kerberos Ticket-Granting Ticket (TGT) created using the password hash of the krbtgt account. The krbtgt account is special: its hash is used to encrypt and sign every TGT issued by the domain controller. If an attacker obtains this hash (via DCSync or direct access to the DC), they can forge a TGT for any user, including non-existent users, with any group memberships they choose.

Golden Tickets are devastating because they bypass normal authentication entirely. The forged ticket is valid for the Kerberos ticket lifetime (default 10 hours, but the forged ticket can specify any duration). Even changing the compromised user's password does not invalidate a Golden Ticket. The only remediation is to reset the krbtgt password twice (it maintains a password history of two), which invalidates all existing tickets in the domain and requires every user and computer to re-authenticate.

Silver Ticket attacks

A Silver Ticket is a forged Kerberos service ticket (TGS) created using the password hash of a service account. Unlike a Golden Ticket, which grants access to everything, a Silver Ticket targets a specific service. For example, if an attacker has the hash of a SQL Server service account, they can forge a ticket granting them sysadmin access to that SQL Server.

Silver Tickets are harder to detect than Golden Tickets because the forged ticket never touches the domain controller. It is presented directly to the target service. There is no authentication event logged on the DC, making Silver Ticket usage nearly invisible to most monitoring solutions.

DCSync

DCSync abuses the domain controller replication protocol. Domain controllers replicate their databases with each other using the Directory Replication Service (DRS). An account with the "Replicating Directory Changes" and "Replicating Directory Changes All" privileges (typically Domain Admins and Domain Controllers) can request any user's password hash directly from a domain controller.

The attacker does not need physical or remote access to the domain controller. They simply issue the replication request from any machine on the network. The DC responds with the requested password hashes, including the krbtgt hash, which enables Golden Ticket attacks. DCSync is the standard final step in most of our AD engagements.

Pass-the-Hash

NTLM authentication in Windows does not require the plaintext password. The NTLM hash itself is sufficient to authenticate. An attacker who extracts a hash from memory, a SAM database, or a DCSync operation can use that hash directly to authenticate to other services without ever knowing the actual password.

Pass-the-Hash has been a known technique for over two decades. Modern mitigations exist (Credential Guard, Protected Users group, disabling NTLM), but most environments have not fully deployed them because legacy applications still depend on NTLM authentication.

Azure AD and Entra ID: cloud identity testing

Most enterprise environments are no longer purely on-premises. Hybrid configurations with Azure AD (now Microsoft Entra ID) are the norm, and they introduce an entirely new set of attack surfaces that many organizations have not fully assessed.

Hybrid identity risks

Azure AD Connect synchronizes on-premises AD with Azure AD. The server running Azure AD Connect stores the credentials needed to replicate passwords to the cloud. If an attacker compromises this server, they can extract the synchronization credentials and use them to reset passwords for any cloud-synced account, including Global Administrators.

We test for this specifically because the Azure AD Connect server is frequently treated as a regular server rather than a Tier 0 asset. It often sits on the same network segment as standard file servers, runs unpatched, and has local admin accounts shared with other systems. Compromising this one server can give an attacker control over both the on-premises domain and the entire cloud tenant.

Cloud-specific attack paths

In the Azure AD and Entra ID space, we test for:

• Over-privileged service principals. Application registrations with broad Microsoft Graph permissions that can read all user data, modify directory roles, or access SharePoint and Exchange on behalf of the organization.
• Consent grant abuse. Misconfigured consent settings that allow any user to grant an external application access to organizational data.
• Conditional Access gaps. Policies that require MFA for interactive sign-ins but not for legacy authentication protocols or service principal authentications.
• Token theft and replay. Primary Refresh Tokens (PRTs) on Azure AD-joined devices can be extracted and used to bypass MFA and access cloud resources from an attacker-controlled device.
• Cross-tenant trust abuse. Misconfigured B2B collaboration settings that allow external identities broader access than intended.

Entra ID security posture review

Beyond attack path testing, we evaluate the overall security posture of the Entra ID tenant. This includes reviewing the number of Global Administrators (we commonly find 10 or more, when Microsoft recommends fewer than 5), evaluating MFA enforcement coverage, checking for stale accounts and orphaned service principals, and assessing the Secure Score against Microsoft's baseline recommendations.

For organizations that run red team exercises, the hybrid environment often provides the richest attack scenarios because defenders need to monitor and respond across two fundamentally different platforms simultaneously.

Password policy analysis and credential hygiene

Weak passwords remain the single most exploitable finding in Active Directory. During every engagement, we perform a comprehensive analysis of the domain's password policy and the actual passwords in use.

What we typically find

The default AD password policy requires a minimum of 7 characters and three of four complexity requirements (uppercase, lowercase, numbers, symbols). This means Password1 is technically compliant. So is Summer2026!. And CompanyName1. We crack these in seconds.

After performing a DCSync (with authorized access during the engagement), we run the full domain password database through our cracking rig. The results are consistent across organizations:

• 30-50% of passwords crack within 24 hours using common wordlists and rule sets
• 10-20% of passwords match common patterns: [Season][Year][Symbol], [CompanyName][Number], [City][Number]
• 5-15% of accounts share the same password as at least one other account
• Service accounts almost always have weak, static passwords that haven't been rotated in years
• Former employees' accounts remain active with unchanged passwords in roughly 20% of environments

Fine-grained password policies

Many organizations don't realize that AD supports fine-grained password policies (FGPPs), which allow different password requirements for different groups. Privileged accounts should have a stricter policy: longer minimum length, shorter maximum age, no password reuse. We frequently find that the same 7-character minimum applies to domain admins as it does to the intern's account.

Service account abuse

Service accounts are the keys to the kingdom in most AD environments, and they are almost universally over-privileged and under-protected.

The problem with SPNs

Every service account with a Service Principal Name is vulnerable to Kerberoasting. The fix is not to remove the SPN (the service needs it to function), but to ensure the password is strong enough to resist cracking. A 30-character randomly generated password will not be cracked by any attacker in any reasonable timeframe.

Better still, use Group Managed Service Accounts (gMSAs). These are AD-managed service accounts with 240-character randomly generated passwords that rotate automatically every 30 days. They eliminate the human element entirely. The service authenticates using a password that no person ever sees or manages. The challenge is that not all applications support gMSA, though the list of supported platforms has grown substantially in recent years.

Over-privileged service accounts

The most dangerous finding is not a weak password. It is a service account that is a member of Domain Admins "because it was easier." We find this in roughly one out of every three environments. The account was created years ago, someone added it to Domain Admins to troubleshoot a permissions issue, and nobody ever removed it.

Service accounts should follow the principle of least privilege rigorously. A SQL Server service account needs permissions to its databases, not domain admin rights. A backup service account needs permissions to read files, not write to Active Directory. Each service account should be scoped to exactly the permissions it requires and nothing more.

Lateral movement techniques

Once an attacker has valid credentials, they need to move through the network to reach higher-value targets. Lateral movement is where individual vulnerabilities become systemic risk, and where the lack of network segmentation becomes painfully apparent.

Common lateral movement methods

We use several techniques during AD engagements, all of which mirror real-world attacker behavior:

• Pass-the-Hash (PtH): Using an NTLM hash to authenticate to remote services over SMB or WinRM without knowing the plaintext password.
• Pass-the-Ticket (PtT): Exporting Kerberos tickets from memory and importing them on another machine to impersonate the ticket's owner.
• Overpass-the-Hash: Using an NTLM hash to request a Kerberos TGT, effectively converting a hash-based credential into a Kerberos credential that bypasses systems monitoring NTLM usage.
• Remote execution via WMI and WinRM: Executing commands on remote systems using Windows Management Instrumentation or Windows Remote Management, both of which are enabled by default on most Windows servers.
• PSExec and SMB execution: Deploying a service binary over SMB and executing it as SYSTEM. Noisy but effective, and often undetected in environments without endpoint detection.
• RDP hijacking: On a compromised server, disconnected RDP sessions can be hijacked without authentication if the attacker has SYSTEM-level access. This provides access to the session of whoever was previously logged in, including their cached credentials and open applications.

Why segmentation matters

Lateral movement is only possible when systems can reach each other. In a flat network where every workstation can communicate with every server, a single compromised machine is a foothold into everything. Network segmentation, micro-segmentation in particular, limits the blast radius of any individual compromise.

We consistently recommend segmenting AD infrastructure into tiers:

Detection and monitoring recommendations

Prevention is ideal, but detection is essential. Many AD attacks leave artifacts that can be detected with proper logging and monitoring. The challenge is that most organizations either don't collect the right logs or collect so many logs that the signal is lost in noise.

Critical events to monitor

• Event ID 4769 (Kerberos service ticket request): A spike in TGS requests from a single source, especially for multiple service accounts in a short window, indicates Kerberoasting.
• Event ID 4768 with pre-authentication failure type 0x6: Indicates AS-REP roasting against accounts without pre-authentication.
• Event ID 4662 (directory service replication): Replication requests from non-DC machines indicate DCSync attacks. This is one of the highest-fidelity detections available.
• Event ID 4624 with logon type 3 from unexpected sources: Network logons from workstations to servers that don't normally communicate can indicate lateral movement.
• Event ID 4720/4728/4732 (account and group changes): Unexpected additions to privileged groups, especially Domain Admins, Enterprise Admins, or Schema Admins.
• Event ID 5136 (directory service object modification): Changes to GPOs, delegation settings, or AdminSDHolder can indicate privilege escalation attempts.

Tooling recommendations

Effective AD monitoring requires more than native Windows logging:

• Microsoft Defender for Identity (MDI): Purpose-built for detecting AD attacks including Kerberoasting, DCSync, lateral movement, and reconnaissance. The best single investment for AD monitoring.
• SIEM with AD-specific detection rules: Ensure your SIEM ingests security event logs from all domain controllers and correlates events across the domain.
• Deception technology: Honeypot accounts with SPNs, decoy admin credentials, and canary file shares generate high-fidelity alerts when touched by an attacker. Zero false positive rate when deployed correctly.
• BloodHound for defense: The same tool attackers use to find paths to domain admin can be run by defenders to identify and eliminate those paths proactively. Schedule regular BloodHound collections and review attack paths quarterly.

Active Directory hardening checklist

Based on the findings from hundreds of AD engagements, this checklist covers the changes that have the highest impact on reducing risk. They are ordered roughly by impact and implementation effort.

Immediate actions (do this week)

• Disable LLMNR and NBT-NS via Group Policy across all machines. There is almost never a legitimate reason for these protocols to be active. GPO path: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution. For NBT-NS, disable via network adapter GPO settings.
• Require SMB signing on all systems. GPO path: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > "Microsoft network server: Digitally sign communications (always)" set to Enabled.
• Enable Kerberos pre-authentication on all accounts. Query for affected accounts: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}. Fix each one unless there is a documented, currently valid business justification.
• Audit Domain Admins membership. Remove any account that does not absolutely require it. Service accounts should never be Domain Admins. Personal user accounts should not be Domain Admins; use separate privileged accounts.

Short-term improvements (this quarter)

• Deploy fine-grained password policies. Require 14+ characters for standard users, 20+ for privileged accounts, and 30+ for service accounts.
• Migrate service accounts to gMSA wherever supported. For accounts that cannot use gMSA, set 30+ character randomized passwords and rotate every 30 days via a PAM solution.
• Remove unconstrained delegation. Query: Get-ADComputer -Filter {TrustedForDelegation -eq $true}. Convert to constrained or resource-based constrained delegation.
• Audit and remediate GPO permissions. Use BloodHound or manual ACL review to identify non-admin users with write access to GPOs, especially those linked to domain controllers or servers.
• Enable Protected Users group for all privileged accounts. This disables NTLM authentication, Kerberos delegation, and credential caching for members, significantly reducing the attack surface for high-value accounts.
• Deploy LAPS (Local Administrator Password Solution) for local admin passwords on all workstations and servers. This eliminates shared local admin passwords, which are a common lateral movement enabler.

Strategic improvements (this year)

• Implement tiered administration. Separate admin accounts and workstations for Tier 0, 1, and 2. Use Privileged Access Workstations (PAWs) for Tier 0 administration. Never allow Tier 0 credentials to touch non-Tier 0 systems.
• Deploy Microsoft Defender for Identity on all domain controllers. Configure alerts for Kerberoasting, DCSync, lateral movement, and reconnaissance activities.
• Enable Credential Guard on all Windows 10/11 and Server 2016+ systems. This uses virtualization-based security to protect LSASS, preventing most credential dumping tools from extracting passwords and hashes from memory.
• Reduce NTLM usage toward elimination. Audit NTLM authentication events (Event ID 4624 with authentication package NTLM), identify applications that require it, and work toward disabling NTLM domain-wide. This eliminates Pass-the-Hash and NTLM relay attacks entirely.
• Reset the krbtgt password twice, 12-24 hours apart. This invalidates any existing Golden Tickets. Schedule this annually and after any suspected compromise.
• Conduct regular AD attack path analysis. Run BloodHound quarterly, review paths to Domain Admins, and remediate before the next penetration test. This turns reactive testing into proactive defense.

What a good AD pentest looks like

Not all AD penetration tests are created equal. A thorough engagement should cover all of the areas discussed in this article, not just run a tool and hand you a list of Kerberoastable accounts. Here is what to expect from a quality assessment:

• Full attack path mapping. Not just individual findings, but the complete chains from initial access to domain compromise. This is what BloodHound-based analysis provides, and it is far more actionable than a flat list of vulnerabilities.
• Password analysis report. A statistical breakdown of password strength across the domain, including crack rates, common patterns, and comparisons against your stated password policy.
• Privilege analysis. A review of who has admin rights, where those rights are excessive, and which accounts represent the highest risk. This includes both direct group memberships and indirect paths (e.g., GenericWrite on a privileged group).
• Hybrid environment coverage. If you run Azure AD or Entra ID, the test should cover cloud attack paths, synchronization infrastructure security, and conditional access gaps.
• Prioritized remediation roadmap. Findings ranked by both severity and exploitability, with specific technical remediation steps and a recommended implementation order.

The phases of a penetration test apply to AD engagements just as they do to web application or cloud assessments. The difference is the depth of post-exploitation analysis and the systemic nature of the findings.

Active Directory is not going away. Despite the shift toward cloud identity, the majority of enterprises will run hybrid environments for years to come. The attack techniques described in this article are not theoretical. They are the techniques we use in nearly every engagement, and they work in nearly every environment, because the same misconfigurations persist across industries, organization sizes, and maturity levels.

The good news is that every finding in this article has a fix. Most of the immediate actions, disabling LLMNR, requiring SMB signing, cleaning up Domain Admins, cost nothing and can be implemented in a single change window. The strategic improvements take longer but fundamentally change the security posture of your AD environment.

The question is not whether your Active Directory has these issues. Based on our experience, it almost certainly does. The question is whether you find them first or an attacker does.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.