This is the second HTB machine I attempted before taking the PJPT exam. If you’ve done the HTB Forest machine before, this one should feel pretty smooth sailing.
It took me way less time to pwn this machine compared to Forest, probably because I was able to apply a lot of the things I learned from it.
OS: Windows
Difficulty: Easy
After nmap enumeration:
└─# nmap -T4 --min-rate 5000 -p- -sV -sC 10.129.95.180
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-23 13:26 -0400
Nmap scan report for 10.129.95.180
Host is up (0.23s latency).
Not shown: 65515 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Egotistical Bank :: Home
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-09-24 00:27:27Z)
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 (Domain: EGOTISTICAL-BANK.LOCAL, Site: Default-First-Site-Name)
445/tcp open 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 (Domain: EGOTISTICAL-BANK.LOCAL, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
49667/tcp open msrpc Microsoft Windows RPC
49673/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49674/tcp open msrpc Microsoft Windows RPC
49675/tcp open msrpc Microsoft Windows RPC
49688/tcp open msrpc Microsoft Windows RPC
49696/tcp open msrpc Microsoft Windows RPC
Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled and required
|_clock-skew: 7h00m00s
| smb2-time:
| date: 2026-09-24T00:28:21
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 148.94 seconds
From the scan results, we can identify several services and pieces of information that give us a good indication of the target’s role:
- DNS is running, which is commonly used within Active Directory environments for name resolution.
- Kerberos is running, which is a key authentication protocol used by Active Directory.
- LDAP is running, which is commonly used to query and interact with Active Directory directory services.
- The domain name is EGOTISTICAL-BANK.LOCAL
The combination of Kerberos, LDAP, and DNS, along with the presence of an Active Directory domain, is a strong indicator that this machine is a Domain Controller (DC).
I used windapsearch to check whether anonymous LDAP enumeration was allowed on the domain. It was, which meant I could query the LDAP directory without providing credentials.
This allowed me to enumerate users and other objects present in the Active Directory environment. (I learned about windapsearch while working on the HTB Forest machine, so I knew it was worth trying here as well)
I took the usernames I had enumerated and used impacket-GetNPUsers to check whether any of the accounts had Kerberos pre-authentication disabled.
If an account has Kerberos pre-authentication disabled, it may be vulnerable to AS-REP Roasting, allowing us to request an AS-REP response for the account and potentially crack the hash offline.
However, all of my attempts came back with no useful results, so there were no obvious accounts to AS-REP roast. This meant I needed to take a different approach.
From the Nmap scan, I found that HTTP port 80 was open, which indicated that the domain controller was also hosting a website that I could access.
I checked the website and found a list of team members under the “About Us” section. This was interesting because the names listed there could potentially correspond to valid user accounts within the Active Directory domain.
I created user.txt file and stored the names of the team members in the following format:
For example, if the person’s name is Fergus Smith, the username would likely be fsmith.
This is because the Active Directory environment appears to follow a common username naming convention: the first letter of the user’s last name is combined with their first name.
I then ran impacket-GetNPUsers again using my newly created user.txt file. This time, I found that the fsmith account was vulnerable to AS-REP Roasting.
Next, I used Hashcat to crack the AS-REP hash that I obtained earlier. After successfully cracking the hash, I was able to retrieve the password for the fsmith account.
From the Nmap enumeration, I also found that port 5985 was open, which is the default port used by Windows Remote Management (WinRM) over HTTP.
Since I now had valid credentials for the fsmith account, I could use Evil-WinRM to authenticate to the machine remotely.
After gaining access, I navigated to the fsmith user’s Desktop and found the user flag.
Privilege Escalation:
Privilege escalation on this machine was relatively straightforward, mainly because I had already learned about WinPEAS from the HTB Archetype machine.
WinPEAS is a Windows enumeration tool that checks various parts of a system for potential privilege-escalation opportunities, such as misconfigured services, permissions, stored credentials, and other security weaknesses.
I used WinPEAS to enumerate the machine and look for anything that could help me escalate my privileges.
For a more detailed explanation of how to download WinPEAS and run it on the Windows machine, you can refer to my HTB Archetype write-up.
After running WinPEAS, I found credentials for a service account named svc_loanmanager
Now that I had the credentials for svc_loanmanager, I knew I probably (hopefully) needed to make use of this information somehow.
The next thing that came to mind was figuring out what privileges this account had and what relationships it had with other users, groups, and computers in the domain.
To map out these relationships, BloodHound was the obvious tool to use.
I first tried using bloodhound-python to enumerate the objects and relationships within the Active Directory environment. If that didn’t work, I would have had to fall back to SharpHound and run the enumeration from the Windows machine instead.
Fortunately, bloodhound-python worked, so I was able to collect the data and ingest the resulting JSON files into BloodHound for further analysis.
I then went to the “Shortest Path to Domain Admin” section in BloodHound, but svc_loanmanager was nowhere to be seen.
At this point, I couldn’t see any obvious attack path from the account to Domain Admin, so I needed to dig a little deeper
Since our goal is to ultimately gain control of the domain, I wanted to see which objects had control or administrative privileges over the Active Directory domain.
Bingo! We found that the svc_loanmanager account actually has the GetChangesAll privilege over the Active Directory domain.
This was a significant finding because GetChangesAll is one of the permissions required to perform a DCSync attack. DCSync abuses Active Directory replication functionality to request password-related data for domain accounts as if the requesting account were another domain controller.
This meant I could potentially use impacket-secretsdump with the svc_loanmanager credentials to perform a DCSync attack and extract credential material for domain users, including the Domain Administrator account.
Get the svc_loanmanager account username in the Active Directory
I then used impacket-secretsdump with the svc_loanmanager credentials to perform the DCSync attack.
The attack was successful, and I was able to retrieve the NTLM hash of the Domain Administrator account.
With this hash, I could use Pass-the-Hash to authenticate as the Domain Administrator without needing to know the account’s plaintext password.
Finally, I used impacket-psexec with the Domain Administrator’s NTLM hash to authenticate to the machine using Pass-the-Hash.
Once I obtained a shell as Domain Administrator, I navigated to the Administrator’s Desktop and retrieved the root flag, completing the machine.
Top comments (0)