Active Directory VAPT: Kerberoasting to Domain Admin

Active Directory remains the primary identity infrastructure for the majority of enterprise IT environments, and it remains the primary target of internal network penetration testing. The pattern is remarkably consistent across engagements: initial access from a low-privileged user account, systematic enumeration of the directory, identification of misconfigurations that permit privilege escalation, and progression to Domain Admin equivalent access within days. This document describes what a defensive VAPT programme assesses and the controls that actually prevent the escalation paths that repeatedly succeed.

Directory Enumeration as the Starting Point

Any authenticated domain user, regardless of privilege level, can read most of the Active Directory schema. This is by design — normal application functionality requires domain users to discover services, group memberships, and organisational structure. The information available to a low-privileged user is sufficient to plan a complete escalation path in most enterprise environments. BloodHound and related tools automate the enumeration and graph analysis to identify escalation paths that would take weeks to discover manually.

A defensive VAPT assessment begins with the same enumeration an attacker would perform, from an authenticated but unprivileged account. The output is a graph of user accounts, group memberships, computer objects, service accounts, and the trust relationships between them. Analysis of this graph identifies the shortest escalation paths from arbitrary starting points to high-value targets — typically Domain Admin, Enterprise Admin, or accounts with equivalent privileges via less-obvious paths.

The graph analysis frequently reveals surprises. Backup service accounts with unnecessary domain-wide permissions, help desk groups with password reset rights over privileged accounts, application service accounts with local administrator rights across large numbers of workstations, and machine account quotas that permit any authenticated user to create new machine accounts are all common findings. Each of these becomes a starting point for further escalation analysis. The output of enumeration is not a list of vulnerabilities but a map of the escalation surface that subsequent testing will validate.

Kerberoasting as a Historical Artifact

Kerberoasting exploits a deliberate feature of the Kerberos authentication protocol. Service accounts registered with Service Principal Names (SPNs) can have Kerberos service tickets requested by any authenticated user, and the tickets are encrypted with the service account's password hash. Weak service account passwords can be recovered by offline brute-force analysis of the captured tickets. The attack requires no elevated permissions to initiate and produces no immediate detection signals.

The defensive posture against Kerberoasting is a combination of eliminating weak service account passwords and detecting the enumeration behaviour that precedes the offline attack. Group Managed Service Accounts (gMSAs) eliminate the attack surface entirely for the service accounts that support them because the passwords are managed by the domain and rotated automatically with high-entropy random values. Any service that supports gMSAs should use them; assessments should identify traditional service accounts that could be migrated.

For service accounts that must remain traditional, minimum password length policies specific to service accounts (28 characters or longer) push offline cracking outside the timeframe of most engagements. Detection of Kerberos ticket request enumeration — the operational signal of Kerberoasting preparation — is supported by Windows Event ID 4769 correlation but requires SIEM tuning to filter legitimate service ticket requests from anomalous enumeration. A defensive assessment reviews the detection posture as much as the underlying password strength.

AS-REP Roasting and Preauthentication Gaps

AS-REP roasting is a related attack against accounts that have the "Do not require Kerberos preauthentication" flag set. Preauthentication was introduced specifically to prevent offline attacks against user password hashes; disabling it exposes the account's hash to any authenticated user (and sometimes to any user, depending on domain configuration). The attack surface should be zero in a well-managed domain because no legitimate account should have preauthentication disabled.

Assessments consistently find accounts with preauthentication disabled — historical service accounts, accounts created to work around legacy application issues, and accounts left over from migrations. Every account with this flag should be reviewed against current requirements, and the flag should be re-enabled wherever operational testing confirms preauthentication is compatible with the accounts' use. The defensive checklist here is short and mechanical: enumerate accounts with the flag, review each, remediate where possible.

