# OSCP Prep #3 
HTB Write-Up : Active
 

# 1\. Target Overview

**Target Name:** Active  
**Platform:** HackTheBox  
**Operating System:** Windows  
**Environment:** Active Directory

In this engagement, I targeted the HackTheBox machine **Active**, which is a Windows host operating within an Active Directory environment. The goal of this exercise was to enumerate the target, identify potential weaknesses within the domain environment, obtain an initial foothold, and ultimately escalate privileges to achieve full administrative control.

As this machine is part of an **Active Directory domain**, the engagement focuses not only on host-level vulnerabilities but also on weaknesses in **domain services, authentication mechanisms, and network shares**, which are common attack surfaces in Windows enterprise environments.

### **Tools Used**

**Nmap**  
Used for initial network discovery and service enumeration.

**NetExec**  
Used for SMB enumeration, credential validation, and share spidering.

**smbclient**  
Used to manually access SMB shares and retrieve files.

**gpp-decrypt**  
Used to decrypt the `cpassword` value stored inside Group Policy Preference files.

**Impacket**  
Used for multiple Active Directory attack techniques including Kerberoasting and remote command execution.

**John the Ripper**  
Used to crack the Kerberos service ticket hash offline.

# 2\. Enumeration

## Active Directory Attack Checklist

To maintain a structured workflow, I followed a **repeatable attack checklist** for Active Directory environments.

1.  **Add FQDN to** `/etc/hosts`
    

* * *

## Port Scanning

As always, I began the engagement by performing a **port scan** against the target to identify exposed services and gather initial information about the system. **Command used:**

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/1ecae68a-276e-4cb5-8e1b-09f7f3e4844b.png align="center")

The scan revealed several services commonly associated with **Active Directory domain controllers**, including DNS, Kerberos, SMB, LDAP, and RPC services.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5d42da9d-20de-41e5-8c14-62e051b5145a.png align="center")

These services strongly suggested that the target is functioning as a **Domain Controller**.

The scan also revealed useful host information:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/90c6cc99-ce2e-449f-9025-5cda9dd28f26.png align="center")

This indicates the hostname of the system is **DC**, which is typical naming for a **Domain Controller**.

Additionally, LDAP enumeration revealed the **domain name**:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/bb8ae5c0-1108-450d-ac5a-177c7f28628a.png align="center")

Because Active Directory environments rely heavily on DNS resolution, the first step in my attack checklist was to add the **Fully Qualified Domain Name (FQDN)** to my `/etc/hosts` file. **Command used:**

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/be1ae1ad-e387-4a34-b6c7-ae65c024272e.png align="center")

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/ce11b43d-da04-4caf-a646-b900304e7d54.png align="center")

This ensures proper resolution when interacting with **Kerberos, SMB, and LDAP services** during further enumeration.

## SMB Enumeration

After identifying the target as an Active Directory domain controller, the next step in my checklist is to investigate **SMB**, which is often one of the most valuable enumeration vectors in Windows environments.

Many organizations expose file shares that contain:

*   login scripts
    
*   configuration files
    
*   backup data
    
*   credentials or sensitive information
    

Because of this, SMB enumeration is always **step two** in my Active Directory attack methodology.

To begin, I attempted **anonymous authentication** and listed the available shares using **NetExec**.

```plaintext
nxc smb 10.129.4.185 -u '' -p '' --shares
```

The results showed that **null authentication was allowed**, which allowed me to enumerate the available shares.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/1aa21a66-fd76-4cd1-9559-b3517e3121db.png align="center")

Of particular interest was the **Replication share**, which allowed **read access**. Shares that allow anonymous read permissions can sometimes contain scripts, backups, or configuration files that expose sensitive information useful for further exploitation. Share Spidering

To recursively enumerate files inside accessible shares, I used the **NetExec** `spider_plus` **module**.

```plaintext
nxc smb 10.129.4.185 -u '' -p '' -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$,print$'
```

This revealed several Group Policy files, including:

```plaintext
groups.xml
```

Group Policy Preference files have historically been known to store **encrypted credentials**, making this file particularly interesting.

* * *

## Retrieving groups.xml

To inspect the file further, I connected to the Replication share using **smbclient**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d316d056-b5d3-436b-9259-03646974e5c3.png align="center")

I then downloaded the file:

```plaintext
get Groups.xml
```

