A single user account. No admin privileges, no special rights—obtained through a phishing email sent to the accounting department. In many of our internal penetration tests, this is the starting point—and in an alarmingly high percentage of environments, it’s enough to become a domain administrator within a few hours. Not through a spectacular zero-day vulnerability, but through configurations that have remained unchanged in the directory for years.
Active Directory (AD) is the world’s leading directory service for managing Windows networks. Adoption figures vary depending on the source: Frost & Sullivan estimates that approximately 90 percent of Global Fortune 1000 companies use AD as their primary means of authentication and authorization; older figures from Microsoft put the number even higher, at 93 to 95 percent. The exact current number of installations is difficult to determine—however, industry observers assume that the percentage has not decreased significantly since then. AD is also the de facto standard in the DACH region: Some industry sources estimate that around 80 percent of German companies with more than 50 employees rely on Windows Server systems, and that a large proportion of SMEs use AD or its cloud counterpart, Microsoft Entra ID—however, no reliable primary statistics specifically for Germany are available on this topic.
In practice, this widespread use means that AD manages identities, authenticates users and services, and determines who is allowed to access which resources. It is precisely this central role that makes it the most valuable target. Whoever controls the domain controls practically everything.
This article shows, from an attacker’s perspective, what a typical path from a standard user to a domain admin looks like, which techniques will actually work in 2025 and 2026—including the very latest ones like BadSuccessor —and what hardening measures you can use to close these paths. Finally, we’ll assess what a professional Active Directory penetration test can achieve and where its limitations lie.
Why Active Directory Is the Main Target
In September 2024, the Five Eyes agencies—including the U.S. CISA, the NSA, and the U.K.’s NCSC—published a joint guideline titled “Detecting and Mitigating Active Directory Compromises,” which describes 17 of the most commonly observed attack techniques targeting AD. Their key message: Active Directory is the most widely used authentication solution in corporate networks worldwide—and is routinely targeted by attackers to escalate privileges and take over the most valuable accounts.
The Sophos Active Adversary Report 2026, which analyzes 661 incident response and MDR cases from 70 countries, highlights just how central Active Directory is to real-world attacks. In about two-thirds of the incidents examined (67 percent), the cause was related to identity—compromised credentials, brute-force attacks, and phishing. And attackers are moving faster: The median time from initial access to reaching Active Directory was most recently just 3.4 hours —about 70 percent shorter than a year earlier. The trend is clear: Attackers who want to move laterally and ultimately encrypt data almost always use Active Directory as their pathway.
There are two fundamentally different reasons for this. The first is historical baggage: AD has grown over two decades in many organizations and carries a corresponding amount of baggage—generous default settings, legacy protocols that are still supported for compatibility reasons, and permission chains that have developed over the years that no one can fully understand anymore. These weaknesses are the result of configuration and historical circumstances and can, in principle, be resolved.
The second reason is inherent in the design, which is precisely why it is so sensitive: AD concentrates the most valuable secrets in one place. Through multimaster replication, every writable domain controller maintains a complete replica of the central database ntds.dit —including the password hashes for all accounts. Anyone who compromises a single one of these domain controllers potentially gains access to the login credentials for the entire domain. The BSI addresses this specific security requirement in its IT-Grundschutz module APP.2.2 Active Directory Domain Services, which consistently classifies domain controllers and the AD infrastructure as requiring a high level of protection.
An Overview of the Typical Attack Path
An internal attack on AD almost always follows the same pattern. The individual stages are interlinked, and at several points, a single misconfiguration is enough to bypass a stage:
- Reconnaissance – The directory is scanned: users, groups, service accounts, permissions, and trusts.
- Credential Access – Initial credentials or password hashes are compromised, for example, through kerberoasting or password spraying.
- Privilege Escalation – An unprivileged account is elevated to a privileged one, often due to misconfigurations in certificate services or permissions.
- Lateral Movement – The attacker moves sideways across the net, from one side to the other.
- Domain Dominance – Complete control over the domain, usually achieved by extracting all password hashes.
- Persistence – Long-term, stealthy access that is not eliminated even by a password change.
The following sections walk through the most important techniques along this path—each with an explanation of how it works, its prerequisites, its effects, and countermeasures.
Reconnaissance: Reading the Directory Like an Attacker
Before an attacker takes action, they assess the situation. Tools like BloodHound, using the SharpHound collector, query LDAP information and represent Active Directory as a graph: users, groups, computers, and permissions become nodes, and the relationships between them become edges. From this graph, privilege escalation appears to be a simple pathfinding problem—the shortest path from a compromised account to the Domain Admins becomes visible, even if it involves over a dozen intermediate steps and nested group memberships.
Prerequisite: In the default configuration, any valid domain account is sufficient to read large portions of the directory. Impact: The attacker often knows the attack surface better than the internal IT team. Countermeasure: Restrict anonymous and unnecessary read access, regularly audit permissions—and use the same tools defensively. BloodHound, PingCastle, and Purple Knight are excellent tools for identifying risky paths before an attacker does.
However, it’s nearly impossible to prevent simple read access—every authenticated account is allowed to read large portions of the directory. The focus therefore shifts to detection, and this is precisely where XDR (Extended Detection and Response) solutions come in. They correlate telemetry from endpoints, identities, and the network, and detect enumeration based on behavior rather than individual signatures. Tools like SharpHound leave a characteristic footprint: high-volume, widely distributed LDAP queries, massive SAMR enumeration, and unusual access patterns to the domain controllers. An identity-focused XDR component—such as Microsoft Defender for Identity as part of Defender XDR—reports such activities via detections like Security Principal Reconnaissance (LDAP) or User and Group Membership Reconnaissance (SAMR).
This can be effectively supplemented by deception: deliberately placed decoy or honeypot accounts—such as dummy accounts with “Admin” in their names—trigger an alert as soon as they are queried, because regular operations never access them. However, detection is not a panacea. Attackers find ways around it, for example by shifting data collection from LDAP to Active Directory Web Services (ADWS) to blend in with normal web traffic. Therefore, only a combination of restricted read access, behavior-based monitoring, and deception can provide robust protection.
Credential Access: Kerberoasting and AS-REP Roasting
Kerberoasting is one of the most reliable techniques out there because it exploits a legitimate Kerberos mechanism. Any account with a Service Principal Name (SPN)—typically service accounts for databases, web servers, or applications—can be requested by any authenticated user. The domain controller issues a service ticket encrypted with the service account’s password hash. The attacker takes this ticket and cracks it offline, leaving no further traces on the network. If the service account has a weak password—and this is usually the case with service accounts that have been in use for years—it can be compromised in minutes.
AS-REP Roasting works in a similar way, but targets accounts where Kerberos pre-authentication is disabled. For such accounts, an encrypted server response can be requested and also cracked offline—in this case, not even a password is required.
Impact: At first, both techniques only yield a crackable hash, not a complete password. Only successful offline cracking can turn it into a plaintext password, and that works only with weak passwords. If a service account cracked in this way is also part of a privileged group, the attacker can gain direct access to the target. A sufficiently long, random password, on the other hand, renders the attack ineffective. Countermeasure: The most effective defense is strong, random passwords—ideally (group/delegated) Managed Service Accounts with automatic key management. This includes avoiding privileged service accounts and maintaining good SPN hygiene, i.e., removing unnecessary SPNs. Enforcing AES instead of RC4 significantly reduces the likelihood of a successful attack but does not eliminate Kerberoasting: The service ticket remains protected by the account’s long-term key and can still be attacked offline. Enabling pre-authentication also helps protect against AS-REP Roasting. When it comes to monitoring, Event 4769 is not a reliable alarm indicator, as service ticket requests are part of normal operation and RC4 is not inherently malicious in legacy environments. The signal only becomes meaningful in context—for example, when a single account requests tickets for many different SPNs within a short period of time. A targeted password audit reveals precisely those weak service accounts that make Kerberoasting worthwhile.
Password Spraying: One Password, Many Accounts
Instead of attacking an account with many passwords and triggering account locks, password spraying tries a few likely passwords against many accounts—such as the current quarter plus the year. The Five Eyes guidelines recommend, among other things, locking an account after a maximum of five failed login attempts, as well as actively scanning the web at least once a month for login credentials stored in plain text. Effective protection also includes multi-factor authentication and the use of blacklists for obviously weak passwords.
Privilege Escalation via Certificate Services (ADCS / ESC)
Active Directory Certificate Services (ADCS) are used in many companies—and are often misconfigured. In 2021, SpecterOps described the first eight escalation classes (ESC1 through ESC8) in its research paper “Certified Pre-Owned”; the Certipy tool automates their detection and exploitation and now covers the entire known range from ESC1 to ESC17. The classes beyond ESC8 were identified by other researchers and were added by 2025.
Two classic examples illustrate the problem:
- ESC1: If a certificate template allows a regular user to specify the applicant (Enrollee Supplies Subject) and issues the certificate for client authentication, then an unprivileged user can have a certificate issued in the name of a domain administrator. Privilege escalation in just a few minutes, without an exploit.
- ESC8: Here, a forced authentication of a domain controller via NTLM isrelayed to the CA’s Web Enrollment Interface. The attacker obtains a machine certificate for the DC, uses it to authenticate, and can then read the entire domain. This chain does not require any domain privileges at the outset.
Countermeasure: Systematically review and clean up templates; remove the “Enrollee Supplies Subject” right; set enrollment permissions restrictively; secure web enrollment (HTTPS with Extended Protection for Authentication) or disable it if it is not needed. Events 4886 and 4887 are relevant for monitoring. The BSI also classifies the CA as part of the Tier 0 environment—its security is inextricably linked to that of Active Directory.
NTLM Relay and Coercion: They’re Not Dead Yet
Microsoft has signaled the end of NTLM, but in practice, the protocol remains a reliable attack vector. Using so-called coercion techniques—known by names such as PetitPotam or PrinterBug —a domain controller can be tricked into actively authenticating itself to a system controlled by the attacker. This authentication is then forwarded to a valuable target, such as LDAP or the ADCS Web Enrollment interface (see ESC8).
The vulnerability demonstrated in 2025 showed that this is not just a theoretical residual risk CVE-2025-24054: An NTLM hash disclosure that, according to security research, was actively exploited in attack campaigns against government agencies within days of the patch being released—triggered simply by viewing a specially crafted directory. Although Windows Server 2025 introduced useful default hardening measures, it shifted the attack surface rather than eliminating it.
Countermeasures: Enforce SMB signing, enable LDAP signing along with channel binding, and gradually reduce and disable NTLM on Web Enrollment endpoints. In APP.2.2, the BSI explicitly requires signed SMB traffic, the deactivation of LM and NTLMv1, and signed LDAP sessions with channel binding tokens.
Domain Dominance: DCSync
If an account with the DS-Replication-Get-Changes and …-All replication rights is accessible, DCSync is used. Instead of logging on to a domain controller, the attacker sends a standard replication request via the DRS protocol—just as domain controllers do among themselves. The DC willingly responds with the requested data, including all password hashes and the particularly valuable ` krbtgt` key. The result: all login credentials for the domain, extracted remotely without ever having directly accessed a DC.
Important to understand: DCSync exploits legitimate replication permissions; it does not exploit a software vulnerability. A patch alone, therefore, does not prevent this technique. Microsoft’s own AD Threat Guidance from December 2025 lists DCSync as one of the most frequently observed techniques following a compromise. Countermeasure: Grant replication permissions strictly according to the least-privilege principle and audit them quarterly; consistently implement tiering. In monitoring, event 4662 with the replication GUID is the key indicator.
Persistence: Gold and Silver Tickets
Anyone who possesses the ” krbtgt” hash can issue themselves a “Golden Ticket “—a self-generated Ticket-Granting Ticket that allows the attacker to impersonate any identity, including a domain administrator. A Silver Ticket is more limited in scope and forges a service ticket for a specific service. Both are persistence techniques: even after compromised user passwords have been reset, access remains intact.
Countermeasure: Protect the krbtgt password and rotate it regularly— twice, with sufficient time between rotations so that the old keys become completely invalid. An unscheduled rotation should be performed whenever an employee with Tier 0 access leaves the company. A useful rule of thumb from real-world experience: If you don’t know when the krbtgt password was last changed, you should assume that an attacker knows it.
New and Relevant: BadSuccessor and dMSA Abuse
With Windows Server 2025, Microsoft introduced Delegated Managed Service Accounts (dMSA)—a new account type designed to simplify the migration of legacy service accounts. In May 2025, Akamai researcher Yuval Gordon demonstrated, under the name BadSuccessor, how this migration mechanism could be exploited.
The crux of the problem: An attacker with the right to create objects (CreateChild) in any organizational unit (OU) can create a dMSA and, using two attributes— msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState — simulate a migration from any account. The Key Distribution Center then treats the dMSA as the legitimate successor and transfers the privileges and keys of the target account to it—including those of a domain administrator. What’s particularly concerning: By default, the attack works as long as there is even a single Windows Server 2025 domain controller in the forest, even if dMSAs are not used at all. Akamai found the necessary permissions in 91 percent of the environments examined for accounts other than domain administrators.
Microsoft initially classified the vulnerability as moderate and did not release an immediate patch—an assessment that Akamai publicly disputed. On August 12, 2025, a patch was finally released under the identifier CVE-2025-53779. Important to note: While the patch closes the direct escalation path, the BadSuccessor technique remains relevant—for example, as a means of obtaining credentials if an attacker already controls a dMSA and a target object.
Countermeasure: Patch Windows Server 2025 DCs, check permissions on OUs and containers, strictly limit the creation and modification of dMSAs to Tier 0, and monitor write access to the specified attributes (events 5136/5137 with SACLs set accordingly). The simple principle: Treat dMSA creation with the same care as other highly sensitive operations.
Why Standard Hardening Isn’t Enough
Most AD environments are stable—but stability does not equal security. Over the years, configurations that were acceptable ten years ago have accumulated and now represent an open door: RC4 enabled, krbtgt passwords that have never been rotated, lack of tier separation, and overprivileged accounts. In many environments, the number of privileged accounts is many times higher than the necessary minimum—and every unnecessary privileged account is a potential point of entry.
The tricky thing about the techniques described is that none of them exploits a “vulnerability” in the traditional sense. Kerberoasting, DCSync, and ADCS abuse all use legitimate mechanisms. A standard vulnerability scan that looks for missing patches will therefore not detect them. What is needed is a systematic review of permissions, configurations, and attack vectors.
Resilience: The Five Pillars of Resilient AD Security
The Microsoft Tier Model, which the BSI also adopts as a recommendation in its IT-Grundschutz framework, forms the foundation. It separates administrative identities based on security requirements: Tier 0 includes domain controllers and the AD infrastructure; Tier 1 includes critical servers and applications; and Tier 2 includes workstations and end users. The ironclad rule is: A Tier 0 account must never log in to a Tier 1 or Tier 2 system. Any domain administrator who opens their email inbox is handing over the highest privilege to the very first phishing link.
Five practical pillars rest on this foundation:
- Segregation of Accounts and PAW. Dedicated administrator accounts for each tier; block cross-tier logins via Group Policy; secure the built-in administrator. Privileged administration is performed exclusively via Privileged Access Workstations —dedicated devices without email, a browser, or Office.
- Harden Kerberos. Enforce AES instead of RC4, rotate the
krbtgtpassword twice, and schedule this rotation on a quarterly basis. Do not use SPNs on privileged accounts to prevent Kerberoasting. - Phase out legacy protocols. Reduce and disable NTLM, sign SMB, disable SMBv1, enable LDAP signing with channel binding, and disable LM and NTLMv1—in accordance with BSI APP.2.2.A8.
- Protect credentials. Use LAPS for local administrator accounts, the Protected Users group for critical accounts, Credential Guard, and LSA Protection on all current Windows systems to prevent credentials from being read from memory. For Tier 0 and Tier 1 accounts, use phishing-resistant multi-factor authentication such as FIDO2, smart cards, or Windows Hello for Business.
- Continuous monitoring. Hardening without monitoring is like a lock without an alarm system. In addition to the events already mentioned (4769, 4662, 4886/4887, 5136/5137), 4672 and changes to privileged groups (4728/4756) deserve special attention. A regular BloodHound or PingCastle scan will reveal whether new risky paths have emerged.
Compliance Requirements: NIS-2, ISO 27001, and BSI Basic Protection
Since December 6, 2025, the German NIS-2 Implementation Act has been in effect and has significantly expanded the group of companies subject to its requirements. Several of the core measures required by § 30 BSIG—access control, cryptography, multi-factor authentication, and secure authentication—can be directly mapped to the AD hardening described here. When it comes to the obligation to provide evidence, precision is key: Section 39 of the BSIG applies only to operators of critical infrastructure, who must provide evidence of implementation to the BSI for the first time no earlier than three years after classification and every three years thereafter. Facilities classified as “particularly important” and “important” are subject to the risk management obligations under the BSIG but are not automatically covered by § 39 solely based on this classification; the BSI may order audits of these facilities on a case-by-case basis (§ 61, § 62 BSIG). Which regime applies depends on the sector, size, and classification and must be assessed on a case-by-case basis.
The advantage from a compliance perspective: AD hardening can be documented. The Tier model, LAPS, NTLM restrictions, Kerberos-AES, and LDAP and SMB hardening are measures whose implementation status can be verified and documented—both to a BSI auditor and as part of an ISO 27001certification, which addresses, among other things, privileged access and secure authentication. The BSI module APP.2.2 provides the specific requirements framework for this. A penetration test, in turn, provides proof of effectiveness: It demonstrates not only that measures are in place, but also whether they can withstand a real-world attack.
How an Active Directory Penetration Test Is Conducted
The most meaningful scenario for Active Directory is an “assumed breach” scenario in a gray-box variant: The tester starts with a standard domain user account—exactly the situation that actually exists after a successful phishing email or a compromised endpoint. This is significantly more realistic and efficient than first having an attacker laboriously breach the perimeter, and it reveals exactly the internal paths that are relevant here.
The process follows the attack path outlined above: After the scoping phase, the tester enumerates the directory, identifies attack paths, demonstrates their exploitability in a controlled manner, and documents where the chain leads to domain takeover. The result is not a generic PDF, but a prioritized report with concrete, actionable recommendations. Such an Active Directory penetration test is typically part of an audit of the internal IT infrastructure.
This should be distinguished from red teaming: While a penetration test identifies and documents vulnerabilities as comprehensively as possible within a fixed time frame, a red team operation pursues a specific goal under realistic conditions and places particular emphasis on remaining undetected. Both use the same penetration testing techniques; the difference lies in the mission and approach.
A word on the significance of qualifications: Certifications such as OSCP for testers or ISO 27001 certification for the service provider are useful minimum indicators of quality and a structured approach—but they are not an end in themselves and do not replace either experience or a sound methodology. Ultimately, what matters is whether a test identifies the actual attack vectors and presents them in a clear and understandable way. An automated vulnerability scan is a useful supplement to this, but not a substitute: it does not detect the misconfigurations described here.
Conclusion
In many environments, the path from standard user to domain administrator is shorter than those in charge would like—and it rarely involves spectacular vulnerabilities, but rather configurations that have accumulated over the years. The good news: Nearly all of the paths described can be closed using known, documentable measures. Tiering, Kerberos hardening, phasing out NTLM, protecting credentials, and consistent monitoring form the framework. A regular Active Directory penetration test ensures that this framework isn’t just on paper.