Preauthentication configuration should be monitored for regression. New accounts should not be created with preauthentication disabled, and existing accounts should not have the flag re-added. A Group Policy Object that alerts on preauthentication flag changes, or a scheduled compliance check that produces a daily report of accounts with the flag disabled, provides the ongoing assurance that reduces the risk of regression between assessments.

Active Directory Certificate Services (ADCS) Concerns

ADCS has become one of the highest-impact areas of Active Directory VAPT since research published in 2021 catalogued a series of certificate template misconfigurations that permit escalation to Domain Admin. The identified misconfigurations — collectively referred to as ESC1 through ESC8 with subsequent additions — allow a low-privileged user to request a certificate that authenticates them as an arbitrary user, including Domain Admin, if the affected certificate templates and CA configurations exist in the environment.

A defensive assessment enumerates every certificate template published in the domain and every CA server configuration, checking each against the documented misconfiguration patterns. The specific templates that permit escalation typically permit low-privileged users to enroll, have the "Client Authentication" extended key usage, and either permit the requester to specify the subject or use the User Principal Name from the requester for subject construction. Templates matching these patterns are the highest-priority remediation targets.

The remediation for ADCS misconfigurations is usually straightforward — restrict template enrollment permissions, remove client authentication from templates that don't need it, and disable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on CAs where it is not required. The obstacle to remediation is that certificate templates are often not centrally documented and each template requires investigation to determine legitimate use before changes are made. A defensive assessment produces the inventory that makes remediation planning feasible.

Group Policy Preferences and Legacy Credential Storage

Group Policy Preferences (GPP) permitted administrators to embed credentials in Group Policy Objects for tasks like scheduled task creation, service account changes, and local administrator password management. The credentials were encrypted with a well-known key that Microsoft published in documentation, making the encryption effectively decorative. Microsoft removed the capability to store new credentials via GPP in 2014 but did not remove existing stored credentials, and many domains still contain GPP files with legacy credentials.

A defensive assessment searches SYSVOL for GPP files containing encrypted credentials and enumerates the accounts affected. The remediation is to remove the GPP files after ensuring the credentials they contained have been rotated. This is a mechanical remediation that has been necessary for over a decade but continues to appear in assessments because SYSVOL contents are frequently forgotten by administrative teams focused on active configuration management.

Local Administrator Password Solution (LAPS) is the modern replacement for the local administrator management use case that GPP served. LAPS stores randomly-generated local administrator passwords in Active Directory attributes protected by access control lists, rotates the passwords automatically, and requires explicit permissions to retrieve. Deployment of LAPS is a defensive posture improvement that also addresses the tangential concern of lateral movement via reused local administrator passwords across large numbers of workstations.

DCSync and the Case for Tiered Administration

DCSync is a technique that requests replication of the entire Active Directory database from a domain controller, exposing all password hashes including the Kerberos KRBTGT account hash. It requires specific replication permissions — Replicating Directory Changes and Replicating Directory Changes All — which are held by domain controllers but should not be held by any other account. Assessments frequently find these permissions delegated to service accounts, backup accounts, or migration accounts that no longer need them.

Once DCSync is possible, the resulting KRBTGT hash enables Golden Ticket generation — forged Kerberos tickets that authenticate as any user with any privileges, remain valid until the KRBTGT password is rotated twice (which almost no organisation does routinely), and produce minimal detection signals because they exercise legitimate Kerberos code paths. The blast radius of a DCSync capability is effectively total domain compromise with persistent access.

The defensive control against DCSync is tiered administration — Microsoft's Active Directory Tier Model. Under the tier model, accounts with rights over domain controllers (Tier 0) are strictly separated from accounts with rights over servers (Tier 1) and workstations (Tier 2). Tier 0 accounts do not log into lower tiers, workstations do not have Tier 0 credentials cached, and administrative workstations for Tier 0 activities are hardened and isolated. Full tier model deployment is a substantial project but consistently reduces the incident rate of Domain Admin compromise more effectively than any technical control focused on specific attack techniques.