* * *

## Inspecting groups.xml

Examining the file revealed a username and `cpassword` field embedded within the XML configuration.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/11a8473a-827e-4201-a99d-f9c2c869770d.png align="center")

Because the encryption mechanism used by Group Policy Preferences is publicly known, the password can be decrypted using specialized tools.

# 3\. Exploitation

## Decrypting the GPP Credential

Using the `gpp-decrypt` tool, I decrypted the password contained in the `groups.xml` file.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0d269587-735d-4cbe-9e1d-3a773f8ba5bf.png align="center")

This revealed the following domain credentials:

```plaintext
SVC_TGS : GPPstillStandingStrong2k18
```

* * *

## Validating Credentials

I verified that the credentials were valid using NetExec:

This confirmed successful authentication to the domain and the enumeration returned four users:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f8311e6d-2c1d-4ea5-9f98-0a2808a34f1d.png align="center")

Since there were no additional accounts to pivot to, the next step was to determine whether the SVC\_TGS service account could be abused for privilege escalation.

# 4\. Privilege Escalation

## Password Spraying

Since I had obtained a valid password for the **SVC\_TGS** account, my first step was to test whether the same password had been reused across other accounts in the domain.

Password reuse is extremely common in enterprise environments, making **password spraying** a useful technique whenever new credentials are discovered.

I attempted to authenticate using the recovered password against other domain users, including the **Administrator account**.

However, the password was **not valid for the Administrator account**, indicating that password reuse was not present in this case.

* * *

## Next Attack Vector

Because there were no additional user accounts to pivot to and password spraying did not reveal any further access, the next logical step was to investigate whether the **SVC\_TGS service account** could be abused for privilege escalation.

Service accounts in Active Directory are often associated with **Service Principal Names (SPNs)** and can sometimes be exploited through **Kerberoasting attacks**, which allow attackers to request service tickets and attempt offline password cracking.

With valid credentials for the **SVC\_TGS account**, the next step was to attempt **Kerberoasting**.

## Kerberoasting

Because I had valid domain credentials, I attempted a **Kerberoasting attack** using Impacket.

This successfully returned a **Kerberos service ticket hash** associated with the **Administrator account**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0174a6ea-59c8-46c2-b334-6ef05b6ff573.png align="center")

Kerberoasting allows attackers to request service tickets for accounts with **Service Principal Names (SPNs)** and attempt to crack them offline.

* * *

## Cracking the Kerberos Hash

After obtaining the Kerberos ticket hash, I cracked it offline using **John the Ripper**.

The password was successfully recovered:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/6a8ac951-39c8-40f4-844a-c58e9576051c.png align="center")

This revealed valid **Administrator credentials**.

* * *

## Domain Administrator Access

With Administrator credentials obtained, I used **Impacket’s PsExec** tool to execute commands on the target system.

After authentication, I gained a shell on the target machine and verified my privileges:

At this point, I had successfully obtained **full administrative control of the domain controller**, completing the attack chain.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/405f84a1-9b16-408f-b866-72ebc336e1a9.png align="center")

# 5\. Lessons Learned

This engagement highlighted several important security weaknesses that ultimately led to full domain compromise.

**1\. Anonymous SMB Access Can Expose Sensitive Data**

The initial foothold in this attack chain came from **anonymous SMB access**. Because the Replication share allowed unauthenticated read permissions, I was able to enumerate internal files and discover sensitive Group Policy artifacts.

Allowing anonymous access to SMB shares significantly increases the attack surface of an Active Directory environment and can expose configuration files, scripts, or credentials that were never intended to be publicly accessible.

* * *

**2\. Storing Credentials in Group Policy Preferences (**`cpassword`**) Is Dangerous**

The `groups.xml` file contained a `cpassword` field, which is a legacy mechanism used by Group Policy Preferences (GPP) to store credentials.

Although the password is technically encrypted, the encryption key was publicly disclosed by Microsoft many years ago, meaning the password can be trivially decrypted using tools such as:

```plaintext
gpp-decrypt
```

Because of this, storing credentials using **GPP cpassword values is considered obsolete and insecure**.

* * *

**3\. Service Accounts Are High-Value Targets**

Once domain credentials were obtained, the **SVC\_TGS service account** became the primary pivot point for further attacks.

