VenomousViper Labs
Portfolio Writeups
← Back to Writeups

AD Attack Path Assessment

Analyst: Jeremy Tarkington
Engagement Type: Internal Active Directory attack-path assessment (lab)
Targets: HTB "Forest" (10.10.10.161) & "Active" (10.10.10.100)

1. Executive Summary

This assessment examined two Windows Active Directory environments ("Forest" and "Active") to identify realistic attack paths from unauthenticated network access to full domain compromise.

Across both environments, I was able to:

In both cases, the end state was complete control over the domain, including the ability to dump NTDS hashes and execute arbitrary code on domain controllers.

The findings demonstrate how relatively small misconfigurations (legacy GPP credentials, "Do not require pre-auth" flags, excessive group permissions) combine into reliable, repeatable attack chains that an adversary can weaponize with widely available tooling (Impacket, BloodHound, Hashcat, Evil-WinRM).

2. Scope and Environment

2.1 Objectives

  1. Enumerate externally visible services on each domain controller.
  2. Identify credential-exposure and privilege-delegation weaknesses.
  3. Validate whether an unauthenticated or low-privilege user can reach Domain Admin.
  4. Document the full attack chains and provide remediation guidance.

2.2 Systems in Scope

Forest

Active

3. Methodology

  1. Network Reconnaissance - Full TCP/UDP port scan using nmap to identify exposed services; DNS enumeration against the domain controllers.
  2. Unauthenticated Enumeration - Anonymous / null-session checks against SMB (smbclient, smbmap) and RPC (rpcclient); Enumeration of domain users and groups via RPC where permitted.
  3. Credential Acquisition - AS-REP Roasting (Forest) using Impacket's GetNPUsers.py; GPP credential extraction (Active) from SYSVOL/Replication share; Kerberoasting using GetUserSPNs.py and offline cracking via Hashcat.
  4. Initial Access & Lateral Movement - Remote shell via WinRM (evil-winrm) or Impacket tools (psexec.py, wmiexec.py) using recovered credentials; Domain enumeration from a foothold using PowerShell tooling and BloodHound collectors.
  5. Privilege Escalation - In Forest, graph analysis with BloodHound to identify abuse paths (group membership and DACL abuse); Abuse of Exchange Windows Permissions and DCSync rights to dump NTDS credentials.
  6. Impact Validation - Use of secretsdump.py to obtain NTLM hashes for Administrator and other domain accounts; Confirmation of Domain Admin access via remote command execution.

All offensive activity was contained within the lab domains and conducted against test systems only.

4. Findings – Forest Domain (htb.local)

4.1 Network and Domain Enumeration

An unauthenticated nmap scan against 10.10.10.161 identified the typical service layout of a domain controller:

DNS queries against 10.10.10.161 resolved:

SMB did not allow useful anonymous access; however, an unauthenticated RPC session (rpcclient -U "" -N) was permitted and allowed full domain user and group enumeration.

Notable accounts discovered:

Notable groups:

4.2 AS-REP Roasting – Compromise of svc-alfresco

Because user enumeration was available, I tested for users with the "Do not require Kerberos preauthentication" flag set by attempting AS-REP roasting with Impacket's GetNPUsers.py against each enumerated username.

Result:

The recovered hash was then cracked using Hashcat (-m 18200 – Kerberos 5 AS-REP etype 23) and the rockyou.txt wordlist.

Recovered Credentials

Username: svc-alfresco
Password: s3rvice

These credentials were valid for domain logon.

4.3 Initial Foothold via WinRM

With the valid service account credentials, I established a remote PowerShell session to the domain controller over WinRM using evil-winrm:

The login succeeded, providing an interactive PowerShell session as HTB\svc-alfresco on the DC, and allowed retrieval of user-level artifacts such as user.txt.

This confirmed a significant security issue: a single low-privilege service account, reachable from the network, could authenticate interactively to the domain controller.

4.4 Graph-Based Escalation – Abuse of Delegated Exchange Permissions

To understand possible escalation paths from svc-alfresco to higher privileges, I:

  1. Executed the SharpHound collector from the compromised host to gather AD objects, group memberships, and access control lists.
  2. Exfiltrated the resulting BloodHound data archive for offline analysis.
  3. Loaded it into BloodHound and ran the built-in query "Find Shortest Paths to Domain Admins" from svc-alfresco.

Attack Path Identified

  1. SVC-ALFRESCO is a member of Service Accounts.
  2. Service Accounts is a member of Privileged IT Accounts.
  3. Privileged IT Accounts is a member of Account Operators.
  4. Account Operators has GenericAll rights over the Exchange Windows Permissions group.
  5. Exchange Windows Permissions has WriteDACL rights on the domain object (HTB.LOCAL), allowing attackers to assign DCSync rights to an arbitrary principal.

Practically, this meant:

4.4.1 Adding svc-alfresco to Exchange Windows Permissions

Using PowerView / PowerShell from the compromised WinRM session, I executed a one-liner to add svc-alfresco to Exchange Windows Permissions, then grant DCSync-equivalent rights over Domain Admins / the domain object.

After execution, verification via net group "Exchange Windows Permissions" confirmed svc-alfresco was a member.

4.4.2 Granting DCSync Rights and Dumping NTDS

With the new rights in place, I used Impacket's secretsdump.py from an external host, authenticating as svc-alfresco / s3rvice against 10.10.10.161.

Because DCSync rights had been granted, secretsdump.py was able to use the DRSUAPI method to replicate password data from the domain controller:

