How Internal Penetration Tests End at Domain Admin
When a penetration tester gets a foothold on an internal network, the average time to domain administrator privileges in a typical enterprise environment is somewhere between four hours and two days. Usually closer to four hours.
That is not a commentary on how bad corporate security is. It is a commentary on how Active Directory works, what default configurations it ships with, and how those defaults combine in ways that make lateral movement and privilege escalation nearly automatic for someone who knows the path.
Here is what the path looks like from the attacker's side, and why it matters that you understand it before someone else demonstrates it for you.
The Starting Position
Most internal assessments start from the same premise: a low-privileged domain account, similar to what a new employee would have, and a workstation on the corporate network. The tester is not an administrator. They have no special access. They are a regular user who happens to know some things.
The goal is domain administrator, or more specifically, the ability to access any system or data in the environment. The question the test answers is: starting from this position, how long does it take to get there?
The Enumeration Phase Nobody Likes to Hear About
Before a tester exploits anything, they spend time learning the environment. This phase alone surfaces more about an organization's security posture than most organizations are comfortable knowing.
BloodHound is the tool that changed internal network assessment permanently when it was released. It ingests Active Directory data and renders it as a graph, showing attack paths from any user to domain administrator. It does not find zero-days. It finds the logical chains of trust and delegation that already exist in the environment and shows them visually. Most environments contain multiple paths to domain admin that are invisible without this kind of analysis and obvious with it.
Other enumeration work surfaces service accounts with Kerberoastable SPNs, accounts with AS-REP Roasting exposure, machines with unconstrained delegation configured, and trusts between domains that may have different security postures. None of this requires exploits. It is Active Directory answering legitimate protocol queries about itself.
Kerberoasting: The Attack That Should Not Still Work
Service accounts in Active Directory often have Service Principal Names registered so that the Kerberos protocol can hand out service tickets for them. Any authenticated domain user can request one of these tickets. The ticket is encrypted with the service account's password hash.
The tester requests the tickets, takes them offline, and runs a password cracking tool against them. If the service account has a weak or dictionary-based password, the cracker finds it. The tester now has credentials for that service account.
The reason this matters is what the service account can do. Service accounts accumulate permissions over their lifetimes. They are given access to things, usually for operational reasons that made sense at the time, and access is rarely removed when circumstances change. A service account that runs backups has read access to everything. A service account that was temporarily given domain admin during a migration two years ago still has domain admin because nobody revoked it.
Kerberoasting is over a decade old. It is in every penetration tester's standard toolkit. It works in a large percentage of environments because service account password hygiene is genuinely difficult to enforce and rarely prioritized until it appears on a findings list.
Credential Reuse and Lateral Movement
Once a tester has compromised one machine, they can work toward extracting credential hashes. Modern endpoint protection makes this harder than it used to be. It does not make it impossible.
A more reliable path is credential reuse. In environments where the same local administrator password is used across many workstations, or where users have reused their domain password on a system the tester can reach, one compromised credential scales to many systems. Spray those credentials across the network, find everywhere they work, and the foothold expands without a single additional exploit.
The findings that actually change security postures are rarely the dramatic ones. They are the quiet ones: the service account with domain admin that nobody remembers granting, the workstation-to-server path that network segmentation was supposed to close, the trust relationship with a subsidiary that has weaker controls. In a flat network, a compromised user workstation can directly authenticate to domain controllers, file servers, and every other host on the segment. SMB signing disabled means NTLM relay is available. Every trust relationship is a potential stepping stone.
The honest answer to "how did they get to domain admin in four hours" is usually not "because they were clever." It is "because the environment had the same configuration patterns that most environments have, and those patterns have well-documented exploitation techniques that have not changed much in years."
What Actually Changes the Outcome
The findings that appear on these reports most consistently are not expensive to address.
Group Managed Service Accounts make Kerberoasting impractical because the passwords are long, random, and rotated automatically by the domain controller. Enabling SMB signing across the environment closes relay attacks entirely. Credential tiering, where admin accounts used on workstations are different from admin accounts used on servers, limits how far a single compromise travels. Local Administrator Password Solution randomizes local admin passwords per machine so that compromising one workstation does not hand the tester the keys to every other one.
None of these require purchasing a new product. They require configuration work, and they require someone to actually prioritize it instead of leaving it on the security backlog where it has lived for two years behind more visible projects.
The tester who gets to domain admin in four hours is not doing something exotic. They are following a path that the environment built for them.
The Uncomfortable Part
Internal network penetration tests are uncomfortable in a specific way that external tests are not. External assessments surface problems at the boundary. Internal tests show what happens after the boundary fails, which is increasingly the more important question given how common phishing, supply chain compromise, and credential-based initial access have become.
The path from a compromised helpdesk account to domain admin exists in a meaningful percentage of enterprise environments that have functioning security programs, annual compliance audits, and genuine investment in their security posture. It exists because Active Directory's defaults were not designed with modern attack techniques in mind, and because the operational work of hardening it is less visible and less rewarded than deploying new perimeter technology.
The test shows you the path. What you do with it is what distinguishes a compliance exercise from a security program that is actually trying to close gaps before someone who is not on your payroll finds them first.