Service accounts often have **Service Principal Names (SPNs)** assigned to them, making them vulnerable to **Kerberoasting attacks**, where attackers request Kerberos service tickets and attempt to crack them offline.

Weak passwords on service accounts can therefore lead directly to privilege escalation within the domain.

# 6\. Defensive Insight

This attack chain highlights several common Active Directory misconfigurations that organizations should address to prevent domain compromise.

### 1\. Restrict Anonymous SMB Access

The initial entry point in this engagement came from **anonymous access to an SMB share**. Because the Replication share allowed unauthenticated read access, I was able to enumerate internal Group Policy files and retrieve sensitive configuration data.

Organizations should ensure that:

*   Anonymous SMB authentication is **disabled wherever possible**
    
*   File shares are configured using **least privilege access controls**
    
*   Sensitive configuration files are **not accessible without authentication**
    

Regular audits of SMB permissions can significantly reduce the risk of sensitive data exposure.

* * *

### 2\. Eliminate Group Policy Preference Credentials

The presence of a `cpassword` **field inside a Group Policy Preference file** represents a legacy security issue that has been widely documented.

Because the encryption key used by GPP is publicly known, any attacker who obtains the file can easily decrypt the stored password using widely available tools.

Microsoft has long deprecated this mechanism and recommends:

*   **Removing any GPP credentials from domain policies**
    
*   Using **Group Managed Service Accounts (gMSA)** or secure credential management solutions instead
    
*   Regularly auditing domain controllers for **GPP credential artifacts**
    

Failure to remove these legacy configurations can expose domain credentials to attackers.

* * *

### 3\. Harden Service Account Security

The **SVC\_TGS service account** ultimately allowed privilege escalation through a **Kerberoasting attack**.

Service accounts are particularly attractive targets because they often have:

*   Elevated privileges
    
*   Service Principal Names (SPNs)
    
*   Long-lived passwords that rarely change
    

To mitigate Kerberoasting risks, organizations should:

*   Enforce **strong password policies for service accounts**
    
*   Use **long randomly generated passwords**
    
*   Implement **Group Managed Service Accounts (gMSA)** where possible
    
*   Monitor for abnormal **Kerberos ticket requests**
    

Security monitoring tools should also alert administrators when unusual numbers of **Kerberos service ticket requests** occur.

* * *

### 4\. Monitor for Kerberoasting Activity

Kerberoasting attacks require requesting Kerberos service tickets from the domain controller. This activity generates **Event ID 4769** in Windows logs.

Security teams should monitor for:

*   Unusual volumes of **service ticket requests**
    
*   Kerberos tickets requested for **multiple service accounts in rapid succession**
    
*   Requests originating from **non-standard hosts**
    

Detecting these patterns early can allow defenders to identify Kerberoasting attempts before passwords are cracked offline.

# Final Thoughts

This machine provided a great demonstration of how small weaknesses in an Active Directory environment can quickly lead to full domain compromise when approached with a structured methodology.

The initial foothold came from **anonymous SMB access**, which exposed internal Group Policy files. From there, the discovery of a **Group Policy Preference credential (**`cpassword`**)** allowed me to recover valid domain credentials for the **SVC\_TGS service account**.

Although those credentials did not immediately grant administrative access, they provided enough domain authentication to perform **Kerberoasting**, which ultimately exposed the password for the **Administrator account** through offline cracking.

This attack chain highlights the importance of **methodical enumeration in Active Directory environments**. Rather than relying on a single vulnerability, the compromise resulted from chaining together multiple weaknesses

# Useful Commands

* * *

### SMB Share Enumeration

```plaintext
nxc smb <target-ip> -u '' -p '' --shares
```

* * *

### SMB Share Spidering

```plaintext
nxc smb <target-ip> -u '' -p '' -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$,print$'
```

* * *

### Downloading Files from SMB

```plaintext
smbclient //<target-ip>/Replication -N
```

```plaintext
get Groups.xml
```

* * *

### Decrypting GPP Password

```plaintext
gpp-decrypt <cpassword>
```

* * *

* * *

### Kerberoasting

```plaintext
impacket-GetUserSPNs -request active.htb/svc_tgs -dc-ip <target-ip>
```

* * *

### Cracking Kerberos Hash

```plaintext
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
```

* * *

### Remote Command Execution

```plaintext
impacket-psexec administrator@<target-ip>
```