Active Directory remains a central identity and authorization component in many corporate Windows environments. Users, computers, groups, servers, service accounts, permissions, policies, and authentication systems are all connected to the directory in one way or another.
This makes an internal Active Directory assessment very different from searching for a single critical vulnerability. Risk usually appears in the relationships between objects: an account with more permissions than necessary, a weak service account password, an overly permissive delegation, a certificate template with unsafe settings, or an identity that retains privileges both on-premises and in the cloud.
An individual finding may appear relatively minor. The real problem emerges when several findings form a path that allows an attacker to move from a low-privileged identity to another one capable of administering servers, modifying the directory, or accessing critical resources.
In hybrid environments, the boundary does not necessarily end with the on-premises domain. Active Directory may coexist with Entra ID, registered devices, synchronized identities, cloud applications, and Single Sign-On mechanisms. A modern assessment must understand which relationships exist between both environments and, more importantly, which ones should not exist.
In this guide
- Active Directory is rarely compromised through a single vulnerability
- The first step: understanding relationships and privileges
- Kerberos and service accounts
- Accounts without preauthentication
- Permissions and ACLs: when a small permission changes everything
- AD CS and certificate-based identity
- Credentials and lateral movement
- Directory replication and domain compromise
- What compromising the krbtgt account really means
- The hybrid boundary with Entra ID
- How to detect attack paths
- How to actually reduce the attack surface
- How to approach an internal pentest
- What this means for offensive security
- Frequently asked questions
Active Directory is rarely compromised through a single vulnerability
One of the most important ideas when learning internal pentesting is to stop constantly looking for “the critical vulnerability”.
Active Directory works as a system of relationships. An account belongs to groups. Groups receive permissions. Those permissions affect users, computers, organizational units, policies, and other objects. Services run under specific identities. Administrators log into machines that may later store authentication material.
From an offensive security perspective, the objective is to understand how those pieces relate to each other.
A service account with a weak password may not be particularly interesting if it has no meaningful privileges. However, that same account may administer a server. That server may contain a privileged session. That privileged identity may, in turn, be able to modify a group or another directory object.
The real vulnerability appears in the composition.
This is why two apparently similar domains can have completely different attack surfaces. What matters is not only which technologies they use, but how privileges have been delegated over years of operation.
The first step: understanding relationships and privileges
An internal assessment should begin by building an inventory of trust.
You need to identify users, computers, privileged groups, service accounts, administrative sessions, policies, trust relationships, delegations, certificate authorities, and any other component involved in authentication.
Then comes the important question: who can control whom?
Control does not always mean membership in an administrative group. An identity may be allowed to reset another user's password, modify its attributes, change group membership, alter an access control list, or modify an object on which other systems depend.
This is why modern assessments often represent these relationships as paths. The value is not only in knowing that an incorrect permission exists, but in understanding which sensitive asset could ultimately be reached through it.
From a defensive perspective, the same methodology is extremely useful. It can reveal escalation paths that would never appear by reviewing only the direct members of administrative groups.
Kerberos and service accounts
Kerberos is the main authentication protocol used in an Active Directory domain, and its design creates a particularly interesting surface around service accounts.
When a user needs to access a service registered with a Service Principal Name, the client requests a service ticket from the domain controller. That ticket contains information protected cryptographically using a key derived from the credentials of the identity running the service.
This behavior is completely legitimate. The problem appears when that identity uses a weak or predictable password.
An authenticated domain identity can request tickets for available services and later perform password recovery attempts offline. Because that phase takes place outside the domain, it does not trigger account lockouts for each attempt made against the captured material.
This technique is known as Kerberoasting.
The severity does not depend only on whether an account is susceptible to Kerberoasting. You also need to determine what privileges an attacker would gain if those credentials were recovered.
An account with a weak password but no meaningful permissions may have limited impact. A service account with administrative privileges over servers, databases, or directory components can become a significant escalation path.
How to reduce the risk
The most effective measure is to avoid human-managed passwords for service identities whenever possible. Managed service accounts allow the system to manage and rotate credentials automatically, significantly reducing the risk created by static passwords that remain unchanged for years.
For accounts that cannot be migrated, long, random passwords should be used and rotated in a controlled manner, while also applying least privilege.
What to monitor
Security event 4769 records Kerberos service ticket requests on domain controllers when the corresponding auditing is enabled.
A single request does not prove that an attack is taking place. What matters is anomalous behavior: an identity requesting an unusual number of tickets, services it does not normally use, unexpected source systems, or legacy encryption types that should not be part of normal activity.
Accounts without preauthentication
Kerberos normally includes a preauthentication mechanism that requires the client to prove knowledge of the credential before the domain controller returns certain authentication information.
Active Directory allows this protection to be disabled for an account through the DONT_REQ_PREAUTH setting.
When this happens, someone who knows the account name can request an authentication response containing information encrypted with material derived from the account password. That information can later be used for offline password recovery attempts.
This is known as AS-REP Roasting.
Unlike Kerberoasting, this technique does not depend on the account having an SPN. The relevant condition is that Kerberos preauthentication has been disabled.
The mitigation is particularly clear: unless there is a documented technical requirement, accounts should require Kerberos preauthentication.
From a detection perspective, Kerberos authentication requests appear in events such as 4768. Again, the event itself does not prove malicious activity: the preauthentication fields, involved identities, and expected behavior of the environment must be analyzed.
Permissions and ACLs: when a small permission changes everything
One of the most interesting characteristics of Active Directory is that almost every object has an access control list.
This allows administration to be delegated with a high level of granularity. A team may manage users within a specific organizational unit without becoming domain administrators, for example.
The same mechanism can become an escalation path when delegation is too broad.
Permissions such as attribute write access, DACL modification, ownership changes, or full control have very different implications depending on the object to which they apply.
With certain permissions over a user object, it may be possible to modify authentication-related properties. Over a group, it may be possible to change membership. Over a computer object, delegation-related settings may be altered. At the domain level, some permissions can eventually affect replication rights.
The important thing during an assessment is not to memorize names such as GenericWrite, WriteDACL, or GenericAll, but to understand the effective capability granted by each ACE over that specific object.
Inheritance also matters. A seemingly harmless permission applied to an organizational unit may affect dozens or hundreds of objects beneath it.
What defenders should review
Delegations should have a known owner, justification, and scope. Inherited permissions that no longer correspond to an operational requirement are particularly important because they can remain unnoticed for years.
Changes to directory objects can generate events such as 5136 when the required auditing has been configured. This telemetry is useful for detecting sensitive modifications to attributes, groups, permissions, or authentication-related material.
AD CS and certificate-based identity
Active Directory can use a public key infrastructure to issue certificates to users, computers, and services.
These certificates are not only used to encrypt traffic. Depending on their configuration, they can also be used to authenticate identities.
This makes the certificate infrastructure a critical part of the domain's trust model.
A misconfigured certificate template may allow certain users to request certificates with properties they should not be able to control. Enrollment permissions may be too broad, key usages may be overly permissive, certificate authorities may lack sufficient controls, or delegations may allow changes to PKI-related objects.
The potential impact is particularly serious because a valid certificate can become another way of proving an identity without knowing its password.
An assessment should review at least who can request each template, which identities it can represent, which certificate usages are allowed, who can modify the template, and which controls the authority applies during issuance.
Detection
Events 4886 and 4887 can record certificate requests and issuance when Certificate Services auditing is properly enabled.
Analysis should focus on unexpected requests: low-privileged identities using sensitive templates, unusual subject or identity values, and certificates issued outside known operational patterns.
Changes to certificate templates and the objects controlling the PKI should also be monitored.
Credentials and lateral movement
Obtaining one credential does not necessarily mean the attacker has reached the final objective. That identity is usually used to try to access other systems and obtain additional capabilities.
This process is known as lateral movement.
In Windows environments, authentication material can take several forms: passwords, NTLM hashes, Kerberos tickets, certificates, or tokens.
This explains why compromising a workstation used by an administrator can be much more serious than compromising an identical system used only by a low-privileged account.
If reusable authentication material is available on the system, it may allow authentication to other resources without necessarily knowing the original password.
Pass-the-Hash abuses reusable NTLM material. Pass-the-Ticket reuses Kerberos tickets. NTLM relay, when service protections allow it, attempts to relay captured authentication to another target.
Another historically important source is the memory of the process responsible for local security, where different types of authentication material associated with active sessions may exist.
Modern defenses have significantly hardened this surface, but it remains essential to prevent privileged accounts from logging on unnecessarily to lower-trust workstations or servers.
Local administrator passwords
Reusing the same local administrator password across multiple systems greatly increases the impact of compromising a single machine.
Windows LAPS can maintain a different local administrator password for each device and rotate it automatically, reducing this classic lateral movement path.
Directory replication and domain compromise
Domain controllers need to replicate directory information between each other. To support this, specific permissions exist that allow directory changes to be requested.
These permissions are extremely sensitive because some of the replicated data includes credential-related material.
An attack known as DCSync consists of abusing legitimate replication rights from an identity that should not have them, causing a domain controller to return information as if it were communicating with another authorized replication component.
There is no need to access the domain controller database file directly. The abuse takes place through the replication mechanism itself.
The impact depends on the rights obtained and the objects requested, but an identity with sufficiently broad replication permissions may gain access to credential material belonging to highly sensitive accounts.
Detection
Event 4662 can be useful for identifying the use of replication rights when Directory Service Access auditing is enabled and the appropriate SACLs are configured.
Without those conditions, the absence of the event does not prove that nothing happened.
Network telemetry is also extremely valuable. Replication traffic originating from a system that is not a domain controller should be investigated immediately unless there is a known and documented operational exception.
Defense
Replication rights should be limited strictly to the identities that genuinely require them. Assessments should identify any additional delegation and verify its justification.
What compromising the krbtgt account really means
Each domain contains a special account named krbtgt. Its cryptographic material is involved in protecting the Ticket Granting Tickets used by Kerberos.
If an attacker obtains the secret material associated with this account, they can create forged TGTs that the domain may interpret as valid.
This is known as a Golden Ticket.
This scenario represents a very serious compromise because it allows authentication and authorization information to be forged without depending on a conventional user account.
However, the techniques must be separated correctly: performing DCSync does not automatically mean having a Golden Ticket. The attacker would first need to obtain material associated with the krbtgt account and then use it to generate forged tickets.
If there is evidence that this account has been compromised, recovery requires resetting its password using the supported procedure. The operation is performed twice and enough time must be left between both resets so that the environment can correctly renew keys and existing tickets.
This is a sensitive recovery operation and should not be improvised in production.
The hybrid boundary with Entra ID
Many organizations combine on-premises Active Directory with Entra ID to manage identities, cloud applications, and devices.
This does not mean that compromising the local domain automatically provides control over the cloud environment.
The risk depends on how the relationship between both environments has been designed.
One of the most dangerous situations appears when the same identity retains significant privileges in both Active Directory and Entra ID. Compromising a single account may then affect two administrative planes that should ideally remain separated.
Synchronization components should also be treated as high-value assets. They manage relationships between both directories and use identities and permissions that should be strictly limited to what is necessary.
Another important area is devices using Single Sign-On with Entra ID.
On certain systems, a Primary Refresh Token (PRT) helps provide SSO access to cloud resources. It is a sensitive authentication artifact, but it should not be understood as a simple cookie that can always be copied freely from one machine to another.
On supported platforms, the PRT is cryptographically bound to the device and can rely on hardware such as a TPM to protect the keys used during token requests.
This means that analyzing a hybrid endpoint requires looking not only at the presence of tokens, but also at how they are protected, the device state, Conditional Access policies, and which applications accept each type of session.
The real hybrid risk
The problem appears when the boundaries that should separate the on-premises and cloud administrative planes become blurred.
Examples include identities with administrative privileges in both environments, synchronization of accounts that should not have cloud privileges, synchronization components with excessive permissions, or applications with overly broad consent.
How to detect attack paths
One of the most common mistakes when defending Active Directory is trying to associate every attack with a single Event ID.
Logs are pieces of context, not verdicts.
A 4769 event is a normal Kerberos operation. A 4887 event may represent a completely legitimate certificate. A 4662 event may correspond to an authorized operation against the directory.
Detection comes from correlating identity, source, destination, volume, time, and historical behavior.
| Area | Useful telemetry | What deserves attention |
|---|---|---|
| Kerberos | 4768, 4769 |
Anomalous ticket patterns, unusual accounts, legacy encryption, or requests outside expected behavior. |
| AD objects | 5136 |
Changes to authentication-related attributes, delegation, groups, or sensitive permissions. |
| Replication | 4662 and network telemetry |
Use of replication rights by identities or systems that are not legitimate replication components. |
| Certificates | 4886, 4887 |
Requests for sensitive templates by unexpected accounts or changes in normal issuance patterns. |
| Lateral movement | Logons, processes, services, and authentication telemetry | New source systems, administrative accounts used on unusual hosts, or unexpected protocols. |
There is also an important prerequisite: auditing must actually be enabled.
Some events depend on specific audit policies and, for certain directory operations, SACLs configured on the relevant objects. A SIEM cannot detect telemetry that was never generated in the first place.
How to actually reduce the attack surface
Defending Active Directory does not depend on one single configuration. The objective is to prevent an initial compromise from being easily transformed into another privilege.
Separate privileged identities
Administrative accounts should be used only for administrative tasks and from appropriate trusted systems.
A person with elevated privileges should not browse the web, read email, or perform daily work using that same identity.
In hybrid environments, it is equally important to avoid, whenever possible, having a single identity hold significant administrative privileges in both AD and Entra ID.
Reduce permanent privilege
Membership in privileged groups and delegated rights should be reviewed regularly.
If an account needs a permission only for a specific operation, keeping that permission for years unnecessarily increases the attack surface.
Protect service accounts
Managed service accounts reduce dependence on human-managed passwords and allow the system to rotate credentials automatically.
It is also essential to review their privileges. A strong password does not compensate for a service account with unnecessary administrative rights.
Remove unnecessary Kerberos exceptions
Accounts without preauthentication should be reviewed and justified. Old SPNs or SPNs associated with services that no longer exist should be removed.
Organizations should also gradually reduce dependence on legacy cryptographic mechanisms where the environment allows it.
Audit ACLs and delegations
Permissions should be analyzed as control paths, not merely as lists.
Particular attention should be paid to who can modify privileged groups, administrative accounts, computer objects, policies, the domain root, and certificate infrastructure.
Protect local credentials
Windows LAPS can maintain different local administrator passwords for each device and rotate them automatically, preventing one reused local password from enabling lateral movement across the network.
Protect high-value identities
The most sensitive accounts can benefit from specific controls that reduce credential storage and reuse, as well as more restrictive authentication policies.
The objective is to prevent the compromise of a user endpoint from immediately exposing reusable authentication material belonging to an administrative identity.
Treat PKI as critical infrastructure
The certificate authority, its templates, and its permissions are part of the identity system.
They should be protected at a level comparable to domain controllers, because a misconfigured PKI may allow authentication as identities with much higher privileges.
Protect the hybrid environment as two connected administrative planes
Synchronized accounts, synchronization components, applications, consent grants, devices, and cloud roles should be reviewed for unnecessary relationships between the two environments.
Separating on-premises and cloud privileges significantly reduces the blast radius of a single compromised account.
How to approach an internal pentest
A professional assessment should not begin by trying to obtain Domain Admin as quickly as possible.
It should begin by understanding the environment.
1. Define the starting point
The scenario changes completely depending on whether the tester is given a standard domain account, a domain-joined workstation, access to a specific network segment, or only internal connectivity.
This initial position should be clearly documented because it determines which conclusions can be drawn from the exercise.
2. Build the identity map
Identify accounts, groups, computers, services, delegations, permissions, and critical assets.
The objective is not yet exploitation, but understanding where trust relationships exist.
3. Prioritize paths by impact
Not every path needs to be exploited.
If a set of permissions clearly demonstrates that one account can control another critical identity, validating the path with the minimum necessary impact may be enough.
Professional pentesting is not about executing every possible technique. It is about obtaining enough evidence to demonstrate risk.
4. Analyze credentials and authentication
Review service accounts, Kerberos configuration, local credentials, administrative sessions, certificates, and any other authentication material that could enable lateral movement.
5. Review critical identity infrastructure
Domain controllers, PKI, administrative systems, and hybrid identity components should be treated as highly sensitive assets.
6. Assess the hybrid environment separately
If Entra ID is present, determine which objects are synchronized, which identities retain privileges on both sides, and which components connect the on-premises plane to the cloud.
A pivot should never be assumed simply because both directories are connected.
7. Document the chain, not only the final step
A report that only states “Domain Admin was obtained” loses much of the value of the assessment.
What matters is explaining which conditions made that possible: which delegation was excessive, which account had too many privileges, which control was missing, and which specific change would have broken the chain.
This turns an offensive demonstration into a defensive roadmap.
What this means for offensive security
Active Directory pentesting forces you to think differently from the exploitation of an isolated vulnerability.
Knowing a collection of techniques is not enough. You need to understand authentication, permissions, protocols, Windows systems, networks, identity, and trust relationships.
Above all, you need to learn to think in paths.
One configuration may look acceptable on its own. A second one may also seem harmless. The auditor's job is to discover what happens when both are combined.
This mindset applies far beyond Active Directory. It is the same reasoning used in web security when several findings with apparently limited severity form a much larger compromise chain.
At SixHack Academy, we work precisely on that methodology: understand the system first, identify its trust boundaries, validate impact with the minimum necessary intrusion, and document evidence that can be reproduced.
Internal pentesting expands that reasoning from applications into identities, endpoints, networks, and infrastructure services.
An assessment does not end when you find a vulnerability. It begins when you understand how far it can take you.
At SixHack Academy, we teach an offensive methodology based on understanding systems, validating risk, and chaining trust relationships with professional judgment.
Frequently asked questions
What is Kerberoasting?
Kerberoasting is a technique that uses normal Kerberos behavior to obtain service tickets associated with accounts that have SPNs and then perform offline password recovery attempts. The risk is especially significant when those accounts use weak passwords or have elevated privileges.
What is the difference between Kerberoasting and AS-REP Roasting?
Kerberoasting is related to accounts running services registered with SPNs. AS-REP Roasting affects accounts that have Kerberos preauthentication disabled. Both can involve an offline password recovery phase, but the condition that enables each technique is different.
What is DCSync?
DCSync is the abuse of Active Directory replication rights to request information from a domain controller that would normally be exchanged with authorized replication components. With sufficiently broad permissions, it may expose credential material belonging to sensitive accounts.
Does DCSync automatically mean a Golden Ticket?
No. A Golden Ticket requires the cryptographic material associated with the krbtgt account. DCSync can be one way of reaching that material if the compromised identity has the necessary replication rights, but they are separate techniques.
Why is the krbtgt password reset twice after a compromise?
The domain retains the current and previous key to support ticket transitions. During recovery, two properly spaced resets allow compromised keys to be removed from the key history. The supported procedure should always be followed, taking into account the ticket lifetimes configured in the environment.
Why can AD CS be dangerous?
Certificates can be used as an authentication mechanism. If templates, permissions, or issuance policies are misconfigured, an identity may obtain a certificate with capabilities beyond what it should have, turning PKI into a privilege escalation path.
Does compromising Active Directory automatically mean compromising Entra ID?
No. The impact depends on the hybrid architecture. Identities with privileges on both sides, synchronization configuration, applications, and trust relationships may create paths between the environments, but synchronization by itself does not imply an automatic pivot.
Can a PRT simply be copied to another device and reused?
That should not be assumed. On supported platforms, the Primary Refresh Token is cryptographically bound to the device and may rely on hardware-protected keys. The actual security depends on the device, its state, and the token protection and Conditional Access controls in place.
Which events should be monitored?
There is no single list that can detect every attack. Events such as 4768, 4769, 4662, 5136, 4886, and 4887 provide useful context when the required auditing is enabled. Their real value comes from correlating them with identity, source, volume, and normal behavior.
What is the objective of an Active Directory pentest?
It should not simply be “obtain Domain Admin”. The objective is to identify realistic compromise paths, demonstrate their impact with the minimum necessary intrusion, and explain which controls must change to break each chain.
References
- Official documentation — Event 4769 : Kerberos service ticket requests and fields available for monitoring.
- Official documentation — Group Managed Service Accounts : automatic credential management for service accounts.
- Official documentation — Windows LAPS : management and rotation of local administrator passwords.
- Official documentation — Protected Users : additional protections against credential storage and reuse for sensitive identities.
- Official documentation — Resetting krbtgt : supported procedure for renewing the account keys during domain recovery.
- Official documentation — Active Directory security best practices : recommendations for privileged credentials and attack surface reduction.
- Official documentation — Primary Refresh Token : PRT behavior, protection, and device binding.
- Official documentation — Token protection : mechanisms designed to reduce reuse of stolen tokens.
- Official documentation — Hybrid privileged identity risk : recommendations for separating Active Directory and Entra ID privileges.
- Official documentation — Protecting hybrid environments : trust relationships between on-premises infrastructure and cloud resources.
- Official documentation — AD CS certificate templates : template design, permissions, subject identity, and secure template management.