Forest is one of those boxes that feels like a guided tour through Active Directory attack fundamentals. No CVEs, no fancy exploits - just proper AD enumeration, a misconfigured service account, and a BloodHound-mapped path straight to domain admin.
Machine Info
| Field | Details |
|---|---|
| Name | Forest |
| Platform | HackTheBox |
| OS | Windows |
| Difficulty | Easy |
| IP | 10.129.5.64 |
TL;DR
SMB user enumeration reveals a service account with no Kerberos pre-auth required. AS-REP roasting gives us a crackable hash. Shell as svc-alfresco via WinRM. BloodHound maps a path through Exchange groups giving WriteDacl on the domain. We abuse that to grant DCSync, dump the Administrator hash, and psexec our way to SYSTEM.
Recon
The port list is a dead giveaway: DNS (53), Kerberos (88), LDAP (389), SMB (445), Global Catalog (3268), WinRM (5985). This is a domain controller. The hostname is FOREST and the domain is htb.local.
Enumeration
With SMB accessible and no credentials yet, let’s see what we can enumerate without auth.
| |
Anonymous SMB gives us the full user list - this is more common than you’d expect on older AD environments. The interesting account here is svc-alfresco. Service accounts often have weaker configurations, and in this case it turns out to have a critical one.
Foothold
AS-REP Roasting
Kerberos pre-authentication is a setting that forces clients to prove they know the account’s password before the KDC will hand out a ticket. When it’s disabled on an account, anyone can request a ticket for that user and get an encrypted blob back - without knowing the password first. That blob can then be cracked offline.
| |
svc-alfresco doesn’t have UF_DONT_REQUIRE_PREAUTH set (meaning pre-auth IS disabled), so we get a Kerberos AS-REP hash back. John handles the rest.
Password: s3rvice. WinRM is open on port 5985, let’s try it.
We’re in.
Privilege Escalation
BloodHound Mapping
With a foothold, the next step is understanding the AD environment. BloodHound is the standard tool for this - it collects relationships between users, groups, computers and GPOs, then maps attack paths.
| |
The graph tells a clear story: svc-alfresco is a member of Service Accounts, which is inside Privileged IT Accounts, which gives membership in Account Operators. Account Operators can manage most groups - including Exchange Windows Permissions. And that group has WriteDacl on the HTB.LOCAL domain object.
WriteDacl on the domain means we can modify the domain’s ACL. Specifically, we can grant ourselves DCSync rights - the ability to replicate domain credentials as if we were another domain controller.
Abusing WriteDacl
Step one: add svc-alfresco to the Exchange Windows Permissions group.
| |
Step two: use bloodyad to grant DCSync rights to our account.
| |
DCSync and Pass-the-Hash
With DCSync rights in place, we can ask the domain controller to replicate the Administrator’s credentials to us using secretsdump.
| |
We have the Administrator NTLM hash. No need to crack it - pass-the-hash with psexec gets us a SYSTEM shell directly.
| |
nt authority\system. Root flag on the desktop.
Takeaways
AS-REP roasting is low-hanging fruit in any AD assessment. Accounts with Kerberos pre-auth disabled hand you a crackable hash with zero credentials. Always run GetNPUsers against any user list you can enumerate.
BloodHound turns complex AD graphs into actionable paths. Without it, the chain from svc-alfresco through Exchange groups to WriteDacl on the domain would take hours to map manually. With it, it’s a five-minute read.
Exchange-related groups in AD are notorious for overprivileged ACLs. The Exchange Windows Permissions group existing with WriteDacl on the domain is a known design issue left behind by Exchange installations. Even in environments that have removed Exchange, these ACLs often linger.