Example (truncated):

htb.local\Administrator:500:...:32693b11e6aa90eb43d32c72a07ceea6:::

This provided cryptographic control of all domain accounts.

4.5 Final Privilege Escalation – Domain Admin Shell

Using the recovered Administrator hash, I demonstrated full privilege escalation in two ways:

  1. WMI Execution (wmiexec.py) with pass-the-hash:
    • Authenticated as HTB\Administrator using the NTLM hash.
    • Obtained a SYSTEM-level interactive shell on the domain controller.
  2. WinRM as Administrator (alternative method) using Evil-WinRM with the Administrator credentials.

From this position, I had:

5. Findings – Active Domain (active.htb)

5.1 Initial Reconnaissance and SMB Enumeration

A port scan against 10.10.10.100 revealed a similar set of domain controller services (DNS, Kerberos, LDAP, SMB, RPC).

Attempted SMB connections with null credentials using crackmapexec revealed an anonymously accessible share named Replication.

This underscores the importance of always testing anonymous access even in hardened environments; in this case, it exposed highly sensitive configuration data.

5.2 Group Policy Preferences Credential Exposure (GPP)

Browsing the Replication share revealed standard SYSVOL content, including Group Policy objects.

Within one GPO directory, a file named Groups.xml was present. This file is associated with Group Policy Preferences, a legacy mechanism where local admin accounts, services, or groups could be configured centrally.

Older implementations of GPP stored passwords in Groups.xml as an encrypted cpassword value using a key that is publicly known. Microsoft released MS14-025 to address this, but legacy configurations still exist in many environments.

Using gpp-decrypt against the cpassword value in Groups.xml revealed:

Recovered Credentials

Service Account: SVC_TGS (credentials redacted)

These credentials were valid for domain authentication.

This represents a critical misconfiguration: a domain controller was serving world-readable, decryptable credentials via an openly accessible share.

5.3 Post-GPP Enumeration and SPN Discovery

With SVC_TGS credentials, I performed additional enumeration:

SPN enumeration identified a high-value SPN associated with the Administrator account. Because an SPN exists, Kerberos will issue a service ticket for that account, which can be requested and then cracked offline.

5.4 Kerberoasting and Administrator Compromise

Using Impacket's GetUserSPNs.py with SVC_TGS credentials:

The ticket hash was then cracked offline with Hashcat, yielding Domain Administrator credentials.

With these credentials, tools such as psexec.py were able to:

This chain demonstrates a classic "GPP → service account → Kerberoast Administrator" escalation path.

6. Risk and Impact

Across both domains, the cumulative impact of the identified weaknesses is complete domain compromise from an unauthenticated network vantage point.

6.1 Key Risks

6.2 Business Impact

If the same conditions existed in a production environment, an attacker could:

7. Recommendations

7.1 Identity and Credential Hygiene

  1. Remove AS-REP Roastable Flags - Ensure that no user accounts (especially service accounts) have "Do not require Kerberos preauthentication" enabled unless there is a compelling and well-documented business need; Review and remediate any such accounts with priority.
  2. Eliminate Group Policy Preferences Passwords - Search SYSVOL for Groups.xml, Services.xml, ScheduledTasks.xml, etc., containing GPP passwords; Remove embedded credentials and replace with: Managed Service Accounts (gMSA), Secure password vaults, or Modern configuration management.
  3. Audit Service Principal Names - Review accounts with SPNs, particularly where highly privileged users (e.g., Administrator) are directly associated with SPNs; Move services to dedicated, low-privilege service accounts and ensure long, complex passwords.
  4. Harden Service Accounts - Enforce strong, randomly generated passwords and rotation; Restrict logon rights to only required hosts; Deny interactive logon to domain controllers where possible.

7.2 Privilege Management and Delegation

  1. Review Group Memberships - Reassess nested groups such as Service Accounts, Privileged IT Accounts, Account Operators, and Exchange Windows Permissions; Minimize the number of accounts with: GenericAll, WriteDACL, or WriteOwner rights on security-sensitive objects; Ensure that service accounts are not indirectly granted powerful delegation paths.
  2. Limit DCSync Capabilities - Restrict Replicating Directory Changes / DCSync rights to a minimal set of tightly controlled security principals (e.g., only Domain Controllers and dedicated backup/identity services); Use tools such as BloodHound or ADSI queries to identify principals with replication privileges.

7.3 Monitoring and Detection

  1. Kerberos Abuse Detection - Monitor for: Unusual volumes of AS-REP requests without pre-auth, High rates of TGS requests (Kerberoasting patterns) from individual hosts.
  2. AD Graph Analysis - Regularly run BloodHound or similar tools to identify emerging attack paths caused by group changes, ACL drift, or new applications.
  3. Audit Remote Management Paths - Monitor WinRM, WMI, and SMB admin sessions to domain controllers; Alert on service accounts or non-admin users authenticating directly to DCs.

7.4 Hardening and Hygiene

  1. Apply Relevant Security Updates - Ensure patches equivalent to MS14-025 and other AD-related security updates are fully applied; Remove or refactor any legacy configuration that relies on deprecated features.
  2. Enforce Strong Administrative Separation - Use dedicated, tiered admin accounts for domain administration; Prohibit everyday user or service accounts from holding administrative privileges.
  3. Backup and Recovery - Maintain tested backups of AD, GPOs, and key systems; Implement procedures for recovering from full domain compromise scenarios (e.g., forest recovery).
← Back to Writeups