Forest HTB
Forest HTB Summary Forest is an Active Directory-focused Hack The Box machine where anonymous RPC access allowed domain user enumeration. AS-REP Roasting against the discovered users exposed a crackable hash for svc-alfresco, providing valid credentials and WinRM access. BloodHound revealed that svc-alfresco inherited privileges through nested group memberships, eventually leading to control over the Exchange Windows Permissions group. Since this group had WriteDACL over the htb.local domain, a new user was created and granted DCSync rights. Using those permissions, the Administrator NTLM hash was extracted with secretsdump and used in a pass-the-hash attack through Evil-WinRM, resulting in full Domain Administrator access. Nmap Scanning I began with an Nmap scan to identify the services exposed by the target. --- Nmap Scan Analysis The scan results strongly suggested that the target was a Windows Domain Controller named FOREST for the htb.local Active Directory domain. Several services commonly associated with Active Directory were exposed: | Port | Service | Purpose | |---|---|---| | 53 | DNS | Active Directory-integrated name resolution | | 88 | Kerberos | Domain authentication | | 135 | MSRPC | Windows Remote Procedure Call | | 139 | NetBIOS | Legacy Windows networking | | 389 | LDAP | Active Directory directory services | | 445 | SMB | File sharing and domain-related communication | | 464 | Kerberos password change | Password management for Kerberos accounts | | 593 | RPC over HTTP | Windows RPC communication | | 636 | LDAPS | LDAP over TLS | | 3268 | Global Catalog LDAP | Forest-wide directory queries | | 3269 | Global Catalog LDAPS | Encrypted forest-wide directory queries | | 5985 | WinRM | Remote PowerShell management | The combination of Kerberos, LDAP, SMB, DNS, and Global Catalog services confirmed that this system was functioning as a Domain Controller. The scan also revealed: SMB signing was enabled and required, which meant traditional SMB relay attacks would not be possible against this host. However, the scan reported that null authentication was accepted, making unauthenticated SMB and RPC enumeration worth testing. --- Adding the Domain Name I added the target IP address and identified domain names to /etc/hosts. This allowed tools to resolve the domain name locally without relying on external DNS. --- SMB Enumeration I began SMB enumeration with NetExec. The output confirmed several important details: The target was running Windows Server 2016. The hostname was FOREST. The Active Directory domain was htb.local. SMB signing was required. SMBv1 was enabled. Null authentication was accepted. I attempted to enumerate SMB shares anonymously, but no useful shares were accessible. Since null authentication was enabled, I moved to RPC enumeration. --- RPC Null Session I connected to the RPC service without supplying a username or password. The connection succeeded, confirming that the target permitted an unauthenticated RPC null session. An RPC null session can expose domain information such as usernames, groups, password policies, and Security Identifiers without requiring valid credentials. --- Enumerating Domain Users I used the enumdomusers command to retrieve the list of domain accounts. The output contained built-in accounts, Exchange-related service accounts, health mailboxes, and several normal domain users. For further authentication testing, I extracted the most relevant usernames: I saved these entries to a file named users.txt. --- Testing for AS-REP Roasting With a confirmed list of valid domain users, I tested whether any account had Kerberos pre-authentication disabled. The GetNPUsers utility requests Kerberos authentication responses for the supplied usernames without providing a password. Under normal Kerberos authentication, a user must first prove knowledge of their password by sending encrypted timestamp data during the pre-authentication stage. If the account has the following setting enabled: the Key Distribution Center returns an AS-REP response without first validating the user's password. Part of that response is encrypted using a key derived from the account's password. An attacker can save this encrypted data and attempt to crack it offline without causing repeated authentication attempts against the domain controller. The returned hash began with: This confirmed that svc-alfresco was vulnerable to AS-REP Roasting. The 23 value identified the RC4-HMAC encryption type, which is directly supported by common password-cracking tools such as John the Ripper and Hashcat. --- Cracking the AS-REP Hash I saved the returned hash to a file named hash-alfresco and attempted to crack it using the RockYou wordlist. John successfully recovered the password: The weak password made the AS-REP hash crackable almost immediately. --- Validating the Credentials Before attempting remote access, I validated the recovered credentials against SMB. The successful authentication confirmed that the credentials were valid for the htb.local domain. Since port 5985 was exposed, the account might also have permission to access the system through WinRM. --- Obtaining a WinRM Shell I used Evil-WinRM to authenticate with the recovered service account credentials. The connection succeeded, providing an interactive PowerShell session as: This confirmed that the account was a member of a group permitted to connect through Windows Remote Management. --- Capturing the User Flag I navigated to the user's desktop and located user.txt. Privilege Escalation With a foothold as svc-alfresco, the next objective was to understand the account's position inside Active Directory and identify any permissions that could be abused to reach Domain Administrator privileges. For this, I used SharpHound to collect Active Directory relationship data and analyse it in BloodHound. --- Uploading SharpHound I uploaded SharpHound.exe to the compromised host through the existing Evil-WinRM session. The upload completed successfully. SharpHound collects information about Active Directory objects and their relationships, including: Group memberships Access Control Lists Local administrator rights Remote-management permissions Active sessions Domain trusts Delegated control Object ownership This information can then be imported into BloodHound to identify privilege-escalation paths that may not be obvious through manual enumeration. --- Collecting BloodHound Data I executed SharpHound from the compromised host. SharpHound resolved multiple collection methods and began gathering Active Directory information from the htb.local domain. Once the collection completed, it generated a ZIP archive containing the JSON files required by BloodHound. --- Downloading the BloodHound Archive I downloaded the generated ZIP archive to my attack machine. The BloodHound archive was downloaded successfully and then imported into BloodHound for analysis. --- BloodHound Analysis After importing the collected data, I marked svc-alfresco as Owned. image I then inspected the account's outbound control. Screenshot 2026-07-27 at 23-54-20 BloodHound revealed a privilege-escalation path from svc-alfresco to control over the htb.local domain. Screenshot 2026-07-31 at 23-37-11 The path was based on the following nested group memberships and permissions: The important relationships were: svc-alfresco was a member of the Service Accounts group. Service Accounts was nested inside Privileged IT Accounts. Privileged IT Accounts was a member of Account Operators. Members of Account Operators could create and manage non-protected domain accounts. Account Operators had GenericAll control over the Exchange Windows Permissions group. Exchange Windows Permissions had WriteDACL permission over the HTB.LOCAL domain object. The final WriteDACL permission was the critical weakness. WriteDACL allows a principal to modify an object's Discretionary Access Control List. Because the affected object was the domain itself, a member of Exchange Windows Permissions could assign additional domain-level permissions to another account. This meant we could create an account under our control, add it to the required groups, and modify the domain ACL to grant that account DCSync privileges. --- Privilege-Escalation Plan The attack required four main steps: Create a new domain user. Add the user to Exchange Windows Permissions. Add the user to Remote Management Users for WinRM access. Abuse WriteDACL over the domain to grant the user DCSync rights. Using a separate account for this attack also made credential handling easier because we controlled its username and password. --- Creating a Domain User As svc-alfresco, I created a new domain account named pentest. The credentials were: The command succeeded because the effective group membership inherited through Account Operators allowed svc-alfresco to create and manage standard domain accounts. --- Adding the User to Exchange Windows Permissions I added the newly created account to the Exchange Windows Permissions group. This group possessed WriteDACL over the HTB.LOCAL domain object. By adding pentest to this group, the account inherited the ability to modify the domain's access-control entries. --- Granting Remote Management Access I also added pentest to the local Remote Management Users group. Membership in this group allowed the account to authenticate through WinRM, which would provide a stable remote-management channel if needed later. --- Validating the New Account I verified the credentials against SMB using NetExec. Authentication succeeded, confirming that the new domain account was active and the credentials were valid. The target IP had changed from the earlier enumeration because the machine had been reset, but the hostname and domain remained the same. --- Uploading PowerView To modify the domain ACL, I uploaded PowerView.ps1. PowerView provides functions for enumerating and modifying Active Directory objects, including their access-control entries. Additional information about abusing Active Directory ACL permissions can be found here: --- Loading PowerView I imported PowerView into the current PowerShell session. Dot-sourcing the script loaded its functions into the active session, allowing commands such as Add-ObjectACL to be used directly. --- Granting DCSync Rights I first converted the password for pentest into a PowerShell secure string and created a credential object. I then used Add-ObjectACL to grant DCSync rights to the pentest account. The command completed without returning an error, indicating that the required access-control entries had been added successfully. --- Understanding DCSync DCSync is an Active Directory credential-replication technique that abuses the same protocol used by domain controllers to synchronise directory data. In a normal environment, domain controllers replicate sensitive information between each other using the Directory Replication Service Remote Protocol. This replication data includes password hashes stored inside the Active Directory database. An account capable of DCSync does not need interactive access to the domain controller or direct access to the NTDS.dit database. Instead, it can impersonate a domain controller and request selected account secrets through the replication interface. The most important extended rights associated with DCSync are: In some environments, the following right may also be relevant: These permissions are normally held by highly privileged groups such as: By granting the required replication rights to pentest, the account could now request password material for domain users, including the built-in Administrator account. The attack did not reset or modify the Administrator password. It replicated the existing NTLM hash directly from Active Directory. Dumping the Administrator Hash I used Impacket's secretsdump to request the Administrator account's NTLM hash. The options limited the replication request to the built-in Adm